In todays most complex IT environments, advanced software change processes (and with it advanced tools) are not a luxury anymore, but a core requirement! Keeping all the changes manageable, be revision safe and compliant - that's what those processes and tools can offer you. But there is more and it's absolutely vital: only those tools will help you protecting your production systems, your business processes and in the end: your IT investments! Hopefully, this series will give you some valuable insights into what SAP has to offer in the realm of software change control, allow you to ask questions and give feedback to influence our future developments - because this is not a series of blog posts written by product managemnt, but straight from the developers! And be assured: we will listen!
Today, let's get started with what probably matters most: protecting your production! And as this is a prio 1 topic for us, we have more then one tool in place to make sure, that only what fits into your system, goes into your system! Software dependency issues are hard to tackle - you write software, assuming a specific environment is given in your development system, but after propagating throughout your whole landscape, is the actual environment still the same in the production system? Are all dependent objects there? In the correct version? If you follow the guidance, to always import and deploy transport request in the given export order, you might be on the safe side. But let's be honest, sometimes you have to do some emergency changes, sometimes something goes live out of context and release plan and what about support packages?
Yes, with any change comes risk and with risk comes cost! That's a law of nature, isn't it? Well, no it is not and we have a set of tools and best practices to help you minimize the risk (and therefore the cost). Let us help you protect your production! How? Well, let's start simple - with the so called software component-based checks.
Component-based Protection
Some (dry) theory first: each SAP (ABAP) system has a so called component version vector: a list of all components installed in the system - including release and patch level.
This information is always attached to a transport requests during release. Hence, it is possible, to always identify, in what kind of system - defined by its component version vector - a transport was created and released.
Now what can we do with this data? Right before you a requests should be imported into a target system, the software can now compare the systems vector with the one saved for the request and if they differ, warn you or cancel the complete import.
But what would a not matching component version tell you? Well, simply put, that the software configuration of the source and the target system do differ and this could potentially mean, that your transport request does not really fit to the system.
The observant reader might have some questions here - what does 'software configuration' mean? And should I care about 'could potentially mean'? Software configuration here means the complete state of the system - with all its actual software, customizing and system configuration. So if the component vectors differs, the software components are different - meaning that different software is deployed in the source and target system! Since your transport request was created in the environment of the export system - and therefore within the context of a specific software configuration (e.g. release and patch level of the components), it might not really fit to the target.
But again 'might' and 'potentially'? Yes, the component-based approach is not really hi-res… Meaning, that by simply comparing the version vectors we cannot really know, if objects contained in a request do really require a specific environment feature - read here: software component.
It is a simple, yet powerful solution - we do not compare data on an object level, but instead use the static component version vector to narrow down potential dependency issues. This does reduce runtime and safe some performance on the one hand, but it can produce false positives on the other hand. In general, we would expect any system in a given transport track to have very similar or even identical component versions - otherwise, development, test and go-live would be really tricky and any test results from the quality environment would be not really that meaningful at all.
However, the world is not that perfect - imagine applying a support package, probably, you will start with the development system and apply a new SP, make your adaptions and move on the test and later to production. However, in between, development and fixing of software cannot simply be stopped - what would be the result? You create requests with newer components then the ones deployed in test and production! But don't worry! SAP Patch Manager (SPAM) will help you out here - buy using exactly the mentioned data, it can tell you, which request should be imported before you perform a patch and which should be imported after the patch - with one intention: protecting your production systems!
If you are interested in some more details or want to know something about the configuration, we have a note at hand, to ease your way into the lands of component-based import protection - see note 1742547 (Information about component version check in TMS).
If you fear, that this might not be enough to protect your production from software dependency issues, fear no more! We have something else for you - object level predecessor and downgrade checks as part of CTS! But for this, you will have to stay tuned and check back in later this week!
Christian
