Hello SAP Integration enthusiasts,
first of all I would like to say that I am very excited, this is my first published SAP Blog. I am thinking about to publish many more in the future, so any kind of feedback is highly appreciated!
The topic that is covered in this Blog is related to Value Mapping Replication used for mass data where the content is directly sent to the SAP PI runtime engine and how to migrate this requirement to SAP Cloud Integration.
Moreover, in this case the content is sent from an SAP backend system to SAP PI via a Proxy Sender Adapter on a daily basis. How to move that replication scenario to Cloud Integration? And how to do this in an automated way? The answer is by making use of the published OData APIs which can be found in the SAP Business Accelerator Hub.
We will focus on the Value Mapping OData APIs. You can get familiar and see the APIs here: ValueMapping API References
Also please create a ValueMapping in CPI beforehand and download the .zip content afterwards to get familiar on how the value_mapping.xml inside the .zip is structured.
Please also read the Outlook section it might be interesting to you.
- Manually create and deploy an initial Value Mapping with the desired name (this is a one time activity and needed in order to get the .zip through OData API)
- Get current Value Mapping through OData API
- Use Zip Splitter to split the files
- Use Router to modify value_mapping.xml only
- Gather the Files
- Encode the files Base64 (This is needed because the ODATA Upload API required this format)
- Delete current Value Mapping (the initial one is deleted from the package, but still in Deployed state)
- Upload new Value Mapping
- Deploy new Value Mapping (the initial one will be over deployed)
Now let’s put our design thinking into practice.
Step1 – Create and Deploy VM
This is our initially created VM. We can see that it has been deployed successfully by me. Later the Deployed By name should change and we should see the CPI technical user.
Step2 – Get current VM through OData API
Before calling the Get OData Api, we need to save the initial Payload coming from the SAP Backend system as a Property as we will need to restore it in a later step. Afterwards we can call the Odata API. The adapter configuration looks as follows:
Note: The Id (ValueMapping Name) is set via a property. I take it as a XPath Expression from the incoming payload. You can read more in the outlook section about that topic.
Step3,4,5,6 – Split Zip, Modify value_mapping.xml, gather files as Zip, Encode Base64
After that the content will be base64 encoded. That content needs to be stored as a Property as we will need it later for the upload part.
Step7,8,9 – Delete current VM, upload new VM, deploy new VM
Before uploading the new VM, we need to set the body as required by the OData API:
I am a big fan of designing iFlows and the integration architecture as generic as possible. The ultimate goal is to make as much re-use as possible of already existing artifacts. That makes it possible to save time, quality and costs as there is no need to re-engineer.
Having said that, we have extended the Flow in such a way that we only have one Proxy Dispatcher Flow. That means no matter from which SAP backend system and no matter which interface, it is always pointing to that one XI Sender Adapter in CPI. The CPI Proxy Dispatcher Flow then is responsible for routing to the main iFlow. Further the ValueMappingReplication is also kept dynamic and suitable for any other requests/contexts coming from the SAP Backend system. If you are keen to know how a Proxy Dispatcher Flow can look like, please do let me know. I am happy to create another blog about that topic.