PDF version HERE
The CA
IdentityMinder official document does not have much detail about work flow.We learned some basic concepts from previous chapter
- If requirement requires approver, you need workflows.
- Workflow runs under asynchronous phase.
- Workflows can have a long life. It may take time up to an hour or month.
- The Business Logic Task Handler has been done before workflow start.
This chapter, you will learn both workflow API
and how to create custom workflow.
5.1 Workflow Concepts
You
must enable workflow in Management Console. By default, workflow is disabled.
Configuration: Management Console
1.
In the Management Console, select an
Environment.
2.
Go to Advanced Settings, Workflow.
3.
Select the Enabled check box, and click Save.
4.
Restart the application server.
 Figure 5-1 shows workflow properties in Management Console |
In the event mappings
table, there are some default mappings between event and global workflow
process. It means when any events in this table start, workflow will be executed.
We do not modify any values.
5.1.1 Default Workflow Features
This section, we will learn default
workflow features in CA IdentityMinder. We cover these topics:
§
Workflow Level, workflow can run admin task or
event level.
- Select Workflows, which workflow can execute.
- Policy Base, it is condition to start workflow.
- Task for Approver, and screen for approver.
- Approver, who is approver.
- Expected Outcome, the final result: approve or reject.
Workflow Level
Workflow can run at Admin task
level and/or Event level. What level should be? It is depending on requirements.
For example, we have admin task “Modify User”, our admin task has 2 tabs: Profile Tab and Access Role Tab. So events will
be generated from this admin task divides as 2 groups:
- The first group of events came from profile tab; events will be generated when user’s attributes have been modified.
- The second group of events came from access role tab; events will be generated when we add or remove access role for user.
 |
Figure 5-2 shows all events from
example admin task.
|
We
have 2 requests: request to modify user’s attributes from the profile tab and
another one request to add/remove role from the access role tab.
- Senario1: all requests (both modify user’s attributes and add/remove role) need only one workflow for approval, we should specific workflow as Admin Task Level.
- Senario2: only modify user’s attributes request (profile’s tab) require approver, we should specific workflow at Event Level: ModifyUserEvent.
- Senario3: only add role (access role tab) request requires approver, we should specific workflow at Event Level: AssignAccessRoleEvent.
- Senario4: Any requests (modify user’s attributes and add/remove role) require Manager as first approver.
o
Modify user’s attributes request requires HR
manager as second approver
o
Adding role request requires IT manager second
approver.
We specific the first approver workflow at Admin Task Level
and the HR and IT workflow at Event Level: ModifyUserEvent and
AssignAccessRoleEvent. This case shows in the picture below.
 Figure 5-3 shows workflow of Senario4 |
Admin Task Level
The workflow at admin task requires
to set an attribute TASK_LEVEL=true. You will see it in the example code. Enable
work flow at admin task level, you have to configure:
- On the Profile tab, check Enable Workflow checkbox.
- On the Profile tab, click the pencil icon at workflow process label. The workflow configuration screen display.
 Figure 5-4 shows how to configure workflow at admin task level |
Event Level
Enable work flow
at event level, you have to configure:
- On the Profile tab, verify that Enable Workflow is checked
- On the Events tab, click pencil icon on events. The workflow mapping screen display, and select a process template.
 Figure 5-5 shows how to configure workflow at event level |
Select Workflows
You can select workflow from drop
down. CA IdentityMinder provides three default process templates:
- SingleStepApprovalProcess for one primary approver and default participant when primary approver is not found.
- TwoStageApprovalProcess for two primary approvers and default participant when primary approver is not found.
- EscalationApprovalProcess for one primary approver and default participant when primary approver is not found. This workflow primary approver can escalate to another approver.
You can create more custom workflow, so we will go
details later.
Policy
Base
The policy-based is condition before start workflow. The
picture below show Policy Base: if user’s city is New York, it requires
workflow: TwoStageApprovalProcess.
 Figure 5-6 shows screen of workflow’s policy base |
If request is not met any condition, event or admin
task will execute without workflow.
Task for Approver
If workflow requires approver, we
need screen for approver to perform action approve or reject. The picture below
show screen to select Approval Task:
 |
The picture below shows the example
screen for approver. The icon
means that value has
been changed. You can click for rollback the value.
 Figure 5-8 shows screen for approver |
You can create
new approver task by create new admin task. You have to choose action as
“Approve Event” or “Approve Task”.
Approver
If workflow requires approver, we
have to specific who is approver. We can select type of approver for drop down
Participant Resolver. It provides condition to get approver.
 Figure 5-9 shows drop down: Participant Resolver |
If your
requirement getting approver is complicated, you can do programming by using Participation
Resolver API. We will learn Participation Resolver API in the next chapter.
Expected Outcome
Working
with workflow, we should always aware outcomes: approve or reject. For example,
we have admin task with 2 tabs: Profile tab and Access Role tab. We have one Business
Logic Task Handler and we set 3 workflows: one at admin task level, one for ModifyUserEvent
and one for AssignAccessRoleEvent. The picture below shows all outcomes.
 Figure 5-10 shows all outcomes examples |
If
you use ProviderAccessor API, you have to aware ProviderAccessor updates user
store directly and not depend on workflow. The picture below shows initial
value of City is Toronto. And then we use ProviderAccessor API modify City
attribute to be New York. Whatever workflows will be rejected or approved, the
final value of city is New York.
 Figure 5-11 shows ProviderAccessor API modify attribute’s value |
5.1.2 Workpoint Designer Concept
The workflows
inside of CA IdentityMinder are created by tools WorkPoint Designer. WorkPoint
Designer is 3rd party software and integrated with CA
IdentityMinder. You can run Workpoint Designer by command in <admin_tools>\WorkPoint\bin\Designer.bat
 |
Figure 5-12 shows starter screen of
Workpoint Designer
|
You
have to check configuration file “workpoint-client.properties”. The file is
located in folder <admin_tools>\WorkPoint\conf. The J2EE Client
Configuration must match with your application server.
Processes vs. Jobs
Process and Job is technical term
of Workpoint.
§
Processes are a function that a business
conducts and normally repeats.
§
Jobs are the process instance.
For example, if the Process is a
plan for an order fulfillment process, the specific cases (or Jobs) are the
actual orders. Process looks like a Class in java and job is an object or
instance of java class.
Processes
Run
Workpint Designer, select “Open Process” from menu. Double click on process
named “SingleStateApproval”, you will see the process.
 |
Jobs
Select “Open Job” from menu. Double
click on process named “SingleStateApproval” you will see the jobs of this
process. (If you executed some admin task that contains workflow
SingleStateApproval) You can see the current status of job date created, date
started. Select one of them.
Figure 5-14 shows job
|
The selected
nodes appear as blue color; in picture is node “Approval” and node “IM Reject”.
The selected line paths appear as green line.
Using Help
Click
menu “Help”, help contents will display as pop up. You can select topic
“process definition” and “job definition”.
It shows “What is a Process?” and “What is a Job?”
Figure 5-15 shows help of Workpoint
Designer
|
Another
Workpoint document located in <admin_tools>\Workpoint\docs.
5.2 Custom Workflow
The
official CA IdentityMinder documents do not tell exactly how to create custom
workflow step by steps. The all the rest of this chapter will show how to
create custom workflow.
Why we need custom workflow?
The first reason, the default
template workflows do not fit our requirements. For example, you may want 3
approvers, the default supports up to 2 approvers.
The second reason, we need
integration with other systems or perform some business logic during workflow
process. For example:
- During workflow, we need to call web services.
- If user’s location is North America, it requires second approver. We have to create routing path to check user’s location.
This section contains 2 parts.
- Workflow for CA IdentityMinder, you will learn the rule of workflow that relates to CA IdentityMinder.
- Workpoint Programming, we introduce some Workpoint API features.
5.2.1 Workflow and CA IdentityMinder
When
you create workflow for CA IdentityMinder, you have to follow these rules:
Rule 1: Must start with a node “Start”
and end with a node “Stop”
It
makes sense rule, workflow must have start and end point. In Workpoint
designer, you drag node from menu.
 Figure 5-16 shows Start and Stop node in Workpoint Designer |
Rule
2: Must have Node “Approve” or “Reject”
before go to Node “Stop”
Any
workflow, you need to set state to be “Approve” or “Reject” before complete
workflow. We need to tell the final result to CA IdentityMinder, it is approved
or rejected.
Drag
automate node and set configuration: (You will see details in example code, do not
worry)
§
In the resources tab: select external
§
In the agents tab, for approve state, select
“Notify IM Approver” and for reject state, select “Notify IM Reject”
 Figure 5-17 shows Approve and Reject state before Stop |
Workflow
is not always requires both approve and reject but workflow must have at
least one approve node before node stop. (The work flow has only one reject
node does not make sense)
Rule 3: Approver Configuration
(If you require approver)
If you require approver, you have
to: (You will see details in example code)
- Drag activity node to canvas
- In the resources tab: select “IMApprovers”
- In the agents tab: select “Nobody AutoComplete” for asynchronous
- In the user data tab, set value in below table: (We have details step by step in example: Basic custom workflow.)
Name
|
Type
|
Description
|
ACTION_PERFORMED
|
Text
|
For transition
|
PARTICIPANT_ID
|
Text
|
Approver ID
|
PARTICIPANT_NAME
|
Text
|
Link to properties file
|
PARTICIPANT_DESCRIPTION
|
Text
|
Link to properties file
|
Rule 4: workflow at admin task
level (Optional)
The default value, workflow can run
at event level. If you want workflow run at admin task level, you have to:
- Select process’s User Data and add TASK_LEVEL = true
Awesome Blog
ReplyDeleteThanks for sharing the information on CA Identity Manager
ReplyDeleteGood post thanks for sharing valuable information
ReplyDeletecyber security course