S4HANA upgrade preparations

When you are already using S4HANA, you will still want to regularly upgrade to the newest version. This blog will explain the preparation steps for a next upgrade.

If you are looking for information about S4HANA conversion (from ECC to S4HANA): read this dedicated blog on S4HANA conversion preparations.

Questions that will be answered are:

  • What do I need to check as part of an S4HANA upgrade?
  • Where do I find information on the HANA database revision upgrade?
  • Do I need to run the simplifications check again?
  • Do I need to check my addons again?
  • How can I check for differences in SAP FIORI apps?
  • How can I reduce downtime for my S4HANA upgrade?
  • How can I know about changes to security parameters after the S4HANA upgrade?

HANA database revision

For each S4HANA upgrade, first you must apply the minimum revision published by SAP before you can start the upgrade.

You can apply this revision already in your running system as well.

HANA DB revision usage for S4HANA can be found in this OSS note: 2655761 – SAP S/4HANA – restrictions and recommendations regarding specific revisions of SAP HANA database for use in SAP S/4HANA.

Add ons

For each upgrade, you need to validate that the addons you use are already released for your target upgrade version.

Generic OSS note is 2214409 – SAP S/4HANA: Compatible Add-Ons. This will refer to version specific OSS note you must read.

Simplification items

For each upgrade, you must update the TCI note for the simplifications items and run the checks. See blog.

For an ECC to S4HANA conversion this list is long to very long (can contain over 100 items). For an upgrade from S4HANA lower to higher version, the list is typically only 10 or less items.

FIORI apps impacted by the upgrade

FIORI apps can change between versions. Older apps are replaced by new ones. You might need to act on this if the apps are used by the business. To get a list of SAP FIORI app differences, follow the instructions from this SAP blog.

Readiness check

Also for S4HANA upgrades from older to newer S4HANA version, you can run the readiness check. Read more about it in this blog.

SLT triggers

If you are using SLT triggers, also check this OSS note carefully: 2755741 – Potential Impact of SLT During SAP S/4HANA System Conversion / Upgrade of S/4HANA System. In some cases it is better to drop the triggers and recreate after the upgrade.

Custom code checks

A quick check on the use of unreleased SAP objects in custom code can help to avoid upgrade issues. To execute the run, check this blog.

Downtime reduction

An S4HANA upgrade can take a long time to run in productive system. It can take a complete day to execute the upgrade on production.

During your S4HANA upgrade you should really spend time on downtime minimization.

First step is to determine the maximum downtime you are allowed to have by the business. If you have this timing, use the first sandbox and development system conversions to measure the expected downtime as first estimate. You can use the downtime recording from the SUM tool. But you have to add time for many more elements:

  • Graceful shutdown
  • Transport imports after the upgrade
  • System validation before startup
  • Graceful startup

Test the actual downtime on your acceptance system. If required, you can also create extra copy of production to a special conversion upgrade dress rehearsal system to practice the downtime and your optimizations.

Tips for downtime reduction:

  1. Check the SUM options for downtime reduction
  2. Check the downtime optimization app from SAP: see this blog
  3. Consider to include customer transports in SUM: see this blog
  4. Consider to contact SAP if your system is very large and you outage window requirements are not met by the actual times. SAP can offer tailored services to further reduce your downtime. These services are expensive, but can be worth the money to help your project meet the business maximum downtime requirements

Security parameter changes

After S4HANA upgrade, there are new and updated security parameters. Read more on this topic in this blog.

SAP best practices

SAP has an excellent best practice document “Upgrading SAP S/4HANA: Why, How, and Best Practices”.

Check custom code for use of unreleased SAP objects

Custom code can use standard SAP code and SAP objects. Some of these objects might technically exist, but are in an unreleased status. This might mean SAP will not give support on them, or might remove them in a future upgrade.

Also when you want to move to the BTP ABAP cloud, you cannot use the unreleased code.

Questions that will be answered in this blog are:

  • How can I scan my custom code for use of unreleased standard SAP objects?

Tool preparation

First install the program SYCM_UPLOAD_RELEASED_OBJECTS by applying OSS note 2989803 – Check Usage of Released Objects with the Latest List of Released Objects.

And download the attached file in the same note in the attachments section;

Now run program SYCM_UPLOAD_RELEASED_OBJECTS and upload the file to a new SCI variant:

After the upload, you will find this new variant in SCI:

ATC run for unreleased code

Now you can start new ATC run with this newly created variant:

Run the variant for you custom code (can take few hours).

Result can be shown as special whitelist item:

ST06 OS host monitoring

If you want to see how well your OS is doing in terms of CPU, memory, disc utilization, etc, then transaction ST06 OS host monitoring is your solution.

Questions that will be answered in this blog are:

  • How to use transaction ST06?
  • How to get information on CPU, memory and disc usage on OS level?
  • What is different in ST06 when my SAP system runs in the cloud?

ST06 transaction

Start transaction ST06:

Top left you can select the application server you want to inspect. On the right screen you see the details. Bottom left you can select different tools or specific sections and history.

For more background on all ST06 issues and functions, read OSS note 2067546 – ST06/OS07N: Overview note.

ST06 and systems running in cloud

If your SAP system runs on infrastructure in the cloud, your infrastructure provider may have a certain setup that may not allow all ST06 functions to work as with a system installed in your own data center.

OSS notes on this topic:

ABAP code to write to application log

The SLG1 application log is a powerful mechanism to support team in SAP systems.

This blog will explain how you can write to the application log in your own custom ABAP code using ABAP code below.

It is recommended to create one single SE24 ABAP class for the application log that can be re-used in all your custom code.

Instantiation method

First method to create is the instantiation method:

   DATA: zls_log        TYPE bal_s_log,
         zlt_log_handle TYPE bal_t_logh,
         zlt_message    TYPE bal_t_msg. 

      zls_log-object     = ziv_object.
      zls_log-subobject  = ziv_subobj.
      zls_log-extnumber  = ziv_extnumber.
      zls_log-aluser     = sy-uname.
      zls_log-alprog     = sy-repid.


 CALL FUNCTION 'BAL_LOG_CREATE'
      EXPORTING
        i_s_log                 = zis_log
      IMPORTING
        e_log_handle            = zgv_log_handle
      EXCEPTIONS
        log_header_inconsistent = 1
        OTHERS                  = 2.

As input you have to give SLG1 object name and sub object name. You can re-use existing or create new custom one in transaction SLG0.

Now you have a log handler.

Add the messages

Now you can add a method to add one or more messages, re-using the log handler:

zls_msg      TYPE bal_s_msg,

      CALL FUNCTION 'BAL_LOG_MSG_ADD'
        EXPORTING
          i_log_handle     = zgv_log_handle
          i_s_msg          = zls_msg
        EXCEPTIONS
          log_not_found    = 1
          msg_inconsistent = 2
          log_is_full      = 3
          OTHERS           = 4.

Save the log

Create a method for saving the application log, again re-using the log handle:

    CALL FUNCTION 'BAL_DB_SAVE'
      EXPORTING
        i_t_log_handle   = zlt_log_handle
      EXCEPTIONS
        log_not_found    = 1
        save_not_allowed = 2
        numbering_error  = 3
        OTHERS           = 4.

Set up once and re-use

Set up the application logging helper class once in SE24 and tell all your developers to re-use it. You might find out that you developer already used the function modules above a lot in their Z code. This can be found with the ABAP code scanner tool. Check case by case when it makes sense to swap to the central helper class.

SLG1 application log

SLG1 application log is a powerful function in supporting productive system. This blog will explain the backgrounds.

Questions that will be answered in this blog are:

  • What is the intended use of SLG1 application log?
  • Should SLG1 application log be used by the business or IT only?
  • How can I download or export the logs from SLG1?
  • How can I clean up or delete SLG1 logging?

Intended use of SLG1 application log

The SLG1 application log is primarily intended for use by IT staff to support the SAP system. The logging can be used to analyze issues that the user is reporting, without IT staff requiring direct access to the business data transactions (not even to display data). Most standard SAP applications will log errors in the application log.

The logging can be for:

  1. Technical errors
  2. Functional error (like missing customizing)
  3. (master) data errors

When you are having frequent (master) data errors that primarily show in SLG1 application logging, it can make sense to give access to SLG1 for your business key users. You should train them on the transaction, since it might be too technical for them.

Use of SLG1 application logging transaction

Start the application logging with transaction SLG1 and fill the required fields:

Best to start with Only important logs to reduce the volume.

Output can look like below:

On top open the alert and click on it. At the bottom part of the screen the details will be displayed.

SLG1 objects

The object and subobjects for data filtering in SLG1 are defined in transaction SLG0:

Export of SLG1 logging

To export SLG1 logging, start transaction SLGD:

The output of SLGD can be done on ALV screen, from which you can download the data.

More background in OSS note 2546052 – Transaction SLG1 – Cannot download or export error logs.

Deleting SLG1 application log

You can use transaction SLG2 to delete the application log. For more details see blog on technical clean up.

Logging levels

Next to deletion there is another option to reduce the amount of application log entries: setting the logging level. In many customizing settings for diverse applications, the log level can be set. This can range from: error only to everything. The everything setting is typical for a development system. The error only is typical for a productive system. Upon issues, you can still set the productive system temporarily to everything. Unfortunately: this feature is per function and has to be setup in customizing in the specific application, and not all functions support the log level settings function.

ABAP code to write to application log

If you want to write entries to the application log in your custom ABAP code, read this blog.