Using the Task Web Service Operations
To use the task Web service operations described below, your client program must log on to My webMethods Server with a user ID that has appropriate functional and task access privileges on the Task Engine. Operations that your client program performs are executed under this user ID. If the user ID does not have the required function and task access privileges, the operation fails and an exception is generated.
You can specify an alternative user ID for the operation by setting the optional user input parameter, which is available on all operations in the task Web service. This parameter enables a client program to perform an operation under a user ID that is different from the one it used to log on to My webMethods Server.
Important:
To use the user parameter, your client program must log on to the My webMethods Server with a user ID that belongs to the "Admin Role" role. If your program does not belong to the "Admin Role" role and it requests an operation using the user parameter, the operation fails and an exception is generated.
When a client requests an operation with the user parameter, the Task Engine executes the operation as though it were requested by the specified user. For example, if your client program logs on as "mrussel," but executes the searchTask operation under the user ID "rkosi," the Task Engine searches only tasks the user "rkosi" can access.
My webMethods Server updates a user's role membership only when the user interactively logs in into My webMethods Server. When impersonating a user with the Task Engine APIs, there is no interactive login of this user to My webMethods Server. Therefore, the Task Engine itself handles role membership changes and updates for these impersonated users.
The Task Engine updates a user's role membership when:
A specified time has passed since last time the user ID was impersonated. The default value is 30 minutes.
A specified time has passed since the last time the user's role membership was updated. The default value is 24 hours (session total time-to-live).
These default time periods can be modified with the following environment settings:
-Dtask.remote.session.timeout=<the time period in seconds between updates
of user role information. The session is not invalidated or expired.>
-Dtask.remote.session.ttl=<user session time-to-live in seconds>
Important:
It is important to understand that the -Dtask.remote.session.timeout setting does not affect the duration of the actual session. The only purpose of the setting is to specify the time interval between updates to the impersonated user’s role membership.
For more information about setting these options, and assigning task functional privileges and task access privileges, see the PDF publication
webMethods Task Engine User’s Guide.
For more information about working with roles and users, see the PDF publication
webMethods Integration Server Administrator’s Guide.