In part 1 of this mini-series I described why we decided to and which initial steps we took to set up a central ATC-system. Now that we have a brand new NW 7.52 system available, it's time for part 2 to list the activities we actually did to configure our systems. In order to do this, I again read through and followed the steps outlined in olga.dolinskaja's very helpful blog post series. I won't bore you with just repeating the information contained in those articles and the discusssions in the comment threads. Instead, I'll mention where we hit snags, how we circumvented them and anything else which I feel might be of interest.
In order to not unnecessarily inconvenience our colleagues with what would for sure become a series of trial and error, the first steps were done in the new central ATC- and a rarely used sandbox as a satellite dev-system. Most of the work was done by me and my colleague alexander_merz from our basis team. Alex focused on the relevant system setup like authorisations and OSS-notes and I spent my time mostly in the ATC- and SCI transactions to set things up in both the central and the satellite system. We also involved one of our colleagues to help with testing as needed.
One of the first things I noticed when taking a look at the central settings was the obvious lack of check variants. Apart from one default variant none were there. Luckily enough, a quick search found the solution: I simply had to go into SCI and use menue entry "Import check variants" to get them loaded. I however don't quite understand why they don't just come preloaded as a central system without check variants doesn't really make much sense, does it?
While I was working my way through Olga's first blog post, Alex was setting up the RFC-connection between the systems and straightening out authorisations. [Update, Oct. 22, 2018: As we learnt after go-live, it makes sense to set the language of the RFC-connection to English. This will avoid tool failures if users trigger the check while logged in with a language not installed in the central check system.] Based on recommendations we decided to start out with trusted connections for this even though this means that all developer usernames will need to be known in the central system. Once that was done, we were obviously keen to see if it worked, so I defined our first run series, picking a relatively small Z-package from the sandbox system and a check-variant from the central ATC-system fairly randomly and hit execute. Once the run had finished, we quickly noticed that we had been getting ahead of ourselves in our eagerness to see "something"! Instead of a long list of findings we got just a fairly small one but hundreds of "tool failures" in the sandbox system and more than 4,000 dumps listed in ST22 to go along with them!
We quickly realised that the sandbox system was missing many OSS-notes which Alex found and implemented in due course. Here is the list of the ones we had to get into the system but this will obviously vary depending on the system release you are currently on:
2485231 - Remote ATC Checks of Modifications and Enhancements
2270689 - Remote Analysis (for source system)
2587593 - ATC: Checkability of Modifications and Enhancements in Remote Checks - Developer Scenario
2190065 - ATC/CI: Remote Code Analysis - Object Provider Stub
2190065 - ATC/CI: Remote Code Analysis - Object Provider Stub
2381403 - Infrastructure for remote checks
2375864 - ATC: Remote Checks - Developer Scenario
2587593 - ATC: Checkability of Modifications and Enhancements in Remote Checks - Developer Scenario
2614006 - ATC remote check fails in developer scenario
One of the notes - 2270689 - even caused some timeouts during the download/implementation and a closer read of it revealed that a system parameter needed to be updated to avoid this from happening (and it wasn't even in fine print!).
It also helps to keep 2364916 - Recommended SAP Notes for using ATC to perform remote analysis handy as a quick reference for the various notes which might need to be implemented while setting up the systems.
Something else I was keen to explore were the S/4HANA readiness checks which I could see listed as check variants. So, I defined another run series, again picking a fairly random package and one of the relevant check-variants. The one thing I was fairly certain about, was that the package contained programs which did some stuff S/4HANA wouldn't be overly happy with like using an 18-character long field for material number or even worse, doing hard updates on SAP-tables. So, I was a bit mystified when those checks came back without any priority 1 findings but a lot more check failures than expected. How could that be?
Again, a search provided the answer and yet another OSS-Note needed to be implented in the central system to get simplifications loaded: 2241080 - SAP S/4HANA: Content for checking customer specific code. Once that was done and the run series was executed again, I was (somewhat and not really) happy to see 2,300+ findings!
I also experimented with defining a check-variant in the satellite system which actually makes use of one of the checks defined in the central system, like e.g. one of the S/4HANA readiness checks. And this worked as expected.
So, after a couple of hours work between the two of us, Alex and I managed to set things up to be able to run some initial checks either triggered from the central system on code in the satellite system or from code in the satellite system utilising one of the central check variants. The next steps will be setting up the exemption process and to decide which checks to include in the "master" check eventually to be used to prevent transport release from the development system. But these will be topics for future posts in this series, so please stay tuned!
Here are the links to the other parts of the series for easy reference:
Part 1: Setting the stage
Part 3: Tweaking the settings to our liking
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.
In order to not unnecessarily inconvenience our colleagues with what would for sure become a series of trial and error, the first steps were done in the new central ATC- and a rarely used sandbox as a satellite dev-system. Most of the work was done by me and my colleague alexander_merz from our basis team. Alex focused on the relevant system setup like authorisations and OSS-notes and I spent my time mostly in the ATC- and SCI transactions to set things up in both the central and the satellite system. We also involved one of our colleagues to help with testing as needed.
One of the first things I noticed when taking a look at the central settings was the obvious lack of check variants. Apart from one default variant none were there. Luckily enough, a quick search found the solution: I simply had to go into SCI and use menue entry "Import check variants" to get them loaded. I however don't quite understand why they don't just come preloaded as a central system without check variants doesn't really make much sense, does it?
While I was working my way through Olga's first blog post, Alex was setting up the RFC-connection between the systems and straightening out authorisations. [Update, Oct. 22, 2018: As we learnt after go-live, it makes sense to set the language of the RFC-connection to English. This will avoid tool failures if users trigger the check while logged in with a language not installed in the central check system.] Based on recommendations we decided to start out with trusted connections for this even though this means that all developer usernames will need to be known in the central system. Once that was done, we were obviously keen to see if it worked, so I defined our first run series, picking a relatively small Z-package from the sandbox system and a check-variant from the central ATC-system fairly randomly and hit execute. Once the run had finished, we quickly noticed that we had been getting ahead of ourselves in our eagerness to see "something"! Instead of a long list of findings we got just a fairly small one but hundreds of "tool failures" in the sandbox system and more than 4,000 dumps listed in ST22 to go along with them!
We quickly realised that the sandbox system was missing many OSS-notes which Alex found and implemented in due course. Here is the list of the ones we had to get into the system but this will obviously vary depending on the system release you are currently on:
2485231 - Remote ATC Checks of Modifications and Enhancements
2270689 - Remote Analysis (for source system)
2587593 - ATC: Checkability of Modifications and Enhancements in Remote Checks - Developer Scenario
2190065 - ATC/CI: Remote Code Analysis - Object Provider Stub
2190065 - ATC/CI: Remote Code Analysis - Object Provider Stub
2381403 - Infrastructure for remote checks
2375864 - ATC: Remote Checks - Developer Scenario
2587593 - ATC: Checkability of Modifications and Enhancements in Remote Checks - Developer Scenario
2614006 - ATC remote check fails in developer scenario
One of the notes - 2270689 - even caused some timeouts during the download/implementation and a closer read of it revealed that a system parameter needed to be updated to avoid this from happening (and it wasn't even in fine print!).
It also helps to keep 2364916 - Recommended SAP Notes for using ATC to perform remote analysis handy as a quick reference for the various notes which might need to be implemented while setting up the systems.
Something else I was keen to explore were the S/4HANA readiness checks which I could see listed as check variants. So, I defined another run series, again picking a fairly random package and one of the relevant check-variants. The one thing I was fairly certain about, was that the package contained programs which did some stuff S/4HANA wouldn't be overly happy with like using an 18-character long field for material number or even worse, doing hard updates on SAP-tables. So, I was a bit mystified when those checks came back without any priority 1 findings but a lot more check failures than expected. How could that be?
Again, a search provided the answer and yet another OSS-Note needed to be implented in the central system to get simplifications loaded: 2241080 - SAP S/4HANA: Content for checking customer specific code. Once that was done and the run series was executed again, I was (somewhat and not really) happy to see 2,300+ findings!
I also experimented with defining a check-variant in the satellite system which actually makes use of one of the checks defined in the central system, like e.g. one of the S/4HANA readiness checks. And this worked as expected.
So, after a couple of hours work between the two of us, Alex and I managed to set things up to be able to run some initial checks either triggered from the central system on code in the satellite system or from code in the satellite system utilising one of the central check variants. The next steps will be setting up the exemption process and to decide which checks to include in the "master" check eventually to be used to prevent transport release from the development system. But these will be topics for future posts in this series, so please stay tuned!
Here are the links to the other parts of the series for easy reference:
Part 1: Setting the stage
Part 3: Tweaking the settings to our liking
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:
6 Comments
