Skip to Content

It’s been a while (understatement of the year) since I wrote Structuring Integration Repository Content – Part 1: Software Component Versions . You might want to (re-)read it prior to reading this blog for the sake of continuity.

 

Best practices document

A few months after I wrote part 1, I discovered a document titled SAP® Exchange Infrastructure 3.0: Best Practices for Naming Conventions. This was actually published before my blog, but doesn’t seem to have received much attention. At least I have been unable to find any reference to it in blogs or forums.

It was very gratifying to read this document, because what it advocates regarding Software Component Versions (SWCVs) is essentially the same as approach 4 in my blog, i.e. separate SWCVs for sender interfaces, receiver interfaces and mapping components. It formalizes and extends the approach and recommends naming conventions that reflect the component decomposition. If you haven’t already read the document, I highly recommend it! The document covers all object types in both the Integration Repository and Integration Directory dealing mainly with naming conventions, but I have chosen to focus exclusively on SWCVs in this blog entry.

The document contains (on page 6) a very nice diagram illustrating the approach. I hope no-one will mind me reproducing that diagram here:

Software Component Version model

The diagram shows two systems, A and B, running Application A and Application B, respectively, and communicating with each other via XI. There is one interface SWCV, in red, which contains Application A’s interfaces and a separate interface SWCV, in yellow, which contains Application B’s interfaces, and there is an application SWCV, the large blue rectangle, which contains the mappings between the interfaces of Application A and Application B.

One of the great things about the best practices document is that it provides us with some useful terms for referring to these different types of SWCVs:

  • Interface SWCVs – containing the interface definitions for an application and
  • (XI) Application SWCVs – containing integration scenarios, actions, and mappings which connect the interfaces of one or more applications

Additionally, the document introduces

  • Base SWCVs – “…for templates, generic structures, shareable Java programs, and so on” and
  • Canonical SWCVs – “For generic business objects; intended for reuse.”

It seems a bit unclear what this actually means, so I’ll elaborate on how I believe these last two SWCVs should be used.

Base SWCVs

Use base SWCVs to store common data types, message types and external definitions that you expect to share across multiple interface SWCVs. Any mapping templates associated with such shared definitions also go here.

Any common Java code (in imported archives) that can be reused by different application SWCVs also belong in a base SWCV.

Define dependencies (of type installation) in the SLD to allow other SWCVs to refer to objects in base SWCVs.

If you develop a custom adapter, I would also consider its SWCV as a base SWCV.

Canonical SWCVs

If your company defines a corporate-wide canonical data model, then the data types and message types of this model should be stored in one or more canonical SWCVs.

Also, if you need to communicate with a business partner using an industry standard interface such as ebXML or xCBL, place the corresponding definitions in canonical SWCVs.

Summary: what goes where?

Here’s a table showing which Integration Repository object types can belong in each type of SWCV.

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

 

  Object type     Interface     Application     Base     Canonical  
  Integration Scenarios           X              
  Actions     X                 X  
  Integration Processes           X              
  Message Interfaces     X     X*           X  
  Message Types     X     X*     X     X  
  Fault Message Types     X     X*     X     X  
  Data Types     X     X*     X     X  
  Data Type Enhancements     X     X*              
  Context Objects     X     X*           X  
  External Definitions     X     X*     X     X  
  Interface Mappings           X              
  Message Mappings           X              
  Mapping Templates                 X        
  Imported Archives           X     X        
  Adapter Metadata                 X        
  Communication Channel Templates     X           X        

X* = only when related to an Integration Process

 

Remember, none of these suggestions are written in stone. You may come across exceptional situations where other recommendations are appropriate. Use your common sense 😉

 

 


To report this post you need to login first.

6 Comments

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

  1. Bhavesh Kantilal
    After much pestering, you are back with the part 2.I love this structuring of SWCV’s as well.

    We define our Namespace’s by Business Processes and hence one namespace for PO, one for PO Change, Shipment Notification and so on is the norm spread across the multiple SWCV’s. When using this notation unfortunately we ended up with multiple project’s and interfaces using the same namespace and there by segregation of objects and transports was and at times still is a difficult experience.
    But, with the new Folder concept in PI 7.1 , having a additional layer of division in the namespace solved the trick! Maybe worth a note adding the folder’s concept of PI 7.1 here or is that in a later blog ? 🙂

    One another problem of this multiple SWCV’s though ~ Assuming, that your core Integration Content SWCV is being used across multiple projects and so are your source and target SWCV’s. Even though you might want to transport only one namespace to the next landscape , QA / PRODUCTION, the transport mechanism in XI end up transporting all namespaces of the SWCV’s but as empty namespaces. Something I don’t like as production SWCV’s end up with namespaces that are still being developed and refined in Development, they might be empty in Production but they still are something not very useful. Your thoughts on this? Is there a work around or one of those things you have learnt to live with as well.

    Thanks once again for this series!
    Regards
    Bhavesh

    (0) 
    1. Thorsten Nordholm Søbirk Post author
      Thank you for pestering, Bhavesh 😉

      Namespaces is another topic I’d like to blog about (no promises at this point though), and folders in the ESR are definitely worth noting. In order to avoid the problem you mention, it has been our practice to include the SWCV name (or at least an abbreviated form of it) in all its namespaces. This has the drawback of making namespaces even longer, though.

      To your comment about empty namespaces appearing after transporting other content: I haven’t experienced this, but it certainly sounds annoying. Maybe I’ve just been lucky not to encounter it.

      Cheers,
      Thorsten

      (0) 
      1. Alan Cecchini
        Hi Thorsten,

        We have decided to split our SWCs by sender/receiver systems and use another for mappings – all very logical so thanks for the advice.

        What would you recommend as an approach when there are multiple senders all calling the same receiver service/system?

        In our current case we only have 2 senders hence it is not too much overhead to copy the sender message interface/message type/data type from the first sender system SWC to the second SWC but obviously no benefits are being taken from reuse.

        Any suggestions?

        Thanks,

        Alan

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

          If, as you seem to be indicating, the two sender systems actually implement the same interfaces then if would make sense to let them share one SWCV. If this doesn’t quite make sense in the particular circumstances then you could also create one SWCV for each sender system and a third, shared, SWCV containing the interfaces they have in common. You should then specify a dependency (in the SLD) from each of the 2 sender system SWCVs to the shared SWCV, thus making the common interfaces visible in both the other SWCVs.

          Regards,
          Thorsten

          (0) 
  2. Swapna Seelam
    Hi Thorsten,

    Structuring PI Content is something that is disturbing me for a while now.Thank you so much, it is really informative.

    Any suggestions on SLD Landscape and Integration Directory Content structuring please? Am confused with Business Systems and Products association during structuring, should it be just one Business System for all Application Products created? How Configuration Scenarios should be structured?

    Thanks,
    Swapna

    (0) 

Leave a Reply