This blog post is to demonstrate how to feed data on the SAP Emarsys from SAP CDC.

In this part, I demonstrate the developments on the SAP CPI that receives the customer data from SAP CDC, does the necessary transformations and enrichments, then send it to SAP Emarsys.

This blog demonstrates the following process:

1. An account is created on the SAP CDC, triggering an event.
2. This event starts a job that sends the account data to an IFlow on the SAP Cloud Integration through an HTTP post.
3. The first IFlow is responsible for generating the HTTP Header WSSE necessary to authenticate in the SAP Emarsys tenant.
4. The second IFlow receives the data from SAP CDC and send it to the third IFlow for further conversions.
5. The third IFlow uses first IFlow to generate the WSSE header and transforms the data to the SAP Emarsys expected format.
6. The data is sent to the SAP Emarsys tenant.

This diagram briefly shows the process described above.

As described in the SAP Emarsys API documentation, their API requires a WSSE authentication. For this reason, I created the Emarsys security material with the user and password provided by the SAP Emarsys tenant administrator.

Products/Solutions/Services used:

• SAP CDC
• SAP Cloud Integration (SAP Integration Suite)
• SAP Emarsys Customer Engagement

As mentioned in the Process Flow, I created three Iflows:

1. Generate X-WSSE Header:

This IFlow is used to generate the HTTP Header WSSE required by the SAP Emarsys API as the authentication method. It is called through the process direct adapter and expects to receive the message header SecureMaterial, which contains the SAP CPI security material ID used to generate the HTTP Header.

It is composed of three Groovy scripts that do the following:

1. Script1.groovy: This is our main groovy script which is directly being use in the above mentioned IFlow. We have imported the other two scripts (SecureStorageHelper, WsseHelper) in our main Script (Script1) and these two scripts are being called in our main function to fetch the stored credentials and X-WSSE Header.

2. SecureStorageHelper.groovy: This script is being used to fetch the stored credentials from “Security Material” and then returning them in a form of Tuple.

3. WsseHelper.groovy: This script is being used to generate the X-WSSE Header. Script1 passes the credentials to “getWsseHeader” function after receiving them from “SecureStorageHelper.groovy”.

There are 4 functions present in WsseHelper script with each having their own responsibility:

• generateNonce: This is a function which is being used to generate a “Nonce” i.e., a 16-digit random number which is encoded in a hexadecimal format.
• getDate: This function is being used to generate current date with timestamp in a “UTC” format.
• generateDigest: This function combines the “Nonce”, “Date” and “Password” and then produces a 160-bit (20-byte) equivalent hash value. And then it gets encoded in Base64 format.
• getWsseHeader: In this function, all other functions are called and then the combination of them is returned in the format mentioned in the script.

2. Receives Contact from SAP CDC:

This IFlow receives the contact data from SAP CDC and stores it into Data Store.

The Iflows proceed as follows:

• SAP CDC sends the contact data using the HTTPS protocol (method POST). Just for simplicity, I disabled the CSRF protection.
• And then after converting and splitting, the data gets saved into the data store.

3. Replicate Contacts to SAP Emarsys:

In this IFlow, we are picking the data from the above-mentioned data store and performing several steps to convert the data into Emarsys understandable format.

The steps are as follows:

Step 1. We are picking the data from the data store and converting it into XML format from JSON format as SAP CPI needs the data to be in XML format to perform the required operations.

Step 2. In the next step, we are storing “Email” into exchange properties from the payload and then making a “GET” call to Emarsys to check whether we already have a contact into our database with this email or not.

Step 3. In this step, we are saving the API call response in the exchange properties and routing the data to “Create contact (same)” IFlow or “Update Contact” IFlow based on the router condition.

Step 4. In this step, based on the country we are routing the contacts to normal opt-in or double opt-in depending on our requirements.

Step 5. If a contact is not from country where Double Opt-in is required then, it will enter the “Normal Opt-in” sub-IFlow. Otherwise, it will enter the Double Opt-in Sub-IFlow. For e.g.: Contact will enter DOI Flow only if it is from “DE” or “AT”.

Step 6. After entering the Opt-in Sub-IFlow, contacts will enter the mapping sub-IFlow via the process call and based on the router conditions, mapping will happen.

Step 7. After the mapping and gathering of data, it again gets converted into JSON format from XML format and then the data is sent to Emarsys after changing the header type to “application/json”.

Step 8. To trigger the DOI event for contacts entering double opt-in sub-IFlow, we are using Emarsys trigger event API.

Note: If a DOI event or Double Opt-in event is triggered for any contact, then that contact will receive one confirmation email asking for the confirmation of opt-in. If the contacts click on the confirm button, only then it’s opt-in will get changed to “True”.

DOI event will only be triggered for the contact if they are fulfilling the given router condition:

The payload for the API is stored in the content modifier:

And the API are:

Note: In the API, 457 is the event ID from Emarsys.

Note: In Emarsys, we had a requirement to maintain all the id origins i.e., to maintain the information about all the source system or to recognize all the source systems from where we have received the information for this contact.

Therefore, to maintain all ID origins of a particular contact in Emarsys, we came up with another custom solution.

Step 1. We created a multiple-choice field with the name “ID Origin” and inserted all the possible ID origin values.

Step 2. Created one sub-IFlow, to check the ID Origin from the payload and compare it with the existing Id Origin value in Emarsys using the Groovy Script after fetching the data from Emarsys using a Post API Call.

This script checks that whether we have the ID Origin from the payload already in Emarsys ID Origin field or not. If we already have that, then we don’t do change anything and send the same value again. If we have some new value which is not there in Emarsys field, then we append that value in the pre-existing values and then send it to Emarsys.

With this design, you will be able to replicate contacts in Emarsys from SAP CDC. If you have any queries, please drop a comment. Kindly like and share this blog if you find it helpful.

• SAP Emarsys API – Authentication
• SAP Emarsys API – Create Contacts

Thanks & Regards,

Aman Jain.