5 Simple Steps to Check the Functional Correctness of Existing Custom ABAP Objects in ECC before Migrating to S/4HANA.

How to Use SCI for S/4HANA​​ Migration?

You company has finally taken the long pending decision to migrate to S/4HANA from ECC. Everyone is excited with the​​ news.​​ You are glad that the time you invested in taking HANA-ABAP training and preparing yourself for S/4HANA project is going to be useful now.​​ It’s Action​​ Time.

Show your Boss,​​ you are prepared for the coming​​ S/4HANA Project by providing him a detailed report of custom objects which might break during S/4HANA migration. You can stand out from rest of your colleagues by showing your Project Manager the list of​​ objects​​ which might have the risk of Functional​​ Incorrectness. Even though you are a Technical guy.​​

What does Functional Correctness mean?​​

It means when the code is moved to HANA, it might still be Technically correct and it might still give some output. But they might not be Functionally Correct​​ (business wise incorrect).

For example, if you do not SORT and do a BINARY search, the output​​ might​​ be correct if the data are sorted somehow. But if the data are not sorted, it would give some wrong output.

Go to t-code SCI

Step 1.​​ Do F4 for​​ Functional DB​​ in the Check Variant area.

You can hit the display icon of Check Variant to see all the default checks provided by SAP.

For example, we clicked on the yellow arrow on​​ Critical Statements under Security Checks. It drills down to​​ Native SQL​​ and​​ DB Hints​​ checks.

Similarly, for Problematic statements for result of SELECT/OPEN CURSOR without ORDER BY. You would find, Report access to Pool/Cluster.

Step 2.​​ Create an Object Set.​​

This is needed just​​ to identify your sets. As a good practice we can do the inspection at​​ Package Level​​ for each team. Or we can be granular and do at program level​​ as well.

Give a name and hit the create icon.​​ I want to inspect for all the objects in my package ZSCM. You can give your package​​ name.​​

The Object Set for package ZSCM gets saved.

Hit the back arrow and go back to initial SCI screen.

Step 3.​​ Create the Inspection.

Give the inspection name and hit the create icon.

Provide the​​ Object Set​​ name we created​​ earlier​​ and the​​ Check Variant​​ name​​ as well.

Note​​ –​​ There is a Red Circle beside Inspection name. It means the Code Inspector has not been executed yet. It turns green once Inspection is done.

Step 4. Execute the Code Inspector

We can run immediately or schedule in background from ATC (ABAP Test Cockpit).

Based on the number of objects, the time taken for the inspection might differ.

Step 5. Review the Result Log of Code Inspector: Inspection

Hit the Results Log​​ (highlighted in above image)​​ and you would get the below summary.

If we expand the Error, we see that there are BINARY and DELETE ADJACENT DUPLICATES, without SORT.

This might fail in HANA as HANA DB does not explicitly SORT during SELECT. We need to have ORDER BY during SELECT.

Let us check the Warning.

It shows where there can be functionally wrong. Select SINGLE might not return a unique entry as we might not have passed all the PRIMARY Keys in the WHERE clause.

It is a good practice to look at the Information as well.

Note:​​ The log would be saved for certain days. If you come back tomorrow and want to check the log, you can.

Check the green icon​​ (below). It means the Inspection for the Object Set and Check Variant was executed. If you think, you have not made any change in the programs, then no need to execute again.​​

But if you want to test after correction, you can re-execute the Inspection.

This is one of the precautionary steps undertaken before we jump to the real S/4HANA migration.​​