Tuesday Jun 10, 2014

Common usecases and techniques when integrating a 3rd party application with Oracle Sales Cloud

Over the last year or so I've see a lot of partners migrating and integrate their applications with Oracle Sales Cloud. Interestingly I'd say 60% of the partners use the same set of design patterns over and over again. Most of the time I see that they want to embed their application into Oracle Sales Cloud, within a tab usually, perhaps click on a link to their application (passing some piece of data + credentials) and then within their application update sales cloud again using webservices.

Here are some examples of the different use-cases I've seen , and how partners are embedding their applications into Sales Cloud,
NB : The following examples use the "Desktop" User Interface rather than the Newer "Simplified User Interface", I'll update the sample application soon but the integration patterns are precisely the same

Use Case 1 :  Navigator "Link out" to third party application

This is an example of where the developer has added a link to the global navigator and this links out to the 3rd Party Application. Typically one doesn't pass any contextual data with the exception of perhaps user credentials, or better still JWT Token.

Techniques Used  

Use Case 2 : Application Embedded within the Sales Cloud Dashboard

Within the Oracle Sales Cloud application there is a tab called "Sales", within this tab its possible to embed a SubTab and embed a iFrame pointing to your application. To do this the developer simply needs to edit the page in customization mode, add the tab and then add the iFrame, simples! The developer can pass credentials/JWT Token and some other pieces of data but not object data (ie the current OpportunityID etc)

 Techniques Used

 Use Case 3 : Embedding a Tab and Context Linking out from a Sales Cloud object to the 3rd party application

In this usecase the developer embeds two components into Oracle Sales Cloud. The first is a SubTab showing summary data to the user (a quote in our case) and then secondly a hyperlink, (although it could be a button) which when clicked navigates the user to the 3rd party application. In this case the developer almost always passes context specific data (i.e. the opportunityId) and a security token (username password combo or JWT Token). The third party application usually takes the data, perhaps queries more data using the Sales Cloud SOAP/WebService interface and then displays the resulting mashup to the user for further processing. When the user has finished their work in the 3rd party application they normally navigate back to Oracle Sales Cloud using what's called a "DeepLink", ie taking them back to the object [opportunity in our case] they came from.

This image visually shows a "Happy Path" a user may follow, and combines linking out to an application , webservice calls and deep linking back to Sales Cloud.

Techniques Used

Use-Case 4 :  Server Side processing/synchronization

This usecase focuses on the Server Side processing of data, in this case synchronizing data. Here the 3rd party application is running on a "timer", e.g. cron or similar, and when triggered it queries data from Oracle Sales Cloud, then it queries data from the 3rd party application, determines the deltas and then inserts the data where required. Specifically here we are calling Oracle Sales Cloud using SOAP/WebServices and the 3rd party application is being communicated to using the REST API, for Oracle Sales Cloud one would use standard JAX-WS WebService calls and for REST one would use the JAX-RS api and perhap the Jackson api for managing JSON objects.. This is a very common use case and one which specifically lends itself to using the Oracle Java Cloud Service as the ideal application server where to host the mediator between the two applications.

 Techniques Used

General Resources

The above is just a small set of techniques and use-cases which are used today. There are plenty of other sources of documentation and resources available on the internet but to get you started here are a few of my favourite places 

JWT Token Security with Fusion Sales Cloud

When integrating SalesCloud with a 3rd party application you often need to pass the users identity to the 3rd party application so that 

  • The 3rd party application knows who the user is
  • The 3rd party application needs to be able to do WebService callbacks to Sales Cloud as that user. 

Until recently without using SAML, this wasn't easily possible and one workaround was to pass the username, potentially even the password, from Sales Cloud to the 3rd party application using URL parameters..

With Oracle Fusion R8 we now have a proper solution and that is called "JWT Token support". This is based on the industry JSON Web Token standard , for more information see here

JWT Works by allowing the user the ability to generate a token (lasts a short period of time) for a specific application. This token is then passed to the 3rd party application as a GET parameter.  The 3rd party application can then call into SalesCloud and use this token for all webservice calls, the calls will be executed as the user who generated the token in the first place, or they can call a special HR WebService (UserService-findSelfUserDetails() ) with the token and Fusion will respond with the users details.

Some more details 

The following will go through the scenario that you want to embed a 3rd party application within a WebContent frame (iFrame) within the opportunity screen. 

1. Define your application using the topology manager in setup and maintenance

2. From within your groovy script which defines the iFrame you wish to embed, write some code which looks like this :

def thirdpartyapplicationurl = oracle.topologyManager.client.deployedInfo.DeployedInfoProvider.getEndPoint("My3rdPartyApplication" )
def crmkey= (new oracle.apps.fnd.applcore.common.SecuredTokenBean().getTrustToken())
def url = thirdpartyapplicationurl +"param1="+OptyId+"&jwt ="+crmkey
return (url) 

This snippet generates a URL which contains

  • The Hostname/endpoint of the 3rd party application
  • Two Parameters
    • The opportunityId stored in parameter "param1"
    • The JWT Token store in  parameter "jwt"

3. From your 3rd Party Application you now have two options

  • Execute a webservice call by first setting the header parameter "Authorization" to the value "Bearer <JWT token>" then calling your webservice of choice. The webservice call will be executed against Fusion Applications "As" the user who execute the process
  • To find out "Who you are" , set the header parameter "Authorization" value to "Bearer <JWT Token>" and then execute the  webservice call findSelfUserDetails(), in the UserDetailsService

For more information 


Architect & Technology Evangelist - If its middleware,PaaS/SaaS integration then I'm interested

The views expressed on this blog are my own and do not necessarily reflect the views of Oracle.


« June 2014 »