Skip to Content

Versioning in SAP PI

I’ve been asked to look at versioning on PI. Specifically how we maintain multiple versions of a single interface for our various releases. I’ve researched the options, run a few tests and my conclusions are below but I would appreciate your feedback


1) Create a new SWCV.

According to SAPs documentation ‘a software component version is a shipment unit for design objects in the ES Repository. You use a SWCV to group together objects that are shipped or installed together.’ SAP uses this approach for the majority of their standard content. You can’t copy objects between different releases of a SWCV. You have to use the Transfer Design Objects Function (ESR Menu under tools). It’s a neat tool that will transfer objects only if the source objects are more recent or the target objects don’t exist. You can preview the changes and it will tell you what will be updated (source version is more recent), what can’t be transferred (the target version is more recent) or what doesn’t need to be transferred (the versions are the same).

This is appropriate for deploying different versions of a particular software packages but doesn’t allow us to use both versions. The majority of the ID objects refer to the interface/namespace and not the SWCV. If you try and add two identical interfaces from separate SWCV to the same Communications Component you get an error.

2) Create a new namespace with a version number.

SAP has used this approach for the NFE updates and it works.

25-01-2013 11-44-36-AM.jpg

3) Ensure that the interface is backwards compatible.

Backwards compatibility isn’t always easy to achieve. The functional requirements we are given evolve over time and it may be the case that what seems to be a simple change that may not have any impact may will change significantly.

4)  Add a version number to the object names

Not the most elegant approach but it would work.

5) Stand up a separate PI landscape.

Not my preferred approach as it introduces additional costs, maintenance, monitoring and development.


Using different SWCV’s allows new releases to be created and deployed but you can only have a single release active at any moment in time. Using Namespaces allows multiple releases to be deployed. If you look at the SWCV for NFE, SAP SLL-NFE you can see they’ve taken this approach. I’ve checked the SAP support sites and can’t find anything on versioning.

My preferred option is number 2. Using a different namespace works but will require the calling system to update their configuration to support this.

25-01-2013 11-44-36-AM.jpg
You must be Logged on to comment or reply to a post.
  • Hello Robert,

    Thanks for a blog on that topic, I think it deserves some attention.

    I actually prefer option 1, since the restriction you mention usually does not apply. It depends on your landscape, of course, but in the installations I have seen there is only one application per system using the interface, and either they move to the new version (in that case you switch in the configuration for that system) or they keep using the old one.

    I found this is also a quite elegant way to support project and maintenance landscapes with just one PI system.

    Advantage over option 2 is that you keep your SWCV clean, you don’t drag along old versions and can delete old ones more cleanly.



    • Jörg

      Many thanks for your comments. I prefer option 1 too but if we have a global application and are dependant on the local businesses to upgrade we will need to have multiple versions deployed for a period of time. I agree, option 1 is very clean and easy to manage. However, in this situation it wouldn’t work. I have recently added some more information to a new blog that may be worth reading.–part-2


      Rob Warde

      • Hello Robert,

        thanks, I’ve read both parts before posting here.

        My point is that in most cases an interface is only consumed or provided once on an ABAP system, no matter if used locally or globally. If that is the case, you can perfectly use option 1. If that is not the case, so if your interface is called from multiple applications on the same system, then you’re in trouble with that approach, that is true. However, I would always recommend option 1, if possible, and if not, go for option 2. But the main brain change is to think in interface lifecycles at all. This is my experience so far. People know build and run, but usually not decommission or even evolve their interfaces. This is why I like a blog on that topic. Keep it up!