Technical Articles
Extending standard integration flow to support Customer extensions – Part II
Introduction
This is a continuation of earlier blog Extending standard integration flow to support Customer extensions. In this blog let’s look at how to implement the exit points provided in the standard content with an example.
The example Integration Flow used is, Replicate Stock Location from SAP Business Suite from package SAP Cloud for Customer Integration with SAP ERP.
As mentioned in the previous blog, this is an IDOC to SOAP scenario. Because extending the IDOC structure will result in change of the root message element of the source interface, to support extensions both pre-exit and post-exit are required for this Integration Flow.
The standard Integration Flow uses message mapping ERP_COD_StockReplication to map the IDOC structure to SOAP Web service structure.
Source message : COD_STOCK_REPLICATE.COD_STOCK_REPLICATE01
Target message : StockLocationtReplicationRequest
Extending the source and target structures
For this blog I have added following extension fields to the source and target structure.
- In the Source (IDOC) message one element YHEADEXTF1 at the header level and
- two elements YITEMEXTF1 and YITEMEXTF2 at the item level.
Note: The IDOC COD_STOCK_REPLICATE01 is BAPI based IDOC, so extensions are created using Append structure and then IDOC is generated using BDFG. You can find more information about extending generated IDOC on this SCN blog.
Similarly in SAP Cloud for Customer two extension fields are added using KUT.
- ANHead at header level and
- TestAN at item level (for each product).
These extension fields are available in the WSDL for the corresponding service interface.
Note: in this case adding extension will not alter the root message (StockLocationtReplicationRequest) name.
Defining Exit Integration Flows
Note: From 1908 release pre-exits are no longer needed for IDOC to SOAP scenarios for new delivered integration Flows. 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.
Since we have all the prerequisites ready, now let’s see how to implement the exits.
As mentioned in the earlier blog, pre-exit is required where the source structure is different from what the standard mapping expects.
In this case the source IDOC message after adding the extension element is YANCOD_STOCK_REPLICATE .YANCOD_STOCK_REPLICATE01, where as the standard mapping can only work with message COD_STOCK_REPLICATE.COD_STOCK_REPLICATE01.
So in the pre-exit we need to map the extended IDOC message structure to standard message structure. We will define a Pre-exit Integration Flow as shown below and it will have
- A sender adapter (process direct) and
- A message mapping step.
The important point to note here is process direct adapter for the exit Integration Flow must run at the exact address expected by the standard Integration Flow. As an example if the standard Integration Flow expects the pre-process Integration Flow to run at an endpoint as shown below,
Then in the process direct sender adapter must be configured to run at the same endpoint.
In the mapping step we need to map our extended IDOC structure to standard IDOC structure.
The report SRT_IDOC_WSDL_NS can used to download the extended IDOC structure from Business suite system.
The mapping is simple 1:1 mapping where we map all the fields from extended IDOC message to Standard IDOC message structure. The Map Selected fields and sub-tree with identical names button can be used for 1:1 mapping as shown below.
Now similarly create an Integration Flow for Post-exit processing, with one sender (process direct) adapter and one mapping step.
For the post exit the mapping is a n:1 mapping. The source message is a bundle of 2 messages,
- Message 1: is the original source payload, which is in this case the extended IDOC and
- Message 2: is output of standard mapping.
The target message is the message structure with extension fields, from the SAP Cloud for Customer system.
The WSDL can be downloaded from the relevant communication arrangement in SAP Cloud for Customer.
Here as a first step map the second message (output of standard mapping) to target message. Again the Map Selected fields and sub-tree with identical names button can be used for 1:1 mapping. This will make sure all the output of standard mapping is populated in the target structure as is.
Next, map the extension fields from the extended IDOC (first message of source) to extension fields on target structure as needed.
As mentioned earlier process direct adapter for the exit Integration Flow must run at the exact address expected by the standard iFlow.
Deploy the exit Integration Flows and main Integration Flow.
For main Integration Flow make sure to set the isExtensionEnabled flag to true. This will enable the main Integration Flow to look for exits. The default value is false and will not call exits, used for standard scenario without extensions.
Monitoring
Now if we trigger a message for this scenario, we should see 3 Integration Flows in the message monitor.
The main Integration Flow and the exit Integration Flows are linked via the Application Message ID. i.e. all the 3 Integration Flows can be searched using the IDOC number in this case, as the main iFlow stores the IDOC number as the application ID (SAP_ApplicationID).
Note: all standard mappings use IDOC without namespace. Since the IDOC downloaded using report SRT_IDOC_WSDL_NS, is qualified by namespace, it is required to remove the namespaces before it can be used in the post exit mapping. This is only applicable for scenarios where IDOC structure is the target message, i.e. messages are being sent to Business suite system using IDOC adapter. You can check this blog for adjusting the IDOC with namespaces.
Some other points:
- The end point address for post and pre exits in standard Integration Flow are configurable
- The standard source and target messages are a part of the pre-delivered Integration Flows and can be used in the exit Integration Flows.
Conclusion
In this blog we looked at how to implement the exit points provided in standard Integration Flow. In the next blog I will explain how the standard Integration Flow has been modeled to support extensions and will explain output of various steps, so that it can be easier to find out what is going on in case of any issues in the message processing.
Hello Abinash
Thanks for this wonderful blog which is very helpul.Just a question about the iflow from C4C to CRM.For eg Business partner replication from CRM to C4C, here we have z fields in CRM and have created corresponding KUT fields in C4C and as per your blog we have enhanced the iflow.But what about the iflow from C4C to CRM having the same KUT fields and Z fields in CRM .This is C4C to CRM Customer Replication iflow don’t have any pre or post exit things.In that case how to enhance this iflow without modifying the original one (SOAP to IDOC scenario)Latest version of iflow
Hi Ketan,
I will enable the exits and it should be available with 1911 release. We are enabling extensions on a phased manner and that's why not all iFlows are exit enabled as of now.
Best regards, Abinash
Hello Abinash,
this is an very interesting and helpful blog. I would have two questions concerning the pre-exit topic.
You mentioned that from release 1908 pre-exits are no longer needed for IDOC to SOAP scenarios. I want to use scenario "Replicate Sales Order and Sales Quote from SAP Business Suite" release 1908. This scenario contains an Pre-Exit and an Post-Exit. I would only need the post-exit, but if I activate the "Extension Implemented" parameter in the configuration of the Iflow and no pre-exit is available, the message "No consumers available on endpoint" appears, which makes sense for me. Is there another possibility the just deactivate the Pre-Exit?
So that I can use the post-exit, I implemented the Iflow for the pre-exit with the simple mapping you
mentioned in this block. The pre-exit flow is called from the original, but it seems that no data
is returned to the original ifow. In the last step of the pre-exit I can still see the original content,
but in the calling iflow I only see a soap envelope tag with the tags <IdocAssign>, <TransferId>,
<DbId>, enclosed by the tag <COD_REPLICATE_SALES_ORDER02Response>.
What could be wrong in this case?
Thanks and best regards,
Christian
Hello Christian,
<DbId>, enclosed by the tag <COD_REPLICATE_SALES_ORDER02Response>" - I assume you have mapped the response structure instead of request structure from IDOC WSDL.
Nevertheless I can provide a patch for this iFlow so that you can skip the pre-processing iFlow. For this please provide the iFlow package name and the iFlow technical ID. Also please create an incident in the component LOD-CRM-INT-ERP/LOD-CRM-INT-S4H and mention to assign it to me from development team.
Best regards, Abinash
Hello Abinash,
thank you for your quick reply.
We are using the package C4C integration with S/4HANA.
Regarding my mapping in the Pre-Exit, I took the WSDL from the standard Iflow that is applied after the Pre-Exit and used it as source and target in my Pre-Exit IFlow. But as I mentioned in my previous post, I only got a few tags back.
Since the pre-exit does not work in my case, I would accept your suggestion for a patch and create an incident.
Thanks and best regards,
Christian
Hello Christian,
Please create the incident in LOD-CRM-INT-S4H component for S/4 package and mention to assign it to me.
Best regards, Abinash
The updated iFlow is now available in API hub. The latest version does not need the pre-exit iFlow.
https://api.sap.com/integrationflow/com.sap.scenarios.s42c4c.salesorder.replicate
P.S. - The earlier version had a bug, where the link from pre-exit to main iFlow was missing.
Best regards, Abinash
Hi Abinash Nanda ,
I am new to CPI and trying to understand how to extend standard Iflows.
I copied the same package and trying to use same Iflow (Stock Location).
However, when I am trying to edit Iflow to add pre and post exit IFlows I am getting below error -->
"If you edit the artifact, it will not receive any further updates. Would you like to proceed?"
What wrong I am doing here?
Please help to understand it.
BR,
Rashmi
Hello Rashmi,
You should not edit the standard iFlow, it should only be configured. Create your exit iFlows and deploy them and make sure the path for the exit iFlows match to what you have configured in the standard iFlow.
Best regards, Abinash
Hi Abinash Nanda ,
If I click on configure, I can see only sender and receiver tabs.
I am wondering how did you add Router --> Pre and Post Exit (Local IFlows) here without editing it.
So from your above reply what I understood is, first I see to create separate pre exit then another Iflow post exit....
Now deploy them...
Can you please elaborate more on this --> "make sure the path for the exit iFlows match to what you have configured in the standard iFlow."
BR,
Rashmi
Please confirm if I am following same package and iflow as you have demonstrated above.
Package –>
SAP Cloud for Customer Integration with SAP ERP
IFlow –>
Replicate Stock Location from SAP Business Suite
Version -->
BR,
Rashmi
HI Abinash,
what happens if we have an Exit implemented and the structure (source/target) changes with an upgrade. Do we have to update the Exit as well (with the newest WSDL)? My concern is that we would loose those fields because they are not part of the mapping in the post exit iFlow.
Thanks,
Chris
Hello Chris,
Are you referring to SAP supplied fields or Custom fields? Standard fields are almost never removed or edited from an interface. An interface usually only gets new fields but existing elements are never changed to make sure back award compatibility.
So I don't understand the statement "My concern is that we would loose those fields because they are not part of the mapping in the post exit iFlow"
Best regards, Abinash
Hello Abinash Nanda
thank you very much for your quick response. I'm sorry for my poor explanation, let me try to visualize it. We see an SAP iFlow in version 1.3 and version 1.4. We built our Post Exit in 1.3. with the given WSDL/Message mapping. Version 1.4 adds an additional field "Field4" (source and target), but because our Post Exit uses the "old" mapping, this fields will not be transfered to the target system (without the post exit it would). Am I right?
Hello Chris,
Ok now I understand your concern, yes in this case you need to update the WSDL in the exit iFlow if you are using a message mapping to populate the extension fields
Best regards, Abinash