Yesterday Oracle released their cloud adapter for salesforce.com (SFDC) so I thought I would talk a little about why you might want it. I had previously integrated with SFDC using BPEL and the SFDC web interface, so in this post I will explore why the adapter might be a better approach.
So if I can interface to SFDC without the adapter why would I spend money on the adapter? There are a number of reasons and in this post I will just explain the following 3 benefits:
Lets take each one in turn.
The first obvious benefit is how you connect and make calls to SFDC. To perform an operation such as query an account or update an address the SFDC interface requires you to do the following:
Now these are not unreasonable demands. The problem comes when you try to implement this interface.
Before calling the login method you need the credentials. These need to be obtained from somewhere, I set them as BPEL preferences but there are other ways to store them. Calling the login method is not a problem but you need to be careful in how you make subsequent calls.
First all subsequent calls must override the endpoint address with the one returned from the login operation. Secondly the provided session ID must be placed into a custom SOAP header. So you have to copy the session ID into a custom SOAP Header and provide that header to the invoke operation. You also have to override the endpointURI property in the invoke with provided endpoint.
Finally when you have finished performing operations you have to logout.
In addition to the number of steps you have to code there is the problem of knowing when to logout. The simplest thing to do is for each operation you wish to perform execute the login operatoin folloed y the actual working operation and then do a logout operation. The trouble with this is that you are now making 3 calls every time you want to perform an operation against SFDC. This causes additional latency in processing the request.
The adapter hides all this from you, hiding the login/logout operations and allowing connections to be re-used, reducing the number of logins required. The adapter makes the SFDC call look like a call to any other web service while the adapter uses a session cache to avoid repeated logins.
The standard operations in the SFDC interface provide a base object return type, the sObject. This could be an Account or a Campaign for example but the operations always return the base sObject type, leaving it to the client to make sure they process the correct return type. Similarly requests also use polymorphic data types. This often requires in BPEL that the sObject returned is copied to a variable of a more specific type to simplify processing of the data. If you don’t do this then you can still query fields within the specific object but the SOA tooling cannot check it for you.
The adapter identifies the type of request and response and also helps build the request for you with bind parameters. This means that you are able to build your process to actually work with the real data structures, not the abstract ones. This is another big benefit in my view!
The SFDC API is very powerful. Translation: the SFDC API is very complex. With great power comes complexity to paraphrase Uncle Ben (amongst others). The adapter groups the operations into logical collections and then provides additional help in selecting from within those collections of operations and providing the correct parameters for them.
Installation takes place in two parts. The Design time is deployed into JDeveloper and the run time is deployed into the SOA Suite Oracle Home. The adapter is available for download here and the installation instructions and documentation are here. Note that you will need OPatch to install the adapter. OPatch can be downloaded from Oracle Support Patch 6880880. Don’t use the OPatch that ships with JDeveloper and SOA Suite. If you do you may see an error like:
Missing class: oracle.tip.tools.ide.adapters.cloud.wizard.CloudAdapterWizard
You will want the OPatch 11.1.0.x.x. Make sure you download the correct 6880880, it must be for 11.1.x as that is the version of JDeveloper and SOA Suite and it must be for the platform you are running on.
Apart from getting the right OPatch the installation is very straight forward.
So don’t be afraid of SFDC integration any more, cloud integratoin is clear with the SFDC adapter.