Okay, today, let me try to resolve some confusion out there, when it comes to the naming and especially the meaning of the CTS-related products and features.
You all might have heard of CTS, CTS+ or even Central CTS. The 'CTS' in all of those terms refers to the SAP Change and Transport System - and all-integrated software logistics tools to record and propagate changes. Historically, (stick with me here for a second, I won't bore you with the history of CTS too long), the foundation was developed in the early 1990's. With the introduction of SAP R/3 a new kind of business software platform was born. The tooling itself grew over the years from the very core (the kernel parts) of CTS including the transport control program tp and the database content tool R3trans, into a fully integrated workbench environment and an advanced ABAP-based transport management system (TMS).
However, not only did the IT world become more and more complex, but also the SAP landscape evolved into something more heterogenous - non-ABAP solutions based on JAVA environments - like SAP Enterprise Portal - started to emerge in the early 2000s. But of course, with the introduction of those new platforms, the need for orchestrated and properly managed change processes became more and more essential. Since so many SAP customers were quite familiar with our ABAP-level CTS-based tooling and processes on top (using solutions like SAP Change Request Management and SAP Quality Gate Management), we decided to integrate those new technologies into the existing infrastructure. Hence, an extension of CTS was developed to manage exactly those new applications - and now, guess what this extension was called? CTS+ That's right, CTS+ is the extension of CTS to incorporate non-ABAP changes - it was never meant to be the next version of CTS, but instead CTS itself now simply included non-ABAP features. In order to give those a catchy name, the term 'CTS+' was introduced.
Okay, now we know, that CTS is still CTS, even if it comes with a CTS+ feature set, but how about Central CTS? Is this the next version of CTS? Well, here the answer is again: no! Central CTS is not the next version of CTS, but rather again, a new set of features of CTS rolled out under this term. The evolution of the transport system did not stop with the introduction of non-ABAP systems and content, but went on together with the evolution of the business landscapes. The basic idea was to focus on actual business solutions, instead of just enabling different technologies. A business process does not stop at system-borders, but rather might incorporate multiple systems, running on all sorts of platforms. Which means, that changes and development for such a process need to be implemented in multiple systems as well. So, how to keep those pieces together? Here is where Central CTS (cCTS) comes into the play - basically, cCTS is a set of features (clusters, collections, synchronization, flexible bundling) helping customers to manage even the most complex landscapes and change processes. And once more: Central CTS is not a new version of CTS, but rather a feature-based extension to enable change processes in complex, heterogenous landscapes.
Well, was this confusing? Another way of thinking about it is this: imagine a box called CTS, just like a model kit with various parts and features included, one of them being plain CTS, another one CTS+ and the third one Central CTS. All those pieces do offer different options and possibilities. You can deploy them all together or as you need them.
So, what to take away from this post? That's really simple: plain CTS, CTS+, or Central CTS - in the end, it is all CTS!
Welcome back! SAP TechEd Las Vegas and Amsterdam were a blast! But now, I am back at my desk and will continue to share some change control insights with you! In the last two posts I was giving some information on how to protect the production systems on a basic level (Protect your Production and Protect your Production 2). Today, we will continue this topic with the final and most comprehensive set of tools for protecting production systems. So, without further ado, let's dive into it!
Central Downgrade Protection - ChaRM & CTS
With SAP Solution Manager 7.1 SPS05 with introduced a completely new infrastructure to track changes and their propagation in the whole landscape! With this central approach we introduce a change tracking repository on object-level. Together with the Cross-System-Object-Lock data, we can now deliver a complete set of checks that will protect your production system from the very start!
We first check at change time, when the object is acutally touched. We do also check if the object list of a transport request is changed using SE09. Reassigning changes from one project or decoupling single request from a change make both, ChaRM, and QGM highly flexible. However, this flexibility also introduces additional risks we can defy by the DGP checks as well. Finally, we check right before the import of changes, if any predecessors do exist, or if the import would create an actual downgrade.
The algorithms themselves work on key-level, so we have the most comprehensive solution together with ChaRM/QGM. It might need a little bit more of setup - but it definitely is worth it! For more details about setup and more technical information, check this cool blog post by Raquel.
This unmatched holistic downgrade protection approach does especially gain relevance, when on SAP ChaRM and SAP QGM side, propagating changes is used with all flexibility features we introduced with SAP Solution Manager 7.1 SPS10 and the Central CTS infrastructure.
SAP offers a wide variety of tools as part of the change control portfolio - from basic protection, as part of NW, to advanced protection with CTS_PLUG, and high-end protection with full-blown DGP on SAP Change Request Management and Quality Gate Management level. You have the full set of options to choose, what fits your needs, processes and landscapes - full flexibility, even when it comes to protecting your production systems!
You have feedback? Just use the comment section to drop us a line! And don't forget: stay tuned for the next edition of SAP Software Change Control Insights!
In addition, we have a bunch of networking sessions set up - so I promise, if you put change control on your agenda, you won't regret it! Enjoy your stay... but don't spend to much playing slot machines...
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!
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.
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!
do you remember me? No? Well, that's probably my fault - we were very, very busy programming and testing and all of this tech stuff. But guess what - we actually built something you might want to check out, something pretty cool - perhaps the best software change control solution out there? I'll let you decide... but more about this later!
For now, allow me to recap what happened so far (nope, this is not the latest episode of your favorite fantasy-drama show, but pretty close): once upon a time we decided to take this well-hung piece of software called SAP CTS (Change and Transport System) for a good spin and not only enhance it, but bring some super new and future proof concepts to the table. We introduced bundles of systems - so called clusters, we introduced bundles of transport requests - so called collections. With those new entities in place, we can synchronize across transport tracks, we can bundle over time, we can change project assignments, we have sophisticated downgrade protection in place, we have new import locks and, of course, end to end application logging… yeah, there's a lot inside this box labeled Central CTS (some more details are available here and here)! The power of those new CTS feature is leveraged exclusively by SAP Change Request Management (ChaRM) and SAP Quality Gate Managment (QGM). Intrigued? Then check out this blog post by Tobias Hauck!
But wait for it! There is one more thing, which definitely sweetens the deal: it now not only integrates seamlessly with SAP Change Request Management and SAP Quality Gate Management, but it super fuels the new flexibility in SAP software change control process tools. What you get? Well, that would be a spoiler… wouldn't it? You just have to wait a little bit longer, because we have decided to dedicate some of our time at this years SAP TechEdto this topic, exclusively! So don't miss out on those great lectures and hands-ons!
ITM207 Discover Change Control Management Based on a Central CTS (lecture) - Las Vegas / Amsterdam ITM208 Configure Central CTS Foundation for ChaRM and QGM (lecture) - Las Vegas / Amsterdam ITM161 Discover the New Flexibility of Change Request Management with Central CTS (hands-on) - Las Vegas / Amsterdam
Want to know more? Then Stayed tuned or visit us at SAP TechEd 2013!
It has been over a year since we first introduced the concepts behind central CTS here on SDN. We used this time wisely and built, what we believe to be the first step of the most powerful version of the SAP Change and Transport System ever. Over the course of the last year, we wrote a lot of code, discussed concepts, visited customers in the context of the Customer Engagement Initiative, gathered early feedback, presented a first version at SAP TechEd 2010 and made a major step towards a first delivery. However, there might be a little grain of salt here as well: our first shipment (we call it 'version one') will most likely not be available for general use, but we plan to make it available to a selected set of customers at first, who agreed to test-drive central CTS during the Customer Engagement Initiative. As we make progress with version two and its delivery, we will keep you informed about a general availability of the release.
For those, who might not really know much about central CTS, its concepts, ideas and solutions, let me give a quick recap on what we intend to deliver. From an evolutionary perspective, one could describe the growth of CTS as a step by step introduction of a set of tools able to handle more and more change management requirements that arose around SAP ecosystems.
It all started with the core CTS introduced in 1992. Over the years it was improved in an iterative fashion. Due to the fact, that system landscape grew more diverse over the years, including non-ABAP and even non-SAP systems, CTS was enhanced in 2007 to handle such landscapes with the well known and supported transport tools. A common transport system for different technologies was highly appreciated. However, it did not cover all aspects arising from divers landscapes: What about cross-technology dependent changes? What about downgrades and so-called 'over takers'? What about integration into higher level change management tools and processes? With central CTS, we plan to address some of those questions and create the next generation CTS. If you could not make it to SAP TechEd 2010, allow me to share two helpful links with you: the complete set of slides of the session ALM210: CTS – it's one tool to control your changes is available online, a live recording can be found here: Virtual SAP TechEd. Central CTS is not just an extension or enhancement of CTS, but together with CTS+ and the core CTS it constitutes the next generation CTS.
Please remember, that your feedback is honestly appreciated by the whole team developing central CTS - so keep it coming!
The existing SAP Change and Transport System (Change and Transport System) has grown over the years from early R/3 days into what it is today - a stable and proven solution for managing and transporting changes in the SAP ecosystem. As part of this evolutionary development CTS+ was introduced in 2007 as an enhancement for transporting changes across technology stacks. We intend to take the same iterative path to scale CTS even further.
Even in midsized business organizations IT landscapes tend to be rather large, diverse and complex. Software changes in such an environment demand for well educated administrators, project managers and developers. But without a solid, yet flexible tool base, even the best staff will not be able to handle change projects in a transparent way. Our goal is to deliver exactly this reliable tool base. Central CTS is planned to be the technological basis for that.
In order to give you the opportunity to learn more about the foundation of the next generation of transport tools, we would like to offer a technology preview in the form of a white paper that introduces the main concepts behind central CTS and illustrates them for a simple, yet illuminating scenario. The white paper is available for download here on SDN.
We see central CTS as the technological basis for the next generation of our products. As such, it should gratify your needs and solve your actual day to day problems. Consequently, we would like to get in touch with you, gather your feedback and let you take part in the development of central CTS. Please feel free to provide any feedback and ask questions in the comment section. Every comment will help us create the best product we possibly can!
Update 2014: Hey SAP-nerds, some years have passed by and we have made so progress in the cCTS and ChaRM area! Check out the latest news, here!
Login to follow, like, comment, share and bookmark content.