In the previous chapters we built integrations that primarily had one source (trigger) and one target (invoke) service connection. Within some of our integrations we extended this by introducing enrichment services and chaining integrations using the publish/subscribe pattern. This kind of service could be called after the message was received by the source connection or after receiving the response from the target connection, just before sending the response back to the caller of the source connection. Between these service calls we transformed the message so that the message was in the correct form to be understood by the receiver of the message.
In the previous chapters you might have noticed that we were restricted in making different decisions based on the message content and the limited possibility of chaining service calls.
In this chapter we want to introduce you to orchestration. In Chapter 1, Introducing the Concepts and Terminology, we discussed the basic concepts of orchestration. Orchestration is another pattern that ICS supports and with it we can make more intelligent decisions based on the result of a previous activity. With orchestration we can chain activities (for example, services) to automate certain tasks, perform specific activities based on an expression (branching), and the combine results of multiple activities. In upcoming releases of ICS we will see a huge growth in functionality for this type of integration.
If you are familiar with orchestration in the context of Business Process Execution Language (BPEL) then you will notice some similarities. For example, building the actual orchestration uses a similar UI to JDeveloper's BPEL Designer for SOA Suite and will include, as time goes by, more and more activities we know of from the on-premises SOA suite.
To demonstrate this integration pattern we will revisit some of the connections and integrations we built in previous chapters and reuse them in our orchestration to perform multiple activities based on one incoming event. The following diagram shows the final state of the orchestration as we work through the chapter:
The orchestration will cover to following scenario:
- The orchestration triggers when it receives a call about a flight schedule change from the ICS integration.
- The process calls the
FlightAirlineRESTendpoint used in Chapter 2, Integrating Our First Two Applications to get additional information about the airline. - Depending on the flight status, the request is branched. There is a branch for flights that have arrived at the gate and one for other updates.
- When a flight has arrived at the gate then the following flow will be executed:
- The Trello API is called to create a new card/task for the ground personnel to unload the cargo from the plane.
- Based on the social preference received from the
FlightAPIcall, the request is branched for a second time. A message announcing the arrival is either sent to:
- When the orchestration receives a different status update the message is:
- Both branches return with a synchronous reply back to the caller.
Before we get started we need to have all connections ready for use in our orchestration. As we mentioned we are going to reuse some already existing connections, but we also have some new connections that we are going to use. The new connections include Trello and an updated version of the FlightAirlineREST API (used in Chapter 2, Integrating Our First Two Applications) which we need to set up.
For Trello, we are using another OOTB Cloud adapter. With this cloud adapter it is possible to, for example, retrieve a list of all tasks, update a task list, and create new tasks. Depending on the operation you choose you get a different response. Within the orchestration we are free to use it elsewhere in the process. For the Flight API, we are reusing the already existing connection, but we will update the API definition in apiary to include a new resource to have airline details include social preferences.