Skip to Content
Technical Articles
Author's profile photo Hakan Köse

How to extend your SAP Marketing Integrations with Post-Exits in SAP Cloud Platform Integration (Part-2)

This blog is successor to this blog. So I highly recommend you to read it first before proceeding with this one especially if you don’t know the meanings of the notations (Message A, Message B etc) that we use in this blog. The predecessor blog explains all of them.

This part is going to focus on configuration activities solely.

Configuration Activities

1. Preparation of Integration Package “SAP Cloud for Customer Integration with SAP Marketing”

You need to log in to your SAP Cloud Platform Integration (CPI) tenant with your credentials. You need to navigate to “Discover” page and find the integration package “SAP Cloud for Customer Integration with SAP Marketing”.

After you copy it, your copy will be available in “Design” tab in your CPI tenant. These activities are already explained in the documentation of the standard integration package here. You need to read “Integration with SAP Marketing via CPI” or “Integration with SAP Marketing Cloud via CPI” documentations depending on your deployment.

When you check out the copied package in “Design” tab, you can spot our integration flow “Replicate Business Partner to SAP Marketing` in the list of “Artifacts” tab (Figure 1.5)

Figure 1.5: Replicate Business Partners to SAP Marketing integration flow

You need to configure the integration flow by following instructions in documentation of the standard integration package.

During the configuration of the integration flow, you need to take note of two points regarding our topic:

– You need to set `Extension Implemented” to “true” in integration flow configuration (Figure 1.6)

To do that, simple go to “More” tab and type “true” (all lower case) for the parameter named “Extension Implemented”. This indicates we have an extension scenario and standard integration flow should call our post-exit flow that we are going to create.

Figure 1.6: “Extension Implemented” parameter

   –  You need to note down address of Post-exit flow because it will be really important during the design of our Post-Exit Flow.

To find out the address of Post-Exit reference, you need to go to “Receiver” tab and pick “BusinessPartnerReplicationPostExit” from drop-down list for “Receiver” parameter. Address should appear like in the Figure 1.7.

Figure 1.7: Address of the Post-Exit Flow

After you’re done with other configurations for “Replicate Business Partner to SAP Marketing` you just need to save your settings.

That’s it, There’s nothing we should do about the standard integration flow from this moment on.Now we’re getting on to design our Post-Exit flow.

2. Designing Post-Exit Flow

To design our Post-Exit flow, we need to create an integration flow in our integration package. For Post-Exit concept to work properly, your standard integration flow has to be in the same CPI tenant with your Post-Exit flow. We’re going to create our Post-Exit integration flow in the same integration package with our standard integration flow, so this prerequisite will already be fulfilled.

To create our Post-Exit flow, you can follow below screenshots (Figures 1.8 – 1.10)

Figure 1.8: Editing standard integration package

Figure 1.9: Creating Post-Exit Integration Flow

I normally give the same name as original standard integration flow and add “Post Exit” as a suffix. This way our post-exit flow gets listed right after original standard integration flow in the list of “Artifacts” tab in our integration package. You can easily spot your Post-Exit flows if you stick with this namespace pattern.

Field Description Value
Name You can give the same name with your original integration flow and provide “Post Exit” addition at the end of it Replicate Business Partner to SAP Marketing Post Exit
ID Should be populated automatically based on the name
Product Profile Dot not change it
Description Description of your Post-Exit flow. You can type anything you like here to describe your Post-Exit flow purpose Post Exit During Business Partner Replication to SAP Marketing

Figure 1.10: Maintaining information for your Post-Exit Flow

Finally click “OK” to save your Post-Exit integration flow.

2.1. Defining Process Adapter and Message Mapping

Now we’re going to design an integration flow like shown in Figure 1.2 in predecessor blog

Let’s start with “Process Direct” adapter. You can follow the screenshots below for the instructions (Figures 1.11 – 1.14)

Select “Connectors” from left lane menu and click on “Sender” box and draw a line to “Start” icon with drag&drop

Figure 1.11: Connect “Sender” to “Start” by drag6drop

 

Figure 1.12: Selecting ProcessDirect as “Adapter Type”

Now, here’s very important. On “Connection” tab, for the “Address” field, you need to type down the exact address you noted in Figure 1.7

Figure 1.13: Defining address for Process Direct adapter

You can optionally externalize this parameter so that you can also maintain this address while configuring the Post-Exit flow.

Figure 1.14: Externalizing address parameter

Now we need to create a message mapping for our own mapping. For instructions, you can follow screenshots below (Figures 1.15 – 1.19)

Figure 1.15: Defining mapping – 1

Figure 1.16: Defining mapping – 2

Figure 1.17: Defining mapping – 3

Figure 1.18 Naming your mapping

Figure 1.19: Defining mapping -4

We added required elements to our Post-Exit flow. Now we need messages (Message A, Message B and Message C) to perform our own mapping.

2.2. Getting Extended Metadata of C4C SOAP Service (Message A)

The creation of custom field (ZZMKTS4ID) and enabling it for relevant web services in SAP C4C is not part of this blog. These administration activities are normally done by C4C consultants.

To download extended metadata of the SOAP service (including our custom field), log in to SAP C4C with your credentials. You need to find corresponding communication arrangement for your integration scenario and download WSDL from there. For our scenario, the communication arrangement is “Business Partner Replication to SAP Business Suite” for Marketing communication partner.

You can follow the screenshots below for instructions (Figures 1.20 – 1.22)

Figure 1.20: Finding relevant communication arrangement – 1

Figure 1.21: Finding relevant communication arrangement – 2

Figure 1.22: Downloading WSDL for the SOAP service

You can optionally rename your wsdl file after you download it.

2.3. Getting Standard Metadata of SAP Marketing OData Service (Message B)

This is relatively easy because it’s already available in standard integration flow. You can download it from “Resources” tab of “Replicate Business Partner to SAP Marketing” integration flow once you identify which schema you should download (Figures 1.23 – 1.26)

Figure 1.23: Identifying the schema – 1

Figure 1.24: Identifying the schema – 2

Figure 1.25: Identifying the schema – 3

Figure 1.26: Downloading the schema

Similar to Message A, you can also rename this service metadata.

2.4. Getting Extended Metadata of SAP Marketing OData Service (Message C)

This part is a bit tricky. Fortunately, I already created a blog series that explain how to create a custom field in SAP Marketing and enable it for required OData services. Furthermore it also explains how you can get the latest version of an OData service metadata (including our custom fields) from SAP Marketing. Kindly note that, though, our custom field (ZZ1_S4ID_ENH) and our OData service (CUAN_BUSINESS_PARTNER_IMP_SRV) differs from the ones explained in referred blog (But of course, the mentality is the same).

For how to create custom field and enable it for our OData services, click here to find out.

In order to get the latest metadata of OData services from SAP Marketing, we first need to create a connection between “End” icon and “Receiver” box and choose OData as Adapter Type in our Post-Exit Flow (Figures 1.27 – 1.31)

Figure 1.27: Getting the latest metadata of OData service – 1

Figure 1.28: Getting the latest metadata of OData service – 2

Figure 1.29: Getting the latest metadata of OData service – 3

Figure 1.30: Getting the latest metadata of OData service – 4

Figure 1.31: Getting the latest metadata of OData service – 5

From this moment on, the steps are quite similar to steps explained here in this blog. We just need that schema generated at the end with .XSD extension. If you follow the steps and get the latest metadata from OData service CUAN_BUSINESS_PARTNER_IMP_SRV, you will have a list like the following in “Resource” tab for your Post-Exit integration flow (Figure 1.32)

Figure 1.32: The latest metadata of OData service (Message C)

Since we got the Message C in place, you can now delete the connection between “End” and “Receiver” and even “Receiver” itself in our Post-Exit flow design.

We need to add Message A and Message B as well to our Post-Exit integration flow resources [We downloaded them in the steps “2.2. Getting Extended Metadata of C4C SOAP Service (Message A)” and “2.3. Getting Standard Metadata of SAP Marketing OData Service (Message B)” respectively]. You have to select WSDL files from your PC folders that you downloaded them to (Figure 1.33)

Figure 1.33: Adding Message A and Message B to resource list

If you don’t rename the WSDL files after you downloaded them to your computer, you should end up with resource list like below (Figure 1.34)

Figure 1.34: Final list of resources (Message A, B and C)

2.5. Performing Post-Exit Mapping

We’re all set so we can perform our mapping as we have got all the sources that we need. Once you select the mapping to go into details, you can follow below screenshots as they demonstrate you how to select your sources in order and how you can perform our mapping according to our scenario: We should map our custom field from C4C (ZZMKTS4ID) with our custom field from SAP Marketing (ZZ1_S4ID_ENH) in addition to existing mapped standard fields (Figures 1.35 – 1.44)

 

Figure 1.35: Adding source message

Figure 1.36: Picking up Message A

Figure 1.37: Adding second source message – 1

Figure 1.38: Adding second source message -2 

Figure 1.39: Picking up Message B

Figure 1.40: Adding target source (message)

Figure 1.41: Picking up Message C

Figure 1.42: Final picture after message assignments

Figure 1.43: Mapping custom fields & existing standard fields

Figure 1.44: Saving changes

!!!CAUTION!!!: You should really be careful when performing post-exit mapping here. Kindly note that, the messages here are independent from each other. That means, you have to ensure that one particular entry in Message A and Message B should be matched to the exactly same entry in Message C. Especially in bulk data exchange scenarios, I notice there were some misalignments between messages for my custom fields. So we have to map our custom fields with custom functions in SAP CPI. Speaking of business partner replication for instance, we take Internal ID for entries in Message A and we always make sure we’re working with exactly same entry in Message C comparing Internal ID (Message A) and Id (Message C) as they should be identical. For this kind of custom functions in SAP CPI, you might ask for help from an integration expert who is familiar with CPI functions. Custom functions, as they require a certain level of expertise and detail, are out of scope for this blog and thus is not going to be covered in this blog.

3. Deploying standard integration flow and Post-Exit flow

Figure 1.45: Standard integration flow & Post-Exit flow

We configured our standard integration flow before and now we finished the configuration of our Post-Exit flow. We need to deploy them to see them in action. We first need to deploy standard integration flow “”Replicate Business Partner to SAP Marketing” and then our Post-Exit flow “”Replicate Business Partner to SAP Marketing Post-Exit” (Figure 1.46)

Figure 1.46: Deployment of standard integration flow & Post-Exit flow

4. Testing Standard Integration Flow and Post-Exit Flow

Once our standard integration flow and Post-Exit flow are deployed, we are ready to test them. Log in to your SAP Cloud for Customer system with your credentials and make a small change for your test customer. In our case, our custom field should be updated with S/4 HANA number (Figure 1.47)

Figure 1.47: Update of test customer in SAP Cloud for Sales

You can check the payload of this change in SAP C4C via “Web Service Message Monitor” and you can also check if there’s any error for that outbound message. We can confirm that our custom field (ZZMKTS4ID) gets the value “0020000452” in the corresponding payload (Figure 1.48)

Figure 1.48: Checking outgoing payload in SAP C4C via Web Service Message Monitor

We should see our standard integration flow and Post-Exit flow are triggered successfully in CPI (Figure 1.49)

Figure 1.47: Trigger of standard integration flow and post-exit flow

And for the last step, we can check if our mapped custom field in SAP Marketing (ZZ1_S4ID_ENH) gets the right value. We can do it by searching our test customer via “Inspect Contact” app in “Data Stewardship” section in our SAP Marketing system. We need to check the origin data for SAP C4C for our test customer(Figure 1.48)

Figure 1.48: Checking incoming SAP C4C origin data via Inspect Contact app

 

Summary

That’s it! You should be able to extend your integration flows for your custom integration scenarios. With this new functionality;

  • You don’t need to worry about later releases for your standard integration package as the standard integration flows always remain intact thus unmodified
  • Based on previous point, you don’t risk any update or bug fixes applied by SAP to standard integration content (standard integration flows)
  • All your extension activities are carried out in a separate custom integration flow so you have to work with less resources and less CPI elements (only one mapping actually)
  • You save a load of time without performing your extension activities over and over again because your Post-Exit flow will always be there after you upgrade to newer release for your integration package

Good luck with your extensions

Assigned Tags

      13 Comments
      You must be Logged on to comment or reply to a post.
      Author's profile photo MArcus Robst
      MArcus Robst

      Well written blog Hakan. Thanks for taking the time to do that!

      Author's profile photo Hakan Köse
      Hakan Köse
      Blog Post Author

      Hi Marcus,

       

      Thanks for the feedback! Appreciated.

      Let me know if any part requires more elaboration...

      Kind Regards,

      Hakan

      Author's profile photo Saurabh Kabra
      Saurabh Kabra

      Incredible way of explanation. Thank you so much Hakan Köse . I will wait now for your next blog.

       

      BR
      Saurabh

      Author's profile photo Hakan Köse
      Hakan Köse
      Blog Post Author

      Thanks Saurabh!

      It's always great to hear what your thoughts are about my content

      Best Regards,

      Hakan

      Author's profile photo Phani B Kalaga
      Phani B Kalaga

      Hi Hakan Köse and Saurabh Kabra ,

      Can you please tell me how to find these WSDL in SAP marketing on-premise system? We have added new custom field in our system and need to give the updated WSDL for SAP business partner replication integration.

      It would be great help if you can explain how to find these CUANBusinessImportPartner.wsdl in system.

      Thanks,

      Phani

      Author's profile photo Tobias Schneider
      Tobias Schneider

      Hi Hakan,

      great blog! Very good step by step explanation! 🙂

      Do you also already have any blog about the BAdI implementation to bring the data of your custom field into the contact as additional facet, that you wrote about in the first part of your article?

      BR Tobias

      Author's profile photo Christopher Linke
      Christopher Linke

      Hi Hakan Köse ,

      thanks a lot for this! What happens if the original iFlow gets updated, let's say there are fields added to the source and target structure. Because the message mapping in our Post Exit iFlow is static, it will not take those new fields into consideration and they get therefore lost. Am I right or do I miss something here?

      Thank you,

      Chris

      Author's profile photo Hakan Köse
      Hakan Köse
      Blog Post Author

      Hi Christopher Linke ,

      Thanks for the kind words.

      I know what you mean. You can always update those messages with new metadata. You need to repeat following sections:

      2.2. Getting Extended Metadata of C4C SOAP Service (Message A)
      2.3. Getting Standard Metadata of SAP Marketing OData Service (Message B)
      2.4. Getting Extended Metadata of SAP Marketing OData Service (Message C)

      After getting all of the metada files, just replace the messages with new ones. Existing mappings should be taken over and you can always map newly added fields if necessary.

      P.S: We've just upgraded our integration package to latest version. This is exactly what I'm going to do.

      I hope this helps

      Best Regards,

      Hakan Köse

      Author's profile photo Christopher Linke
      Christopher Linke

      Thank you Hakan! I will work on a solution that doesn't need those manual updates, maybe I will first extract all elements that need to be changed visa XLST, change them in the mapping and then replace them in the original message (message B in your case).

      Author's profile photo Hakan Köse
      Hakan Köse
      Blog Post Author

      Hi Christopher Linke ,

      Good. Personally, I just compare "Message B" in upgraded standard iFlow with "Message B" in Post-Exit. If there is no difference, I then check the endpoints of SOAP services and OData versions for Message A and Message C just to make sure.

      In my humble opinion, if there's no difference for Message B's, then it means there's no change for the standard iFlow mapping metadata which is fine for Post-Exit iFow.

      Author's profile photo Hakan Köse
      Hakan Köse
      Blog Post Author

      Dear community,

      I updated the blog with an important explanation like below for the section -> 2.5. Performing Post-Exit Mapping

      "!!!CAUTION!!!: You should really be careful when performing post-exit mapping here. Kindly note that, the messages here are independent from each other. That means, you have to ensure that one particular entry in Message A and Message B should be matched to the exactly same entry in Message C. Especially in bulk data exchange scenarios, I notice there were some misalignments between messages for my custom fields. So we have to map our custom fields with custom functions in SAP CPI. Speaking of business partner replication for instance, we take Internal ID for entries in Message A and we always make sure we're working with exactly same entry in Message C comparing Internal ID (Message A) and Id (Message C) as they should be identical. For this kind of custom functions in SAP CPI, you might ask for help from an integration expert who is familiar with CPI functions. Custom functions, as they require a certain level of expertise and detail, are out of scope for this blog and thus is not going to be covered in this blog."

      Best Regards,

      Hakan

      Author's profile photo Elio Centeno
      Elio Centeno

      Hola Hakan Köse

       

      I have already tried creating custom fields and making them visible so CPI can take them on integration

      But I understand or if it is possible for a standard field or attribute to be visible to in a specific API.

      For example when I am creating a custom attribute, in the ODATA Apis or SOAP Apis tab I can make the new attribute visible for integration.

      But when it is a standard attribute, where can it be enabled so that it is available for a specific API?

      For example: I want the field TITLE_FT, telephone, among others to be available for the API:

      https://myXXXXX-api.s4hana.ondemand.com/sap/opu/odata/sap/API_MKT_CONTACT_SRV;v=0003/

      Best regards

      Elio C

      Author's profile photo Hakan Köse
      Hakan Köse
      Blog Post Author

      Hello Elio Centeno ,

       

      Sorry for the late response. For availability of standard fields for OData API's, you can quickly check metadata information for related OData API. For instance, for API_MKT_CONTACT_SRV, you can check the XML file for the reponse to below request:

      https://myXXXXX-api.s4hana.ondemand.com/sap/opu/odata/sap/API_MKT_CONTACT_SRV;v=0003/$metadata

      If they are not included in metadata, then as per my knowledge all you can do is to submit an improvement request to ask for them to be part of the related OData API's. Unlike custom/extension fields, it's not possible to maintain SOAP & OData availability of standard fields in an app like Custom Fields & Logic

      Best Regards,

      Hakan Köse