WA1844 WebSphere Process Server 7.0 Programming Using WebSphere Integration Developer Web Age Solutions Inc. USA: 1-877-517-6540 Canada: 1-866-206-4644 Web: http://www.webagesolutions.com
Chapter 6 - Introduction to Mediation Flow Objectives Key objectives of this chapter is to learn: What a mediation flow is Main uses of a mediation flow The basic structure of a mediation flow The basics of primitives Introduction to subflow 6.1 What is a Mediation Flow? A mediation flow is a SCA component that can be used to implement most of the ESB patterns. Mediation flows can be deployed to WebSphere Enterprise Service Bus and Process Server. A mediation flow acts as an intermediary between the actual service providers and consumers Among other things, a mediation flow alters request and response messages, performs routing of requests, and translates the protocol. Like any other SCA component, a mediation flow has one or more service interfaces and zero or more partner references. Service Consumer I Message Flow Logic R R Service Provider Service Provider Service Interface Partner References
Chapter 6 - Introduction to Mediation Flow What is a Mediation Flow? A mediation flow is an SCA component that can be used to implement most of the ESB patterns, such as protocol translation, data transformation and content based routing. Some of the very complex problem scenarios cannot be solved using a mediation flow. They will require the use of a business process or business state machine. These two SCA components can only be developed using WebSphere Process Server. Mediation flows can be deployed to WebSphere Enterprise Service Bus and Process Server. IBM has continuously improved the capabilities of a mediation flow. Now, more complex problems than ever before can be solved using a mediation flow. A mediation flow has the same basic structure as any other SCA component. That is, it has one or more service interfaces and zero or more partner or target references. As required by nearly all ESB patterns, a mediation flow acts as a middleman or intermediary between the actual service providers and consumers. Consumers, instead of directly invoking operations of the service provider, invoke operations of a service interface of a mediation flow. The mediation flow in turn invokes operations of the service provider by invoking an operation of the partner reference. Inside of the mediation flow, message flow logic implements the ESB patterns. 6.2 Source and Target Operations Operations of the service interface of a mediation flow are called source operations. Operations in the interface of a partner reference are called target operations. A source operation is connected to one or more target operations. The connection indicates that when a consumer invokes the source operation, the mediation flow eventually calls one of the connected target operations. 62
Chapter 6 - Introduction to Mediation Flow Source Operation Source and Target Operations Target Operations Operations of the service interface of a mediation flow are called source operations. A consumer invokes these operations. The operations in the interfaces of the partner references of the mediation flow are called target operations. The mediation flow invokes these operations. A source operation is connected to a target operation. This indicates that when a consumer invokes the source operation, the mediation flow eventually calls the connected target operation. A source operation may be connected to multiple target operations from one or more service references. In this case, the mediation flow needs to decide at runtime which one of the many connected target operations should be involved. That is the basic technique used in message routing as we will see later. The diagram above shows how operations are connected in WebSphere Integration Developer. In this case, the mediation flow has one service interface TireOrderManagement. It has two service references with interfaces GoodyearOrderManager and MichelinOrderManager. The placeorder source operation is connected to the createorder and processorder target operations. This means, when a consumer invokes the placeorder operation, the mediation flow eventually invokes either the createorder operation of GoodyearOrderManager interface or the processorder operation of the MichelinOrderManager interface. Note: A source operation does not always have to be connected to a target operation. This is a more advanced configuration. In this case, the mediation flow does not invoke any external service and the mediation flow becomes the sole service provider. 6.3 Message Flow Logic Message flow logic is used to implement ESB patterns. A message flow is a sequence of mediation primitives that alter or route the message. 63
Chapter 6 - Introduction to Mediation Flow A request flow is used to process the request message sent by the consumer of the mediation flow before it is delivered to a target service. A response flow is used to process the reply from the target service before it is delivered to the consumer of the mediation flow. Message Flow Logic The message flow logic forms the heart of a mediation flow. When a request message is sent by a consumer, the message flows through a sequence of steps. Each step is called a mediation primitive. For example, a mediation primitive can convert the message format. Two separate flows are created to deal with the request and response messages. The request flow is a chain of primitives that operate on the request message. At the end of the request flow, an operation of a service reference is invoked and the request message is set as its input. The response flow is a sequence of primitives that operate on the reply from the service operation invoked at the end of the request flow. After the reply message goes through these primitives, it is delivered back to the original consumer as response. A response flow is required only if the source operation has an output (it is a two way operation). In the examples above we see how a message flow is created in WID. First, we see the request flow for the placeorder source operation. The request message is passed through two primitives a message logger and a data transformer. The message logger saves the request message in a database. The message is not modified in any way. The data transformer primitive converts the message into a different format. The converted message is then delivered to the target operation createorder. The second example shows the response flow for the placeorder source operation. The output of the createorder target operation is passed through a message transformation primitive. The converted message is sent back to the consumer of the source operation as output. 64
Chapter 6 - Introduction to Mediation Flow 6.4 Mediation Primitives Mediation primitives are the basic building blocks of a message flow Mediation Primitives Input Terminal Output Terminal Mediation primitives are the basic building blocks of a message flow. Primitives are connected together to form the flow. A message flows through these primitives in sequence. Some primitives change the message content after it passes through the primitive. Others leave the message unaltered. A primitive has one or more input terminals (usually one). The message enters the primitive through this terminal. After that the primitive does its function. For example, the message logger primitive saves the message in a database and the XSL transformer primitive converts the message format. A primitive has one or more output terminals. Most primitives have only one output terminal. Primitives that apply conditional logic (such as the message filter primitive used for routing) have multiple output Fail Terminal terminals. The message comes out of a primitive through one of these terminals. An output terminal of an upstream primitive is connected to an input terminal of a downstream primitive. That means, the message output by the upstream primitive becomes the input for the downstream one. 6.5 Special Nodes A request flow starts with an Input node. 65
Chapter 6 - Introduction to Mediation Flow A request flow may end with a Callout node. This calls an operation of a target service. Use of a callout node is now optional, since a Service Invoke primitive can also call an operation of a service. A response flow starts with a Callout Response node. This represents the reply from the target service. A response flow ends with an Input Response node. This signifies delivery of the response to the consumer of the mediation flow. Special Nodes A flow starts and ends with special nodes. Typically, a request flow ends with a callout node. A callout node calls an operation of a target service. However, since the service invoke primitive was introduced, a callout node has become rather redundant. As of v7, callout is now completely optional. 6.6 Creating a Mediation Flow Right click Integration Logic and select New > Mediation Flow. Enter these values: Name of the mediation flow Name space Source interfaces. Usually only one is selected. Target service interfaces. 66
Chapter 6 - Introduction to Mediation Flow For each target interface, a partner reference is added. You can always add more partner references by clicking Add Reference button in the mediation flow editor. 6.7 Creating an Implementation Click on a source operation to select the implementation type. Creating an Implementation The three types of implementation options are as follows. 1. Service Integration This is a classic mediation flow with callout nodes used to invoke target services. If the source operation is two way, then a response flow is also created. 2. Operation Map This is a special case of the service integration option discussed here. If you choose this option then the request is mapped from the source interface to the target interface. Similarly, the response from the target service is mapped back to the source interface. Only one target service can be used with this option. 3. Blank Mediation Flow If you choose this option then callout nodes are not used. Also, a response flow is not created. You are responsible for using service invoke activities to call target services. This option now makes sense since service invoke primitive makes callout node redundant. With this option, the request and response messages are processed in the same flow. 67
Chapter 6 - Introduction to Mediation Flow 6.8 Anatomy of a Message A mediation flow works with two messages request and response. Primitives in the request flow have access to the request message. Primitives in the response flow have access to the response message. A message is represented as a Service Message Object (SMO) by WebSphere ESB. If a message flow has parallel paths, a separate SMO is used for each path. A SMO has these components: Protocol specific header (such as SOAP and HTTP headers) Context data created by primitives during message processing The body containing the actual message data Message attachments Anatomy of a Message A mediation flow works with two messages the request and response. Originally, the request message is the same as the data sent by the consumer when it invoked the source operation. This message may later be altered by the primitives in the request flow. For example, an XSL transformation primitive can change the contents of the SMO. The response message is originally the same as the output of a target operation invoked at the end of a request flow. Primitives in the response flow can alter this message if needed. The request flow has access to the request message only. Primitives used in this flow can operate only on the request message. Similarly, the response flow and the primitives used there can only work with the response message. If a request or response flow has multiple parallel paths, a separate SMO is created for each path. We will learn about this in more details when we discuss the Fan Out primitive. A message is represented as a Service Message Object (SMO) by WebSphere ESB. Every SMO has these components: 1. Header information 2. Context information 3. Attachments 68
Chapter 6 - Introduction to Mediation Flow 4. The body or the payload The body or the payload contains the actual message data. In most cases, this is the only portion of the SMO that you need to work with. The header information includes communication protocol specific data. For example, if a message arrived using the SOAP over HTTP protocol, then HTTP and SOAP header data will be saved in this area. A common use of the header is to perform dynamic invocation of services. We will learn about that later. Primitives can save additional data in the context for downstream primitives to retrieve. There are several context areas for a SMO. The most commonly used ones are discussed below: 1. Shared context If multiple SMOs are created due to multiple parallel paths, all SMOs share this context. That is, data stored in this context will be visible to all paths. 2. Transient context Unlike the shared context, the transient context is private to a SMO (and as a result, a flow path). Data saved in this context by upstream primitives can be retrieved by the downstream primitives. 3. Correlation context You can store data here within the request flow. The data will be available in the response flow. This context is used to pass data to the response flow. In contrast, shared and transient context are specific to either the request or response flow. 6.9 Routing Primitives Message filter Routes messages based on its body, header or context. Type filter Routes messages based on the data type of the message. Fan out Routes a message to multiple target service operations. Used for parallel processing. Fan In Gathers or waits for response messages from operations invoked by a fan out primitive. Service Invoke Invokes an operation of a service. Routing Primitives These primitives use conditional logic to route messages to one or more targets. The fan in primitive is special in the sense that it is used to wait for reply messages from multiple services. We will learn about some of these primitives in more detail in the routing patterns chapter. 6.10 Transformation Primitives XSL Transformation 69
Chapter 6 - Introduction to Mediation Flow Business Object Transformation Message Element Setter Header setters for HTTP, SOAP, JMS and MQ Data Handler Transformation Primitives These primitives are used to convert the body, context and header of a message. We will learn more about some of these primitives in the data transformation patterns chapter. 6.11 Other Primitives Message Logger Saves the message in a database or file. Stop Ends a flow. Fail Returns a fault. Subflow. Other Primitives We will learn about stop and fail primitives in the error handling chapter. Message logger is covered through a lab exercise. Subflow is discussed later in this chapter. 6.12 Subflow A reusable sequence of primitives that can be called from a mediation flow. Has no defined input and output message types. Subflow A sequence of primitives may be common between multiple message flows. In that case, you can isolate the common elements in a subflow and use them from multiple message flows. Subflow simply fosters reusability in a large project. To create a subflow, right click Integration Logic and select New > Mediation Subflow. A subflow can be truly generic in the sense that its input and output data types are not specified. 70
Chapter 6 - Introduction to Mediation Flow 6.13 Summary In this chapter we discussed: Mediation flow. Various primitives. Service message object (SMO) 71
Objectives This chapter will cover the following topics: How to create a business process in WID? Creating most commonly used BPEL activities. Assembling and deploying a business process. 10.1 Creating a Business Process In a module, right click Integration Logic and select New > Business Process. Enter the name and namespace of the business process. Click Next. Choose if the process is long running or a microflow (see guidance below). Click Next. Select the interface of the process. System can generate a simple interface if you don't have one. See guidance below. Click Finish. System will create the process. By default, the following are automatically added to the process: If the starting operation of the process takes input, a process variable is created. The first receive activity is configured to save the input in that variable. A partner link for the process is created. This is called the interface partner. This partner conforms to the interface of the process. All receive activities must use this partner. If the starting operation returns output, another variable of the output's type is defined. A reply activity is added. This activity is configured to return data from the process variable. Note: This output variable is not initialized by default. You must use an assign activity to initialize it. Creating a Business Process Long Running Process Some processes need to wait for certain events that can take several hours to days. These are long
running processes. As a rule of thumb, a process containing a Receive activity or a human task should be marked as long running. The type of a process can be changed at a later time from the properties page. Process Interface The new process wizard can automatically define an interface for you. In most cases, you should design the interface first before creating the process. This will give you more control over the interface design. Each operation of the interface is associated with a Receive activity in the process. The very first receive activity starts a new instance of the process. A consumer has to invoke the operation for that activity to have a new instance created. Most simple processes will have an interface that has only one operation (which is used to start a process instance). More complex processes that need to wait for events using the Receive activity have additional operations in the interface. Note: Every operation in the interface must be mapped to a Receive activity. If an operation is not associated with a Receive activity, an error is shown. Items Added to a New Process WID intuitively adds many primitives to a newly created business process. This speeds up development quite a bit. You don't have to create a partner link that represents the role of the process (myrole). A variable to save the input is created. A receive activity is automatically added which is preconfigured with the starting operation and the input variable. If the starting operation has an output, an output variable is defined in the process and a reply activity is added to the process to return data to the consumer. 108
10.2 The Process Editor Activity palette Process flow editor To add an activity, select it in the palette and then click on the process flow editor. To view the properties of an activity, simply select it in the flow editor. The Properties view below the editor will be synced automatically. Process ingredients To view the properties of the process itself, click anywhere in the white area of the flow editor. 10.3 Process Variables Process variable saves the internal state of a process instance. Each variable has a name and data type. 109
Click the + icon in the Variables list to create a new variable. From the Properties view, set the data type of the variable. Process Variables Global and Local Variables By default, a variable is global and accessible from anywhere in the process. You can also create variables that are local to a scope. To do that, first add a scope. Select the scope. Now, the variables list will only show the local variables. Click the + icon to create a local variable. Variable Initialization 10.4 Variable Initialization A process variable must be initialized before it can be used as a source of data. For example, if a variable is used as an input for an Invoke activity, it must be initialized. Variables that are used as a target of data, do not need to be initialized. For example, variable used to store the input data obtained by a Receive activity does not need to be initialized. System automatically creates and initializes them. The same happens for variables setup to save the output of an Invoke activity. There are a few ways of manually initializing a variable. You can use the Assign activity. Or, you can use the Details tab of the variable's property page. There, you can supply the source of initial data. That can be another variable, XPath expression or constant value. 110
10.5 Reference Partners A reference partner is a representation of an external service. A reference partner has a name and a service interface. A business process uses a reference partner to invoke an operation available in the service interface. A reference partner does not directly point to any specific implementation of a service. They must be wired to a service or an import of a service for the process to be able to send a request message to the service provider. To create a reference partner, click the + icon next to the list of reference partners. Enter a name. From the Properties view, set the interface. For easy reference, you can view the operations offered by the service interface by expanding the reference partner as shown above. Reference Partners A reference partner is essentially a BPEL partnerlink that represents an external service. Reference partners play a major role in the Invoke activity. A business process uses an Invoke activity to invoke an operation of an external service. After you add an Invoke activity, you need to specify its reference partner and the operation that should be invoked. 10.6 The Interface Partner An interface partner is a BPEL partnerlink that represents the process itself. Usually, there is only one interface partner per process. WID automatically creates the interface partner when a process is created. 111
The interface partner conforms to the interface of the process. External applications invoke operations of this interface to interact with the process instances. One of these operations is used to start the process. The other operations are used to send notifications to an already started instance. We will learn about this in more detail later. The Interface Partner For every Receive activity, you need to specify an interface partner and an operation. A consumer invokes that operation to send a notification to that Receive activity. 10.7 The Receive Activity The receive activity makes the process wait for an external notification. Essentially, the receive activity is configured with an interface partner and operation of the partner's interface. An external application calls this operation to send the notification. For example, a process that needs to wait for an order to be shipped by the warehouse, must use a receive activity. The warehouse software will invoke the operation associated with the receive activity (such as notifyshipment) to send the notification. 112
Every process must start with a receive activity. This activity is specially configured to start a new instance of the process. Receive activities used in the middle of the process do not start a new instance. For a receive activity, you should also specify the process variables where the input to the operation will be saved. Receive activities used in the middle of process must use correlation. The details of why and what is correlation will be discussed in a separate chapter. The Receive Activity The screenshot above shows how to configure a receive activity in WID. The most important configurations are: 1. The interface partner. You can use the Browse button to select it from a list. Usually, there is only one interface partner per process. 2. The operation that is associated with the receive activity. 3. The process variables where inputs to the operation will be saved. 4. A boolean flag stating if a new process instance should be created. This is set to true for the first receive activity only. 10.8 The Reply Activity If the operation associated with a receive activity returns output, you must use a reply activity in the process to supply that output. For every receive activity using a two-way operation, there must be a 113
matching reply activity. The reply activity can appear anywhere after the corresponding receive activity. For example, a long running process can send a reply back immediately and continue to perform activities. For a reply activity, specify: Interface partner. Operation name. This is same as the operation used in the matching receive activity. The process variable from where the output data will be retrieved. These variables must have been created and initialized. The Reply Activity An external application that invokes operations of the process needs to wait for the return data. This return data is supplied by the process using a reply activity. A reply activity is needed only if the operation for the receive activity is two-way. Note that a reply activity does not end a process instance. The instance continues with the next activity. A reply activity simply sends a response back to the client. 10.9 The Invoke Activity 114
For the invoke activity, specify: The reference partner. The operation of the partner that needs to be invoked. Process variables that will supply the input to the operation. These variables must have been created and initialized. Process variables that will save the output from the operation. Note: Invoke activity in WID can invoke any kind of service: Web Service, human task, business rules, Java class, etc. The exact nature of the service implementation is not known to the process. 10.10 The Assign Activity Assign activity is used to copy data into process variables. The source of the data can be: A process variable or its child element (field). Constant (string, number, date) value. XPath expression. You can use this option to do basic data conversion before copying the data into the target. The data can be copied into a process variable or a child element of a variable. In the beginning, a variable does not exist. It must be created and 115
initialized before it is used (say as the input of an Invoke activity). You can set up a variable as a target of an assign activity to create and initialize it. Advanced processes can dynamically manipulate partner references or the endpoint of a service using an assign activity. This is called dynamic invocation. The Assign Activity The most common use of the assign activity is to copy data into a process variable. If the variable does not exist, the system will create it. It is a common error to use variables with an invoke or reply activity that have not been created and initialized. A variable used as the input of an invoke or the output of a reply activity must be created and initialized. There are two ways to create and initialize a variable: 1. Use the variable as a target for an Assign activity. 2. Configure the variable as the input of a receive activity or the output of an invoke activity. 10.11 Parallel Activity 116
Parallel activity (flow in BPEL) allows you to run multiple concurrent flows of activities. Running independent tasks in parallel is a great way to optimize a process. Activities in a parallel activity are connected to each other. The direction of the arrow indicates what task must be finished first before executing the next task. If a task has multiple outgoing connections, then these connections will be followed in parallel after the task finishes. If a task has multiple incoming connections, the source tasks must be all finished before the task can begin. Each connection can have a conditional statement. The connection is followed only if the condition evaluates to true. Tasks that do not have any incoming connection are started as soon as the parallel activity is entered. Caveat: Each parallel flow must use its own transaction. Example: Invoke1 and Invoke2 must use the "Commit Before" transaction attribute. Otherwise, the system will run them in sequence. Also, if you configure WPS with an Oracle database, sequential execution is used. Parallel Activity You can use the example above to learn how parallel activity works. Invoke1 and Invoke2 have no incoming connections. As a result, they are started as soon as the parallel activity is entered. After Invoke1 finishes, Invoke3 and Invoke4 should be started. However, Invoke4 has another incoming connection from Invoke2. This means, Invoke4 will start only after both Invoke1 and Invoke2 have finished. Invoke5 will start only after Invoke3 and Invoke4 have finished. 117
10.12 The Choice Activity Choice activity (switch in BPEL) allows you to run a flow of activities only if a condition is true. Each flow is called a case. Each case has its own condition. Only if the condition is true, the flow for a case is executed. To add a new case, right click the Choice activity and select Add a Case. Select a case and edit its condition from the Properties view. If conditions for multiple cases evaluate to true, only the first case (as it appears in the BPEL document) will have its flow executed. Under no circumstances can more than one flow path be executed. A special case, called otherwise, is executed only if all other cases evaluate to false. It is a good idea to always add an otherwise case to catch any unexpected situations. If such situations should not occur, you should raise a fault. Right click the Case activity and select Add an Otherwise element. 118
10.13 While Loop The while activity contains a flow of activities that is repeatedly run until a condition evaluates to true. Select the while loop and from the Properties view set the condition. The condition can be an XPath expression, a simple condition, or a Java expression. 10.14 For Each Activity It repeats a flow in one of three ways: For each item in an array collection (dynamic bounds). 119
For a given starting count and end count (static bounds). For XPath expressions that return the starting count and end count. For example, if you set the collection to be the addresslist field of the customer variable, then the system will execute the flow once for each addresslist element. In the Properties view, supply the collection that will be iterated. Alternatively, you can also supply a count to control how many times the flow will be repeated. Or, you can supply expressions that will be the upper and lower bounds of the index. The activity can define a local variable that will hold the current index into the collection. Important: If you are iterating over a collection, the value of the index starts with 1. For Each Activity Iteration Type There are three iteration types: 1. Iterate over a collection. A collection will most likely be a field of a process variable. In the example above, we are iterating over all addresses of a customer. This is the most common use case. 2. Loop for a fixed number of times. This is called Integer (static bounds). Supply the start and end value of the index. The index value will be initialized to the start value. After every loop it will be incremented by one. Looping will continue until the index value exceeds the end value. 3. Start expression and end expression. The expressions must return a "long" data type. The index will be initially set to the result of the start expression. After every loop, the index will be incremented by 1. Looping will continue until the index exceeds the value of the end expression. The index variable is called "Index" by default. You can change it to anything. It is of type Long. We see an example above of how to use the index variable to obtain the current item from the collection. If you are iterating over a collection, index starts with 1. As a result, you must subtract 1 to get the Java index. In XPath, an index of an array starts with 1. Getting the Current Element in Array 120
If you are iterating over an array, you would like to know the value of the current element. The For Each activity saves the value of the index in the index variable. You need to use that variable in an XPath expression to get the current element. For example, let us say that you are iterating over the AddressList array element which is a field of the customer process variable. The index variable is called addressindex. In that case, the expression $customer/addresslist[$addressindex] will return the current element's value. Typically, the value of the current element is saved in a process variable using an Assign activity. That variable can then be used with an Invoke and other activities. In the example below, the current element is assigned to a process variable. 10.15 Receive Choice A regular receive activity can wait for one type of event only. A receive choice activity can wait for multiple events. Whichever event occurs first causes the waiting to be over. Essentially, a receive choice activity is a grouping of multiple regular receive activities called receive cases. Each receive case is configured with a method of the interface partner. An external application calls one of these operations to send in a notification. Whichever notification comes first ends the receive choice activity. A receive choice activity can be the very first activity of a process. In that case, it should be configured to create a new process instance. If a receive choice activity appears in the middle of a process, correlation must be configured for each receive case. Also, in this case, a time out 121
branch can be added. If no notification comes within a timeout value, the system will execute the timeout branch. Receive Choice A receive choice activity adds powerful event handling capability to a process. A process can wait for any one of several possible events to occur. Creating a receive activity is simple. Just add multiple receive cases in it. Each receive case is configured like a regular receive activity, including correlation. In the example above, "Add Customer" and "Update Customer" are two receive cases. As you can see, the Add Customer receive case is configured with the addcustomer operation of the interface partner. 10.16 Timeout for Receive Choice You can execute a flow if none of the receive cases fire within a given timeout. Right click the Receive Choice and select Add a Timeout Element. Select the timeout and specify the duration value in the Properties view. The expression language used to specify the timeout can be one of: Java - Specify a date or duration. Timeout allows you to enter static values (shown above). XPath expression - Specify a date or duration. 122
10.17 Defining Conditions Conditions are used heavily in WID in conjunction with Choice, While and Parallel activities. WID provides a common condition editor in all cases. Each condition must evaluate to true or false. There are several ways to define a condition: Simple Specify True or False static value. XPath 1.0 expressions - Can be edited manually or using an XPath expression editor. Example: starts-with($customer/name, 'John') Java expressions - They can be created visually or using straight Java code. Example: return customer.getstring("name").equals("john"); The Java expression must use the "return" keyword and return a boolean value. 10.18 Assembling a Process A few steps must be performed before a process becomes available to the external applications. A process must be added to the assembly editor. All reference partners must be wired to actual services or service 123
imports. If the interface of a reference partner does not match the interface of a service or service import, you will need to use an interface map. An export for the process needs to be created. Usually, this will be a web service export. This will expose the operations of the interface partner as web services operations. 10.19 Summary In this chapter, we learned how to create a basic process using these activities: Receive Reply Invoke While For Each Parallel Flow Choice Receive Choice 124