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.
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.
- 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”
- 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.
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.
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.
- 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:
- One Master Map per interface
- One Value change map per interface
- Multiple Content change maps as on need basis
- 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)
- 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.
- Consider the outbound scenario where Sender Party is A and Receiver Parties are X, Y & Z.
- 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.
- First we created Master Map, which will be used by all of three X, Y, and Z.
- 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.
- 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.
- 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:
- 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.