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.
Objective:
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".
Solution:
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.
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"
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.
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.
Difficulties:
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:
Interface Mapping:
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.
Example:
Message Mapping:
Interface Mapping:
Interface Determination in XI Integration Directory:
For Inbound scenario the sequence of message mappings in interface mapping will be reversed.
Reference:
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.
http://help.sap.com/saphelp_nw70/helpdata/EN/4f/ef761a5ecfb1418b79896e10fe4c57/frameset.htm
http://help.sap.com/saphelp_nw70/helpdata/EN/ec/21ee117a909f44a8b69794b9ed6221/frameset.htm
http://help.sap.com/saphelp_nw70/helpdata/EN/cf/406642ea59c753e10000000a1550b0/frameset.htm
Regards,
Shripad Joshi