Suppose you want to design a new Split-Join called Service Availability that handles orders for a telco's cable service package including TV, phone, and internet service. The idea is for the Split-Join to receive an incoming package order and to reply with an order acknowledgement for each type of service. In this case, Service Availability is designed as a Static Split-Join because there are three message requests per order, one for each type of service. In this particular example the customer requests only TV and DSL service.
Creating the Service Availability Split-Join may include the following tasks:
4. Adding an Assign for Each Branch
5. Adding an Invoke External Service
6. Adding an Assign for Each Branch
7. Exporting and Testing the Split-Join
Create a new Split Join based on the WSDL operation you want to use for placing the order. In this case the WSDL operation we want is called "telecom."
After you select the WSDL operation, a skeleton of the newly created Split-Join appears in the Split-Join editor, as shown in the following figure. It consists of a Start Node, a Receive, a Reply. The labels are then edited in the general properties tab to better reflect the specific function of each node in this particular Split-Join.
The Start Node contains both a Request Variable and a Response Variable that have been determined by the WSDL operation initially selected. The Receive receives the incoming request message (in this case for the three or fewer different kinds of cable service), and the Reply generates a response message and sends it back to the client.
Note: | The Receive node requires no further configuration. Similarly the Reply requires no further configuration, unless to generate an error fault--which is not the case in this scenario (see Configuring a Reply for more information on generating faults). |
The first Assign, Prepare Output Message, contains an Assign operation that prepares the Response Variable in a form such that the later nodes can work on the data within it (that is, Copy/Insert/Assign/Replace/Delete the data). This output message is relayed to the final Reply node in the Split-Join and, in turn, returned to the original client.
The Parallel Node contains two main branches, one to check cable TV availability and one to check DSL availability. Each branch is composed of a number of actions, the sequence and general configuration being the same for both branches.
The first Assign in each Parallel Branch, Prepare Input Address, copies the incoming customer address data into a Variable that is referenced to check the availability of the service at that location. The Assigns are the same for each branch and would be for additional branches as well.
An External Service is then invoked to check whether the requested service type is available at the customer's location. Each branch contains one Invoke External Service, Check Cable TV Availability and Check DSL Availability. Each invocation calls an External Service, which compares the customer's address (stored in the Variable initialized in the previous step) to the availability of the service at that location. The result is then stored in an output Variable that is passed on to the final Assign in the Branch below.
The final two Assigns, Update Cable TV Status in Output Message and Update DSL Status in Output Message, take the results of the external service invocations and put them into the output message using a Replace operation. The aggregated response are then sent to the original client in the final Reply node, which requires no further configuration.
After you design the Split-Join, you can export it to the ALSB console for testing and production.
Related Topics