N:1 & N:M mappings not possible without BPM... Any more !!!!!!!!!!

[former_member181985]

The concept of this blog is originated from my new idea (https://cw.sdn.sap.com/cw/ideas/9473) posted on SDN idea place, which is basically to facilitate mapping provision for incoming attachments at interface/operation mapping level.

The fundamental obstacle in SAP XI/PI classical configuration is that it can not collect messages, which means that a sender agreement/receiver determination can have only one sender interface technically. Due to this fundamental restriction, n:1 and n:m transformations are not possible in classical configuration. To avoid this restriction, we might have to think and effectively use some alternate ways/techniques/features which are already available in SAP XI/PI and source systems.

With a little trick, now we can implement n:1 and n:m mappings without using BPM, but in an indirect way. The basic assumption here is that the sender adapter/sender system has to collect multiple messages pertaining to various source systems in the form of payload and attachments. How...? Below are few cases.

1. An ABAP/Java client proxy should collect messages from various systems as is, to include them as proxy attachments.
2. We can effectively use File sender adapter option “Specifying Additional Files” to receive multiple messages from various source systems. Assumption is that, the payload message has to be in place only when all other systems files are in place.
3. A web service client system should collect messages from various source systems.

With the above approach we can have one technical message for different source systems. Now the below steps should be used in SAP PI (>= PI7.1 version)

In Integration Repository/ESR,

1. Define/import service interfaces and their corresponding message types and data types for source and target systems.
2. As usual, define multi-mapping (graphical message mapping) which does transformation between source and target message types which is required by target systems.
3. Define operation mapping with source and target service interfaces which involve n:m/n:1 mappings.
4. Before assigning the above message mapping defined in step - ii, we should have a java mapping with below functionality.       

         Java Mapping Functionality

1. The java mapping should read the incoming payload and attachments and then form a multi-message as expected step-ii graphical message mapping

                         <?xml version="1.0" encoding="UTF-8"?>

                         <ns0:Messages xmlns:ns0="http://sap.com/xi/XI/SplitAndMerge">

                              <ns0:Message1>Source1 as PayloadData</ns0:Message1>

                              <ns0:Message2>source2 Data using correct input attachment</ns0:Message2>

                              <ns0:Message3>source3 Data using correct input attachment</ns0:Message3>

                              <ns0:Message4>source4 Data using correct input attachment</ns0:Message4>

                         </ns0:Messages>

1. The java mapping can have extra functionality such as logging, error handling and removing attachments if they are not at all required by the target systems.

In Integration Directory, steps are normal as required by one sender and multiple receivers with enhanced interface determination ensuring it uses correct multi-map defined in repository. That’s all.

How about PI7.0 and lower versions? The corresponding versions mapping API’s doesn’t support attachment handling during mapping pipe line step. One solution is, to create custom adapter module (file adapter, case B) which can form the multi message with same logic as explained in IV- a & b, but however using adapter module API.

I see one more issue in PI7.0 and lower versions configuration. The interface determination does not show the multi-map interface mapping (which involves multiple source interfaces) define in repository. The trick is to change the interface mapping definition to one source and multiple target interfaces in IR with activation and then come back to configuration interface determination which allows you to select interface mapping. After activating ID contents go back to repository and change the definition of interface mapping i.e., multiple source and target interfaces.

Hope this new concept helps in building interfaces without BPM which will eventually lead to better system performance and easy monitoring.