In Oracle Integration Cloud Service, the core function is creating integrations between applications. Integrations use the created connections to connect to our applications. Integrations define how information is shared between these applications.
Integrations can be created from scratch, but can also be imported from an existing environment (that is, using an exported integration). As explained earlier, an integration always has a source and a target connection. The source and the target define the type of integration pattern that is implemented.
There are four types of integrations; point-to-point (that is, data mapping), publish messages or subscribe to messages, content-based routing, and Orchestration:
For these types of integration you can start with a blank canvas, but Oracle Integration Cloud Service provides templates to quick start your integration.
A point-to-point integration, also known as a Basic Map Data integration in ICS, is the least complex integration pattern. We use a point-to-point integration when we have to send a message to a single receiver (that is, a 1:1 relationship). For example, a customer is updated in the HCM Cloud, which sends out an automatic message to the ERP, to also update the customer details. Another example is that a third-party channel calls an API, which returns flight data from an on-premises database.
This integration pattern is the most common pattern that advertises Oracle Integration Cloud Service. You create an integration and use your defined connections for the Source and Target. You also define data-mappings between the Source and Target and vice versa.
As mentioned previously, the source and target operation that is implemented, determines the kind of integration capabilities. A one-way source can only send data to a one-way target, and a synchronous source can only send data to a synchronous target. This integration does not support mixing one-way with synchronous operations:
Although this pattern supports a more complex integration flow, Integration Cloud Service provides the possibility to enrich the data, by calling another service between the source and the target or vice versa. For example, the target requires more data for its input than the source provides.
By using enrichment services you are able to invoke a service operation that returns the required data. The data from the source and the data from the enrichment service can then be used for the request mapping to the target:
In a one-way integration the source data can be enriched by calling an additional service:
In a synchronous integration both sources as target data can be enriched by calling additional services.
A publish-subscribe integration, in ICS separated in two separate integrations, implements a messaging pattern where messages are not directly sent to a specific receiver. The senders of messages are called publishers and the receivers of messages are called subscribers.
Publishers send messages, which are then published to an intermediary message broker or event bus without knowledge of which subscribers, if any, are interested in the message. On the other hand, subscribers register subscriptions on messages they are interested in, without knowledge of which publishers, if any, are sending these messages. The event bus performs a store and forward to route messages from publishers to subscribers:
This pattern generally uses the message queue paradigm and provides greater scalability and a more dynamic network topology. Most messaging systems support this pattern in their API using Java Message Service (JMS).
The publish-subscribe pattern in ICS can be implemented using its own messaging service, by using the Oracle Messaging Cloud Service (OMCS) adapter or the JMS adapter for on-premises connectivity. All implementations use JMS as its underlying protocol.
The ICS Messaging Service also uses the OMCS for its delivery, but these messages can't be accessed outside of ICS.
The two major advantages of using this kind of pattern are scalability and loose coupling.
This integration pattern provides the opportunity for better scalability of the message flow. Messages can be handled in parallel instead of being processed one after each other. If the amount of messages succeeds the amount the systems can process, a new system or a subscriber can be added. A subscriber can also choose to temporarily stop receiving messages to process already received messages.
When using the publish-subscribe pattern, publishers and subscribers are loosely coupled and generally don't know of each other's existence. Both can operate normally regardless of the state of the other. In a point-to-point integration, the systems are tightly coupled and can't process messages if one of the services is not running. When using ICS it is possible to even decouple the location of the publishers and subscribers by using OMCS or the on-premises JMS adapter.
The advantage of loosely coupling also introduces side effects, which can lead to serious problems. We should also consider issues that can occur during the delivery of messages.
Because the publishers and subscribers do not need to know of each other's existence, it is important that the data is well defined. This can lead to inflexibility of the integration, because in order to change the data structure you need to notify the subscribers. This can make it difficult for the publishers to refactor their code. In ICS this should not be a problem because it can be fixed by versioning the integration and its data structure.
Because a pub-sub system is decoupled, it should be carefully designed to assure message delivery. If it is important for the publisher to know a message is delivered to the subscriber, the receiving system can send a confirmation back to the publisher. If, for example, a message can not be delivered, it is important to log the error and notify someone to resend the failed messages. When designing an integration, keep in mind that delivery management is important to implement.
An integration with content-based routing is a more advanced version of the point-to-point integration. Content-based routing essentially means that the message is routed based on a value in the message payload, rather than an explicitly specified destination:
A use case for this type of routing is the possibility to retrieve data from a different application based on the country code.
Typically, a point-to-point integration receives a message and sends the message to an endpoint. This endpoint identifies the service or client that will eventually process the message. However, what if the data is not available (anymore) at that destination? For example, what if the data specific to the callers country is available at a different site and the service cannot return the requested data? Is it also possible that one destination can only process specific types of messages and no longer support the original functions.
A solution for this is content-based routing. A content-based routing is built on two components: services and routers. Services are the consumers of the messages, and like all the other integrations they decide on which messages they are interested in.
Routers, usually one per integration, route messages. When a message is received the message is inspected and a set of rules are applied to determine the destination interested in the message content. With this pattern we can provide a high degree of flexibility and can easily adapt to changes, for example, adding a destination. The sender also does not need to know everything about where the message is going to end up.
Each destination can have its own implementation, which means the router also needs to transform the message where necessary.
The following diagram illustrates a simple example of the content-based routing architecture. It shows how a message is sent to the endpoint of Service A. Service A receives the message and the Router routes the message to Service B or Service C, based on the content of the message:
With Integration Cloud Service it is as easy as adding a filter on the request operation of the source connection. We can define multiple rules in an if-then-else construction and in every rule we can filter on multiple fields within the request message.
The two major advantages for using this kind of pattern are efficiency and sophisticated decisions.
Content-based routing is very efficient. This is because the decision to route the message to one consumer or the other is kept away from the provider. The decision is based on the provider's request. There is also no risk of more systems than necessary consuming the message (when compared to the pub/sub integration), because we route to dedicated consumers.
When designing a content-based router it can become highly sophisticated. We can have multiple routing rules where one rule can filter on multiple fields of the request message. Content-based routing is easier to incorporate into a process pipeline more often than not.
The disadvantages arise when the number of consumers grows.
When we introduce an additional consumer it also means changing the router (compared to a pub-sub integration, which requires no change). We also need to add an extra routing decision.
The usage of Orchestration comes into the picture when we discuss integrations in the context of service-oriented architecture. Service Orchestration is usually an automated process where two or more applications and/or services are integrated.
We have discussed point-to-point integrations and have seen that in many use cases this pattern fulfills our requirements. However, point-to-point integrations can lead to complex dependencies, if we need to integrate multiple application and/or services. The downside of this is that it is hard to manage, maintain, and possibly monitor.
An integration that implements Orchestration provides an approach that aggregates services into application processes. Orchestration has the capabilities for message routing, transformation, keeping the process state for reliability, and security through policies. The most important capability of Orchestration is centralized management, for example, resources and monitoring.
Orchestration, in a sense, is a controller, which deals with the coordination of (a)synchronous interactions and controls the flow. Usually Business Process Execution Language (BPEL) is used to write the code that is executed. This is also the case with Integration Cloud Service; however, a visual representation is used to define the process.
To get a practical sense of service Orchestration, let us take a look at an example of a mortgage application. A mortgage broker wants to request a mortgage on behalf of a customer. The application uses API that calls an HTTP endpoint, which sends the initial request to the orchestrator through Service A.
The orchestrator enriches the customer data by calling Service B. Based on the age of the customer, Service C or Service D is called to find special mortgage quotes, but Service E is called for everyone. Service E retrieves credit scores belonging to that customer. The data from both service calls are merged and sent to Service F to return the best quote for that customer:
The two major advantages of using this kind of pattern are loose coupling and enabling automation.
Application and business services can be designed to be process-agnostic and reusable. The business process is responsible for the management and coordination of state, which frees composite services from a number of design constraints. Additionally, the logic of the business process is centralized in one location, instead of being distributed across and embedded within multiple services.
In day-to-day operations, Orchestration enables us to automate processes such as insurance claims that come from medical offices. This is one process where human approval can be removed by programming parameters to accept claims. Orchestration can also automate error handling; for example, a message can be retried automatically when an endpoint is unavailable or a notification can be sent to a human when it needs to be recovered manually.
There is one major disadvantage and that is debugging. There can be complex processes, which have multiple service interactions, nested loops, and so on. In these situations, it's not easy to debug your process if something goes wrong, because we need to know what message initiated the flow. We will touch on this topic in Chapter 10, Advanced Orchestration with Branching and Asynchronous Flows.