Typical workflow and steps to execute
Before we dive deep into the major three areas, let's first take a look at the typical workflow when creating integrations with Oracle Integration Cloud Service. Since ICS is a cloud service, you only need to open a browser and enter the URL of your Cloud instance, for example: https://instancex-domainy.integration.us2.oraclecloud.com/ics.
We can sign into Oracle Integration Cloud Service by entering our credentials. Just like any Oracle Cloud Service users can be provisioned after subscribing to a service. After logging in we are welcomed by the home page:
The home page gives an overview of all major functionalities that ICS has to offer. On this page we can easily navigate to each of these functions or to the help pages to learn the details. Besides the home page, all the functions are part of the Designer Portal. We use the Designer Portal to create the five pillars of ICS: Integrations, Connections, Lookups, Packages, Agents and Adapters. We will discuss the pillars in the chapters to come, but we specifically address the agents in Chapter 11, Calling an On-Premises API and adapters in Chapter 13, Where Can I Go From Here?:
Let's investigate the most important pillars. Each integration starts with a blank canvas:
An integration always consists of a Trigger (source) and an Invoke (target). A Trigger means the connection where the integration receives the message from. An Invoke means the connection where the integration sends the message to. These two connections are the first two objectives before creating an integration.
In the following figure, both Trigger and Invoke connections use a SOAP connector. Just simply drag and drop the connection to use from the Connections panel onto the drop zone:
When integrating two applications with each other, it is likely that the data structure which the Trigger and Invoke applications understand is different. The next objective is to map the data between the two applications:
It depends on the type of connection pattern which mappings you can create. For example, when dealing with an asynchronous/one-way operation you only have a request mapping. When dealing with a synchronous operation you have both request and response mappings. The only time you can create a fault mapping is when both trigger and invoke connections define faults. For instance, in the preceding case where both WSDLs define a business fault in their specification.
For point-to-point integrations these are the objectives to reach. But if you are dealing with more complex integrations a typical workflow can consist of a few more objectives.
For instance, if the data received from the Trigger needs to be enriched (that is, locating and adding additional data based on data included in the message) before it can be sent to the Invoke. The next objective would be to add a call to an enrichment service. This enrichment service can be a different connector from your trigger or invoke:
An enrichment service can easily be added with a simple drag and drop of the connection. Another objective can be to route to a different target based on the source data:
All of these objectives are going to be discussed in detail, but first let's explore the concepts and terminology behind them.
