BAPI_USER_CHANGE - Sperre

[Jolin2218]

Hallo Zusammen,

mal wieder eine Frage zur Benutzer-API. Weiß jemand von Euch, welchen Baustein ich verwenden muß, um für den Benutzerstamm ein Sperre abzusetzen. Mein Problem ist nämlich folgendes: Ich habe ein eigenes UI zum Verwalten von Usern (Anlegen, Ändern, etc.) Nun ergibt sich im Falle des 'Änderns' das folgende Problem:

Ich möchte in diesem Fall zuerst die aktuellen Userdaten lesen, und auf dem UI anzeigen. Wenn der Bearbeiter auf 'ändern' geht, dann muß eine Sperre auf den Benutzerstamm abgesetzt werden, solange bis der Bearbeiter die geänderten Daten abspeichert. Das ist dann der Zeitpunkt, zu dem die Daten vom UI an den BAPI_USER_CHANGE übergeben werden. Wenn das erfolgreich war, muss die Sperre wieder entfernt werden. Genau da liegt mein Problem. Welchen Baustein kann man verwenden, um diese Sperre zu setzen und welchen um die Sperre zu entfernen? Danke.

Gruss,
Jens

[Willy1492]

Was ist der Vorteil Deines eigenen UI gegenüber den SAP-Standard-Transaktionen?

Also wenn ich einen User mit SU01 ändere, erscheint in der SM12 eine Sperre auf ADRC (Shared) und eine auf USR04. Doppelklick bringt hierfür in einem Popup das Sperrobjekt E_USR04 hoch. (hätte man auch im Verwendungsnachweis für USR04 finden müssen).

Wenn ich übrigens das Paßwort eines Users ändern will, wird nur USR04 gesperrt.

ENQUEUE_E_USR04 und DEQUEUE_E_USR04 wären also die FBs, die Du brauchst.

Das ist die Logik, die BAPI_USER_CHANGE verwendet (in einer FORM, die in SUSR_BAPI_USER_CHANGE aufgerufen wird):

Code: [Select all] [Expand/Collapse] [Download] (Untitled.txt)

1.   DATA SY_SUBRC LIKE SY-SUBRC VALUE 1.
2.   DATA WAIT_TIME TYPE I VALUE 0.
3.  
4.   BNAME = P_USERNAME.
5.   WHILE SY_SUBRC = 1 AND WAIT_TIME < 60.
6.   CALL FUNCTION 'ENQUEUE_E_USR04'
7.        EXPORTING
8. *           mode_usr04     = 'X' "Note 198339; use default MODE='E'
9.             BNAME          = BNAME
10.        EXCEPTIONS
11.             FOREIGN_LOCK   = 1
12.             SYSTEM_FAILURE = 2.
13.        SY_SUBRC = SY-SUBRC.
14.        WAIT_TIME = WAIT_TIME + 1.
15.        WAIT UP TO  1 SECONDS.
16.   ENDWHILE.
17.  

GeSHi ©

[Jolin2218]

Hallo Frank,

Erstmal Danke für Deinen Hinweis, das hat mir auf jeden Fall weitergeholfen. Bei den Bausteinen die Du genannt hast, handelt es sich aber um die nicht rfc-fähigen Bausteine des User Managements. RFC-fähige Sperrbausteine gibt es in diesem Bereich anscheinend nicht (ich habe nämlich leider keine gefunden). Notwendig wäre meiner Ansicht nach eigentlich ein 'BAPI_USER_ENQUEUE' und ein entsprechendes Gegenstück zum Abräumen der Sperre. Das heißt für meinen Fall müßt ich mir eine RFC-Verschalung um die von Dir genannten Sperrbausteine bauen. Denn die Sperre die der BAPI_USER_CHANGE setzt ist eigenlich zu spät. Wenn ein Benutzer A auf dem UI einen User ändert und gleichzeitig versucht es auch ein Benutzer B, dann 'gewinnt' derjenige, der zuletzt speichert. Die Sperre muß jedoch schon zu dem Zeitpunkt abgesetzt werden, wenn der Benutzer A als erster in den Bearbeitungsmodus auf dem UI geht, so dass Benutzer B erst dann in den Bearbeitungsmodus wechseln kann, wenn A mit seiner Bearbeitung komplett fertig ist und gespeichert hat.

Ach ja, wg. dem Vorteil (bzw. den Vorteilen) eines eigenen UserManagements: Wenn Du hergehen möchtest und SelfServices für Geschäftspartner anbieten willst, dann sollen diese Geschäftspartner auch die Möglichkeit haben, sich selbst einen User über ein Web-basiertes UI (was man auch in eine Portalumgebung integrieren kann) anzulegen. Man trifft dort dann eben eine Einschränkung was die Rollen anbelangt oder man arbeitet mit Referenzbenutzern, die eine entsprechende Auswahl schon vorhalten. Aus dem Grunde die BAPI-Schnittstellen. Was nun aber die Sperre anbelangt muß man sich wohl selbst darum kümmern.

Gruss,
Jens