"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.
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:
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:
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.
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:
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.
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:
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.
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:
I will address some of these aspects in later blogs, all building on the foundation of approach 4 above.