Setting up a central ATC-system – Part 1: Setting the stage
We are getting ever closer to setting up a central ATC-system so I thought it might be of interest to start a little blog series detailing the various steps as we actually walk through the process helpfully outlined in Olga Dolinskaja‘s blog post series. At the moment I don’t yet know how many posts this will turn into or when the next part will get published. I’ll just play that by ear.
We have a pretty complex SAP environment but for now will concentrate on our two main ERP development systems which feed two “lines”: one for the headquarter and a second for all the subsidiaries around the globe. We also have a central dev-system which feeds into the two main development lines. This is mainly used for SAP- and dictionary objects to keep these in-sync across the two main landscapes. ABAP-code in Z-objects is only maintained in some rare cases in this central system.
Development for the headquarter system (DEV-HQ) is mostly done by internal and external developers located in Germany, with some exceptions being large-scale projects where development gets done by contracted consultants. Development for the worldwide systems (DEV-WW) is in parts also done by our team of internal and external developers, but some countries either also have their own small teams or look for contractors to especially get legal requirements implemented.
Since end of November 2017 we are on NW 7.50 EHP8 with HANA-DB and had our Z-code updated by Smartshift to meet the HANA-requirements. Thus far, I have ATC enabled with HANA-checks in both the DEV-HQ and DEV-WW system and it also kicks in during transport release, but doesn’t prevent it. So, we obviously currently run the risk of non-HANA-ready code creeping back into our Z-code. As we want to prevent this we were given the green light to set up a central ATC-system based on NW 7.52 with all the capabilities that brings with it, like the option to work with a baseline and do the checks already on task-release.
As I’m writing this, the system is getting set up, so I haven’t yet been able to actually see it. Once it has technically been set up, our basis team will prepare it for our usage and then it’ll be my turn to do the ATC-customizing.
I’m using this time to get the word out to our developers, starting with the ones working from our headquarters in Winnenden. This is not really the first time they’ll hear about ATC as information about what it is and how we use it has been available in our development guidelines for quite some time leading up to the migration to the HANA DB. There’s also mention of the fact that we’ll eventually switch to preventing transport release from the DEV-systems as soon as that is feasible. So, they’ve already had some “fair warning” that this is coming!
My current plan is to activate the central ATC-checks for DEV-HQ first, see how that goes, and then add DEV-WW in a second step. So, I invited our local developers to a short informational session to show them what’s coming and why. These took about 2 hours to prepare and 1 hour each to hold. I offered two sessions to accommodate the different days in a week some of them are available either in the office or via web-conference.
Sometime in June I hope to get my hands on the central system to do the customizing. This will not just involve the one-off settings but also deciding which messages should get which priority with only a few of them designated as “1” or “2” in order to not have too many findings potentially preventing a transport release. As an aside, I’d very much like to have an option in customizing to only have prio “1” messages prevent a release and not also prio “2” as there are just way too many messages which currently fall into one of these two categories.
Once we have the settings defined, we’ll create our very first baseline for all the Z-code currently in the DEV-HQ system. We’ll also have to give setting up the exemption process some thought as the standard option where the developer picks one of the designated approvers will not quite work in our case. We’ll need to find a possibiity to have the notification go out to a group of potential approvers and to also have the process kick in a lot more often than the default setting of once per day. But all of this will most likely be material enough for a second part in this blog series – so please stay tuned till then!
Here are the links to the other parts of the series for easy reference:
Part 3: Tweaking the settings to our liking
Part 5: Keeping an eye on things (January 2019)
Part 6 – accumulated FAQs (March 2021)
For the overall journey, please see the long, long winding road edition.
As far as I understand, the checks in the central variant have to be RFC enabled in order to work via the central ATC? Looking into my 751 system, few of the in the "Programming Conventions", "Metric and Statistics", "Dynamic Tests" and "User Interfaces" categories are RFC enabled.
Will you be decreasing the number of checks run via the central ATC setup?
yes, it's my understanding as well that the checks have to be RFC-enabled in order to use them for central ATC-checks. We'll start with a 7.52 system so I hope that more checks will be available than with a 7.51 system. Our main focus will however be on HANA and other mostly database-access related checks we deem critical and not so much on general checks liks the ones you mention.
Will be interesting to see what will and what will not be available!
We are on 7.51SP3 and most of the "important" checks are already RFC enabled.
Bärbel Winkler : we currently are on the same way. One small Gateway system is alreay connected to the central ATC, the first bigger development system should be ready in a few weeks. We want to give a small ATC training for the developers first.
... and we've got a small design problem which we have to solve first: because we are only allowed to use trusted RFC, we have to have all current and future developers also on the central system...
Looking forward to your next blog post in this series.
Thanks Bärbel Winkler for the interesting blog. Looking forward to other blogs in the series. Every client has a different landscape strategy which impacts the configuration of different check. Like in yours case you have one for headquarter and one for subsidiaries, in our case we have segregation of system at division level then further at regional level. Looking forward to your experience and implementing some of it when i get a chance in my case:)
Hi Bärbel Winkler
Very interested to see this blog as I have been setting up a (now) 7.52 instance of the Central ATC for the last 9 months or more (part time). Certainly happy to provide feedback on any issues you may encounter.
I have noticed some of your posts on Olga Dolinskaja‘s blog post series as I have also posted on here multiple times. You also have the requirement to have an approver group which is hopefully to be addressed by SAP.
So far, I have connected 3 systems to our Cental ATC, One 7.31, one 7.52 and one 7.50 system. Technically, this is mostly fine (although currently an update to note 2270689 is causing an issue on implemetation in the remote systems). I have enabled exemptions on all 3 systems (1 blocks transports, and 2 are info only currently). I have also tried setting a baseline, although this has not been as easy as initially thought as all code does not appear to be captured on the initial selection.
Personally though, I see the biggest issue for us is organisationally, so if you are able to provide any details on how you will operate the ATC from this perspective, that woudl be great.