1. Introduction

People interact with business processes at different times and for different purposes. Depending on the role they have in a certain business process, they are authorized to start processes, administer and monitor them. Similarly, they can perform various tasks in the course of staff activities.

IBM WebSphere Application Server Enterprise Process Choreographer handles authorizations and user roles by means of work items.

This paper helps you to understand the concept of work items. It explains work items in general and then provides more information on modeling work items for activities and processes and the impact this has on work items in the Process Choreographer Web client.

The article also answers the frequently asked question of why users that are assigned the BPESystemAdministrators role via the WebSphere administrative console don't see work items in the Process Choreographer Web client.

Back to top

2. Understanding work items

When you model a business process, you can assign users to the different roles that exist for business processes. You do this by specifying staff expressions (so-called staff queries) for each role. A staff query can be concrete and specify user names for a certain role, or it can be more indirect and address, for example, all employees that belong to a certain department. See WebSphere Application Server Enterprise Process Choreographer Staff Resolution Architecture for more information about staff queries in the context of business processes.

When Process Choreographer executes the staff queries associated with a process entity, it creates work items for all users that have been assigned roles for the respective entity when the process was modeled. Thus, work items represent the assignment of a specific role to a specific user.

A work item represents the relationship between a business process entity and a specific user. A process entity can be the process itself, an activity, or an event. Figure 1 shows this relationship.

A work item is associated with one process entity and one user. Each process entity can have multiple work items, and each user can own several work items.

The properties of a work item include the following:

• Owner ID
  The ID of the user who owns this work item.
• Object ID
  The ID of the process entity this work item belongs to.
• Associated object type
  The type of process entity this work item belongs to. This can be a process, an activity, or an event.
• Assignment reason
  The reason why the owner of this work item owns this work item. See later sections for the assignment reasons for the various process entities.

Users are authorized to view process entities and their properties only if they own work items for the entity.

The assignment reason of a work item is crucial to the authorizations a user has for a process entity. For example, a user is only authorized to monitor a process instance if he owns a work item with reason ADMINISTRATOR for the process instance.

See WebSphere Application Server Enterprise Process Choreographer - Work items and the query() API call for more information about work items and how they can be accessed using the Process Choreographer API.

Back to top

3. Work items for processes

A work item represents the assignment of a role to a user. The following sections explain the different roles that users can have with respect to a process. They show you how user roles can be assigned on a process level and point out what impact these assignments have at run time.

3.1 Modeling processes

When you model a business process in WebSphere Studio Application Developer Integration Edition, you can assign users to process-related roles. To assign user roles:

1. Go to the Staff tab in the process editor as shown in Figure 2.
   Figure 2: Assign users to roles for a process
   
   

   There are three roles to which staff queries can be assigned.

2. To assign users via staff queries to these roles, click Change. A dialog as shown in Figure 3 appears:
   Figure 3: Define staff query
   
   

   You can define a staff query in the Change Query for Role dialog for the role you selected in the Staff dialog. The staff verb that is shown in Figure 3 is fairly simple. It defines the users Sarah and Angel as process administrators. However, much more complex queries are possible. For more information about defining staff queries, refer to WebSphere Application Server Enterprise Process Choreographer Staff Resolution Architecture and WebSphere Application Server Enterprise Process Choreographer: Staff Resolution Parameter Reference.

3.2 Processes in the Web client

As explained in the preceeding section, there are three different roles for a business process: STARTER, READER, and ADMINISTRATOR. If you want to start a process instance using the Web client, for example, the STARTER role must be assigned to you in Studio Application Developer. If you have been nominated as READER or ADMINISTRATOR, you are only authorized to view the properties of the process template, for example, to read the process template description.

If no one has been nominated as the ADMINISTRATOR of a process explicitly, the starter of a process instance becomes automatically the process administrator for this process instance. The ADMINISTRATOR role is important in the further flow of the process. Only users in the administrator role (that is, users that own a work item with assignment reason ADMINISTRATOR for the process) are authorized to perform actions such as monitoring, deleting, or terminating a process.

The following table shows the roles a user can have when interacting with processes and the typical actions they are authorized to take for this role.

You can have multiple work items for a single process instance. For example, if you are the process administrator and the process starter for a process, you will get work items for both of these roles.

However, you need to own at least one work item for a process to use the lists in the Web client that deal with processes.

There are three predefined lists that you can use when dealing with processes, depending on the assignment reasons of your work items:

• Created By Me
  This list shows the process instances you have started. If you have not started any processes, the Web client displays an empty list.
• Administered By Me
  This list shows the process instances you administer. If you do not administer any process instances, the Web client displays an empty list.
• My Templates
  This list shows the process templates you can either view or use to start process instances.

You can use the links "Define Process Instance List" and "Define Process Template List" to define additional lists of process instances or templates. In these user-defined lists, you see all the objects for which you own a work item, no matter what the assignment reason for your work items is.

Back to top

4. Work items for activities

The following sections help you to understand the different kinds of work items that exist for an activity. They describe how to assign user roles to users on an activity level. Furthermore, they explain the impact of these assignments on the authorizations that different users have at run time.

4.1 Modeling activities

As for processes, you can use staff queries to assign users to staff activity roles when you model a business process in Studio Application Developer.

1. In the process editor, right-click the activity for which you want to define staff assignments. Click Properties > Staff in the context menu of the activity.

   A dialog as shown in Figure 4 appears:

   
   Figure 4: Assign users to roles for staff activities
   
   

   In this dialog, you can define staff queries for the different user roles that exist for staff activities.

2. Select one of the roles Editor, Reader, or Potential Owner and click Change.

   Defining staff queries for activity roles works the same way as defining staff queries for processes. See 3.1 Modeling processes for more information.

4.2 Activities in the Web client

At runtime, there are the following assignment reasons for activity work items:

• ADMINISTRATOR
• OWNER
• POTENTIAL OWNER
• EDITOR
• READER

While you can explicitly assign users only to the roles Potential Owner, Editor and Reader when modeling your process, those roles are not the only roles a user may have when dealing with activities. There are other reasons why a user may own a work item at runtime:

You own a work item for an activity with assignment reason ADMINISTRATOR if you are the process administrator of the process instance the actual activity belongs to. Furthermore, you get a work item with assignment reason OWNER if you have claimed an activity for which you were a potential owner before.

In the following table, typical actions that users are authorized to perform when working with activities are listed with the roles users can have for activities.

The Web client includes one predefined list that shows activities, the My To Do list. You can see activities in this list if you are the owner, potential owner, editor, or reader of the activity (that is, if you own a work item with one of these assignment reasons).

You can use the entry "Define Work Item List" in the navigation pane to define additional lists of activities. On these user-defined lists, you see all the objects for which you own a work item, no matter what the assignment reason for the work item is.

Back to top

5. The BPESystemAdministrator role

The BPESystemAdministrator is a further user role in Process Choreographer. It is independent from processes and activities and thus valid for all process entities that are administered by Process Choreographer.

5.1 Assigning users to the BPESystemAdministrator role

You can assign users to the BPESystemAdministrator role using the administrative console of WebSphere Application Server:

1. In the navigation pane of the administrative console, click Applications > Enterprise Applications.

   The content pane shows a list of all enterprise applications that are installed on your server.

2. Click the application named BPEContainer_<hostname>_<servername> where <hostname> is the name of the host where your server is running and <servername> is the name of your server.
3. Under "Additional Properties", click Map security roles to users/groups. A dialog as shown in Figure 5 appears.

In Figure 5, the user Birgit is the only user that has been assigned to the role BPESystemAdministrator. To change the user assignment for the BPESystemAdministrator role:

1. Click the check box for the BPESystemAdministrator.
2. Click either Lookup users or Lookup Groups.

   A dialog as shown in Figure 6 appears. In this dialog, you can search for users and add them to or remove them from the BPESystemAdministrator role.

3. Click OK in this dialog.
4. Click OK on the Mapping Users to Roles dialog.
5. Save your changes in the administrative console.

To make your changes effective, stop and restart the BPEContainer_<hostname>_<servername> application.

5.2 The BPESystemAdministrator in the Web client

The BPESystemAdministrator is a super user and is authorized to perform any action on any process entity. However, users in the BPESystemAdministrator role do not see activities and processes in the predefined lists in the Web client unless they have been explicitly assigned a user role for a specific activity or process. In addition, BPESystemAdministrators typically do not own work items for processes or activities.

If you are a BPESystemAdministrator, you can use the "Define xx List" dialogs in the Web client to view and work with process entities.

For example:

1. Click Define Work Item List in the navigation pane of the Web client.
2. Click Show List without specifying any criteria.

   A list of all staff activities appears. You can save this list for later use.

3. To save a list, specify a list name and click Save.

Resources

• You can find further information about Process Choreographer in the WebSphere Developer Domain. The WebSphere Application Server Enterprise Process Choreographer page lists all the current articles.
  
  

About the author

Comments (Undergoing maintenance)

Back to top

Trademarks  |  My developerWorks terms and conditions

Table of contents

• 1. Introduction
• 2. Understanding work items
• 3. Work items for processes
• 4. Work items for activities
• 5. The BPESystemAdministrator role
• Resources
• About the author
• Comments

Next steps from IBM

• Try: WebSphere Application Server
• Webcast: Using Rational Application Developer with WebSphere Application Server to increase productivity
• Briefing: Building SOA solutions and managing the service lifecycle
• Buy: WebSphere Application Server

My developerWorks community

Dig deeper into WebSphere on developerWorks

DB2 pureScale

See how true transparent scaling architecture can be achieved on distributed platforms

Special offers