引言
碰巧的是，在我目前的工作场所，我不得不熟悉这项技术。 我将从一些背景开始。 在下一次集会上，我们的团队被告知，我们需要与一个著名的系统进行集成。 集成意味着这个众所周知的系统将通过HTTP向特定端点发送请求，而我们奇怪的是以SOAP消息的形式发送回响应。 一切似乎都是简单而琐碎的。 它遵循所需的条件...
挑战赛
创建3个服务。 第一个是数据库更新服务。 当新数据从第三方系统到达时，此服务将更新数据库中的数据并生成某个CSV文件，以将其传输到下一个系统。 第二个服务的端点称为-FTP传输服务，它接收传输的文件，对其进行验证，然后通过FTP将其放入文件存储中。 第三个服务，即到使用者的数据传输服务，与前两个异步地工作。 它接收来自第三方外部系统的请求，以接收上述文件，获取完成的响应文件，对其进行修改（更新id，description，linkToFile字段），然后以SOAP消息的形式发送响应。 也就是说，总体情况如下：前两个服务仅在要更新的数据到达时才开始工作。 由于信息的使用者很多，因此第三项服务一直在工作，每分钟大约有1000个接收数据的请求。 服务始终可用，并且它们的实例位于不同的环境中，例如测试，演示，预生产和生产。 下面是这些服务的工作图。 我将立即说明简化了一些细节，以避免不必要的复杂性。
技术深化
在计划问题的解决方案时，我们首先决定使用Spring框架，Nginx平衡器，Postgres数据库以及其他技术性的东西来制作Java应用程序。 由于开发技术解决方案的时间使我们能够考虑解决该问题的其他方法，因此我的目光投向了在某些领域流行的Apache NIFI技术。 我必须马上说，这项技术使我们能够注意到这三项服务。 本文将向用户介绍文件传输服务和数据传输服务的开发，但是，如果有这篇文章，我将在数据库中撰写有关数据更新服务的文章。
这是什么
NIFI是一种分布式体系结构，用于快速并行加载和处理数据，用于源和转换的大量插件，版本控制配置等等。 一个不错的好处是它非常易于使用。 琐碎的过程（例如getFile，sendHttpRequest和其他过程）可以表示为正方形。 每个方块代表一个特定的过程，其相互作用可以在下图中看到。 有关过程调整交互作用的更详细的文档在此处编写。 ，对于那些用俄语的人- 这里 。 该文档完美地描述了如何解压和运行NIFI以及如何创建流程，它们是正方形的
写一篇文章的想法是经过长时间搜索和整理以某种有意识的方式获得的信息，以及为了使将来的开发人员生活更轻松的愿望而产生的。
例子
考虑正方形如何相互作用的一个例子。 总体方案非常简单：我们获得一个HTTP请求（理论上，请求的主体中包含一个文件。为了演示NIFI的功能，在本示例中，该请求开始了从本地PF接收文件的过程），然后我们发回了已接收到请求的响应，从中接收文件的过程。 FH，然后通过FTP将其移动到FH的过程。 值得解释的是，进程之间通过所谓的flowFile进行交互。 这是NIFI中存储属性和内容的基本实体。 内容是由流文件表示的数据。 粗略地说，如果您从一个广场收到文件并将其转移到另一个广场，则内容将是您的文件。
如您所见，该图描述了整个过程。 HandleHttpRequest-接受请求，ReplaceText-生成响应主体，HandleHttpResponse-返回响应。 FetchFile-从文件存储中接收文件，并将其传输到PutSftp广场-将文件放在FTP上的指定地址。 现在更多关于这个过程。
在这种情况下，请求就是一切的开始。 让我们看看它的配置选项。
除了StandartHttpContextMap之外，这里的所有内容都很琐碎-这是一项允许您发送和接收请求的服务。 您可以
在此处查看更多详细信息甚至示例
接下来，请参见ReplaceText方形配置选项。 值得注意的是ReplacementValue-这将以答案的形式返回给用户。 在设置中，您可以调整日志记录的级别，可以查看日志{解压缩nifi的位置} /nifi-1.9.2/logs还有失败/成功参数-基于这些参数，您可以控制整个过程。 也就是说，在成功进行文本处理的情况下，调用了向用户发送响应的过程，而在另一种情况下，我们仅承诺不成功的过程。
HandleHttpResponse属性除了成功创建响应的状态外，没有其他特殊之处。
我们用答案对请求进行了整理-让我们继续接收文件并将其放置在FTP服务器上。 FetchFile-在设置中指定的路径处接收文件，并将其传输到下一个进程。
然后PutSftp方框-将文件放入文件存储中。 可以在下面看到配置参数。
值得注意的是，每个正方形都是必须启动的单独过程。 我们研究了不需要任何复杂定制的最简单示例。 接下来，考虑该过程稍微复杂一点，我们在凹槽上写一些点。
更复杂的例子
由于修改SOAP消息的过程，向消费者的数据传输服务变得更加复杂。 下图显示了整个过程。
在这里，这个想法也不是很复杂：我们从消费者那里收到了他们需要数据的请求，发送了他们收到消息的响应，开始了接收响应文件的过程，然后使用特定的逻辑对其进行了编辑，然后以SOAP消息的形式将文件传输给了消费者到服务器。
我认为不应该再描述我们在上面看到的那些正方形-我们将直接使用新的正方形。 如果您需要编辑文件，而像ReplaceText这样的常规正方形不适合，则必须编写自己的脚本。 可以使用ExecuteGroogyScript方块完成此操作。 其设置如下所示。
有两个选项可将脚本加载到此方框中。 首先是通过加载脚本文件。 第二种是通过将脚本插入scriptBody中。 据我所知，executeScript方格支持多个JP-其中之一是常规的。 我让Java开发人员感到失望-您无法在Java中以这种方式编写脚本。 对于那些真正想要的人-您需要创建自己的自定义正方形并将其放入NIFI系统中。 在整个操作过程中，要进行相当长的带有手鼓的舞蹈，在本文的框架中我们将不再讨论。 我选择了时髦的语言。 下面是一个测试脚本，该脚本仅增量更新SOAP消息中的ID。 重要的是要注意。 您从flowFile中获取文件，对其进行更新，不要忘了您需要它，对其进行更新，然后将其放回此处。 还值得注意的是，并非所有库都已连接。 可能仍然需要导入其中一个库。 不利的一面是，这个方块中的脚本很难发布。 有一种方法可以连接到JVM NIFI并启动调试过程。 我个人运行了一个本地应用程序，并模拟了从会话中获取文件的过程。 调试也在本地完成。 加载脚本时发出的错误很容易被Google搜索，并由NIFI写入日志。
import org.apache.commons.io.IOUtils import groovy.xml.XmlUtil import java.nio.charset.* import groovy.xml.StreamingMarkupBuilder def flowFile = session.get() if (!flowFile) return try { flowFile = session.write(flowFile, { inputStream, outputStream -> String result = IOUtils.toString(inputStream, "UTF-8"); def recordIn = new XmlSlurper().parseText(result) def element = recordIn.depthFirst().find { it.name() == 'id' } def newId = Integer.parseInt(element.toString()) + 1 def recordOut = new XmlSlurper().parseText(result) recordOut.Body.ClientMessage.RequestMessage.RequestContent.content.MessagePrimaryContent.ResponseBody.id = newId def res = new StreamingMarkupBuilder().bind { mkp.yield recordOut }.toString() outputStream.write(res.getBytes(StandardCharsets.UTF_8)) } as StreamCallback) session.transfer(flowFile, REL_SUCCESS) } catch(Exception e) { log.error("Error during processing of validate.groovy", e) session.transfer(flowFile, REL_FAILURE) }
实际上，正方形的定制就此结束。 接下来，将更新的文件传输到正方形，该正方形将文件发送到服务器。 以下是此正方形的设置。
我们描述了发送SOAP消息的方法。 我们写到哪里。 接下来，您需要指出这正是SOAP。
添加一些属性，例如主机和动作（soapAction）。 保存，检查。 有关如何发送SOAP请求的更多详细信息，请参见此处。
我们研究了NIFI流程的几种用法。 他们如何互动以及他们有什么真正的好处。 所考虑的示例均为测试示例，与战斗中的实际示例略有不同。 我希望本文对开发人员有所帮助。 谢谢您的关注。 如有任何疑问，请写下。 我会尽力回答。