Chapter 10. Advanced Orchestration with Branching and Asynchronous Flows

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...

Getting ready

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.

Setting up Trello

For this orchestration, we are going to use Trello. This is a collaboration tool that organizes projects and tasks into boards and lists. It can tell what is being worked on, who is working on what, and where something is in a process. The Trello API with the adapter offers operations to let you search, read, create, and update the board, task content, and metadata. In our case we are creating a new task for ground personnel when a flight has arrived at the gate. To complete our setup of Trello, we need to execute the following steps:

1. Get access to a Trello account.

2. Create a new Board and Tasks list.

3. Obtain list identification.

4. Obtain API credentials.

Step 1 – Getting access to a Trello account

For this integration, we can use any Trello account you can get access to. If you do not have an account yet, or want to have an extra account for testing purposes, go to trello.com/signup and follow the instructions.

Step 2 – Creating a new board and tasks list

To allow ICS to interact...

Updating the apiary Flight API

For this orchestration, we are reusing the Flight API built using apiary in Chapter 2,Integrating Our First Two Applications. In the current state the Flight API only has one resource, providing a list of all airlines and the details of each airline in the list. We are going to add two more resources to get a specific airline based on a flight airline code (two characters).

To update the Flight API in apiary we need to execute these steps:

1. Log in into apiary and switch to the Flight API endpoint.

2. Change the source of the API Blueprint.

Step 1 – Log in to apiary and switch the API

To allow ICS to retrieve specific airline information we need to change the blueprint of the API. Go to login.apiary.io, and log in with your credentials. If you have only one API on your account you are redirected to the ICS Flights API; otherwise you can click on the name of the current selected API and switch to the ICS Flights API as shown in the following screenshot:

Step 2 – Change...

Defining the necessary connections

In this chapter, we will reuse most of the inbound and outbound connections from previous chapters. The only connection that we need to create is the one to the Trello API. You should have created all the other connections in past chapters, but we will need to update one to also work as an invoke connection.

In ICS, navigate to the connections page and create a connection using the Trello adapter. Create a connection to Trello with the following details:

Property	Value
Connection Name	Trello_Ch10
Identifier	This will be proposed based on the connection name and there is no need to change it unless you would like an alternative name
Connection Role	Invoke
Description	The description should be: This connection interacts with the Trello API to for example create or list tasks

After creation, configure the connection with the following details:

Building the orchestration

With the connectors established we can create the orchestration. Instead of creating an integration with the Basic Map Data pattern, we are doing something different this time. Create an integration with the Orchestration pattern as shown in the following screenshot:

Create the orchestration using the following details:

Property	Value
Email Address	Your e-mail address
Configure Security | Credentials...

Property	Value
Integration Name	FlightScheduleUpdateProcess_Ch10
Identifier	This will be proposed based on the connection name and there is no need to change it unless you would like an alternate name
Version	01.00.0000
Package Name	ics.book.ch10
Description	The description should be: This orchestration will take the ScheduleUpdate request and will call different services based on the flight identification

With the empty orchestration created you can immediately see that the UI is different from a basic map data pattern of integration. The UI and functionalities offered will progressively change based on the completeness...

Completing and activating the integration

Now that the logic of our orchestration is finished we only need to add the tracking fields before we can complete and activate the orchestration. At the top right, click Tracking to open the Business Identifiers dialog. We are going to set two tracking fields: updateType and ident. Drag and drop both trigger fields to the list and use updateType as the primary identifier. Change the tracking name of the updateType field to Flight Update and change the value of the ident field to Flight Id. Click Done to save the identifiers and, in the orchestration canvas, subsequently click on Save and then Exit Integration to finish our orchestration. We are returned to the list of all the integrations. Notice that the UI shows most of the connections that we used in the orchestration. To scroll through the connections click on the angle bracket (< or >) as shown in the following screenshot:

Use the PENDING ACTIVATION button of the integration we have...

Testing the orchestration

Before testing our solution, we need to know the web address for the endpoint our integration is running. Click the information icon on the right side of our entry to view its activation details. Find the Endpoint URL within the integration details and copy the address to your clipboard. Notice that the endpoint of an orchestration does not differ from an endpoint that exposes an integration. The URL will look similar to: https://xxx-yyy.integration.zzz.oraclecloud.com/integration/flowsvc/soap/FLIGHTSCHEDULEUP_CH10/v01/?wsdl.

Invoke a cloud endpoint using SoapUI

To test our cloud endpoint we are going to use SoapUI again to simulate our flight tracking and incident system. Instead of creating a new SOAP project, we have created one for you to use to make these steps easier. Import the SoapUI project from the chapter resources. This can be done through the File menu and selecting Import Project. Open the project file FlightScheduleUpdate-Ch10-soapui-project.xml, which can be found in the book's resources for this chapter. This SoapUI project contains the SOAP binding to send messages to our orchestration and a test suite with two test cases. The first test case includes four calls to the orchestration, each with a different flight identification and a different outcome. Each call takes a different path in the orchestration. The second test case will call the orchestration twice; one call executes the otherwise branch and the other call will result in a fault as shown in the following screenshot:

Before we can...

Summary

In this chapter we looked at how ICS provides the means to perform a powerful level of orchestration when creating an integration. We first explained the high-level differences from the integrations we have built up so far. We reused a few connections we built in earlier chapters, but also created a new connection to the SaaS application Trello, which is a Jira-style application. We also updated the existing REST API available at Apiary.io. After the initial setup we started building our orchestration and granularly made the process more intelligent. We first looked at the different UI and workflows, compared the basic map data integrations, and explained the available actions, which ranged from simple to more advanced functionality. To give you a basic feel for creating an orchestration, the more common actions were introduced, for example, assign, switch, and branches. Because of the different routes we implemented, we then needed to test the orchestration extensively. Using the...

Building the orchestration

With the connectors established we can create the orchestration. Instead of creating an integration with the Basic Map Data pattern, we are doing something different this time. Create an integration with the Orchestration pattern as shown in the following screenshot:

Create the orchestration using the following details:

Completing and activating the integration

Now that the logic of our orchestration is finished we only need to add the tracking fields before we can complete and activate the orchestration. At the top right, click Tracking to open the Business Identifiers dialog. We are going to set two tracking fields: updateType and ident. Drag and drop both trigger fields to the list and use updateType as the primary identifier. Change the tracking name of the updateType field to Flight Update and change the value of the ident field to Flight Id. Click Done to save the identifiers and, in the orchestration canvas, subsequently click on Save and then Exit Integration to finish our orchestration. We are returned to the list of all the integrations. Notice that the UI shows most of the connections that we used in the orchestration. To scroll through the connections click on the angle bracket (< or >) as shown in the following screenshot:

Use the PENDING ACTIVATION button of the integration we have...

Testing the orchestration

Before testing our solution, we need to know the web address for the endpoint our integration is running. Click the information icon on the right side of our entry to view its activation details. Find the Endpoint URL within the integration details and copy the address to your clipboard. Notice that the endpoint of an orchestration does not differ from an endpoint that exposes an integration. The URL will look similar to: https://xxx-yyy.integration.zzz.oraclecloud.com/integration/flowsvc/soap/FLIGHTSCHEDULEUP_CH10/v01/?wsdl.

Invoke a cloud endpoint using SoapUI

To test our cloud endpoint we are going to use SoapUI again to simulate our flight tracking and incident system. Instead of creating a new SOAP project, we have created one for you to use to make these steps easier. Import the SoapUI project from the chapter resources. This can be done through the File menu and selecting Import Project. Open the project file FlightScheduleUpdate-Ch10-soapui-project.xml, which can be found in the book's resources for this chapter. This SoapUI project contains the SOAP binding to send messages to our orchestration and a test suite with two test cases. The first test case includes four calls to the orchestration, each with a different flight identification and a different outcome. Each call takes a different path in the orchestration. The second test case will call the orchestration twice; one call executes the otherwise branch and the other call will result in a fault as shown in the following screenshot:

Before we can...

Summary

In this chapter we looked at how ICS provides the means to perform a powerful level of orchestration when creating an integration. We first explained the high-level differences from the integrations we have built up so far. We reused a few connections we built in earlier chapters, but also created a new connection to the SaaS application Trello, which is a Jira-style application. We also updated the existing REST API available at Apiary.io. After the initial setup we started building our orchestration and granularly made the process more intelligent. We first looked at the different UI and workflows, compared the basic map data integrations, and explained the available actions, which ranged from simple to more advanced functionality. To give you a basic feel for creating an orchestration, the more common actions were introduced, for example, assign, switch, and branches. Because of the different routes we implemented, we then needed to test the orchestration extensively. Using the...