Figure: Duplicate ID indicated in Properties Page
Interactive Activities are assigned to participants - roles or organizations. Users assigned to these roles or organizations perform the work represented by an activity instance. Being assigned one or more activity instances, a user can perform these activities by completing the work items in his worklist.
Hence, there is a distinction between
Consequently, in your modeling environment you use roles and organizations. Individual human performers are created and assigned to these roles in the Stardust Portal or console administration tools or via embedding application.
The following sections describe the usage of participants in the Process workbench:
Please note that IDs containing hyphens, blanks or dots and IDs starting with digits are not supported.
IDs for participants have to be unique within all model participants like roles, organizations or conditional performer. When trying to add a duplicate ID, this is indicated in the participant properties page:
Figure: Duplicate ID indicated in Properties Page
The Problems View also shows the following error entry:
Figure: Duplicate ID indicated in Problems View.
In the Process Workbench, a participant may be represented, depending on the type of resource, by one of the symbols:
- Role
- Conditional Performer
- OrganizationParticipants are represented in the Outline view as in the following figure:
Figure: Representations of Participants in the Outline View
In diagram, participants are represented as displayed in the following figure:
Figure: Participants represented in a Diagram.
An organization element represents a group of resources. For example, a department or any organizational unit. This section describes which properties are provided and how to work with organization elements in the modeler.
The General properties entry contains:
To create an organization you can either:
When deleting organizations, you must make a distinction between deleting an organization from the model information or only deleting a symbol from a diagram. To do the first - delete an organization from the model - you proceed as follows:
The option Delete Symbol in the pop-up menu called from within the diagram canvas will only remove the organization symbol from the diagram.
It is possible for organizations to add a department scope which is evaluated at runtime. This department scope is described as a data path to process data which returns a scope key to identify a department representing this scope.
In the Department Binding section you can determine that the organization is allowed to support departments by enabling the checkbox Organization supports departments..
Figure: Department Binding
Once the checkbox is enabled, a new field opens, where you can enter data for the department OID. It is possible to select one of the following two data types:
Note
the data path should be an element (type String) of the structured data and not be using
methods as dereferentiation path.
You can set a Cost Center controlling parameter for organizations.
Figure: Controlling Parameter for Organizations
In the properties dialog of the organization you can choose how the task assignment is performed:
Figure: Task Assignment of an Organization
In this section you can specify simulation configurations, as described detailed in the chapter Simulation Configurations of the Stardust Simulation Guide.)
In this section you can set the organization complexity for project effort calculation:
Figure: Effort Planning Property of an Organization
Please refer to the chapter Project Effort Calculation for detailed information on this functionality.
A role denotes the responsibility assigned to the participants. Following sections provide information on how to work with roles.
The General properties entry contains:
To create a role you can either:
When deleting roles you must make a distinction between deleting a role from the model information or only deleting a symbol from a diagram. To do the first - delete a role from the model - you proceed as follows:
The option Delete Symbol in the pop-up menu called from within the diagram canvas will only remove the role symbol from the diagram.
You can define the cardinality of roles in the properties dialog. Type in the maximum users that can be assigned to this role in the Cardinality entry field.
Figure: Setting the Cardinality
The following controlling parameters are provided for roles:
Figure: Controlling Parameters for Roles
In the properties dialog of the role you can choose how the task assignment is performed:
Figure: Task Assignment of a Role
In this section you can specify simulation configurations, as described detailed in the chapter Simulation Configurations of the Stardust Simulation Guide.)
In this section you can set the role complexity for project effort calculation:
Figure: Effort Planning Property of a Role
Please refer to the chapter Project Effort Calculation for detailed information on this functionality.
The conditional performer is evaluated at runtime and it determines the identity of the actual performer. The following sections help you to work with conditional performers.
To create a conditional performer you can either:
As described in the chapter Participants and Users, the OID or respectively ID of the performer assigned dynamically at runtime is passed to the Stardust resource.
Following are the General properties of conditional performer:
Figure: Conditional Performer - General Properties
Among the conditional performer's properties, there is also the distinction between an individual user of the runtime environment and a performer defined in the modeling environment (corresponding to a role or organization) used as a conditional performer. This distinction has to be made in the same properties dialog. Click Runtime Binding to define the performer as a user, organization/role or user group and choose the data and optional data path to provide the performer's identity.
In the Kind drop-down list, define the performer as one of the following:
Figure: Specifying a Conditional Performer
In the OID/Id section, choose the data and data path providing the performer identity.
Figure: Conditional Performer
Note
In case the data is of type Long, the value is used to identify the
OID of the performer, as thus it refers to a user. If the data is of type String,
the value is used to identify the Id of the performer, as this has to be a role in that case.
If the conditional performer is defined as a user, an additional field appears to
fill in the users realm
data.
Figure: Specifying a Conditional Performer as User
The Last Activity Performer data usage determines that the performer is used as a computed value. The algorithm for a specific process instance is as follows:
Note
Please note that in case the activity is the first activity in the work flow,
there would be no Last Activity Performer.
If an activity other than the first one is unable to retrieve
the last activity performer due to the transaction isolation level COMMITMENT,
set in the database, enable the Fork on traversal flag in the
transition between the current and the last activities.
Please refer to the section Activity Thread of the
chapter Runtime Behavior for detailed
information on the Fork on Traversal
functionality.
In this section you can specify simulation configurations, as described detailed in the chapter Simulation Configurations of the Stardust Simulation Guide.
In this section you can set the performer complexity for project effort calculation:
Figure: Effort Planning Property of a Conditional Performer
Please refer to the chapter Project Effort Calculation for detailed information on this functionality.
When deleting conditional performers, you must make a distinction between deleting a conditional performer from the model information or only deleting a symbol from a diagram. To do the first - delete a conditional performer from the model - you proceed as follows:
The option Delete Symbol in the pop-up menu called from within the diagram canvas will only remove the symbol for the conditional performer from the diagram.
Note that it is not possible to assign a conditional performer to a manual trigger!
Organizations are groups of human resources. Consequently, they may contain individual roles or subordinate organizations. Like process definitions, organizational hierarchies can be modeled in the Stardust Process Workbench with the help of diagrams.
To model your organizations, use either diagrams bound to a process definition or model diagrams. A prerequisite for establishing relationships between an organization and its members is the existence of these elements: an organization and all its members (roles or smaller organizational units). Proceed as follows:
Figure: Making an Organization Part of Another
To add further members to the organization, repeat these operations for each member. An example of an organizational hierarchy diagram is shown below.
Figure: A Sample Organizational Diagram
The following sections describe the restrictions on associations between organizational elements.
Please note that a model participant can only have one relationship like Work For or Manager of to other participants. Otherwise the model validation fails and the following error message appears in the Problems view:
Figure: Error indicated in Problems View
An organization should not be part of more than one other organization. Otherwise the model validation fails and the following error message appears in the Problems view:
Figure: Error indicated in Problems View
Stardust supports scoping of roles, organizations and departments. The following sections describe what happens when the organizations are scoped.
Roles are implicitly scoped via the next scoped Organization above.
When a User is assigned to an (implicitly) scoped Role, the Role and the departments for all organizations, the Role has a "Works For" or "Is Manager Of" relationship, have to be specified.
All Organizations and Roles underneath a scoped Organization inherit the target departments of this Organization, as long as the sub-organization does not define a new target department. Hence, for every participant the relevant target department is the scope of the next scoped Organization upwards the organizational hierarchy.
Stardust only allows pure tree structures for organizational hierarchies. Neither Roles nor Organizations may be assigned to more than one Organization. Matrix structures can be mapped by disjoint organizational structures with possibly different scopes (e.g. branch vs. project), whereby users might be assigned to Roles in both structures.
Stardust supports the matrix organization structure at runtime. While modeling, you cannot model the matrix structure completely. The matrix organization structure can be achieved at runtime using the process portals. You need to create departments in the Administration perspective to make a complete matrix structure.
The following diagram displays the sample structure created at the modeler level. In the organization structure diagram, we have four organizations - M1 Project Orga, M2 Project Leader Orga, M1 Test Orga and M1 Development Orga. Each of these organizations has roles defined. The M1 Project Manager is the manager of M1 Project Organization. The M3 Project Member works for M2 Project Leaders Organization. These two organizations - the M1 Project Organization and M2 Project Leaders organizations are connected. The M2 Test Engineer Organization works for M1 Test organization and M1 Test Manager is the manager of the M1 Test Organization. We cannot connect one role to multiple organizations directly. That's why we need to create departments and assign users to roles. To achieve the same scenario, three red arrows are used to indicate that you need to create department Project A in the M1 Test organization and department Project A and Project B in the M2 Leaders Organization.
Figure: Sample Model for Matrix Organization
Note that restrictions exist for deploying a model with changes in the department association for existing roles or organizations, to a succeeding model version. Please refer to the section Changes in the organizational structure of the Consistency Checks part in the chapter Deploying a Workflow Model for detailed information on which changes are supported and which will lead to a consistency error.
A role can be assigned as team leader to an organization. Please refer to the section Teams of the chapter Participants and Users for a detailed description on the definition of a team.
There can only be one team leader per organization. In case no team leader is associated to an organization yet, you are offered the following two types of connection:
The Works For connection is a simple assignment of a role to an organization, whereas the Manager Of connection defines the role to be the organizations team leader.
Figure: Connecting a Role as Team Leader
The connect transition between a team leader and an organization is displayed as a dashed line.
Figure: Connect Transition between Team Leader and Organization
In the Control Center Perspective of the Stardust Portal, the team leader has an overview over the activities of all users belonging to the same organization the team leader belongs to.
In case an organization has an invalid teamlead connection, e.g. it has a teamlead connection, but the team leader is not set in the model file, an error indicates this in the Problems View.
Figure: Connection Error displayed in the Problems View.
You have the option to use the provided Quick Fix functionality for quickly fixing this error. Right-click the error entry and choose the Quick Fix option in the drop-down menu.
Figure: Select Quick Fix to fix the Error.
The Quick Fix dialog opens, where you can fix the teamlead connection for the organization.
Figure: Quick Fix Dialog
In case you want the admin user to view all the processes in the model whereas the other user/role should start only a specific process. For example, you have a model which contains four processes P1, P2, P3 and P4. The process P1 and P2 display the data whereas P3 and P4 update of data. The model has two participants that are Admin and Teller.
Suppose you want the Admin user to start all the four processes and the Teller user to start only two processes that are P1 and P2.
To achieve this, define an organization A and make the roles Admin and Teller Works for organization A. Then assign the manual start trigger of P1 and P2 process to organization and manual start trigger of P3 and P4 to Admin role.
When the provider-consumer relationship is established between two models, the participants of the provider model can be referenced in the consumer model. To reference the participants, perform the following steps:
Figure: Participant Available for Reference
When you drag-and-drop the referenced participant the reference is created and the referenced model participant appears in the locally defined model participant.
Figure: Participant Available for Reference
For more information, please refer to the section Referencing Model Elements of the External Model Resources chapter.
Note that if the participant with identical ID already exists in the consumer or referencing model then you cannot refer the participant of the provider or referenced model. Similarly, you cannot create a participant in the consumer model, if the participant with identical ID is in use as a reference from a provider model. In such a case, a model validation error is displayed.
For more information, please refer to the section Consistency Checks of the Deploying a Workflow Model chapter.
Also, the following dialog is displayed in case the referenced participant ID is identical with the consumer participant and you try to drag and drop the referenced participant. If you click Ok, only the selected element is imported by reference. If the organization has sub-organizations, then those sub-organizations do not get imported by reference.
Figure: Conflict - Replace