9 Managing Process Workspace (for Administrators)

9.1.1 How to Specify the Login Page Realm Label in Process Workspace

If the identity service is configured with multiple realms, then, when a user logs in to Oracle BPM Worklist, the login page displays a list of realm names. LABEL_LOGIN_REALM specifies the resource bundle key used to look up the label to display these realms. You can change the term realm to fit the user community—terms such as country, company, division, or department may be more appropriate. To change the term realm, customize the resource bundle, specify a resource bundle key for this string, and then set the Login page realm label parameter to point to that resource bundle key.

For information about customizing the resource bundle, see Appendix B, "Customizing a Resource Bundle".

For information about specifying a resource bundle, see Section 9.1.2, "How to Specify the Resource Bundle in Process Workspace."

9.1.2 How to Specify the Resource Bundle in Process Workspace

The resource bundle provides the strings displayed in the Worklist Application. By default, the class path to the resource bundle is:

oracle.bpel.worklistapp.resource.WorklistResourceBundle

As an administrator, you can add or modify strings shown in the application by creating a custom resource bundle. You can then use the Resource Bundle field in the Application Preferences page to specify the class path to your custom resource bundle.

For more information about customizing the resource bundle, see Appendix B, "Customizing a Resource Bundle."

9.1.3 How to Specify the Language Locale Information in Process Workspace

You can specify how the Worklist Application display language is determined. Information about the language locale can be derived from either the user's browser or the identity provider that stores information on worklist users.

9.1.4 How to Specify a Branding Logo in Process Workspace

A branding logo is the image displayed in the top left corner of every page of the Worklist Application. The Oracle logo is the default, and you can change it to one of your choosing.

To specify the branding logo:

Do one of the following:

• Refer to an external image-hosting website. To do this: In the Branding Logo field, enter the URL of the image.

• Upload an image to a particular location on the server and, in the Branding Logo field, enter its relative path, for example, /afr/my_logo.png.

• Refer to an image from the shared library. To do this: In the Branding Logo field, enter the path of the logo name as found in the shared library, for example, /my_logo.png

For more information about deploying images in a shared library, see Appendix D, "Deploying Images and JAR files as Part of a Shared Library JAR file".

9.1.5 How to Specify the Branding Title in Process Workspace

You can specify the title for your site, changing the default title, BPM Worklist, to one that you choose.

To specify the branding title:

Do one of the following:

• In the Branding Title field, enter a simple string for your title.

• In the Branding Title field, enter a label that refers to a key-value pair in the Resource Bundle. In this way, you can internationalize your title, for example, LABEL_WORKLIST_TITLE.

9.1.6 How to Choose a Skin in Process Workspace

A skin determines the look and feel of your graphical interface.

To choose a skin:

Do one of the following:

• From the Choose a Skin list, select one of the default ADF skins

• Upload your own customized skin .css file in a .JAR file and deploy it as a part of shared library. Then, when you restart your application from the console, your custom skin appears in the Choose a Skin list.

To create a customized skin:

1. Create a directory structure similar to the following example:

   C:\temp\META-INF\adf\oracle\skin\images
        META-INF\skins\custom.css
        META-INF\trinidad-skins.xml
   

   Note that, in this example, you can change the word custom to the name of your own customized skin.

2. Make sure the content of trinidad-skins.xml file is as follows:

   <?xml version="1.0" encoding="ISO-8859-1"?>
   <skins xmlns="http://myfaces.apache.org/trinidad/skin">
      <skin>
        <id>custom.desktop</id>
        <family>custom</family>
        <extends>custom.desktop</extends>
        <render-kit-id>org.apache.myfaces.trinidad.desktop</render-kit-id>
        <style-sheet-name>skins/custom.css</style-sheet-name>
      </skin>
   </skins>
   

3. Create the .JAR file by issuing the following command from the c:\temp directory:

   jar -cvf customSkin.jar META-INF/
   

4. Copy this Jar file to the directory /scratch/username/sharedLib.

For more information about deploying images in a shared library, see Appendix D, "Deploying Images and JAR files as Part of a Shared Library JAR file".

9.1.7 How to Enable Customized Applications and Links in Process Workspace

For Process Workspace, you can create customized external applications and links that become available in the External Applications panel. Moreover, in both Process Workspace and the Worklist Application, you can specify the columns that appear in the Task Details pane.

To enable customized applications:

1. In the Application Preferences page, enter the class name of your custom application in the Application customization class name field.

2. Restart the application from the console.

   Depending on your customization, you can now see it's effects.

   If your customization is for Process Workspace and involves either creating an external application or specifying inbox columns in the Task Details pane or both, you will see the following:

   • Your custom application listed in the External Applications panel of the Process Workspace Home page as shown in Figure 9-2.

     Figure 9-2 External Applications Panel in Process Workspace

     
     

   • The columns of the Task Details inbox adjusted according to your specifications.

   For information about customizing applications, se Appendix C, "Customizing Applications in Process Workspace and the Worklist Application".

9.1.8 How to Show or Hide the Default Tab Pages in Process Workspace

If you are an administrator, you can specify whether to show or hide the Process Workspace standard tabs, for example, Tasks, Activity Guides, Process Tracking, and Standard Dashboards. Also, from the tabs you decide to show, you can select the one to be the default tab when a user logs in.

To Show or Hide the Standard Process Workspace Tabs:

1. Select Administration, then Application Preferences.

2. From the Show Standard Tabs row, select the checkboxes for the tabs you want to show, or deselect them for the tabs you want to hide.

3. From the tabs you decide to show, specify which is the default tab when a user logs in. Do this by selecting the radio button next to the check box for that tab.

Figure 9-3 shows the Application Preferences page with the Show Standard Tabs row highlighted. It calls out a check box for selecting a tab to show or hide, and a radio button for selecting a tab to be the default at user login.

Figure 9-3 Show Standard Tabs Selection

9.2.1 Managing Mapped Attributes (Flex Fields) 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:

1. Specify a label for the mapped attribute to be populated.

2. 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.

For more information about how to map mapped attributes, see Oracle Fusion Middleware Developer's Guide for Oracle SOA Suite.

9.2.1.1 How to Specify Mapped Attributes

An administrator, or users with the necessary privileges, can use mapped attributes, shown in Figure 9-4, to transfer data from the payload to inline 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 9-4.

Figure 9-4 Specifying a Mapped Attribute

For more information about public and protected mapped attributes, see Oracle Fusion Middleware Modeling and Implementation Guide for Oracle Business Process Management.

To create labels: 

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 9-5.

Figure 9-5 Creating a Label

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.

To browse all mappings: 

1. Click Browse all mappings.

2. Select a row in the label table to display all the payload attributes mapped to a particular label.

To edit mappings by task type: 

1. Click Edit mappings by task type, optionally provide a task type, and click Search.

2. Select a task type and click OK.

3. With the task type displayed in the Edit mappings by task type field, click Go.

4. Select a mapping label and click Select.

9.2.2 Administering Approval Groups in Process Workspace

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 user interface that enables users with administrator rights to manage approval groups.

9.2.2.1 How to View Approval Groups

To view approval groups: 

1. From the Process Workspace toolbar, click Administration. The Administration Areas panel appears in the left pane.

2. Under Task Administration, click Approval Groups. The Groups page appears in the right pane.

3. 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 9-6.

Figure 9-6 Oracle Business Process Management Workspace: Approval Group Detail

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.

9.2.2.4 How to Add a New Member to a Static 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: 

1. From the Details page shown in Figure 9-9, 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.

2. Select User.

3. 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.

4. Select Users from the list.

5. 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.

6. Choose a user from the list.

   The details for that user appear in the Details section of the dialog.

7. Click OK.

8. 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 9-9.

Figure 9-9 Approval Group Structure: Multiple Members

9.2.2.9 Using Dynamic Approval Groups

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 Service Integration class path

9.2.2.9.1 How to Write a custom Dynamic Approval Group Class

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 9-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 9-10 shows a code snippet for a sample dynamic approval group class.

Figure 9-10 Code for Dynamic Approval Group Class

9.2.2.9.2 How to Register the Custom Dynamic Approval Group Class

For more information, see Oracle Fusion Middleware Modeling and Implementation Guide for Oracle Business Process Management

9.2.2.9.3 How to Make the Custom Dynamic Approval Group Class Available

To make the class file available in a globally well-known directory that is part of the Service Integration 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.

9.2.2.9.4 How to Add a Dynamic Approval Group

The following procedure explains how to add a dynamic approval group.

1. In the left pane, click the Add (+) button and select Create Dynamic from the list

2. Enter a name and a class for the group.

3. Click Apply to save the group.

9.2.3 Using Task Configuration in Process Workspace

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:

1. From the Process Workspace toolbar, click Administration. The Administration Panel appears in the left pane.

2. In the Administration Panel, under Task Administration, click Task Configuration. The Task Configuration page appears in the right pane, as illustrated in Figure 9-11.

Figure 9-11 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.

9.2.4 Using Evidence Search in Process Workspace

The evidence store service is used for digital signature storage and nonrepudiation of digitally signed human tasks.

To search the evidence store:

1. In the Process Workspace toolbar in the upper right corner, click Administration. The Administration Areas panel appears in the left pane.

2. In the Administration Areas panel, under Task Administration, select Evidence Search. The Evidence Search page appears in the right pane, as shown in Figure 9-12.

   Figure 9-12 Searching the Evidence Store

   
   

3. 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.

9.2.5 Managing Exceptions in Process Workspace

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.