SAP Software Change Control Insights: Protect your Production! (2)
Last time (part I of this series), I tried to establish, how important protecting your production systems is – I guess that was not at all a hard sell, was it? I introduced the component-based checks, which are part of SAP NetWeaver AS ABAP from 7.00 and newer. Today, I want to give you some insights into a more sophisticated tool for managing software dependencies when propagating software changes using SAP Change and Transport System (CTS).
From just utilizing component vector versions, we now move on to real object-level dependency analysis. The CTS team did spend quiet some effort and time to develop an advanced set of checks, running based purely on the requests, their respective objects in a given import queue and the import history of the system. With this data, we are able to provide you a predecessor and downgrade check for ABAP and, with some limitations, also for non-ABAP.
Those checks do only leverage data available locally in the actual system, where the import should take place – there is no additional persistence – we simply evaluate the list of objects for all requests in a given import queue and all requests relevant from the history of the system. The checks themselves can be executed explicitly, or as first step of the import process – even canceling the import, if any conflicts are found!
With this information, we can calculate if two transport requests overlap object-wise and if you should also import predecessors or if you are provoking a downgrade. No additional configuration is necessary – you just need to install CTS Plugin (part of SL Toolset) and fire up the new import UI – ‘wait, there is a new import UI’, you may ask? Well, yes and we will tell you more about this in the future. But as far as those CTS-based downgrade protection checks sound interessting to you, just click here and check out the online documentation.
The granularity of the checks introduced today, is way finer, then the granularity of the one based on static component information – remember, we use object-level data here! However, since a lot of information has to be processed, they can also be very calculation intensive from a technical perspective and the algorithms behind the scence are a lot more complex. But as far as the level of protection goes, this is clearly a great addition and progress compared to the checks introduced last time.
‘So, what’s next?’ You might ask! We have a complete protection on object-level, there possibly can’t be anymore, can there be? Well, we worked hard and yes – we can do even better – just stay tuned and check out the next post of this series!