Skip to Content
1
Jul 24, 2018 at 10:40 AM

How best to define check-variants to be eventually used during transport-release?

537 Views

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:

  1. Is this the right approach?
  2. Does it make sense to include S/4HANA checks (eventually set to priority 3 to just give a heads-up) in the variant used during transport-release or should this be tackled separately?
  3. Am I going about this in the right sequence?
  4. Do you have any recommendations of what I should and shouldn't do?

Looking forward to your thoughts and comments!

Cheers

Baerbel

Attachments