NiFi调用HTTP API后，如何在调用HTTP API之前获取原始流文件答案

【问题标题】：NiFi after calling HTTP API, how to get original flowfile before calling HTTP APINiFi调用HTTP API后，如何在调用HTTP API之前获取原始流文件
【发布时间】：2019-07-25 21:05:57
【问题描述】：

我有以下调用 rest API 的顺序。

Generate FLowfile 处理器-->jsonpath 处理器-->文本替换处理器（用于后期数据创建）---> InvokeHTTP--->XPATH 处理器用于属性--->生成流文件生成的原始流文件.

所以，在文本替换处理器之后，原始数据将被新数据替换。那么，如何获取原始数据并使用调用API后产生的属性。

【问题讨论】：

标签： apache-nifi

【解决方案1】：

您可以使用来自GenerateFlowFile 的直接输出关系来维护原始流文件，稍后将流文件与 MergeContent 合并，模式为 碎片整理 和 保留所有唯一属性 ，或者如果原始流文件内容足够小，您可以在更改流文件内容之前将其移动到一个属性，然后在收到带有Update Attribute/ReplaceText 的新数据后重新组合它们。

【讨论】：

你能给我一个例子或链接吗

【解决方案2】：

在您有原始文件插入UpdateAttribute 并评估某些独特属性的位置。

例如MyUID = ${UUID()}

UpdateAttribute 之后的success 连接应进入准备流程以调用 http，并且此连接的副本应转到应结合原始和评估的内容和属性的 MergeContent。

流程：

UUID 和拆分：

合并内容：

【讨论】：

【解决方案3】：

两个通用答案是：

Dagget 解释的合并内容
等待/通知，如 here 所述（最初由 Andy 提供）

这些解决方案应该可以很好地扩展并首先考虑。我个人觉得它们有点复杂，所以我也在这里提出一个工作。

如果您正在执行 HTTP 请求，那么您可能只处理少量非常小的消息。在这种情况下，您可以考虑以下“技巧”来避免复杂性。

考虑（ab）使用属性而不是拆分

最简单的解决方法是将所有数据放在一起。无需拆分消息，只需将原始内容的副本放在属性中即可。无论内容中返回什么，此属性在您的 HTTP 请求后仍然可用。

简单的解决方案是在 HTTP 请求之前使用 ExtractText，并创建一个名为 original 之类的属性，其中包含全部内容。

强制警告：属性被设计为很小，因此存储在内存中。因此，将大量内容放入属性中可能会很快消耗您的内存。

为可能的未来读者提供的最终解决方法：如果您控制 HTTP 服务，或者至少了解规范，请考虑是否希望让输出也包含输入。通常不会，但有时你还是会得到它！

【讨论】：