About Web Service Calls and Orchestrations

SBM automatically passes security tokens for automated processes such as SBM Web service calls and orchestration workflows. The credentials of the user that invokes the orchestration workflow are automatically supplied to all of the SBM Application Engine Web service calls that are made throughout the orchestration workflow at runtime. This means that the orchestration workflow is invoked under the control of the user's privileges, and the user's name appears in the change history for the affected item.

Restriction: An external event could have a security token or a user credential that could be used to obtain a security token, or be anonymous. When the external event is anonymous, there is no security token for the orchestration to pass to the SBM Web services, so authentication credentials must be hard coded in the auth element in the orchestration workflow.

The dynamic relationship between the orchestration workflow and the user performing the change not only grants tighter privilege control, but also provides a more detailed audit trail in the affected item's change history. For example, when Bill executes a transition that invokes an orchestration workflow containing the TransitionItem Web service operation, the update is performed by Bill's user account under the control of his item privileges. His user credentials are automatically supplied by his security token to the auth element for this operation; therefore, the administrator does not need to hard code user credentials in the orchestration workflow ahead of time. If Bill does not have privileges to update the associated item, the TransitionItem operation will fail. If Bill does have these privileges, after the transition completes, Bill's user name appears in the change history of the updated item.

An asynchronous orchestration workflow is only executed after the transition that invoked it finishes. For example, suppose a user transitions an item from the New state to the Assigned state. The asynchronous orchestration workflow is executed after the item is in the Assigned state. If the user who initiated the transition no longer owns the item, or does not have the privilege to update items in the Assigned state, the orchestration workflow will fail.

There are two ways to handle or prevent these failures:

In the application workflow, include an intermediate state that waits for the asynchronous orchestration workflow to finish. When it finishes, the item moves to the intermediate state, which can be used to handle failures. For example, this state could have a "return" transition that an administrator can use to move the item back to the original state or to an error state for reprocessing. The original user needs privileges to transition the item to any successful state but should not have privileges to open items that are in the intermediate state or execute the "return" transition.
Make sure the user performing the transition has privileges to update items in the affected states.

CAUTION:

Credentials you hard code in the auth element will override security token credentials, so make sure the user has the appropriate privileges for the action that the Web service operation will take. Conversely, if you remove the credentials from the auth element, make sure the user who runs the orchestration workflow has sufficient item privileges in SBM.