Skip to Content
User Experience Insights

Easy C4C OData PATCH/POST operations in SDK without CSRF token

Hello everyone,

Welcome to my blog , the intent here is to discuss the one of the most reliable way to consume C4C OData within C4C itself with standard Communication Scenario: OData Services for Business Objects. Thanks to a friend  Ayushi Verma  who had a  business case which required updating objects in different deployment units which inturn inspired me to share this to the community. As we all know C4C OData required CSRF token for security reasons for any post/update operations , thanks to the new feature wherein not all scenarios require CSRF token in a server-to-server communication – e.g. Integration (technical) user() SAP documentation.

Earlier, OData posed a slight limitation as basic authentication was restricted to Business user which caused concerns of security and password management however, with standard scenario(OData Services for Business Objects) which supports all the standard and custom services in it and with  technical users in authentication made life easier.

Use Cases:

  • We can follow this strategy to avoid calling Standard SOAP WSDLs in SDK whenever required.
  • This can be implemented for updating objects from cross deployment units.
  • Objects which are not PSM released in SDK can be updated/modified with ease.

Advantages of ODATA:

  • C4C OData API’s are not only restricted to SAP landscape unlike the Standard SOAP interfaces provided and can be used for any integration
  • It’ s lightweight integration technique and can be used for heavy volume of data.
  • ODATA allows performing several operations in a request using  $batch.
  • Easily configurable and any additional field additions is very convenient.
  • Web Services APIs (SOAP, A2X) are being deprecated and planned to to be retired hence OData services are preferable.

Solution:

The underlying scenario which we will be implementing is to update/create the Tickets from Activity  business object which are both in different deployment units. Actual business scenarios may widely differ , intention here is to just explain a basic functionality, Any coding reference is not supposedly  recommended for productive use.

Steps :

  1. Create a communication system pointing to C4C tenant as hostname.
  2. Create Communication arrangement for standard Communication Scenario: OData Services for Business Objects. Select the communication system created above in the system instance.
  3. Next step would be to select the required service to be consumed from the services list be it standard or custom. These custom service can be based on standard objects or completely custom objects created in the OData explorer. In our case we care using a custom OData service for Tickets.
  4. In the authentication we will find a technical user created already for which we need to maintain the password. Make a note of these technical user details which would used again in the following steps.
  5. So far we have set up all the communication details of the standard OData service  which is an inbound service.
  6. Log on to SAP Cloud application studio and Add a new item> External webservice integration. This is done to trigger an outbound service from SDK which communicates with the inbound service we configured in step 3 to send to data back to C4C.
  7. Maintain the webservice type as REST and maintain the URL of our custom OData selected in step 3. This URL can also be fetched from OData explorer under administration.
  8. Once we have configured the external webservice integration we further need to create a communication scenario and arrangement for it.
  9. Right click on the WSID file created for our service in SDK and Create communication scenario, post that verify the service is checked in the outbound service in the scenario and activate it.
  10. Next step is to create a communication arrangement for the webservice. In the authentication method select User id and Password and maintain the technical user credentials which we configured in step 4.  Save and activate.
  11. The communication is all set for trial.
  12. Based on our use-case we will write a piece of code in Activity>BeforeSave to modify/create tickets calling our custom OData service.
  13. Once we set all communications and our logic to update the Ticker from Activity is in place, we can proceed to try it out by updating any appointment which has ticket in it’s related items. The screenshots below are the test results.

Happy Learning !!!

Cheers,

Rocky

Be the first to leave a comment
You must be Logged on to comment or reply to a post.