BAPI_USER_GET_DETAIL — BAPI_USER_GET_DETAIL Read User Master Data

The BAPI acts on the user master record maintained through SU01 (technically stored across USR02, USR21, and the role and profile assignment tables). Given a username it returns everything a display in SU01 would show: logon data such as user type and validity dates, address data, default printer and time zone settings, assigned roles and profiles, user parameters, and lock status. It performs no write operations and requires no authorization to change anything, only to display. It is the standard mechanism identity management systems, GRC access review tools, and custom reporting programs use to pull a snapshot of a user's authorization footprint without opening a dialog session.

There is nothing to commit. The BAPI performs a read and returns data drawn from the current, already-committed state of the user master. Calling it inside a BAPI_TRANSACTION_COMMIT wrapper has no effect and is not required. The only behaviour worth watching is not commit-related but read-consistency related: if another session is mid-change to the same user (role assignment in progress, password reset in flight), the read reflects whatever is committed at the instant of the call, which can differ from what a screen open in the same moment shows if that screen has unsaved changes.

RETURN here is a table, not a single structure, which trips up developers used to single-message BAPIs. A username that does not exist produces an error-type row in RETURN and every export structure and table comes back empty rather than the call raising an exception. An interface that checks only whether the call executed without a system error, and never inspects RETURN for TYPE equal to E or A, will treat a nonexistent user as a real user with zero roles and zero profiles. In access review automation this is dangerous: a typo'd username or a user deleted between extraction and review reads as fully deprovisioned rather than as a lookup failure. The correct pattern is to loop RETURN, treat any E or A row as a failed lookup, and only trust ACTIVITYGROUPS, PROFILES and PARAMETER as meaningful when RETURN carries no error. A single S or blank RETURN table is not proof of success on its own; absence of an error row is what matters, not presence of a success row.

The BAPI remains valid and in active use on S/4HANA, on-premise and private cloud editions. SU01 itself is unchanged as the underlying transaction, and identity management middleware, GRC access control connectors, and custom compliance reports continue to rely on this BAPI for on-premise systems. For cloud identity scenarios newer identity provisioning services and OData-based user APIs are used instead, but within a classic ABAP stack this BAPI has not been formally deprecated or replaced by an equivalent released API.

Interface failures that stem from unchecked RETURN or client routing sit with the developer who wrote the calling program. Disputes about whether a role or profile shown (or missing) is correct sit with the security team, who need the raw ACTIVITYGROUPS/PROFILES table contents alongside the equivalent SU01 screen for the same user and client to compare, rather than a summary report.

SU01 is the transaction this BAPI mirrors in read mode. Underlying tables include USR02 for logon data, USR21 for address links, and the role and profile assignment tables behind the roles and authorization tabs. BAPI_USER_CREATE1 and BAPI_USER_CHANGE are the write-side siblings that share the same structural shape for logon data, address and role tables, which makes this BAPI a useful pre-read before calling either of them.