EWA workspace

SAP Eearly Watch Alerts (EWA) has always been a primary tool delivered by SAP for system administrators to get an automated report on their SAP system.

The last few years SAP has been working very hard to get the EWA online as part of the support.sap.com pages. This development is now so far and good, that you can consider to switch using the online EWA workspace in stead of the EWA’s generated by your local solution manager system.

Questions that will be answered in this blog are:

  • How to access the online EWA workspace?
  • Can I still get my EWA in PDF or word format?
  • What are extra functions the online EWA workspace offers versus the traditional EWA?
  • Can I set up e-mails for EWA workspace to receive early watches?

EWA workspace

The EWA workspace can be reached on this URL: https://launchpad.support.sap.com/#/ewaworkspace.

The first page is the overview page:

By clicking on the tiles you can zoom in on the diverse topics.

EWA for single system

In the overall rating tile, you can click on the donut graph to goto the list of separate EWA’s:

Here you can open the word or PDF doc, or by clicking on the line goto the online EWA for the single system:

On each topic you can zoom in by clicking on the line:

Sending EWA data to SAP

To get the information to SAP still the local SAP solution manager system (or Focused Run, see this blog) is used to collect the data, and submit it to the SAP market place. In the past the sending was once per month. With the switch to the new backbone infrastructure this is now once per week. If the EWA is not received on SAP EWA workspace page, please check the reference OSS notes in OSS note 1684537 – EarlyWatch Alert not sent to SAP: troubleshooting guide.

Setting up mails on EWA workspace

Follow the instructions of OSS note 2530034 – How to set up e-mail, SMS, and/or launchpad notifications – SAP ONE Support Launchpad to setup mail notifications for the SAP early alert workspace.

Background on EWA workspace

The primary background site about the EWA workspace can be found here.

A great start for first users is this blog on the effective use of EWA workspace.

One of the functions on EWA workspace that add value over the traditional EWA is the performance evaluation. Read more on this SAP blog.

SAP logon user exit hack

In SAP there is a user exit just behind the logon of a user. This can be used correctly, but also used for hacking.

Questions that will be answered in this blog are:

  • How to switch on the user exit after logon?
  • What is good use of the user exit after logon?
  • How to use the user exit for hacking?

Activation of the user exit

In transaction SMOD you can call up user exit SUSR0001:

This exit has only one component:

Double click on the exit to go to the Z code include:

To activate the exit, create a project in CMOD and and include this enhancement. Then double click on the include code ZXUSRU01 to activate the code.

Good use of the user exit

The user exit itself is described in OSS note 37724 – Customer exits in SAP logon. Example of good use it to restrict multiple logons in case you cannot switch on parameter login/disable_multi_gui_login. See OSS note 142724 – Prevention of multiple SAPGUI logons.

The exit is also used a lot by GRC and firefighter type of tools.

The user exit logon hack

In the user exit code, you can put in your own stuff.

As hacking example: copy function module PASSWORDCHECK and the screen that belongs to it to your own ZPASSWORDCHECK.

Modify the screen logic a bit. This is the original code:

Now change the code: the password is always reported back as ok. And the user input you catch in the field password is yours: you can mail it or store it somewhere for you to pick up later.

Put the altered code in the user-exit with logic:

IF SY-UNAME = 'target user name' and not capture before.    
  Store capturing.     
  Set capture flag.

This looks as follows at runtime:

Many end users (and even auditors) will enter their password without thinking twice.

Alternatively you can use function module POPUP_GET_USER_PASSWORD as a basis for your copy: this has also clear text password:

The password field can be stored.

This has the following look and feel:

Detection and protection

It is wise to shield off this user exit from improper use and to yearly check the content of what is inside this user exit.

SAP pathfinder

SAP pathfinder is an SAP tool to give you insights into your system and let SAP tell you where they think you can improve, optimise and innovate.

Questions that will be answered in this blog are:

  • What is SAP pathfinder?
  • How do I run it?
  • Can I see a sample report of what I will get?

SAP pathfinder

SAP pathfinder is part of the innovation and value support part of SAP. The full background can be read on the SAP pathfinder site. This site includes video’s that explain everything.

On this site you can also find an example output report.

Background OSS notes:

How to run SAP pathfinder?

For SAP pathfinder you will need to upload 2 files to the SAP site:

  • EWA with BKF (business key figure) data
  • ST03N download data

The ST03N data is simple. If you do not have the BKF section yet in your EWA read on below.

If you have the files, upload them at the SAP site, confirm, and wait about 1 to 2 weeks before SAP has finished your report.

Main screen shot from the sample:

Setting up the BKF section in the EWA

OSS note 2282310 – Business Key Figures for EWA report contains the steps to get the BKF chapter activated.

Make sure in the managed system the user running the EWA data collection has the special role SAP_MANAGED_BPOANA_DIS. This is cause number 1 of issues.

If you make the settings, you would have to wait 3 weeks before the data is filled properly.

To gain speed, you can use the Express option. This option is explained in OSS note 2821062 – BKF Express Option/Manually running the BPMON job.

The UI of Business key figures Chapter Setting settings in the EWA is terrible. Please use the scroll bars to go to the right part. And the instruction mentions that you need to double click on a button or tab. This is correct. If you click once, nothing will happen. You really need to double click. This is completely counter-intuitive. But if you don't do it, it will not work, and you loose a lot of time.

If it still does not work, don’t hesitate to raise a message to SAP for component SV-SMG-SER-EWA.

SAP might ask you to apply the note 2477832 – SAP EWA Special Content BKF – on demand data collection (routine update & ZReport) as a workaround.

Central user administration (CUA)

Central user administration (CUA) is a great tool. Despite the fact that SAP has tried to replace it with IDM tools (IDentity Management). CUA remains efficient and reliable.

Questions that will be answered in this blog are:

  • What are use cases for CUA?
  • How to setup CUA?
  • How to monitor CUA?

Use cases for central user administration

Use cases for central user administration:

  • Management of users in the entire landscape (including production servers)
  • Management of users in non-production (sandbox, development, acceptance)
  • Management of users in client 000

Suppose you have a larger landscape consisting of 100 SAP systems and a new basis person will join. Good luck creating 100 user accounts… With CUA connected this is done in one shot.

And every now and then you need to go to client 000. You have forgotten the password, or due to security settings you users is automatically locked there after xx amount of days. With CUA you can simply reset your password there and log on.

Check if you are using to use SAP-GRC access control. This might conflict with CUA.

Set up of central user administration

In the central CUA system (also called CUA master) you need to set up a logical system for each CUA child system. Use transaction BD54 to create them.

Also setup 1 RFC in SM59 to each child system with this naming convention:


Use a non-expiring background user, with the appropriate rights, in this RFC. Make sure you update the whitelist for CUA in the RFC, otherwise you might get RFC callback error. See this blog.

Now start transaction SCUA:

Create a new model view and add the child system:

Do check that the RFC status is fine.

Save and activate the CUA model view:

Check in the master CUA system that the distribution model is created correctly. Start transaction BD64 and look for the CUA model:

Check in WE20 in the master CUA system that the partner profiles are correctly generated towards the child system:

Check that the outbound settings are set to collect the idocs.

If you have a user base up to 1000 users, you could set the idocs to immediately. With larger user bases: set to collect. Reason is that CUA will daily compare the child and master. It will generate 1 idoc per user. This will clog the child system if you do not set to collect. 

Check on the CUA child system that the WE20 partner profiles are also created correctly:

Also here, set the processing to collect in stead of process immediately.

In transaction SCUM you can make a very detailed configuration per field on which fields are globally maintained in the CUA master, and which local:

First synchronisation

After the first setup you need to do an initial synchronisation.

Start transaction SCUG:

First synchronise the Company address. Then synchronise the users. During user synchronisation you will get errors due to user groups. Each user group in the CUA child system needs to be defined in the CUA master system as well.

Transaction SCUL can be used to check the logging:

For text comparison a traffic light shows whether the child system supports it or not. See SAP note 1642106 – CUA|PFCG: Automatic text comparison of roles for central system. This note explains to update table USR_CUST:

For issues remaining with first setup, read OSS note 333441 – CUA: Tips for problem analysis.

Regular batch jobs

In the CUA master system plan the following batch jobs:

  • RSCCUSND (Send user master data to child systems), daily
  • SUSR_ZBV_GET_RECEIVER_PROFILES (text comparison between child and central), daily
  • RSEOUT00 (Send idocs to child systems), every 5 minutes

In the CUA child system plan the following batch jobs:

  • SUSR_ZBV_GET_RECEIVER_PROFILES (text comparison between central and child), daily
  • RBDAPP01 (Process idocs from the master system), every 5 minutes
Due to the jobs, a change in CUA master can take up to 10 minutes to be effective in the child system.

In the central system the next standard jobs are scheduled:


In the child systems the next standard jobs are scheduled:


More background information can be found in OSS note 399271 – CUA: Tips for optimizing ALE distribution performance.

CUA in action

If you goto SU01 in the master system, you see there is an extra tab called systems. And you have to specify the system for each role you assign to a user:

Copying a user can be done for multiple systems.

Also password resets can now be done for multiple systems in one shot.

Emergency cases

There might be emergency cases when CUA master is down or is having maintenance or issues, you might need to temporarily disconnect CUA.

Read OSS note 320449 – Deactivating the CUA temporarily. Run program RSDELCUA in the child system.

Background information

More background information: