Introduction
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 http://www.cap-standard.com/.
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. 
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. |
Concusion
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 middleThe 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.
5 Comments
