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:
Remote Code Analysis in ATC – Technical Setup step by step
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 .
We'd like to transport the custom codes from ECC to S/4hana 2020 with transport copy using New Implementation(Greenfield Approach) like you, I have some questions:
1. In your blog,you said to perform a remote ATC check for old ECC system first. Why not perform a local ATC check for new S/4hana after transporting the custom objects?
2. In your blog, you said to exclude standard modification and custom enhancements. Why not transport the custom enhancements to S/4hana system at the same time? In my opinion,custom enhancements won't overwrite SAP S/4HANA version.
Hi Zhang JiWen ,
Please check my below comments:
For point 1, as you are aware in S/4HANA data model is changed and certain functionality and table have become obsolete.
So, if your custom code deals with such scenario where you are using such obsolete functionality, then ATC check will inform you in advance and you can plan to redesign such custom code.
Hence, it is recommended to run ATC Check as pre check.
For standard modifications, we have observed that if we move them via transport then it overwrites the S/4HANA code version. Hence it should be strictly avoided.
For custom enhancements, most of the time you are right, it will not create issues.
But in certain cases, if standard has removed or changed enhancement place, then custom enhancement will not work via transport.
Hope this helps.
Thanks for the blog. I have a topic here.
You know If the whole custom package is migrated, it will definitely bring a lot of garbage to the new system. How can we choose all the objects we need and move them to the new system efficiently?
Is there any Best Practices about the migration tools? like the ZDOWNLOAD(Assuming you know which program I'm talking about), SAPLink, ABAPGit, etc.
Looking forward to you reply.