Service Bus 12c–Creating Static Split-Join

In this post, you will learn to create and use Split Join and will use the same XYZCustomer project used in previous posts.

Split Join allows you to split the request payload so that you can call multiple services concurrently as opposed to the sequential processing. This way, you will achieve improved service performance.

In this post, you use Split Join to aggregate Customer Information by invoking different business services in parallel. The Customer Information includes basic Customer Details, Orders and Accounts. You can create the business services using the WSDLs given below. Make sure that you create 3 business services named CustomerServiceBS, CustomerOrderServiceBS and CustomerAccountServiceBS using following WSDLs respectively.

Split Join can only be created based on WSDL so create new WSDL in WSDLs folder, having single operation with following. You can get the WSDL used in this post from .

Customer ID as input.

Customer information including Customer, Orders and Accounts Info as output.

Copy CustMigrationSplitJoin.wsdl into WSDLs folder of XYZCustomer project from here and create a new folder SplitJoins as shown below.

Creating Split-Join:

Open Service Bus overview editor and drag Split Join into middle swim lane from Components -> Service Bus -> Resources and finish the creation using wizard as shown below. Make sure that you select SplitJoins folder as the location in wizard.

Drag Parallel activity after Receive as shown below from Flow Control and add another branch by clicking. The Parallel activity allows you to invoke different services concurrently.

In Properties tab, modify Name for all the Scope activities as shown below. Drag Invoke Service activity into each of these Scope activities in all 3 parallel branches from Communication to invoke Business services. Also modify Name property for Invoke activities in Properties tab.

For InvokeCustomer, create Request and Response variables as shown below. Request Variable can be created as local variable as you don’t use it outside the scope.

Now your properties tab for InvokeCustomer should look like below.

Similarly create variables CustOrderReq, CustOrderResp for InvokeCustOrder and CustAccReq, CustAccResp for InvokeCustAccount respectively. Local variables created for each Scope activity should look like below.

Your global variables would be shown at Split Join level.

Drag Assign activity from Assign Operations into each of the scope activity and name them as AssignCustInfoReq, AssignCustOrderReq and AssignCustAccReq respectively in Properties tab.

In Properties tab, set properties for AssignCustInfoReq as shown below. This populates request variable with payload for CustomerServiceBS. Since there are not many fields to map, we have chosen this way to populate the payload avoiding new transformations.

Value:

<cust:customerid_input xmlns:cust="urn:xyzbank:cust:schema:customer">

<customer_id>{$request.parameters/customer_id/text()}</customer_id>

</cust:customerid_input>

In Properties tab, set properties for AssignCustOrderReq as shown below. This populates request variable with payload for CustomeOrderServiceBS.

This would fetch Customer, Order and Account information concurrently by invoking respective business services. And you have to aggregate all these responses before returning back to caller. So you need a transformation to do this.

Create a XQuery map in XQueries folder of XYZCustomer project as shown below. Give name as CustOrderAccountToCustInfo.xqy.

Choose the Source for XQuery map using steps shown below.

Go back to Create XQuery Map window by clicking OK twice.

Similarly add 2 more parameters as shown below to accept Account and Orders information as the input.

Your Create XQuery Map screen should look like below.

Select Target using steps mentioned below.

Click OK twice to finish XQuery map creation and should be visible in XQueries folder as shown below.

Observe the Sources and Target structures and finish the mapping as required and as shown below. You may want to test your XQuery map using the steps mentioned in this post.

Next step is using this XQuery map in Split Join. Drag Assign after Parallel activity from Assign Operations andset properties as shown below.

With this, you are done with message flow for Split Join and let us finish error handling as well before proceeding with testing. The WSDL used for split join has generic fault structure and you will use the same structure to return all types of faults to caller. So we will do fault handling at Split Join level. Right click CustMigrationSplitJoin and select CatchAll as shown below.

In Properties tab, give the fault variable name as shown below.

Drag Reply activity into Catch All branch from Communication.

In Properties tab, set properties as shown below by creating the new fault variable. This enables Split Join to return fault in case of any error to Pipeline.

Drag Assign activity into Catch All branch before Reply activity from Assign Operations. Modify name to AssignFault and set properties as shown below.

Test your Split Join in similar to Proxy service/Pipeline. For my testing, I have used SOAP UI Mock Service to send sample responses to Split Join.

Positive Case:

Negative Case:

Invoking Split Join:

Drag Stage into Request Pipeline of your message flow and set the name as CallSplitJoin. Drag Service Callout from Communication as shown below.

In Properties tab, browse and select CustMigrationSplitJoin for Service property.

Select GetCustomerInfo operation and set other properties of Service Callout as shown below.

sJoinReq is variable to be populated with the payload for GetCustomerInfo operation and sJoinResp is variable that contains response returned by split join after service call. Since you are using ‘Configure Payload Document‘ option, you just need to populate the request variable with required payload.

Drag Assign activity from Message Processing into Request Action of Service Callout and set properties as shown below.