I'm currently configuring our new central system for ATC-checks (for some background, please see here and here) and before I get lost in the details, I'd appreciate feedback on my current thinking of how to actually define the check-variants. The system is on NW 7.52 with all the required OSS-Notes applied. The satellite-systems are on NW 7.50 and also have the needed OSS-Notes.
My starting point was the check-variant currently used during transport-release (without blocking it) which in turn is an adapted version of SAP's DEFAULT variant with some checks from FUNCTIONAL_DB and PERFORMANCE_DB. So I re-created the variant in the central system picking and chosing most of the checks I already had - if they showed up as RFC-enabled. I also picked some of the S/4HANA readiness checks.
Here are some of them:
I then did a trial run with one package in a sandbox system and after about 2 hours got the results with quite a "few" findings - well make that a couple of thousend priority 1 findings!
I plan to take this hopefully fairly representative result to now define the checks used in the variant to create the baseline. My thinking is, that I'll start with a copy of the variant I now have and uncheck some of the checks which I'd eventually like to still show during transport release - like e.g. direct updates on SAP-tables even if they've been in the program for ages. As this will then be a priority 1 finding (it's a 3 right now), requiring either getting fixed or asking for an exemption, we'll at least become more aware of where this type of processing is used in programs requiring changes i.e. actively used.
The other thing I need to do - and the one I'm looking forward to the least! - is to tweak the priorities for many of the checks. Most of the ones currently defined as 1 or 2 will become a 3 in order to still get flagged but to not prevent the release of a transport. But there are also some priority 3 findings (like the one mentioned above regarding hard updates on SAP-tables) will become a priority 1 finding.
I will of course offer some sessions / workshops for our developers before we role this out in earnest. I already gave them some fair warning that "something" is coming but that was before we actually had the central system up, so I then couldn't show them much about the baseline or the exemption process.
At the moment I have these questions:
Looking forward to your thoughts and comments!
Cheers
Baerbel
Here is an update (not just but to also "bump" this question as I'm really interested to get some answers):
After doing some initial trials with sandbox systems, we also "attached" our two main development systems (NW 7.50, EHP 8) to our central ATC system.
I then defined check variants in the satellite systems utilising the centrally defined variant tentatively planned to eventually being used during transport release. To get a better idea of how actual development will later be affected and to also tweak the variant definition if and as needed early on, I'm using this new check variant in a daily batch-job to run ATC-checks on objects contained in modifiable transport requests in the dev-systems. I receive a daily email from this and can tell by the summary of the ATC-results if it's worthwhile to check them directly in the system. In case that you are interested in how this gets done, please see my earlier blog post where I describe the functionality.
Dependend on the results, I'll either decide to exclude certain checks and/or to tweak their message priorities. There are two things I'd like to avoid:
Bottom line: I'm trying to find the right the balance
Can anybody help me do that?
Cheers
Baerbel
My response would still be the same as I posted in your very early question on this topic - make it very forgiving, maybe just one or two blocking checks. Let it run for a week or two to get a feel for the volume of change and number of errors, then start upping the priorities on other checks.
Also consider running ATC as a regular (nightly) job - possibly with different checks. This way you can chart the change over time.
Add a comment