Process Cloud Service (PCS) Integration Options

Process is ubiquitous - be it SaaS process extensions, automation of a manual process, gain visibility into a process or just eliminating human errors.

With fully visual, browser based, no IDE platform that runs on the cloud, Process Cloud Service lends itself as a simple yet powerful tool to citizen developers and LOB users alike, to raidly automate their business processes with little to no dependency on IT/DevOps. Cloud platform (PaaS) offerings such as Process Cloud Service and Integration Cloud Service enable modern enterprises leveraging a range of SaaS applications to extend, automate and integrate back with on-prem systems.

Outside of its own instance data, business processes also need data from external data sources. Process Cloud Service offers 3 options to seamlessly integrate with external systems / services;

1) SOAP
2) REST
3) ICS (Integration Cloud Service)

To invoke or call external services using a Service Activity within a business process, we must first create a connector - available under the Integrations section in your process composer.

Out of the box, Process Cloud Service allows connectivity to external services through SOAP / REST protocols. For any other type of integration - for eg., Database, File, Oracle/3rd party apps, you have 2 options;

1) Expose them as SOAP/REST APIs either through a middle tier or using natively available options (eg., APEX ORDS for Database) and call them directly from PCS
2) Use Integration Cloud Service (ICS) to quickly interface your target data source as SOAP/REST using a range of technology, application and SaaS adapters

1) SOAP

With this integration option, you can connect to any SOAP web service that is accessible over internet. You have options to either upload a WSDL definition or use a SOAP URL directly.
If you are using URL, notice that all the referenced schema (XSD) files are also imported automatically.

You also have an option to configure the "Read Timeout", "Connection Timeout" and WS-Security parameters for the service.

2) REST

Process Cloud Service offers extensive support to integrate and connect to REST APIs. Intuitive wizard guides through configuration of REST based services including various HTTP verbs, resources and request-response payloads.

3) ICS Integration

Process Cloud Service (PCS) provides tight-integration to Integration Cloud Service (ICS) among other PaaS / IaaS services such as Documents Cloud Service, Business Intelligence Cloud Service, Storage Cloud and Notification Service.

All it requires is a one-time configuration in PCS workspace and while modeling a process, the service connector display all ICS integrations to choose from.

With all these different integration options, Process Cloud Service not only delivers rapid process automation but also offers extensive connectivity to external systems and services.

Smart Connect Modern Enterprise Apps & SaaS w/ Oracle iPaaS

Modern enterprise systems stretch from ground to the cloud and everything in between.
With plethora of diverse SaaS applications combined with existing home grown/legacy on-premise applications - each promising to solve a specific business problem, the integration problem has just got complicated.

IDC predicts that by 2018, SaaS-based enterprise applications would generate over $50 billion in revenue resulting in more than 27% of enterprise apps running on cloud.

Enterprises must equip themselves to embrace this change to integrate, secure and manage their "extended" enterprise on cloud.

Most traditional integration solutions have 2 shortcomings;
One, they require considerable DevOps efforts - think development, deployment, maintenance etc..
Two, they aren't built ground-up for SaaS integrations - lack of SaaS adapters, network latencies, firewall pinholes for SaaS connectivity etc..

Hence the need for an iPaaS - Integration Platform as a Service. For any iPaaS solution to be successful, there are 3 important considerations that enterprise architects must account for;

1. Ease of Use
2. Time to Market &
3. Deployment Choice

1. Ease of Use:

A cloud solution's first deliverable to business must be "Simplifying IT" and bringing IT closer to business. Oracle Integration Cloud Platform (ICS) is built for "citizen developers" and hence truly offers a "zero code" integration platform. This is a huge advantage for business and IT alike, as all technology complexities are hidden away. This means; there is no new technology to learn / ramp-up, no skill-gaps to fill, quicker turn-around times...

Oracle ICS also features a pattern-driven integration model with a bunch of common integration patterns to choose from, for a variety of integration needs including pub-sub, straight-on data mapping, orchestration etc.. all delivered just over a browser. No IDE, No installation & Zero Code.

2. Time to Market:

A huge impediment to any project plan is "TTM" delays that concerns the business.

Even for some of my customers who are on the bleeding edge of technology find it pragmatically difficult to staff, develop, administrate & manage their integration projects - partly owing to changing trends in technology but mostly because their DevOps can't scale to handle business demands. For instance, in the last 6-9 months, their sales department has bought into salesforce.com, HR moved to Fusion HCM cloud and Marketing is automating campaings on Eloqua. All of these are strategic initiatives driven by the line of business which offers feature-rich enterprise applications with lesser dependency on IT Ops at least to manage & maintain them.

However, care must be taken not to build silo'ed SaaS applications - there must be a robust integration platform to connect SaaS with On-prem systems without the complexities of a traditional middleware. Oracle ICS was architected ground-up with "Time to Market" as its principle goal. Integrations that typically take a few months can be up & running in a few days.

This is made possible with the ever-growing list of feature-rich SaaS, Apps and Technology adapters built for cloud, pre-built integrations and smart recommendations.

3. Deployment Choice:

Another integration decision is the "Integration Center of Gravity" which defines where the integration can be run for best performance. Let's say we want to connect 2 SaaS applications - does it make sense to run the integration on-prem behind your enterprise firewall? probably not. On the contrary, if you want to integrate 2 on-prem systems but still like to leverage the advantages that Oracle ICS offers, you have the flexibility to run ICS on-prem within your datacenter.

Oracle ICS is a truly hybrid iPaaS providing full deployment choice whether you want to run your integration platform on cloud or on ground.

Integrate OSB with Oracle MFT

Recently, I had an opportunity to work with a customer on MFT integration with OSB.

Some pain points were;
1) Ever-increasing FTP servers across their enterprise which was increasingly becoming tough to manage and maintain.
2) Custom code for compression/decompression logic before/after file transfers
3) Bunch of third-party utilities for scheduling file transfers
4) Java code exposed as API for PGP encryption/decryption

Obviously they had a lot of integration touch-points while putting together a file transfer solution - which also meant multiple points of failure and not to mention the maintenance/debugging nightmare if something were to go wrong.

One of the cool features of Oracle MFT is that it supports out-of-the-box integration with many technologies including OSB. For many OSB users, the following could be some of the use-cases where they could take advantage of MFT and reap benefits;

Traditional OSB implementations used File/FTP adapters for file transfers - No real visibility into the transfers and not the best of designs to manage/maintain.

With Oracle MFT exposed as a webservice it is now just a seamless webservice invocation - with the added benefits such as real-time visibility, OOTB scheduling, Compression, PGP encryption, ease of maintenance to name a few..

Use-Case 1: OSB triggers a MFT transfer

In this use-case OSB would trigger a MFT transfer. MFT would then fan-out the transfer;
a) Decompress, Decrypt and store in file system
b) Initiate a SOA process to do further processing (human task etc..)

Creating a MFT Source:

Step 1: Login to Oracle MFT console (http://hostname:port/mftconsole)

Step 2: Go to the Design tab. Click on the Sources and create a new OSB source as shown below;

Creating a MFT Target:

Step 3: Now, click on the Targets and create a new MFT target (This can be a webservice, SOA service, FTP, sFTP, File etc..).
In this case, we would be creating 2 targets - one SOA target and a File target as shown below;

Note: For the SOA target - I just created a simple SOA composite with MFT adapter...

Now. let's create a Transfer - nothing more than linking the source & target on a canvas.

Step 4: Click on the Transfers and create a new MFT. In the MFT canvas, drag and drop the OSBSrc to the source panel. Similarly, drag and drop the OrderSOATarget & PutFile targets to the target panel. Note that "decompress" and "decrypt" pre-processing actions are added to the targets. These are out-of-the-box capabilities that you can leverage with Oracle MFT.

That's all. Now just define a business service in OSB as usual that will trigger the transfer in Oracle MFT. You can obtain the MFT (OSBSrc) source webservice URL by just opening the source.

Use-Case 2: Oracle MFT invokes OSB proxy service

Here we will pick a file from the embedded FTP server (FTP & sFTP servers are embedded and comes out-of-the-box with Oracle MFT), and invoke a OSB target.

Step 1: Click on Sources and create a new source of type "FTP Embedded" as shown below;

Step 2: Click on Targets and create a new target of type "OSB" as shown below

Step 3: Click on the Transfers and create a new MFT. In the MFT canvas, drag and drop the FileSrc to the source panel. Similarly, drag and drop the OSBTgt to the target panel

Done. Now, let's see how to create a OSB proxy service that will consume the MFT transfer.

Step 4: Login to OSB console. Create a proxy service based on the WSDL available @ $FMW_Home/mft/integration/wsdl/MFTSOAService.wsdl (While source/target type is chosen as OSB or SOA, MFT exposes the web service based on this WSDL contract)

Note: Ensure that the proxy service URL and the MFT OSBTgt URL matches.

As easy as that.