User Context "on the fly" ändern

[Francesca5048]

Hallo Zusammen

'Bin zum ersten Mal in diesem Forum. Die Qualität hat mich echt überrascht! Toll, dass es doch noch ein paar SAPler gibt, die nicht nur Informationen "absaugen" wollen, sondern auch was beisteuern.

Zu meinem Problem:
Ich muss in einer Applikation den User-Kontext ändern. Ein RFC-FuBa muss mit einem beliebigen bestehenden R/3-Dialog User Account ausgeführt werden. Username und Passwort sind bekannt.

Den einzigen Weg, den ich bis dato gefunden habe, ist eine RFC-Destionation gekünstelt anzulegen, so SM59-mässig mit hartem reinschreiben in die RFCDES etc. Diese Lösung ist allerdings sehr holperig und der SysAdmin sieht natürlich alle automatisch angelegten RFC-Destination.

Kennt jemand einen anderen Weg? Ev. müsste es auch über die Job-Steuerung gehen, dort werden ja Jobs mit anderem User-Kontext ausgeführt.
Oder weiss jemand, wie man mit C-Calls dynamisch lokale RFC-Verbindungen aufbauen kann (so à la RFCconnect)?

Würde mich auf ein Echo sehr freuen?

[Philippa2744]

Hi,

also um einen RFC-Fuba mit einem bestimmten User aufzurufen, würde ich auf jeden Fall die Doku zum RFCSDK empfehlen. Dort gibt es auch Beispielprogramme, wie man das macht. Link hier:


http://help.sap.com/saphelp_45b/helpdat ... ameset.htm

Selbst etwas zu machen mit Job-Steuerung oder RFC-Destination würde ich nicht empfehlen. Genau dafür ist die RFCSDK da, die im übrigen auch von anderen Schnittstellen genutzt wird (DCOM-Connector oder JayCo). Dort passiert ja im Grunde genau dasselbe. Man macht beispielsweise aus einer Java-Anwendung einen RFC-Call ins R/3 entweder mit einem dedizierten User oder man kann alternativ Connection Pooling betreiben.
Wie gesagt RFC-SDK müßte Dir weiterhelfen.

LoLo

[Francesca5048]

Hallo LoLo

Besten Dank für den Feedback. Leider kann ich mit dem RFCSDK nur Fremdanbindungen lösen. Innerhalb von ABAP (alles läuft auf einer Kiste) nutzt mir der Kit allerdings nix. Oder habe ich da was übersehen?

Ich habe einen Service-Job im R/3, der unter einem BATCH-User läuft.
Dieser Job startet dann den FuBa an. Der FuBa sollte dann diverse Batch-Input Reports anstossen, und diese sollten mit anderen Usern gefahren werden, damit in den Änderungsprotokollen der richtige User drinsteht.

Eine Idee?

[Philippa2744]

Hi Urs,

ok, mir ist nun klar, was der Hintergrund des ganzen ist, aber ich bin mir nicht so sicher, ob das die Lösung ist. Eigentlich müßte es doch ausreichen, beim Einplanen eines neuen Batchjobs den User in der entsprechenden FB-Schnittstelle zu setzen (z.B. FB: BP_JOB_CREATE, dort kann in der Struktur 'OB_CR_HEAD_INP' ein User mitgegeben werden. Ich weiss allerdings nicht, ob sich das dann auch auf die Änderungsbelege entsprechend auswirkt).

Schau Dir am besten mal die Funktionsgruppen BTC2, BTCH und BTCHCNTXT an. (letztere für den Batchkontext). Wahrscheinlich läßt sich mit diesen Apis Dein Problem lösen.

LoLo

[Francesca5048]

Hi LoLo

Danke für die Idee. Leider klappt es so auch nicht. Die einzelen
BTCi-Reports machen eine synchronen CALL Transaction, da nach
erfolreicher Ausführung das Message Log und ein paar PIDs ausgelesen
werden können. Anhand dieser Infos wird dann der weitere Ablauf gesteuert.

Ich kann also keine Folge-Hintergrundjobs definieren und starten (was übrigens mit anderem User-Kontext funktioniert), weil mir dann einfach Informationen flöten gehen (die auch nicht im JobLog zu finden sind).

Ausserdem wird das ganze zu zeitkritisch, weil ich dann auf den Jobscheduler angewiesen bin, der eine saumässig grosse Latenz-Zeit aufweist.

Trotzdem vielen Dank für Deine Idee. Ich vermute so aus dem hohlen Bauch heraus, dass die Lösung irgendwo im RFC-Umfeld liegt.

Urs