Generic Job Parameters

Besides the input parameters defined by each job itself, the server kernel evaluates a number of parameters that can be passed with any job call — independently of the executing engine. This page documents these parameters centrally; the procedure pages of the individual jobs do not list them but refer here instead.

These parameters are recognizable by their triple-dollar notation ($$$Name$$$).

1. Switching the User Context for Job Calls

A server job can be executed in a different user context. For this purpose one of the following parameters is added to the job call:

Name Description

$$$SwitchContextUserGUID$$$

GUID of the user on whose behalf the job is to be executed.

$$$SwitchContextUserID$$$

ID of the user on whose behalf the job is to be executed.

$$$SwitchContextUserName$$$

Name of the user on whose behalf the job is to be executed.

The three parameters are alternatives — the user is addressed either by GUID, ID or name.

For jobs that evaluate the rights system, the permission check is performed for the specified user. Further jobs that are executed server-side as a consequence of the call — for instance an internal call of std.IndexDataChanged to create a history entry on DMS objects — then also run on behalf of the specified user.

The executing (logged-in) user requires the system role 72 (Server: Switch job context, internally R_SRV_SWITCH_CONTEXT). If it is missing, the call is rejected with the error code -1042218022 ("The system role R_SRV_SWITCH_CONTEXT is not present.").

The system roles assigned to the calling user can be determined with mng.GetUserRoles; an overview of all roles is available under System Roles.

If the addressed user is unknown, the call is rejected with the error code -1043332467; the server message contains the user GUID.

The same role is also required by krn.CheckUserAccount — there without a context switch, solely to call the job.

A typical use case is an integration that is logged in under a technical service user but has to perform operations on behalf of the business user acting — so that user’s permissions apply and the history entry names them as the originator.

For the XML jobs of the DMS engine there is additionally the job-specific input parameter JobUserGUID (see The JobUserGUID Parameter), which is only permitted for server-side calls from other jobs.