How to extend your SAP Marketing Integrations with Post-Exits in SAP Cloud Platform Integration (Part-1)
In this blog, we’re going to learn how to extend SAP Marketing integration flows by using post-exits.
It’s quite common that you require custom (extension) fields (specific information regarding your business needs) in your integration landspace, so you might end up extending metadata of your integration services, thus corresponding integration flows . However, at the same time, you obviously don’t want to miss or risk SAP’s new capabilities and bug fixes coming with upgrades while you’re trying to extend your integration flows.
Untill last year, you wouldn’t get any updates to your integration flows if you explicitly edited and extended them. If you wanted to upgrade your those modified integration flows to a newer release anyway, you would have to start with a new copy of standard integration package again and perform all your extension activities (extended sources, extended mappings etc) from scratch because there was no automation or migration supported. And these activities are very time-consuming and more importantly prone to the mistakes (Not to mention all those integration tests you have to do all over again)
Last year, pre-exits and post-exits in integration flows were featured and these new exits allow you to extend your integration flows without touching standard ones by SAP. This means, pre-delivered standard integration flows remian intact as you’re extending them. And this obviously means you don’t need to worry about the upgrades and perform your extension activities over and over again anymore
Figure 1.0: Pre-Exit and Post-Exit Concept for Standart Integration Flows
A typical standard integration flow looks like following figure
Figure 1.1: Standard Integration Flow
While this standard integration flow figure has both pre-exit and post-exit, we’re going to focus on post-exit concept because almost all SAP Marketing integration flows have only post-exits (Honestly, I think pre-exits are redundant if you have a content modifier that stores original payload but the discussion might lead to another post, so I leave it here).
If you pay a close attention to the Figure 1.1, you may figure out the ultimate purpose: Those two process calls in standard integration flow refer to separate integration flows (Exit Flows) in which we have our extended sources (our extended integration service metadata including our custom fields) and have our own mappings (where we also map our custom fields). After our extended mappings are performed, the flow goes back to original path in standard integration flow where it leaves off and completes the integration process. The whole extension activities are done in separate Exit Flows whereas standard integration flows remain intact.
Since Exit Flows have only our extended mapping, it has a really simple and straight forward process design like the following figure
Figure 1.2: Exit Flow
As I mentioned earlier, we’re going to focus on an example of SAP Marketing integration flow which have only post-exit in this blog. However, if you want to get more details about pre and post exit concept, I highly recommend you read SAP help documentations about Integration Flow Extension
Let’s assume we have SAP Marketing system integrated with SAP Cloud for Sales and SAP Cloud for Sales is also integrated with SAP S/4 HANA. We’re trying to retrieve S/4 HANA numbers along with C4C internal numbers for a consistent business partner replication with Cloud for Sales.
Our C4C colleagues inform us they store S/4 HANA number in a separate custom field (ZZMKTS4ID) securely. We, as Marketing team, decide it would be much easier to map that custom field with one of our custom fields (ZZ1_S4ID_ENH). We then add this number as an additional facet with a help of BAdI implementation in SAP Marketing.
We need to extend SOAP service in Cloud for Sales and we need to extend our OData service in SAP Marketing so that they include our custom fields. Eventually we need to extend our responsible integration flow and map our custom fields.
For this scenario, we’re going to use standard integration package “SAP Cloud for Customer Integration with SAP Marketing” in SAP Cloud Platform Integration. And we’re going to extend the integration flow “Replicate Business Partner to SAP Marketing”. This integration flow has a process flow like the following. You’ll notice that it has only a post-exit (Figure 1.3)
Figure 1.3: Replicate Business Partner to SAP Marketing standard integration flow
If we want to translate this standard integration flow into a simpler figure, we would have something similar to below figure
Figure 1.4: Standard integration flows with only post-exit
Since I’m going to use the same notations in Figure 1.4 for the configuration activities in this blog, let’s have a precise understanding on what each of them means:
Message A: This message represents the original (extended) payload coming from source system. In our scenario, source system (Sernder) is C4C. So this message should have the extended metadata of SOAP service BusinessPartnerReplicationSelfInitiatedOut. This means the message includes our custom field that stores S/4 HANA business partner number (ZZMKTS4ID)
Message B: This message represents the outcome of standard mapping operation in standard integration flow.
The Message B would be the message that’s to be delivered to receiver (SAP Marketing) if we leave the standard integration flow as it is (without extension). So it’s just standard metadata of OData service of SAP Marketing (CUAN_BUSINESS_PARTNER_IMP_SRV)
Message A, B: This message is the combination of Messages A and B. Remember that Message B represents the mapped message (standard metadata of OData service in SAP Marketing) after standard mapping operation in standard integration flow. That means it holds only mapped standard fields. On the other hand, Message A additionally holds unmapped standard fields as well as custom fields as it represents the original message (payload) from C4C.
This combination grants us a great flexibility and extensibility options and enables us to map our custom fields in addition to mapped or unmapped standard fields. We really have the possibility to shape our own mapped message the way we want it to be.
Message C: There’s only one missing message that we need before we can get down on our extension activities. And that is the extended metadata of OData service in SAP Marketing (CUAN_BUSINESS_PARTNER_IMP_SRV). This extended metadata should include our custom field (ZZ1_S4ID_ENH) in SAP Marketing. And this is exactly what our Message C is going to be like. In other words, you could roughly say Message C is going to be some sort of an extended version of Message B.
We shape Message C with our own mapping operation (Post-Exit Mapping in the figure 1.4) where we also map our custom fields in post-exit integration flow. Consequently, this message is basically 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.
Now, we grasped the meaning of the notations and we’re ready to perform our configuration activities step by step in next part.
Amazing blog . Pictorical representation makes it even easier for the readers to understand the concept . Thanks for taking the time to do that!