This section provides information about the following:
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:
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:
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:
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:
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.
When you design and develop the task plan, you can specify the following properties:
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.
|
|
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.
|
|
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 in Using Worklist Console.
|
|
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.
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 defines some system data types, and the system will support the addition of user-defined data types (plugged in by implementing an SPI layer for the new data type). The system data types are:
TaskMessage with MIME Type and Value (MIME Type can be changed dynamically, and value is interpreted according to the MIME Type).
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 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:
worklist-client.jar
file (WebLogic installation directory/weblogic92/integration/lib). Select the file and click Open. Now, your utility project should have access to Worklist API classes needed to write the plugin implementation.
There are three Worklist application types:
This is a standalone Worklist application that hosts its own Worklist system instance, its own task plans, and its own Worklist user and manager portals. By this definition, a stand-alone Worklist application is a Worklist host application, task plan host application, and Worklist portal host application. The simple client uses the Worklist API to interact with Worklist.
This is an application that hosts a Worklist system instance. In most cases, a Worklist application is also a Worklist host application. A Worklist system host defines task plans and uses the Worklist User Portal to interact with Worklist.
This is an application that hosts or deploys an instance of the Worklist portals. In most cases, a Worklist application is also a Worklist portal host application. Process hosts define WebLogic Integration processes and task plans and use Worklist controls to interact programmatically with Worklist and the User Portal to interact with Worklist for human actions.
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.
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 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 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 actions cause the task on which they are taken to be reassigned according to assignment instructions defined for the 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.
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 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.
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. |
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 Worklist Console, see "Assigning a Task to User or Group" in Worklist Administration in Using Worklist Console. 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:
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
Before you start using Worklist, make sure that you:
You may create a domain using the Configuration Wizard. For more information, see Creating a New WebLogic Domain in Creating WebLogic Domains Using the Configuration Wizard.
You need to configure a server on which you can deploy the worklist applications.
Note: | If a server is not configured, and if you try to start Worklist Console from Workshop for WebLogic Platform, you get the following error message: |
The Workshop for WebLogic Platform IDE is displayed.
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:
The Worklist application is created. In the Package Explorer View, three project folders (one folder each for the EAR project, Web project and the Utility project) are automatically created and displayed.
If Task Plan perspective is not the current perspective, the Open Associated Perspective dialog appears.
The Task Plan perspective is now associated with the Worklist application. The Task Plan icon appears on the top right corner of the Workshop for WebLogic Platform window.
<EAR project folder name>\EarContent
folder, and select New Folder. The New Folder dialog appears.
This task plan folder is created under the <EAR project folder name>\EarContent
folder.
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.
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:
*.task
file) to add the steps.
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.
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.
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. |
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.
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-6, after Action 3 in Step 1 is completed, control returns to Step1. Double-click an Action to enable self-transition. |
All Steps and actions are added to the task plan. You need to define 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. |
You can also view the task plan in the Outline View.
You can set any of the following properties for a step:
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:
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.
The system properties are now set. If required, click the 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.
You can set the following system properties for any action:
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.
The Create User Property dialog appears.
The data type can be Boolean, DateTime, Float, Integer, JavaBean, String, URL,
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.
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. |
If the task plan is invalid, the error details are displayed in the Validation Results dialog. Fix the errors and re-validate the task plan.
If required, you can modify the layout of the task plan by selecting Worklist Automatic Layout.
To import an existing task plan into the current workspace:
Existing Projects into Workspace
as the import source and click Next. The Import Projects dialog appears. 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. |
Once the task plan is modeled completely, you can deploy it on WebLogic Integration Server.
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 Workshop for WebLogic environment.
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.
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. |