Skip to Content

Pipeline Approach in SAP XI Implementations.

Problem Statement:


It is often observed with migration projects to XI that we often end-up developing similar map again and again with very little variations.


Sometimes, redundant implementation of certain interfaces is needed to fulfill customer needs. Those needs in reality are just a small diffraction with the standard implementations.


This blog will explain you the effective way to implement SAP XI in large-scale organizations where this is a common problem.


Solution Implemented:


Let’s know the example landscape structure and the need of the solution.


Previous Landscape Structure:


Recently we came across a situation where we wanted to phase out other EAI packages and develop XI based interfaces for our customer. .


We were having huge number interfaces both inbound and outbound developed per site or business unit (country specific requirements) and some special customer specific mappings. More or less the mapping was same, except some segment occurrence conditions or addition of some special segments. It is observed that maps are more or less same with very slight changes to accommodate different requirements.




We wanted to organize newer development in proper manner to reduce development cost, operational cost, reliability and effective maintenance. Also it is quite common to  add or remove the sites/partner  in real life business. So it was necessary to give a solution in such a way that, it will not affect the architecture in future. We call this as  “Loosely Coupled Architecture”.




To implement our business need into reality, we decided to follow the pipeline approach. This pipeline approach is different than XI pipeline. This pipeline approach is based upon three different mappings and sequential use of them in a specific order to serve the purpose.


Those three mappings are named as Master Mapping, Value Change Mapping and Variant Mapping.


Now we will discuss each of these three mappings in a bit detail.


  1. Analysis of current scenario/mappings in current EAI technology & creation of master mapping.


We started analyzing the current mappings developed for particular site and customers. After completion of detailed analysis, we created a template specification based upon common mapping rules implemented in each particular interface.


For those common rules, we implemented most generic form of mapping and named it as a “Master Mapping”




  1. Value change mappings & use of XI tables:


During our detailed analysis we found that there are some mappings that only differs in the qualifiers or the segment values. All the fields mapped & Segments are exists as like Master Mapping.


To solve this issue, first we created a table in SAP XI with certain unique fields. These unique fields formed the primary key. We populated this table with the values that map needs and extracted them at the run time based upon combination of primary key.


In message mapping we created a UDF, which sets up the connection with SAP XI and extracts the values.


The function definition is as follows.


Name: GetXITableValue


Input Parameters:


            SenderID                  // Name of Sender System

            ReceiverID               // Name of Receiver System

            InterfaceName         // Interface Name like Invoice or Orders

            FieldName               // Field Name for which you want to extract the value


These four fields formed primary key in SAP XI table. If you want to use more values to form the primary key then you can use them.


Output Parameters:


            Multiple Values.



These multiple values then stored in a container variable and used whenever needed in the mapping.


With this second step we able to solve, the issue of mappings that have same structure in the output, but only differs in the conditions/qualifiers or values from the basic master mapping.


  1. Content Change Mappings (Variant Mappings):


The final subpart of this pipeline approach is of course dealing with the mappings that differ in the structure with the standard or Master Mapping.


To solve this issue we created variant mappings as on need basis for the sites or special customers. We truncated the segments that are not needed by the particular customers.


This approach reduced development effort tremendously and thus offered huge saving for us as well as for customer.





               During the implementation of master variant pipeline approach, we came across one big difficulty. The problem was, some customers wanted some special and specific mappings that others don’t want, i.e. a structural difference with master map.


                Once any input payload comes into the XI and enters in this pipeline approach, we cannot go back to fetch the extra data when needed. So even if, one or couple of cases needs special mappings then also we included them in master mapping specs.


                This was an extra data for the others & if they did not want that then we followed variant mapping concept in case of others as well.


XI Integration Repository Structure:


Message Mapping:


  1. One Master Map per interface
  2. One Value change map per interface
  3. Multiple Content change maps as on need basis             


Interface Mapping:


  1. One interface mapping that contains combination of Master and value change mappings. (Order is based upon the nature of interface i.e. Inbound or Outbound)
  2. One interface mapping per special case in which variant mapping is included.




XI Integration Directory Structure:


Conditional Interface Determination is used that selects the appropriate interface mapping based upon the condition (i.e. Receiver partner number) and then it will route to proper pipeline of multiple message mappings and create the correct output.




Message Mapping:


  1. Consider the outbound scenario where Sender Party is A and Receiver Parties are X, Y & Z.
  2. Now X & Y have same structure of segments except some changes in the values and they don’t care extra values coming in. Where as Party Z wants some segments to be removed before they are coming in.
  3. First we created Master Map, which will be used by all of three X, Y, and Z.
  4. Then we created Value Change Map in which we fetched the values from XI Table and populated in mapping. This is also used by all of three.
  5. For X & Y this will end the mapping step. But for Z we have to truncate the structure. For that we created one more mapping and truncated not needed segments.


      Interface Mapping:


  • 1. We created two interface mappings, say P & Q respectively. One for parties X & Y and one for party Z
  • 2. For parties X & Y, the sequence of Message Mappings in the Interface Mapping (P) will be Master Map à Value Change Map
  • 3. For Party Z, the sequence of Message Mappings in the Interface Mapping (Q) will be Master Map à Value Change Map à Variant Map.





Interface Determination in XI Integration Directory:


  1. We will create conditional interface determination. For parties X & Y, based upon condition we will select Interface Determination ‘P’ and for party Z, based upon condition we will select Interface Determination ‘Q’



For Inbound scenario the sequence of message mappings in interface mapping will be reversed.





This approach is nothing but the use of multiple message mappings inside an Interface mapping and RFC lookup from UDF to access the ABAP tables.


Following are the references used to create this blog.




Shripad Joshi

You must be Logged on to comment or reply to a post.
  • good idea!!!

    but one question.
    what about the performance?
    Executing 2 message mappings in sequence will lead to loading of xml twice.


  • Shripad

    What we miss is the reusable quotient from this exercise..I think Ur master map would be reusable in a future upgrade/migration.but if the customer is looking not to save development effort and is more concerned on Performance, the approach goes out of the window..Its a good perspective though.. Nice post

    • Hi Sriram,

      This scenario is in production for almost an year and provides good throughput and performance. It is agreed that it will consume more time than developing every map separately, but it has reduced lot of rework. The measure issue of maintainability has been served and this approach is really paying off.

      With Regards,
      Shripad Joshi