Outlining the Roles and Authorizations of a BPMN Process

Task processors can only execute the particular task he or she is assigned to.

The processor who assigned to a human activity overrides the task processor. There might be different processors for a task because the task as reusable entity can be assigned to multiple human activities.

The processor who is assigned to a lane can execute all tasks that are assigned to human activities in this lane. The lane processor overrides the task and human activity processors. If you use a task within a process, the potential processor definition of the surrounding lane takes precedence.

The processor is evaluated while the task instance is created at runtime. During this process, UME groups and roles are resolved into UME users. This means that changes to the group or role after the task has been instantiated do not have any effect on the task instance that is currently being created. If a user is assigned to a group or role that allows the user to execute a task during the task instance creation, the user could continue to work on the task and complete the task even if the assignment to the group or role is changed or canceled. These changes only take effect on the future task instances.

There are three types of roles for tasks, activities, and lanes: potential owners, excluded owners, and task contributors. The figure illustrates the relations between these objects.

Further explanations:

Potential Owners

Potential owners are used to identify users authorized to complete a task, activity, or activities in a lane. A potential owner becomes the actual owner, or processor, only when the task is opened. Once a task is claimed by a potential owner, the task is removed from the task list of all potential owners. Potential owners and task authorizations are defined at the task, human activity, and lane levels.

When using principal propagation, the principal information of the actual owner is propagated in the process flow to be used later by an automated activity.

Tasks can be accessed in the Universal Worklist. In Business Process Management (BPM), portal roles are assigned to users to enable them to access and execute tasks (of a BPM process) in the universal worklist (UWL).

Excluded Owners

Excluded owners are principals who are not allowed to process a task in the process model. This construct is necessary to prevent users from approving their own requests. Excluded owners are defined on the task, human activity, or lane levels.

Task Contributors

An actual owner of a task can invite other contributors to work on the task instance while the task is active. Any user can be a contributor, except excluded owners. Task contributors can see the whole process context, monitor the task execution, and add notes and attachments, but cannot complete the task.

When a user is invited to be a task contributor, the task displays in their UWL. When the contributor opens the task, they can see the actual owner and the task description.

A business process administrator can execute administration tasks for processes, activities, or tasks. At least one administrator must be available for each process. A process cannot be deployed without an administrator.

Process administration allows a process to be suspended, resumed, and terminated. Task administration allows you to execute, forward, suspend, or resume a task, change deadlines, and prioritize activities and tasks.

Troubleshooting allows for the debugging of running processes in the Process Composer to locate and analyze errors. The troubleshooting tool is integrated into the SAP NetWeaver.

Administrator is used to check for the availability of BPM components and subsystems. There are also tools to monitor and manage processes and tasks.

When maintaining the attributes of the Administrator tab, you can define the administrator(s) of a pool via the notion of principals. A principal represents any user, user role, or user group responsible for some aspects of the process.

The Administrators category is used to define a process’s Pool Administrator, which can perform administrative tasks on the process, such as canceling, suspending, or resuming. A minimum of one administrator is mandatory in the process. While defining an administrator, you can choose between selecting an administrator directly from the UME of the SAP Process Orchestration (PO) server or using an expression. The administrator subject is covered in more detail in the next section.

You can select multiple users (principals) as administrators for a pool. Any of the selected principals can act as administrators for the pool.

Specifying a principal as a specific user might not always be a good approach. This is because you are required to know the names of the users in advance, that is, during the development time. This approach does not provide much flexibility. If you hard-code the name of a specific user in a task, then only this specific person can perform the task in question. What if he or she is absent? Note that changing this attribute’s value requires a transport — not very useful if your process is in production and you need to change it.

A better approach would be to use roles or groups. In that way, you only need to add users to the appropriate role or group, and they will automatically be able to administer the process. Assigning a role to a user or adding the user to a group can be directly performed in the UME of the required environment (for example, production) and does not require objects to be transported. As a result, this approach has less risk and offers more flexibility.

Additionally, you can use an expression to define a pool administrator. When using an expression to define the pool administrator, it’s possible to make use of default functions provided by SAP to select the correct users or administrators during runtime. Use the getPrincipal function to specify the administrator. This is an easy and flexible way to access the principals without having to connect to the server.

In general, the following roles and participants will occur in the notification of a business process:

• the lane administrator

• the pool administrator

For each lane, you will have an administrator. To keep the example simple and understandable the number of roles and participants in the purchase order process was limited to one.

In this example, both possible roles are taken by the user Administrator##. In a real example, you could have more lanes, with different administrators.

These administrators can be roles or users.

If you assign a user as Administrator for a pool or lane, the user inherits the roles and rights (Authorizations) that are stored in the UME. Each user may have multiple roles assigned to him or her in the UME. In an implementation, these roles can be recreated or enhanced by the customer.