Migrating ValueMappingReplication from SAP PI/PO to CPI

[mert_oezkan]

Introduction

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

Prerequisites

Please note that in order to being able to call the OData API, we must create an Instance with Service: Process Integration Runtime and Plan: api and must create a Service key for that instance in the SAP BTP Cockpit. We will authenticate with that Service key against the OData APIs.

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. 🙂

Procedure

1. 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)


2. Get current Value Mapping through OData API


3. Use Zip Splitter to split the files


4. Use Router to modify value_mapping.xml only


5. Gather the Files


6. Encode the files Base64 (This is needed because the ODATA Upload API required this format)


7. Delete current Value Mapping (the initial one is deleted from the package, but still in Deployed state)


8. Upload new Value Mapping


9. Deploy new Value Mapping (the initial one will be over deployed)

Implementation

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

 

For the router you can use the Non-XML Expression ${header.camelfilename} = 'value_mapping.xml'. After that the initial payload from Step2 is restored. We need to map that to the structure which is required and predefined for ValueMappings. Please note that the version needs to be hardcoded to 2.0, otherwise deployment will fail:
The XML Modifier removes the XML Declaration. After that all three files inside the zip or gathered again. You can declare the gather step as follows:

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

Adapter configuration for deleting:

Before uploading the new VM, we need to set the body as required by the OData API:

{
"Name": "${property.context}", 
"Id": "${property.context}",
"PackageId": "ValueMappingReplication",
"Description": "${property.context}",
"ArtifactContent": "${property.content}"
}

 

And finally we can deploy the new VM:

Testing

Now let's run a test. I have mocked some data via Postman. Let's see what monitoring says:

Here we can see that Deployment has changes, it is now the technical user. Let's verify and have a look at the new VM:

It worked! 🙂

Outlook

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.