#853 SOA Suite to OIC --> how easy is it?

 

This is the first in a series of posts addressing current SOA Suite customers interested in leveraging Oracle Integration Cloud.

We currently have many SOA Suite customers adopting OIC. This adoption can take different forms -

1. "Migrating" existing SOA composites to OIC -

Here we are essentially talking about re-implementing the existing SOA Suite composites in OIC. I have many customers doing this and doing it very well. One of them had ca. 200 integrations to implement in OIC. This work was done by a team of 2 developers over a period of 6 months - that is from initial development to production. 

2. Lift and Shift SOA Suite on-premise to SOA on OCI - Net new integrations implemented on OIC -

Think of the following scenario - customer is doing a lift and shift of E-Business Suite on-premise to Oracle Cloud Infrastructure (OCI). SOA Suite is heavily used so it makes sense to lift and shift this component as well. Customer then adopts a cloud based CRM and now has net new integration requirements in respect of, for example, opportunity to order between CRM and EBS.

3. Co-existence - Net new OIC integrations invoking SOA Suite processes via the OIC SOA Suite adapter and SOA Suite composites invoking OIC integrations.

This post, is, hopefully, the first of many on this theme. I begin with the simple BPEL process shown above and go deeper as we go along. The process is very simple - allowing me to insert an Order in the Database, via a SOAP interface.

 

The processing is essentially just an assign of the input values to the DB invoke parameters -

Before implementing this Synchronous Request/Response flow in OIC - let's look at some of the artefacts we can reuse -

For example, the service wsdl - ProcessOrder.wsdl - and it's xsds.

I zip up the wsdl and the xsds it references - note the reference to the xsd in the wsdl - it expects to find the xsd in the /Schemas folder. Now one could recreate this folder structure or else just amend the reference -

to

I then copy the referenced xsds into the same folder as the wsdl and then zip -

I now go to OIC and create the 2 connections I require, SOAP and Oracle Database.

 

I now need to upload my zipped wsdl - 

Test and Save - 

I now create the DB connection - 

I specify an agent group - this refers to the lightweight OIC connectivity agent I have already installed on the same network as the database. The agent contains the DB adapter and will use that to process  interactions with the DB, both design-time and runtime. For design time, consider the initial call to the DB to retrieve all the schema tables etc.

Now to creating the integration itself - OIC offers different integration styles/patterns - I choose app driven or this use case.

 

I add the SOAP Trigger - akin to BPEL Receive -

and configure as follows - 

My model now looks like this - 

I add the DB connection as follows - 

Drag, drop and configure -

Model now looks like this - 

I do the mapping - akin to BPEL Assign -

The Mapper works on different levels - 

1. simple drag and drop

2. developer mode - access to a host of functions/xslt constructs

3. full edit access to the underlying xslt generated

I use option 1 for this simple example - 

I now map the return value -

I still have 1 issue to be sorted, before I can deploy and test. Here I need to specify a tracking variable. This tracking variable can be used in the Monitoring UI to find the flows for specific orders.

I activate (deploy) the integration  -

I can then access the url - 

This I will use in SOAP UI -

The Response from OIC -

I check out the DB table - 

Here is the Monitoring UI - 

So how easy is it? 

Very easy!

Granted this was a simple example, but there are BPEL processes out there of this ilk.

Future posts on this subject will look at more complex flows.