Now we’re ready to create connections and integration from OIC. If you missed part 1, please go for Part 1 now. Also my colleague Carlos already wrote excellent blog, Teaching how to integrate Salesforce and Sale Cloud with Oracle Integration Cloud Service so you can look at how to configure outbound message from Salesforce.com and Salesforce Connection with Trigger from OIC.
Luckily, I’ve got a chance to look at PeopleSoft integration with other SaaS app using OIC (Oracle Integration Cloud) and decided to share what I learned.
We have covered multiple blogs on how to use Terraform to help automate the provisioning of environments and treat your Infrastructure as Code. Until now, for PaaS stacks, we have used Terraform together with Oracle PaaS Service Manager (PSM) CLI. This gives us great flexibility to script our own tailored PaaS stacks the way we want them. However, with flexibility comes responsibility, and in this case, if we choose to use PSM CLI, it’s up to us to script the whole provisioning/decommission of components that make up the stack. As well as what to do if we encounter an error half-way through, so that we leave things consistently.
A simpler way to provision PaaS stacks is by making use of Oracle Cloud Stack, that treats all components of the stack as a single unit, where all sub-components are provisioned/decommissioned transparently for us. For example, Oracle Integration Cloud (OIC) stack, is made of Oracle DB Cloud Service (DBCS), Integration Cloud Service (ICS), Process Cloud Service (PCS), Visual Builder Cloud Service (VBCS), IaaS, storage, network, etc. If we use Oracle Cloud Stack to provision an environment, we only have to pass a YAML template with the configuration of the whole stack and then, Cloud Stack handles the rest. Pretty awesome huh?
Similarly, as we have done in the past, we are going to use a “Build Server”. This will be used as a platform to help us provision our PaaS stacks. When provisioning this “Build Server”, I will add all the tooling it requires as part of its bootstrap process. For this, I am using Vagrant + Terraform, so that I can also treat my “Build Server” as “infrastructure as code” and I can easily get rid of it, after I built my target PaaS stack.
This is a graphical view of what I will be doing in this blog to provision an OIC stack via Cloud Stack:
In a previous blog, I explained how to treat your Infrastructure as Code by using technologies such as Vagrant and Terraform in order to help automate provisioning and decommissioning of environments in the cloud. Then, I evolved those concepts with this other blog, where I explained how to use Oracle PaaS Service Manager (PSM) CLI in order to provision Oracle PaaS Services into the Cloud.
In this blog, I am going to put together both concepts and show how simply you can automate the provisioning of Oracle Integration Cloud with Terraform and PSM CLI together.
To provision a new PaaS environment, I first create a “Build Server” in the cloud or as my boss calls it a “cockpit” that brings all the required bells and whistles (e.g. Terraform, PSM CLI, GIT, etc) to provision PaaS environments. I will add all the tooling it requires as part of its bootstrap process. To create the “Build Server” in the first place, I am using Vagrant + Terraform as well, just because I need a common place to start and these tools highly simplify my life. Also, this way, I can also treat my “Build Server” as “infrastructure as code” and I can easily get rid of it after I built my target PaaS environments and save with that some bucks in the cloud consumption model.
Once I build my “Build Server”, I will then simply git clone a repository that contains my scripts to provision other PaaS environments, setup my environment variables and type “terraform apply”. Yes, as simple as that!
This is a graphical view of what I will be doing:
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:
Building Enterprise integrations in the Cloud with iPaaS brings many benefits, including among others: simplicity, agility and scalability. However, these benefits should not be taxed by having a weak core, not able to properly manage common enterprise requirements, such as error management. I’ve been a bit disappointed with how most iPaaS vendors handle runtime exceptions of integration flows. A typical example of this, is not being able to support dehydration for asynchronous flows (i.e. dehydration is crucial to supporting long-running instances by saving their memory state into a database, until a correlation invocation, a.k.a call-back, wakes it up to continue with the flow). This causes that when an error occurs, recovery has to start from the beginning of the integration flow that failed.
In these situations, we would have to either design an integration to be fully idempotent and stateless across all its partner links (service invocations), which is not always possible. Another way to do it is by manually handling the recovery of errored scenarios, this is to avoid state inconsistency across the previous service invocations in the orchestration, prior to the error… But then if we have to manually handle compensation, what about iPaaS being easier?
Luckily, Oracle Integration Cloud maintains simplicity at the front end and a mature and strong integration core at the backend. It acknowledges when an orchestration is asynchronous, so that dehydration points (a.k.a. break points) are enforced along the way across service invocations or long-term actions (e.g. waits), enabling with this long-term running instances avoiding to timeout, but to stay in memory (and DB back store) until all activities and external call-backs in the orchestration flow complete.
In this blog, I am going to show you how to recover errored instanced with Oracle Integration Cloud. For this, I am going to build a flow that demonstrates how errored instances recovery occurs from the latest dehydration point, allowing you to simplify complex orchestrations without having to compensate manually.
In this blog, I want to share my experience after having created many APIs using different approaches and technologies. I am going to encapsulate a simple process that will help you construct APIs, starting from scratch with an idea or requirement and move it all along to a happy consumption.
The best part of APIs is that they are microservices enablers, which implies that they are not technology prescriptive, so in this blog you will see that your APIs can be implemented using any technology or programming language.
I decided to use “Jokes” as the vehicle to explain the APIs construction best practices, mainly because jokes are a simple concept that anyone can relate to, but also because I want you to feel compelled to consume these APIs and by doing so, get a laugh or two.
My original idea with jokes is to:
- Get a random joke.
- Translate the joke to any language.
- Share the original or the translated joke with a friend via SMS.
This is the high-level view of how our end solution will look like: