Technology Blogs by Members
Explore a vibrant mix of technical expertise, industry insights, and tech buzz in member blogs covering SAP products, technology, and events. Get in the mix!
cancel
Showing results for 
Search instead for 
Did you mean: 
engswee
Active Contributor

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.

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

Service InterfaceCategoryTypeAssociated Data Type
SI_O_A_Order_SourceOutboundAsyncDT_Order_Source
SI_I_A_Order_TargetInboundAsyncDT_Order_Target
SI_A_A_Order_Target_IntermediateAbstractAsyncDT_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.

iFlowSource MessageSource OccurrenceTarget MessageTarget Occurrence
FirstMT_Order_Source1MT_Order_Target_IntermediateUnbounded
SecondMT_Order_Target_Intermediate1MT_Order_Target1

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.

iFlowSource InterfaceSource OccurrenceTarget InterfaceTarget Occurrence
FirstSI_O_A_Order_Source1SI_A_A_Order_Target_IntermediateUnbounded
SecondSI_A_A_Order_Target_Intermediate1SI_I_A_Order_Target1

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.

iFlowChannelAssociated SystemDirectionAdapter Type
FirstCC_SOAP_S_XI_ProxySenderBC1SenderSOAP (XI3.0)
FirstCC_SOAP_R_LoopbackReceiverBC2ReceiverSOAP
SecondCC_SOAP_S_LoopbackSenderBC1SenderSOAP
SecondCC_SFTP_R_DemoOrderBC2ReceiverSFTP

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

Sender

System

Sender

Interface

Sender

Channel

Operation Mapping

Receiver

System

Receiver

Interface

Receiver

Channel

BC1SI_A_A_Order_Target_IntermediateCC_SOAP_S_LoopbackSenderOM for iFlow 2 from design stepBC2SI_I_A_Order_TargetCC_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.

Sender

System

Sender

Interface

Sender

Channel

Operation Mapping

Receiver

System

Receiver

Interface

Receiver

Channel

BC1SI_O_A_Order_SourceCC_SOAP_S_XI_ProxySenderOM for iFlow 1 from design stepBC2SI_A_A_Order_Target_IntermediateCC_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.

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.

3 Comments
Labels in this area