split

Processor that splits the payload into fragments and sends each fragment as a separate message to the given flow.

Processing will not be considered complete until a response has been received for each fragment. If the payload is a collection, each element will be considered a fragment, unless the chunkSize property is used. If the payload is not a collection, the whole payload will be used as a single fragment.

The splitter maintains some state for the delivery of messages and avoids (re-)delivering fragments that have already received a response. This state is not persistent, meaning that the processor does not provide any special delivery guarantees. How long the splitter maintains state for x number of simultaneous messages can be configured.

This has the following connotations:

Message processing is only considered successful if all fragments have successful responses.
Any delivery guarantee has to be implemented upstream in the flow when needed.
Because state is not persistent, downstream target flows/processors that are not idempotent must ensure any guarantees they require themselves.

There is one exception: If a flow ID contains the suffix -handoff, messages are forwarded using handoff semantics. See the handoff processor for more details.

Properties

Name Summary

Name	Summary
`splitterExpiryMillis`	The amount of time after splitting is initiated the splitter maintains state of delivery.
`flowId`	The flow that the fragments will be forwarded to.
`chunkSize`	Optional integer that splits the collection into list-fragments, where each fragment contains a list of at most `chunkSize` elements from the original collection. Note that the last list-fragment could have fewer elements than the configured chunk size. If not set, the incoming collection will be split into one fragment per collection element.
`splitterExpiryCheckMillis`	The frequency of which the splitter checks for and evicts its internal state for abandoned/failed splittings.
`splitterMaxMessages`	The maximum number of active messages that the splitter processor can handle simultaneously. This refers to the number of incoming messages, not the number of message fragments produced by the splitter. If this threshold is reached, the splitter will replace an existing entry by using an undefined strategy.
`allowEmptyPayload`	Optional flag indicating whether the splitter allows empty payloads or not. If `true`, the message exchange will succeed when there are no elements in the payload. If `false`, the message exchange will fail. Defaults to `true`.
`name`	Optional, descriptive name for the processor.
`id`	Required identifier of the processor, unique across all processors within the flow. Must be between 3 and 30 characters long; contain only lower and uppercase alphabetical characters (a-z and A-Z), numbers, dashes ("-"), and underscores ("_"); and start with an alphabetical character. In other words, it adheres to the regex pattern `[a-zA-Z][a-zA-Z0-9_-]{2,29}`.
`exchangeProperties`	Optional set of custom properties in a simple jdk-format, that are added to the message exchange properties before processing the incoming payload. Any existing properties with the same name will be replaced by properties defined here.
`retainPayloadOnFailure`	Whether the incoming payload is available for error processing on failure. Defaults to `false`.

splitterExpiryMillis

The amount of time after splitting is initiated the splitter maintains state of delivery.

flowId

The flow that the fragments will be forwarded to.

chunkSize

Optional integer that splits the collection into list-fragments, where each fragment contains a list of at most chunkSize elements from the original collection. Note that the last list-fragment could have fewer elements than the configured chunk size. If not set, the incoming collection will be split into one fragment per collection element.

splitterExpiryCheckMillis

The frequency of which the splitter checks for and evicts its internal state for abandoned/failed splittings.

splitterMaxMessages

The maximum number of active messages that the splitter processor can handle simultaneously. This refers to the number of incoming messages, not the number of message fragments produced by the splitter. If this threshold is reached, the splitter will replace an existing entry by using an undefined strategy.

allowEmptyPayload

Optional flag indicating whether the splitter allows empty payloads or not. If true, the message exchange will succeed when there are no elements in the payload. If false, the message exchange will fail. Defaults to true.

name

Optional, descriptive name for the processor.

id

Required identifier of the processor, unique across all processors within the flow. Must be between 3 and 30 characters long; contain only lower and uppercase alphabetical characters (a-z and A-Z), numbers, dashes ("-"), and underscores ("_"); and start with an alphabetical character. In other words, it adheres to the regex pattern [a-zA-Z][a-zA-Z0-9_-]{2,29}.

exchangeProperties

Optional set of custom properties in a simple jdk-format, that are added to the message exchange properties before processing the incoming payload. Any existing properties with the same name will be replaced by properties defined here.

retainPayloadOnFailure

Whether the incoming payload is available for error processing on failure. Defaults to false.

Sub-builders

Name	Summary
messageLoggingStrategy	Strategy for describing how a processor’s message is logged on the server.
payloadArchivingStrategy	Strategy for archiving payloads.
inboundTransformationStrategy	Strategy that customizes the conversion of an incoming payload by a processor (e.g., string to object). Should be used when the processor’s default conversion logic cannot be used.

Name

Summary

messageLoggingStrategy

Strategy for describing how a processor’s message is logged on the server.

payloadArchivingStrategy

Strategy for archiving payloads.

inboundTransformationStrategy

Strategy that customizes the conversion of an incoming payload by a processor (e.g., string to object). Should be used when the processor’s default conversion logic cannot be used.

Details

Results

The split processor will only produce a result when all elements in the collection have received a response from the target flow. The processor results are not an aggregate of the responses returned. Instead, the results are built from only one of the elements' processing responses. The element response is chosen by the following order of precedence:

Message failure from a non-transient error
Message failure from a transient error
Successful message
Filtered message

For example, if the main flow (a REST endpoint) receives a JSON array of two objects, but the second object causes a script error in the target flow, the split processor’s results will reflect the script error. On the other hand, if both objects are processed successfully, then the split processor’s results will only reflect one of the objects' responses. It’s not defined which of the two responses this would be.

Handoff Syntax

If the target flow is a handoff flow, then the target flow ID must include the suffix -handoff. This naming pattern signals to the split processor that a handoff is taking place, and so the processor will no longer wait for all processed responses.

See the handoff processor for more details.

Was this page helpful?