Skip to Content
Introduction

“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
  • versioning
  • funktional, organisational, etc. subdivisions
  • standard vs. bestoke interfaces
  • industry standards e.g. xCBL, ebXML, etc.
  • transport considerations
  • authorisations
  • operations and support

I will address some of these aspects in later blogs, all building on the foundation of approach 4 above.

To report this post you need to login first.

15 Comments

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

  1. Anonymous
    Indeed a much needed blog! I have seen several threads on the XI forum related to this topic in general…and I’m sure it will be very helpful.

    But I’d like to mention one thing about the 3rd 4th approach that you have suggested. I think they contradict the idea of the component model in one way:->
    If we end up creating SWCs as categories for sender system’s, receiver system’s and mapping’s objects, then isn’t the idea of designing a SWC for one particular process flow…for one particular interface-design, lost?

    With this kind of approach, irrespective of how small or big the landscape is, you will have to create and (every other time) import atleast 2-3 SWCs right?-wouldn’t this be cumbersome if many systems are invoved? Also, when file transports are done between different enviroments of XI(for ex.-DEV and PROD) there might be possibilities of version conflicts. Sorting out these version conflicts when SWCs are defined like this->I think is very difficult!

    I personally think that apart from the number of systems involved, the way a developer attempts to seggregate&/classify the objects in the landscape also depends upon how big the landscape is…not just how many systems are invloved but also how many [i]times[/i] each of these systems are used in the landscape, dependency of one part of data(from one particular system) on another part of the data (coming from another application system), etc.

    But again, I think there are many permutations and combinations possible…so, the number of appraoches that are possible are also many!

    Looking forward to your next blog:)

    Regards,
    Sushumna

    (0) 
    1. Bhavesh Kantilal
      Hi,
      A really good blog. Am still not convinced on the approach 4, but i would like to wait for the next few blogs before I make up my mind.
      Looking forward to them,
      Regards,
      Bhavesh
      (0) 
    2. Thorsten Nordholm Søbirk Post author
      Hi Sushumna,

      First, thank you for commenting. I really believe we need a broader discussion of this topic.

      To clarify: “designing a SWC for one particular process flow…for one particular interface-design” is precisely what I want to avoid. As an example, consider an interface between R/3 and a bespoke mainframe system. In the single-SWCV model (approach 1 or 2), both the sending and receiving interfaces (as well as the mapping) would be defined in a single SWCV. To reflect this in the SLD you would mark this single SWCV as installed on both your R/3 and mainframe Business Systems. This is clearly absurd. Each of these systems requires its own SWCV.

      Regarding the number og SWCVs required: clearly, approach 4 results in a larger number of SWCVs than approach 1 or 2. However, the number does not necessarily need to be huge. A single SWCV for holding e.g. all R/3 interfaces will suffice in some organisations. Likewise for a mainframe. And a single SWCV can hold mappings for a number of related scenarios. (I would however caution against using a single SWCV for all mappings as this becomes unmanagable with time. More in a later blog…)

      Could you explain in more detail your concern about version conflicts? I’m not sure what you mean.

      Kind regards,
      Thorsten

      (0) 
  2. Michal Krawczyk
    Hi Thorsten,

    I added your weblog to the XI best practices
    section in XI/PI faq

    it’s question 13 so hope you’re not superstitious 🙂

    Regards,
    michal

    (0) 
      1. Michal Krawczyk
        >>>- love your FAQ!

        thanks 🙂
        hope all of your weblogs from
        this series will be as detailed and great as this one – however I have no doubt about it:)

        Regards,
        michal

        (0) 
  3. Anonymous
    Hello,

    During the initial days of our XI implementation we took a lot of time in coming up with a standard format for organizing IR. We looked at various alternatives, but were finally motivated with the way SAP organizes all their stuff based on business area.

    For example if we were building a scenario of getting customer master data,

    Software Component
    ——————-
    COMPANY_SD_APPLICATIONS

    Namespace
    ———-
      http://company.com/SD/MDM/Customer

    Interface
    ———–
      requestCustomerDetails

    MessageType
    ————
       CustomerDetailsRequest
       CustomerDetailsResponse

    We currently have a ton of scenarios following this patern, and i must say our IR is highly organized. An ABAPer will feel like at home as the organization was borrowed from SAP. But on the same token a non ABAPer will find it very intutive….

    Cheers,
    Naveen

    (0) 
    1. Thorsten Nordholm Søbirk Post author
      Hi Naveen,

      I would agree that this approach leads to a neatly organised IR.

      I cannot tell from the information you listed whether the COMPANY_SD_APPLICATIONS component also contains the interface at the other end of your scenario and the mappings or whether these are in separate software components. Could you elaborate on this?

      Regards,
      Thorsten

      BTW, I plan to discuss various options for using namespaces in a later blog.

      (0) 
  4. sachin kotalwar
    hi Thorsten,

    A very good blog targeting the critical deficiency in SAP XI documentation.

    The approach 4 is indeed modularized & following OOAD concepts. It would be great if you can give some more details of creating SWCV dependencies for build and installation time. I could not find much documentation for same.

    cheers,

    sachin kotalwar

    (0) 
  5. waldemar roberti
    Hi Thorsten!

    Congratulations! Is a very helpful blog! We are waiting the next one 🙂

    About the fourth proposition, could we consider if we have N systems to integrate (imagine about 50 systems), we will have two SWCV for each one (one for inbound interfaces, another for outbound interfaces) and another one for the mappings? It seems to be a good number of  SWCVs? And about the namespaces? It is really difficult to find something about guidelines for structuring namespaces to.

    Thanks!

    roberti

    (0) 
  6. Bhavesh Kantilal
    I revisited this blog this morning and I still find it to be among the best blogs here on SDN for XI. 🙂

    Unfortunately, the series has stopped abruptly and it would be really helpful to all us XI devlopers if you can continue with the series as earlier planned. We all need more blogs on these concepts.

    Regards
    Bhavesh

    (0) 
  7. Liang Ji
    Hi Thorsten:

    I really enjoyed your blog, it is truely an one of the best. and Abolutely agree with you, we used the 3-SWCV-aproach in past two projects.

    When question being asked, how many interface used System A as end point system, just simply explore the SWCV version and count the namesspaces created inside it.

    However, I did not see your part 2.

    Liang

    (0) 
  8. S Kantheri
    HI,

    This is a very handy piece of info for any PI developer. I was struggling to understand the approach and found no documents provided by SAP neither in SDN, exactly like what you pointed in your blog.

    This defenitely gives a structured approach to any organisation as well the developer. Thanks for sharing this.

    Regards
    Shashi

    (0) 

Leave a Reply