An important part of enabling optimal use of SaaS applications is integrating various functions in said applications. Events in one application need to have an effect in others. From simple practical matters such as “send an email when a specific type of file was uploaded into a certain Dropbox or OneDrive folder” or “Update a Google Document when a IRA issue is created” to more profound actions as “When a new lead is added to Oracle Sales Cloud, a new message is posted in a Slack channel” or “When an Eloqua Account is added, create same account Oracle Sales Cloud.”
Oracle Self Service Integration Cloud provides a framework for periodically polling a wide range of business applications out of the box as well as any application you add yourself (as long as the application can be polled through calls to a REST API). Any records retrieved in a polling action can be used to trigger actions in other applications. SSI can perform some logic (filter, loop, conditional execution as well as some calculation and conversion) and create a request message to send to a target application. Many recipes are available out of the box, and more can easily be created for all know business applications as well as for those we add ourselves.
Note that SSI will be the foundation for a new Custom Adapter development kit for Oracle Integration Cloud; apparently this it will support a low code, graphical experience with drag and drop for easy creation of adapters.
In this article a few first impressions with SSI.
Step 1: provision an SSI instance
From the Cloud Dashboard, I have opened the Service Console for SSI. Here I have selected the option to create a new instance.
All that is required is the name (no dashes please in the name!) and optionally an email address to send a ‘ready’ mail to.
Confirm the choices and press Create:
Instance provisioning is under way:
Step 2: Create my First SSI Recipe
SSI knows recipes – defined by us, for our (connections to our) Cloud Applications and to run on our terms. These recipes are typically the custom configured instances of predefined recipes, out of the box available with SSI. Recipes are executed periodically – and this results in a Recipe Job History. We can define additional Cloud App Definitions (new Cloud Applications that SSI can integrate with – such as our own custom applications and SaaS apps that SSI does not currently support, such as for example GitHub, Twitter or SalesForce).
Let’s create a new Recipe, based on two existing Cloud Applications.
Here is a list of a Cloud Applications that SSI currently has predefined Triggers and Actions for:
Each of these applications can be source or destination in a recipe – a recipe that can be defined completely declaratively.
The not-overly useful recipe I will create will be triggered by the reception of an email in my GMail account. Its action will consist of composing and sending an email message to my Outlook account – to notify me about the email. I have to authorize SSI with both SaaS Email Services, add a little bit of logic about which mailbox to observe and what emails to be triggered by and specify how to the outgoing email is to be composed – in part from elements available in the incoming email.
Click on Create a Recipe
Type the name of the recipe. Click on the Trigger to select the triggering cloud application.
After selecting Google Mail as the triggering cloud application, I need to authorize SSI for the specific GMail account that it should use:
The Authorization dialog appears
and the familiar OAuth exchange takes place:
Allow SSI to ‘use’ this account for selected operations:
After allowing, this Cloud Application Account is set up:
and we can continue with the design of the recipe.
Note that in the Label field, we can indicate for which mails in the GMail account we want this recipe triggered:
After defining the Trigger we can define one or more actions that the trigger should set off.
The Action editor is similar to the Trigger editor.
And the first step is to select the Cloud Application that is to be object of the action. In a similar way as before, I select my Office 365 Outlook mail account as the target for my action:
Now I provide the details for the action. What is the destination email address, do I want to sent cc or bcc copies? What are the subject and the body of the email(s) to be sent?
The configured action could look like this:
I save the recipe.
Activate the Recipe
In the overview of recipes, I can drill to recipes to inspect and edit them. And I can activate (and deactivate) the recipes:
With the recipe active, let’s check the incoming email events in my GMail folder. An overview of my GMail Inbox shows the following:
These emails have triggered the SSI recipe. For each one, a job was performed that composed and sent an email.
We can inspect the Job History:
as well as each individual Job execution log:
Here are some of the resulting notification emails sent by SSI to my Outlook mail account, one mail for every email received into the GMail account:
How is this different from IFTTT?
You are probably familiar with the If This Then That service. This service also allows you to define recipes for sending messages in response to a trigger. And Oracle SSI is very similar. There are certainly differences in the range of supported systems. Oracle SSI has far more support for Oracle SaaS services than IFTTT has. IFTTT currently has a wider range of 3rd party applications that it supports. Both can be used to define new services with – such as integration with your own custom applications. There is probably the real differentiator – and how the two compare is not yet fully clear to me. I am assuming that creating recipes to interact with custom applications running on Oracle Cloud will prove very well facilitated by SSI (it is the least it should do) – and that may bring differentiation compared to IFTTT. Perhaps – but I have yet to explore – building and running custom recipes will turn out to be much easier on SSI than on IFTTT. At first glance, management seems easier or at least more enterprise style on SSI.
There are bound to be differences in TCO. However, commercial prices for IFTTT are not available on their website (“Contact Sales”) – so I will not go into detail right now.
Final Though: Apache Kafka & Oracle Event Hub
One design that crosses my mind with SSI: I would like to make use of the “adapters” that SSI offers out of the box for detecting events in many different cloud applications. Knowing about these events and having access to the salient data involved is frequently the foundation of integration solutions. If Apache Kafka (for example in the form of Oracle Event Hub Cloud Service) would be supported as a Cloud Application, we could easily create a range of recipes that intercept events in SaaS applications and publish Kafka event messages for these events – allowing me to make good use of the extensive collection of tools, libraries and frameworks to handle Kafka events.
SSI currently does not offer Kafka integration out of the box – it only can talk in terms of REST. An obvious approach for the recipe described above would be a combination of the SSI recipe that invokes through REST a Serverless Function that publishes the Kafka event.
Resources
Documentation on SSI: https://docs.oracle.com/en/cloud/paas/self-service-integration-cloud/tasks.html
