ABAP Migration to S/4HANA – First Questions (Part 2)
In my first article, I spoke about some points of view about S/4HANA´s changes, ABAP performance, and new tools and artifacts:
Now, I continue talking about the ABAP custom code but now from the perspective of Functional Issues and Data Migration, and then I expose some new questions about the migration to S/4HANA.
All ABAP custom code works after the Migration to S/4HANA?
If you thought that all ABAP custom code could work well, don’t trust it. In fact at least an ABAP consultant is needed for these code adjustments and this is another great opportunity for us to do an interesting job. The potential functional issues could occur when:
- Use native SQL with the EXEC SQL sentence like for example:
EXEC SQL. CREATE TABLE abap_docu_demo_mytab ( val1 char(10) NOT NULL, val2 char(10) NOT NULL, PRIMARY KEY (val1) ) ENDEXEC.
More examples about the use of EXEC SQL Sentence:
- Use %_HINTS which works just as specific parameters of the query to the database and depend entirely on the installed database and its indexes. As example:
SELECT bukrs gjahr belnr buzei budat kunnr umskz augbl INTO TABLE gti_bsid FROM bsid FOR ALL ENTRIES IN gti_bsis WHERE bukrs EQ gti_bsis-bukrs AND belnr EQ gti_bsis-belnr %_HINTS DB6 '<IXSCAN TABLE=''BSID'' INDEX=''"BSID~5"'' />'.
More information about %_HINTS:
- When the code checks for the existence of indexes, using, for example, the function module “DB_EXISTS_INDEX” and the forward logic depends directly from the result:
DATA: loc_subrc_dbindex TYPE sysubrc. CALL FUNCTION 'DB_EXISTS_INDEX' EXPORTING tabname = 'JGTSADR' indexname = 'O06' IMPORTING subrc = loc_subrc_dbindex EXCEPTIONS parameter_error = 1 OTHERS = 2. IF sy-subrc = 0 AND loc_subrc_dbindex = 0. SELECT * FROM jgtsadr APPENDING TABLE i_jgtsadr WHERE isphandy = jgtsadr-isphandy AND land1 = jgtsadr-land1 AND herk NE con_adr_zu_beablst AND herk NE con_adr_zu_avm_cpd AND herk NE con_adr_zu_adressversand AND xadrloe = con_nicht_angekreuzt. ENDIF.
- Assume a sort result that depends on primary keys or secondary indexes: This kind of issue isn´t easy to identify because it lacks explicitly order. Maybe you need to debug the query and after identify, the solution consists of giving a sort ABAP sentence to the query result or use a sorted internal table in the definition.
- When the ABAP Program accesses directly to physical clusters and pools: then you could adapt these direct accesses using maybe the new tables that replace the old cluster tables.
Also Code Inspector and ABAP Test Cockpit (Transactions SCI and ATC) can be used to get some functional issues in the code within the Migration to S/4HANA using the variant FUNCTIONAL_DB. The way is like the PERFORMANCE_DB variant.
What about Data Migration?
Data migration means the process of selecting, extracting, transforming, and loading (ETL) data from a system “A” to a system “B”. Also, ensure that the data moved is of high quality and support the underlying business process and goals of the company.
When the system “A” is an SAP system like SAP ECC, and the system “B” is S/4HANA, it is considered a special direct Data Migration because the Data “stay in the same” system (as approach). This kind of migration is named “brownfield” and within SAP S/4HANA 1909 exists a direct data transfer between old and the new system.
However, if the system “A” is a Non-SAP System, and the system “B” is S/4HANA, we could speak about a no-direct Data Migration and a “greenfield” path transition and also is referred as a new implementation.
Nice tools are available to execute a data migration like for example LTMC and LTMOM transactions. With these tools is possible to do the migration without build ABAP programs to this purpose.
I highly recommend learning about data migration by studying the Open Sap Course “Migrating Your Business Data to SAP S/4HANA – New Implementation Scenario“:
In conclusion to this second part of ABAP’s questions within the migration to S/4HANA, not only performance issues appear, but also there are functional issues within the custom code. The migration to S/4HANA involves a Database’s change. When the code depends directly on a particular previous Database and its indexes, this will not work well. The SCI transaction could be used with object variant “FUNCTIONAL_DB“ to get some of this kind of other issues.
Aditional to the custom code adjustments, it is very important to consider the Data Migration at the beginning of the Migration Project, because this job has significant times.