In my previous article I discussed the fall updates of Integration Cloud Service. One of the features in this update is the possibility for content-based routing within integrations. I came across this feature during UKOUG Tech 15 in the beginning of December. In an two our hands-on lab I had some time to play with the content-based routing feature. The amazing thing is that it did it all on my iPad. In this article I will describe the feature and the steps to implement a common use-case.
What does Content-Based Routing mean?
The fall updates introduced content-based routing, which essentially mean that based on a value in the payload a different flow is executed. A use-case for this type of routing is the possibility to retrieve data from a different application based on the country code. With Integration Cloud Service is as easy as adding a filter on the request operation of the source connection.
Step 1: Adding a filter to route on
The first step is adding a filter to route the request on. To demonstrate this I’m using an already existing integration. This integration receives a GET request for retrieving the information of an organization. The current integration always retrieves the organization from the US site.
To add a filter a user would click on the funnel icon. Clicking on this icon will open the Expression Builder. In the Expression Builder a user can set an expression to filter requests on. This can simply be done by drag n drop the field to filter on
For example on the field country: /nssrcmpr:processOrganization/nssrcmpr:organizationParty/nsmpr6:Country
Step 2: Create new routing/branch
To create a new routing for the new branch a user only have to click on the dotted arrow in the branch view.
The user gets a new partly constructed integration. The source connection is the same, but the target connection is empty. The user can drag n drop the correct connection, needed for the other site, on the drop zone of the integration. For example our International Acme Rightnow instance.
Step 3: Every branch has its own mappings
It does not mapper which option you choose, for each branch you need to create a separate request and response mapping or export/import an existing one.
Step 4: Testing the integration
After completing the changes to the integration it should be (re-)activated. This only takes a minute.
It depend on the type of source connection how to test the integration. In this case the integration is exposed by a HTTP (SOAP) endpoint. In this case SoapUI is used to test the integration. The webservice is called two times. In the first call the main branch is tested by specifying USA as Country of the organization to retrieve. With the second call the ELSE branch is tested by retrieving an organization from the UK.
When the user want to look at a specific instance it can by navigation to the page by clicking on the instance link. Instances are trackable by the given business indicator. In this example the business indicator is set on the Party ID. Let’s look at both instances.
As you can see it is now very easy to extend your ICS integration to use multiple sites for retrieving data from or saving data to based on an expression. Right now the request can only be processed in one flow/branch. In the future ICS will get a new flexible, free-form UI Canvas which lets the user drag & drop endpoints, connect wires, configure routes and branches.
It will supports the already existing ICS features like tracking, mapping data. endpoint configuration, content-based routing and customization. New features are branching, looping and pipeline/chaining of callouts. This smells like BPEL to me, but more on this when it is available in the next year.