An ABAPer’s Real Experience during S/4 HANA Migration
So the season for the S4 HANA conversion has started and most clients would be converting the ECC business suite to S4 HANA tomorrow, if not today. That includes a set of tasks which involves the BASIS consultant, Functional Consultant and of course us i.e. the immortal ABAP consultants (based on the client’s system landscape BW/CRM/PI/PO consultants might also be required). Let us briefly describe the Overall Conversion Process before we dig into the role of an ABAP Consultant.
We highly recommend going through Part I and Part II of our S/4 HANA Technical series, and then continue with this series. In Part I, we have shown you how the actual S/4 HANA system looks. In Part II, we have talked about the tables which are made Obsolete in S/4 HANA and we also touch the Compatible CDS Views in S/4 HANA.
Before starting the Conversion Process, BASIS consultant has to find out if the system can be converted to S4 HANA. There are dependencies which might make the current system incompatible to S4 HANA and stop the conversion. For example, the client might be using some add-on products which are not yet supported in S4 HANA system. Maybe the current system cannot be directly upgraded to S4 HANA, and you might need to upgrade the current system to a minimum support package before you can actually start the conversion. For your information, the system needs to be a Unicode system as a Prerequisite for conversion to S/4 HANA. Once the Basis consultant declares that the system can be converted and give their green signal, the actual process of conversion can be commenced.
The entire task of the Conversion to S/4 HANA can be broadly categorized into three segments.
1. Pre-Conversion Activities
2. System Conversion
3. Post-conversion Activities
1. Pre-Conversion Activities
- The basis consultant should create a Sandbox System where we should perform the dry run. The Sandbox should be the copy of Production System where “Realistic” tests can be executed.
- Basis consultant needs to apply necessary notes to enable the functional consultants do the consistency check.
- Functional consultants do the consistency check and rectify all the errors found.
- ABAPers change the custom code and make it compatible to HANA system.
2. System Conversion
- Once all the errors are rectified and custom codes are changed, then starts the actual process of the system conversion. Basis consultants start the conversion with the help of SAP Provided tool SUM ( Software Update Manager ) with DMO (Database Migration Operation)
- This tool will help the Basis consultant to convert the ECC system to HANA system and migrate the data from the legacy database to Hana Database.
3. Post-Conversion Activities
- Once the Conversion is done, functional consultants have to check the impact of the conversion and they might need to perform some additional activities.
WHAT IS THE ROLE OF AN ABAPER IN S/4 HANA MIGRATION PROJECT?
The above discussion gives a brief outline of the S/4 HANA Conversion Process. Now, let’s discuss the Custom Code Management i.e. Role of an ABAPer.
Custom Code management can be segregated into two distinct steps.
1. Decommissioning the unused Custom Code
2. Making the Custom Code ready for HANA system
1. Decommissioning the unused Custom ABAP Code
AS SAP recommends, we should decommission the unused Custom Codes first (not the other way round) i.e we should not try to make change to code to make it HANA ready first.
The reason being Simple. That will eventually help us and we don’t have to work on objects which are not used anymore. SAP has been suggesting a few tools for some time now to identify the custom codes that are not in use anymore. UPL (Usage Procedure Log), SQLM (SQL Monitor), SCMON (ABAP Call Monitor) are to name a few of it. There are a lot of SAP Mentors writing blogs about these tools and you’ll get a plenty of resources over the internet which describes the way to use these tools. However, you don’t have to use all of these tools. After going through the pile of blogs/articles, we found that “SCMON” is the latest t-code and use of this t-code is sufficient to identify the custom codes which are being used and which are not.
The purpose of the ABAP Call Monitor is to monitor the execution and usage of custom ABAP code (ie. program, FM, method calls etc.) in the productive system. The advantage of the SCMON compared to the UPL in SAP Solution Manager is that using this tool we not only collect the usage data (how frequently a specific ABAP object is called) but also the information about the calling Business Process. Therefore as a result of the monitoring, we get a list of business transactions (callers) along with all ABAP objects that have been called within these business transactions including the number of calls.
Sounds easy. Isn’t it? Allow me to make it a bit complicated.
“SAP suggests we use this t-code in the Production System for quite a long time – ideally ranging from 6 to 12 months”.
So what’s the problem with that?
The problem is, we should start using this t-code even before we have planned to move to S/4 HANA. Doesn’t it sound illogical?
Yes, it does.
So what approach we could take to decommission the unused custom code?
Our suggestion is that it should be altogether a separate project. We should not take it up along with the S/4 HANA Conversion Project. We can start SCMON for as long as we think is suitable for our client (Please remember, it should also capture those objects which are used once in a while, for example, month end/ quarter end or maybe year-end). Once that is done, we can proceed with the decommissioning of the custom code with the tool called “CCLM” Custom Code Lifecycle Management.
2. Making the Custom Code Ready for HANA system
What does that mean? Why is this necessary at all? Although SAP has come up with new tables (in order to reduce data footprint & to have a single source of truth), it still supports all the old tables. Either the old tables are still getting populated or there is some view with same name (except KONV table which is replaced by a new table called PRCD_ELEMENTS). So it should support all the custom codes. Well, it does support the old custom codes except the following few cases.
- Custom codes, which relies on DB specific features or using native SQL or Hints is not supported in SAP HANA.
- Default Sorting is not guaranteed in SAP HANA. So we need to make a few changes.
Now the question is, do we need to make these changes in order to convert the OLD SAP business suite to HANA? The answer is YES. Before we start the actual process of the conversion, we need to make changes wherever any of the above 2 cases are found. This is a part of the Pre-Conversion activities and it is mandatory.
Is there any way to identify the custom codes which must be changed?
The answer is YES again. SAP has come up with a brilliant solution for the custom code check. The tool for HANA checks is ABAP Test Cockpit (ATC) with Remote Code Analysis. You set up only one ATC central system (SAP_BASIS >=7.51) for all static checks of your custom ABAP code in your system landscape, which needs to be migrated to SAP S/4HANA.
So the steps should be the following:
- Install a standalone SAP NetWeaver system with the components shown in below images. This NetWeaver system can be connected to any system in the landscape (through RFC)
- Setup ATC applying the recommended notes in the NetWeaver system.
- Download the latest version of the Simplification Database content from SAP Service Marketplace.
- Install the Simplification Database content on the central ATC check system.
- Create an RFC connection in the source system in your landscape (Dev system, for example) to this NetWeaver system.
- Push the custom code (Preferably push all Y* & Z* packages) from the Dev system to the NetWeaver System using the RFC.
- Execute SAP HANA and/or SAP S/4HANA checks: Run the ABAP Test Cockpit with the variant FUNCTIONAL_DB.
- Analyse the ATC result list and make necessary changes in the Dev system.
This is the mandatory part. Once this is done, your custom code is ready for HANA migration.
After the migration to HANA (S/4 HANA Sandbox), there is only one thing left for an ABAPer. All the select queries to KONV table are to be changed to PRCD_ELEMENTS table. However, you can still keep on using the KONV structure for data declaration.
Additionally, you can check the custom code using the variant PERFORMANCE_DB. However, we recommend that the performance optimization should be taken up separately after migrating to HANA. This is when we suggest using SCMON tcode. Once the migration is complete, activate SCMON in the Production System (S/4 HANA Sandbox) and identify the unused custom codes. Once the unused custom codes are detected, decommission the same with help of CCLM (Custom Code Lifecycle Management). After decommissioning the unused custom codes, you can start with the custom code check with the variant PERFORMANCE_DB (in ATC) and resolve the errors found. However, you can do performance tuning if it is required for any particular object.
REAL PROJECT EXPERIENCE
In a real conversion project, we found around 200 errors while checking with FUNCTIONAL_DB variant which was simple in nature and easy to fix. However, we got roughly 12000 errors while checking with PERFORMANCE_DB variant and most of these were complex in nature. They required a considerable amount of effort in development & testing. As we know that checking with FUNCTIONAL_DB is mandatory and PERFORMANCE_DB is optional and resolution of the PERFORMANCE_DB check will involve considerable effort, we suggest taking on Performance Tuning separately.
