Userswitch
Inbound-/Outbound-Scheduler 
Verwendung
Werden qRFCs oder tRFCs über den Inbound/Outbound-Scheduler abgearbeitet, kann es vorkommen, dass der qRFC/tRFC unter einem anderen User abgearbeitet wird als unter dem aufrufenden User. Dies kann auftreten, falls der Scheduler (SMQS/SMQR) die Ausführung der LUW übernimmt.
Voraussetzungen & Vorgehensweise
Outbound-Scheduler SMQS:
Wenn die Übertragung bzw. die Ausführung dieser LUWs vom Outbound-Scheduler bewerkstelligt wird und innerhalb der Destination SM59 keine oder keine vollständigen Logon-Daten gepflegt sind, kann es passieren, dass nachfolgende LUW Aufrufe unter den Logondaten eines vorangegangenen Users ausgeführt werden. Dies tritt auf, wenn der Destinations-Scheduler zum Aufrufzeitpunkt einer LUW (n+1) bereits unter einem anderen User läuft und in der SM59 keine Logondaten gepflegt sind. In diesem Fall läuft der Destinations-Scheduler unter dem User und der Sprache des Users der den Scheduler angestartet hat. Somit läuft der Destinations-Scheduler und somit die Verarbeitung der nach folgenden LUW unter den falschen Logon-Daten.
Daher durften bisher am Outbound-Scheduler nur dann Destinationen registiert sein, wenn vorher die vollständigen Logondaten (Mandant, User , Passwort, Sprache) in SM59 gepflegt waren, sofern die LUW immer unter einem definierten User/Sprache abgearbeitet werden musste. Nur für den Fall, das der ausführende User und auch die Sprache keine Rolle spielt, konnten auch Destinationen ohne die vollständigen Logondaten (Mandant, User, Passwort und Sprache) registiert werden. Darüberhinaus gibt es interne Destinationen (NONE/<SPACE>) bei denen es keine Möglichkeit gibt den User oder die Sprache in SM59 einzutragen. Aus diesem Grunde durften aus Kompatibilitätsgründen zum tRFC diese Destinationen nur mit dem optionalen Flag 'ohne TRFC' im Outbound- Scheduler registiert werden.
Inbound-Scheduler SMQR:
Um beim Inbound-Scheduler sicher zu sein, dass eine angestartete LUW unter einem fest definierten User abläuft, kann in SM59 eine Logische Destination angelegt werden, auf die im Inbound-Scheduler (SMQS) referenziert wird. In dieser Logischen destination müssen die vollständigen Logondaten hinterlegt sein. Diese Logische Destination muß beim Registieren in SMQS angegen werden. Damit werden alle LUWs dieser Queue unter diesem User und Sprache abgearbeitet. Im Falle, dass keine logische Destination für eine Queue definiert ist, kann es passieren, dass eine nachfolgende LUW innerhalb der Queue unter einem anderem User/Sprache ausgeführt wird als dem aufrufenden. Dies kann auftreten, wenn unterschiedliche User in die selbe Queue verwenden.
Ergebnis
Der Outbound-/Inbound-Scheduler ist nun in der Lage jede LUW unter dem User/Sprache des Aufrufers abzuarbeiten!
Somit kann nun jede Destination bzw. Queue registiert werden! Auch solche die keine Logondaten in SM59 geplegt haben bzw. auch die Sonderdestinationen bei denen es keine Möglichkeit gibt einen User oder Sprache anzugeben.
Die Verhaltensweise ist wie folgt:
· Sind in SM59 Logondaten gepflegt werden diese verwendet.
· Sind keine Logondaten gepflegt werden die Userdaten (Sprache, Mandant User) des Aufrufers verwendet.
· Sind nur teilweise Logon-Daten in SM59 gepflegt werden diese als Logondaten für die Verarbeitung verwendet. Für alle Logon-Daten die nicht in SM59 vorhanden sind werden die aktuellen Logon-Daten des Aufrufers verwendet (Sprache, Mandant, User).
Weiter geht’s mit: