This chapter gives us an overview of the concepts and terminology that apply when implementing integrations with Oracle Integration Cloud Service. It explains the components a general integration consists of, with a step-by-step approach.
When we talk about integration, we mean the act of bringing components together into one single system. In the context of IT, we refer to a process that stitches together different subsystems, so that the data contained in each system becomes part of a larger single system that can share data more quickly and easily.
Oracle Integration Cloud Service is a solution that enables you to simplify integrations between cloud applications, and between cloud and on-premises applications. It helps you create connections to well-known and less-known SaaS and PaaS applications, using the available cloud adapters, publish or subscribe to the Messaging Cloud Service, or use industry standards such as SOAP, REST, FTP, File, and JMS. Most of these technologies will be explained in more detail later. Integration Cloud Service (ICS) provides enterprise-grade connectivity regardless of the application you are connecting to or where they are hosted.
The concepts and terminology can be categorized into three major areas:
- Connections describe the inbound and outbound applications that we are integrating with
- Integrations describe how information is shared between applications
- Transformations and lookups describe how to interact with the data
We can engage with Oracle Cloud Services and especially with ICS by going to http://cloud.oracle.com/integration. Here we can try the service for free, which we can use when going through this book.
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.