SAP Archives » Page 32 of 40 » Musings of an IT Implementor

All Reports & Transactions Under SUIM

The list below is useful if you are constructing a roll to house the SUIM capabilities:

Users by System S_BIE_59000198

Users by Roles S_BIE_59000199

Users by Profiles S_BIE_59000197

Users by Address Data S_BCE_68001393

Users by Complex Selection Criteria S_BCE_68001400

By user ID S_BCE_68001394

By Role S_BCE_68001399

By Profiles S_BCE_68001395

By Authorizations S_BCE_68001396

By Authorization Values S_BCE_68001397

By Transaction Authorizations S_BCE_68001398

By Critical Combinations of Authorizations at Transaction Start S_BCE_68001401

With Unsuccessful Logons S_BCE_68001402

By Logon Date and Password Change RSUSR200

List of Users With Critical Authorizations S_BCE_68001403

With Critical Authorizations (New Version) S_BCE_68002111

Roles by Complex Selection Criteria S_BCE_68001425

By Role Name S_BCE_68001418

By User Assignment S_BCE_68001419

By Transaction Assignment S_BCE_68001420

By MiniApp S_BIE_59000249

By Profile Assignment S_BCE_68001421

By Authorization Object S_BCE_68001422

By Authorization Values S_BCE_68001423

By Change Dates S_BCE_68001424

Profiles by Complex Selection Criteria S_BCE_68001409

By Profile Name or Text S_BCE_68001767

By Profiles Contained S_BCE_68001404

By Authorizations S_BCE_68001405

By Authorization Values S_BCE_68001406

By Last Change S_BCE_68001407

By Role S_BCE_68001408

Authorizations by Complex Selection Criteria S_BCE_68001417

By Object S_BCE_68001414

By Values S_BCE_68001415

By Last Change S_BCE_68001416

Authorization Objects by Complex Selection Criteria S_BCE_68001413

By Object Name, Text S_BCE_68001410

By Object Class S_BCE_68001411

By Field, Text S_BCE_68001412

Executable Transactions (All Selection Options) S_BCE_68001429

Executable for User S_BCE_68001426

Executable for Role S_BCE_68002041

Executable with Profile S_BCE_68001427

Executable with Authorization S_BCE_68001428

From users S_BCE_68001430

from Roles S_BCE_68001777

From profiles S_BCE_68001431

From authorizations S_BCE_68001432

In Users S_BCE_68001399

In Users S_BCE_68001395

In Roles S_BCE_68001421

In Composite Profiles S_BCE_68001404

In Users S_BCE_68001396

In Profiles S_BCE_68001405

In Users S_BCE_68001397

In Roles S_BCE_68001423

In Profiles S_BCE_68001406

In Authorizations S_BCE_68001415

In Programs S_BCE_68002030

For Users S_BCE_68001439

for Role Assignment RSSCD100_PFCG_USER

For Roles RSSCD100_PFCG

For Profiles S_BCE_68001440

For Authorizations S_BCE_68001441

How to Patch an Oracle Database Under SAP

Are you thinking of patching an Oracle database which sits under an SAP system?
If you have a specific bug and you’ve identified the Oracle patch number that fixes the bug, you’d be tempted to just download the patch from Oracle.

According to SAP, you should not download any patches from Oracle directly. As you know, the Oracle binaries themselves are slightly different for an SAP system.
Instead, if you have the Oracle patch number, search through the README files that come as part of the SAP Bundle Patch (SBP) for Oracle downloads located on the marketplace: https://service.sap.com/oracle-download to see if the Oracle patch is included in the bundle patch.

If you can’t see it in there, then it may be worth asking SAP to clarify if/when they may include it in the next bundle patch.
Each bundle patch is released monthly, but it may not mean that relevant Oracle patches older than a month are included in the bundle.

The bundle patches themselves are cumulative, so you only need to apply the latest one. It includes specific Oracle patches, plus a CPU patch (dependent on the date/time of the released SBP).

Remember to re-check the SAP notes about Oracle database parameters after applying SBPs, since SAP usually update the notes at each SBP release, to include any relevant _fix_control or event parameter settings.

SAP Authorisation Objects Naming Convention

The first letter of SAP authorisation objects is intelligently coded to represent the SAP module for which it belongs:
e.g. F_KNA1_BUK

A Assets Accounting
C Classification System
E Consolidation
F Financial Accounting
G Special Ledger
K Controlling
L Logistic execution
M Materials Management
P Human Resources
S Basis
V Sales and Distribution

If the second character is an underline, then this indicates this authorisation object is a SAP standard one.

Use transaction SU03, SU21 or table TOBJ, to list the authorisation objects in the system and drill-down into the authorisation fields and their possible values.

If using the tables, you may need the other related tables to pull the texts: TOBJ, TOBC (classes), TOBJT.

SAP Users With Roles Not Assigned via Composite Roles

Have you ever needed to list SAP roles that are assigned to user accounts, but show only the single roles that are directly assigned (not single roles inherited through composite roles)?

Here’s how you can do it:
Using SE16, get the records from AGR_USERS table with field COL_FLAG=’ ‘

Relate this to USR02 table BNAME field to decide if the user account is locked (valid) or not in use anymore.

I’ve also discovered this can be done in transaction S_BCE_68001394 (Users by User ID). You just input * into the user ID field, execute the report and then sort the two columns for “Direct Assignment” and “Role Type”. This will give you the Single roles assigned directly.

R/3 to ECC – Benefits of not upgrading anything?

This is a question that will probably be asked by many IT persons over the coming months, as SAP draws to a close support for the SAP R/3 4.7 system.
(see the SAP production availability matrix https://service.sap.com/pam).
Whilst upgrading to ECC will mean a SAP supported system, what other options are out there?
Let’s look at just a few so that you may have some ideas that you maybe hadn’t considered.

– Stay where you are and pay for extended support.
This is an interesting option. Let’s face it, if you use SAP as a basic product e.g. for accounting or sales transactions, then exactly what else will you need from a product in the future? Why not save the upgrade costs and simply pay for extended support, and keep paying each time it expires.
Whilst the initial support costs may be known, the future costs are not and SAP could hike these. Also, there may be a fairly straight upgrade path to a newer product at the moment, but in the future you may have to follow that path, plus the additional paths and intricacies of upgrades to later versions in order to reach something more modern (UNICODE anyone!).
Things like OS support may bite you eventually, and those of you on HP-UX Itanium are already seeing what happens to non-x86 based operating systems when companies like Oracle decide to stop supporting you. Your future upgrade path could involve skill-sets no longer available/costly, or even more lengthy processes because you’re moving from older hardware.
On the positive side, the future could hold hope in the form of faster systems, smarter tools and cheaper processes that could make future upgrades/migrations faster and cheaper than doing it now. A big database in the future may not be so big in relational terms.

– Stay where you are and don’t pay for extended support.
You will loose all access to standard SAP support sites and tools, plus you will not benefit from any DB updates or DB vendor support.
This could be very problematic if your business needs to apply SAP legal patches for changes to HR related functions within the SAP modules.
I’m not entirely sure if you will still be able to request SCCR keys for modifying SAP objects or even be able to develop your own ABAP code in your own system. Maybe someone can let me know on that one.
Some of the words in Oracle Database support contracts state that you may have to back-pay for support if you decide to re-enable support at a later date. I’m not sure if SAP would be the same.
You would potentially suffer during external audits if additional security related legislation comes along (SOX for example) and you are not able to apply the updates/functionality to provide that security.

There are some common issues with both options above. These mainly centre around the IT resources that are supporting those systems. Nobody likes to stay still in IT. Not unless they are happy in the knowledge that retirement is looming and they just need to keep rolling in the meantime.
The constant need to keep abreast of the latest technical enhancements/changes is one of the most difficult aspects of the IT profession.
However, with the advent of off-shore IT resources, it should be possible to secure long-term support resources even if you can’t secure them on-shore. Having said that, I don’t yet know of any off-shore company that has a high retention level. Maybe this is coming…

In summary, there are some cost advantages in the short term for not upgrading an SAP system. But unfortunately those costs may hit you in the end in some form or another.