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 |
Integration Name |
|
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 |
|
Package Name |
|
Description |
The description should be: |
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 of the orchestration.
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:
Tab |
Question |
Action |
Basic Info |
Call your endpoint field? |
Because of multiple operations call it |
What does this end point do? |
Add the description: | |
Operations |
Selected Port Type |
This is automatically selected because only one is defined that is, |
Select the Operation |
Select | |
Request Object |
The objects that are assigned to the operation are displayed. These values change when a different operation is selected. | |
Response Object | ||
Fault Object | ||
Disable validation |
Select No. | |
Summary |
WSDL URL |
The Summary tab as always shows the selected connector information: The Cloud Operation matches the operation we selected in the Operations tab that is, |
Selected Port Type | ||
Cloud Operation | ||
Message Exchange Pattern |
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.
Action |
Purpose |
Assign |
Enables you to assign variables from data that is available in the integration or assign literal values to variables. Variables you create can be used in mappers and in expressions. The variables are only available to this integration. |
Callback |
Enables you to end a process and return to the trigger. The callback action is only available if the trigger supports callbacks. |
Map |
Enables you to add ad hoc mappers to the integration. A map action is normally placed before an invoke action. The target element of the map is the source element of the invoke. The source elements of the map are the variables that are available at that time in the process. |
Return |
Enables you to return an immediate response. The return action is only available when the trigger is synchronous. A synchronous operation always has a return, usually at the end, but for example in a branch (of a switch) we can send a response earlier when another branch is executed. |
Stop |
Enables you to terminate the integration. This action is available when we are dealing with a fire-and-forget trigger or a trigger that supports callbacks. With this action no response message is returned to the trigger. |
Switch |
Enables you to add a switch activity for defining branches based on the routing expression in the integration. For example, if |
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:
Action |
Purpose |
Callout |
Enables you to invoke callout functions to execute logic that is not possible with the standard available functionality. The callout functions are JavaScript-based, but can be compared with custom XPath functions in XSLT. |
For each |
Enables you to loop on files (batches) and on records (array of elements) in a message or file. The logic within the for each is executed for all files/records. A for each can run records in parallel; they are automatically split over clusters to reduce to cost. |
Schedule |
Enables you to trigger the integration based on a scheduled timer instead of a configured connection. This can be useful for file/batch integrations. |
Stage File |
Enables you to optimize the processing for file operations. It is very useful for managed file transfers. This action offers an extraction of the file system; it can read, write, or create files. You can compare it with a staging area for files. This action can extend normal file operations using callout for example, encrypt/decrypt and zip/unzip. |
Wait |
Enables you to put in a wait period to pause the execution before continuing with the next activity. This can be useful when executing a loop and between files or records, there needs to be a wait period because an invoking connection requires it. |
While |
Enables you to loop through a block of activities as long as the specified condition/expression is true. |
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:
Tab |
Question |
Action |
Basic Info |
Call your endpoint field? |
Call it: |
What does this end point do? |
Add the description: | |
What is the endpoint's relative resource URI? |
Enter the URI: | |
What actions does the endpoint perform? |
Select the | |
Select any options that you want to configure: |
The option Add and review endpoint parameters is checked and can not be unchecked because of path parameter in URL Check option:Configure this endpoint to receive the response | |
Request Parameters |
Template parameters |
Our URL consists of the path parameter code. Select string to use as its type. |
Response |
Select Response payload |
Pick: JSON Sample |
Enter sample JSON (click the inline link) |
| |
Summary |
Description |
The description we entered |
REST Service URI |
| |
Method |
| |
Response Media Type |
|
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:
Name |
Description |
Value |
|
|
|
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:
Tab |
Question |
Action |
Basic Info |
Call your endpoint field? |
Call it: |
What does this end point do? |
Add the description: | |
Operation Selection |
Select Operation |
Find and select Create a Card . |
Summary |
Description |
The description we entered. |
Task Resource URI | ||
Method |
Create a Card. |
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:
Source Element |
Target Element |
The literal value of your List Id which you collected when you created the |
|
|
|
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:
Tab |
Question |
Action | ||||||||||||
Basic Info |
Call your endpoint field? |
| ||||||||||||
What does this end point do? |
Add the description: | |||||||||||||
What is the endpoint's relative resource URI? |
Enter the URI: | |||||||||||||
What action does the endpoint perform? |
Select the | |||||||||||||
Select any options that you want to configure: |
The options | |||||||||||||
Configure Headers? |
These can remain unticked. | |||||||||||||
Request Parameters |
Specify Query Parameters |
Add the URI's query parameters into the table and define the expected data types.
|
|
|
|
|
|
| ||||||
|
| |||||||||||||
|
| |||||||||||||
|
| |||||||||||||
Template Parameters |
None will be defined as the URI uses query parameters. | |||||||||||||
Response |
Select the response payload file |
As the TimeZoneDB response defaults to use XML we can use that, so select the XML Schemaoption. We need to provide a schema so use the Choose file to upload the provided | ||||||||||||
Select the type of payload |
Click on the XML option. | |||||||||||||
Summary |
This simply provides what you have provided in the previous tabs – you need only verify that it reflects the values correctly. |
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:
Tab |
Question |
Action |
Basic Info |
Call your endpoint field? |
|
What does this end point do? |
Add the description: | |
Operations |
Selected Port Type |
As we only have a single operation in the WSDL this tab will not offer any options. |
Selected Operation | ||
Request Object | ||
Callback Operation |
Choose the type of response |
Because we have selected a one-way operation, we need to choose the type of response expected for the Select the option: No Response |
Summary |
This simply provides what you have provided in the previous tabs-you need only verify that it reflects the values correctly. |
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:
Source Element |
Target Element |
|
|
|
|
Literal string that represents the key from |
|
Save and exit the mapper to return to the orchestration canvas. Next click on the PublishFlightUpdate map activity and configure it using these details:
Source Element |
Target Element |
|
|
|
|
Empty literal string |
|
Empty literal string |
|
Empty literal string |
|
|
|
|
|
String function |
|
|
|
|
|
|
|
|
|
Save and exit the mapper to return and lastly click on the ScheduleUpdate map activity and configure it using these details:
Source Element |
Target Element |
|
|
Literal string with value |
|
|
|
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:
Tab |
Question |
Action |
Basic Info |
Call your endpoint field? |
Call it |
What does this end point do? |
Add the description: | |
Operation |
Select Operation |
Select Tweet |
Summary |
Description |
This tab shows the connector settings. The Twitter URI shows the URL of the Twitter API. https://api.twitter.com/1.1/statuses/update.json It also lists the query parameters we can provide to send out a more advanced tweet, like geo-location information. |
Twitter Resource URI | ||
Method | ||
Query Parameters |
After closing the dialog the invoke activity and featured map activity are created. Complete the mapper configuration with the following source-to-target mappings:
Source Element |
Target Element |
|
|
|
|
|
|
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:
Tab |
Question |
Action |
Basic Info |
Call your endpoint field? |
Call it |
What does this end point do? |
Add the description: | |
Which Salesforce service you like to design with? |
Select option Standard application delivered by Salesforce.com | |
Operations |
Select and Operation Type |
Select CRUD in the operations list. Select create in the types list. |
Select Business Objects |
Select FeedItem and tick the single arrow. You case use the filter to quickly find the object. | |
Header |
Configure the Header properties for selected operation |
This tab gives a lot of possibilities to configure headers that can be used by Salesforc,e for example triggering an e-mail. In this chapter we are not configuring any of them so leave the default settings. |
Summary |
Operation Name |
This tab gives a short summary about the chosen operation, object name and configured headers. |
Object(s) Name |
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:
/sObject/00558000001NCwhAAG/view
.sObject
, for example 00558000001NCwhAAG
.Complete the map activity CreateFeedItem
with the following mappings:
Source Element |
Target Element |
|
|
Literal string with value |
|
Your profile id you just collected |
|
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:
Tab |
Question |
Action |
Basic Info |
What do you want to call your endpoint? |
Call it |
What does this endpoint do? |
Write update to a file at the target location | |
Configure File Write |
Select Operation |
Select Write File |
Select a Transfer Mode |
Set this to ASCII as we will be writing a XML file. | |
Specify an Output Directory |
Set the target to | |
Specify a File Name Pattern |
Specify the name: The pattern | |
Append to Existing File |
Tick this box to add flight updates produced on the same day to the same file. | |
Schema |
Define a schema for this endpoint? |
Choose the option Yes |
Create a new schema or select an existing one? |
Choose the option Select an existing schema from the file system | |
Format Definition |
Select a New File |
Select the file from book resources: |
Selected File Name |
Will show selected file or none. | |
Select Schema Element |
Select | |
Summary |
This tab gives a short summary about the chosen operation, transfer options and format definition (NXSD) which you can download for reuse. |
After closing the dialog configure the mapper with the following mappings:
Source Element |
Target Element |
|
|
|
|
|
|
|
|
|
|
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:
Source Element |
Target Element |
|
|
Literal string with value |
|
|
|
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: