I would like to share my experience on SFDC REST API Integration with PO. I thought it is worth sharing and covering the end to end scenario at one place. Hence I am writing this blog. Hope you find it useful.
REST’S decoupled architecture, and lighter weight communications between producer and consumer. When Web services use REST architecture, they are called RESTful APIs (Application Programming Interfaces) or REST APIs. REST architecture involves reading a designated Web page that contains an XML file. The XML file describes and includes the desired content. Once dynamically defined, consumers can access the interface.
The Salesforce system can be integrated using SOAP or REST adapter. Here, we have used SOAP adapter for login lookup and REST adapter to consume REST API in SAP PI/PO.
The pre-requisites for REST API service.
- Java mapping knowledge
- Knowledge of REST adapter and its feature
- Target URL for SOAP lookup receiver channel
Step1: Get login WSDL from SFDC team.
Step2: Import WSDL into SOAP UI and test connection whether getting session ID in response structure.
Java mapping has set of activities as given below.
- Form SOAP envelope for SFDC login lookup.
- Get Session ID and Server URL from SFDC
- Assign SFDC Server URL and Session ID value into REST adapter service using dynamic configuration.
REST adapter service configured on receiver communication channel for all REST service call from SAP PI/PO to SFDC. The REST adapter converts the XML message to JSON format and gets SFDC server URL and session ID dynamically which received runtime from ESR.
Below REST Communication channel configured to get access_token and serverUrl in runtime:
- Instance is pattern element name which gets serverUrl value in runtime and assigned into URL Pattern.
- The resource value will be identified based on the receiving message type of particular scenario. We have configured different message type, since the communication channel is same for all receiving SFDC messages.
- Token is pattern element name which gets access_token value in runtime and assigned into HTTP header level as a field value for Authorization.
- Below is the Data format configuration used to convert XML to JSON and vice versa.
- Internally, a REST adapter makes use of 3rd party Jettison library for JSON processing tasks. In standard configuration, REST adapter relies on default conversion logic implemented in Jettison processor, which does not correlate or take into consideration payload elements properties as defined in a corresponding message type, but has its own optimization and type derivation mechanisms that are based on nature of the value of a processed XML document’s element rather than XSD schema of a processed message. As a result, this conversion may sometimes result in unobvious output – here are just few examples which are commonly faced:
Below is the configuration for multiple interfaces using the one REST Receiver communication channel. Much like we do for SOAP receiver for the same target e.g. – inbound SOAP over proxy channel.
I am aware that there are blogs which talks about bits and pieces about the REST Integration, but the overall scenario is not discussed in length. I hope you all find it useful. For any questions, please feel free to write back.