Extending standard integration flow to support Customer extensions – Part III

In this blog let’s take a closer look at the various steps inside an Integration Flow (iFlow) that supports extension and purpose of each. The idea is to get an understanding of all the steps in the delivered content so that it becomes easier in case of a debugging is required or one can develop an iFlow to support extensions on similar lines.

I am using the iFlow Replicate Registered Products from SAP Business Suite from the integration package, SAP Cloud for Customer Integration with SAP ERP, for this blog.

This Integration Flow has the following steps:-

Steps in Main integration process:

1. Content modifier step (Set Application ID) –
   1. Used to store the IDOC number for monitoring
   2. An external parameter (Extension Implemented) to check if extension is required. The default value is false, means no extension implemented.
   3. A local variable to store the incoming payload, which will be used to later to create the needed payload for post processing exit.
2. Filter step (Filter IDOC) – which filters the incoming IDOC, this is required incase IDOC has been extended by customer where the IDOC message type either has an extension or IDOC basic type is in customer namespace (as is the case when generated IDOCs are extended as explained in the blog Extending Generated IDOC)
3. Content modifier step (Prepare Mapping Input) – Where the message payload is prepared for the main mapping
4. Main Mapping step
5. Router (Extended?) – Based on the external parameter value, Extension Implemented, from step 1, either sends the message to target system (Step 7), which is also the default behavior or routes it to a local integration (Step 6) process to call the exit iFlow.
6. Process call (Post Processing) – Calls the Local integration process (Step 8)
7. End Message – Send payload to receiver system

Steps in Local integration process:

1. Local Integration Process (Local Integration Process_Post_Processing) – has a series of steps to handle extension as mentioned below
2. Filter (Filter Mapping output) – Removes the XML declaration that was added by the main mapping
3. Content Modifier (Bundle Message) – Prepares the message by combining the message from filter step and the original payload stored in the local variable in step 1.
4. Request Reply (Call Exit) – Extension iFlow is called
5. Filter (Prepare Final Message) – Removes the outer elements added by the extension exit because of multi mapping (n:1).

Additionally, the required namespace mappings are defined under the Integration Flow -> Runtime Configuration.

Case 1 : (Standard Flow)

First iFlow is executed with Extension Implemented parameter set to false (default setting), which means exit iFlow will not be called.

Now let’s look at the trace for few of the steps to understand what is going on

Step: Set Application ID – The IDOC number is stored for monitoring

And we can see the external parameter is set to false and the original payload is stored in a property variable.

Take a note of the IDOC type name (ZZSCN_COD_EQUIPMENT_SAVE01), which is in customer namespace as the original IDOC has been extended.

Step: Filter IDOC – The IDOC type is filtered out from the payload with the XPATH expression, //IDOC. This is needed as standard mapping expects the root message type to be COD_EQUIPMENT_SAVE01 not ZZSCN_COD_EQUIPMENT_SAVE01.

Step: Prepare Mapping Input – Here we add the standard IDOC message type to the payload as needed by standard mapping to execute correctly.

Step: Standard Mapping – The Output of standard mapping. Here note the XML declaration that has been added by the main mapping.

Then as shown in the main flow the output of the mapping is directly passed to the receiver from the router step as the external parameter is set to false.

Case 2 : (Extension Flow)

Next we set external parameter (Extension Implemented) to true and examine the message flow.

As shown below, this time the router calls the local integration process, which in turn calls the exit iFlow.

Let’s have a quick look at the exchange properties and see the value for parameter Extension Implemented

Now let’s look at the steps inside the local integration process.

Step: Filter Mapping output – Removes the XML declaration that was added by standard mapping. It uses an XPATH expression to filter “/p1:RegisteredProductBulkReplicationRequest”.

Note: The namespace mapping is defined at the iFlow -> Runtime configuration as mentioned earlier.

Step: Bundle Message – This combines the output of the previous step and the original payload stored in exchange property to create the needed payload for exit call.

For ease of viewing I have downloaded the payload and opened it in a browser.

It also adds the required namespaces <ns1:Messages xmlns:ns1=”http://sap.com/xi/XI/SplitAndMerge”>, to the combined payload.

Step: Prepare Final Message – The output from exit has XML declaration and other namespaces as shown below.

The Prepare Final Message step, removes the XML declaration and the multimapping message element by using an XPATH expression “/p2:Messages/p2:Message1/p1:RegisteredProductBulkReplicationRequest“, as filter.

The output of this filter step is as below, which is delivered to the target system.

Note: From 1908 release pre-exits are no longer needed for IDOC to SOAP scenarios. So, one needs to just implement the one exit to map the extension fields. With this approach the no of calls inside the CPI tenant can be reduced significantly for high volume scenarios.

With this we conclude this blog series.

Happy Learning!!!