Using Worklist

     Previous  Next    Open TOC in new window  Open Index in new window  View as PDF - New Window  Get Adobe Reader - New Window
Content starts here

Creating and Managing Worklist Task Plans

This section provides information about the following:

 


About Tasks and Task Plans

In Worklist, a task represents an activity that is assigned to a human user. The human user oversees the progress of the task and ensures that it is completed in a correct and timely manner. A task can include one or more steps, and one or more exit points (called terminal steps). Each step represents a distinct phase in the completion of the task. Human actors move tasks through their defined steps by taking actions on the task at each step. Each step defines one or more actions from which the human actor can choose. An action called a “work action” has an associated step to which the task will move when the action is taken. This model allows a task to move through a set of planned steps in a manner dictated by the actions taken on the task.

A terminal step indicates the end of the effective lifetime of the task. Terminal steps can only be reached via a work action taken by a user. Terminal steps can be marked to indicate normal completion (via Complete Step) or abnormal termination (via Abort Step). A task plan must have at least one terminal step.

Tasks can be assigned to and claimed by a human user. Tasks are associated with a set of properties representing task data. Human users can specify and alter properties as the steps in a task are completed.

The steps and properties for a given type of task are defined by a Task Plan and apply to all instances of tasks of that type. All tasks of a given type are then governed by the plan defined for that type of task. Task plans are defined by a designer prior to the creation of any task instance of the type being governed by the plan.

All task instances, regardless of their associated task plan, have properties (called system properties) like:

In addition, the task plan associated with the task instance defines other elements of a task instance. These include:

 


Administrative and Working States

The Administrative state of a task is a value that describes how the Worklist system is currently treating the task instance.The various administrative states are:

Table 2-1 Administrative States
Administrative State
Description
Aborted
Task instance completed abnormally. No further actions are allowed on steps, and all properties are read-only. The task can be reactivated using the Reactivate global action.
Active
Task instance is active and can be interacted with. You can take actions on your steps, set properties, and so on.
Completed
Task instance completed normally. No further actions are allowed on steps, and all properties are read-only. The task can be reactivated using the Reactivate global action.
Error
Task instance has encountered some technical error and cannot proceed without administrative intervention. No actions are allowed on steps, but task properties may still be modified. Other types of interaction are allowed on this task only after using the ClearError global action.
Suspended
Task instance is not yet complete (or aborted) but temporarily cannot be interacted with (except to resume it). No actions are allowed on steps, and properties are read-only.

The Working state of a task is a value that describes the current association of the task with human actors who can work on the task. The various working states are:

Table 2-2 Working States
Working State
Description
Assigned
Task instance is associated with a list of candidate users who may potentially work on the task. No user has taken responsibility for completing the task.
Claimed
Task instance is associated with a single human user who has taken responsibility for completing the task. This user may later choose to complete the task or return it (putting it back into the Assigned working state).
Unassigned
Task instance is not associated with any human user who can work on the task

The coresponding database numeric value of the worklist task states are:

 


Global Actions

A number of global actions have been defined that affect the administrative state of the task. These actions may be taken on any task instance regardless of task plan. The actions that effect administrative state are:

Table 2-3 Global Actions
Operation
Description
Abort
Forcefully stop a task. This signifies that the task should be cancelled and should not complete. This operation is performed by the claimant, an administrator, or the task owner. State of the task becomes Aborted.
Assign
Causes a task to move to the ASSIGNED state. The Assignees list must be set when this operation is performed and specify which users can claim the task.
This operation can be performed on tasks in a final state, such as COMPLETED or ABORTED. This allows you to work on the task again.
This operation can unassign or reassign a task. Assignment can be performed on a single task instances multiple times throughout its life cycle. When assigning a task, an algorithm must be specified to determine how to set the Assignees List. To learn about the algorithms, see Assignment Algorithms.
This operation is performed by the task owner, task creator, an assignee, or an administrator.
Claim
Causes a task in the ASSIGNED state to become CLAIMED. A user that is on the Assignees List is set as the claimant of the task. This signifies that a user on the Assignees List has marked ownership of the task and intends to complete it. This operation is performed by a user who wishes to become the claimant for a task, or by an administrator or task owner on behalf of another user.
Clear Error
Force a task instance that has been set into the error state back into the active state. This action will fail if the current user is not an administrator or owner for the task.
Complete
Causes a task in the STARTED state to become COMPLETED. It signifies that the claimant has finished the work required to complete the task, or as much of the work as is possible to do is finished. This operation is performed by the claimant, or by an administrator or task owner on behalf of the claimant.
Create
Creates a new task instance in the ASSIGNED state.
Delete
Delete a task instance. This action will fail if the current user is not an administrator or owner for the task.
Reactivate
Bring a task back from a terminal state. This action will fail if the current user is not an administrator/owner for the task.
If the task was administratively completed or aborted, the value of the current step will be the step the task was on when the task was aborted or completed. In this case, this step will again be the current step after reactivation of the task instance.
If the task completed or aborted as a result of a user action, the final action or step fields will be used to put the task instance back at the step from which the final action was taken.
Resume
Cause a SUSPENDED task to return to the state it was in prior to its suspension. This operation is performed by an administrator or by the task owner.
Return
Remove the current claimant for the task, and force the task back into the Assigned working state. This action will fail if the current user is not an administrator/owner for the task.
Set Error
Force a task instance into the Error Administrative state. This action will fail if the current user is not an administrator or owner for the task.
Start
Causes a task in the CLAIMED state to become STARTED. It signifies that the claimant is starting to work on the task. This operation is performed by the claimant, or by an administrator or task owner on behalf of a claimant.
Stop
Causes a task in the STARTED state to return to the CLAIMED state. It signifies that the claimant is stopping work on the task, possibly temporarily. They can start it again when they are ready to continue working. This operation is performed by the claimant, or by an administrator or task owner on behalf of the claimant.
Suspend
Causes a task to become SUSPENDED. It signifies that the task no longer progresses and should not be worked on, possibly temporarily. The task can be resumed (using the resume operation) when work should continue. This operation is performed by an administrator or task owner.

 


Worklist Properties

Every task has a number of built-in properties, called the system properties. System properties that can be edited may be specified when you define the task plan, steps and actions in the task plan. In addition, you can define properties that are relevant to your task plan. These are called user properties.

Task Plan Properties

When you design and develop the task plan, you can specify the following properties:

Table 2-4 Task Plan Properties
Property
Description
Completion Due Date
The business date and time by which this task must be completed. This is specified as a time interval, and an optional business calendar name. If there is no business calendar name given, the Worklist global system calendar will be used in the date calculation. The business calendar is used to calculate the absolute date by which the task must be completed.
The interval may define a number of days, hours and/or minutes in the D days H hours M minutes format, where D is number of days, H is number of hours, and M is number of minutes.
The completion due date of the task is generated based on the interval, and the user or business calendar. For example, if the interval is specified as 10 days and the business calendar is selected. If current date is 1, and the next 5 days are busy based on selected business calendar, then the completed due date for the task would be 15.
Description
A description of the task plan
Owner Name
Name of the User who created the task.
Time Estimate
The estimated time (specified as a business calendar interval, for example, 3min2hour1day or 10 years 5 hours 3 seconds) required to complete the task. This information is used by the default Worklist assignment handler for load balancing. If specified, this value is used as a default value for the time estimate setting on all the steps this task contains.
Version
The version of the task plan. Default value is 1.0.
Terminal Task Retention
The duration (specified as a business calendar interval, for example, 3min2hour1day or 10 years 5 hours 3 seconds) for which Completed or Aborted tasks should be retained in the runtime store before becoming eligible for purging. For more information, see “Purging Tasks” in Worklist Administration.
Threshold Priority
An integer value that, if specified, conditionally enables the use of user availability information when performing load balancing during task assignment. Availability checking is performed only for those task instances that have a Priority value greater than or equal to the given threshold value.

System Properties

Every task has a number of built-in properties (defined by Worklist and not any individual task plan) that may be set from a constructor or action taken from a step. These properties (called system properties) may be referenced in the property name list of an action or constructor by prefixing the name of the system property with a system defined prefix.

Note: This prefix is locale-sensitive. In the US English locale, the prefix is 'sys:'.

Some of the system properties that can be edited are Task Name, Comment, Priority, Task Completion Due Date, Task Time Estimate, Current Step Completion Due Date, and Current Step Time Estimate.

User Properties

The user properties for a task consist of any number of name/type pairs that define data elements that are maintained for any instance of the task plan. These data elements represent the data passed between participants in completing a given task. A task plan may define any user properties that make sense to help accomplish the goal of that type of task.

At runtime, Worklist administrators (and/or the Worklist API and task control) can modify the properties (both user and system) of a task instance (including adding new user properties) as needed. This is done by creating a copy of the task plan for the task, adding the user property, and applying the new task plan to the task instance using the Set Task Plan global action. This ability allows Worklist administrators to respond to special circumstances that may arise on a per-task instance basis.

User properties may be defined with:

 


Worklist Application

A Worklist application consists of an EAR and a Web project, which contain all the files and directories that relate to a single unit of work. Optionally, there can be a Utility folder for the Worklist Application that contains the Oracle WebLogic System Integration and Control Schemas.

The EAR project corresponds to the Enterprise Application. You can build and deploy this project to create the entire process flow of the enterprise. The task plan that you create is stored under the EARContent folder in the <EAR project name> folder.

The Web project corresponds to the Web application of Worklist that acts as the user interface for the system. The Web project is a part of the EAR project.

Note: <web project name> in this document refers to the name of this folder.

Worklist allows developers to define custom plugin classes of various types. For example, developers can define custom assignment handlers by implementing com.bea.wli.worklist.api.config.AssignmentHandler, or implement a custom task event listener by implementing com.bea.wli.worklist.api.events.TaskEventListener.

The custom plugin classes must be placed in a utility project so that they are available from the host application's class loader. In order to write these classes, developers need access to Worklist API classes. To implement custom plugin classes, create a utility project to host the plugin code, and then manually add the worklist-client.jar library to the build path of the project.

To add the worklist-client.jar library to the project build path:

  1. In Package Explorer view, right-click on the Utility folder and select Properties. The Properties for <utility folder name> dialog appears.
  2. Select Java Build Path in the left navigation pane and select the Libraries tab (see Figure 2-1).
  3. Figure 2-1 Add worklist-client.jar


    Add worklist-client.jar

  4. Click Add External JARs and navigate to the location of the worklist-client.jar file (WebLogic installation directory/wli_10.3/lib). Select the file and click Open.
  5. Click OK.

Now, your utility project should have access to Worklist API classes needed to write the plugin implementation.

There are three Worklist application types:

 


Overview of Creating Task Plans

The steps and properties for a given type of task are defined by a Task Plan and apply to all instances of tasks of that type. Every step (other than terminal steps including Completed Step and Aborted Step) of a task plan can include actions, which allow the transition of the task instance from one step to another. The actions can be taken by authorized employees or system actors.

Steps

A step is a distinct phase in the life cycle of a task. A Worklist designer defines steps within the scope of a task plan. A step represents a simple set of actions that can be taken to move a task along in its processing. Terminal steps (Complete Step or Abort step) allow a step to be terminated. A step has elements like:

You can select the steps from the Palette View, drag and drop it into the Task Plan Editor. You can then actions to the step and also set the properties of the step. For more information, see Adding Steps and Actions to a Task Plan.

Actions and Connections

Actions represent work a human user does or decisions that are made by a human user in a step in the task instance. Users take actions that are defined for the current step in the task instance. An action definition lives within a step, which in turn lives within a task plan. The various types of actions in Worklist are:

You can select any of these steps from the Palette View in the Task Plan Perspective, drag and drop the actions within the step in the task plan. For more information, see Adding Steps and Actions to a Task Plan.

Work Action

Work Actions represent work the user has done or decisions they have made with respect to this task. A work action causes the transition of a task from one step to another step. The step from which the transition occurs is the step that contains the action. The step or terminal state to which the transition occurs is named or identified within the action itself. Information about the work done or decision taken is captured in properties for the task. Work actions define the data required to complete the action (if any), and a description of what the action means, and under what circumstances the human actor should take the action.

Work actions can specify a number of properties that must be updated or specified when the action is taken. This is the primary mechanism for updating the properties for a task.

Assign Action

Assign actions cause the task on which they are taken to be reassigned according to assignment instructions defined for the action.

Return Action

Return actions cause the task to be “returned” to the Assigned Working state so that they may be claimed by a different user at a later date.

Assign to Next User

AssignToNextUser actions works in conjunction with the “Iterate List” candidate list handling and assigns the task to (and automatically claims it for) the ‘next’ user in the candidate list. For more information, see Candidate List Handling.

Connections

Connections in the Palette View are used to specify the navigation of the steps and actions in the task plan. The connections connect the connector with the first step in the task plan and also the order in which the actions should be done.

Constructors

A task plan defines one or more constructors that are used to initialize new instances of the task plan. A constructor defines:

The properties defined for a constructor follow the same rules for properties listed on a work action. That is, the constructor can reference properties defined on the task plan or the system editable task properties.

Note: A task plan may define constructors that define no required properties. In addition, there can be any number of such constructors.

Candidate List Handling

A task may be explicitly assigned to task or implicitly assigned to a task via a Assignee list. For information about assigning a task from the Oracle Worklist Console, see “Assigning a Task to User or Group” in Worklist Administration. For information about assigning a task from the Task Plan Editor, see Assignment Instructions.

The assignment instructions contain the following:

The assignee list is evaluated to generate a list of candidate claimants for the task. The candidate list is then evaluated. The possible scenarios of candidate list evaluation are given below. These scenarios are based on the type of candidate list handling chosen. Valid values for candidate list handling are:

Load Balancing

When an assignee list yields a list of candidate users that contains more than one candidate, and the candidate list handling type is set to “Load Balancing”, Worklist chooses a user based on that user's workload and, optionally, availability. This behavior is called “load balancing”.

Since load balancing can be somewhat costly (especially when evaluating work load for a large list of candidate users), Worklist allows the task administrator to specifically enable load balancing on a step by step basis. Load balancing may be enabled by specifying the candidate list handling type as LoadBalancing on the assignment instructions in the WorklistTaskAdmin.assignTask() call, or on any step that specifies assignment instructions.

By default, load balancing does not take into account the user's availability (based on business calendar). However, if this is required, checking can be turned on within the load balancing process. Availability is calculated as a “score” where higher score values indicate greater availability

Steps in Creating a Task Plan

  1. Create a task plan folder.
  2. Create a task plan.
  3. Add one or more steps to the task plan.
  4. Define the system properties of each step in the task plan.
  5. Add one or more actions for each step in the task plan.
  6. Define the system properties for each action in all the steps in the task plan.
  7. Define any user properties for the task plan, if required.
  8. Use Connectors to specify the sequence in which the steps and actions should be executed.
  9. Create a Constructor for the task plan.
  10. Validate the task plan.

 


Before you Begin

Before you start using Worklist, make sure that you:

Creating a Domain

You have the option to create a domain to:

Configuring a Domain to Run WLI Business Process and Worklist

You may create this domain using the Configuration Wizard. For more information, see Creating a New WebLogic Domain in Creating WebLogic Domains Using the Configuration Wizard.

Configuring a Domain to Run Worklist

You may create this domain for running worklist application independently, without business process support. To configure the domain perform the following steps:

  1. Create a Oracle WebLogic Server domain in the Configuration Wizard.
  2. From the Start menu, click All ProgramsArrow symbol>Arrow symbolOracle WebLogic >Arrow symbolWebLogic Server 10g R3 >Arrow symbolToolsArrow symbol>Arrow symbolConfiguration Wizard to start the Oracle WebLogic Configuration Wizard.
  3. Select Extend an existing WebLogic domain and click Next. This displays the Select a WebLogic Domain Directory Source page in the Configuration Wizard dialog box.
  4. Select the WebLogic domain to which you want to add the applications and services and click Next.
  5. Select Extend my domain using an existing extension templete and click Browse.
  6. Select workshop_wl.jar and click Ok.
  7. Click Broswe, and select the p13n.jar.
  8. Repeat the above steps and select wli_worklist.jar.
  9. Accept the default settings in the Customize JDBC and JMS File Store Settings page and click Next.
  10. In the Extend WebLogic Domain page, click Extend.
  11. Click Done, and the domain is configured.

Configuring a Server

You need to configure a server on which you can deploy the worklist applications.

To configure a server:

  1. Select File > New > Other. The Select a Wizard dialog appears.
  2. Click the Add worklist-client.jar icon next to Server and select Server. Click Next. The Define a New Server dialog appears (see Figure 2-2).
  3. Figure 2-2 Define a New Server


    Define a New Server

  4. Select the host name of the server and server type. Retain default values for the rest of the fields. Click Next.
  5. The Define a WebLogic Server dialog appears (see Figure 2-3).

    Figure 2-3
    Define a New Server
    Define a Oracle WebLogic Server
  6. Enter the path to the domain home. If required, click Browse to locate the domain. Click Next.
  7. The Add and Remove Projects dialog appears (see Figure 2-4).

    Figure 2-4 Add and Remove Projects


    Add and Remove Projects

  8. Select any projects in the Available Projects list and click Add.
  9. Click Finish.

The server is configured.

Configure a domain to run only for worklist

Starting Oracle Workshop for WebLogic

To start the application:

  1. Select Start > All Programs > Oracle WebLogic > Workshop for WebLogic.
  2. The Workspace Launcher dialog appears ( see Figure 2-5).

  3. Specify the folder in which all your projects should be stored. This folder is called the Workspace.
  4. Figure 2-5 Workspace Launcher


    Workspace Launcher

  5. Click OK.
  6. The Oracle Workshop for WebLogic IDE is displayed.

 


Creating a Worklist Application

A Worklist application consists of an EAR and a Web project, which contain all the files and directories that relate to a single unit of work.

The EAR project corresponds to an Enterprise Application. You can build and deploy this project to create the entire process flow of the enterprise.

The Web project corresponds to the Web application of Worklist that acts as the user interface for the system. The Web project is a part of the EAR project.

To create a new Worklist application:

  1. In the Oracle Workshop for WebLogic IDE, click File > New > Project.
  2. The New Project dialog appears.

  3. Click Workspace Launcher next to WebLogic Integration and select Worklist Application (see Figure 2-6).
  4. Figure 2-6 New Worklist Project


    New Worklist Project

  5. Click Next.
  6. The New Worklist Application dialog appears (see Figure 2-7).

    Figure 2-7 New Worklist Application Dialog Box


    New Worklist Application Dialog Box

  7. Select the Worklist application type. For more information, see Worklist Application.
  8. Specify the name of the EAR project.
  9. Specify the name of the Web project.
  10. If required, select the Create Utility Project check box and specify the Utility project name. This project will contain all the Oracle WebLogic Integration schemas.
  11. Select the Add WebLogic Integration System and Control schemas in utility project check box, this will create the WorklistEvent filter.
  12. Click Finish.
  13. If Task Plan perspective is not the current perspective, the Open Associated Perspective dialog appears (see Figure 2-8).

    Figure 2-8 Open Associated Perspective? Confirmation Box


    Open Associated Perspective? Confirmation Box

  14. Select the Remember my decision check box and click Yes.
  15. The Worklist application is created. In the Package Explorer pane, three project folders (one folder each for the EAR project, Web project and the Utility project) are automatically created and displayed.

The Task Plan perspective is now associated with the Worklist application. The Open Associated Perspective? Confirmation Box Task Plan icon appears on the top right corner of the Oracle Workshop for WebLogic window.

 


Creating a Task Plan

To create a task plan
  1. In the Package Explorer pane, right-click the <EAR project folder name>\EarContent folder, and select New > Folder.
  2. The New Folder dialog appears.

  3. Enter a folder name for the task plan and click Finish.
  4. This task plan folder is created under the <EAR project folder name>\EarContent folder.

  5. Select the task plan folder and press Ctrl+N.
  6. The New dialog appears.

  7. Click Open Associated Perspective? Confirmation Box next to WebLogic Integration and select Task Plan.
  8. Click Next.
  9. The New Task Plan dialog appears (see Figure 2-9).

    Figure 2-9 New Task File Dialog


    New Task File Dialog

  10. Specify the path to the task plan folder in the Container field.
  11. Enter the name of the task plan.
  12. Click Finish to proceed.

The task plan is created and opens in console where you can define the steps and actions for the task. Task plan files (.task files) are placed directly in a WebLogic EAR project under its Content folder. This folder name can vary depending on the project's configuration, but is generally named EARContent.

To create a task plan to a Process Application
  1. Create a Process Application.
  2. Add Worklist facets to your Process Application by selecting Project > Properties > Project Facets, from the Oracle Workshop for WebLogic menu (see Figure 2-10).
  3. Figure 2-10 Project Facets


    Project Facets

  4. Click Project Facets.
  5. The Project Facets dialog appears.

  6. Check the AquaLogic Core Facet and WebLologic Integration Worklist Application Module check box under Project Facet to enable Worklist facet (see Figure 2-11).
  7. Figure 2-11 Project Facets


    Project Facets

  8. Click Finsh.
  9. Click Ok.
  10. The facets are added to your project.

  11. Complete the Steps in Creating a Task Plan.

Adding Steps and Actions to a Task Plan

A task plan is a collection of steps that define the actions a user needs to do when working on a task. To add steps and actions to a task plan:

  1. Double-click on the task plan file (*.task file) to add the steps.
  2. From the Palette View, click Step and then drag and drop it anywhere in the <taskname>.task tab.
  3. The default name for a new step is Step#, where # is an incremental numeric value that starts with 1 and changes depending on the number of existing steps in the task plan.

  4. Select the step to set its system properties in the Properties View. For more information, see Setting the System Properties of a Step.
  5. Repeat step 2 and step 3 to define the required number of steps to your task plan.
  6. From the Palette View, click Action and then drag and drop it into a step.
  7. The default name for a new action is Action#, where # is an incremental numeric value that starts with 1 and changes depending on the number of existing actions in the step.

  8. Select the action to set its system properties in the Properties View. For more information, see Setting the System Properties of an Action.
  9. Note: If required, you can create user properties for the task plan and define these user properties for any of the actions. For more information, see Creating User Properties of the Task Plan.
  10. Repeat step 5 and step 6 to define the required number of actions to your step.
  11. Repeat step 5 and step 6 to define all the actions for all the steps in the task plan.
  12. Select Abort Step and Complete Step options in the Palette View and place then anywhere in the task plan tab.
  13. Click Connections in the Palette View and click the source action that you want to connect to the target step or action. Press and hold the Mouse and point to the target step or action. You will see a line that originates from the source action. Release the Mouse cursor at the target step or action. The source and target are not joined by the connecting line.
  14. After specifying the connection, a green tick appears against the source Action as shown in the following figures. Connecting an action to another step or action specifies the order in which steps and actions in the task plan should be executed (see Figure 2-12).

    Figure 2-12 Connecting a Source Action to a Target Action


    Connecting a Source Action to a Target Action

    Note: You can also use self-transition to ensure that after the current action is complete, the actions returns to the step. In Figure 2-12, after Action 3 in Step 1 is completed, control returns to Step1. Double-click an Action to enable self-transition.
  15. Repeat step 10 to connect all the actions in the task plan.
  16. Save the task plan.

All Steps and actions are added to the task plan. You need to define a constructor for the task plan.

Defining a Constructor for the Task Plan

In a task plan, there is at least one constructor that defines how a task instance comes into existence. A constructor for a task plan lists the initial data to be provided for the creation of a task instance as well as the resulting step of the task instance. Each constructor needs to have a step associated with it. There may be more than one constructor for a task plan.

Note: Constructors can be invoked by authorized users or system actors, so that the task instances can be created either by human data entry or system execution in a process.

To define a constructor:

  1. Click Constructor on the Palette tab and drop it in the Constructor container of the task plan tab.
  2. Specify the system properties for the constructor. For more information, see Setting the System Properties of an Action.
  3. If required, specify any user properties defined for the task plan. For more information, see Creating User Properties of the Task Plan.
  4. Click Connection in the Palette View to connect the Constructor to the required step in the task plan (see Figure 2-13).
  5. Figure 2-13 Task Plan


    Task Plan

You can also view the task plan in the Outline View (see Figure 2-14).

Figure 2-14 Task Plan in Outline View

Task Plan in Outline View

Setting the System Properties of a Step

You can set any of the following properties for a step:

Assignment Instructions

Steps define assignment instructions to control who can claim instances of its parent task plan, when those instances are on this step. At any given time, a task instance may be claimed by at most one human actor. Thus, the assignment instructions for the current step (if present) effectively become the assignment instructions for the whole task instance.

The actor that claims a task instance is called the 'claimant' for the task instance. This actor may be designated by name, by group or by role. A human actor must be either one of the named actors, or belong to one of the named groups, or be granted the named role, in order to claim the step.

To set the system properties of a step, do any of the following:

  1. To assign the current step to any existing user or group, select Assignment Instructions and click System Properties of a Step in the Value column. The Assignment Instructions dialog appears.
    1. Click Add and enter the user or group name in the Name column.
    2. In the Type column, select User or Group.
    3. In the Candidate List Handling field, select the type of handling to be applied while assigning the step to the specified users or groups. For more information about candidate list handling, see Creating a Task Plan.
    4. Select or clear the Enable Avail Checking check box only when you select Load_Balancing as the Candidate List Handling method for the step.
    5. Click OK. The specified user or group is assigned to the current step in the task based on the candidates associated with the step will be handled.
    6. Figure 2-16 Assignment Instructions


      Assignment Instructions

  2. Select Completion Due Date and click Assignment Instructions. The Completion Due Date dialog appears.
    1. Enter the number of days, hours, and minutes required to complete the current step in the task.
    2. Specify a calendar to associate a business calendar with the due date. The number of days required to complete the days is calculated based on the number of free and busy days in the calendar.
    3. Select a user name to use the calendar associated with user to calculate the due date.
    4. Click OK.
    5. The interval may define a number of days, hours and/or minutes in the D days H hours M minutes format, where D is number of days, H is number of hours, and M is number of minutes. The completion due date of the task is generated based on the interval, and the user or business calendar.

      Figure 2-17 Completion Due Date for the Step


      Completion Due Date for the Step

  3. Select Description and click Completion Due Date for the Step. The Description dialog appears (see Figure 2-18).
    1. Enter a brief description for the step.
    2. Click OK.
    3. Figure 2-18 Step Description


      Step Description

  4. Select Name and enter a meaningful name for the step.
  5. Select Return Step and select True or False. If True, the task is returned, thus returning it to the Assigned Working state so that it may be claimed by a different user at a later date.
  6. Select Time Estimate and click Step Description. The Time Estimate dialog appears.
    1. Estimate the days, hours and minutes required to complete the step.
    2. Click OK.
    3. Figure 2-19 Time Estimated for the Step


      Time Estimated for the Step

The system properties are now set. If required, click the Time Estimated for the Step icon to restore the default system properties for the step. You can restore to the default values only if you did not save the task plan.

Setting the System Properties of an Action

You can set the following system properties for any action:

Table 2-6 System Properties of an Action
Property Name
Description
Name
Name of the action.
Description
A brief description of the action.
Next Step
The next step that should be done after completing the current action.
Current Step Claim Due Date
The date by which the current step should be claimed by any user.
Current Step Completion Due Date
The date by which the current step should be completed.
Is Owner Group
When set to true implies that the value specified in the Owner property refers to a group.
Owner
The owner of the task.
Priority
The priority of the task. This is an integer value that, if specified, conditionally enables the use of user availability information when performing load balancing during task assignment. Availability checking is performed only for those task instances that have a Priority value greater than or equal to the given threshold value.
Step Time Estimates
The estimated time (specified as a business calendar interval, for example, 3min2hour1day or 10 years 5 hours 3 seconds) required to complete the current step in the task. This information is used by the default Worklist assignment handler for load balancing. If specified, this value is used as a default value for the time estimate setting on the current step in this task.
Task Completion Due Date
The business date and time by which this task must be completed. This is specified as a time interval, and an optional business calendar name. If there is no business calendar name given, the Worklist global system calendar will be used in the date calculation. The business calendar is used to calculate the absolute date by which the task must be completed.
The interval may define a number of days, hours and/or minutes in the D days H hours M minutes format, where D is number of days, H is number of hours, and M is number of minutes.
The completion due date of the task is generated based on the interval, and the user or business calendar. For example, if the interval is specified as 10 days and the business calendar is selected. If current date is 1, and the next 5 days are busy based on selected business calendar, then the completed due date for the task would be 15.
Task Name
Name of the task.
Task Time Estimate
The estimated time (specified as a business calendar interval, for example, 3min2hour1day or 10 years 5 hours 3 seconds) required to complete the task. This information is used by the default Worklist assignment handler for load balancing. If specified, this value is used as a default value for the time estimate setting on all the steps this task contains.

Creating User Properties of the Task Plan

User properties are business-specific data elements of a task plan. User properties are global and apply to all the steps throughout the life cycle of the task plan. In WLI, Enumeration (List) Data type user properties is available to task properties.

To create user properties:

  1. From the User Properties View, click the Create user property icon (see Figure 2-20).
  2. Figure 2-20 User Properties Tab


    User Properties Tab

    The Create User Property dialog appears (see Figure 2-21).

    Figure 2-21 Create User Properties for Task Plan


    Create User Properties for Task Plan

  3. Enter the name and description of the user property.
  4. Select the data type of the user property from the Type drop-down list.
  5. The data type can be Boolean, DateTime, Float, Integer, JavaBean, String, URL,List,or XMLBean. If you select DateTime, JavaBean, or XMLBean in the VariantInfo field, enter the format in which the property should be specified. For example, mm/dd/yyyy ‘at’ hh:mm:ss can be the date and time format.

    For creating List data type, the information entered in the Enum Values field should be separated by a (,) (see Figure 2-22). For example: yes, no, neutral, no comments. Once the user property of this type is created , the default value edited in the Properties view for List data type will have similar behavior of other data types.

    Figure 2-22 Create User Property (List Data Type)


    Create User Property (List Data Type)

  6. If required, enter the default value of the user property.
  7. Click OK.

The user property is created.

 


Validating a Task Plan

The final stage in designing and deploying the task plan is to validate if the task plan is working according to the required enterprise model specification.

Note: For the task plan to be deployed successfully, version of the task plan should be 1.0. Verify that the task plan version in the Properties View is 1.0.

To validate the task plan:

  1. Click Worklist > Validate Task Plan for Runtime.
  2. If the task plan is valid, then the Validation Results dialog appears as shown in the following figure.
  3. If the task plan is invalid, the error details are displayed in the Validation Results dialog (see Figure 2-23). Fix the errors and re-validate the task plan.

    Figure 2-23 Validate Task Plan


    Validate Task Plan

  4. Click OK to confirm.
  5. Select FileArrow symbolSave All to save the application.

If required, you can modify the layout of the task plan by selecting Worklist Arrow symbol Automatic Layout.

 


Importing a Task Plan

To import an existing task plan into the current workspace:

  1. In Oracle Workshop for WebLogic, select FileArrow symbol> Import.
  2. The Import dialog appears.

  3. Under Select an import source, expand General and select Existing Projects into Workspace as the import source and click Next.
  4. The Import Projects dialog appears.

  5. Specify the root directory in which the project is located.
  6. Select the projects that you want to import.
  7. Click Finish.

The task plan is imported into the current workspace.

Note: In the Import dialog, you can also select File System as import source. The File System dialog appears. Specify the path to the task plan, select the projects that you want to import, specify the parent folder into which you want to import the file system. Click Finish to import the task plan.

 


Deploying a Task Plan

Once the task plan is modeled completely, you can deploy it on Oracle WebLogic Integration Server.

To deploy the task plan:

  1. In the Package Explorer View, right-click on the <web project name> folder and select Run As Arrow symbolRun on Server. The Run on Server dialog appears.
  2. Specify the server on which you want to deploy the task plan. You can choose an existing server or manually define a new server. For more information about defining a server, see Configuring a Server.
  3. To choose an existing server, from the Select the server that you want to use: list, select the server on which you want to deploy the task plan and click Next. The Add and Remove Projects dialog appears.
  4. Select the project in the Available projects list and click Add. The selected project is listed in the Configured projects list.
  5. Figure 2-24 Add or Remove Projects Configured on the Server


    Add or Remove Projects Configured on the Server

  6. Click Next. The Select Tasks dialog appears.
  7. Click Finish.

The selected project is deployed on the specified server.

It will take some time to deploy the project on the server. After the task plan is deployed successfully, it opens up on the Worklist User Portal within the Oracle Workshop for WebLogic environment.

 


Changing a Task Plan

You can change a task plan as and when required. Make sure that you re-deploy the task plan after you change the task plan.

To change a task plan:

  1. From Package Explorer, navigate to the location of the task plan.
  2. Right-click on the task plan and select Open With > Task Plan Editor.
  3. Make the required changes and save the task plan. For more information, see Creating a Task Plan.

The task plan is changed.

Note: After you update the task plan, re-deploy the task plan. For more information, see Deploying a Task Plan. The updated changes are only reflected in task instances that you created after you re-deployed the task plan.

  Back to Top       Previous  Next