Skip to Content
Author's profile photo Eng Swee Yeoh

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…


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


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.


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 /wp-content/uploads/2015/01/dt_source_632874.png
Target /wp-content/uploads/2015/01/dt_target_632891.png
Intermediate Target /wp-content/uploads/2015/01/dt_int_632875.png

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.

Service Interface Category Type Associated Data Type
SI_O_A_Order_Source Outbound Async DT_Order_Source
SI_I_A_Order_Target Inbound Async DT_Order_Target
SI_A_A_Order_Target_Intermediate Abstract Async DT_Order_Target_Intermediate

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.

iFlow Source Message Source Occurrence Target Message Target Occurrence
First MT_Order_Source 1 MT_Order_Target_Intermediate Unbounded
Second MT_Order_Target_Intermediate 1 MT_Order_Target 1

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.

iFlow Source Interface Source Occurrence Target Interface Target Occurrence
First SI_O_A_Order_Source 1 SI_A_A_Order_Target_Intermediate Unbounded
Second SI_A_A_Order_Target_Intermediate 1 SI_I_A_Order_Target 1


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 Channel Associated System Direction Adapter Type
First CC_SOAP_S_XI_ProxySender BC1 Sender SOAP (XI3.0)
First CC_SOAP_R_LoopbackReceiver BC2 Receiver SOAP
Second CC_SOAP_S_LoopbackSender BC1 Sender SOAP
Second CC_SFTP_R_DemoOrder BC2 Receiver SFTP


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







Operation Mapping







BC1 SI_A_A_Order_Target_Intermediate CC_SOAP_S_LoopbackSender OM for iFlow 2 from design step BC2 SI_I_A_Order_Target CC_SFTP_R_DemoOrder


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.







Operation Mapping







BC1 SI_O_A_Order_Source CC_SOAP_S_XI_ProxySender OM for iFlow 1 from design step BC2 SI_A_A_Order_Target_Intermediate CC_SOAP_R_LoopbackReceiver


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 childmessage 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.



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.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Former Member
      Former Member

      Excellent blog Eng Swee

      Author's profile photo Arthur Silva
      Arthur Silva

      Great document Eng. Do you think possible to create a REST loopback? I have a requirement which consists in calling a REST service after a multi-mapping, and then forward to the receipt.

      Author's profile photo Sugata Majumder
      Sugata Majumder

      Excellent blog Eng Swee! Explained in detail with all the steps.
      Could you please let me know if this can be applied for Synchronous receivers as well? I am trying to build a scenario where the 2nd iFlow will have a Asunc sync bridge in the receiver channel and will trigger another iFlow 3 to send the response back. As we are using the Abstract out bound Async interface for the 2nd iFlow, can we map that to a target Sync interface?



      Sugata Bagchi Majumder