“How should we structure our Integration Repository content?” – This is a question every development department should ask itself before embarking on XI development. After all, if you don’t consiously decide upon a structure, developers have no guidelines to adhere to. Thus there will be no overall consistency in the Integration Repository, chaos will reign, and sooner or later you will end up with one big mess.
Considering how important this topic is, it is surprising that SAP has not published any guidelines. It is equally surprising to find how little it has been discussed on SDN. I think this lack of apparent interest can be interpreted in one of two ways: either developers don’t think about it at all, or they assume it is trivial.
In this blog I will discuss some commonly encountered approaches and why, in my opinion, they are inadequate. And I will point the way toward a more useful approach.
This first blog deals only with using Software Component Versions (SWCVs). I will tackle other dimensions of this topic such as namespaces, functional and organisational subdivisions, etc. in later blogs.
Approach 1: Single SWCV for all
One approach that I have come across is at once the most obvious and the most naive. Unfortunately, it is also the approach taken by SAP in their standard XI courses, so it is no wonder that it persists among some developers. In this approach only a single Software Component Version (hereafter abbreviated SWCV) is created and this is made to contain all Repository content. (I have even seen this taken to the extreme of having only a single namespace within the SWCV. You can’t get less structure than that!)
Imagine a simple scenario involving a sender system with one outbound interface, a receiver system with one inbound interface, and a mapping between these two message types. Using this approach, the single SWCV contains both systems’ interface definitions as well as the mapping. In the SLD, you would mark the SWCV as installed on both the sender and receiver business systems. When additional scenarios arise, their interfaces and mappings are developed within the existing SWCV.
At first sight, the single-SWCV approach does appear to have some advantages:
- There are no limitations on how objects can reference one another.
- An entire integration scenario can be transported using a single export.
- All objects related to a scenario can be found in one place.
The greatest, single disadvantage of this approach is that it does not conform to SAP’s excellent component model. In this model, a SWCV is a “deployable unit”, i.e. a self-contained piece of software that can be deployed/installed on a system. By taking the single-SWCV approach, you are essentially modeling your integration solution as a single deployable unit. But in reality there are normally different software components on each system taking part in an integration scenario – that’s exactly why we do integration. In short, the single-SWCV approach simply doesn’t make sense conceptually.
This approach also does not effectively support the loose coupling of systems in the landscape. Modelling the entire integration landscape as one SWCV is in a sense the most tightly coupled model possible.
As for its apparent advantages:
- Limitations on how objects can reference one another are a central tenet of good, general software design. Think of encapsulation and abstraction in OO languages, modularisation in non-OO languages, etc. Removing such limitations amounts to no more than a lazy convenience and almost invariably backfires in the long run.
- Although an entire scenario can be exported in a single step, great care must be taken when multiple transports are in the CMS pipeline simultaneously. The Assembly step in particular must be used carefully to avoid accidentally transporting untested changes to production together with tested changes. Subset assembly can be used to solve this problem but at the cost of extra administrative overhead.
- All objects related to an interface scenario can be found in one place, but as the number of interfaces increases they inevitably become more and more difficult to find in the “one place”.
Approach 2: Single SWCV per scenario
Another approach I have seen in action is one where a separate SWCV is created for each integration scenario, but still such that for any given scenario both sender and receiver interfaces as well as mappings are contained in one SWCV. In my view this gives only the illusion of more structure but is essentially equivalent to approach 1.
Approach 3: Separate SWCVs for sender and receiver
In this improved approach, separate SWCVs are created for each sender and receiver system (or type of system) in the landscape while mappings are arbitrarily (but consistently) developed within either the sender’s or the receiver’s SWCV. This approach has the following advantages over those previously presented:
- It fits well with the component model.
- It promotes loose coupling of systems.
The troubling aspect of this approach is the arbitrary assignment of mappings to either the sender’s or receiver’s SWCV. After all, mapping is performed by XI – not by the sender or receiver. Approach 3 doesn’t model this adequately.
Approach 4: Separate SWCVs for sender, receiver and mapping
Introducing a separate SWCV to represent XI and placing mappings within this, instead of in the sender or receiver SWCV, effectively remedies the shortcomings of approach 3. Returning to the simple scenario described under approach 1, three SWCVs are required:
- The first SWCV represents the sender system and contains only Interface Objects in the Integration Repository.
- The second SWCV represents the receiver system and likewise contains only Interface Objects in the Integration Repository.
- The third SWCV represents XI and contains only Mapping Objects and the Integration Scenario in the Integration Repository.
In this approach, Actions (for Integration Scenarios) can be placed either in the sender/receiver SWCVs with their corresponding Message Interfaces or in the XI SWCV together with the Integration Scenario.
Integration Processes would normally be placed in the XI SWCV, as would any asynchronous Message Interfaces required.
Only the foundation
In this blog I have focused exclusively on the SWCV dimension and only on its most fundamental aspects. Numerous other aspects and their interplay can also be considered when deciding how to structure Integration Repository content, including:
- use of namespaces
- funktional, organisational, etc. subdivisions
- standard vs. bestoke interfaces
- industry standards e.g. xCBL, ebXML, etc.
- transport considerations
- operations and support
I will address some of these aspects in later blogs, all building on the foundation of approach 4 above.