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.

1. In the Source (IDOC) message one element YHEADEXTF1 at the header level and
2. 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.

1. ANHead at header level and
2. 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

1. A sender adapter (process direct) and
2. 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,

1. Message 1: is the original source payload, which is in this case the extended IDOC and
2. 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:

1. The end point address for post and pre exits in standard Integration Flow are configurable
2. 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.