Best practices on version mgmt / versioning strategy of enterprise services

[Former Member]

Hi,

Could anyone share with me at high level what the version strategy they have used for maintaining enterprise services on PI 7.1.

Is there any best practices document from SAP on versioning strategy of Enterprise services using SAP PI 7.1.

Basically, i want my enterprise service version to be maintained for existing consumers when a new consumer needs an enhancement to an existing service.

Thank you in advance for sharing experiences in this area.

Thanks & Regards,

Renjith John Andrews

[Former Member]

Hi Renjith,

I haven't personally come across any best practice (documented) guides on versioning enterprise services but what I can offer are some suggestions...Ther are partner co-innovations (with SAP Co-Innovation Lab) that work as a solid governance layer on top, see this very useful blog with references: [http://www.sdn.sap.com/irj/scn/weblogs?blog=/pub/wlg/12063] [original link is broken];

Ideally, you would want to manage an Enterprise Service Lifecycle through it's phases (broadly design-time, runtime & change management) with a proper impact (compatibility for current consumers) analysis.

Suggestions in no particular order:

- Factor into account the communication pattern (e.g. is it query-response, request-confirmation etc.) for the enterprise service to be version stepped. This will help with the impact analysis.

- Business might be driving the change so they would need to specify whether the new requirements should be mandatory or optional (from a webservice parameter context).

- Document potential impact to current consumers (e.g. additional mandataory request parameter would impact all curent consumers).

- Consider business requirements like should the existing enterprise service version co-exist with the version stepped one or should the existing go through pre-defined lifecycyle stages of support (for a certain period) --> then deprecation --> then deprecation. Business may even decide that they should co-exist indefinitely.

- Also consider things like, if the requirement is for an additional parameter, can current consumer compliance be maintained by making the parameter optional (backward compatibility).

- You may or may not have noticed, when SAP version steps a service operation in the standard delivered Enterprise Services, they add a "_V1" to the current operation naming convention & it's added to the same Service Interface. That's also another way to go about it. However, I've noticed strange behaviour when I've tried this approach. It seems like the endpoints need to be deleted & re-created in SOAMANAGER before the new operation becomes visible in the WSDL. Possible current consumer impact during endpoint deletion & creation.

- You can also look at the Release Transfer functionality in the SAP ESR for your requirements.

Just some suggestions.

Regards, Trevor

[Former Member]

Hi Trevor,

Thank you very much for your response and suggestions.

I was kind of hoping that SAP would be having a best practices document in this area and wanted to make sure of the same since i couldnot search and find it myself.

Also to your point i did notice the naming style that SAP has adopted in the versions of the standard services.

The Release transfer itself will not help me much since to have 2 versions to be active simultaneously i need a difference in the

name / namespace.

From my understanding, what it boils down to really is taking time and ensuring a good service interface, putting governance in place regarding change management, bite the bullet and maintain different objects in case changes are needed

Regards,

Renjith John Andrews

[robert_warde4]

Iu2019ve been asked to look at versioning on PI. Specifically how we maintain multiple versions of an interface for the various SAP systems we will be rolling out globally. During part of that rollout we will need to have multiple releases. Iu2019ve researched the options, run a few tests and my conclusions are below but Iu2019m looking for a second opinion from my peer group.

Options

1) Create a new SWCV.

According to SAPs documentation u2018a 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.u2019 SAP use this approach for the majority of their standard content. You canu2019t copy objects between different releases of a SWCV. You have to use the Transfer Design Objects Function (ESR Menu under tools). Itu2019s a neat tool that will transfer objects only if the source objects are more recent or the target objects donu2019t exist. You can preview the changes and it will tell you what will be updated (source version is more recent), what canu2019t be transferred (the target version is more recent) or what doesnu2019t need to be transferred (the versions are the same).

This is appropriate for deploying different versions of a particular software package but doesnu2019t allow us to actually 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.

3) Ensure that the interface is backwards compatible.

Backwards compatibility isnu2019t 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. It seems to overkill.

Summary

Using different SWCVu2019s 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 theyu2019ve taken this approach. Iu2019ve checked the SAP support sites and canu2019t 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.

[Former Member]

Hi Robert,

Thank you very much for your response and like you i am a bit perplexed as to why SAP doesn't have a "Best practices document out there" on versioning. Version management of neterprise services is a vey pertinent topic in the ESOA area.

We have created our first set of versions in this release and come next release, my approach as i think now, would be a combination of namespace with versions and objects with versions(depends on how much of a functionality change comes in the new version).

Thanks & Regards,

Renjith John Andrews