Version: 17.07
Supported Since: 17.07
The Invoke Async Flow Processor can be used to clone the current message context and invoke a separate integration flow branch asynchronously while the rest of the original message flow continues as it is.
While some of the attributes of the cloned context will be different from the original context, some attributes will be shared by both. Please refer the following tables on how the important message context attributes and message attributes are been handled in cloning. |
Message Context Attributes
Attribute | Clone with message | Clone without message | Clone without payload |
---|---|---|---|
Context ID |
A new ID will be generated |
||
Message |
Original message will be cloned with payload |
Message will be |
Original message will be cloned without payload |
Exchange pattern |
Can be defined as a parameter in this processor configuration |
||
Scopes |
Current scopes of the original will be inherited |
||
Context properties |
Primitive property values will be cloned. If the property value is a complex object, same object will be referred by both contexts |
||
Context Closeables |
Closeables of the original context will neither be inherited nor cloned |
||
Transactional properties |
Same set of transactional properties will be shared by both contexts |
Message Attributes
Attribute | Clone with message | Clone without payload | Clone without message |
---|---|---|---|
Message ID |
A new ID will be generated |
Message is not cloned under this clone type |
|
Payload |
Payload of the original message will be cloned. Cloning mechanism will depend on the type of the payload. |
Payload will be empty |
|
Transport headers |
Transport headers with primitive types will be cloned. If the header value is a complex object, same object will be referred by both messages. |
||
Message properties |
Message properties with primitive types will be cloned. If the property value is a complex object, same object will be referred by both messages. |
||
Attachments |
Attachments of the current message will be cloned |
Cloned message will not have any attachments |
|
Destination URI |
Will be same as the current value of original message |
||
Content type/Request content type |
Will be same as the current value of original message |
||
Response Code |
Will be same as the current value of original message |
Original Flow |
The original flow will continue through this port |
Async Flow |
The Async flow will continue through this port |
On Exception |
The message context will be sent to this outport if any exception occurred |
Exchange Pattern * |
Basic |
Defines the exchange pattern to be set for the cloned message context. If Keep Original option is selected, the exchange pattern of the original message context will be set to the cloned message context as well. |
Clone Type * |
Basic |
Defines the type of cloning to be used. Please refer the above tables for the comparison between each cloning type. |
In the following use case the requirement is to proxy a HTTP request to another HTTP endpoint while incoming request payload is backed up in local file system in an asynchronous flow to ensure the performance of the HTTP proxy is not affected by the local File I/O delay.
To achieve this, I have included the Invoke Async Flow processing element in the middle of a direct proxy flow which consist of a HTTP ingress connector and a HTTP egress connector.
I have selected the Exchange pattern to be OUT_ONLY since the async message will be guided in to a File Egress Connector which is a out only egress connector. Further I have selected the Message Clone type to With Full Message so that the copy of original message will be included in the message context which goes to the asynchronous flow.