Custom Code Adaptation – SAP ECC to SAP S/4HANA (Greenfield Approach)
This blog post will give you quick overview on custom code adaptation for SAP S/4HANA conversion project using New Implementation (Greenfield Approach).
SAP S/4HANA is a new product line for SAP next-generation Digital Core business suite, which is completely separated from the classical SAP Business Suite.This is because you move from one SAP product (Business Suite) to the completely new one (SAP S/4HANA), built on the new architecture and data models, containing renewed applications and new UI technology (SAP Fiori).
Since years SAP customers invested heavily into custom ABAP code developments related to the SAP Business Suite.Therefore when customer decides to move from classic SAP ERP system running on any DB to SAP S/4HANA custom ABAP code needs to be adapted for SAP S/4HANA.
Customers are having 3 options to migrate to SAP S/4HANA landscape:
In this approach , a new SAP S/4HANA system is the starting point and business processes are mapped here .If the customer has custom code from SAP IBSO as IDP project or In-house development, then this needs to be taken care separately. We are going to discuss this approach in detail in this blog.
In this approach, an existing SAP ECC system is converted to SAP S/4HANA. Here SAP SUM tool takes care of end to end conversion process.
An SAP Landscape transformation is a value-driven, selective data migration to the new SAP S/4HANA platform. The focus is not on a whole system migration, but on picking & choosing entities which you want to carve out and move on to the SAP S/4HANA platform.
Now, let’s discuss step by step how to adapt custom code in new implementation approach :
Remote Readiness Check and SAP HANA Specific Findings in Central ATC Check System for SAP S/4HANA
In SAP S/4HANA , lots of data model changes are done and hence SAP has provided simplification list which talks about these changes in detail.
Along with simplification list, SAP has provided readiness check variants per release. The check variant “S4HANA_READINESS_REMOTE” in ATC tool will do code scanning remotely based on simplification list of relevant SAP S/4HANA release on custom code in old SAP ECC system.
The other variants below are used to do code scanning in the SAP S/4HANA system itself :
The below blog talks in detail about how to set up remote ATC:
NOTE:This step needs to be done before moving the custom objects to new SAP S/4HANA system.This will help in understanding the impact of custom code in SAP S/4HANA and effort to resolve the same.
In order to do this step before moving the custom objects to new SAP S/4HANA system, you would need central ATC check system and then with the help of RFC connection to your old SAP ECC system you can run the check variant “S4HANA_READINESS_REMOTE“.
The result will give you findings on custom code which needs to be addressed in SAP S/4HANA system.
The results consist of a code point where a potential issue is. If you click on the code point you jump to the analyzed systems code.
There is also a note number which explains what you need to check.
Now basically 3 things can happen:
- You can fix the issue directly: nice, the next run the issue is gone.
- You read from the OSS note the function has changed or is no longer present in SAP S/4HANA. Read the OSS note for alternatives or check with your functional consultant on functional alternatives. Example of change is the way output and pricing is done. You know now it will be changed, but you cannot prepare in the current system. Use the list as input for project management for work estimation.
- You read from the OSS note the potential issue and conclude it is not relevant for your situation. Example is material number length handling. If you use material numbers properly this is not relevant for you, but the tool will generate massive amounts of alerts. But maybe in some cases you need to intervene.
HANA Specific Findings : For the SAP HANA migration SAP provides new static checks integrated in the code inspector. These checks are bundled in the code inspector variant FUNCTIONAL_DB and FUNCTIONAL_DB_ADDITION. These variant needs to be run for HANA DB specific findings.
These are different checks would be performed:
- Finding Native SQL
- Database (DB) hints
- Finding ADBC (ABAP Database Connectivity) Usages
- Finding usages of special DDIC function modules that check or return the existence or technical properties of certain DB indexes.
- Finding accesses to technical pools/clusters of a pool/cluster table
- Finding non-robust ABAP code that relies on non-ensured/implicit sorting of certain SQL queries, although no ORDER BY clause is used.
There are two different checks available for finding non-robust ABAP code:
“Search problematic statement…w/o ORDER BY”
“Depooling/Declustering: Search for…w/o ORDER BY ”
These additional checks addition to Functional DB checks.
- Checking SQL Operations without a WHERE Clause
- Checking SQL operations with the addition FOR ALL ENTRIES IN , whereby in the code itself it is not ensured that the internal table < itab> is always filled.
- Checking settings in DDIC tables for consistency. In particular, this checks whether table buffer settings have been maintained in a consistent manner (influence on performance).
Transporting Custom objects from SAP ECC to SAP S/4HANA System
When it comes to custom objects , they could consist of different types of objects like DDIC ,report, includes,enhancements,standard modification,etc.
Broadly, we are classifying them into 3 categories based on how they need to be handled from transport point of view.
1. Objects created in customer namespace in custom package.
2. Custom Implicit / Explicit Enhancement.
3. Standard modification done with modification assistant.
In system conversion approach, post conversion we need to adjust any modification and enhancements using the standard transactions SPDD, SPAU, SPAU_ENH .Here we get support of these tools as we are converting the same box and hence system takes care of everything and post conversion we get an option to adjust conflicts in SPDD, SPAU, SPAU_ENH transactions.
But in case of new implementation,these transaction cannot be used.Because when we transport enhancements,standard modification objects from SAP ECC to SAP S/4HANA , they will overwrite SAP S/4HANA version with old SAP ECC version.
Hence, its strongly recommend not to transport any enhancements,standard modification from SAP ECC to SAP S/4HANA and create them manually in SAP S/4HANA.
So, we will be transporting only custom packages excluding enhancements and standard modification.
Once custom packages are transported, next step is to create enhancements and standard modification in SAP S/4HANA system directly.
Now that all the custom code is present in SAP S/4HANA system, next step is to resolve ATC findings from SAP HANA and SAP S/4HANA check variant in SAP S/4HANA.
Resolving SAP S/4HANA Readiness Check and SAP HANA Specific Findings in SAP S/4HANA System
Fix SAP HANA and SAP S/4HANA findings – Adapt custom ABAP code, using the findings of the SAP HANA and SAP S/4HANA checks (ATC results).
Findings of SAP S/4HANA checks are related to SAP S/4HANA Simplifications. Each simplification requires a different approach to solve findings.
Therefore, findings of SAP S/4HANA checks refer to a SAP Note which describes how you can solve them.
Test Custom Functionality in SAP S/4HANA System
At last step, testing will be done for custom functionality in SAP S/4HANA.
So to summarize , in new implementation approach custom code in the form of standard modification and custom enhancements needs to be taken care manually and only custom packages (excluding standard modification and custom enhancements) can be moved via transports. ATC check variants for SAP S/4HANA will help you in the impact analysis on custom code.
Feel free to comment, like and ask your queries using this forum .