Interact directly with Salesforce API using the Enterprise WSDL- No Salesforce adapter

As part of Oracle Fusion Middleware 11.1.1.7, Oracle introduced the Cloud Adapter for Salesforce.com integration.

However, for complex scenarios it might be better to interact directly with Salesforce API using the Enterprise WSDL. You will need to manage the sessions (login/logout) in your custom code, but it allows you more flexibility to create a generic approach and reuse it.

Before you call the service to query or change objects, you need to call the Login operation and handle the Session ID received back, that needs to be included in any subsequent requests

Here in this tutorial I am sharing a way to interact directly with Salesforce API using the Enterprise WSDL instead of salesforce adapter.

Prerequisites:

1)  Credentials to your Salesforce.com account

     Username (in the form of an e-mail address)

     Password + Security token.

2) Download Enterprise WSDL file form Salesforce.com

3)  Import Salesforce.com Certificate into Client/Server

The Salesforce.com Client certificate has to be downloaded from the Salesforce.com application user interface. This certificate has to be imported into the client server for successful handshaking with Salesforce.com

For more information on the prerequisites, please refer to the user guide for salesforce adapter.

http://www.oracle.com/technetwork/middleware/adapters/documentation/ug-sfdcadapter-ps6-2104970-2262659.html

Create a BPEL process to invoke Salesforce

1    1) Create a SOA project with sync BPEL

 2)Another component that would be brought into the composite is a Web Service Adapter. Create it on the basis of enterprise WSDL. On the composite.xml, provide wiring between both the component.

3) Click on the BPEL to write the logic

4) In Salesforce the first operation that is invoked is the login operation. This process takes 2 inputs: ‘user name’ and ‘password’ via payload. The password is a combination of Salesforce password and the security token. Only when we are successfully able to invoke the login operation we would be able to invoke the other operations on Salesforce.

Drop an invoke activity and select Login operation from the drop down. Create input/output variables for the invocation.

5) Dropassign activity assigning values to username and password parameters, prior to the Invoke activity.

6) The output payload provides two important details using which we would precede with the subsequent operations. These are as follows:

Session ID: This ID needs to be sent as part of header information for all operations post login

ServerURL: This is the URL that needs to be called for all subsequent operations (query, update etc.) for this user.

The output of login operation provides Session ID that needs to be included in any subsequent requests to maintain the sessions.Create a SessionHeader variable of type Header.Map the session id retrieved from the login operation into this variable.

7) Configuration for Server URL: Create one PartnerReference variable in BPEL project of ‘EndpointReference’ type defined in ws addressing xsd http://schemas.xmlsoap.org/ws/20 03/03/addressing. Map the server URL received as a response of login operation to this variable, and then subsequently assign this variable PartnerReference directly to the partner link prior to invoking the second operation.

8) Drop an invoke activity and select the next operation you want to perform (create in this case).

9) In the invoke activity, select Header tab and select SessionHeader.

10) In order to assign input to CREATE operation, drop an XSLT activity to map input variable to Invoke_CreateTestObject. 

Salesforce WSDL exhibits polymorphic behavior. Records need to be substituted as actual Salesforce object as shown below

So this is how the BPEL looks like. Deploy and test the composite

HAPPY LEARNING!!!!