Using Split-Joins in OSB Services for parallel processing of messages.

The Split-Join can be a very useful tool in your OSB services yet seems to be underestimated. When I did some asking around it turned out not many developers use this, even though I can come up with plenty of uses for the Split-Join. The Split-Join’s strength is in numbers, meaning it is the most powerful when you need to process a lot of pieces of similar data. For this example I used a simplified version of a project I am working on. In this project mobile devices are set to send data about rainfall to a database. The data is collected at a regular interfal creating a record and sent to the database per session which contains a large set of records. Instead of processing these records one at time I can process them concurrently and save a lot of processing (and waiting) time.

I created the XML Schema files and WSDL’s for the two services using JDeveloper and not Eclipse/OEPE because its design interface for these files is a lot more userfriendly (although this is of course personal preference).

The image shows the Record element, at first I had defined Record to be a complex type,  using it as a type to set for the element in request messages. However this actualy makes it implementing your Split-Join smoothly a bit harder. Having this element defined allows me to create variables using this structure and processing them without using XQuery translations. Saving you a significant bit of processing time inside your service. Especially when dealing with repeating actions (like the parallel processing of multiple records) you want to be aware of unnecessary overhead and try to avoid it. Or as a colleague put it, ‘for each step consider if you really need it’.

As you can see there are Requests and Responses for both ‘InsertRecord’ and ‘InsertRecords’ the first are for the service that processes a single record called storeRecord. This service processes and stores a single record in the database. The second set of messages is for a service that is exposed to the outside and the endpoint where devices will send their collections of records.  As you see the messages are relatively straightforward and most importantly, they both use the same Record element.

The Split-Join is a seperate file/component in your project, so first we create a new Split-Join, when asked for an operation we use the InsertRecords operation from the exposed WeatherData service. This will automatically create a Split-Join object with a recieve and reply action, as well as a request and response variable. Keep in mind that before we can do anything with a variable in the Split-Join they need to be initialized, in this example we use an assign or copy action to intializa variables.  The request variable is initialized for us since it contains the request we will be sending to the Split-Join. The response we initialize by assigning the an empty InsertRecordsResponse to it: <InsertRecordsResponse xmlns=”http://tu.delft/iot/Services/messages”/>.

I added a storeRecordResponseList because I want to collect all responses from the StoreRecord service but I don’t want to send them back as a list of tens or hundreds of response messages, instead we will process this into a single, concise InsertRecordsResponse after all the records have been processed. In a Split-Join you can add a variable by right-clicking the Variables listing. Here you pick the structure for your element. Remember how I created a Record element instead of type, just like I created an element for this list. This is where it comes in handy. Were I to use a type, the variable will automatically use the types name as the root elements name. Even if you initialize it with another root element (of the apropriate type). You could solve this by giving your types the names you would use for elements, but that would mess-up any naming convention and create a messy schema.

Now that we have set up the basics, the real fun can begin. After the Assign Actions place a for-each component in your Split-Join. This for-each component is where the magic happens. Instead of the normal for-each component, this one is able process multiple items in parallel, and with that it is the strength of the Split-Join.

In the for-each we set the counter start value to 1, and the final value to the total number of records: ‘count($request.parameters/weat:Record)’ . Name your counter simple yet clear since you will need it later.

The second step is to create a variable for storing the Record we are currently working on. After we create the Record variable we initialize it by copying the Record for this exexution of the for-each loop into it. To find the right Record we use the previously set Counter.

Once we have our record savely stored away we’ll go ahead and create the service call-out that processes our Record. In a Split-Join this component is called Invoke Service, and just like a Service Call-Out we configure the service and operation we are invoking, as well as an input and output variable. Remember to create these variables inside your for-each loop. In this case we’ll call them storeRecordRequest and storeRecordResponse. storeRecordResponse will be initialized with the response message of the service we invoke, storeRecordRequest however needs to be initialized by us.
We will initialize it by assigning the value ‘<InsertRecordRequest xmlns=”http://tu.delft/iot/Services/messages”/>’ to it.

Once initialized when can go ahead and put our Record in the request. Because we use the same Record element structure everywhere we can simply go ahead and insert it inside the storeRecordRequest variable as a child of the InsertRecordRequest element.

Last but not least we need to do something with the return messages. Remember the storeRecordResponseList variable? It is set to hold one or more storeRecordResponse messages. Again, we do not want to do too much, so with a simple insert we add our local storeRecordResponse to the global list.

Now that we have processed every Record all we need to do is process the response list into a concise response. We can do this by putting an assign after the for-each but before the reply. This will be executed once all parallel executions of the for-each are finished. With an XQuery resource that takes a ResponseList for input we construct the InsertRecordsResponse message for the Reply (response).

To put our newly created Split-Join to use all we have to do is generate a business service based upon the .flow file that we just created (make sure you save it first). Right-click the file and select Oracle Service bus>Generate Business Service. We call this business service from a proxy service using a simple routing that simply passes through the in- and outbound messages, make sure to select that option in your routing. Since the Split-Join and our proxy service use the same WSDL, we don’t have to do anything to these messages, obviously you could add some functionality to your proxy service like a validation step before sending the message of to your Split-Join.

To test the perfomance increase I created a mockservice using SoapUI for the StoreRecord service. In this service I set a 40ms to simulate processing time before it responds. Next I created a similar proxy service using a standard for-each component instead of a Split-Join, using the same steps as I used in the Split-Join example with as little alteration as necessary. Again using SoapUI I created a request with 10 records and sent it alternately to the Split-Join service and the for-each service. The first averages around 520ms of total response time while the latter takes all of 3000ms for the complete roundtrip.

On a last note I can recommend creating a proxy service using a normal for-each after you’ve created your first proper Split-Join to to see exactly what the differences are.

You can download the project here, import it in Eclipse and play around with it. For ease of use the SoapUI mockservice has been replaced with a storeRecord proxy service that echoes a standard response.

SplitJoinBlogCase

There is now a follow-up on this post about dealing with large amounts of messages that can be read here.