Audit-proof versioning of programs: VERS_AT_IMP


Hi there,

let’s have a look at a very handy system parameter, which is nevertheless not checked as frequently as others in audits — the tp parameter VERS_AT_IMP.

In a default installation, this parameter is set to »NEVER«, which means that no new version is created when transporting a program to a target system; the code is simply overwritten there.
If the parameter is set to »ALWAYS« (which is the only other valid option), a version history is maintained analogous to the development system.

Btw.: not only reports are affected by this, but all workbench objects that support versioning.

Functionality of tp parameter VERS_AT_IMP

Why does that matter?

The legal codes of many (all?) countries prescribe a duty to preserve records, which is also relevant for program code – the German HGB (Handelsgesetzbuch) for instance. Therefore, it is a risk to allow old program versions to be deleted (due to a lack of knowledge – or on purpose).

Developers are usually allowed to execute all reports on a development system, which also includes RSVCAD03 and RSVCAD04. These reports allow the deletion of a program’s version history (they’re NOT assigned to any program authorization group and the program code does NOT contain any AUTHORITY-CHECKs ← read comments below).

Update: Meanwhile SAP has added an authorization check for S_CTS_ADMI with value TABL to both programs. Anyway, this authorization is checked in many places and chances are high that some users have (and need) this authorization for other purposes. So, this does not change the general recommendation of this article…

Your options are:

  • if you want to keep the version history on the development system: do whatever it takes to secure RSVCAD03 and RSVCAD04 (just removing S_CTS_ADMI from all roles will not work, especially on non-productive systems) and be careful when restoring the system; you might lose versions (think of reinstallations)
  • set VERS_AT_IMP to »ALWAYS« on the productive system and keep your version history there (of course, the above reports have to be secured as well)

As you probably guessed, the second option is favorable, because:

  • authorizations on production are much more limited, so protecting the reports RSVCAD03/04 is much easier there
  • the continuity of a productive system can be ensured, while this is not true for a development system

Where to check it?

Start report RSTMSTPP, enter the productive system’s SID and go for it.

Where to set it?

Go to STMS → System Overview. Then double-click in your productive system and switch to the “Transport Tool” tab.
If the parameter does not appear there, it is set to the default value »NEVER«!

Update: Effect on installation of support packages

SPAM settings: Object versioning during support package installations


Switching the parameter to ALWAYS has no automatic effect on transaction SPAM. In other words: installing support packages does not lead numerous (useless) versions of SAP standard objects.
The simple reason is that SPAM allows you to choose whether to create versions of the objects in support packages or not (→ disabled per default).
To enable it, setting VERS_AT_IMP to ALWAYS is a prerequisite — check out SPAM → Extras → SettingImport queueCreate object versions during import — but be aware that this might have an impact on performance and database size.

So long!

+++ End of article +++
+++ Begin of article +++

What do SAP and a punk rock band have in common?


Hi folks.

Nothing, you say? Nope – that’s not exactly right.
I just found another “relict” in the SAP source code, while playing around a bit… 😆

If you’re interested in the lyrics of Blink 182‘s song “Obvious” (I am not), have a look at the SAP report RDDPUTJZ_REQUEST_COMP_CHECK3 and scroll down to the bottom:

Blink 182 song lyrics: Obvious

Someone at SAP must’ve been very bored!

Ciao!

+++ End of article +++
+++ Begin of article +++

Find obsolete SAP roles (not assigned for X days)


Hi,

from time to time I get in the mood to clean up one or two SAP systems – and lately, I was looking for obsolete roles, which weren’t assigned to anybody for a long time (e.g. used at least 365 days ago).

While looking around in SUIM and change documents, the developer inside me became more and more delighted – because there is no SAP standard solution for this → time for some R&D. 😛

Report

Here we go:

  • Create a new report in SE38 and paste this source code (don’t forget to set a program authorization group *cough*).
  • There’s no need to edit any of the selection texts, as they’re defined inside the report…
  • Activate & execute the program.

Usage

The report allows you to select:

  • the role names (all SAP standard roles excluded per default),
  • the user who created the role (default exclusion: “SAP”) and
  • the days since the role’s last assignment to any user (default: 180).

Result

The result consists of the following columns:

  • Role: well… the role name
  • Creation date: the role’s creation date
  • Change date: the date of the role’s last change
  • Removal date: the date of the last removal from a user
  • Removed by: the user, who performed the removal
  • Role name: the role description
  • 3 status indicator fields:

Role type:

The role type shows, whether it is a single or
composite role (using the standard SAP icons).

Status:

This icon equals to the traffic light icons on PFCG’s “Authorizations” tab
(→ green: generated, yellow: action required, red: not generated).
For composite roles, this field stays empty (since they have no profile).

SR used in CR:

For single roles, this icon indicates if the role is assigned to a composite
role (glowing bulb) or not (dark bulb). Of course, this makes no sense
for composite roles – so the field is empty then.

Final words

Obsolete / superfluous / unused roles on productive systems should be removed before they get moldy!

Happy holidays!

+++ End of article +++