在我的流程中了解NIFI中的通知和等待过程 [英] Understand the Notify and Wait process in NIFI in my flow

问题描述

我是NIFI流程的新手，在我的当前工作中，我已通知并等待流程.有人可以帮助我了解这一流程

I am new to the NIFI process where in my current job, I have notify and wait process. could someone help me to understand this flow

在什么基础上进行通知工作.在我的情况下，我们有4个模式文件进程和4个数据文件，分别是这些文件. 以下详细信息是通知属性.

On what basis the Notify work. in my case we have 4 schema files process and 4 data files with respective those. the below details are notify properties..

下面是Wait属性:

Below are the Wait properties:

***我了解到，等待过程正在寻找8 Signal来继续进行下一级别的过程.但是从技术上讲，这不确定如何.

***I understand that, the wait process looking for 8 Signal to proceed to process the next level of process. but technically how this will woks not sure.

如果有人在此过程中提供详细的技术级别说明，将不胜感激.

Please it will be much appreciate if some one provide in-detail technical level explanation on this processes.

推荐答案

@Andy提到的博客很好地解释了如何使用等待和通知:

The blog mentioned by @Andy gives a nice explanation on how to use the wait and notify together: https://ijokarumawak.github.io/nifi/2017/02/02/nifi-notify-batch/

但是，如果您想更深入地了解技术，我发现各个处理器的文档非常有用.

However, if you want a more in depth technical understanding, I find the documentation of the individual processors very useful.

将传入的FlowFiles路由到等待"关系，直到从相应的Notify处理器将匹配的释放信号存储在分布式缓存中为止.当识别到匹配的释放信号时，等待的FlowFile被路由到成功"关系，具有从FlowFile复制的属性，这些属性从Notify处理器生成了释放信号.然后将释放信号条目从高速缓存中删除.如果等待的FlowFiles超过了Expireation Duration，它们将被路由到"expired".如果需要等待多个信号，请通过目标信号计数"(Target Signal Count)属性指定所需的信号数.这对于将源FlowFile拆分为多个片段(例如SplitText)的处理器特别有用.为了等待所有片段被处理，请将原始"关系连接到等待"处理器，并将拆分"关系连接到相应的通知处理器.配置通知"和等待"处理器以将"$ {fragment.identifier}"用作发布信号标识符"的值，并在等待"处理器中指定"$ {fragment.count}"作为"Target Signal Count"的值在将等待"关系用作循环时，建议使用优先级排序器(例如，先进先出).

Routes incoming FlowFiles to the 'wait' relationship until a matching release signal is stored in the distributed cache from a corresponding Notify processor. When a matching release signal is identified, a waiting FlowFile is routed to the 'success' relationship, with attributes copied from the FlowFile that produced the release signal from the Notify processor. The release signal entry is then removed from the cache. Waiting FlowFiles will be routed to 'expired' if they exceed the Expiration Duration. If you need to wait for more than one signal, specify the desired number of signals via the 'Target Signal Count' property. This is particularly useful with processors that split a source FlowFile into multiple fragments, such as SplitText. In order to wait for all fragments to be processed, connect the 'original' relationship to a Wait processor, and the 'splits' relationship to a corresponding Notify processor. Configure the Notify and Wait processors to use the '${fragment.identifier}' as the value of 'Release Signal Identifier', and specify '${fragment.count}' as the value of 'Target Signal Count' in the Wait processor.It is recommended to use a prioritizer (for instance First In First Out) when using the 'wait' relationship as a loop.

在发行版缓存中缓存释放信号标识符，还可以选择将其与FlowFile的属性一起缓存.一旦在缓存中发现此信号，将释放在相应的Wait处理器中保存的所有流文件.

Caches a release signal identifier in the distributed cache, optionally along with the FlowFile's attributes. Any flow files held at a corresponding Wait processor will be released once this signal in the cache is discovered.

这篇关于在我的流程中了解NIFI中的通知和等待过程的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！