.png&w=640&q=75)
After the introduction on how to set up and start the SAP S/4HANA tool for Readiness Check, in this second episode of the “S/4HANA” mini-series, I’m going to deal with another fundamental topic that you have to face when setting up a project to switch from SAP ERP / ECC 6.0 to a SAP S/4HANA system:
the complete ABAP Custom Code review
In the first blog (“Prevention is better than cure: start SAP S/4HANA Readiness Check Now!“), we’ve seen how the SAP Readiness Check for SAP S / 4HANA already introduces – with a high-level perspective – the categories of adjustments to be applied to the custom code. However, the Readiness Check does not provide details of the objects impacted by these changes.
To retrieve this information, it is necessary to use additional “tools”.
Let’s see together which ones.
Below I’m going to describe in the following order:
Before describing in detail how to analyze your custom code, you need to be aware of how switching to SAP S/4HANA would have a significant impact on the structure of existing custom programs.
In view of planning a S4 transition project, there are three main areas of interventions to be considered on the ABAP custom code:
The third area of intervention is instead only optional, but it is strongly recommended.
At first glance, it may seem to be facing a “titanic” effort, especially for those SAP customers who make massive recourse to Z * programs …
However – in the final part of the blog – we will see how it is possible to limit the list of custom objects to be adjusted (from the performance point of view) to the only objects which are actually used in the system.
The reference tool for analyzing the custom code is the ABAP Test Cockpit (ATC).
It is a good “old” SAP Standard tool, designed to perform automatic tests on the ABAP code, which was more recently extended to analyze the custom code also from the point of view of its “behaviour” on a SAP S/4HANA system.
The steps necessary for its proper use are well described by the two SAP OSS notes:
Now that the tool has been identified, let’s see what the system requirements are, or rather the requirements for the systems landscape needed to run the code analysis.
It is essential to underline that – to perform the analysis of the custom code on the ECC source system – it is necessary to use an additional SAP system (called Evaluation System), based on a NetWeaver (SAP_BASIS) 7.51 or higher release.
(It is not mandatory, however, for the Evaluation System to have installed a particular application component: a bare and raw SAP NetWeaver system wil be enough).
The final architecture for the analysis will look like the following:
The ECC system to be choose as object for the analysis (the so-called Checked System) should be – possibly – the Development System.
The reason behind is to be sure to conduct the analysis of all the ABAP custom code, including the one not yet released to production and / or test environments.
The following OSS notes must also be installed on the identified Checked System:
On the Evaluation System you will then need to install several OSS notes, depending on the NetWeaver release and the installed Support Package level. The two notes above mentioned (2364916 and 2436688) detail the list of all the other required notes to implement.
Ad ogni modo per evitare di dover implementare troppe note, si raccomanda di installare come Evaluation system un SAP_BASIS 7.51 SP05 o superiore, oppure un SAP_BASIS 7.52 SP01 o superiore.
However, to avoid having to implement too many notes, it is recommended to install as an Evaluation system a SAP_BASIS 7.51 SP05 or higher, or a SAP_BASIS 7.52 SP01 or higher.
Did you define the landscape and have all the necessary notes been installed?
Well! We can eventually proceed with the analysis of ABAP Custom code.
All we need to do now is to follow these 5 steps in a sequence to get the results of the analysis, by finally bringing to light all the gaps that separate us from having an ABAP code optimized till perfection for S/4HANA:
Define a RFC connection between the Evaluation and the Checked System
Download the SAP S/4HANA Simplification Database from SAP Service Marketplace.
Install the Simplification Database into the Evaluation System.
Perform the ATC technical configuration on the Evaluation System
Run S4HANA_READINESS_REMOTE variant via ATC
As a first step, simply define a RFC connection between the Evaluation System and the Checked System; it is recommended to define a Trusted RFC Connection between the two systems.
Alternatively, you can opt for a traditional RFC connection, with an RFC user having the authorization role SAP_SATC_ADMIN.
More details on how to define the connection between the Evaluation System and the Checked System are available at the following link: Setting up RFC Communications Between the ATC Master System and Satellite Development Systems
The Simplification Database contains all the Simplification Items that SAP makes available with every new version of SAP S / 4HANA.
At the time of writing (please check for updates), the latest SAP S / 4HANA onPremise release is the 1709 Feature Pack Stacks 01 (FPS01) and the Simplification Database is updated to the Content Patch 6 version:
You can download it by following the instructions of OSS Note:
Always following the indications of note 2241080, it is possible to install the Simplification Database on the Evaluation System using the transaction SYCM:
In the pop-up, you will have to select the zip file previously downloaded.
And if everything went well, you can finally view the Simplification Database, here it is:
First of all, it is necessary to define the role of the Evaluation System as a system where the ATC Checks are processed starting from the Object Providers.
We are in practice saying that the system not only analyses the local ABAP code, but it also scans all the code supplied by the various providers connected to the central system. The analyzed ECC system will therefore be configured as a provider.To do this, we launch the ATC transaction and select the “System Role” node:
in the next screen, just mark the “ATC Checks by Object Providers Only” radio button and save:
Once defined the system ATC role, let’s go to configure the ECC system (Checked System) as ATC provider: from transaction ATC just select the node “Object Providers”:
In the next maintenance view the following must be set:
A “System Group” – i.e. a homogeneous group of systems sharing the same release An “Object Provider” – i.e. the ECC system we intend to analyze Insert a System Group (for example 702 in case we are going to run the analysis for ECC systems based on NetWeaver 702):
In the Object Provider folder we need to hook the RFC destination previously define in Par.#1: “Define a RFC connection between the Evaluation and the Checked System”:
Once the customization for the ATC has been defined, we can schedule our analysis via RFC which points to the ECC system under examination.
Always from the ATC transaction, we select the “Schedule Runs” node:
Let’s select the “Create” button:
and let’s input the following data:
It is important to remark that if we have dedicated customer namespaces (type / XYZ /) that we want to submit for analysis, these namespaces must be defined by SE03 transaction also on the Evaluation System.
It is also possible to select objects using Object Sets defined in the remote system; in this case it will be necessary to define the Object Set via the SCI transaction on the ECC system.
Once the above values have been entered, we can save our configuration.
After saving our configuration, we can schedule it by selecting the “Schedule” button:
Let’s now perform the analysis and monitor its progress by selecting the “Monitor and Control Runs” node of the ATC transaction:
Once completed, we can check the results by clicking on the “Results” button:
The findings found are organized by type and their number is structured by priority for intervention:
Double clicking on each type shows all the impacted objects and, through further double clicks, you can navigate to the exact coding point that determined the error.
Detailed information about the checks nature, are available by analyzing the variant S4HANA_READINESS_REMOTE through the SCI transaction:
As we stated at the beginning of the blog, there are two types of fundamental errors:
Functional errors can refer to one of the following sub-categories:
The errors related to the Simplification Database are, generally, categorized as follows:
As we introduced at the beginning of the blog, next to the checks related to functional correctness and Simplification Database, it is possible to analyze the custom code also from the performance point of view.
To run the performance analysis, simply repeat the steps described in the paragraph “Execute variant S4HANA_READINESS_REMOTE via ATC”.
Then use as reference variant the PERFORMANCE_DB variant:
Generally, the checks related to performance optimization produce the highest number in findings.
To limit the effort due to their optimization, SAP recommends to activate the SQL Monitor (SQLM transaction) in production, for a period of at least 4 weeks.
This will reduce the focus only to the objects actually used in the system.
Note # 1885926 – ABAP SQL monitor introduces e well describes how to use SQL Monitor.
We have come to the end of this long two-part blog that deals with the ECC systems preparation for the transition to the new S/4HANA platform, through the use of the tools that SAP provides, namely the SAP S/4HANA Readiness System Check and the ABAP Test Cockpit (ATC) for the revision of the custom code.
All that remains is to “roll up your sleeves” and proceed to immediately test the degree of readiness of your SAP ERP / ECC system.
