Over the last couple of months, I shared our steps to set up our central ATC system in a series of four blog posts:
Part 1: Setting the stage
Part 2: Preparing the systems
Part 3: Tweaking the settings to our liking
Part 4: The final stretch
Part 5: Keeping an eye on things (January 2019)
While collecting my thoughts for a planned presentation at DSAG's ABAP developer group meeting, I jotted down rough dates for our various activities and ended up with a stack of individual notes. Instead of just using these to build a timeline for the presentation, I thought that it might be useful to also create a blog post based on them detailing our journey from start to finish.
So, let's get started on this long, long winding road....
Once upon a time on a cold and dreary day in the winter of 2016 .....
No, scratch that, I don't have a clue of what the weather was like and which day it was when I first happened upon olga.dolinskaja 's blog post "Remote Code Analysis in ATC – One central check system for multiple systems on various releases. I only know that it was after December 16, 2016 as this is the date Olga published it. What I however vividly remember is that I was immediately hooked on the idea of getting such a system installed as it just made perfect sense to me. Needless to say, however that it was way too late in the year to get it on that year's wishlist for Christmas!
A proof of concept for a move to S/4HANA was started but it soon became apparent that it would make more sense to do the conversion to HANA-DB first. However, the sandbox-system we had available for the PoC gave us access to improved ATC-functionality to check out than what we had in our ERP-systems. Talk about whetting my appetite!
An upgrade to HANA DB was planned for later in 2017 and I had been dabbling a bit with check variants and ATC in our development systems by that time. So I decided to go with what I had, defined an enhanced check variant, put together some information for our developers about code inspector (SCI) and ABAP test cockpit (ATC) and made all of this available in our guidelines (which we keep in a Confluence space for easy access and maintenance).
I also added ATC-checks to already executed SCI-checks during transport release. The purpose of this was mainly to give the developers some exposure to these - for us - new tools.
With the help of Smartshift we adapted our custom code for the conversion to HANA-DB which happened as part of an upgrade to NW 750 with EHP8.
Our initial plans had been to switch-on blocking on transport release for the ATC-checks fairly soon after the upgrade to avoid having "HANA-critical" code leave the dev-systems. But, this turned out to not be feasible as we didn't yet have the creation of a baseline as an option with NW 750. And even with the code adapted in preparation for HANA-DB we knew that we'd make our developers very unhappy with long lists of ATC-findings to correct in code they didn't actually touch with their latest changes! So, we shelved that plan for the time being. But, this gave us the first good reason to really start looking into setting up a central ATC-system!
Plans to move in the direction toward S/4HANA started to really take shape again and with that the need for S/4HANA readiness checks, something else we couldn't yet do with NW 750. And with that we had a second good reason to set up our own central ATC-system.
It also was clear, that the longer we waited with setting things in motion the higher the likelihood of preventable issues happening due to HANA-critical code going undetected would be.
After getting the green light for it from management, we embarked on a project to have our own central ATC-system intalled. Yay! With the project's approval I started to look forward to getting my hands on the system in the not too distant future.
From reading Olga's blog posts I was aware, that quite a few tasks would be needed to properly configure the ATC-system. In order to not lose track, I started to collect information in a central repository. This included links to said blog posts, relevant OSS-Notes, SAP Community discussion threads and whatever else I could get my hands on as far as tips & tricks go.
In order to take our developers along for the ride, I put together a presentation for an initial workshop to give them a first look at what would be coming later in the year. As we didn't yet have the central ATC-system available this first get-together mostly hinged on Powerpoint and a discussion. You can read more details about setting the stage in the first part of my blog series.
The system was delivered by our service provider in July and alexander_merz did the basic customizing to get it up and running. He also had to apply several OSS-Notes to get the latest versions of everything.
Next, he connected one of our sandbox systems to the new ATC-system where also quite a few OSS-notes needed to be applied. The details of these activities are described in part 2 of my blog series.
Quite a lot happened during August when we connected our development systems to the central ATC system, copied over the settings from the sandbox, defined the baselines and the central check variant to be used during transport release. I also started running daily ATC-checks for transports modifiable in the dev-systems to get a better handle on how things looked like and to help with tweaking the message priorities. Part 3 of my blog series has the details.
At the end of August and beginning of September I offered another workshop for the developers and this time I could show them how things actually worked and looked like in the system. Once these workshops were done and dusted I switched the checks on task- & transport-release to central checks but still without blocking upon release. For the details, please see part 4 of my blog series.
The rest of September nothing much happened as I was on vacation.
Once back from vacation, I invited the developers to a feedback session to collect and discuss any potential issues they might have identified while I was away. Of the originally planned 90 minutes we only needed about 30 which I took as a good sign that no big issues were looming and that everything was ready and in place to switch-on blocking on transport release.
On October 18, 2018 at 12:00 I flipped the switch in the first of two development systems to "block on any error (priority 1 or 2)". The second system followed suit the next day and I sent emails out to the developers to give them a heads-up that the "long awaited" switch had now occurred.
And to record the weather for myself and posterity: this happened on an unseasonally warm and sunny day for mid-October with temperatures hovering around 20°C as they had been for quite a while.
I'd be interested to learn whether or not our road from getting hooked on the idea of a central ATC-system to actually getting it up and running is typical. So please share your experiences in the comments. Thanks!
Part 1: Setting the stage
Part 2: Preparing the systems
Part 3: Tweaking the settings to our liking
Part 4: The final stretch
Part 5: Keeping an eye on things (January 2019)
While collecting my thoughts for a planned presentation at DSAG's ABAP developer group meeting, I jotted down rough dates for our various activities and ended up with a stack of individual notes. Instead of just using these to build a timeline for the presentation, I thought that it might be useful to also create a blog post based on them detailing our journey from start to finish.
Yes, I jot down notes like these in German!
So, let's get started on this long, long winding road....
December 2016
Once upon a time on a cold and dreary day in the winter of 2016 .....
No, scratch that, I don't have a clue of what the weather was like and which day it was when I first happened upon olga.dolinskaja 's blog post "Remote Code Analysis in ATC – One central check system for multiple systems on various releases. I only know that it was after December 16, 2016 as this is the date Olga published it. What I however vividly remember is that I was immediately hooked on the idea of getting such a system installed as it just made perfect sense to me. Needless to say, however that it was way too late in the year to get it on that year's wishlist for Christmas!
January 2017
A proof of concept for a move to S/4HANA was started but it soon became apparent that it would make more sense to do the conversion to HANA-DB first. However, the sandbox-system we had available for the PoC gave us access to improved ATC-functionality to check out than what we had in our ERP-systems. Talk about whetting my appetite!
March 2017
An upgrade to HANA DB was planned for later in 2017 and I had been dabbling a bit with check variants and ATC in our development systems by that time. So I decided to go with what I had, defined an enhanced check variant, put together some information for our developers about code inspector (SCI) and ABAP test cockpit (ATC) and made all of this available in our guidelines (which we keep in a Confluence space for easy access and maintenance).
I also added ATC-checks to already executed SCI-checks during transport release. The purpose of this was mainly to give the developers some exposure to these - for us - new tools.
Announcements posted in our guidelines webpage
November 2017
With the help of Smartshift we adapted our custom code for the conversion to HANA-DB which happened as part of an upgrade to NW 750 with EHP8.
Our initial plans had been to switch-on blocking on transport release for the ATC-checks fairly soon after the upgrade to avoid having "HANA-critical" code leave the dev-systems. But, this turned out to not be feasible as we didn't yet have the creation of a baseline as an option with NW 750. And even with the code adapted in preparation for HANA-DB we knew that we'd make our developers very unhappy with long lists of ATC-findings to correct in code they didn't actually touch with their latest changes! So, we shelved that plan for the time being. But, this gave us the first good reason to really start looking into setting up a central ATC-system!
Winter 2017/2018
Plans to move in the direction toward S/4HANA started to really take shape again and with that the need for S/4HANA readiness checks, something else we couldn't yet do with NW 750. And with that we had a second good reason to set up our own central ATC-system.
It also was clear, that the longer we waited with setting things in motion the higher the likelihood of preventable issues happening due to HANA-critical code going undetected would be.
March 2018
After getting the green light for it from management, we embarked on a project to have our own central ATC-system intalled. Yay! With the project's approval I started to look forward to getting my hands on the system in the not too distant future.
Source: Wikimedia (CC)
April 2018
From reading Olga's blog posts I was aware, that quite a few tasks would be needed to properly configure the ATC-system. In order to not lose track, I started to collect information in a central repository. This included links to said blog posts, relevant OSS-Notes, SAP Community discussion threads and whatever else I could get my hands on as far as tips & tricks go.
May 2018
In order to take our developers along for the ride, I put together a presentation for an initial workshop to give them a first look at what would be coming later in the year. As we didn't yet have the central ATC-system available this first get-together mostly hinged on Powerpoint and a discussion. You can read more details about setting the stage in the first part of my blog series.
July 2018
The system was delivered by our service provider in July and alexander_merz did the basic customizing to get it up and running. He also had to apply several OSS-Notes to get the latest versions of everything.
Next, he connected one of our sandbox systems to the new ATC-system where also quite a few OSS-notes needed to be applied. The details of these activities are described in part 2 of my blog series.
August 2018
Quite a lot happened during August when we connected our development systems to the central ATC system, copied over the settings from the sandbox, defined the baselines and the central check variant to be used during transport release. I also started running daily ATC-checks for transports modifiable in the dev-systems to get a better handle on how things looked like and to help with tweaking the message priorities. Part 3 of my blog series has the details.
September 2018
At the end of August and beginning of September I offered another workshop for the developers and this time I could show them how things actually worked and looked like in the system. Once these workshops were done and dusted I switched the checks on task- & transport-release to central checks but still without blocking upon release. For the details, please see part 4 of my blog series.
The rest of September nothing much happened as I was on vacation.
Mönkebude beach at the Baltic Sea
October 2018
Once back from vacation, I invited the developers to a feedback session to collect and discuss any potential issues they might have identified while I was away. Of the originally planned 90 minutes we only needed about 30 which I took as a good sign that no big issues were looming and that everything was ready and in place to switch-on blocking on transport release.
On October 18, 2018 at 12:00 I flipped the switch in the first of two development systems to "block on any error (priority 1 or 2)". The second system followed suit the next day and I sent emails out to the developers to give them a heads-up that the "long awaited" switch had now occurred.
And to record the weather for myself and posterity: this happened on an unseasonally warm and sunny day for mid-October with temperatures hovering around 20°C as they had been for quite a while.
I'd be interested to learn whether or not our road from getting hooked on the idea of a central ATC-system to actually getting it up and running is typical. So please share your experiences in the comments. Thanks!
- SAP Managed Tags:
