Description:

SpringContextProcessor – allows integration of processes encapsulated in Spring Application Context to run as NiFi processor by becoming a runtime host for an instance of Spring Application Context.

Communication between NiFi and process encapsulated within Spring Application Context is accomplished via Spring Messaging (one of the core modules of Spring Framework) and supports 3 usage modes:

• Headless - no interaction with NiFi, meaning nothing is sent to it and nothing is received from it (i.e., some monitoring app). In this case NiFi simply plays the role of the runtime host.
• One way (NiFi -> Spring or Spring -> NiFi). - This depends on existence of pre-defined message channel in Spring Application Context. The name of the channel should be “fromNiFi” and the type org.springframework.messaging.MessageChannel.
• By-directional (NiFi -> Spring -> NiFi or Spring -> NiFi -> Spring) - This depends on existence of two channels in Spring Application Context. One channel receives messages from NiFi with name “fromNiFi” and type org.springframework.messaging.MessageChanneli> and another is to receive messages from Spring with name “toNiFi” and type org.springframework.messaging.PollableChannel.

    <int:channel id=”fromNiFi”/>

    <!—
    your custom app configuration to receive messages from ‘fromNiFi’ channel and optionally send back to NiFi via ‘toNiFi’ channel.
    It could contain any Spring-based application (i.e., Spring Integration, Apache Camel and/or custom code). All you need to do is inject
    channels into your beans and send/receive messages from it.
    -->

    <int:channel id="toNiFi">
        <int:queue/>
    </int:channel>
            

The component is based on assumption that user has an existing Spring Application encapsulated in Spring Context that exposes optional in/out MessagingChannels to allow data to flow to/from ApplicationContext and into/out-of. NiFi. Such application is realized by having a directory on the file system, which contains contains all required resources for such application to run. Such resources usually are JAR files to satisfy application's class-path as well as JAR representing the application and its configuration. Below is the example of what such directory may contain. In this case the 'SI_DEMO-0.0.1-SNAPSHOT.jar' represents the actual application and the rest of the JARs represent class-path dependency required by an application.

        deps
         ├── SI_DEMO-0.0.1-SNAPSHOT.jar
         ├── aopalliance-1.0.jar
         ├── commons-logging-1.2.jar
         ├── spring-aop-VERSION.jar
         ├── spring-beans-VERSION.jar
         ├── spring-context-VERSION.jar
         ├── spring-core-VERSION.jar
         ├── spring-expression-VERSION.jar
         ├── spring-integration-core-VERSION.jar
         ├── spring-messaging-VERSION.jar
        

You introduce the processor the usual way and then configure its properties:

• Application Context config path [REQUIRED] - a path to the Application Context configuration. The path is relative to the class-path of the application defined by the Application Context class path property
• Application Context class path [REQUIRED] - a path to a directory on the file system where application dependencies are.
• Send Timeout [OPTIONAL] - the wait time for sending messages to Spring Application Context. Only required if NiFi plans to send data to Spring. Defaults to 0 (don't wait). FlowFiles that were successfully sent to Spring will be removed from session while FlowFiles that could not be sent to Spring will be routed to failure relationship.
• Receive Timeout - [OPTIONAL] - the wait time for receiving messages from Spring Application Context. Only required if NiFi plans to receive data from Spring. Defaults to 0 (don't wait). FlowFile is created if and only if a message is successfully received from Spring. It is then transferred to success relationship.