This chapter explains the various tasks an administrator can perform in Process Workspace.
This chapter contains these topics:
Section 8.1, "Setting the Display of the Work Items Panel in Process Workspace"
Section 8.2, "Managing Other Users' or Groups' Rules (as an Administrator) in Process Workspace"
Section 8.3, "Managing Your Organization in Process Workspace"
Section 8.4, "Administering and Configuring Task-Related Information in Process Workspace"
To set the display of the Work Items panel, administrators can specify the following application preferences:
Login page realm label—If the identity service is configured with multiple realms, then the Process Workspace login page displays a list of realm names. The LABEL_LOGIN_REALM
parameter specifies the resource bundle key used to look up the label to display these realms. The term realm can be changed to fit the user community—terms such as country, company, division, or department may be more appropriate. Administrators can customize the resource bundle, specify a resource key for this string, and then set this parameter to point to the resource key.
Global branding icon—This is the image displayed in the top left corner of every page of the worklist. (The Oracle logo is the default.) Administrators can provide a .gif
, .png
, or .jgp
file for the logo. This file must be in the public_html
directory.
Resource bundle—An application resource bundle provides the strings displayed in the worklist. By default, this is the class at:
oracle.bpel.worklistapp.resource.WorklistResourceBundle
Administrators must extend WorklistResourceBundle.java
by adding their resource strings. Administrators can change the strings shown in the application by copying WorkflowResourceBundle
and customizing it. This parameter allows administrators to specify the class path to this custom resource bundle. Then administrators create a JAR file from the compiled resource bundle and copy it under
SOA_Oracle_Home\j2ee\home\applications\worklist\worklist\WEB-INF\lib
Use language settings of—Select the browser or the identity provider.
The identity provider that stores information about worklist users can store the user's locale, which can determine the worklist display language. Alternatively, the user's browser can supply the locale information. This parameter determines which is used as the source for determining the worklist application display language.
For more information about the display of local languages, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
To specify application preferences:
Click Administration.
Click Application Preferences.
Specify the login page realm label, branding icon, or resource bundle as described earlier in this section and as shown in Figure 8-1.
Figure 8-1 Setting Application Preferences in Process Workspace
Select which language settings you want to use—from the browser or the identity provider.
Click Save.
Administrators can make changes to rules. This ability is useful for correcting a problem with a rule. For example, for a user who no longer works for the company, administrators can set up a rule for that user so that all tasks assigned to the user are automatically assigned to another user or group.
To create a rule for another user or group:
From the Process Workspace toolbar, click Configuration.
From the Configuration panel, in the Rules section, click Rules.
Click the Other Rules tab.
From this point, follow the instructions in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
Oracle Business Process Management Suite enables you to model an organization by defining organizational units, business calendars, business holidays, roles, and other user properties.
This section contains these topics:
Section 8.3.1, "Understanding Deployment of Organization Entities in Process Workspace"
Section 8.3.2, "Managing Holiday Rules in Process Workspace"
Section 8.3.3, "Managing Calendar Rules in Process Workspace"
Section 8.3.5, "Managing Organization Roles in Process Workspace"
Section 8.3.6, "Extending User Properties in Process Workspace"
Section 8.3.7, "Managing Organizational Units in Process Workspace"
For information about organizational units, see Oracle Fusion Middleware Modeling and Implementation Guide for Oracle Business Process Management.
When a process is deployed, the various organization entities—for example, the organizational unit, calendar, and so on—are created. Later, when the process is redeployed, those entities are not modified. After a process is created, modification can happen only through Process Workspace. This is to prevent data in Oracle BPM Studio overwriting what can be changed during run time.
Business holidays are collections of holidays that can be applied to calendar rules. Then, when computing the duration of a process, the calendar takes into account the specified holidays.
You can create as many holiday rules as needed for different calendar rules. For example, if you apply holiday rules for India, the United States, and China to a given calendar, then those various national holidays are taken into account when the duration of a process is computed.
When you create a business holiday rule, you specify the holiday name, date, and holiday type. Table 8-1 lists and describes the holiday types.
Holiday Type | Description |
---|---|
Same Day Every Year |
On the same day each year |
Current Year |
In the current year only |
Nth Week Day of Month |
In a specified week, on a specified day, in a specified month each year—for example, in the United States, Thanksgiving Day is celebrated each year on the fourth Thursday of November |
Nth Day of Reference Holiday |
On a day in relation to another specified holiday—for example, on the day after Thanksgiving Day |
Closest week day |
The closest day to a given date—for example, in the United States, the Independence Day holiday may be celebrated on the weekday closest to the Fourth of July. |
From the Process Workspace toolbar, select Administration. The Administration Areas panel appears.
In the Organization panel, click Calendars. The Calendars page appears.
In the Holidays List section, click Add a Holidays List. The Add a Holidays List dialog prompts you for the name of the new holiday list.
Enter the name of the new holidays list and click OK. The new holidays list appears in the holidays list.
Select the new holidays list. The details for the new list appear in the right pane.
In the holiday details section, click Add a Holiday. A row appears for you to specify the attributes of the new holiday.
Specify the name of the holiday, and the day on which the holiday occurs each year. Options for specifying holiday occurrence are described in Table 8-1.
Click Apply. The new holiday rule is configured according to your specifications.
From the Process Workspace toolbar, select Administration. The Administration Areas panel appears.
In the Organization panel, click Calendars. The Calendars panel appears in the right pane.
In the Holidays List section, select the holiday rule you want to edit. The details page for the rule appears in the right pane.
Change the settings, and click Apply. The holiday rule is now modified according to your specifications.
From the Process Workspace toolbar, select Administration. The Administration Areas panel appears.
In the Organization panel, click Calendars. The Calendars panel appears in the right pane.
In the Holidays List section, select the holiday rule you want to delete. The details for the rule appears in the right pane.
Click Delete Holiday Rule. The holiday rule is now deleted.
A business calendar defines a work pattern for each day and a work week structure for each week. In addition, a calendar also defines non-working days by using business holiday rules—that is, the business calendar and holiday rule together define the work period.
When you create a business calendar, you define the following:
Calendar name
Time zone
Working days in week
Start time and end time for each day
Optional holiday rule
You can create as many calendars as necessary.
You can specify a business calendar for a role and organizational unit association. For example, you can specify that the InsuranceAgents role in the US-California organizational unit follows the US-California business calendar.
From the Process Workspace toolbar, select Administration. The Administration Areas panel appears.
In the Organization panel, click Calendars. The Calendars page appears in the right pane.
In the Calendars section, click Add a Calendar Rule. The Add a Calendar Rule dialog prompts you for the name of the new calendar rule.
Enter the name of the new calendar rule, and click OK. The new calendar rule appears in the Calendars list.
Select the new calendar rule. The details for the new rule appears in the right pane.
Specify the following:
The time zone
The holiday rule, if any, that applies
The appropriate starting and finishing times
Click Apply. The new calendar rule is now configured according to your specifications.
From the Process Workspace toolbar, select Administration. The Administration Areas panel appears.
In the Organization panel, click Calendars. The Calendars page appears in the right pane.
Select the calendar rule you want to edit. The details page for the new rule appears in the right pane.
Change the settings, and click Apply. The calendar rule is now modified according to your specifications.
To associate a calendar rule with a role and an organization unit:
From the Process Workspace toolbar, select Administration. The Administration Areas panel appears.
In the Organization panel, click Roles. The Roles panel displays a list of the roles you are authorized to administer.
In the Details panel, in the Calendars section, click Associate a new calendar rule to an organization unit for the application role. Calendar and Organization Unit lists appear in the Calendar section.
Using Calendar and Organization Unit lists, specify the calendar and organization unit to which you want to associate this role.
Click Apply.
To associate a calendar with an organization unit:
From the Process Workspace toolbar, select Administration. The Administration Areas panel appears.
Under Organization, click Organizational Units. The Organizational Units panel appears.
Select the organizational unit with which you want to associate a calendar rule. The details for that organizational unit appear in the right pane.
In the Details panel, from the Calendars list, select the calendar to associate with this organizational unit.
Click Apply.
From the Process Workspace toolbar, select Administration. The Administration Areas panel appears.
In the Organization panel, click Calendars. The Calendars panel appears in the right pane.
In the Calendars section, select the calendar rule you want to delete. The details for the rule appears in the right pane.
Click Delete Calendar. The calendar is now deleted.
Roles are created as application roles under the application OracleBPMProcessRolesApp. There are two types:
Swimlane roles: Each swimlane role in a BPM process is created during design time in Oracle BPM Studio. It is then mapped to an application role that is created during deployment. This mapping cannot be changed after deployment.
Members for these application roles can be defined and updated before deployment by using Oracle BPM Studio or after deployment by using Process Workspace.
In this release, swimlanes define the default task assignee and how to initiate a process if the initiator task pattern is used. During runtime, only members of those roles can perform actions such as viewing and acting on tasks and initiating processes.
Application roles: These represent any roles in the organization, and they can be created in addition to the swimlane roles defined during design time. An application role can be used as a task assignee or as a grantee of another application role. They can be created by using either Oracle BPM Studio or Process Workspace.
When you create a role, you define both the role name and the grantees of the role. The grantees can be users, groups, or other application roles.
To add a new application role:
From the Process Workspace toolbar, select Administration. The Administration Areas panel appears.
In the Organization panel, click Roles. The Roles panel displays a list of the roles you are authorized to administer.
In the upper-right corner of the Roles panel, click Add a new application role. The Add Role dialog box appears.
Specify a name, and, optionally, a description for the new role. Click OK. The new role is now listed in the Roles panel.
To grant this role to users, groups or application roles, follow the steps in Section 8.3.4.2, "How to Grant and Revoke Roles".
To associate a calendar and its corresponding organizational unit with this new role, in the Calendar section:
Select Associate a new calendar rule to an organization unit for the application role.
From the Calendar list, select the calendar you want to associate with this new role.
From the Organization Unit list, select the unit that you want to associate with the calendar you just specified.
Note:
When a calendar is associated with an organization unit for a role, this calendar overrides the calendar associated with the calendar page when the particular role is used.You can grant roles to, and revoke them from, users, groups, or application roles
To grant a role to a user, group, or application role:
From the Process Workspace toolbar, select Administration. The Administration Areas panel appears.
In the Organization panel, click Roles. The Roles panel displays a list of the roles you are authorized to administer.
Select a role. The Details panel displays the details for the selected role, as shown in Figure 8-4.
In the Members section, click Grant the role to user, group, or role.
Specify the parameters of your search, click Search, then select the user, group, or application role to whom you want to grant this role. The Details section for your selection appears.
Click OK. The user or group you specified now appears in the Members box.
To revoke a role from a user, group, or application role:
From the Process Workspace toolbar, select Administration. The Administration Areas panel appears.
In the Organization panel, click Roles. The Roles panel displays a list of the roles you are authorized to administer.
Select a role. The Details panel displays the details for the selected role.
In the Members section, click Revoke the role from user, group, or role.
Click OK. The user or group you specified no longer appears in the Members box.
Note:
Process Workspace caches the user's role information for the duration of the session. As a result, if you are an administrator, and you grant a role to or revoke a role from yourself as the administrator, you will not see the change reflected in the interface until you terminate the session and open a new one. Terminate the session by logging out, then log back in.
If, during design time, you update a process by removing a member from a role and then re-deploy the process, the member you removed is still listed as a member of that role. This is because permission to remove members from roles is limited to administrators during runtime.
For information about creating a role-specific layout, see Section 5.1, "Creating Custom Pages in Process Workspace"
Organization Roles are logical roles that define the members of an organization unit. They are groups of users specified by using a query. These roles are dynamic—for example, all grantees of role InsuranceAgent with expertise in HomeInsurance where expertise is an extended user property.
The query can contain one or more of the following parts:
Extended user properties
For information about extended user properties, see Section 8.3.6, "Extending User Properties in Process Workspace".
Note:
Deleting an extended user property already in use by an organization role causes an error when administering that role.An organization role can be a member of organizational unit.
To associate properties to users, you must have a manager role in relation to those users.
Organization roles can be based only on process roles that can be created in the Administration Areas panel in Process Workspace.
You can define several parameters of which some, none, or all can be evaluated and used at run time.
To create an organization role:
From the Process Workspace toolbar, click Administration. The Administration Areas panel appears in the left pane.
Select Organization Role. The Organization Role panel appears in the right pane.
In the Organization Role panel, click Create Organization Role. This opens an editable Details panel.
Enter a name for this organization role, and specify the conditions users in this role must meet.
From the Grantees list, select either Groups or Application Roles.
If you select Groups:
Either enter the name of the group in the text field, or click Select Group to begin a search. The Select Group dialog box appears.
Specify your search, or use an asterisk (*) as a wildcard, then click OK. The group you specified is listed as the grantee of this organization role.
If you select Application Role:
From the Application Role list, select the application role you are granting.
If you know the role identifier of the grantee, enter it in the Role Id field. Otherwise, you can use an asterisk (*) as a wildcard.
Click Search. The search results appear in the Searched Items panel.
Select a role from the Searched Items list. More detailed information for that role appears in the Details panel.
Click OK. The role you specified is listed as the grantee of this organization role.
Click Apply.
To modify an organization role:
From the Process Workspace toolbar, click Administration. The Administration Areas panel appears in the left pane.
Select Organization Role. The Organization Role panel appears in the right pane.
From the Organization Role panel, select the role you want to modify. The Details panel for that role appears to the right.
Enter the new values for the role just as you did when you created the role. See "To create an organization role:".
Click Apply.
To delete an organization role:
From the Process Workspace toolbar, click Administration. The Administration Areas panel appears in the left pane.
Select Organization Role. The Organization Role panel appears in the right pane.
From the Organization Role panel, select the role you want to delete. The Details panel for that role appears to the right.
Click Delete Organization Role and, when prompted, confirm the deletion.
Extended user properties are used in defining organization roles, which are described in Section 8.3.5, "Managing Organization Roles in Process Workspace.".
Typically, users have some properties specified in Oracle Internet Directory or some other LDAP directory. Often, however, additional properties specific to their organization and roles are necessary. At times, these properties are added on demand when newer business processes are created. At that time, it might not be possible to extend the company's global LDAP directory. In these cases, extended user properties are useful. For example, you can specify that a given user with the sales representative role is located in California. Although, from a functional point of view, there is only one role, the individual user is associated with a property, and that property has a value assigned for that user.
Figure 8-6 shows the Extended User Properties page.
Extended user properties can be assigned to users, groups, or roles.
When you create extended user properties, you define the following:
Property name
Property type, which can be of the following data types: string, number, date and free form text. String data types are enumerated values. Free form strings can have any value.
Enumeration in case of a string data type. Note that only string-typed properties can be assigned values at the time of definition and only those values can be assigned to users when the property is associated with a user.
After properties are defined, they can be associated with any user. During association, values must be assigned to the property for that user
Only users who have Administrator privileges can define new properties.
To add extended user properties:
From the Process Workspace toolbar, select Administration. The Administration Areas panel appears.
In the Organization panel, click Extended User Properties. The Extended User Properties page appears in the right pane.
In the Properties pane, click Add Property. Property fields appear in the table.
An Extended User Property has the following fields:
Name—The name can be any user defined string that is meaningful to the user or the company. Case does not matter. The system will convert all names to uppercase.
Type—The type field is a drop-down list from which the user must select the data type of the values that the property is expected to hold when it is associated with various users in the organization.
Value—The value field is meaningful only when the property is assigned the data type string because only string typed properties can be assigned enumerations of values. For all other data types (number, date and freeform text) no values can be assigned to the property.
For number, date, and freeform text-typed properties, a value is assigned to the property only when the property is associated to a user and the value assigned can be different for each user.
After you specify the property, click Apply. A column for this property appears in the Map Properties pane.
To modify extended user properties:
From the Process Workspace toolbar, select Administration. The Administration Areas panel appears.
In the Organization panel, click Extended User Properties. The Extended User Properties page appears in the right pane.
In the Properties pane, select the property you want to edit, then click Edit Property. The row for that property becomes editable.
Enter your changes, then click Apply.
To delete extended user properties:
Note:
Deleting an extended user property already in use by an organization role causes an error when administering that role.From the Process Workspace toolbar, select Administration. The Administration Areas panel appears.
In the Organization panel, click Extended User Properties. The Extended User Properties page appears in the right pane.
In the Properties pane, select the property you want to delete, then click Delete Property. A Confirm Delete dialog box advises you that deleting a property will dissociate this property from and associated user, if any. If you are sure you want to proceed, click Yes.
In the Properties pane, click Apply.
To associate extended user properties to users:
To specify the user with whom this property is to be associated, in the Map Properties pane, click Add User. The User field appears.
Specify the user. You can do this either by entering the user identifier in the field or by clicking Select User, and, in the Identity Browser window that appears, performing a search for the user and clicking OK.
If the property is a string type, then, in the Map Properties pane, from the column for the property, select the property to assign to this user. If the property is a number, enter the appropriate value in the text field.
Note:
The All check box means that you wish to assign all the values defined on the string property to a particular user. It does not mean that you are assigning all the properties defined in the system to the user. The purpose of the All check box must be understood in the context that a user can be assigned multiple values for a string and a freeform text typed property. For string-typed properties the values that you can assign to a user are enumerated at the time of property definition itself and the All checkbox enables you to assign all of them to a user at once. Freeform text-typed properties do not have any values defined on them. To assign multiple values to a freeform text-typed property at the time of associating it to a user, enter the multiple values and separate each value by a comma.After you map the property to the user, in the Map Properties pane, click Apply.
An organizational unit represents departments or divisions within an organization. Organizational units can contain child organizational units, creating a hierarchy that corresponds to your organization.
When you create an organizational unit, you define the following:
Organizational unit name
Time zone
Members of the organizational unit, which can include users, groups, application roles, or organization roles
Optional parent organizational unit
Optional business calendar
When a process is associated with an organizational unit, only members of that organizational unit and its children can see that process and the tasks initiated by it.
Note:
A manager is not a member of an organizational unit by default. The manager must be added to the organizational unit in order to see the processes and the tasks within it.If a process is associated with an organizational unit, then the tasks initiated by the process can use the business calendar associated with the organizational unit. Please see Section 8.3.3, "Managing Calendar Rules in Process Workspace" for more information.
To create an organizational unit:
From the Process Workspace toolbar, select Administration. The Administration Areas panel appears.
Under Organization, click Organizational Units. The Organizational Units panel appears.
From the Add Organizational Unit list, select either Root Organization Unit or Child Organization Unit. The Create New Org Unit dialog box prompts you for the name of the organizational unit.
Enter the name of the organizational unit, and click OK. The new organizational unit appears in the Organizational Units list as shown in Figure 8-7.
In the right pane, in the Details section for the new organizational unit, do the following:
Optionally provide a description of the newly created organizational unit.
From the Calendar list, select a calendar rule to associate with this organizational unit.
For information about adding a calendar rule, see Section 8.3.3, "Managing Calendar Rules in Process Workspace".
In the Members window, click Add new member. The Select Member dialog box prompts you to search for a user or group to add to this organizational unit.
Enter the name of the user or group you want to add, then click Search. From the Available column, select one or more members you want to add, and use the arrow button to move them to the Selected column. Click OK. The members you added appear in the Members window.
Similarly, in the Managers window, select Add new member. The Select Manager dialog box prompts you to search for a user or group to add to this organizational unit.
Enter the name of the manager you want to add, then click Search. From the Available column, select one or more managers you want to add, and use the arrow button to move them to the Selected column. Click OK. The managers you added appear in the Members window.
Click Apply.
To edit an organizational unit:
From the Process Workspace toolbar, select Administration. The Administration Areas panel appears.
Under Organization, click Organizational Units. The Organizational Units panel appears.
In the Organization Units panel, select the organizational unit you want to edit.
Figure 8-8 Organization Units Details Panel
In the right pane, in the Details section for the new organizational unit, make the changes you want, then click Apply.
To delete an organizational unit:
From the Process Workspace toolbar, select Administration. The Administration Areas panel appears.
Under Organization, click Organizational Units. The Organizational Units panel appears.
In the Organization Units panel, select the organizational unit you want to delete, and click Delete Organization Unit.
This section contains these topics:
Section 8.4.1, "Managing Mapped Attributes (Flex Fields) in Process Workspace"
Section 8.4.2, "Administering Approval Groups in Process Workspace"
Section 8.4.3, "Using Task Configuration in Process Workspace"
Human workflow mapped attributes (formerly referred to as flex fields) store and query use case-specific custom attributes. These custom attributes typically come from the task payload values. Storing custom attributes in mapped attributes provides the following benefits:
They can be displayed as a column in the task listing
They can filter tasks in custom views and advanced searches
They can be used for a keyword-based search
For example the Requester, PurchaseOrderID, and Amount fields in a purchase order request payload of a task can be stored in the mapped attributes. An approver logging into Process Workspace can see these fields as column values in the task list and decide which task to access. The user can define views that filter tasks based on the mapped attributes. For example, a user can create views for purchase order approvals based on different amount ranges. If the user must also retrieve tasks related to a specific requester or a purchase order ID, the user can specify this in the keyword field and perform a search to retrieve the relevant tasks.
For the mapped attributes to be populated, an administrator must create mapped attribute mappings, as follows:
Specify a label for the mapped attribute to be populated.
Map the payload attribute that contains the data to the label.
These mappings are valid for a certain task type. Therefore, each task type can have different mapped attribute mappings. After the mapping is complete and a new task is initiated, the value of the payload is transferred to the mapped attribute that has just been mapped. Tasks initiated before the mapping do not contain the value in the mapped attribute. Only top-level simple type attributes in the payload can be transferred to a mapped attribute. Complex attributes or simple types nested inside a complex attribute cannot be promoted. It is important to define the payload for a task in the Human Task Editor, keeping in mind which attributes from the payload may must promoted to a mapped attribute. All text and number mapped attributes are automatically included in the keyword-based search.
Essentially, the Human Task Editor is used only when defining the payload for a task. All other operations are performed at runtime.
Directory naming is not available concomitantly with the flex file naming convention.
Note:
Mapped attributes must be defined before instances of the business process are generated. Only instances generated after mapped attributes are created reflect the correct mapped attributes. Older instances of the business process do not reflect subsequent mapped attribute changes.For more information about how to map mapped attributes, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
An administrator, or users with the necessary privileges, can use mapped attribute mapping, shown in Figure 8-9, to transfer data from the payload to inline attribute mapped attributes. By promoting data to mapped attributes, the data becomes searchable and can be displayed as columns on the task list.
Administrators and users with the appropriate privileges can map both public and protected mapped attributes. They see both a Public Flex Fields node and a Protected Flex Fields node in the Administration panel as shown in Figure 8-9.
For more information about public and protected mapped attributes, see Oracle Fusion Middleware Modeling and Implementation Guide for Oracle Business Process Management.
To create a mapped attribute mapping, an administrator first defines a semantic label, which provides a more meaningful display name for the mapped attribute. Click Add to use the Create Label dialog box shown in Figure 8-10.
As the figure shows, labelName is mapped to the task attribute TextAttribute1. The payload attribute is also mapped to the label. In this example, the Text attribute type is associated with labelName. The result is that the value of the Text attribute is stored in the TextAttribute3 column, and labelName is the column label displayed in the user's task list. Labels can be reused for different task types. You can delete a label only if it is not used in any mappings.
A mapped payload attribute can also be displayed as a column in a custom view and used as a filter condition in both custom views and workflow rules. The display name of the payload attribute is the attribute label that is selected when doing the mapping.
Note the following restrictions:
Only simple type payload attributes can be mapped.
A mapped attribute (and thus a label) can be used only once per task type.
Data type conversion is not supported for the number
or date
data types. For example, you cannot map a payload attribute that is assigned the string
datatype to a label that is assigned the datatype number
.
Click Browse all mappings.
Select a row in the label table to display all the payload attributes mapped to a particular label.
To edit mappings by task type:
Click Edit mappings by task type, optionally provide a task type, and click Search.
Select a task type and click OK.
With the task type displayed in the Edit mappings by task type field, click Go.
Select a mapping label and click Select.
An approval group consists of a name and a predefined set of users configured to act on a task in a certain pattern. This pattern is similar to a human workflow routing slip pattern where users can act on tasks in serial or parallel. An approval group also can contain a nested approval group in the pattern.
The name of an approval group is necessary when specifying the approval group list builder as discussed in Oracle Fusion Middleware Modeling and Implementation Guide for Oracle Business Process Management. The pattern configured in the approval group is used by default to order the users who must act on the task. However, when creating the list builder, the default pattern can be overridden by specifying the voting method.
The sections that follow describe the Worklist Application user interface that enables users with administrator rights to manage approval groups.
From the Process Workspace toolbar, click Administration. The Administration Areas panel appears in the left pane.
Under Task Administration, click Approval Groups. The Groups page appears in the right pane.
In the navigation pane of the Approval Groups page, select an approval group. A details page for that approval group appears in the right pane, similar to the one shown in Figure 8-11.
The figure shows that the DisbursementTeam approval group has two users, bpalmer and rjames. The users will act on a task in a specific sequence configuration.
You can search for an approval group either by user name or group name.
From the Process Workspace toolbar, click Administration. The Administration Areas panel appears in the left pane.
Under Task Administration, click Approval Groups. The Approval Groups page appears in the right pane.
Select User from the list.
Enter the full user name for the user in the field. (You also can perform a wildcard search (*) with a partial user name.)
Click the action (>) button.
A list of all approval groups to which the user belongs displays in the left pane, as shown in Figure 8-12.
Clicking the approval group name refreshes the details pane on the right with the structure of that group.
In the left pane, select Group from the list.
Enter the full group name in the field. (You also can perform a wildcard search (*) with a partial group name.)
Click the action (>) button.
A list of all matching approval groups displays in the left pane.
Clicking on the approval group name refreshes the Details pane on the right with the structure of that group.
To add a static approval group:
Click the Add (+) button and select Create Static from the list, as shown in Figure 8-13.
Figure 8-13 Create Approval Group: Select Static Group
Enter a new name for the group.
Click Apply.
You can add members to the new approval group.
Members of a static approval group can be either users or other approval groups.
To add a new user member to an approval group:
From the Details page shown in Figure 8-14, click the Add (+) icon.
The other icons enable you to edit, delete, and reorder members in the approval sequence.
The Add to Group dialog box appears.
Select User.
Do one of the following:
Enter a full user name and click OK.
The dialog box closes and the new member appears in the Members section of the Details pane.
Click the magnifying glass to search for a user.
If you click the magnifying glass, an Identity Browser pop-up dialog appears.
Select Users from the list.
Enter a full name in the text-entry field and click Search. (You also can perform a wildcard search (*) with a partial user name.)
The Identity Browser dialog refreshes and the search results appear.
Choose a user from the list.
The details for that user appear in the Details section of the dialog.
Click OK.
Click OK again to close the Add to Group dialog.
A node representing the selected user appears in the approval group structure in the Members section of the Details pane.
You can add more members to the approval group by repeating the steps above. The resulting approval group structure will look similar to the one shown in Figure 8-14.
Figure 8-14 Approval Group Structure: Multiple Members
To delete a member from an approval group:
Choose the appropriate member node from the approval group structure.
Click the Delete icon.
The approval group structure refreshes and the member node has been deleted.
To change the sequence order of an approval group:
Choose a member node to move.
Use the Push Member Up (^) and Push Member Down (v) icons to move the member to the desired location.
Nesting an approval group means making it part of another approval group.
Click the Add icon.
Select Approval Group.
Click the magnifying glass.
Another Add to Group dialog box appears.
From the left pane, choose the approval group you want to add.
Its structure appears in the right pane.
Click OK.
Click OK again to close the Add to Group dialog box.
The new approval group appears in the approval group's structure.
Enter the new name of the approval group in the Name field.
Click Apply.
The name change is reflected in other approvals groups in which this approval group is nested.
Dynamic Approval Groups provide a way to create approval groups through a custom Java class at runtime. This requires the following:
Writing a custom dynamic approval group class for the custom implementation by the developer
Registering the custom dynamic approval group using the worklist apps UI by the IT department
Making the class file available in a globally well known directory that is part of the SOA class path
To define a dynamic approval group, the user must define an implementation class using the interface file IDynamicApprovalGroup.java
, defined by AMX for dynamic approval groups in the package oracle.bpel.services.workflow.task. This package contains only one public method that gets the approval group members. The Task object will be the only input parameter. The primary key list can be obtained from the task task/systemAttributes/collectionTarget.
Example 8-1 Implementation Class
************** IDynamicApprovalGroup.java ****************** public interface IDynamicApprovalGroup { /** * Get members of this dynamic approval group * @param task Property bag containing information required to generate the approver list * @return list of IApprovalListMember including sequence, member, member_ type; null for empty group * The primary key list can be obtained from task: task/systemAttributes/collectionTarget */ public List getMembers(Task task ) throws WorkflowException; } **********************************************************
Figure 8-15 shows a code snippet for a sample dynamic approval group class.
For more information, see Oracle Fusion Middleware Modeling and Implementation Guide for Oracle Business Process Management
To make the class file available in a globally well-known directory that is part of the SOA class path, put your class files in the following WebLogic Server directory:
$BEAHOME/AS11gR1SOA/soa/modules/oracle.soa.ext_11.1.1/classes
For example, for the Java class oracle.apps.DynamicAG, the path would be $BEAHOME/AS11gR1SOA/soa/modules/oracle.soa.ext_11.1.1/classes/oracle/apps/DynamicAG.class
. You must restart WebLogic Server after you put your class files there.
In the Approval Group page, choose the approval group you want to delete.
Click the Delete (-) button.
A confirmation dialog box appears.
Click OK.
The approval group is deleted.
Note:
If the approval group you deleted is nested in other approval groups, it also is deleted from those parent groups.Task Configuration in Process Workspace lets business users and administrators review the rules that were configured automatically by the workflow designer. These predefined rules can be changed for a specific customer based on the customer's applicable corporate policies.
For example, if a corporate policy requiring two levels of approvals for expense amounts greater than 1000 is changed to a policy requiring three levels, the customer can use this web-based application to change the rule rather than having its IT department modify the rule in the underlying process and then deploy it again. Any change made to the rule will be applied starting with the next instance; instances that are already in progress will use the current rule definitions.
Task Configuration enables you to edit the event driven and data-driven rules associated with an approval flow at run time; that is, when the workflow has already been deployed.
To access the Task Configuration page:
From the Process Workspace toolbar, click Administration. The Administration Panel appears in the left pane.
In the Administration Panel, under Task Administration, click Task Configuration. The Task Configuration page appears in the right pane, as illustrated in Figure 8-16.
Figure 8-16 Task Configuration: Main Page
The Tasks to be configured section in the right pane lists all workflow tasks that have been configured to use approval-flow rules. It also provides a search capability. In the view mode, the right panel displays the default configuration and rules for overriding the approval-flow list builder configuration. The rule configurations are displayed based on the stages defined in the approval flow.
This section contains information about event-driven settings (task metadata).
To edit an event-driven setting:
From the Process Workspace toolbar, click Administration. The Administration Panel appears in the left pane.
In the Administration Panel, under Task Administration, click Task Configuration. The Task Configuration page appears in the right pane.
In the Tasks to be configured pane, select a task. The main page refreshes in edit mode.
Make your changes and click Apply to save them.
Note:
An improper or incomplete rules definition in a list-creation rule set can cause runtime errors. Errors can be caused by the following:No rule was defined in the rule set.
None of the conditions defined in the rule was met.
Ensure that rules are properly defined to handle all conditions.
The Event Driven page contains a limited set of the routing options available in the Human Task Editor.
Approval aggregation requirements can be any of the following:
None
Once per task
Once per stage
Defining expiration and escalation policies in Process Workspace is similar to how it is done in the Human Task Editor. For more information, see the section "How to Escalate, Renew, or End the Task" in the chapter "Designing Human Tasks" in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
Creating or updating notification settings for a task in Process Workspace is similar to how it is done in the Human Task Editor. For more information, see the section "How to Specify Participant Notification Preferences" in the chapter "Designing Human Tasks" in Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
Access-rule settings can be set to control the actions a user can perform and is similar to how it can be done in the Human Task Editor. Content and action permissions can be specified based on the logical role of a user, such as creator (inititator), owner, assignee, and reviewers.
For more information, see Oracle Fusion Middleware Modeling and Implementation Guide for Oracle Business Process Management.
To edit a data-driven setting (a rule or condition):
From the Process Workspace toolbar, click Administration. The Administration Panel appears in the left pane.
In the Administration Panel, under Task Administration, click Task Configuration. The Task Configuration page appears in the right pane.
In the Task Configuration page, select the Data Driven page.
In the Tasks to be configured pane, select a task.
The right panel refreshes in edit mode.
Do any of the following:
Add
Update
Delete
Change assertions (which depend on the type of list builder for which the rule has been configured)
Add variables
When you have finished making your changes, click Apply.
The changes are saved to the rule definitions in the rules dictionary.
For more information about editing tasks see Oracle Fusion Middleware Modeling and Implementation Guide for Oracle Business Process Management.
To add a variable:
In the Data Driven page, click Add variable.
The Add Variable window appears.
Enter a name for the variable.
Click the down arrow to select a variable type from the list.
The types displayed in the list correspond to those that are available in the rule dictionary (built-in and others that have been registered).
Enter a value.
Click OK.
The variable can now be used to define conditions.
You can set the left and right sides of a condition by selecting operands from condition browsers. Clicking the magnifying glass icon displays the browsers.
The operator for comparing the operands of the condition will change based on the type of operand selected for the left side of the condition.
You also can define more complex conditions using the Expression Builder.
For more information, see the section "Creating ADF Data Binding EL Expressions" in Oracle Fusion Middleware Fusion Developer's Guide for Oracle Application Development Framework. See also the section "Creating EL Expressions" in Oracle Fusion Middleware Web User Interface Developer's Guide for Oracle Application Development Framework.
The evidence store service is used for digital signature storage and nonrepudiation of digitally signed human tasks.
In the Process Workspace toolbar in the upper right corner, click Administration. The Administration Areas panel appears in the left pane.
In the Administration Areas panel, under Task Administration, select Evidence Search. The Evidence Search page appears in the right pane, as shown in Figure 8-17.
Fill in the search fields, then click Search Evidence Store.
For information about the evidence store for digital signatures, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
Under certain circumstances—for example, an employee who has left the company being assigned to a task—an exception can occur. When an exception occurs, the task gets put into an alerted state. The task then gets assigned to the error assignee or, if one is not specified, to the administrator.
For information about configuring the error assignee, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.
There are other scenarios in which an exception can happen.
The user metadata migration utility, hwfMigrator
, is a tool that automates the process of migrating workflow user-configurable data from one SOA server to another by executing a shell script. The tool also includes a property file that contains key-value pairs and all the input parameters required to perform the migration operation. You customize the property file and then perform the migration by executing the shell script.
For information about using the User Metadata Migration Utility, see Oracle Fusion Middleware Modeling and Implementation Guide for Oracle Business Process Management.
For information about moving Oracle BPM from a test site to a production site, see Oracle Fusion Middleware Administrator's Guide.