Programming Guides › Programming Guide for Java › CA IdentityMinder APIs › Task Phases › Asynchronous Phase Operations

Asynchronous Phase Operations

In the asynchronous phase, the events that were instantiated for the task during the synchronous phase are posted and cannot be recalled. CA IdentityMinder completes the task after all associated events are completed. All operations are optional except the execution of the event.

The following operations are performed for each event, in the following order:

1. CA IdentityMinder posts the events.

   At the beginning of the asynchronous phase of task execution, CA IdentityMinder posts the events that were instantiated for the task during the synchronous phase. At this point, the events are committed for the task and cannot be recalled.

   If workflow is enabled, and one or more of the task’s events are mapped to a workflow process, the task comes under workflow control. The task remains in a pending state until the mapped workflow processes are completed.

2. Event Listeners Perform Pre-Approval Attribute Updates

   The Pre-approval state occurs before a workflow process begins, or before the automatic approval of an event that is not associated with a workflow process. During the Pre-approval state, a custom event listener can update attributes in CA IdentityMinder managed objects associated with the event.

   API: Event Listener API.

3. Custom Objects Perform Operations During Workflow Processing

   If workflow is enabled for the CA IdentityMinder environment, and an event is mapped to a workflow process, the activities in the workflow process must be completed before the event (and ultimately, the associated task) can be completed.

   Note: Custom objects cannot update attributes in CA IdentityMinder objects during workflow processing.

   During workflow operations, the following custom processing can occur:

   • Specify the participants (approvers) for a workflow activity.

     API: Participant Resolver API.

   • Retrieve information about the event and use the information to determine the path of the workflow process.

     For example, during a Create User task, a custom object could retrieve the user’s title. If the title is Manager, a two-step approval is required (from HR and from a corporate officer). If the user’s title is other than Manager, a one-step approval is required, just from HR.

     API: Workflow API.

   • Retrieve information from a third-party application and use the information to determine the path of the workflow process.

     This type of custom processing, called asynchronous validation, lets you add automated activities to a workflow process. The automated activity calls the third-party application and requests the information. The third-party application then returns the information to the activity, where the information is evaluated to determine the course of subsequent workflow processing.

     Note: A workflow process can have an unlimited number of manual and automated activities. For information about workflow activities, see the Administration Guide.

4. Event Listeners Perform Pre-Execution Attribute Updates

   A workflow process results in either the approval or rejection of the associated event, depending upon the outcome of the individual activities in the workflow process. When a workflow process is approved, CA IdentityMinder executes the associated event.

   After a workflow process is approved or rejected, but before CA IdentityMinder executes an approved event, a custom object can modify the attributes of the managed objects in the event. However, if the workflow process is rejected, the event is never executed, and any modifications to the managed object in the event are not written to the data store.

   Pre-execution attribute updates can also be made for events that are not under workflow control. An event that is not under workflow control is automatically approved.

   API: Event Listener API.

5. CA IdentityMinder Executes the Event

   Event execution is complete when all operations associated with the event have been completed.

   If managed object data associated with an event needs to be written to the data store, it is written after execution of the event is complete.

   No CA IdentityMinder APIs are applicable to this operation.

6. Event Listeners Perform Post-Execution Operations

   After the execution of an event is complete, an event listener can perform operations such as the following:

   • Performing rule-based role or group provisioning. For example, suppose users who are assigned to the group QA should automatically be assigned to the group Engineering. An event listener that is "listening for" the event AddToGroupEvent in the Post-event state can do the following:
     • Check whether the group that the user has been added to is QA.
     • If the user was added to QA, add the user to Engineering.
     • Generate another AddToGroupEvent for the addition of the user to Engineering. This allows the additional AddToGroupEvent to be subject to its own workflow and auditing operations.
   • Notifying third-party applications that the event has executed. Notification that an event has executed may be performed for auditing purposes or to allow the third-party application to perform any post-execution processing that it may require.

   API: Event Listener API.

7. CA IdentityMinder Generates Email Notifications

   Email notifications report the status of tasks and events.

   Email notifications are generated from templates. A template can generate event-specific messages through JavaScript calls to the Email Template API. Further, you can write a custom object that determines the list of recipients for email notifications.

   An email’s recipients are determined by the template used to generate the email. For example:

   • Emails based on the Pending template are sent to all users who are potential participants in the associated workflow activity.
   • All templates can call the getNotifiers() method to determine the list of recipients. This method passes to CA IdentityMinder the name of a Java object called a notification rule that determines the list. The method can pass the name of a predefined notification rule (ADMIN, USER, or USER_MANAGER) or a custom notification rule.

   APIs: Email Template API, Notification Rule API.