Skip to main content

Validating automated requests for feasibility

The Workflow Manager has a limited number of threads for processing requests, and will process each request in sequential order. This means that triggering a large number of automated requests simultaneously will prevent other requests from being processed until these requests have been processed.

When designing or troubleshooting workflow automation, keep in mind that:

  • Auto-discovery or idtrack may collect invalid or incomplete data from target systems.

  • Event actions (exit traps) fire at different times during workflow processing, and for all requests.

    Scripts are called repeatedly, at different times, in different possible pre-defined requests and contexts

A request should not be triggered before all requirements for it (including a recipient) are available in the current calling context. That means that all request data may not be available to custom scripts,whether stand-alone or deployed via components.

Before triggering any new request, verify that the current calling context contains a valid recipient value, as well as the data, such as attributes, target/hostid, operations, relevant to the request.

Other possible dependencies must be checked by the script if:

  • The operations to be run as part of the request have such dependencies,

    AND

  • The Transaction monitor is not configured to repeat failed operations,

    OR

  • The dependency is not likely to be added by another operation triggered before the configured retries end.

Positive failures must also be addressed. Operations may fail because the requested entitlement already exists in the target, account or profile where it's being added. These have a low probability of being for the wrong object, but all such possibilities for each entitlement have to be considered at solution design time. For example, if an account is being added to a group where it's already a member, does that operation have to

  • Fail, because the account may belong to another user with the same identifier,

    OR

  • Succeed, because in the current solution there's no chance that target would have two different accounts with the same identifier?

In this section: