Customer Relationship Management Blogs by Members
Find insights on SAP CRM and other customer relationship management products and topics in blog posts from community members and share your own perspective.
cancel
Showing results for 
Search instead for 
Did you mean: 
angela_lopez
Participant

Introduction


In this blog post, we will learn how to configure the iFlow 'Replicate Business Partner to SAP Marketing', in the SAP Marketing Cloud integration with SAP Cloud for Customer for the transfer of information with custom (extension) fields by SAP Marketing Cloud and SAP Cloud for Customer.

Following one of the SAP Cloud Platform Integration updates, the standard iFlows feature Pre-Exit Post-Exit in the integration flows. This means that the previously delivered standard integration flows remain intact as you extend them. And that obviously means you no longer need to worry about updates and perform your extension activities over and over again. But in this case, we are going to make the adjustments within the standard iFlow so that the connection is established correctly because after trying to create a new iFlow for these extensions, but the connection was not established correctly.

 


Figure 1: Pre-exit and Post-exit concept


 

Overview



Figure 2: Standard process


 

This standard integration flow figure has both pre-Exit post-Exit, we will focus on the post-output concept because almost all SAP Marketing integration flows only have post-Exit.

 

Business context


For this scenario, we will use the standard integration package "SAP Cloud for Customer Integration with SAP Marketing" in SAP Cloud Platform Integration. And we'll extend the "Replicate Business Partner to SAP Marketing" integration flow. This integration flow has a process flow like the one below.


Figure 3: Standard iFlow


 

In our case, the call to a new iFlow will be modified by a new mapping with the new fields.

So the iFlow would look like this:

 


Figure 4: Our iFlow


 

Seen in a simpler way it would be like that:

 


Figure 5: Our iFlow simplified


Considering this image, we will follow the figure's notations, so we need to know the meaning of each one of them:

Message A: this message represents the original (extended) payload from the source system. In our scenario, the source system (Sender) is C4C. Therefore, this message must have the extended metadata of the SOAP BusinessPartnerReplicationSelfIniticatedOut service.

Message B: This message represents the result of the standard mapping operation in the standard integration flow. Therefore, it is only standard metadata of the SAP Marketing OData service.

Message A, B: This message is the combination of messages A and B. Remember that message B represents the mapped message (standard metadata of the OData service in SAP Marketing) after the standard mapping operation in the standard integration flow. This means that it contains only standard mapped fields. On the other hand, Message A also contains unmapped standard fields, as well as custom fields, since it represents the original message (payload) from C4C.

Message C: is the extended metadata of the OData service in SAP Marketing. This extended metadata must include our custom fields in SAP Marketing. And this is exactly what our C message is going to be similar to. In other words, I could roughly say that Message C will be a sort of extended version of Message B.

We shape Message C with our own mapping operation where we also map our custom fields into the post output integration flow. Consequently, this message is basically the final mapped message that we want to deliver to the receiver (SAP Marketing). So that message C is delivered to the receiver (SAP Marketing) instead of message B in an extension scenario.

 

Configuration Activities


You have to enter your HCI environment and within your package "SAP Cloud for Customer Integration with SAP Marketing" go to the iFlow "Replicate Business Partner to SAP Marketing".

First, you need to configure the extension.

To do this, we will modify "Extension Implemented" to "true", as shown in the following image:

 


Figure 6: Extension Implemented


Within the standard iFlow we will eliminate the call to a new iFlow, as we will make the changes within the standard iFlow. Instead of this call, we will place a new "Message Mapping"


Figure 7: Part that we are going to eliminate


So the new iFlow sub-process would look like this:


Figure 8: New sub-process


Within this sub-process, we will create the mapping file:


Figure 9: Create the mapping file


Once created, we have to add the messages A, B and C in order to perform the mapping.

Obtaining the message A


To download the metadata through the SOAP service, we will log into C4C, where from the communication agreements we will download the corresponding iFlow for this iFlow:


Figure 10: Message A



Obtaining the message B


Since we have this message because it comes in the standard integration flow we only have to download it from the "Resources" tab


Figure 11: Search for file name


 


Figure 12: Search within the mapping file



Figure 13: File name


This is the name of the file we need, which we can use from "Resources”


Figure 14: Field from Resources



Obtaining the message C


This message will be obtained through the OData Service


Figure 15: OData Service


First we establish the connection


Figure 16: Establishing the connection


Then we select the fields we need to obtain


Figure 17: Select the fields


 

Once this is finished it will create a file automatically which will be the one we have to update in the iFlow


Figure 18: New field created


 

Carrying out the mapping


Once we have all the messages, we upload them in the new Mapping.


Figure 19: Upload messages


Uploading the files within the mapping in the following order:


Figure 20: Messages Order


 

In the mapping of the To message A we will map only the custom fields.


Figure 21: Mapping


On the other hand, the rest of the standard fields will be mapped with the message B, these fields can be mapped giving the option of auto-mapping, which will be faster.

 

Once this mapping is finished, it is already possible to save the iFlow and start to make the information transfer.

Conclusion


This is one of the possible ways to adjust this iFlow so that the custom fields can be passed from one system to another, as we have already mentioned the disadvantage of this way is that, in case this iFlow is updated, we will need to download it again and set up this configuration again. I hope this blog post can help you!