OIC: Oracle Integration Cloud, what is it?

After some feedback I have decided to write a post that gives a small summary of what OIC is and how one can position it within the ecosystem of an enterprise. I will first give an overview of the three main features of OIC, then some of my own perspective on strengths and weaknesses of the products and closing with positioning OIC in an enterprise ecosystem.

Overview trifecta (PCS, ICS, VBCS)

Process Cloud Service (PCS)

The Oracle Process Cloud Service is where one can create structured and dynamic processes. This is all written in BPMN so it should be understandable for the business. All processes have an input and output, where activities can be both automatic or human (tasks) as PCS comes with out of the box task management. It also has the strength of being able to develop both structured and dynamic processes. Where structured processes are deterministic down a pre-defined path, dynamic processes have “prerequisites” for each activity. Each time data changes inside the dynamic process all the prerequisites are re-evaluated (it does know phases to keep this check small). When having BOTH PCS and Integration Cloud Service (ICS) one can use all the integrations very easily from the processes, these are updateable as well by just a few clicks. Working together with ICS it is also possible to have correlation “wait” steps, that wake up when the correct correlation ID is given to that endpoint. PCS impresses here as well as these processes are not necessarily in memory (smart hydration / dehydration method). When modelling processes it is important that these are modelled in such a way that they have one goal and are easily expandable and interchangeable (separation of concerns!!). We can achieve this because it’s very easy to call subsequent processes from within a process or call back to an overlaying orchestration process.

Example: Orchestration dynamic process A is to enable a customer to make a reservation for a restaurant. The input is the contact info, date/time and number of guests. Structured process B is in charge of checking if the reservation is correct: it checks if the date/time is correct and if the amount of people is not exceeding the limits. In case any of these are wrong, a human task is triggered with a UI screen on it that shows both the contact information and editable date/time and editable number of guests. The screen also has a cancel button. If a human task is triggered, the structured process B automatically waits until the task is finished. Process B terminates afterwards, and a call back is sent to the Orchestration process A with one result: the reservation is cancelled or not. Orchestration process A has another activity Structured Process C that has a prerequisite: activity Structured Process B is finished AND reservation is not cancelled. This Structured Process C is in charge of writing the reservation to the database and emailing the guest that the reservation is complete successfully.

Integration Cloud Service (ICS)

The Integration Cloud Service is where one can create integrations with other systems, integrations with CRUD operations to read or write to the database and integrations to send notifications. It also has several adapters that do a lot of work for the user. ICS uses connections (trigger and invokes) and integrations. Each integration must have a trigger (input) and can use any amount of invokes inside the integration (calls to other services). ICS works best with app-driven integrations, which are a sort of mini structured processes. I would highly recommend trying to keep business logic OUT of integrations as much as possible (we have PCS for that right? We only want one place for business logic).

Visual Builder Cloud Service (VBCS)

The Visual Builder Cloud Service has to components, Business Objects and Apps. Business Objects are a sort of out of the box database with added functionality like DB triggers, validation rules and automatically generated REST connectors. It also has some great ways of being able to model relationships between entities in a really simple way. When modelling these relationships one can even define accessors between entities. The other part of VBCS are the Apps. Apps are applications that are designed in a Rapid Application Development way (80% drag and drop, 20% custom). What VBCS does very well is that it enables users to easily drag and drop components and binding that to action chains. These action chains are very powerful in what they can do, for example calling integrations or even starting a PCS deployed process! The VBCS pages also support custom JavaScript calls. The apps also work really well with the Business Objects of course where pages can be auto generated based on the Business Object schema.

Strengths and weaknesses

PCS

Strengths in my opinion:

  • Dynamic processes are not always possible in other BPM tools
  • Dynamic processes have phases
  • Dynamic processes have optional and / or repeatable activities
  • Processes have security per role or group (as swimlanes!)
  • Possibility to both use JSON and XSDs to read business types
  • Possibility to easily consume integrations that are modelled on ICS
  • Possibility to easily call other processes easily
  • Strong data mapper with transform possibilities for each input/output activity
  • All processes have auto generated endpoints when activating
  • Task management is strong out of the box
  • A lot of API’s can be used for PCS
  • Strong “tracking” functionality of the state of the process or where something went wrong
  • Strong correlation of wait steps

Weaknesses in my opinion:

  • Human tasks can use API’s and can also have an external UI URL (as to have custom task screens), this does not work very well yet (for example cannot send a payload when finishing a task)
  • Integration with Visual Builder Cloud Service (VBCS) could be stronger, for example possibility to include VBCS pages inside tasks or make specific “task pages” inside VBCS that have some features out of the box, like claiming, approving, reassigning tasks
  • Fiddly with data types (converting integers, doubles, strings is very error prone when using PCS and ICS together, especially when having optional fields)
  • API’s could be better documented (with more examples)

ICS

Strengths in my opinion:

  • Connections and integrations are separated so that connections can easily be changed (base URL for example)
  • Works very well with PCS
  • Able to have multiple operations inside one integration
  • Able to do XSLT mappings including XPATH2.0
  • Able to choose pre-defined system users from drop downs

Weaknesses in my opinion:

  • Optional fields do not work well in ICS, need a very cumbersome IF check
  • Obscure error messages (“something went wrong”)
  • Activity stream is not very clear, often I just want to see: “I sent this payload to that url”, this information is hidden
  • Connections do not have a very easy “where used” functionality
  • Difficult to see which connections are used when editing an integration
  • Auto mapping button (Recommend) is very bad, when I have two identical structures left and right, it maps 0 elements when not in the same namespace (also JSON!)
  • Mapping UI is very different from PCS’s mapping UI
  • Complex mapping (for-each for example) very difficult

VBCS

Strengths in my opinion:

  • Business Object modelling is very easy (also UI for relationships and even auto drawn diagrams)
  • Business Objects have auto generated REST connectors INCLUDING accessors
  • Business Objects that are related can be called through either accessors or expand=all query parameters
  • Business Objects that are related can be deep inserted through an integration
  • Business Objects can use GroovyScript when doing database triggers and business rules
  • Business Objects can have pre-determined data in dev, stage and live
  • Apps are easily made and fast to prototype
  • Action chains have a lot of features
  • Apps can call custom JavaScript code
  • Custom reusable JET components possible
  • Mostly REST / JSON based

Weaknesses in my opinion:

  • Business Objects do not support views or joining of tables
  • No easy use of JavaScript libraries over applications (see other blog post)
  • Apps can get complex easily, as the flows are not very intuitive (the necessity for subflows is because of missing features in navigation)
  • Mapping inside action chains is a different UI from ICS and PCS
  • Many features not well documented (yet)
  • No bring your own database (yet)

Please note that with a lot of these weaknesses Oracle is very helpful in trying to fix them and placing them on the roadmap.

Using OIC inside an enterprise ecosystem

I do see OIC as a mid-to-large enterprise solution, often in an enterprise that has a lot of other flanking apps and possibly an ERP system. I think OIC should be the process orchestrator for business processes, being started by either a user or a service call through ICS (either from internally or externally). This orchestration process then uses either human tasks (connecting to the user) or automated activities often using ICS connecting flanking apps or the outside world. In my opinion this should always go through a API Management tool. When connecting an ERP system, we found that using an API management platform is not very practical. We would rather create webservices on the ERP system and expose those, subsequentially consuming these services in ICS. We like to do these ERP calls synchronously, while other integrations could be done asynchronously (the process supports this by correlation ID’s on waiting steps). When we use such an orchestration process, we should be careful to not put too much data inside that running process context. A much better solution is saving that data in a database (VBCS Business Objects) while the process knows the “keys” to those business objects. As for human interaction, all should be done through VBCS, either interacting with tasks or with the business objects.

Two notes I would like to make. The first is that VBCS could be interchanged with any UI framework, as the API’s used to call PCS and ICS are generally available. Integrations and processes are much more easily called from VBCS action chains though (no need to call/code APIs yourself). The second is that the VBCS BO’s could easily be interchanged with ANY database (preferably with a REST adapter on top), which probably gives more flexibility and options (views and joining of tables, creating reports).

My recommendation would be to definitely use a custom database instead of VBCS Business Objects from the start. Extra intel: a little birdy told me that Bring Your Own Database could be a real possibility in the future (Business Objects would be on top of your own database).

Join the Conversation

1 Comment

Leave a comment

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: