SAP-Workprozess-Information auf DB- oder OS-Ebene verfügbar?

[Willy1492]

Dann stelle ich mal die erste Frage, damit das neue Forum nicht umsonst eingerichtet wurde:

Folgendes Beispiel-Szenario:

Auf DB-Ebene wird für eine bestimmte Tabelle ein Update-Trigger definiert.
Ziel soll sein, auf DB-Ebene zu protokollieren, welcher R/3-Benutzer die DB-Änderungen vornimmt.
Dazu müsste man auf DB-Ebene (evtl. unter Nutzung von Betriebssystem-Funktionen) herausfinden, welcher SAP-Workprozess auf welchem Applikationsserver den Update initiiert hat.
(Änderungsbelege/DBTABLOG/... mal außen vor gelassen. Es soll eher um Fälle gehen, in denen jemand z.B. ein selbst-geschriebenes Programm startet, das sich nicht an die Regeln hält.)

Kennt jemand eine Möglichkeit, wie man auf DB-Ebene oder OS-Ebene an diese Informationen gelangt?
(Evtl. auch eingeschränkt auf bestimmte SAP-Releases, SAP-Kernel-Patch-Level, Betriebssysteme, bestimmte DBMS oder Fälle, in denen es nicht noch verschiedene Applikationsserver gibt.)

SQL-Audit-Log taugt nicht für die Protokollierung, da nur Zugriffe per Open SQL protokolliert werden können, nicht jedoch Native SQL-Anweisungen zwischen EXEC SQL ... ENDEXEC.

Und als DB-User ein ABAP-Programm zu starten, das alle Workprozesse aller Applikationsserver ausliest und prüft, welche Prozesse gerade mit einem UPDATE auf die jeweilige Tabelle beschäftigt sind, scheint mir etwas zu viel Aufwand zu werden - ganz abgesehen davon, ob man das überhaupt hinbekommt.

Die dazu nötigen R/3-Funktionsbausteine oder Kernel-Funktionen kenne ich zwar.
Problematisch sind aber vermutlich Deadlock-Situationen, wenn z.B. das gerufene Programm erst neu generiert werden muss (inclusive DB-Commit der Generierung), weil die Programm-Load nicht aktuell ist...

Frank

[Alva1590]

Ich sehe keine Möglichkeit, aus einem DB-Trigger heraus festzstellen, welcher R/3 User den aktuellen Aufruf ausgelöst hat. Selbst wenn man im Trigger herausbekommen könnte, von welchem AppServer und WP der Aufruf kommt - bei Oracle z.B. könnte ich mir einen Weg vorstellen (eigene Session bestimmen und dann über v$session die Client-Info holen) -, so wüßte ich nicht, wie man vom DB-Server aus den WP auf dem AppServer fragen könnte, welcher R/3 User gerade aktiv ist.

[Willy1492]

Danke für Deine Antwort.

Ich sehe keine Möglichkeit, aus einem DB-Trigger heraus festzstellen, welcher R/3 User den aktuellen Aufruf ausgelöst hat. Selbst wenn man im Trigger herausbekommen könnte, von welchem AppServer und WP der Aufruf kommt - bei Oracle z.B. könnte ich mir einen Weg vorstellen (eigene Session bestimmen und dann über v$session die Client-Info holen)

Klingt ja schon mal vielversprechend. Bekommt man da tatsächlich die PID des Applikationsservers heraus (und was ist mit hostname oder IP-Adresse des Applikationsservers?), oder ist es die Process ID des DB-Servers, die ja wenig nützen würde.

Vielleicht sollte ich ja mal Google befragen.

so wüßte ich nicht, wie man vom DB-Server aus den WP auf dem AppServer fragen könnte, welcher R/3 User gerade aktiv ist.

Na ja, notfalls so:
1. Man erzeugt einen RFC-fähigen Funktionsbaustein (in einer eigens dazu angelegten Funktionsgruppe, der entweder die in SM50/SM51/... genutzten FBs TH_* oder direkt die darin verwendeten SAP-Kernel-Funktionen aufruft.
2. Man legt einen CPIC-User an, der nur Funktionen dieser einen FUGR aufrufen darf.
3. Man ruft von Oracle aus diesen RFC-fähigen FB auf.

Ist zwar einiger Aufwand, und man müsste noch mal prüfen, ob man was übersehen hat (insbesondere Security-Probleme). Aber funktionieren könnte/müsste es.
(In der SM50 sieht man ja, wenn ein Prozess gerade mit dem Update auf eine Tabelle beschäftigt ist, und welchem User aus welchem Mandanten der Prozess gerade "gehört".)

[Alva1590]

Na ja, notfalls so:
1. Man erzeugt einen RFC-fähigen Funktionsbaustein (in einer eigens dazu angelegten Funktionsgruppe, der entweder die in SM50/SM51/... genutzten FBs TH_* oder direkt die darin verwendeten SAP-Kernel-Funktionen aufruft.
2. Man legt einen CPIC-User an, der nur Funktionen dieser einen FUGR aufrufen darf.
3. Man ruft von Oracle aus diesen RFC-fähigen FB auf.

Ein RFC-Aufruf aus dem Trigger heraus ist sehr clever und wenn's funktioniert eine fantastische Idee. Respekt! Kannst mich ja auf dem laufenden halten, was Deine Implementierung anbelangt.

Über den v$session Views bekommt man sowohl den hostname als auch die PID des Client-Prozesses (also des WPs) heraus. Hier ist das SQL Statement:

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

1.  
2. select machine, process from v$session where audsid = (select userenv('SESSIONID') from dual);
3.  

GeSHi ©