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 

Monday Jan 13, 2014

More complete RESTful Services for Oracle Sales Cloud Sample/Demo Application

This sample code builds on the previous code examples in my blog showing how you can create a RESTful Facade for Oracle Sales Cloud. Specifically this example concentrates on the six main objects people tend to work with :

  • Opportunities
  • Leads
  • Locations
  • SalesParty
  • Person
  • Interactions

This application is an extension of a previous blog article https://blogs.oracle.com/angelo/entry/rest_enabling_oracle_fusion_sales, it is recommended that this article, and tutorial, are followed first. 

Please note this code is SAMPLEWARE and delivered with no guarantees, warranties or  support

Functionality / Features

  • Supports Oracle Sales Cloud Release 7 and JDeveloper
  • Ability to query data in a RESTFul way (using GET/PUT verbs)
  • Data can be queried using JSON or XML data formats
  • URIs can contain parameters which reduce the amount of data which is returned , e.g. only bring back Opportunity IDs and Names
  • URI can contain SIMPLE queries, e.g. where OptyID=12323232
  • Complex queries can be passed in as a POST query when the URI ends in /xmlquery
  • User Credentials, CRM Server, FetchSize and FetchStart can be provided in httpHeaders, thus can be encrypted by SSL
  • Default Server can be setup so that credentials are not needed
  • Project can be extended to cover other objects


  • Read only is implemented, if you want to issue writes (PUTS) or updates then I recommend custom methods for each operation you require.
  • In the future Oracle Sales Cloud will likely have support REST support natively; This software will work fine against future versions of Oracle Sales Cloud but you are probably better off using the native Oracle Sales Cloud REST support when it 


Tuesday Jan 03, 2012

Happy New Year All , and are you all integrated and validated?

Firstly Happy New Year to you all

Secondly, in late December a friend of mine, who works for an Oracle Partner, asked me questions on how to "correctly" integrate  Oracle eBusiness Suite with a 3rd party application, the answer is "it depends".. There are many ways to do integration and depending on what you need to accomplish depends which one is the "best" approach..

It depends on :

- What version of EBS you are using, if its 12.1.3 then you can use the ISG (integrated Service Gateway)  to call services within EBS as Web services.
-  If your on a EBS prior to 12.1.3 (also 11i I guess) then you have something called the Applications SOA Adapter within SOA Suite. This adapter basically acts as a facade between SOA Suite and the Oracle eBusiness Suite PLSQL APIs, quite easy to use and works well.. This adapter is also available in 12.1.3, but its generally recommended to use the previously mentioned ISG Gateway instead.

However beware that the devil is in the detail, it does depend who the 3rd party is and what they are trying to do, you might for example need to use the Oracle Service bus for some complex credential mapping, or maybe the Oracle B2B product is a better fit.. Also consider if its a batch process then perhaps one of the data integration products is a better fit (e.g. ODI)
Finally, what about validating the solution? Does oracle provide validation services? 

Yes we do!


If its custom code, or a one off for a client, then the best people do validate the solution is probably Oracle Consulting Services, if you are a partner who are creating a reusable asset then the partner program has a validation program called "Oracle Validated Integration" which provides a number of benefits  


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.


« November 2015