In this blog, we showcase the abilities of Oracle Integration Cloud – Process to be embedded in SaaS applications. This is useful when you need to straddle workflows across systems or when users you need to conduct an approval are outside your organisation. OIC Process is extremely powerful for application extensions, providing capabilities to deliver embeddable UIs for Forms and Task Lists as HTML5 files that can be inserted in ANY application, Oracle, non-Oracle and even on-prem. We are using Oracle Service Cloud to showcase this. Service Cloud is a Service Request SaaS CRM, typically utilized by Contact Centres. Since only Contact Centre users have access to Service Cloud, what if you need information from another department, such as Field Services/Billing or even another organisation?
In this blog I am going to show you three new capabilities introduced in Oracle Integration Cloud (OIC) that massively simplify the enablement of Application integration with extensions to Business Process Automation workflows and finally how to expose all of that as secured APIs via the Oracle API Gateway.
These three new capabilities are:
- Call your Process Cloud Service (PCS) workflows from an Integration Cloud Service (ICS) orchestration.
- Call your ICS integrations from a PCS business process.
Expose your ICS integrations as APIs into the Oracle API Gateway
Our scenario is simple, it is an incident management extension, that requires some human intervention to manage service requests.
To be specific, let’s assume the following components:
- We need to extend Oracle Service Cloud out-of-the box incident Management functionality with a custom business process automation. For this, Oracle Integration Cloud Service (ICS) will seamlessly listen/subscribe to events in Oracle Service Cloud and when a new Service Requests gets created, it will pass it on into Oracle Process Cloud Service (PCS) to manage the Human interventions.
- PCS starts a new workflow and it redirects the various tasks to the appropriate task owners for approvals/rejections.
- As the PCS workflow runs across the various human interventions, PCS keeps updating the Service Request status into Service Cloud (via ICS) to determine whether it is invalid and needs to be rectified or it is in progress until completion.
- Finally, if we determine that this Incident Management extension workflow could become a reusable asset among other use cases, we can simply go to the ICS integration that triggers the PCS workflow and expose it as an API to be deployed and run into the Oracle API Gateway.
This is a high-level view:
Most organisations have to the deal with several kinds of digital artefacts that need publishing on various channels like Web, Mobile, TV, Social, Kiosks, Print, etc. And it is no brainer that organisations need a “Digital Artifacts” repository that can help them to store these digital assets in a centralised repository. Also, it helps them to distribute very quickly on those channels as mentioned earlier to maintain brand consistency and ensure the rights asset displays on the right channel at the right time. However, most often the digital artefacts are produced in partnership with several teams internally and externally (Primarily design agencies). So the Digital Artifact repository is not only a storage container, but also needs to behave like a collaboration platform to engage with all the stakeholders internal and external to the same platform in real-time. To make it bit more complicated imagine the teams producing the digital assets (aka contributors) need to get all the necessary approvals before the artefacts are published or even consumed by different individuals. Given the nature of the organisations, business approvals can come in various shapes. For example, a Digital Artifact that needs to go out on TV for advertising needs a Product Team, a Branding Team, and Legal Team. The product team is responsible for the design of the digital artefact. The branding team ensures the assets produced are consistent with organisations marketing themes. The legal team task is to ensure the teams have done their due diligence and advise the product teams of the Risk level associated with the activities. So a single digital artefact has got its life-cycle, and there are various touch points before it lands on different social or mobile channels. Your Digital Artifact repository that needs to behave like a collaboration platform should also ensure it provides the capability for digital lifecycle management and manages approvals. Fortunately, the Oracle Content and Experience, and Process Cloud platform addresses the exact above needs in a simple, configurable manner. I don’t need to mention the beauty of having such a platform in the cloud as it allows us to just focus on the problem we have at hand than worrying about installation, what kind O/S server/containers, technology skills, scalability, upgrades, etc. You can read more about Content & Experience and Process Cloud platform that fulfils the requirements for Digital Artifact repository, collaboration, and workflow automation. Now that we have the context let’s focus on one of the problems at hand, how do we make the Digital Artifact go through an approval process using these platforms?
Recently I had to build a Human Workflow that sent SMS and Voice notifications using Oracle Process Cloud Services. The notifications are based on Twilio APIs exposed in Oracle Integration Cloud Service (ICS) and Oracle Application Container Cloud Service (ACCS). After 10 minutes I was done. I was amazed how quickly I managed to create this Business Process using Oracle Platform as a Service (PaaS), so I decided to blog it to show others who are in similar situations.
The diagram below is a quick snapshot of what I will be covering in this blog: