This blog is targeted to ABAP technical team working on S4 HANA conversion OR Suit on HANA migration projects.
As we know in Suit on HANA migration and S/4 HANA conversion projects conventional database is replaced by HANA database. Custom code which was running on non-HANA database earlier will not work as it is since HANA database doesn't sort the data implicitly, it needs to be sorted explicitly.
Hence it is necessary that customer adapts the custom code with respect to HANA database after migration/conversion.
Let's us consider that customer has completed the migration and conversion. Activities like Unicode conversion, SUM execution, SPAU/SPDD activities are completed. And next activity is custom code adoption/Remediation.
I will try to cover following questions in this blog post based on my experience working on S/4 HANA conversion and Suit on HANA migration projects.
Pre-checks to be performed before starting the custom code impact analysis.
In Transaction SCI, check if check variant FUNCTIONAL_DB and FUNCTIONAL_DB_ADDITION are available. If not available, check and implement following SAP notes.
Note: FUNCTIONAL_DB_ADDITION check covers additional performance related checks. Execute this check variant to identify and fix the cases where "Unsecure use Of for All Entries is used."
If customer NetWeaver system is >7.4 and <= 7.5
1912445 - ABAP custom code migration for SAP HANA - recommendations and Code Inspector variants for ...
1935918 - Downport Code Inspector Check Variants for HANA Migration
If customer NetWeaver system is > 7.5
Open Transaction SCI and check if check variant S4_HANA_READINESS_<release version> is available. If not available, check and implement following SAP notes.
2436688 - Recommended SAP Notes for using S/4HANA custom code checks in ATC or Custom Code Migration...
FUNCTIONAL_DB FUNCTIONAL_DB_ADDITION
Screenshot 3: S4HANA_READINESS
In Screenshot1 and Screenshot 3, Security Check ad Robust programming checks cover the SAP recommended checks to be performed on the custom code.
Note: This blog is not intended to cover the "S4 HANA Custom Code Checks".
Activities to be performed before code Adoption/Remediation.
Execute the check variant FUNCTIONAL_DB and FUNCTIONAL_DB_ADDITION on entire custom code using ATC or SCI transaction. You can also include custom namespaces in case those are also required to be remediated.
In case of S/4 HANA conversion, execute S4_HANA_READINESS_<release> check variant. This check variant covers the checks of FUNCTIONAL_DB. Hence it is not required to execute FUNCTIONAL_DB check again.
Execute ATC Transaction
Execute the ATC check on Z* and Y* packages and also on modified objects.
Check Title and Check Message show the various the ATC issues captured.
Now let's see what the different issues captured in FUNCTIONAL_DB check and how those can be fixed.
For Example: Syntax error in in SAPLXEDF.
This check shows the objects in the Syntax error. Unless these syntax errors are fixed, these objects cannot be analyzed as well. Hence fix all such objects in syntax errors and again execute the ATC checks on such objects.
2. Missing Objects
For Example: Used object Screen 9000 does not exist.
This check shows the missing objects like includes screens etc. Unless these errors are fixed, these objects cannot be analyzed as well. Hence fix all such objects have missing objects and again execute the ATC checks on such objects.
3. Use of Database Hint: %_HINTS
Below is the OPEN SQL statement written with underline database as non-HANA database.
After migration to HANA database, HINTS written in the custom code need to be analyzed and decision need to be taken if those can be retained.
In case of conversion to S/4 HANA, SAP provided HINTs may not be available on new S/4 HANA release. Hence such HINT statements need to be either replaced with new HINT or removed.
4. Use of Native SQL
As per SAP's recommendations Embedded Native SQL statements between EXEC SQL and ENDEXEC should no longer be used in the ABAP development though they are supported by SAP. Instead ADBC interface or OPEN SQL to be used to fulfill the requirement.
But even though these SQL statements are not replaced with ADBC or OPEN SQL, functionality is not going to impact.
Refer the SAP Help Native SQL
Hence such issues can either be suppressed using pragma or need to be corrected.
5. Use of ADBC Interface
As motioned in point No 3. ADBC classes can still be used in the development. Hence these classes can be replaced with OPEN SQL or can be continued to be used as it is.
In below example Method EXECUTE of ADBC class CL_SQL_STATTEMENT is used to execute the native SQL.
Hence such issues can either be suppressed using pragma or need to be corrected.
6. SELECT SINGLE is possibly not unique
Here is a code which is running on non-HANA database and using SELECT SINGLE statement.
This code is supposed to SELECT the Document no 0000000005.
Now let's execute similar SEELCT SINGLE statement on HANA database.
Expected Output is 00000018.
However Actual output is 00000021.
As we discussed in the beginning of this blog, explicit Sorting of data is required on HANA database.
Since Explicit sorting is missing in code written on HANA database incorrect result was obtained.
How to correct this issue? Code needs to be adjusted as below.
After making these changes output is
The explicit SORTING by Primary key is required when ALL Key Fields are not passed to SELECT statement written on Transparent table and Views. If the output of such incorrect select statements are used for further processing like validation, calculation etc. the functionality will be impacted.
This might work in cases where SELECTs are written to validate the existence of at least one record in the table. But it is recommended to adjust all such issues before handing over code for functional testing.
Similarly, for all below ATC errors do the explicit sorting after SELECT statement, before READ statement, before DELETE adjacent, before LOOP..ENDLOOP.
7. READ .. BINARY SEARCH for result of statement
8. DELETE ... FROM/TO for result of statement
9. DELETE ... INDEX for result of SELECT statement.
10. LOOP AT itab. AT ... ENDAT
11. LOOP AT itab. AT FIRST/LAST... ENDAT
12. LOOP AT itab. EXIT/RETURN/LEAVE
13. LOOP AT itab FROM/TO for result of statement
14. READ TABLE ... INDEX for result of SELECT statement
15. READ TABLE ... INDEX 1 for result of statement
16. READ TABLE ... INDEX C_CONST for result of statement
17. SELECT ... FOR (former) cluster table
18.SELECT ... FOR (former) pool table
19. DELETE ADJACENT DUPLICATES for result of statement
Summary
We learned.
In next blog I will try to cover some unique scenarios of custom code adaptation.
Please also visit my previous blogs on custom code remediation
Handling of SELECT statements on simplified tables during S/4 HANA conversion | SAP Blogs
How to Handle Amount Field Length Extension scenarios in S4 HANA conversion? | SAP Blogs
Handling of Material Field Length Extension scenarios in S4 HANA conversion | SAP Blogs
As we know in Suit on HANA migration and S/4 HANA conversion projects conventional database is replaced by HANA database. Custom code which was running on non-HANA database earlier will not work as it is since HANA database doesn't sort the data implicitly, it needs to be sorted explicitly.
Hence it is necessary that customer adapts the custom code with respect to HANA database after migration/conversion.
Let's us consider that customer has completed the migration and conversion. Activities like Unicode conversion, SUM execution, SPAU/SPDD activities are completed. And next activity is custom code adoption/Remediation.
I will try to cover following questions in this blog post based on my experience working on S/4 HANA conversion and Suit on HANA migration projects.
- What are the pre-checks be performed before starting the code adoption?
- How to analyze the impact on custom code impact while migrating to HANA database?
- Which ATC issues need to be fixed to adapt the custom code with respect to HANA database?
- What is the solution of the ATC issues?
Pre-checks to be performed before starting the custom code impact analysis.
In Transaction SCI, check if check variant FUNCTIONAL_DB and FUNCTIONAL_DB_ADDITION are available. If not available, check and implement following SAP notes.
Note: FUNCTIONAL_DB_ADDITION check covers additional performance related checks. Execute this check variant to identify and fix the cases where "Unsecure use Of for All Entries is used."
If customer NetWeaver system is >7.4 and <= 7.5
1912445 - ABAP custom code migration for SAP HANA - recommendations and Code Inspector variants for ...
1935918 - Downport Code Inspector Check Variants for HANA Migration
If customer NetWeaver system is > 7.5
Open Transaction SCI and check if check variant S4_HANA_READINESS_<release version> is available. If not available, check and implement following SAP notes.
2436688 - Recommended SAP Notes for using S/4HANA custom code checks in ATC or Custom Code Migration...
FUNCTIONAL_DB FUNCTIONAL_DB_ADDITION
Screenshot 3: S4HANA_READINESS
In Screenshot1 and Screenshot 3, Security Check ad Robust programming checks cover the SAP recommended checks to be performed on the custom code.
Note: This blog is not intended to cover the "S4 HANA Custom Code Checks".
Activities to be performed before code Adoption/Remediation.
Execute the check variant FUNCTIONAL_DB and FUNCTIONAL_DB_ADDITION on entire custom code using ATC or SCI transaction. You can also include custom namespaces in case those are also required to be remediated.
In case of S/4 HANA conversion, execute S4_HANA_READINESS_<release> check variant. This check variant covers the checks of FUNCTIONAL_DB. Hence it is not required to execute FUNCTIONAL_DB check again.
Execute ATC Transaction
Execute the ATC check on Z* and Y* packages and also on modified objects.
Check Title and Check Message show the various the ATC issues captured.
Now let's see what the different issues captured in FUNCTIONAL_DB check and how those can be fixed.
- Syntax Error
For Example: Syntax error in in SAPLXEDF.
This check shows the objects in the Syntax error. Unless these syntax errors are fixed, these objects cannot be analyzed as well. Hence fix all such objects in syntax errors and again execute the ATC checks on such objects.
2. Missing Objects
For Example: Used object Screen 9000 does not exist.
This check shows the missing objects like includes screens etc. Unless these errors are fixed, these objects cannot be analyzed as well. Hence fix all such objects have missing objects and again execute the ATC checks on such objects.
3. Use of Database Hint: %_HINTS
Below is the OPEN SQL statement written with underline database as non-HANA database.
After migration to HANA database, HINTS written in the custom code need to be analyzed and decision need to be taken if those can be retained.
In case of conversion to S/4 HANA, SAP provided HINTs may not be available on new S/4 HANA release. Hence such HINT statements need to be either replaced with new HINT or removed.
4. Use of Native SQL
As per SAP's recommendations Embedded Native SQL statements between EXEC SQL and ENDEXEC should no longer be used in the ABAP development though they are supported by SAP. Instead ADBC interface or OPEN SQL to be used to fulfill the requirement.
But even though these SQL statements are not replaced with ADBC or OPEN SQL, functionality is not going to impact.
Refer the SAP Help Native SQL
Hence such issues can either be suppressed using pragma or need to be corrected.
5. Use of ADBC Interface
As motioned in point No 3. ADBC classes can still be used in the development. Hence these classes can be replaced with OPEN SQL or can be continued to be used as it is.
In below example Method EXECUTE of ADBC class CL_SQL_STATTEMENT is used to execute the native SQL.
*&---------------------------------------------------------------------*
*& Report Z_ADBC
*&---------------------------------------------------------------------*
*&
*&---------------------------------------------------------------------*
REPORT z_adbc.
CLASS demo DEFINITION.
PUBLIC SECTION.
CLASS-METHODS main.
PRIVATE SECTION.
CLASS-DATA: BEGIN OF result_line,
carrid TYPE sflight-carrid,
connid TYPE sflight-connid,
fldate TYPE sflight-fldate,
END OF result_line,
result_tab LIKE TABLE OF result_line.
ENDCLASS.
CLASS demo IMPLEMENTATION.
METHOD main.
DATA carrid TYPE sflight-carrid.
DATA cols TYPE adbc_column_tab.
cols = VALUE #( ( CONV adbc_name( 'CARRID' ) )
( CONV adbc_name( 'CONNID' ) )
( CONV adbc_name( 'FLDATE' ) ) ).
cl_demo_input=>request( CHANGING field = carrid ).
TRY.
DATA(result) = NEW cl_sql_statement( )->execute_query(
`SELECT carrid, connid, fldate ` &&
`FROM sflight ` &&
`WHERE mandt = ` && `'` && sy-mandt && `' AND` &&
` carrid = ` && cl_abap_dyn_prg=>quote(
to_upper( carrid ) ) ).
result->set_param_table( itab_ref = REF #( result_tab )
corresponding_fields = cols ).
IF result->next_package( ) > 0.
SORT result_tab BY carrid connid fldate.
cl_demo_output=>display( result_tab ).
ENDIF.
CATCH cx_sql_exception INTO DATA(err).
cl_demo_output=>display( err->get_text( ) ).
ENDTRY.
ENDMETHOD.
ENDCLASS.
START-OF-SELECTION.
demo=>main( ).Hence such issues can either be suppressed using pragma or need to be corrected.
6. SELECT SINGLE is possibly not unique
Here is a code which is running on non-HANA database and using SELECT SINGLE statement.
This code is supposed to SELECT the Document no 0000000005.
Now let's execute similar SEELCT SINGLE statement on HANA database.
Expected Output is 00000018.
However Actual output is 00000021.
As we discussed in the beginning of this blog, explicit Sorting of data is required on HANA database.
Since Explicit sorting is missing in code written on HANA database incorrect result was obtained.
How to correct this issue? Code needs to be adjusted as below.
After making these changes output is
The explicit SORTING by Primary key is required when ALL Key Fields are not passed to SELECT statement written on Transparent table and Views. If the output of such incorrect select statements are used for further processing like validation, calculation etc. the functionality will be impacted.
This might work in cases where SELECTs are written to validate the existence of at least one record in the table. But it is recommended to adjust all such issues before handing over code for functional testing.
Similarly, for all below ATC errors do the explicit sorting after SELECT statement, before READ statement, before DELETE adjacent, before LOOP..ENDLOOP.
7. READ .. BINARY SEARCH for result of statement
8. DELETE ... FROM/TO for result of statement
9. DELETE ... INDEX for result of SELECT statement.
10. LOOP AT itab. AT ... ENDAT
11. LOOP AT itab. AT FIRST/LAST... ENDAT
12. LOOP AT itab. EXIT/RETURN/LEAVE
13. LOOP AT itab FROM/TO for result of statement
14. READ TABLE ... INDEX for result of SELECT statement
15. READ TABLE ... INDEX 1 for result of statement
16. READ TABLE ... INDEX C_CONST for result of statement
17. SELECT ... FOR (former) cluster table
18.SELECT ... FOR (former) pool table
19. DELETE ADJACENT DUPLICATES for result of statement
Summary
We learned.
- Custom code adaptation must be done with respect to HANA database in Suit on HANA Migration and S/4 HANA conversion projects.
- Use FUNCTIONAL_DB and FUNCTIONAL_DB_ADDITION check variant in ATC to perform custom code analysis.
- FUNCTIONAL_DB_ADDITION is not mandatory though since it covers performance related checks.
- Explicit sorting of the data must be done for various statements we discussed in the blog.
In next blog I will try to cover some unique scenarios of custom code adaptation.
Please also visit my previous blogs on custom code remediation
Handling of SELECT statements on simplified tables during S/4 HANA conversion | SAP Blogs
How to Handle Amount Field Length Extension scenarios in S4 HANA conversion? | SAP Blogs
Handling of Material Field Length Extension scenarios in S4 HANA conversion | SAP Blogs
- SAP Managed Tags:
1 Comment
