Programming Guides › Programming Guide for Java › CA IdentityMinder APIs › Task Execution Summary

Task Execution Summary

The following process summarizes the sequence of operations that can occur when an administrator executes a Modify User task, including adding the end user to a group. In this example, workflow and email notifications are enabled.

1. The administrator selects Modify User from the list of tasks that they are authorized to perform.
2. CA IdentityMinder creates a task session.

   API: CA IdentityMinder calls BLTHAdapter.handleStart() in applicable business logic task handlers (those handlers that are defined in the environment or are associated with the task).

3. The administrator selects a particular User object to modify.

   API: CA IdentityMinder calls BLTHAdapter.handleSetSubject() in applicable business logic task handlers.

4. CA IdentityMinder retrieves the User object.

   API: If any physical attributes in the User object must be converted to logical attributes, logical attribute handlers perform the conversions.

5. CA IdentityMinder displays the user data on a task screen.
6. The administrator modifies some of the user data on the task screen, and also adds the user to a group. The administrator then clicks Submit.

   API: CA IdentityMinder executes validation rules for all applicable fields, and then calls logical attribute handlers to validate logical attribute fields. If a validation fails, an exception is thrown, an error is displayed, and the administrator must resubmit the task.

   API: Logical attribute handlers convert logical attribute values back to physical attribute values.

   API: CA IdentityMinder calls BLTHAdapter.handleValidation() in business logic task handlers to perform task-level validation and any other business logic that may be required. If any handler processing fails, an exception is thrown, an error is displayed, and the administrator must resubmit the task.

7. CA IdentityMinder instantiates the events ModifyUserEvent and AddToGroupEvent. In this example, both of these events are mapped to workflow processes.

   API: CA IdentityMinder calls BLTHAdapter.handleSubmission() in applicable business logic task handlers.

   After this method is called in all business logic task handlers defined in the environment or associated with the task, the task enters the asynchronous phase for processing.

8. CA IdentityMinder posts the events instantiated in the synchronous phase. Events can no longer be recalled.
9. CA IdentityMinder begins processing the event ModifyUserEvent.

   API: CA IdentityMinder calls the before() method in each event listener for the event ModifyUserEvent. This method is called even if the event is not mapped to a workflow process.

10. The workflow process begins for the event ModifyUserEvent.

    API: The Participant Resolver API determines the participants (approvers) for the workflow activity.

    API: The Workflow API can be called to pass information about the event or information from a third-party application back to the workflow process. A workflow process activity evaluates the information to determine the next activity to perform.

11. CA IdentityMinder sends email notification about the pending event.

    API: An email notification can include event-specific information through JavaScript calls to the Email Template API. Also, email recipients can include users who are specified through a call to a custom notification rule.

12. The workflow process for the event ends.

    API: Depending on whether the event is approved or rejected, CA IdentityMinder calls the approved() or rejected() method in each event listener for the event ModifyUserEvent.

13. CA IdentityMinder sends email notification about the event result.

    API: An email notification can include event-specific information through JavaScript calls to the Email Template API. Also, email recipients can include users who are specified through a call to a custom notification rule.

14. If the event is approved, CA IdentityMinder executes the event.

    API: After executing the event, CA IdentityMinder calls the after() method in each event listener for the event ModifyUserEvent.

    If an event listener is performing rule-based role or group assignments, it is typically at this point that the assignments are made.

15. If the event is approved, Step 9 through Step 14 for the event AddToGroupEvent are performed.

    In this example, ModifyUserEvent is a primary event. If a primary event is rejected, no other events are processed (in this example, AddToGroupEvent), and the Modify User Task is not performed.

16. After the workflow process for each event is completed, and if the event ModifyUserEvent was approved, CA IdentityMinder completes the Modify User task.
17. CA IdentityMinder sends email notification about the task result.

    API: An email notification can include event-specific information through JavaScript calls to the Email Template API. Also, email recipients can include users who are specified through a call to a custom notification rule.