SAP has done an improvement on TAANA to count dynamic subfields. This blog will explain how. More generic information on TAANA can be found in this blog.
Questions that will be answered in this blog are:
How to get the new TAANA function for dynamic subfields?
How to run TAANA dynamic subfields?
How to get the new TAANA function for dynamic subfields?
We will use table JEST as example. This table as a pretty annoying setup. The main field OBJNR is in fact 2 fields: the first 2 characters are object identification, and the second part is a number for the object. But if you want to analyze how many objects type you have this is problematic with SE16.
In TAANA we can use the dynamic subfields. Start transaction TAANA and create an Ad Hoc Anlysis for table JEST. First hit Execute to start, enter table JEST and in this screen hit the Ad Hoc Variant button:
Now select the OBJNR field:
In the Offset field fill 0. And in Subfield length 2. This means take first 2 characters of field OBJNR. Press ok and start the run in the background.
The end result is a cross section with counts on the types of the first 2 characters in JEST-OBJNR:
SE16S and SE16H
For some searches, also have a look at SE16S and SE16H.
SE16H is a HANA specific implementation of SE16. This blog will explain the additional functions of SE16H.
Questions that will be answered in this blog are:
How to use SE16H?
Where to find full list of SE16H functions?
Which bug fix notes for SE16H should I apply?
SE16H: HANA specific implementation of SE16
SE16 or SE16N are one of the most used transactions for data analysis on any SAP system. SE16H is the HANA specific implementation which leverages some of the HANA specific strengths.
Transaction code to start is simply SE16H. We now enter VBAK as example table. Just pressing execute will give simple list of first 500 entries. Nothing new.
Now we run again, but tick the Group and Sort tick boxes for the Document Category field:
The output now is a sum of the sales orders in table VBAK grouped by identical Document Category:
TAANA vs SE16H vs SE16S
If you run on HANA, the SE16H transaction is a faster option than the classical TAANA transaction, since SE16H runs online and TAANA runs as batch.
SE16H is for lookup of single table. SE16S can search for content in one or multiple tables. More on SE16S in this blog.
This blog addresses the main challenge in SAP data archiving for functional object: the discussions with the business.
This blog will give answers to the following questions:
When to start data archiving discussion with the business?
How to come to good retention periods?
What are arguments for not archiving certain data?
Data archiving discussion with the business
Unlike technical data deletion, functional data archiving cannot be done without proper business discussion and approval.
Depending on your business several aspects for data are important:
Auditing and Sox needs
Tax and legal retention periods
Product data requirement
And so on…..
Here are some rules of thumb you can use before considering to start up the business discussions about archiving:
Rule of thumb 1: the system is pretty new. At least wait 3 years to get an insight into which tables are growing fast and are worth to investigate for data archiving.
Rule of thumb 2: if your system is growing slowly, but the infrastructure capabilities grow faster: only perform technical clean up and don't even start functional data archiving.
Rule of thumb 3: if you are on HANA: check if the data aging concept for functional objects is stable enough and without bugs. Data aging does not require much work, it is only technical and it does not require much business discussions. Data retrieval from end user perspective is transparent.
Data analysis before starting the discussion
If your system is growing fast and/or you are getting performance complaints, then you need to do proper data analysis before starting any business discussion.
Start with proper analysis on the data. Use the TAANA tool to get insights into the data: how is the distribution of data per document type, per year, per plant/company code etc. If you want to propose retention period of let’s say 5 years, you can use the TAANA results to show what percentage of data you can move out of the database.
Secondly: if you have an idea on which data you want to archive, first execute a trial run on a recent production copy. There might be functional blocks that prevent you from archiving data (like not closed documents).
Third important factor is the ease of data retrieval. Some object have a nice simple data retrieval function, and some are really terrible. If the retrieval is good, the business will more easily accept a shorter retention period. Read more on technical data retrieval in this blog.
As last step you can start the business case: how much data will be saved (and how much money hence will be save) and how much performance would be gain. And how much time is needed to be invested for setting up, checking (testing!) and running the data archiving runs.
In practice data archiving business case is only present in very large systems of 5 TB and larger. This sizing tipping point changes in time as hardware gets cheaper and hourly manpower costs go up.
The discussion itself
Take must time in planning for the discussion itself. It is not uncommon that archiving discussions take over a year to complete. The better you are prepared the easier the discussion. It also helps to have a few real performance pain points to get solved via data archiving. There is normally a business owner for this pain point who can help push data archiving.
This blog will explain how to execute a data archiving run.
Questions that will be answered in this blog are:
Which settings do I need to make or check before data archiving run?
How to perform the data archiving run?
How to validate the data archiving run?
How to retrieve that archived data?
This blog assumes you have finished the basic technical data archiving setup as described in this blog. It also assumes you have made agreements with your business on the retention periods. For more information and tips on discussions with the business teams on data archiving, read this blog.
If you are looking for specific functional data archiving runs:
Functional data archiving example: purchase requisitions
To explain the functional data archiving we will use Purchase Requisitions as example. Technical object name is MM_EBAN.
To see which tables are archived hit the Database Tables button. Here you can see the list of tables from which data potentially be archived:
If you want to see the other way around, which table is used in archiving objects, do put in the table as entry point, to retrieve list of archiving objects. In this example archiving objects that delete from table EBAN:
Dependency of objects
By clicking the top left button on the archiving object you get the archiving dependency view. For MM_EBAN this is pretty simple: it has no dependencies.
As example for dependencies this is the overview for sales orders (SD_VBAK):
Here you can see that before you can archive sales orders, you should archive the billing documents first. And for the billing documents, you should archive the deliveries first.
Functional archiving settings
First we have to make or check the object specific functional archiving settings.
In the case of purchase requisitions we have to set the retention periods per document type:
Pre-processing step
Some archive object have a pre-processing step. MM_EBAN has one as well. In this step data is selected and marked for archiving (many times by setting deletion flag or other indicator).
In the step create the variant (give it a useful name) by putting in the name and pressing Edit. On the next screen fill out your data select the log level. Go back to the first screen and select the start data and spool parameters. When both lights are green, hit the execute button. When you click the job log button you check for the results.
Example of result of pre-processing run:
As you can see not all selected data is archived. Transactions that are not completed from business point of view will not be flagged for archiving.
Write run
If you have done the pre-processing step, continue with the write step. Principle is the same: select the data and log level. Important in the write step is to correctly fill the Archiving Session Note with a useful text. This text is put as label on the archive file for later retrieval:
When done plan the job and execute. Result looks like:
Pending on your technical system settings the file will be stored automatically or you still need to do this manually.
Storage run
If you have setup the system to store files in content server, you first have to execute storage run. For more details see this dedicated blog.
Deletion run
Finally we can now start the deletion run: the actual clean up of old data happens now.
Select the data files you want to archive and start the run.
Word of care with deletion: please don't select too much files and subsection in one go. Each file sub section will result into a deletion job. The deletion will put significant load on the database, since it will be pushing out a lot of data. If you are not careful you will launch easily 20 or more heavy deletion jobs that run in parallel and that might severely decrease system performance.
Result of archiving deletion run:
Checking archive result
The result checking is possible by looking at the technical correctness of the archive file.
In the archiving object choose the Overview button. Then select the archive file you want to inspect. A correct file should like like this:
In the testing phases and first production runs, you also want to do record counting. A good way is to run the TAANA transaction for key tables you want to archive before the archiving and after the archiving. The difference should match the deletion counter on the write and deletion logs. If you find differences: check for bug fix OSS notes.
Data retrieval
Retrieving archived data is different per archived object. Some retrieval is nicely integrated into the normal transaction. Some require extra transaction to run. Some retrieval is via special program.
Data retrieval of purchase requisitions can be done via SARA and choosing the read option.
Here you first need to manually select the archive files to read from (see I did not give the note and regret it, since the file has no meaning now…):
Before starting to check the data archiving for an object, it is best to check and read the OSS notes for the pre-processing, write, delete and read programs. Apply the bug fix notes and read about certain aspects, before you have time-consuming effort to figure out you have a bug or a certain feature that is documented inside the notes.
Controlling amount of parallel batch jobs
The deletion phase of archiving can lead to uncontrolled amount of parallel batch jobs. See this dedicated blog on how you can control it.
Data archiving run statistics
Transaction SAR_DA_STAT_ANALYSIS can be used to collect statistics on the data archiving runs:
FIORI app
If you are running recent version of S4HANA, you can also use a FIORI app for monitoring the data archiving runs. Read more in this dedicated blog.
This blog will explain the general technical setup to be performed for SAP data archiving.
Questions that will be answered in this blog are:
Which generic settings do I need to make for data archiving in the technology domain?
Why should I use a content server to store archive files?
For getting insights in what to archive, read this dedicated blog first.
Data archiving content server setup
For data archiving you can use the file system for storing the archive files. This you can do to perform initial testing. For productive use it is best to store the archive files in a content server. It will not be the first time an overzealous basis person in need for file storage deletes some old files in a directory called /archive…..
After you install the content server, set up in OAC0 the customizing for the content server to use it for Archivelink:
In this initial screen no object is selected. Now press the Customizing button.
Set the Cross-Client File Names/Paths to your needs. You can do that from this menu, or directly from the FILE transaction.
Set the physical path name to be used:
Even when you use content server the file will first be written to physical path for temporary storage.
And check the archive file name:
Technical settings per archiving object
Per archiving object you can set the technical settings. Normally you keep settings the same per object. Only for very large installations with archiving or special needs, you might want to deviate.
In the technical settings per data archiving object set the following:
Important settings to set:
Max size in MB or the max objects
Check the variants (some variants for production have still deliberately the test tick box as on: you have to change it)
Best to leave the delete jobs to Not scheduled (large archiving runs can create many files and many deletion jobs to kick in at the same time): best to do this manually in controlled way
Start storage automatically or manually is a choice for you
Best to store before deletion. This is the most conservative setting.
Best to delete only from storage system: if file is not stored properly in any way, deletion will not have. This is the most conservative setting.
Actual data archiving runs
How to execute the actual data archiving runs is explained in this dedicated blog.
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:
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:
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:
As you can see the 1.52 version is now updated to level 1.52.23. The 1.48 version is the same.
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.
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.
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:
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)
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.
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:
In SU01 such a user looks like this:
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:
On the first block set the dates for last logon and password change to get a good selection of users.
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):
How to test the deletion before executing in a productive environment?
Why delete clients 001 and 066?
The clients 001 and 066 had a purpose in the past and do not have them any more.
The only thing they do now is pose a security threat. Access can be gained to these clients, for example via standard SAP users, and from these client you could take over the system via a cross client attack. Background on client 066 can be found in OSS note 1897372 – EarlyWatch Mandant 066 – Can Client 066 be deleted?.
Also unwanted batch jobs might be still running from these clients consuming resources.
The deletion can be tested on a development and QA system before it is done on productive system. If really in doubt copy the productive system to a different system and perform the deletion there first as a test.
