Skip to Content


Most XI Projects start with building Point-to-Point Scenarios. We have observed that different XI developers use different architectural design decisions concerning the Software Components Versions (SCV). Some XI developers use a “Single SCV model” and some XI developers use a “Multiple SCV model”. The “Multiple SCV model” will be called the “Sender Mapper Receiver SCV model” in this weblog.

In this weblog the advantages and disadvantages of using a “Single SCV model” versus a “Sender Mapper Receiver SCV model” for a Point-to-Point scenario will be explained . The concept of separating the Software Components will be explained by using an example.

First a short definition of a Software component which will be used later on…:
“Software components represent the reusable modules of a product. You can upgrade them or install patches on them.”

Example Case: Receiving Sales Orders from Customers

The company has a business case for receiving sales orders from customers by XML. Also has been decided that the XML format has to be CAP (*1). The sales orders will be send to SAP R/3 by using the IDoc ORDERS.ORDERS05.

Remark *1: CAP stands for Common Aftermarket Protocol, a set of standard messages to improve the electronical exchange of information between manufacturers and buying groups in the European Automotive Aftermarket. For more information see

The following Repository Objects are needed:

  • Sender interface definition – for CAP Order format (External Definition (XSD) and Message Interface)
  • Receiver interface definition – for the IDoc ORDERS.ORDERS05
  • Mapping – for transforming the XML CAP Order to the IDoc ORDERS.ORDERS05

Before creating these Repository Objects in the Repository you first need a Software Component Version.

Single SCV model

In the picture below a single Software Component Version is shown, which consists the Sender Interface, the Mapping and the Receiver Interface.


Sender Mapper Receiver SCV model

SAP advises to assign a Software Component corresponding to the business systems involved.

In this model the interface of the Sender, the interface of the Receiver and the Mapping are placed in separated SCVs. image

Administrating the Interfaces to the Business System

The link between Business System and its interfaces will be realized by linking the Technical System to the Products and linking the Products to the Software components. This is all done in the SLD. In the Repository the Software Components (Versions) will be imported. In the picture below these links are visualized.


Single SCV model and interface administration

By using just one Software Component Version the Interfaces belonging to the Business System cannot be administrated correctly. The picture below shows the incorrect relation between the Receiver R/3 Business System and the Message Definition and Interface of the CAP Order.

This relation is incorrect, because the CAP Interface is not an interface of the Receiver Business System, but an interface of the Sender Business System/Service.


Sender Mapper Receiver model and interface administration

The picture below shows the SMR SCV Model. So the Sender Interface and the Receiver Interface are defined in two Software Components.


The Sender Software Component only contains the interface definition and message interface of the sender.

The Receiver Software Component only contains the interface definition and message interface of the Receiver.

By splitting the Sender and Receiver Software Components it is possible to connect the Receiver Business System to the Receiver interface only.

For the IDoc ORDERS.ORDERS05 you should use the Software Component SAP APPL. The extra advantage of using this standard SAP Software Component is, that you don’t have to link it to your Technical System, because this will be done automatically by configuring transaction RZ70 in your Business System.

For more information on this topic see weblog D-XIE Soap part 3: Determine Software Component Version of standard SAP IDocs and RFMs.

(Remark: when Sender and Receiver both use the same Interface version, and you did make a mapping programming, than you will have at least two Software Component Versions. One for the interface and one for the mapping.)

Mappings in a separated SCV

You could start difficult discussions about putting the Interface Mapping and Mapping Programs in the SCV of the Sender or in the SCV of the Receiver. But we think that the mapping is not a part of either one of them. There are two reasons for separating the Mapping.

1. The Sender and Receiver Software Component should only contain interfaces correspond the real business system.

2. The mapping is a specific integration task uniquely running on XI. It should be managed by its own XI software component. (Example SCV name: DXIE_XI_SALES.)

Looking back at the definition of Software Component, we would be able to upgrade it and install patches. This means another advance of separating the Software Component of the mapping program from the interface. Now you can manage your versioning of the mapping programs and the interfaces separately.

Integration Scenario

Finally we have the Integration Scenario left. In point-to-point connections the integration Scenario should be placed in the Mapper Software Component Version.


The Actions have been placed in the Sender and Receiver SCVs, so that these actions could be reused in other Point-to-Point connections.

Advantages and Disadvantages

Single SCV model Sender Mapper Receiver SCV model
Separated versioning of the Outbound Interface and the Inbound Interface are not possible. The SCV does not correspond to the actual SCV. + Separated versioning of the Outbound Interface and the Inbound Interface are possible.
Separate versioning of the Mapping is not possible. + Separate versioning of the Mapping is possible.
Imported interfaces are not reused, because every Point-to-Point scenario will have a separate SCV and every SCV has consists of the Sender and Receiver interfaces. + Imported interfaces can easyily be reused by the Mapper SCV.
No correct administration of the interfaces linked to Business systems. + Correct administration of the interfaces linked to the Business systems. By (re-)using the standard SAP SCVs (ex. SAP APPL) manually linking the Software Component to the technical system is not necessary.
+ Only one Software Component has to be transported. Three Software Components have to be transported.


We tried to show the advantages and disadvantages of separating your Software Component Versions in stead of using just one Software Component version. We use the “Sender Mapper Receiver model” for Point-to-Point scenarios.

However, we are looking out for comments and additions and your experience on separating SCVs. So please do not hesitate to comment on this weblog.

Coming next in the D-XIE soap:

Why shall we use encryption, signing and compression? Meet you next time in de D-XIE soap…

Other D-XIE soap

The D-XIE Soap part 1: basic principles with XI in the middle
The D-XIE Soap part 2: XI design decisions for synchronous or asynchronous messaging
The D-XIE Soap part 3: Determine Software Component Version of standard SAP IDocs and RFMs

Thanks to all D-XIE members, especial Robert Eijpe and Hans Gmelig-Meyling, both of NL for Business, for helping me writing this weblog.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Hi,

    Really good blog, that will help a lot of people to start thinking about how to set up their SWCs.

    I do like the threefold structure proposed and actually we have used that for various XI implementations at huge companies as we think, it is the best way to achieve maximum reusability. And reusability is the key point to lowering the TCO.


  2. Former Member
    Thanks for the interesting blog.  We are looking at doing this same concept.  My question is how would you handle product/product version.  It’s clear you would create product for the sender/receiver SWC.  How about the “middle” SWC?  Would you have a product/product version for this or not have one at all?


    1. Former Member Post author
      Hello Bevan,

      Thank you for question.

      When you have just one XI system, than one Product Version should be enough.
      (for example DXIE XI 1.0)

      But when you have more than one XI system, than you could make a generic product and an XI system specific product.

      The product version of the generic product is very important.

      Assume you have two XI systems in your Production landscape:
      – XI-A
        – Generic product: DXIE XI GENERIC 1.0
        – Specific product: DXIE XI A 1.0
      – XI-B
        – Generic product: DXIE XI GENERIC 1.0
        – Specific product: DXIE XI B 1.0

      When you change on system A the SCVs of the generic product DXIE XI GENERIC, than you should make a new product version: DXIE XI GENERIC 1.1. You should also make new SCVs (for example DXIE_XI_SALES 1.1).

      (Remark: The name GENERIC, A and B are just examples. You should give your PVs and SCVs a more meaning-full name.)

      The advantage of making generic and system specific products is that you do not have update your system specific product version for every change you make specific for that XI system.

      So the answer to you question:
      – Yes, you should have at least one Product Version.

      Kind regards,


  3. Former Member

    Nice to be able to benchmark our own designs versus some ‘best practice’ examples.
    How would you in general model the middle component ( mapper ) , running on the ‘XI product’.
    Would you use 1 SWCV ( representing XI in general ) for all interfaces and then use e.g. namespaces to organise across different interfaces or would you use 1 SWCV ( representing XI for the specific inteface ) for each interface ( resulting in many , many SWCV after a while in a busy landscape )

    What could be other interesting usages of the namespace level ?

    Deberlanger Dirk
    XI consultant in progress 🙂

    1. Former Member Post author
      Hello Dirk,

      Sorry for my late answer…

      For now we have choosen to split Mapper – SWCVs at business process level.
      So we have used:
      …and so on…

      When you use End-To-End processes than you could use the name of your End-To-End process.

      So each XI SWCV has one Integration Scenario.

      Now the namespaces…

      One package for the Integration Scenario:

      Multiple packages for the interface types:

      Kind regards,
      Alwin van de Put.


Leave a Reply