User Switch in the Inbound and Outbound Schedulers 

Use

If qRFCs or tRFCs are processed using the Inbound Scheduler or Outbound Scheduler, they may be 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 in transaction SM59 in the destination is incomplete, then any subsequent LUW calls might be executed under the logon data of a previous user. 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 (and this user's language). This means the destination scheduler runs under the wrong logon data, as does the processing of the subsequent LUWs.

Until now, destinations could only be registered in the Outbound Scheduler if the logon data (client, user, password, language) had been defined completely in transaction SM59 (if 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. In addition, some internal destinations (NONE/SPACE) do not allow you to enter a user or language in transaction SM59. For this reason, and for tRFC compatibility, you can only register these destinations in the Outbound Scheduler with the optional Without tRFC flag.

 

Inbound Scheduler (Transaction SMQR)

To make sure that a running LUW is processed under a fixed 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 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, including destinations without logon data in transaction SM59 and special destinations without a user or language.

The logon data is handled as follows:

·        If logon data is entered in transaction SM59, then this data is used.

·        If no logon data is entered, then 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, then 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.

 

 

Continue by reading the following:

LUW in Update Records in SM58/SMQ1