Comparing C4C Integration Methods (A2A, A2X, ODATA) for High Volume Scenarios
Comparing C4C Integration Methods (A2A, A2X, ODATA): I’d like to give acknowledgement and thanks to my colleague Edmund Chua for contributing to this blog post. The content is based on our past integration experiences, and specifically our experience on a customer project which involves retail execution (Visit Planning, Activities, Surveys) using C4C and a 3rd party handheld solution in a high volume scenario (expected daily volume in the millions of records).
In this blog post, we’ll compare the 3 different web service integration methods (A2A, A2X, ODATA) for 2 common scenarios: Retrieving Data and Creating/Updating Data. We’ll also provide our recommendation on the type of web service to use in high volume scenarios and also share some lessons learned.
Integration Methodology Comparison
There are 3 integration methods that were analyzed for best fit:
A2X (Application to X users)
- SOAP based web service, Synchronous execution
A2A (Application to Application)
- SOAP based web service, Asynchronous execution
ODATA (Open Data Protocol)
- REST based web service, Synchronous execution
Scenario 1: Retrieving Data
Using A2X to retrieve data requires submitting an XML formatted request payload to a service endpoint. The following is an A2X example of retrieving a specific survey by UUID:
Service Endpoint: https://myXXXXXX.crm.ondemand.com/sap/bc/srt/scs/sap/queryquestionnairevaluationcol
The selection parameters are defined within the XML request body and the response is returned in XML format.
Using A2X Method for Retrieving Data:
Using ODATA to retrieve data requires appending request parameters at the end of the service endpoint URL and submitting an HTTP GET request for the URL.
The following is an example of a request URL to retrieve Activity Worklist Items with various filters:
https://myXXXXXXcrm.ondemand.com/sap/c4c/odata/cust/v1/XX/ActivityWorklistItemCollection?$inlinecount=allpages&$filter=(ParentTypeCode eq ’12’) and (ParentGroupCode eq ‘0027’) and (ParentScheduledStartDate ge datetime’2016-04-27T00:00:00′) and (ActivityLifeCycleStatusCode eq ‘1’) and (ActivityTypeCode eq ‘542’) and (ActivityWorklistItemTypeCode eq ’01’) &$expand=ActivityAttachmentFolder,ActivityTextCollection
Unlike A2X, there is no request body that is sent to the service endpoint. All parameters and filters are embedded directly in the request URL itself.
The response can also be formatted as JSON using the directive $format=json, which returns a more compact response compared to an XML formatted response.
Using ODATA Method for Retrieving Data:
The choice of using ODATA or A2X for retrieving data depends on the business requirement.
For high volume data retrieval, ODATA is recommended for being lightweight compared to SOAP and also for its support of JSON formatted responses.
Scenario 2: Create/Update Data:
The following is an example of an A2X request to update 2 Task activities:
Service Endpoint: https://myXXXXXX.crm.ondemand.com/sap/bc/srt/scs/sap/managetaskactivityin
A2X allows you to submit updates in batches for better performance. In the simple example above, the system successfully processed both updates within the same request. In the scenario where one of the activities fails to update (i.e. object is already locked, invalid ID, etc.), then the entire request will fail. This is not ideal for high volume scenarios because just a single bad request in the batch can render the rest of the requests in the batch to also fail.
A2X Method for Creating/Updating Data:
Similar to A2X requests, the A2A request for creating/updating entities requires an XML formatted payload to be sent to a C4C service endpoint. The following is an example request for creating a Task Activity using A2A:
Service Endpoint: https://myXXXXXX.crm.ondemand.com/sap/bc/srt/scs/sap/activityreplicationin
Since this is an A2A web service call (asynchronous), there will not be a response payload from C4C after your request is received. C4C will return an HTTP 202 Accepted header that signals that the request was received however the response will be empty. To view any success or error messages, you will need to view the log entries in C4C’s Web Service Message Monitoring Tool (Administrator -> Web Service Message Monitoring).
If the request was processed successfully, you will find a success log entry for the request:
If an error occurred, an error entry will be logged in the message monitor:
To view additional details of the error, you can open the Error Log for the request:
Unlike A2X requests where the calling system is required to wait for C4C to execute the actions in the request, A2A requests are asynchronous
A2A Method for Creating/Updating Data:
The following is an example of creating a new contact person using ODATA:
Using ODATA Method for Creating/Updating Data:
The choice of using A2A, A2X, or ODATA depends on the business requirement. For high volume create/update requests, A2A is recommended due to it being an asynchronous service. We use A2X only when A2A is not available.
However, a caveat on using A2A is that it’s not officially available for Third Party integration (i.e. integrating with a non-SAP system). If you encounter issues with an A2A web service after go-live, there is no commitment from SAP to provide support for your A2A solution, so be aware!
Design Considerations for High Volume
To improve efficiency in high volume scenarios, the below principles were used in our interface design:
- Reduce the number of ODATA calls. This can be done by using ToParent property in the ODATA, and merging this ToParent association. For example, by merging ToParent in WorklistItem, we can call WorklistItem directly to get the attributes in both Worklist and WorklistItem, instead of calling Worklist then WorklistItem.
- Avoid the use of navigations in ODATA as these reduce performance in high volume cases. Have all the data available in level 1 of the ODATA object. This is achieved by merging associations.
- Instead of using association, another alternative is to data join. However, do the join outside C4C, i.e. extract the data and join in your external database.
- Minimize extraction of duplicate data.
ODATA: Making Batch Calls
ODATA allows performing several operations within a single request using the $batch directive.
You have the option of encapsulating each operation in its own change-set or lump all operations into a single change-set. The issue with the latter is that, unlike A2A, C4C will not split the batch request if a single operation of the batch call fails. C4C will return a single failed response and it will be up to your application to fix/remove the failing request and to resubmit the batch request again for reprocessing. If using multiple change-sets, C4C will return a response for each change-set in the batch call.
ODATA: Retrieve Data in Batches
When retrieving large volumes of data, we like to retrieve in batches for better management of resources.
One way is to specify the size of each retrieval, such as getting 1000 records each time. This can be done using the $top and $skip.
To get the first 100 records:
Then the next 100 records:
When it is not possible to use $top and $skip (for example in BODS, all data is retrieved before $top is applied, thus making $top ineffective), another way is to use range, such as retrieve (1<=ID<=1000), then (1001<=ID<=2000).
https://…./ActivityCollection?$filter=(ID ge ‘100’ and ID le ‘300’)
For range, due to a limitation in the ODATA framework, gt and lt on the same field does not work. Therefore, we should always only use ge and le.
The last way is to retrieve data using different key values, such as when Type = 1, then when Type = 2, and so on.
https://……../ActivityCollection?$filter=(Type ge ‘1’)
A2A Web Services: WS-Addressing
For asynchronous web service calls (A2A), we need to use WS-Addressing to execute the calls.
Where middleware cannot support WS-Addressing, we need to modify the XML input headers sent.
From the WSDL, look for wsdl:binding where the type is the name of the A2A call. Get the soapAction value.
In the header of the web service call, define the soapenv:Header manually as below. The soapAction will be the wsa:Action. Give a unique MessageID in UUID format. Note that this MessageID must be unique for every call.
Use the same MessageID value for the MessageHeader.ID sections in the body of the web service call.
A2A Web Services: BODS issues with SOAP version 1.2 binding
When using BODS (SAP Business Objects Data Services), the XML parser is not able to identify the soapAction element if the WSDL is based on SOAP version 1.2. C4C’s WSDLs contain both SOAP version 1.1 and 1.2 bindings. To avoid issues, ensure that your the WSDL contains the SOAP version 1.1 binding.
A2A Web Services: Testing with SOAPUI
If you are using SOAPUI to test A2A web services, you will need to make sure the WS-A addressing is enabled and the MessageID is generated automatically:
BODS Performance – Truncate WSDL
SAP Business Object Data Services loads the entire WDSL content in memory for each request that is made. For the elements that are not used, BODS will set the element value to ‘NULL’ which impacts performance in terms of the memory resources required.
To reduce the memory footprint and improve performance, it is recommended to comment out the unnecessary elements in the WSDL.