For simple XI implementation, very often one Software Component Version (SWCV) is where we get started to devise all the XI design objects. Basically put everything together. However, for a complex system landscape where the connected systems are constantly under parallel patching and upgrade, one SWCV appears rigid to meet the fast changing requirements. SAP Best Practice recommends that, you may divide XI design objects into different SWCVs for higher flexibility and reusability.
Image source: SAP Exchange Infrastructure 3.0: Best Practices for Naming Conventions
- Interface Products: Represent extensions to current applications. These extensions are imported later to the Integration Repository and connect the corresponding interface objects and integration scenario actions.
- XI Application Products: Represent objects in the Integration Repository other than interface objects (for example, mapping objects and integration processes).
Real-life example
XI acts as an integration broker for CRM and legacy systems in customer landscape. Using 3-SWCVs approach, the layout of SWCVs is like this:- One Interface Product SWCV for CRM system (I_CRM, 1.0 of company.com) to hold IDocs, RFC objects.
- One Interface Product SWCV for legacy system (I_LEGACY, 1.0 of company.com) to hold DT, MT, and MI.
- One XI Application Product SWCV (A_CRM1.0_LEGACY1.0, 1.0 of company.com) to hold mapping and integration processes.
While AS-IS CRM system is maintained and patched to support daily operation, you are going to initiate a separate code line for new CRM development.
Using one-SWCV approach, you make a copy of the entire SWCV (upgrade to version 2.0), which bundles together the unnecessary and unchanged XI objects of legacy systems.
For 3-SWCVs approach, you do a release transfer for both I_CRM and A_CRM1.0_LEGACY1.0 from 1.0 to 2.0, leaving I_LEGACY untouched. When you want to develop legacy system later, you can upgrade I_LEGACY independent of I_CRM. Does it appear neater and more manageable?
Below is an example of software life-cycle roadmap.
Procedure to define your 3-SWCVs
First, log on your SLD. From there you define Interface Product SWCVs for each application systems. Your DTs, MTs, imported objects, and MIs will go to these SWCVs later.Second, define your XI Application Product SWCV for MM, IM and BPM processes.
Then under your Application Product SWCV, go to Dependencies tab and click on “Define Prerequisite Software Component Versions” button.
Under context “InstallationTime” add the Interface Product SWCVs. This ensures you can reference to DTs, MTs etc from your mapping program and BPM processes, across different SWCVs.
Now from your Integration Repository, you can find three SWCVs as defined. Under A_CRM5.0_LEGACY (Application Product SWCV), a new branch called Basis Objects is displayed. This is the placeholder for objects under I_CRM5.0 and I_LEGACY.
The basis objects are read-only. You can modify them from their original I_xxx SWCVs.
Notes
- in the event of SWCV upgrade, you can use the “Release Transfer” utility tool. Further information on Release Transfer can found on help.sap.com.
- The XI Best Practice paper also suggest further reusability by using Basis Products (templates, generic structures, shareable Java programs) and Canonical Definitions (generic business objects)SWCVs.
How many SWCVs, you decide. 🙂
Further reading
- SAP Exchange Infrastructure 3.0: Best Practices for Naming Conventions
- Thorsten Nordholm also gives a comparative study on different ways of structuring IR objects in Structuring Integration Repository Content - Part 1: Software Component Versions.
1 Comment
