Skip to Content
Technical Articles

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!!!

6 Comments
You must be Logged on to comment or reply to a post.
  • Hi Abhinash ,

    So as SAP has added Filter+ContentModifer to remove the extended IDOC root tag, does this mean we no longer need Pre-Exit flow for any of the scenarios?

    Thanks,

    Manoj

    • Hi Manoj, Pre-exits are not needed only for iFlows which were updated to version 2.0, with 1908 onwards. Integration flows which were delivered prior, still need the pre-exits for IDOC to SOAP scenarios.

      Best regards, Abinash

  • Hi Abinash,

    We are integration S4HANA system with SAP Commerce Cloud and currently working on the “Replicate Material From S4HANA To SAP Commerce Cloud” Scenario.

    There are few custom fields which we need to transfer to Commerce system, these fields are already available in the MATMAS IDOC(at source) but ODATA service will be enhanced with the additional fields in Commerce system.

    I have understood that we can use the Post-exit flow to map the additional fields but we are stuck with the ODATA adapter as there is no option to update the fields section.

    Can you please help us understand how we can use post-exit iflow to extend the mapping fields if we have ODATA adapter at the receiver end?

     

    Regards

    Vishal J

     

    • Hi Vishal,

       

      The fields that you see in the receiver channel are for design time, to create the XSD structure that can be used inside the iFlow example in mapping. During runtime you can pass extra fields as long as ODATA metadata has those extra fields it should work fine.

       

      To sum it up, in your exit iFlow using the ODATA modeller (you can use the ODATA receiver adapter just to create the XSD and delete it afterwards) select the extra fields along with the fields already available in the standard, map them and pass it back to main iFlow. That should work.

      Best regards, Abinash

       

      • Hi Abinash,

        I tried with the approach you mentioned above, but I am getting below error.

        As it says OSCI issue, I tried to change the URL as per OSS note: 2521399 – OData Exception: OSCI issue in HCI. But this resulted in 404 Not Found Error.

        To debug further, I copied the standard flow and rebuilt the query with the EDMX file to match the fields which I have to use but still, it didn’t work.

        Then I removed the ODATA receiver channel from Iflow and added it again with the same configuration and it worked fine.

        Just to reconfirm, I did this twice and interface worked only when I removed the adapter and added it again.

        Seems it is not able to fetch the metadata at runtime or there is an update in the ODATA adapter which is not ported to this Iflow.

        Can you help with this?

         

        Regards

        Vishal J

        /
        • Hello Vishal,

          I would advise to create an incident for the package so that someone from SAP can investigate.

          Without looking at the metadata and the payload it is difficult to pinpoint the exact issue.

           

          Best regards, Abinash