As SAP is decreasing its support for (standard) SOAP services in Sales and Service Cloud, the standard C4CODATA api is used more and more often when dealing with integration issues. The C4COODATA api documentation can be found HERE. The documentation provides an overview of the specific entities available in the underlying odata model and provides example messages for querying, creating or changing objects.
The following points are important to keep in mind regarding the C4CODATA api:
- For creating or changing data a CSRF token is required. This token needs to be fetched by processing a GET request. Additionally the cookie from the token fetch needs to be used for the request to create or change data.
- Creation is done with a POST method (message body is required)
- Update is done with a PATCH method (message body is required in combination with the object ID of the existing object)
- Some entities in the odata model contain sub entities. For example an Account has an Address, Contactpersons etc. Each sub entity has an individual URI.
Now consider an example in which we would like to maintain product data in C4C via an iflow in CPI. The relevant odata URI is the following: https://<ServiceURL>/ProductCollection. We assume incoming messages as described in the examples in the C4C odata documentation (see link above). Questions that pop up are: How do we determine in the iflow which http method to use (POST or PATCH)? How do we add the object ID to the request when needed? An approach is described below:
Step 1: Initialize message header
- We prepare the message header for fetching a CSRF token (and cookie). Additionally we would like to identify if the the current product is already existing in the system or needs to be created. In order to do that a filter parameter is introduced. CamelHttpMethod is that variable parameter that will contain the httpmethod value:
- Because of fetching the CSRF token the message body within the flow will change. Therefore we need to store the initial message body before fetching:
Step 2: Groovy script to populate filter parameter
- The incoming json message is parsed using the jsonSlurper. Using the Slurper we can identify the current product ID and construct our URI filter:
Step 3: Perform GET request to fetch CSRF token (and Cookie)
The filter constructed in the previous step (stored in the header) is used for the GET request.
Step 4: Determine whether an existing object ID for product exists. If so, store in header.
- The json body from the response message is converted to XML for using xpath navigation through the content. The message body is afterwards changed back to json. The Contentmodifier is shown below:
Step 5: Prepare header and body for Update/Create request.
- The CSRF token is fetched but the corresponding Cookie parameter needs to be added to the header.
- A quick check of the body is done to determine if the response contains information on the searched product. That means the product is already existing (update, else we do a Create). CamelHttpMethod is set accordingly.
- For an update the relevant ObjectID is incorporated in the endpoint (ServiceComponent parameter).
Step 6: Restore initial body
- Because of the GET request in step 3 the message body in the flow has been altered and therefore the initial incoming message body needs to be restored by using the property parameter we introduced in step 1.
Step 7: The call to C4C is performed
- The header parameters ServiceComponent and CamelHttpMethod are used to perform the POST or PATCH requests.
Additional tip: In case multiple sub entities need to be changed in one go (for example an Account header, Contacts and Tax data) try using one incoming message which contains the different smaller submessages corresponding to each sub entity. With the splitter functionality the message can be deconstructed. The individual submessage can be processed via the steps mentioned above. Consider creating a local integration process for the steps mentioned above.
Hope this was helpful.