Multi-mapping with Dynamic Configuration - SOAP loopback approach

They say "you can't have your cake and eat it."

They also say you cannot use dynamic configuration with multi-mapping.

But what if you could...

Introduction

In this article, I will demonstrate an approach to overcome one of the most common limitation of multi-mapping, which is the usage of dynamic configuration.

As each child message of a multi-mapping split shares the same dynamic configuration header during the mapping step, it is not possible to have different values (for a particular namespace attribute) assigned during mapping for each child message. One common scenario that requires such functionality is when a source message needs to be split into multiple files, and each target file needs to be dynamically named.

This approach is named the SOAP loopback approach, and has the following benefits:-

• Minimal coding required, i.e. no custom adapter module development
• Utilize standard features of PI for design and configuration
• No additional file system space required for placing temporary intermediate files

Approach

The key concepts to achieve this approach are:

• Intermediate structure with additional placeholder field to store value of dynamic configuration
• Loopback from receiver of iFlow1 to sender of iFlow 2 via SOAP adapter

Below are the flow diagrams of the two iFlow scenarios.

Following are the steps for the design and configuration of this approach.

Design

Data Type

Here is an example of the data type. The source contains a segment with multiple occurrences, while the target has only single occurrence (for each order.) An additional intermediate structure is defined that is exactly the same as the original target structure but with an additional placeholder field for dynamic configuration.

Structure	Definition
Source
Target
Intermediate Target

Service Interface

The sender and receiver interfaces are defined. Additionally, an abstract interface based on the intermediate structure is defined. This abstract interface will be used as the receiver of the first iFlow and also the sender of the second iFlow. The associated Message Types are also created.

Message Mapping

Message mappings are created for the two iFlow scenarios. Important thing to note here is that the first iFlow mapping is a 1-n multi-mapping, while the second iFlow mapping is a normal 1-1 mapping.

For the first mapping, the source is mapped to the intermediate structure. Additionally, the filename is dynamically constructed based on source fields, and mapped to the placeholder field in the intermediate structure.

For the second mapping, all the fields are mapped 1-1 from the intermediate structure to the final target structure. Additionally, the value in the placeholder field of the intermediate structure is used in a UDF mapping to set the dynamic configuration value. This can be mapped to a variable or to any arbitrary field with occurrence = 1.

Operation Mapping

The operation mappings are similar to the message mapping for the two iFlow scenarios.

Configuration

Systems and Communication Channel

For the configuration steps, we will need to configure 2 iFlows. Therefore there will be 2 sender systems and 2 receiver systems. For simplicity sake, we will reuse the same sender and receiver system, so in this example, it will only be BC1 and BC2. Alternatively, the receiver in the first iFlow and the sender of the second iFlow can be any arbitrary system or virtual component.

iFlow

We will configure the iFlow for the second scenario first, as the SOAP endpoint URL generated from the second scenario will be needed in the first scenario.

iFlow 2

The second iFlow will be used for processing the individual child messages to the final target. The main things to take note during configuration here are:

• Sender SOAP channel used for loopback is set to QOS Exactly Once to ensure async processing
• ASMA needs to be set for the receiver SFTP channel

Once iFlow 2 is completed, we need to get the SOAP endpoint for the iFlow. Follow the steps in Generating WSDL in IFLOW in SAP PO 7.4 to switch the perspective and Copy the endpoint.

iFlow 1

Now we are ready to configure the first iFlow that performs the multi-mapping to the intermediate structure. The main thing to note here is the configuration of the receiver SOAP channel for loopback.

Using the value of the endpoint from iFlow 2, enter this into the SOAP receiver channel's target URL - the hostname can be changed to localhost. Enter a messaging service user with sufficient credentials for the SOAP channel, typically it will be PIAPPL<SID>.

Testing Results

Here are the results from testing of the design.

A test message with two orders in the source XML is sent via the testing functionality

iFlow 1

In the payload after mapping of iFlow 1, we can see two child messages with the dynamically constructed filenames in the placeholder field.

The log also shows the child messages created from the split.

The log for the child message shows that the message is sent to the endpoint URL of the second iFlow.

iFlow 2

Next we can view the payload and logs of the child messages in the second iFlow. From the logs we can see that the child message has been transformed to the final target structure, and the filename is stored in the dynamic configuration attribute, which is finally used during processing by the SFTP receiver channel.

First child message

Second child message

Finally, we see in the target folder, the two files created for two child messages with dynamically constructed filenames.

Conclusion

Voila! There we go, "having our cake and eating it"

With this no-hassle approach, another common hurdle in the PI world can now be easily overcome.