SAP_CPI – Demonstrating the ‘DataStoreOperations’ Feature

Introduction:

As integration scenarios are becoming more and more complicated, developers might come across a situation where a message payload of one interface after successfully getting processed might be again required to be reused in the same interface or any other interface. To handle such requirements, SAP CPI has introduced new feature ‘DataStoreOperations’ under which various controls can be used in the iflows for storing/fetching/deleting the message payload of an interface.

Scenario:

I will be demonstrating the different controls available in ‘DataStoreOperations’ using a simple file-to-file scenario by means of SFTP adapter. There are various SAP blogs available that can be referred for working with SFTP adapter in SAP CPI.

From the palette menu, select the DataStoreOperations to find the different controls Delete/Get/Select/Write.

Write operation

1. Create an iflow ‘zflow’ as below. To keep it simple I am just passing an xml file (with 2 records) through SFTP and in ContentModifier step the body of the incoming payload is been passed as-is to the next control step ‘Write’. On the receiver side, I am creating an xml file in the SFTP location using the incoming payload.
2. In the ‘Write’ control step select ‘Global’ for the parameter ‘Visibility’ so that the message stored is visible to other iflows.
3. Once the iflow is deployed, we can goto path Overview->Manage Data Stores, and check that a new data store has been created in the tenant.

GET operation

1. Create a new iflow ‘zflow1’ as below. In this scenario pass a different xml file (with 1 record) through sender SFTP adapter. The content modifier will pass the incoming payload as-is to the ‘GET’ operation.
2. In the ‘GET’ operation step, provide the data store name that was created in the tenant by the ‘Write’ operation.
3. On deploying the iflow, we can check in the logs of the message monitor that the GET operation has received a payload of a single record from Content modifier, but after fetching the message payload (with 2 records) from the data store, it has sent out the fetched payload to the receiver.

Select operation

1. We create a new iflow ‘zflow_select’ as below with similar steps as in previous section and use the ‘Select’ operation from the control’s palette.
2. Here I have selected that 2 messages have to be polled from the data store to be sent to the receiver.
3. On deploying the iflow, we can observe the results in message processing log as below-

The content modifier has sent only 1 record in the payload to the Select operation.

The Select operation after polling 2 messages from the data store has sent 4 records to the receiver.

4. On observing the data store, we could find out that the Select operation by default selects the first 2 messages that were initially added to the data store.

Delete operation

1. I created a new iflow ‘zflow_del’ as below with same steps as provided in previous sections and added a ‘Delete’ operation from the control palette.
2. The value for the parameter ‘Visibility’ is Global, so that the iflow will look for the given data store ‘TestDSN’ at the tenant level.

3. On deploying the iflow, we could check that the message relating to the EntryID specified in the iflow has got deleted and now only 2 entries are available.

Conclusion:

In the real-world scenarios, there are situations where response payload of one message must be used as a request payload in another message. SAP_CPI DataStoreOperation feature gives the developer a flexibility to handle these scenarios easily. It is not necessary that all these operations will be required in one interface; this blog can be used to get the basic idea of using the DataStoreOperations according to the requirements.

References:

1. https://help.sap.com/viewer/368c481cd6954bdfa5d0435479fd4eaf/Cloud/en-US/ac39f1d1bd2f427c97b3694e54370bda.html
2. https://help.sap.com/viewer/368c481cd6954bdfa5d0435479fd4eaf/Cloud/en-US/79f63a4bf5a44b5996aa34c51e2f187f.html