Part 4 in the Soaring through the Clouds article series, written by Oracle ACE Director Lucas Jellema, focuses on the role Oracle Integration Cloud Service plays in a sophisticated demo designed to allow users to nominate and vote on music artists they want to perform at a special concert..

By Lucas Jellema

Article Series Table of Contents

1. Introduction: How to Integrate Ten Different Oracle Public PaaS Services
2. Internet of Things Cloud Service
3. Building the Authorization Process and Microsite
4. Integration Cloud Service to Connect the Dots
5. Orchestration, Enrichment and Persistence with SOA CS and DBaaS
6. Lightweight Application Container Cloud Service for Rich API implementation with Node.js
7. Mobile Cloud Service
8. Oracle JET application on top of MCS and ACC

To make systems work together, they need to understand each other. A little help is often needed to get the conversation going. In our end-to-end cloud integration flow, we have various interactions to deal with—interactions that we need Oracle Integration Cloud Service (ICS) to mediate.

For example: Oracle IoT Cloud Service (IoTCS) publishes messages in a format we cannot (easily) control to some REST endpoint that we can specify. Oracle Process Cloud Service (PCS) exposes a SOAP Web Service to start a human workflow, expecting a request message format it dictates itself. In order to have a PCS process instantiated based on a finding from IoT CS, we need ICS to receive the message from IoT CS and turn it into a call of PCS’s SOAP interface. This allows communication from IoT CS to PCS, without these two actually knowing about each other.

ICS plays a similar role in the connection from PCS to SOA CS, for checking whether a proposal for a specific artist already exists and to have an approved proposal registered in the database. ICS has dozens of built-in adapters that facilitate easy integration with many SaaS applications and popular internet platforms and social media, including Facebook, Gmail, Evernote, LinkedIn and Twitter. This last adapter is leveraged in our integrated cloud demo when a Tweet is published based on a request from SOA CS after registering an enriched, approved proposal. The next figure visualizes this role played by ICS in the cloud demo:

Configuring an Integration in ICS

ICS exposes integrations to consumers. In our case, we need integrations for the flows to PCS, to SOA CS and to Twitter. An integration in ICS consists of two connections: the inbound connection that gets exposed to the consumer and the outbound connection that links to the destination. At the heart of an integration is a request mapping—a translation between the inbound message received by ICS to the message routed to the destination—and frequently a response mapping—a similar translation of the message returned to ICS from the destination to the message returned to the original invoker.

In the next figure, we see the integration ProposeNewActForOOW16-SOAP that PCS invokes to submit an approved artist proposal and that routes that proposal to SOA CS. Note that PCS and the developer configuring the process in PCS do not necessarily know anything about SOA CS; they deal only with ICS.

This integration uses two separate connections that were registered earlier:

• ProposeAct_SOAP_Inbound: a SOAP interface created with PCS in mind, to which a request message with a new approved artist proposal can easily be sent at the end of the PCS workflow
• SubmitActProposal_outbound: a connection to the SOAP Web Service exposed from SOA CS that triggers a SOA Composite that will enrich the artist details and record the proposal in the database [as a service instance]

Because the two interfaces linked together in this integration are already fairly similar, the mappings are pretty straightforward. The next figure shows the mapping for the inbound message (the one we expect PCS to send for an approved proposal) to the format expected by the SOA CS service that this integration invokes. The mapping for the response flow is similar.

Each element mapping can be a simple copy of the value from a source element to its target counterpart. Additionally, mappings can use expressions and functions to manipulate and concatenate values during the mapping.

Note that the mapping created in this visual mapper is translated by ICS to an XSLT document. In order to apply advanced transformation logic that cannot be created in this visual mapper, the integration can be exported as a zip file. This archive contains the XSLT documents for each of the mappings; they can be extracted and manipulated in a text editor or an IDE such as JDeveloper. An enhanced XSLT file can be imported into ICS by clicking on the mapping icon in the integration flow designer, resulting in an enriched mapping. From that moment on, this mapping can no longer be edited in ICS.

ICS allows us to monitor the traffic that it handles. Each interaction is logged. By specifying an integration’s business identifiers for tracking, we instruct ICS to track meaningful identifiers that provide insight into the nature of each interaction. The next figure shows how three identifiers are configured to record the values of artistName, numberOfVotes and imageURL from the source message that kicks off the integration. Currently, business identifiers in ICS can be extracted only from the raw source message.

And Ac[tiva]tion

When the definition of the integration is complete, it has to be activated. Activation is similar to deployment; the inbound connection is published and can be accessed by external consumers, such as PCS in our integration flow. To try out the integration, we can also invoke it from other Web Service clients such as SoapUI.

The next screenshot illustrates a test call—with a proposal to have Bruce NewJersey perform—from SoapUI to the ICS integration that routes the proposal to SOA CS.

The call to ICS results in a number of things:

• A response with the assigned identifier (661) from SOA CS
• A message published on Twitter from within SOA CS (also through ICS)
• An invocation trace in the ICS Monitor (see below)

The monitoring tab in ICS can be opened to get insight in all recent ICS activity, successful and otherwise. In the screenshot below, we can see two recent interactions. The top one was started first and completed last, initiated by the call from SoapUI with the proposal for Bruce NewJersey. The second tracked message is the trace of the callout to Twitter from within SOA CS that took place before the response to the submission of the proposal was returned from SOA CS.

When we drill down on the instance for the ProposeNewActForOOW2016-SOAP integration, we see a visual overview of the progress of the interaction as well as the values for all three business identifiers, as shown in the figure below.

The corresponding tweet was published on Twitter through the account configured through the ICS Cloud Adapter for Twitter.

Conclusion

Integration Cloud Service is the ultimate decoupler. In our demo scenario, ICS is the linking pin between the worlds of Things (IoT CS) and Humans (PCS) and orchestration (SOA CS) and SaaS/Social Media (Twitter). Each of these worlds does not necessarily talk to the others very smoothly; and thanks to ICS, they do not really have to. Each world’s inbound interface is represented in ICS by a Connection and each route from one world to another is realized through an Integration. Mappings are configured declaratively in ICS to translate from one world’s language to another’s. The dozens of out-of-the-box cloud   adapters in ICS speed up the creation of otherwise potentially complex integrations. The business identifiers make it easy to track the integration traffic in the monitor and act in case of errors.

ICS is not perfectly suited for complex transformations or integrations that involve asynchronous interactions, enrichments and orchestrations. Currently, even when a connection is configured to not enforce security constraints, calls to ICS inconveniently have to carry authentication headers for a valid ICS account. To overcome some of the connection limitations in the ICS instance we could employ for the demo, we also used a small proxy component, running in a node.js application container. We expect use of this proxy to shortly become redundant.

Continue to Part 5: Orchestration, Enrichment and Persistence with SOA CS and DBaaS

About the Author

Oracle ACE Director Lucas Jellema is solution architect and CTO at AMIS, based in the Netherlands. An Oracle, Java, and SOA specialist, he works as a consultant, architect, and instructor in diverse areas such as Database & SQL, Java/Java EE, SOA/BPM and PaaS and SaaS Cloud Solutions. The running theme through most of his activities is the transfer of knowledge and enthusiasm (and live demos). Lucas is a well-known speaker at Oracle OpenWorld, JavaOne and various Oracle User Group conferences around the world. His articles have appeared in OTN, OTech and the AMIS Technology Weblog, and he is the author of Oracle SOA Suite 11g Handbook (2014, McGraw Hill) and the Oracle SOA Suite 12c Handbook (2015, McGraw Hill).

This article represents the expertise, findings, and opinion of the author.  It has been published by Oracle in this space as part of a larger effort to encourage the exchange of such information within this Community, and to promote evaluation and commentary by peers. This article has not been reviewed by the relevant Oracle product team for compliance with Oracle's standards and practices, and its publication should not be interpreted as an endorsement by Oracle of the statements expressed therein.