User Switch in the Inbound and Outbound Schedulers 

Use

When qRFCs or tRFCs are processed using the Inbound Scheduler or Outbound Scheduler, they are sometimes processed under a user other than the calling user. This can occur if the scheduler (transaction SMQS or SMQR) is responsible for executing the LUW.

 

Prerequisites and Procedure

Outbound Scheduler (Transaction SMQS)

If the Outbound Scheduler is responsible for sending and executing these LUWs, and the logon data defined in the destination in transaction SM59 is incomplete, subsequent LUW calls might be executed with a previous user’s logon data. This occurs if the destination scheduler is already running under another user when the LUW is called and no logon data is maintained in transaction SM59. In this case, the destination scheduler runs under the user that started the scheduler. It also runs under this user's language. The destination scheduler therefore runs under the wrong logon data, as does the processing of the subsequent LUWs.

Previously, destinations could only be registered in the Outbound Scheduler if the logon data (client, user, password, language) had been defined completely in transaction SM59 (provided that the LUWs always needed to be processed under a specific user and language). Destinations with incomplete logon data could be registered only if the user and language was not important. Some internal destinations (NONE/SPACE) do not allow you to enter a user or language in transaction SM59. For this reason, and to ensure tRFC compatibility, you can only register these destinations in the Outbound Scheduler with the optional Without tRFC flag.

 

Inbound Scheduler (Transaction SMQR)

To ensure that a LUW is processed under a certain user, you can create a logical destination in transaction SM59 that is referenced in the Inbound Scheduler (transaction SMQS). The complete logon data must be entered in this logical destination. This logical destination must be specified when the queue is registered in transaction SMQS. All LUWs in the queue are then processed with this user and language. If no logical destination is defined for a queue, a subsequent LUW in the queue might be executed under a user and language other than that of the calling user. This can occur when different users use the same queue.

 

Result

The Outbound Scheduler and Inbound Scheduler can now process every LUW with the user and language of the calling user.

This also means that every destination and queue can be registered. This includes destinations without logon data in transaction SM59 and special destinations without a user or language.

The logon data is handled as follows:

●      Any logon data entered in transaction SM59 is used.

●      If no logon data is entered, the user data (including the language and client) of the calling user is used.

●      If only some of the logon data is entered in transaction SM59, this data is used as the logon data for processing the LUWs. The missing logon data is replaced by the logon data of the calling user.

 

 

Next Step:

LUW in Update Records in SM58/SMQ1