The most important difference between UI and workflow The most important difference between a basic map database integration and an orchestration-based integration is that orchestrations can invoke an unlimited number of services instead of only one. The other difference lies in the way it is visually structured. Basic integrations are presented as horizontally structured, whereas orchestrations are vertically structured. When creating a new orchestration the UI shows an empty start point and an arrow pointing to the end. On the left-side you see a panel called TRIGGERS, which when expanded lists the adapter types for which you created one or more trigger connections. The trigger creates the inbound connection into our integration, as shown next:

To display the configured adapters for the specific adapter type, click the adapter type and the appropriate adapters will be shown. The triggers that are supported can be synchronous, asynchronous, and fire-and-forget (one-way without response). For our orchestration we going to use the SOAP connection named FlightSchedules_Ch5, which we created in Chapter 5, Going Social with Twitter and Google as our start point. Expand the adapter type for SOAP connections and drag and drop FlightSchedules_Ch5 to the start point/trigger spot indicated by the large plus (+) symbol as shown in the following screenshot:

Dropping a connection onto the canvas will result in the same wizard being displayed as we would see in a basic map data integration for that kind of connection; this will allow us to define the exact behavior wanted. Complete the endpoint configuration wizard with the following values:

After completing the dialog, the orchestration is updated. Because we chose a synchronous operation in the endpoint configuration, ICS automatically creates several elements, specifically:

If the trigger connection has a fire-and-forget behavior then a stop action is created. If the connection was asynchronous it automatically creates an unconfigured map action and a callback action based on the one you selected when creating the trigger.

Before we go further with building our orchestration process, we want to go through the UI and the available building blocks (activities), for implementing our orchestration. At the top-right several icons are provided for adjusting the size of the integration canvas. The integration can be zoomed out (decrease size), zoomed in (increase size), and zoomed to fit the page. With the home icon we can align the integration to a normal size in the upper left corner of the page. The reset icon resets integration back to the normal size.

Activities can be moved separately on the integration canvas, but it is also possible to move multiple activities by enabling multiple select, which is the last icon on the right. Drag the cursor around parts of the integration you want to select. Below the icons you will find a box that shows the scale of the integration we are building. You can place your cursor within the box or on the canvas to move the view of your integration, as shown in the following screenshot:

On the left you will find two collapsed panels holding the available activities: invokes and actions. If you click on the invokes panel it expands and lists the types of adapter, for which you created one or more invoke connections. The invoke adapters that are supported can be synchronous, and fire-and-forget. If you click on action the panel expands and lists the available building blocks to complete your orchestration. Let us look at these actions first.

ICS is being regularly enhanced with additional capabilities; a number of these will resemble those provided by the SOA suite as both products look to address orchestration requirements. It is important to remember that, while SOA is guaranteed to align to the BPEL standard, ICS is not bound to these standards. Let's have a look at these more advanced actions:

In this chapter, we are only using the basic functionality to explain the concept around orchestration. On our website oracle-integration.cloud, we will explain the more advanced orchestrations.

Let's continue with our process. The first thing we are going to add is an invoke to the FlightAirlinesREST connection created in Chapter 2, Integrating Our First Two Applications. We are going to call the /airline/{code} resource to get additional information about the airline. Expand the INVOKES panel and click on REST to display all configured connections. Drag and drop the connection FlightAirlinesREST_Ch2 to the plus symbol (+) above the ScheduleUpdate map activity as shown in the following screenshot:

The endpoint configuration is displayed. Finish the dialog with the following details:

In our process the invoke activity is added and an unconfigured map activity is added to give us a value to the code parameter that the request URL requires, as shown next:

Click on the map activity and then the edit icon to configure the mapping. This will open the mapper UI, which is the same as when creating basic integrations. To determine the value of the template parameter code, we need to substring the first two characters from the value of the ident source element. Click on the target parameter code to open the expression builder.

In the expression builder, drag and drop the string function substring from Mapping Components to the code parameter of the selected mapping statement on the right. The function requires two arguments, the string to substring from and the starting location, but it can also handle an optional third argument for the length of the substring. Drag and drop the element ident from the Source to the first argument, for the second argument set the literal value 1. Right-click on the second argument and create a sibling after it. For this third argument set the literal value 2. The expression should result in: substring(/nssrcmpr:ScheduleUpdate/nssrcmpr:ident, 1, 2). Click on Save and then Close to close the expression builder and then click on Save and then Exit Mapper. Notice that the GetAirlineDetails map activity has turned green. This means it is configured.

Our main goal in the process is to act on the flight status and on the social preference of the airline. Based on these values we branch the flow, but instead of using the available data from the variables created by the trigger and the invoke, we can use the assign action to simply our own variable and make the expressions used to branch on.

Expand the ACTIONS panel and drag and drop the Assign action below the GetAirlineDetails invoke activity as shown in the following screenshot:

A dialog opens where you can create a set of assignments. A set requires a name and an optional description. In our case, name the set AssignExprVariables and give the set the description Assign activity for set of expression variables. Click on OK to create a new empty set as shown in the following screenshot:

After creating the set we are presented with a page where we can create the variable assignments. A variable assignment requires a name, description, and an expression to retrieve the value as shown in the following screenshot:

In our case, we are going to add two variable assignments. Click on the first column Name and enter the value FlightStatus. This name will be the name of the variable. For the column Description enter the value Status of Flight update. To assign the value we need to add an expression. Click on the pencil to open the expression builder. For this first variable drag and drop the source node updateType to the expression area on the right as shown as follows:

Exit the expression builder to accept the expression. Add a second assignment by clicking on the plus (+) button with the following details:

Click on Exit Assignment to return to the orchestration canvas. The activity will turn green, which means it is configured and has one or more complete variable assignments. Now that we have those variables available in the orchestration we can use them in other assign, map, and switch actions. The next step in our process is to branch on the status of the flight update. Based on the status a different route in the process is taken if the value equals on time. Other statuses are routed to the Otherwise branch.

In the orchestration canvas expand the ACTIONS panel and drag and drop the Switch action to the plus (+) symbol below the AssignExprVariables activity. It will add the switch (?) activity and two cases; one is Undefined and one is Otherwise, as shown in the following screenshot:

To define the expression for the flights that are on time click on the Undefined branch and subsequently the edit icon. The condition builder is displayed where we can enter the condition to branch on. Start by naming the expression FlightAtGate. For this branch we are using the FlightStatus variable. Find the variable in the Source panel and drag and drop it to the first part of the expression. In the second part enter the literal value "at gate" (including the quotes) as shown in the following screenshot:

Exit the condition builder and return to the orchestration canvas. Both branches are now configured and we can continue expanding our process. Let's start with the FlightAtGate branch, because this will include most of our process logic. Drag and drop the Trello_Ch10 invoke from the Invokes | Trello panel to the plus (+) symbol behind the FlightAtGate condition. Complete the endpoint configuration wizard using the following details:

After closing the dialog a new map activity is created and then an invoke activity is created. Configure the map activity and complete the mapping using the following details:

After creating these mappings exit the mapper and remember to periodically save the orchestration. Before we continue let's look at the process which should look similar to the following screenshot:

Currently there is a limitation: we cannot put a switch activity as a child of a branch. We will finish the Otherwise branch, which will return a response at the end so the FlightAtGate path can continue. In the Otherwise branch, we will call two services to process other flight updates. We will first retrieve the current date and time based on the longitude and latitude of the current flight position using TimeDB_Ch6 and enrich our request. Secondly, we will publish the message to our existing integration PublishFlightStatusUpdate_Ch3.

Drag and drop the TimeDB_Ch6 connection from the INVOKES | REST panel to the plus symbol within the Otherwise branch. Complete the endpoint configuration using the following details:

Next drag and drop the FlightSitRep_Ch3 connection from the INVOKES  SOAP panel to the plus (+) symbol after the EnrichTimeZone invoke activity. Complete the endpoint configuration using the following details:

Lastly before we start configuring the needed mappings, for which activities are automatically created, the Otherwise branch will return an answer to the caller of the integration. This means that the process will complete its work and everything after this won't be executed. Drag and drop the return activity from the ACTIONS panel after the PublishFlightUpdate invoke activity. Your branches should look like what is shown in the following screenshot:

Notice that the Otherwise and the FlightAtGate branch are now two completely separate flows. Because of this we can add a second switch activity to the FligthAtGate branch. We will do this after completing the mapping for each of the map activities in the Otherwise branch. Click on the EnrichTimeZone map activity and configure it using these details:

Save and exit the mapper to return to the orchestration canvas. Next click on the PublishFlightUpdate map activity and configure it using these details:

Save and exit the mapper to return and lastly click on the ScheduleUpdate map activity and configure it using these details:

For the final time in the Otherwise branch, save and exit the mapper. We have finished this branch and it may be a good time to save the orchestration. With this part behind us we can continue to complete the FlightAtGate route. Drag and drop a switch activity from the ACTIONS panel after the CreateNewTask invoke activity and just before the ScheduleUpdate map activity. This switch activity is going to have three branches and we will branch based on the social preference of the airline. By default, we have one unconfigured branch and one Otherwise branch. For our orchestration we want a branch when the airline's preference is Twitter, a branch when the preference is Salesforce, and an Otherwise branch. We need to add a second branch that we can configure. Click on the switch activity represented by the question mark icon and subsequently click on the plus (+) icon to add a new branch.

Click on the first branch and click the pencil icon to edit the condition. Name the expression SocialPrefTwitter. For this condition we are going to match the SocialPreference variable with the literal value Twitter. Drag and drop the variable from the Source panel to the first part of the expression and type the literal value into the second part. Save the condition and exit the condition builder. Do the same for the second branch, but this time call the expression Salesforce and configure the condition to match SocialPreference against the literal value Salesforce. This part of the process should look similar to the following screenshot:

Now the three branches are configured, we can complete each branch with the correct invocation. The first branch will send an update to Twitter, the second branch will create a FeedUpdate in Salesforce, and the third otherwise branch will write the update to a FTP target. Drag and drop the Twitter_Ch5 connection from the INVOKES panel under the Twitter category to the plus (+) symbol within the SocialPrefTwitter branch. Complete the endpoint configuration using the following details:

After closing the dialog the invoke activity and featured map activity are created. Complete the mapper configuration with the following source-to-target mappings:

After creating the mapping click on Save and Exit Mapper to return to the orchestration canvas. We mentioned that we keep these branches simple, so this branch is now completed and we can continue with the SocialPrefSF branch. Drag and drop the Salesforce_Ch4 connection from the INVOKES panel under the Salesforce category to the plus (+) symbol within this branch. Complete the endpoint configuration using these details:

After closing the dialog we need to configure the map activity. To create a FeedItem we need a ParentId, for example our profile feed from Salesforce. Just like in Chapter 4, Integrations between SaaS Applications, retrieve it by following these steps:

Complete the map activity CreateFeedItem with the following mappings:

Save the mapping and exit the mapper to return to the orchestration canvas. Lastly we need to complete the Otherwise branch. If we receive a social preference other than Twitter or Salesforce, we append an update about the arrival in a file that we write to FTP. Drag and drop the AirportData_Ch9 connection from the INVOKES panel under the FTP category to the plus (+) symbol within the Otherwise branch. Complete the endpoint configuration using these details:

After closing the dialog configure the mapper with the following mappings:

Save the mapping and exit the mapper to return to the orchestration canvas. All branches should now be completed and all mappings should be configured and valid. We have one last task before our process can be ready for activation: process response mapping. Click on the map activity ScheduleUpdate and configure it using the following source to target mappings:

After completing this last mapping our process is done. The next steps include activating and testing the process, but before we continue let's look at the last part of the process as shown in the following screenshot: