 |
The Routing Slip demonstrates how a message can be routed through a dynamic series of processing steps. The solution of the Routing Slip is based on two key assumptions: the sequence of processing steps has to be determined up-front and the sequence is linear. In many cases, these assumptions may not be fulfilled. For example, routing decisions might have to be made based on intermediate results. Or, the processing steps may not be sequential, but multiple steps might be executed in parallel.
How do we route a message through multiple processing steps when the required steps may not be known at design-time and may not be sequential?
Use a central processing unit, a Process Manager, to maintain the state of the sequence and determine the next processing step based on intermediate results.
First of all, let me clarify that the design and configuration of a Process Manager is a pretty extensive topic. We could probably fill a whole book (Volume 2, maybe?) with patterns related to the design of workflow or business process management. Therefore, this pattern is intended primarily to "round off" the topic of routing patterns and to provide a pointer into the direction of workflow and process modeling. By no means is it a comprehensive treatment of business process design.
Using a Process Manager results in a so-called hub-and-spoke pattern of message flow (see diagram). An incoming message initializes the Process Manager. We call this message the trigger message. Based on the rules inside the Process Manager, it sends a message (1) to the first processing step, implemented by Processing Unit A. After unit A completes its task it sends a reply message back to the Process Manager. Next, the Process Manager determines the next step to be executed and sends message (2) to the next processing unit. As a result, all message traffic runs through this central 'hub', hence the term hub-and-spoke. The downside of this central control element is the danger of turning the Process Manager into a performance bottleneck.
The versatility of a Process Manager is at the same time its biggest strength and weakness. A Process Manager can execute any sequence of steps, sequential or in parallel. Therefore, almost any integration problem can be solved with a Process Manager. Likewise, most of the patterns introduced in this chapter could be implemented using a Process Manager. In fact, many EAI vendors make you believe that every integration problem is a process problem. We think that using a Process Manager for every situation may be overkill. It can distract from the core design issue and also cause significant performance overhead.
... Read the entire pattern in the book Enterprise Integration Patterns
Example: Serverless Loan Broker with AWS Step FunctionsNEW
The implementation of the Loan Broker example with AWS serverless services employs AWS Step Functions as Process Manager. Step Functions orchestrates a series of tasks and maintains state across tasks in a JSON document, which covers the characteristics of a Process Manager quote well.
Example: Serverless Loan Broker with GCP WorkflowsNEW
The implementation of the Loan Broker example with GCP employs GCP Workflows as Process Manager.
Related patterns:
Aggregator, Asynchronous Implementation with MSMQ, Asynchronous Implementation with TIBCO ActiveEnterprise, Content-Based Router, Correlation Identifier, Emerging Standards and Futures in Enterprise Integration, Message Channel, Message History, Message Store, Message Translator, Pipes and Filters, Publish-Subscribe Channel, Routing Slip, Claim Check
Integration Pattern Language
