Users are notified via e-mail about specific situations that manifest within a workflow. A notification message is generated and sent to the designated recipients to inform them that a certain event has occurred, such as a new approval task has been submitted to the approvers or the operation has been completed. A notification configuration involves such elements as the event to notify of, the list of the notification recipients and the notification message template.
The logic of an automated management process can be implemented by using administrative policies in Active Roles. Yet creating and maintaining complex, multi-step processes in that way can be challenging. Workflows provide a different approach, enabling IT administrators to define a management process graphically. This can be faster than building the process by applying individual policies, and it also makes the process easier to understand, explain and change.
The diagram below shows a workflow process created in the Active Roles console. In this simple example, upon a request to add a user to a certain group, the workflow first checks to see if the group has an owner. If the group has no owner, the requested changes are denied and the workflow is complete; otherwise, the changes are submitted to the group owner for approval. When approval is received, Active Roles applies the changes, adding the user to the group. On the process diagram, this step is referred to as Operation execution. If the owner rejects the changes, the workflow finishes on the previous (approval) step so that the changes are not applied. After the changes are made, the workflow sends an e-mail notification to the person who requested the changes, and then finishes.
Figure 87: Workflow process in Active Roles
In the above example, the workflow manages the process of adding a user to a group according to the rules defined at design time. The rules constitute the workflow definition, and include the activities that occur within the process and the relationships between activities. An activity in a process definition can be a pre-defined function available out of the box, such as a request for approval or a notification of conditions that require user interaction, or it can be a custom function created using script technologies.
A workflow process is started when the requested changes meet the conditions specified in the workflow definition. In the above example, the conditions might be set up so that the workflow starts whenever an Active Roles user has made changes to the membership list of a certain group. Once the conditions are fulfilled, the workflow process starts to drive the changes through the workflow definition, performing automated steps and, if necessary, requesting human interaction such as approval.
In Active Roles, directory objects such as users, groups or computers are managed by the Administration Service. These objects can be created, changed or deleted through requests made to the Administration Service. Every request initiates an operation to make the requested changes to directory data. For example, a request to create a user or group initiates the Create operation with the target object type set to User or Group, respectively; a request to add users to a group initiates the Modify operation on that group.
Once an operation has been initiated, the Administration Service starts processing the operation. Each operation is represented by a single object, usually referred to as the Request object, which contains all information necessary to perform the operation. Therefore, operation processing takes the form of passing the Request object through a number of phases within the Administration Service.
The operation processing model in Active Roles is composed of four main phases: access check, pre-execution, execution, and post-execution. The Request object passes through these phases in the following order:
Then, after the pre-execution activities are completed so that the operation is not rejected, the Administration Service runs the pre-execution policies. Typical examples of such policies include property generation and validation rules and the functions implementing so-called “pre-event handlers” in script policies.
Finally, after the post-execution polices are finished running, the Administration Service runs the post-execution workflow activities. These are the activities located in the lower part of the workflow process diagram, beneath the Operation execution line. A typical example would be Notification activities that send out e-mails informing of the operation completion.
The Administration Service runs the workflow activities one by one, in sequential order shown on the workflow process diagram, until the last activity finishes. If-Else activities can be used to achieve conditional branching in workflows, which makes it possible to switch the sequence of activities depending on the data involved in the request.
At the beginning of the pre-execution phase, the Administration Service determines the workflows to start. The request is compared to all the existing workflow definitions. In order for a workflow to start, the requested operation needs to satisfy the start conditions defined for that workflow. If the start conditions are satisfied, the workflow is matched to the request.
For a workflow that is matched to the request, the Administration Service runs the activities found in that workflow during the corresponding phases of the operation processing. One workflow or multiple workflows can be matched to a single request. In case of multiple workflows, the Administration Service starts each of them one-by-one, and first runs all the pre-execution activities included in those workflows. Then, during the post-execution phase, the Administration Service runs all the post-execution activities included in those workflows.
If multiple workflows are matched to a single request, then Active Roles uses the
edsaWorkflowPriority attribute of the workflow definition object to determine the order in which to execute the workflows. The activities of the workflow with a lower value of that attribute are executed prior to the activities of the workflow with a higher value of that attribute. The workflows with the same priority value are executed in ascending order of workflow names. The
edsaWorkflowPriority attribute is set to 500 by default. If the
edsaWorkflowPriority attribute is not set, Active Roles assumes that the workflow has the priority value of 500. You can change the value of the
edsaWorkflowPriority attribute to ensure that a given workflow takes precedence over other workflows. A lower value of that attribute indicates a higher priority whereas a higher value indicates a lower priority. To view or change the
edsaWorkflowPriority attribute, use the Advanced Properties command on the workflow definition object in the Active Roles console.
To deploy a workflow in Active Roles, you create a workflow definition, configure the start conditions for that workflow, and add and configure workflow activities. When configuring workflow start conditions, you specify:
Upon a request for any operation that meets all the start conditions specified on a workflow, the Administration Service matches the workflow to the request and runs the activities found in the workflow.