Showing posts with label SSI. Show all posts
Showing posts with label SSI. Show all posts

Thursday, September 27, 2018

#657 SSI - Custom Adapters in a matter of Minutes!

This is the killer feature of SSI -


the ability to create your own REST based adapters in a matter of minutes.


In this simple demo, I will create an adapter for the following Apiary based REST service.






































The URL is as follows -

https://private-nnnn-parkmycarservice.apiary-mock.com/carpark

Note the Developer icon, which appears once you have the relevant role in SSI.



































So I click on - Create a Cloud App Definition.







































Here I enter a Postman like tester.
I copy and paste the request from my Apiary definition



I then click -



























Looks good!

I then click Next















I click Next -













that's the Action created -













Note that the input/output schemas have been automatically created -















That's it!

Now to the Recipe - I will kick this off with a Timer -
























Now to the Invoke of the ParkMyCarService


























Ok, I did hard code the carRegistration !

Now I add a second Action to put the response in an email to myself.


That's it!

Now to testing -


















I check my email -












A very simple example - but this is a huge value add.

Custom adapters to REST based apps in a matter of minutes!














Thursday, July 5, 2018

#637 SSI invoking OIC

Self Service Integration is our compelling new offer, targeting line of business folks.
With SSI, they can easily create their own "personal" integrations; in SSI speak - recipes.

However, they can also leverage existing business processes and integrations, running on OIC.

Here is a simple example -














This integration creates a new organization in Service Cloud, after checking that the organization doesn't already exist.





























So let's call this from SSI - the use case is as follows:

Someone registers for an event in EventBrite - they specify their organization, as part of the
registration process. Now SSI will pick up the Registration Event from EventBrite and then call the above integration.

Firstly, I create a connection to OIC/Integration in SSI -






























































I can now create a recipe leveraging this connection -

The Trigger definition is self-explanatory -

























Now to the Action -

As you can see, it calls my integration -
























Map the fields from EventBrite to the input parameters for the integration, and I'm finished!


Tuesday, April 3, 2018

#624 SSI released, so how does this differ from Integration in OIC?




















My introductory post on SSI covered the basic features.
You can read it here

The Features list above alludes to the main differences between SSI and OIC.
Let's look at some of them -

Personal Account: In SSI you connect to your SaaS app, say Sales Cloud, using your own credentials. This will allow you to see your customers etc.
In OIC, the Sales Cloud connections credentials are usually those of a generic "integration" user.

In other words, SSI for LOB, ad-hoc integrations, OIC for enterprise level integrations.
There may be a grey area between the 2 products from a technical perspective, but I think this emphasis of SSI on your individual cloud application account speaks volumes.

Trigger and Action: SSI is a typical IFTTT style of app - If this, then that e.g. if someone responds to my SurveyMonkey questionnaire, then put their details into my CRM system.

Prebuilt Recipes: SSI places great emphasis on reuse. It comes with a plethora of pre-built recipes (65) or integrations which LOB folks can make your own and leverage immediately.














OIC comes with pre-builts, available via cloud.oracle.com/marketplace. These are canonical integrations between, for example, SaaS apps. The pre-built for synchronizing sales accounts and contacts between Sales Cloud and Service Cloud, is an example of such. Usually these pre-builts will still require some mapping work, for custom fields etc.
 
SSI can, however, leverage OIC.
For example, I am running an event via EventBrite and I would like all attendees to be processed as potential leads in my CRM app. I already have a PCS pricess running on OIC that approves such registrants. This I can call from SSI -

























SSI can also perform actions on the Integration Component of OIC.


SSI comes with its own set of, what one could term, adapters or connectors-

















Some of these are built by Oracle, others you can build yourself.

Here is a list of the Oracle app connectors -
  • Asana
  • DropBox
  • EventBrite
  • GoogleCalendar
  • GoogleContacts
  • GoogleDrive
  • Google Mail (Gmail)
  • GoogleSheets
  • GoogleTasks
  • Jira Cloud
  • LogMeIn GoToMeeting
  • LogMeIn GoToTraining
  • LogMeIn GoToWebinar
  • MailChimp
  • Microsoft Office 365 Excel
  • Microsoft Office 365 Outlook Calendar
  • Microsoft Office 365 Outlook Contacts
  • Microsoft Office 365 Outlook Mail
  • Microsoft Office 365 Outlook Tasks
  • Microsoft OneDrive
  • Microsoft OneNote
  • Microsoft Sharepoint Online
  • Oracle BI Cloud Service
  • Oracle Content & Experience
  • Oracle Eloqua
  • Oracle Integration Cloud
  • Oracle Process Cloud
  • Oracle Responsys
  • Oracle Sales Cloud
  • Oracle Service Cloud
  • SSI Email
  • SSI Timer
  • Slack
  • SurveyMonkey
  • Twilio


Compare and contrast these with the OIC adapters and you will see the emphasis SSI places on LOB productivity tools.


Custom built are, as the name suggests, built by yourself.
But here we are not talking about complex adapter development.
New adapters or connectors, for apps that have REST APIs, are defined via JSON







































Essentially you specify the REST APIS you want to enable -
here is an example from a Weather app -














Pricing -

ocpu based pricing is currently applied to OIC.
SSI will use job execution pricing e.g. our Marketing Dept. friends pay every time they execute an SSI flow to get their EventBrite registrants into their CRM.



 











Want to try out SSI?
Then just click here
















As we say in Ireland - great stuff!









#623 Oracle Self-Service Integration SSI


Introduction to SSI

















So what is Self-Service Integration - SSI?
SSI is light weight integration service, that works on a simple trigger and action paradigm.
It is targeted at line of business folks - simple to use, yet very effective.

These people use a wide range of cloud apps to accomplish their daily tasks. For example, a marketing specialist may use tools such as Survey Monkey to collect customer responses, he or she may also use Eventbrite to organize, yes, you got it, events. So a simple requirement could be to get those customers who responded to the survey into the company's CRM system.

I.T. could provide such an integration solution, but that takes time etc. So what about enabling the LOB folks to do such integrations themselves?

The fact that most productivity/SaaS apps offer REST APIs make it very easy to integrate with them. SSI uses these under the hood.

So let's start off with a simple example -

In this scenario, I want to integrate EventBrite with my marketing app, Eloqua. The use case is that discussed previously.

So let's look at how SSI helps us -















Recipe is the name used for integrations in SSI.

The product comes with a plethora of Public Recipes, i.e. pre-built integrations.

Let's look at some of them -

























Currently we have over 60 such public recipes.

A Simple Example 



But let's create one ourselves, just to show the power of Oracle SSI.

Let's begin with my event -







Now to creating my recipe -












Recipes consist of Triggers and Actions, i.e.

something happening in App A triggers execution.
The execution includes Actions, such as - do something in App B.







I need to authorise SSI usage of my EventBrite account,
if this is the first time I use it.







That's done, now a simple sanity test -


The Trigger, or event occurring,  is someone registering for my event -
I now specify the event - Attendee Registered -





















Now to specify which Event -































Now to the Actions - what should happen when someone
registers for The Hare of The Dog Book Launch.













I have already authorised my Eloqua account - similar experience as with EventBrite.


















Now to what should happen on the Eloqua side -











The following actions are available -















I select Create Contact -

Now to the input fields for Eloqua -




















Let's see which fields are available to us -



So I map accordingly -























I activate the Recipe -

















I now reserve tickets in EventBrite

























I can run the job now, otherwise SSI polls EventBrite every 15 minutes-












I check the result -


















I check in Eloqua -










There's Jimmy!


So what else is there to SSI?

Controls


Actions in SSI also include Controls -












As you can see, we have For Each Loops and IF condition support.

We can, of course, have more than 1 action in a recipe e.g.
If someone registers for an event via EventBrite then put their details into 
Eloqua and Sales Cloud.

Job Execution

Once an SSI recipe is activated, it polls for work every 15 minutes.
So, in respect of the example I created, SSI would poll EventBrite every 15 minutes for 
new attendees. I can also do ad hoc execution from the menu - Run Now

















Monitoring


Monitoring is via Job History - 














As you can see, I can select by recipe, completion status and time range.

Here I have 2 jobs - one successful the other failed -
















Let's look at the failed job -
























The Eloqua error message - email address is not unique - surfaces in SSI.

Perfectly understandable.