Custom code adjustments for HANA database migration

If you convert ECC to S4HANA you need to execute custom code adjustments for both HANA database migration and for functional application changes. This can be read in this blog and this blog.

If you only want to migrate an existing database to HANA for a netweaver ABAP stack (either standalone or for SAP ECC), you will also need to adjust custom code.

Questions that will be answered in this blog are:

  • Which custom code ABAP changes to I need to perform mandatory for a HANA database migration?
  • Which custom code ABAP changes are highly recommended to perform for a HANA database migration?
  • Which other tools should I use to help to smoothen the HANA database migration?

Mandatory custom ABAP changes for HANA database migration

There are mandatory ABAP changes to be made for HANA database migration. The main ones are:

  • Native SQL statements
  • Use of Database hints
  • Search in pool and cluster tables
  • Use of ADBC interface
  • Search for problematic statements without ORDER BY

The first few will not appear too much and are relatively easy to fix.

The last one: the statements without ORDER BY needs some explanation. Some current custom code might work properly with the current database, since some database will present the data to the ABAP application server in a specific sorted way. When migration to HANA database the HANA database might present the same records to the ABAP application server, but in a different sorting or in a random order. This might lead to issues in further handling in custom code. The solution is to analyze the code and to add explicit sorting as per need of the custom program. To scan the usage in live system, see below chapter on SRTCM.

All these changes can be detected with the SCI variant FUNCTIONAL_DB:

Run this SCI variant via the ATC tool on your custom code:

Wait for the run to finish and go to the results. The best overview is when you click the Statistics View button:

Clicking on an item will drill down to the details.

Performance related coding changes for HANA database migration

The second set of custom code changes is from the performance side. For this set you need to run the ATC tool with SCI variant PERFORMANCE_DB:

The PERFORMANCE_DB variant has 2 main parts: mandatory fixes, good to fix.

The mandatory fix is the unsecure use of SELECT FOR ALL ENTRIES. If this is not properly checked, it might blow up the system:

What happens here? If in the current database the SELECT FOR ALL ENTRIES for whatever reason is not giving results this might be running fine. But on HANA the entire table is read in this case. To scan the usage in live system, see below chapter on SRTCM.

The other part is the performance best practices for HANA:

This ATC run can yield a very long working list:

Where to start? Since even the priority 1 and 2 can yield a very long list.

Use the SQLM and SWLT tools. These tools will help you to prioritize the ATC run result from the PERFORMANCE_DB variant. SQLM will take statistics data from production. You start with the heavy used programs. SWLT will combine the heavy use with the ATC run. The output is the heavy used program which can be improved.

SRTCM tool

The SRTCM tool is specifically designed to scan for 2 main issues: Empty table in FOR ALL ENTRIES clause and Missing ORDER BY or SORT after SELECT. The tool is run on a productive system and will list the actual usage in a productive system.

To switch on start transaction SRTCM and press the Activate Globally button.

Let the tool run, and later Display Results from either running system or snapshot:

Show results;

Clicking on the line will jump to the direct code point.

Note for Oracle as source database: 3209584 – RTM: RTM_PERIODIC_JOB canceled with runtime error SQL_CAUGHT_RABAX (ORACLE).

Functionality issues after HANA database migration

Functional issues after HANA database migration are rare. Some might occur on an ECC system if there are minor bugs or issues in the HANA database optimized routines.

Example OSS notes:

Custom code decommissioning

SAP solution manager offers a custom code decommissioning cockpit tool. This tool you can use to delete unused custom code. Unused code does not need to be migrated, which will save you effort.

SAP references

SAP Readiness check for Cloud ALM

SAP will stop supporting SAP solution manager by 31.12.2027. All its functions will be migrated to SAP Cloud ALM.

The SAP readiness check for Cloud ALM will check the usage of current functions in your SAP solution manager and will validate if replacements in Cloud ALM are already present.

Since Cloud ALM is constantly growing in functionality you better run this check yearly. It is up to each customer to decide to move to SAP Cloud ALM for part of the functions or to wait until all functions are available.

There are other readiness checks as well:

Preparation in SAP solution manager

Apply the latest version of SAP note 3236443 – SAP Readiness Check for SAP Cloud ALM to your SAP solution manager system. Run program /SDF/RC_ALM_COLLECT_DATA in your solution manager production system.

It might be that your RFC for destination WEBADMIN is not setup correctly. That will cause a short dump.

If you are not using Trace Analysis function, you can remove code to this call in the local definition of class /SDF/CL_RC_ALM:

Running the check

Run program /SDF/RC_ALM_COLLECT_DATA in your solution manager production system. Select the option Schedule Analysis:

When the job is finished select Download Analysis Data and save the file.

Upload the result file on the Readiness page in SAP for me on this URL.

Result of the check

After the upload, wait up to 1 hour for SAP to process the results. For full explanation of the checks, read this SAP blog. Short description is below:

Top left you get an overview of the capabilities that were detected that are currently in use in Solution manager, or were used in the past:

Below is the most important overview. This shows if your used functions are available on Cloud ALM or will come in the near future, or only on the far Vision future:

SAP Cloud ALM positioning

Read more on SAP Cloud ALM positioning in this blog.

SAP Cloud ALM activation

Read more on SAP Cloud ALM activation in this blog.

Solution manager clean up

For parts of solution manager that you don’t use, you can perform the technical clean up.

Archiving MM- Accounting interface posting data

This blog will explain how to archive MM accounting interface posting data via object MM_ACCTIT. Generic technical setup must have been executed already, and is explained in this blog.

The MM_ACCTIT is strange object. Since it is about intermediate data which is normally not viewed by users, there is no read program. In worst case there is a reload program. Do also read about the option to stop using these intermediate tables if the business does not require them.

Avoiding data in MM-accounting interface tables

Please check OSS note 48009 – Tables ACCTHD, ACCTIT, ACCTCR: Questions and answers to see if you can fully avoid data being written to the tables.

Object MM_ACCTIT

Go to transaction SARA and select object MM_ACCTIT.

Dependency schedule (no dependency):

Tables that are archived:

Technical programs and OSS notes

Write program: MM_ACCTIT_WRI

Delete program: MM_ACCTIT_DEL

Read program: none. Only write and delete.

Relevant OSS notes:

Application specific customizing

MM_ACCTIT has no application specific customizing.

Executing the write run and delete run

In transaction SARA, MM_ACCTIT select the write run:

Select your data, save the variant and start the archiving write run.

After the write run is done, check the logs. MM_ACCTIT archiving has high speed and high percentage of archiving (up to 100%).

Deletion run is standard by selecting the archive file and starting the deletion run.

Data archiving: CO line items

This blog will explain how to archive CO line items via object CO_ITEM. Generic technical setup must have been executed already, and is explained in this blog.

Object CO_ITEM

Go to transaction SARA and select object CO_ITEM.

Dependency schedule (no dependency):

Tables that are archived:

Most important:

  • COEP: CO line items
  • COBK: CO object document header

Technical programs and OSS notes

Write program: CO_ITEM_WRI

Delete program: CO_ITEM_DEL

Read program: RKCOITS4

Relevant OSS notes:

Application specific customizing

In the application specific customizing for CO_ITEM you have to set the residence time in months per CO type:

Executing the write run and delete run

In transaction SARA, CO_ITEM select the write run:

Select your data, save the variant and start the archiving write run.

Give the archive session a good name that describes date range. This is needed for data retrieval later on.

After the write run is done, check the logs. CO_ITEM archiving has average speed, but high percentage of archiving (up to 100%).

Deletion run is standard by selecting the archive file and starting the deletion run.

Data retrieval

Start the data retrieval program and fill selection criteria:

To avoid reporting issues, see OSS note 2676572 – SARI/KSB5 Archived documents not displayed in line item report, fill the archiving structure SAP_CO_ITEM_001.

Data archiving: purchase documents

This blog will explain how to archive purchase orders and purchase documents via object MM_EKKO. Generic technical setup must have been executed already, and is explained in this blog.

Object MM_EKKO

Go to transaction SARA and select object MM_EKKO.

Dependency schedule:

No dependencies.

Main tables that are archived:

  • EKKO: purchase document header
  • EKPO: purchase document item

Technical programs and OSS notes

Pre-processing program: RM06EV70

Write program: RM06EW70

Delete program: RM06ED70

Read program: RM06ER30

Relevant OSS notes:

Application specific customizing

In the application specific customizing for MM_EKKO you can maintain the document retention time settings:

You have to set the residence time per purchase order type:

Preprocessing

In transaction SARA, MM_EKKO select preprocessing:

There are quite some reasons why a purchase order cannot be archived.

Executing the write run and delete run

In transaction SARA, MM_EKKO select the write run:

Select your data, save the variant and start the archiving write run.

Give the archive session a good name that describes the purchasing group and year. This is needed for data retrieval later on.

After the write run is done, check the logs. MM_EKKO archiving has average speed, and medium percentage of archiving (50 to 90%).

Deletion run is standard by selecting the archive file and starting the deletion run.

Data retrieval

For MM_EKKO start the read via SARA:

Then select the archive file(s).

Result is in a simple list.

If you setup the archiving infostructures, the popup with the files will be skipped.

Data archiving: change documents

This blog will explain how to archive change documents via object CHANGEDOCU. Generic technical setup must have been executed already, and is explained in this blog.

Object CHANGEDOCU

Go to transaction SARA and select object CHANGEDOCU.

Dependency schedule: (none):

Change documents are archived as part of other archiving objects. For specific changes you might want to archive the changes sooner to get a grip on CDHDR and CDCLS/CDPOS table sizes and amount of entries.

Main tables that are archived:

  • CDHDR (change header)
  • CDCLS (change details)

Technical programs and OSS notes

Write program: CHANGEDOCU_WRI

Delete program: CHANGEDOCU_DEL

Read program: CHANGEDOCU_READ

Reload program: CHANGEDOCU_REL

Relevant OSS notes:

Application specific customizing

No application specific customizing is required for CHANGEDOCU archiving.

Executing the write run and delete run

In transaction SARA, CHANGEDOCU select the write run:

Select your data, save the variant and start the archiving write run.

Give the archive session a good name that describes change document object(s) and year. This is needed for data retrieval later on.

After the write run is done, check the logs. CHANGEDOCU archiving has average speed and very high percentage of archiving (up to 100%).

Deletion run is standard by selecting the archive file and starting the deletion run.

Data retrieval

Don’t start the data retrieval program from SARA. Start program CHANGEDOCU_READ from SA38 (see OSS note 3395609 – Default read program for CHANGEDOCU in transaction AOBJ):

In the second screen select the archive files. Now wait long time before data is shown.

For faster retrieval, setup data archiving infostructures SAP_CHANGEDOCU1 and SAP_CHANGEDOCU2. These are not active by default. So you have to use transaction SARJ to set them up and later fill the structures (see blog).

Now transaction RSSCD100 can be use for data retrieval:

Don’t forget to select the tick box “Read from archive info system”.

Another option is via transaction SARE (archive explorer) and then choose object CHANGEDOCU with archive structure SAP_CHANGEDOCU1.

Data archiving: purchase requisitions

This blog will explain how to archive purchase requisitions via object MM_EBAN. Generic technical setup must have been executed already, and is explained in this blog.

Object MM_EBAN

Go to transaction SARA and select object MM_EBAN.

Dependency schedule:

No dependencies.

Main table that is archived:

  • EBAN (Purchase requisitions)

Technical programs and OSS notes

Pre-processing program: RM06BV70

Write program: RM06BW70

Delete program: RM06ID70

Read program: RM06BR30

Relevant OSS notes:

Application specific customizing

In the application specific customizing for MM_EBAN you can maintain the document retention time settings:

You have to set the residence time per requisition type:

Preprocessing

In transaction SARA, MM_EBAN select preprocessing:

There are quite some reasons why a purchase requisition cannot be archived.

Executing the write run and delete run

In transaction SARA, MM_EBAN select the write run:

Select your data, save the variant and start the archiving write run.

Give the archive session a good name that describes the purchasing group and year. This is needed for data retrieval later on.

After the write run is done, check the logs. MM_EBAN archiving has average speed, and medium percentage of archiving (50 to 90%).

Deletion run is standard by selecting the archive file and starting the deletion run.

Data retrieval

For MM_EBAN start the read via SARA:

Then select the archive file(s).

Result is in a simple list:

Data archiving: WM transfer requirements and orders

This blog will explain how to archive WM transfer orders and requirements via objects RL_TA and RL_TB. Generic technical setup must have been executed already, and is explained in this blog.

Objects RL_TA and RL_TB

Go to transaction SARA and select object RL_TA and RL_TB.

Dependency schedule (no dependencies for both):

Main tables that are archived:

  • LTAK (transfer order header)
  • LTAP (transfer order item)
  • LTBK (transfer requirement header)
  • LTBP (transfer requirement item)

Technical programs and OSS notes

RL_TA:

Write program: RLREOT00S

Delete program: RLREOT10

Read program:RLRT0001

RL_TB:

Write program: RLREOB00S

Delete program: RLREOB10

Read program: RLRB0001

Relevant OSS notes:

Application specific customizing

RL_TA and RL_TB don’t have application specific customizing.

Typically RL_TA and RL_TB will yield 90 to 100% documents that can be archived.

Executing the write run and delete run

In transaction SARA, RL_TA or RL_TB select the write run:

Select your data, save the variant and start the archiving write run.

Give the archive session a good name that describes sales warehouse and year. This is needed for data retrieval later on.

After the write run is done, check the logs. RL_TA and RL_TB archiving has average speed, and a high percentage of archiving (up to 90 to 100%).

Deletion run is standard by selecting the archive file and starting the deletion run.

Data retrieval

Start the data retrieval program and fill selection criteria for transfer orders:

Start the data retrieval program and fill selection criteria for transfer requirements:

In the popup screen select the wanted archive files.

SAP Solution builder

The S4HANA SAP solution builder can be used to generate SAP best practice content in your S4HANA system as a quickstarter.

Questions that will be answered in this blog are:

  • How to activate SAP solution builder?
  • How to activate a specific solution building block?

Updating solution builder

By default the solution builder is already present. The content is regularly updated. So before starting with the solution builder, read and follow the instructions:

2914416 – SAP S/4HANA 2020 collective note for content activation

3053781 – SAP S/4HANA 2021 collective note for content activation

3199321 – SAP S/4HANA 2022 collective note for content activation

They will refer to content to be uploaded, OSS notes to apply.

Activation of content

Start the solution builder with transaction /SMB/BBI:

First load the data: menu option Solution/ import / global meta data / From reference content.

Now we want to import reference content for specific country. From menu options choose Solution / import / Solution (XML) / From reference content:

In this case we choose US. Now wait until the building blocks are loaded.

From this template we will make a copy to run with limited blocks. First select the copy button and enter the details:

Important now: set this copy to your favorite with the button!

Double click on the solution. Use the tick boxes to set the desired scope:

You can check if you want by clicking the Building Block Builder button that indeed only this content is present now:

On the empty icon on the right you can see the data is not yet loaded:

Select from the menu option Solution / Import / Installation data / From reference content. Wait again and refresh screen. Data should now be loaded.

With the data loaded we can now click on the button Implementation Assistant to start the activation process.

Select the activate button:

Press enter in this screen:

Activation will run.

Check the results:

In SE10 you can find your transport with the customizing activities performed.

Background reference

OSS note 3126942 – Jump Start Your SAP S/4HANA 2021 Implementation by Activating SAP Best Practices contains an excellent description of all the steps and at the end a detailed list of knowledge OSS notes for specific topics of the solution builder.

For SAP help reference click here.

Linux versions and support for Linux

Many SAP system use Linux as operating system.

It is important that you check you run a supported combination of Linux OS, database and application.

SAP HANA OS support

For SAP HANA database, the master note is 2235581 – SAP HANA: Supported Operating Systems. This note contains the references to all the version specific OSS notes.

Checking kernel and LINUX version in SAP system

To check your kernel and LINUX version, go to System Status and then open the Other Kernel Info button:

Another option is to run function module TH_SAPREL3 in SE37:

Translating the version

You have to use the RedHat or SUSE site to translate the kernel number into the LINUX OS version.

Example:

This version

Translates to:

So RedHat version 8.7.