Friday Jun 13, 2014

Using SalesCloud RESTFacade with Custom Fields & CORS support

Some of you may be using my RESTFacade which I wrote and Oracle recently released as sample code on OTN (link).

There has been a couple of requests, or more "how to"s which I thought Id post here.

  1. How to add CORS support (Cross Origin Resource Sharing) support
  2. How to use the facade with custom fields defined in AppComposer

How to add CORS support (Cross Origin Resource Sharing) support

 Adding CORs support is quite straightforward, simply open the web.xml file in the FusionRESTService project and add the following <init-param>


Simples :-)

How to use the facade with CustomFields

This one is a little trickier. The facade uses a collection of static proxies and although I am planning to rewrite the proxies as "dynamic" proxies we're not there yet (and I need to do some reading first).

The only way to use custom fields with the facade today is to regenerate the proxies against your Sales Cloud instance. Here I will go through the steps you will need to do, however in the near future I will release some "scripts" which will do it all for you.

1. Identify the correct package name

The Facade has all its proxies in projects called "FusionProxy_<Object>Service. Within this project you will find the java classes are split between two packages

  • : This contains all the standard generated types
  • oracle.demo.pts.fusionproxy.<objectName> : This one contains the proxy itself

Identify the full package name of the proxy for the object you are going to regenerate. In my example here, im going to regenerate the Opportunity object and as you can see the package name is oracle.demo.pts.fusionproxy.opportunities

 2. Delete the contents of the proxy directory.

Shutdown JDeveloper, navigate to the source directory of the proxy project and delete both the src and classes

Startup JDeveloper, navigate to the FusionProxys project , in our case FusionProxy_OpportunityService, you should notice it is now "empty". If it is not the press the refresh button

4.  Regenerate the proxy from scratch

  • Select the project, right mouse click and select new...
  • Select "Web Service proxy" from the Web Services Categories.. If it doesnt show try typing it in the search  dialog
  • Enter the appropriate WSDL Document. This is the Hostname of your service + Endpoint URL. You can get this information from the file.
    E.g. For opportunities it is https://<hostname>/opptyMgmtOpportunities/OpportunityService?wsdl

    Hint: Check it works in a webbrowser first!

  • Next, Wait a bit....
  • For the package name, use the name you identified in step 1, for the Root Package leave it blank
    • Un-Select "Generate As Async"
  • Next
  • Next
  • Select "Don't generate any asynchronous methods"

  • Next 
  • Select "Oracle/wss_username_token_over_ssl_client_policy"
  • Next, then Finish

This will generate the proxy from scratch , just note the generation of the proxy may take some time. 

5. Go to the XJS_Beans project

Within here edit the generateClasses script and modify with your hostname for all rows.

open a shell prompt, navigate to this directory using your shell and execute this script. This regenerates all the JAXB objects..

6. Finally do a Build/Clean All followed by a Build/Make and deploy as normal

Any questions do ask! and yes as I mentioned earlier I plan to create a script to automate all of this. 

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, 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 


Friday Sep 27, 2013

REST Enabling Oracle Fusion Sales Cloud using Java

Oracle Fusion Sales Could (Rel7) currently has a WebServices/SOAP interface however many clients & partners are interested in accessing Oracle Fusion Sales Cloud using REST & JSON. The main difference between a SOAP service and a REST service is the “way” you get access to the data and methods you use. Whilst SOAP is very powerful, very complete and also can be quite complex perhaps over-complex. REST in comparison is rather simple and uses the http verbs (GET,POST,PUT etc) to define the operation and can be as powerful as you desire.

There are many documents on the web which discuss REST vs SOAP but in summary :              


Originally defined as Simple Object Access Protocol.

A protocol specification for exchanging structured information in the implementation of Web Services in computer networks.

An envelope, which defines what is in the message and how to process it
A set of encoding rules for expressing instances of application-defined datatypes
And a convention for representing procedure calls and responses.

Relies on eXtensible Markup Language (XML) as its message format, and usually relies on other Application Layer protocols (most notably Remote Procedure Call (RPC) and HTTP) for message negotiation and transmission.

This XML based protocol consists of three parts:


RESTful web service (also called a RESTful web API) is a simple web service implemented using HTTP and the principles of REST. Such a web service can be thought about as a collection of resources. The definition of such a web service can be thought of as comprising three aspects:

The base URI for the web service, such as

The MIME type of the data supported by the web service. This is often JSON, XML or YAML but can be any other valid MIME type.

The set of operations supported by the web service using HTTP methods (e.g., POST, GET, PUT or DELETE).




Why would you want to use REST instead of SOAP?

There are many reasons why one would/could want to use REST instead of SOAP, one reasons is that SOAP is considered too heavy-weight for mobile applications, where payload size is critical, and also instead of XML, JSON is the preferred  message format.

The JSON message format is also very appropriate when interfacing with systems that use JavaScript (such as browsers or node.js) and hence adds weight to the desire to use REST instead of SOAP for accessing Oracle Fusion Sales Cloud.

So getting to the matter at hand and getting RESTful

So enough of why REST , how does one do it for Oracle Sales Cloud (aka CRM). Thankfully this is rather straightforward, at Oracle OpenWorld 2013 you would have seen Thomas Kurian demonstrate our new Oracle SOA Suite and how it can transform a SOAP service into a REST service whilst this is excellent and incredibly productive some clients dont want to install SOA Suite soley for this purpose. Thankfully its possible to do the same using pure Java and deploy it to a cloud infrastructure, like the newly release Oracle Java Cloud Service. It is however worth noting that using SOA Suite is preferable because it accelerates the deployment tremendously and would ultimately be more "agile". 

So what are the basic steps to REST enable a Fusion Sales Cloud Service?  

  1. Download and install the Jersey REST libraries, we'll use these for the creation of the RESTful service
  2. Generate the SOAP Client Side Proxie(s) for Oracle Sales Cloud. In this example we're using static proxies however for a more industrialized approach Id recommend going down the dynamic proxy route, more flexible and less likely to break at runtime, however at a development cost.
  3. Create "wrapper" JAXB Objects so that you can return XML data. This is needed because the baseline SOAP clients dont have @RootElement  (s) defined.
  4. Create the RESTful project and expose the services you require.
  5. Deploy to your runtime Java contain, like the Oracle Java Cloud Service
  6. Consume by your favourite client, like a mobile phone etc 

For the purpose of the tutorial (in the document), I've documented step by step how you can build the above, query Oracle Fusion Sales Cloud, manage security  (for development & production) and how to deploy the code to the Oracle Java Cloud. Obviously take note that this document is more of a tutorial than anything else when building your own custom REST Adaptor you would tailor it specifically to what services your client (mobile phone, javascript widget etc) requires.

Happy reading



This document and source code is sample code and assumes no support from Oracle Corporation or myself. 


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.


« October 2015