I have prepared the article that should help you understand where and what is the role of ABAP developers in SAP ERP to S4HANA migration projects. I chose this topic to collect in one place the available information, which is, frankly speaking, too much information on the Internet and it is difficult to find it.
Reading a lot of extensive, long, detailed articles with a lot of additional thoughts, it’s hard to pin down what we, the SAP system developers, would be most interested in.
So, the answers to the questions:
- Where are we?
- What tools to use?
- Is it difficult or not?
- Which phase are we in?
- When are we needed?
- With whom and when do we cooperate?
I hope this consolidated material will help each of us.
ABAP’er Preparation phase
Screen’s presenting main steps in HANA migration. In this document we will focus on Preparation phase.
Custom Code Migration Worklist. ABAP’er work during Migration
Everything started from below NOTE. My comments have been italicized.
SAP NOTE 2190420 – SAP S/4HANA: Recommendations for adaption of customer specific code
“Before looking into SAP S/4HANA custom code aspects it’s important to understand, that the vast majority of custom code recommendations, best practices, activities, and tools you might already know from SAP ERP are also applicable to SAP S/4HANA. Similarly, most of the existing custom code on SAP ERP is compatible with SAP S/4HANA.
So as far as custom code in SAP S/4HANA is concerned, there are indeed some differences on top of everything existing that you must learn about and to adapt to. But these are rather small differences.”
The tools and processes that apply to custom code development on SAP ERP or any other ABAP based product are also applicable to SAP S/4HANA. Including
- check for and remove obsolete custom code, unnecessary modifications and unnecessary clones of SAP objects, in order to keep your code base clean (housekeeping activities).
- TCODE: SCMON (Monitor usage of custom code) – How often Custom code is invoked.
- TCODE: CCLM (Custom Code Lifecycle Management) – Creating a library of custom codes, it has functionality of decommissioning of code, which is not used more than 12 months.
- run all code checks provided by SAP (e.g., functional correctness, performance, security etc.) on your custom code.
- Program /SDF/RC_START_CHECK (Simplification Item List) – Functional and technical impact of the system conversion on your system. Work very difficult to divide. All checks, data inconsistencies, missing mandatory preparation activities which could cause the system conversion to fail, listed here are ABAP Developer work and Functional consultant work. Migration can start only when all listed records will be green = “no issue”.
- TCODE: SYCM (Program SYCM_DOWNLOAD_REPOSITORY_INFO – Custom Code Analyzer
NOTE 2185390 – Custom Code Analyzer – listing of customers code entities which do not comply with the SAP S/4HANA
BLOG link - TCODE: ATC (ABAP test cockpit)
NOTE: 2436688 – Recommended SAP Notes for using S/4HANA custom code checks in ATC or Custom Code Migration app
HINT: Please focus on special S4HANA variant like: “S4HANA_READINESS_1809” or “S4HANA_READINESS_1909” etc. - TCODE: SCI (Code Inspector)
NOTE: 1935918 – Downport Code Inspector Check Variants for HANA Migration
- do performance profiling and optimization (general as well as SAP HANA specific) of your custom code. – improvement in productive business processes)
- TCODE: SQLMD (SQL Monitoring) – Point the most workload in the system
- TCODE: SWLT (SQL Performence Tuning Worklist) – find ABAP SQL code that has potential for performance
- define suitable test concepts and test your custom code. Including leveraging the possibilities of test automation.
Normally, dedicated functional consultants are checking the process (FI,SD,MM,WM) (no budget for dedicated test team), I never heard about test automation in SAP. (I did 3 upgrades of SAP ERP system, and 1 Upgrade of PI system from ABAP stack to JAVA stack (7.31 à 7.4). Even very big corporation with relative unlimited budget, never create dedicated test team for any SAP upgrade or migration. Always Tests are done by functional consultant with ABAP Developer cooperation. So, in fact, ABAP Developer have a lot of work here. Cross module knowledge and soft communication skills are needed.
- follow custom code best practices (ABAP, SQL in general and SAP HANA specific).
This is to big subject to discuss, and it depends on Developer knowledge, team involved, system manager and quality code team. In more than 20 projects in my life, only 1 company has quality code team, which watch over quality of code. From my experience, code inside companies in SAP world, in many situations is wrote by many developers that change, during System lifecycle. Code that is added, very often meet requirement, but do not meet any of best practice. But, nevertheless, every developer needs to write code as clean as possible.
- do SPDD, SPAU, SPAU_ENH adjustments during lifecycle events.
SPDD and SPAU are also part of migration. In one word saying, ABAP Developer need to handle both steps, which are very important, and ABAP developer work very closely with SAP Basis team.
Sap Basis need to do SUM (Software Update Manager). SUM in one word saying, is DB conversion. In that particular BIG step (separate certification could be done here, and such Basis consultant are desired on the market), there is a technical downtime, where SAP ERP DB model, is converted to SAP S4HANA DB model.
One step of that conversion is called SPDD. SUM is stopped, SAP Basis consultant call then ABAP Developer, and wait, when ABAP Developer do necessary work. SPDD is DDIC custom structure check. Every enhancement, of standard SAP Data Element from DDIC need to be adjusted.
After work is done, ABAP Developer need to call SAP Basis, and tell him/her, that work is finish. Basis consultants click then in “SUM” process, that SPDD is done, after couple of minutes (checks of our work are done), SUM stopped again. (If there will be errors in SPDD ABAP Developer work, SUM can be reverted, and all process need to be redone again)
Now we need to do SPAU. SPAU is all Implicit enhancement adjustment, standard code change after object key, includes that are not in standard. ABAP Developer need to rewrite all that code to new system. SPAU can take even couple of days for developer work. First SPAU give first information, about how long ABAP Developer need to work, when it comes to Production technical SUM, what have major impact of downtime planning for S4Hana migration.
S4HANA Architecture. Where ABAP’er is present
Very simple and intuitive SAP S4HANA layer presentation.
Please mention, that SAP trainers call CDS (Core Data Services) as “Data Extractor”. That give a very good understanding, of what CDS are, from architecture perspective. After incredible DB reduction in S4HANA, only to couple Tables (MATDOC, ACDOCA, BUT00), data extraction like CDS, play integration rule in architecture, between Database Layer and Application Layer.
And second very important architectural point is SAP GATEWAY (TCODE: SEGW), which from SAP trainers is called as “Extractor to external world”. That give us once again, a very easy to understand place in architecture. SEGW is next integration layer. SAP gateway is able to send, to external world OData (file like IDOC), using HTTP protocol (SET, GET). OData and HTTP together, are the most popular technology now days.
Modern ABAP Developer work is between CDS and SEGW Extractor with knowledge, how to build CDS, and how to prepare data for SEGW service.
How S4Hana evolved
Below pictures are great presentation on how S4Hana Looks like, and where it is going to.
Summary
I hope that the above-shortened description will help you find the S4HANA migration key issues. This should make it easier for you to explore the more detailed aspects further. Although this is not a description of how to migrate, it can answer many bothering questions about the role of ABAP developers.
