This is part 3 of my ongoing blog series about setting up our central ATC system.
Part 1: Setting the stage and Part 2: Preparing the systems
By now we've become fairly comfortable with how our new central ATC system behaves and how to connect satellite systems to it. So it's time to get down to the nitty-gritty details like prototyping the baseline checks, tweaking the message priorities and setting up the exemption process. In parallel, I'm putting together the necessary documentation to share with the developers before going live with central ATC checks in a couple of weeks from now.
The first thing I needed to do was to decide which checks to include in the variant for what would define our baseline. In order to do that, I however first had to think about and define which checks should go into our future check-variants used during task/transport release where prio 1 & 2 findings will prevent the release. As my related question unfortunately didn't get any responses I just went ahead and started with the check-variant we already had, taking out and adding checks not quite at random but basically just following my "gut-feeling" of what would make sense for us and what wouldn't.
We made the decision to have some checks prevent task/transport release even if they came from "old" code and not just from newly created or changed sections. One such example are hard updates to SAP-tables (with the exception of TVARVC) where we know that we have way too many of in legacy code. We plan to use the exemption process to at least document the places and reasons for why these updates are in the code (and why they cannot easily be changed to better methods). Because of this decision, the check-variant used for the baselines contains a few checks less than the one in the works for transport release.
Once I had the check-variant defined I set up a run series to check all objects in all packages starting with "Z*" in the sandbox system:
Some 5 hours later, the job had finished with just a "few" findings and check failures:
The missing prerequisites errors no longer occurred for the impacted objects in a rerun after we downloaded an updated version of OSS-Note 2270689 – Remote Analysis (for source system) in the sandbox system. The other errors - as far as I can tell - are actual issues in the source code like syntax-errors or missing screen-definitions.
One thing was a bit weird while the checks for the baseline were being executed: for most of the time, refreshing the status screen showed updates in increments of 50 objects and the process kept running at a steady pace. But during some periods of time (more than an hour actually) nothing much happened as far as visible progress goes. Checking via SM50 it looked as if the process was somewhat stuck in routines related to class CL_CI_PROVIDE_CHECKSUM where - judging from taking some peeks via SAT - quite a lot happened in just a few seconds, with some counts getting into the high 10th of thousands within 10 seconds.
After getting the results I added them to the baseline:
I then "played" with the results to check that this really works as described in the related blog post published by olga.dolinskaja . And, guess what? It does!
One task I was looking forward to the least was tweaking the message priorities. Even though this can be done easily enough from either transaction ATC or SCI and the check variants definition by going to Code Inspector --> Management of --> Message Priorities it is a bit of a tedious task.
Our plan is to start with just a few checks preventing a task/transport release which in turn entails having to reclassify quite a lot of checks from message priority 1 or 2 to 3. In order to know which checks needed to be tweaked, we did the following steps:
Doing it like this has the advantage, that I can see how the findings from a transport change from day to day dependent on the tweaks I apply to the priorities. I therefore don't have to guess, what will happen, but will actually know (or so I hope!). It should also help with not inconveniencing the developers too much once we go live as I can tell - and show! - them what to expect beforehand.
ABAP development happens in many locations and also by external developers around the globe so we knew in advance that we'd have to take a close look at how best to define the exemption process before going live with checks preventing the release of tasks/transports. Of particular concern was the apparent restriction (described in another of Olga's neat blog posts) that a developer needed to select a specific approver for an exemption request as most developers wouldn't really know who of the perhaps handful potential approvers might actually be available to "hit the button" at any given time.
We have now figured out a way to do this within the current environment:
We already checked and when everybody a) has the required authorizations and b) is listed as an approver in the ATC "Maintain Approver" settings exemption requests can be updated by whoever is available - it doesn't have to be the ID listed as approver. Once the approval or rejection is done, the username switches to whoever actually did it.
At first, it looked as if we'd had to manually tweak the settings of the job to send out notifications about requested and processed exemptions because the standard configuration would only run the job once per day - obviously not enough for our requirements! Luckily enough, we found OSS-Note 2619387 - ATC: Downport Immediate E-Mail Notification and after its implementation, it's now possible to trigger notifications immediately:
This should hopefully give us the needed flexibility to turn around exemption requests fairly quickly - esp. as we hope to start all of this with just a small set of checks where exemptions might play a role and get requested.
To get our local, global and external developers on board with the new process, I already invited them to another workshop-like session during which I'll show them what has been set up and how we plan to implement it. After the session - and before I go on vacation 🙂 - we'll go live with the newly defined check-variant BUT without preventing task/transport release for a couple of weeks. That way, everybody can get accustomed to the new checks and can also try the exemption process without potential rejections having any kind of real effect. The time can also be used to collect feedback about which message priorities might still need to be tweaked before really hitting the switch.
That's it for now - I'll keep you posted about how it goes the closer we get to the final stage.
Here are the links to the other parts of the series for easy reference:
Part 1: Setting the stage
Part 2: Preparing the systems
Part 4: The final stretch
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.
Part 1: Setting the stage and Part 2: Preparing the systems
By now we've become fairly comfortable with how our new central ATC system behaves and how to connect satellite systems to it. So it's time to get down to the nitty-gritty details like prototyping the baseline checks, tweaking the message priorities and setting up the exemption process. In parallel, I'm putting together the necessary documentation to share with the developers before going live with central ATC checks in a couple of weeks from now.
Setting the baseline
The first thing I needed to do was to decide which checks to include in the variant for what would define our baseline. In order to do that, I however first had to think about and define which checks should go into our future check-variants used during task/transport release where prio 1 & 2 findings will prevent the release. As my related question unfortunately didn't get any responses I just went ahead and started with the check-variant we already had, taking out and adding checks not quite at random but basically just following my "gut-feeling" of what would make sense for us and what wouldn't.
We made the decision to have some checks prevent task/transport release even if they came from "old" code and not just from newly created or changed sections. One such example are hard updates to SAP-tables (with the exception of TVARVC) where we know that we have way too many of in legacy code. We plan to use the exemption process to at least document the places and reasons for why these updates are in the code (and why they cannot easily be changed to better methods). Because of this decision, the check-variant used for the baselines contains a few checks less than the one in the works for transport release.
Once I had the check-variant defined I set up a run series to check all objects in all packages starting with "Z*" in the sandbox system:
Some 5 hours later, the job had finished with just a "few" findings and check failures:
The missing prerequisites errors no longer occurred for the impacted objects in a rerun after we downloaded an updated version of OSS-Note 2270689 – Remote Analysis (for source system) in the sandbox system. The other errors - as far as I can tell - are actual issues in the source code like syntax-errors or missing screen-definitions.
One thing was a bit weird while the checks for the baseline were being executed: for most of the time, refreshing the status screen showed updates in increments of 50 objects and the process kept running at a steady pace. But during some periods of time (more than an hour actually) nothing much happened as far as visible progress goes. Checking via SM50 it looked as if the process was somewhat stuck in routines related to class CL_CI_PROVIDE_CHECKSUM where - judging from taking some peeks via SAT - quite a lot happened in just a few seconds, with some counts getting into the high 10th of thousands within 10 seconds.
After getting the results I added them to the baseline:
I then "played" with the results to check that this really works as described in the related blog post published by olga.dolinskaja . And, guess what? It does!
Tweaking the message priorities
One task I was looking forward to the least was tweaking the message priorities. Even though this can be done easily enough from either transaction ATC or SCI and the check variants definition by going to Code Inspector --> Management of --> Message Priorities it is a bit of a tedious task.
Our plan is to start with just a few checks preventing a task/transport release which in turn entails having to reclassify quite a lot of checks from message priority 1 or 2 to 3. In order to know which checks needed to be tweaked, we did the following steps:
- Properly connected our development systems via trusted-RFC connections to the central ATC system
- Defined the central check variant to be used during task/transport release: CHECKS_TRANSPORT_RELEASE (tip: copy the name to the clipboard as there's no F4-help in the satellite systems!)
- Defined the check variants in the satellite development systems with reference to the central variant in the check system: CENTRAL_TRANSPORT_RELEASE (I plan to make more such referenced checks available for developers and will have all the variant names start with "CENTRAL")
- Have a program select all open transports once a day and execute the ATC-checks for its objects via the central check now available (some more details about this step can be found here)
- Take a look each day at the results in the satellite systems to see which findings get flagged with which priority and update them as needed to get closer to the envisioned future state for task/transport release
Doing it like this has the advantage, that I can see how the findings from a transport change from day to day dependent on the tweaks I apply to the priorities. I therefore don't have to guess, what will happen, but will actually know (or so I hope!). It should also help with not inconveniencing the developers too much once we go live as I can tell - and show! - them what to expect beforehand.
Defining the exemption process
ABAP development happens in many locations and also by external developers around the globe so we knew in advance that we'd have to take a close look at how best to define the exemption process before going live with checks preventing the release of tasks/transports. Of particular concern was the apparent restriction (described in another of Olga's neat blog posts) that a developer needed to select a specific approver for an exemption request as most developers wouldn't really know who of the perhaps handful potential approvers might actually be available to "hit the button" at any given time.
We have now figured out a way to do this within the current environment:
- We defined a new user "ATC_APPROVER" which is available in the satellite systems and the central ATC system with the needed authorizations
- We will have an email group address created for this user
- Emails triggered by the exemption process will go to this group address from where they'll be passed on to the actual approvers
- The point person (or whoever gets to it first) logs in to the central ATC-system with her/his own user ID and approves or rejects the request(s)
We already checked and when everybody a) has the required authorizations and b) is listed as an approver in the ATC "Maintain Approver" settings exemption requests can be updated by whoever is available - it doesn't have to be the ID listed as approver. Once the approval or rejection is done, the username switches to whoever actually did it.
At first, it looked as if we'd had to manually tweak the settings of the job to send out notifications about requested and processed exemptions because the standard configuration would only run the job once per day - obviously not enough for our requirements! Luckily enough, we found OSS-Note 2619387 - ATC: Downport Immediate E-Mail Notification and after its implementation, it's now possible to trigger notifications immediately:
This should hopefully give us the needed flexibility to turn around exemption requests fairly quickly - esp. as we hope to start all of this with just a small set of checks where exemptions might play a role and get requested.
Next Steps
To get our local, global and external developers on board with the new process, I already invited them to another workshop-like session during which I'll show them what has been set up and how we plan to implement it. After the session - and before I go on vacation 🙂 - we'll go live with the newly defined check-variant BUT without preventing task/transport release for a couple of weeks. That way, everybody can get accustomed to the new checks and can also try the exemption process without potential rejections having any kind of real effect. The time can also be used to collect feedback about which message priorities might still need to be tweaked before really hitting the switch.
That's it for now - I'll keep you posted about how it goes the closer we get to the final stage.
Here are the links to the other parts of the series for easy reference:
Part 1: Setting the stage
Part 2: Preparing the systems
Part 4: The final stretch
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.
- SAP Managed Tags:
23 Comments
| User | Count |
|---|---|
| 4 | |
| 2 | |
| 2 | |
| 2 | |
| 2 | |
| 1 | |
| 1 | |
| 1 | |
| 1 | |
| 1 |
