Hi Experts
Is there any definition for these following:
- Ordered task group
- Unordered task group
- Conditional task
- Switch task
- Approval task
- Assignment details
- Guided task
I've learnt that they also represent different icons, where can I find this? Thanks for your help
- SAP Managed Tags:
Accepted Solutions (0)
Answers (1)
This is from the help file:
About provisioning
Provisioning is the act of providing something for use, normally user and account provisioning. In the case of the Identity Center, this normally means creating objects and setting attributes within various repositories. This can, for example, be creating users in an LDAP directory or a database, enabling certain operations by setting attributes within the repositories etc. In the Identity Center, provisioning is based on setting up a number of tasks to perform the given actions.
- Provisioning features
- Provisioning using member event handling
- Provisioning of authorizations using privileges
- Provisioning folders
- Task types
- Private and public tasks
- Task execution
- Root tasks
- Task flow controls
Provisioning features
The provisioning module of the Identity Center offers a provisioning system that has the following characteristics and features:
- Persistent and state driven
For a provisioning system, persistence is important. In real life, servers will fail, networks go down or there will be power glitches. The use of a database to keep a persistent state for all operations will guarantee that no information is lost. - Event driven
By using event tasks on privileges, provisioning is automated based on the assignment of the privilege. - Auditing
It is important to be able to go back, and find out who was allowed to do what, at which time. There are legal requirements in this area, including HIPAA (Health Insurance Portability and Accountability Act) and Sarbanes-Oxley. - Chaining of tasks
In many cases, there is a need for doing a number of tasks in sequence (or parallel). - Delays between tasks
There are cases where you want to set up a delay between two tasks. For example when a user leaves the company, the user account will immediately be disabled, and after 2 weeks, the account will be removed. - Retries
Retries can be defined for all tasks. The retries will take effect when errors occur. - ”Wait for”
This mean that a task can wait for a certain condition (for example an audit flag) to become true, or to wait for all event tasks to finish before continuing. - Rollback
Rollback can be defined across several repositories, so that during a failure, it is possible to undo operations in all involved repositories. - Context variables
Context variables contains context specific information, such as which attributes were updated etc. Can be used to control task execution.
Provisioning using member event handling
The recommended way of starting a provisioning task is to use privileges and member event handling.
For each target system, create a repository definition with connection details for this repository. The repository will also contain references to tasks that are called when a user is granted this privilege (add member), when the privilege is revoked (remove member) and optionally when the user is modified (modify task).
For each resource in a target system, create one privilege. This is normally done by a standard synchronization mechanism. All the privileges should reference the correct repository definition.
Provisioning of authorizations using privileges
The recommended way of provisioning authorizations to repositories (target systems), is to use privileges. Each authorization in each target system corresponds to one (and only one) privilege in Identity Management. Assigning and removing these privileges from users triggers the Add and Remove member tasks, which in turn are responsible for adding and removing the authorization in the target system.
Make sure to follow these recommendations:
- Each privilege corresponds to one (and only one) authorization in the repository. The definition of what an authorization is will vary from system to system, but may for instance be a security group or a role.
- When assigning the privilege to a user, the provisioning process must add the authorization in the target system.
- When removing the privilege from a user, the provisioning process must remove authorization from the target system.
- The Add member task must only add the authorization in the target system. This task should not make any decisions on which action to take, as these should have been made by the Validate add task before the privilege was assigned.
- The Remove member task must only remove the authorization in the target system. Any validation must be done with the Validate remove task.
- The Add member and Remove member tasks should be kept small. An Add member task should, for instance, contain only one action task adding the user to a security group. The Add/Remove member tasks should not contain any conditional or switch tasks.
- If a privilege requires that an account exists in the target system, a master privilege should be used for this.
Provisioning folders
Provisioning folders are only used as a way of organizing the tasks. It is recommended to define a folder structure for an implementation project, and define which types of tasks are stored where. One typical example would be to create a folder for
- Each target system, containing the provisioning/deprovisioning tasks for this system
- User Interface tasks, where you would create a sub-folder for each entry type
- Utility tasks, containing generic tasks which are reused from other tasks
Task types
A provisioning system consists of tasks. There are different types of tasks:
Task groups
A task group contains a set of other tasks. Task groups are used to build a hierarchy of tasks, to create more complex provisioning processes.
Normally, the sub-tasks are executed in a specific sequence, using an ordered task group. The tasks may also or in parallel, using an unordered task group.
Conditional tasks
Different sub-tasks are executed depending on the result of a specific condition. The test can be performed either by executing a stored procedure in the database or by performing an SQL query specified in the task properties.
A condition may, for example, involve checking the presence of an attribute in the identity store, or the value of an attribute within a given table. The condition may also involve checking the existence of an audit flag.
The condition must always evaluate to true or false, and there is one task (or group) connected to each option.
Approval tasks
Approval tasks are used to create a manual approval in a provisioning process. The task has three sub-nodes, "Approve", "Decline" and "Timeout". Depending on the result of the approval, the task(s) under one of these nodes are executed.
Switch task
A switch task controls task execution by evaluating the result of a condition and executing different task(s) depending on the result. The task has a number of case nodes that correspond to the possible values of the returned result.
Action tasks
An action task contains a reference to a job that is run when the task is executed. This is where the actual operations are performed.
Private and public tasks
A task within the Identity Center can be public or private. To be able to execute a task externally, the task must be public. Private tasks are only available from other tasks (task groups or conditional tasks) within the Identity Center. This is used to protect tasks for unauthorized execution.
Task execution
A task always operates on one given entry in the identity store. This is why there is no source defined in the pass of the job in an action task.
In some cases, for example when the task is started by an add or remove member task, a pending value object (MX_PENDING_VALUE) is created, which contains the assignment information. The task is then executed on this entry. By default, any action task will normally operate on the owner entry (i.e. person), and the source will be this entry. To access the pending value, select "Retrieve attributes from pending value" on the "Source" tab of the pass.
Root tasks
A root task is typically started from the Identity Management User Interface or from an external application calling the uProvision. Starting a root task will create a new audit ID and a new entry in the audit table for this task. All tasks below the root task belongs to the same task hierarchy and audit ID.
Task flow control
There are several ways to control the executions of the tasks:
- Conditional tasks
Conditional execution of tasks. - Audit flags
Execute tasks if an audit flag is set or not set - Result handling
Tasks are executed based on the result of a task (OnOK, OnFail).
Conditional tasks
A conditional task has two exits: True and false. Only one of these is executed. The condition must always return true or false.
A switch task has multiple exists, and only one of these is executed.
Audit flags
Note: Audit flags are primarily kept for backwards compatibility. It is recommended to use privileges to indicate a state.
Audit flags can be used to indicate a state for each entry. In the Identity Center you can define any number of named audit flags. The state may, for example, be "User exists in database" and "User authorized for access". As part of the result handling, a task may set or clear an audit flag.
Any action task may check the presence of an audit flag, without the need for a conditional task.
For example in the above figure, the "Create entry" task may check the presence of the audit flag "Entry exists", and set this audit flag as part of the result handling. "Delete entry" will only remove the entry if the "Entry exists" audit flag is set, and clear this audit flag as part of the result handling.
Result handling
Whenever a task completes, the result handling is initiated. The result handling is the same for all types of tasks, and consists of the following components:
- Audit flags
- Task result actions
- Chain result actions
Audit flags
It is possible to set one audit flag and clear another as part of any result handling. This audit flag result handling is only performed when the task completes OK.
Task result actions
For every task, you may define tasks that are executed depending on the result of the task:
- On OK result
This task is executed if the task runs OK. For example, the "On OK result" task can be used to send an e-mail to an administrator, stating that the task was completed. - On Failed result
This task is executed if the task fails. For example, the "On Failed result" task can be used to undo operations.
For a task group, the "On OK result" task will execute when all the sub-tasks are completed OK, which means the entire sub-tree.
The "On Failed result" task will execute whenever one task returns an error. For an ordered group, the "On Failed result" task will execute immediately after the task which failed, and no other tasks will be started. For an unordered group, all tasks are started simultaneously, and several tasks may be running (or may not even have started) when the error occurs. To avoid problems with clean-up tasks (which may be executed by the "On Failed result") the "On Failed result" task will not be executed until all the tasks are completed.
Note: The "On Failed/OK result" task will be executed for every entry.
Chain result actions
The Chain result actions work in the same way as the Task result actions, but the difference is what causes them to be executed. While Task result actions are executed for every node in the tree, the Chain result actions are executed for the node that was called externally, i.e. from an action outside the Identity Center.
Looking at the above figure, we can assume there is an "On OK result" action on the "Create user" task. If the "Create user" task is executed externally (e.g. from a web page), the "On OK result" action will be executed on this task. But if the "Create employee" task is executed externally, the "On OK result" action on the "Create user" task will not be executed.
Also I think the training manual has some slides which goes into detail here.
Matt
| User | Count |
|---|---|
| 95 | |
| 13 | |
| 13 | |
| 11 | |
| 11 | |
| 7 | |
| 6 | |
| 5 | |
| 4 | |
| 4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.