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:
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 😉
6 Comments
