Skip to Content
Author's profile photo Daniel Graversen

Thoughts on versioning of PI components


The use of versions as a way for managing releases has been used for a long time to maintain programs. With the help of a revision control program is it possible to get an overview of what releases are build and which changes have been made. This will make it easier to give a better understanding of what is promoted to production.

On my current PI project we have different phases. We have just gone live with the first part and is currently developing the second part. After each phase a release is tested and moved to production. While the second phase is being developed the first phase must be supported, to ensure corrections can be moved into production before the next release.

PI makes it possible to use different versions of software components, to make it possible to use each version. Like other versioning tools is it a challenge to use it correct. I’ll describe, how we have used it and what we have learned.

How to use versions

The main part of configuring different versions is fairly easy. It just requires the users to create a new software component with a new version identifier. The first release will have version 1.0 and the second version will have version 2.0 and otherwise will be placed in the same products. Remember to add dependencies to the version 2.0 of the interface components, assuming the interface components also are upgrade. The version 2.0 should also be installed on the same systems as the version 1.0 components, otherwise it could cause problems.

Create the namespaces which will be used in version 2.0. Then make a release transfer, where the objects from version 1.0 are copied to version 2.0. The Release Transfer can be found at Tools Menu, and it works much like the export function. Only content from version 1.0 is copied if a similarly namespace is in the version 2.0 component.  You have now copied the content to the version 2.0 and can make changes in each component separate.

With the copy all object is copied to version 2.0. Objects will continue use the depended objects from version 1.0. For instance will a Message Mapping still use the Messages from the version 1.0. Unless the Message has been imported via dependent object, then the Mapping will use the Message from version 2.0 of the dependent software component.

With this upgrade maneuver the objects, will still be the same with very little change to them. It is a problem in the beginning but after getting use to it seems like a good idea. When changes are required simply alter the scenario to use a new interface mapping and maybe actions, and then add the functionality and the functionality can be used.

We tried to copy objects which had imported messages from the imported components. We therefore had the message types from version 2.0 in our 2.0 mappings. I do not think that this was a smart move, since I more like the idea of having to select when to upgrade a message type. Therefore this trick only works for abstract mappings, which have to be imported via the imported components. .

Objects and scenarios

I have earlier written about using Using PI scenarios and dialog tool for communicate the process with the business. With the help of scenarios, it is easier to maintain which version will be used.

When scenarios are copied to version 2.0 it will still point to version 1.0 mappings and actions. When changes are made to the version 2.0 object the scenario must be change to reflect that the mapping is changed. It is thereby possible to make configuration on a system, while maintain everything from version 1.0 except the mapping which has to be changed.


The use of two versions can cause problems. When a support issue arrives, it must be correct at version 1.0. But this change is not maintained in version 2.0. It is therefore necessary to somehow maintain both versions. If this is not done the problem will exist again in when version 2.0 is deployed. This can be difficult because it requires the users to implement the changes in version 2.0, and it gets more complicated if the involved object has been altered for version 2.0. If objects have not been altered in version 2.0, release transfer is possible again. If the object has been changed in version 2.0, the release transfer will show that conflicts exist.

To avoid having to develop thing twice and make sure that, we make the same changes to version 2.0, we made some changes to the process.

  • First we have decided that some processes will not be changed in face 2. Those object have been change so we use the version 2.0 in production. This will remove the need to maintain those objects in both versions.
  • Secondly we have decided on some systems which will be sent into production and maintain in version 1.0. This system shared BPMs with other systems, which will be changed in version 2.0 to support new features.

Namespaces and versioning   

The use of namespaces could make scenes for some areas. Then the version number could be a part of the namespace. It would make it clear if an object contained content from a different version.  If this approach was use then it will not be possible to use release transfer, because the namespace differed. I think that this probably makes most sense to use when communicating with third parties and the WSDLs need to be shared and agreed on which versions are used.



Since we need to be able to support the current running production system and creating we have to have to lines of ERP systems. I believe that this is a common setup for ERP projects. For the PI development it is just to configure the correct scenarios version for the correct ERP and third party systems. It hereby seems possible to perform the support alongside development of phase 2.


The use of versions is pain and requires developers to check what they are doing. I have avoided the use of versions for 4 years now, but have finally agreed to use version. The main argument was, that project had deliverables in two stages.  I believe that it is correct to use versions, but it still requires caution since it is easy to break the setup.

Assigned Tags

      You must be Logged on to comment or reply to a post.
      Author's profile photo Martin Stenzig
      Martin Stenzig
      Daniel, good blog. We have encountered the same problems you mentioned in here. We are trying to develop product quality applications on PI and are using versions to a large extend to keep the code seperate. The 3 biggest problems we have seen are:
      1.) As you pointed out, there is no way to "downgrade" a "patch" or change to a mapping and given that you cannot really do a "diff" it's sometimes hard to figure out what you have to downgrade after you made numerous changes
      2.) When you move objects into a new version we often have the problem that the mappings of the old version are picked up by the runtime. In most cases this problem magically goes away after 24 hours and "No" it is not a Cache refresh problem. We tried that. 😉
      3.) The biggest problem for us is that you don't have a kind of "user exit" for mappings so that customers can extend the mapping without having to copy it. Why is that a problem? If the customer wants to extend the mapping and we provide an updated version of the same mapping they collide.
      Appreciate any ideas.

      Author's profile photo Daniel Graversen
      Daniel Graversen
      Hi Martin,
      Thanks for sharing.

      A way I previos have tried to make the user exis is to make the mappings configurable, so for each segment in a edi message it is possible to switch this segment on. But this will just make the mapping to complicated. It is possible to have different layers of mappings with XSLT, where you have a basis template and then overite the themplate for the customer specific fields.

      I'm also missing the diff functionality to see what is the difference between the two mappings.

      Author's profile photo Former Member
      Former Member
      Hello Daniel,

      Good points, i ve had some similar experience about versioning at a customer running a developement and one maintenance track.
      Doing Maintenance change requires a strong policy on applying changes to the next version, that is already in developement.

      As far as for diffs for grahpical mappings we found a pragmatic way on using the "display text" function of the graphical mapping editor.
      You can copy them and then compare both text versions in a standard Tool like Ultraedit or whatever and its easy to find changes.
      Anyway it would be a usefull to have that feature already to have in the Repository