Using the Worklist
|
 |
 |
|
|
 |
 |
The BEA WebLogic Integration Worklist addresses the flow of work in an enterprise. It directs the routing of business-process tasks to personnel and provides management capabilities that enhance organizational efficiency and responsiveness.
This section includes the following topics:
The WebLogic Integration Worklist is commonly used for scenarios in which human activity combines with automated business processing over time. This time can be short or can continue for days or months. The Worklist is designed to direct the flow of work and manage the routing of tasks to the people in an enterprise. Inherent in the progression of work are actions such as receiving, approving, modifying, and routing of documents. The documents that accompany work activities provide the information necessary for people to perform and complete tasks. The Worklist enables people to collaborate in the accomplishment of work, including creating tasks, assigning tasks, tracking the status of tasks, handling approvals, and other activities required to manage workflow.
The Worklist user interface enables end users—task creators, task workers, task administrators—to interact with running business processes, including handling process exceptions, approvals, and status tracking. For managing the Worklist components of your applications, WebLogic Integration provides a sample Worklist user interface that you can use to help develop your user interfaces.
Important capabilities of the Worklist include the following:
The Worklist allows for the creation, manipulation, and management of Tasks. A Task instance represents a unit of work that requires completion within a certain time period. Examples of tasks include:
In the run-time Worklist system, a Task instance is a particular object that represents a work assignment in the real world. Task instances are part of the WebLogic Integration server and exist independently of any controls or business processes. Multiple business processes can interact with a Task throughout its lifecycle concurrently. Tasks remain in the run time indefinitely, either until they are explicitly deleted or purged by the WebLogic Integration purging process.
After the work is completed, you can use a Task instance to represent a detailed record of that unit of work.
To learn about controls, see Worklist Controls in the WebLogic Workshop Help.
Task Instances have built-in data values for defining how work should be performed, who should do it, by when it needs to be completed, and more. You can also use these data values to capture what actually was done when work is completed.
Examples of task data values include:
Due dates represent the date and time for which tasks should be claimed or completed. The Worklist stores Due Dates as java.util.Date objects, tracks them, and can trigger callbacks to business processes that are listening for the Task due dates. Due dates can be set using a specific date and time, or, they can be set using a business calendar and a business time duration.
Business calendars represent the operating hours of a business. A business calendar specifies a time zone and a set of time period rules. Time period rules determine the days, dates, and hours that are available (free) and unavailable (busy) for business activities.
To learn more about Task Due Dates and Business Calendars, see Task Due Dates.
The state of a Task describes the point at which the task is in its lifecycle. Each task instance is in one of the following states: ASSIGNED, CLAIMED, STARTED, COMPLETED, SUSPENDED, or ABORTED. Operations on the controls or the API allow you to cause an instance to transition from its current state to another state.
To learn about Task States, see Task Due Dates.
To signify a user or a group of users that play a managerial role with respect to this task, a Task Instance can have a Task Owner. The owner manages the task and is the person responsible for getting the Task completed, but not necessarily the person who actually completes the Task. For example, the manager of a café can be the owner of a Task assigned to a chef to prepare a recently ordered dish. The manager takes responsibility if the Task does not get done.
The permission to perform certain managerial operations on a Task instance can be restricted to only the Task Owner or to an administrator.
To learn more about Task Owners, see Task Users and Groups and Tasks and User Permissions.
A Task Instance has a list of assignees to specify which users can claim the task. The Assignees List can contain both users and groups. When a user on the Assignees List claims the task, that user become the claimant. The claimant takes ownership of the task, and performs the work needed to complete the task. The State of the Task is set to Claimed when a user claims the Task.
To learn more about the Assignees List and claimants, see Task Users and Groups and Tasks and User Permissions.
Generally, the Task Request is used to specify what work is done and how the work is done. This value can be read by the task worker who performs the work and completes the task. In addition, assignees can view this information to decide whether or not to claim the task.
The Task Response is generally used to specify what actually took place after a user has worked on the task. It can describe the results of the work, that is what specific actions were performed to complete a task. Callbacks can pass the Response value to business processes that are waiting for a particular task state.
For example, the Task Response can capture the agreement made between a Collections Agent and a delinquent customer after they complete a phone conversation. The process that created the Task to call that customer can use those results to determine what should be done next.
To learn more about request and response documents, see Request and Response Documents.
Operations are used to create new tasks, alter task states or data values, delete tasks, or read information about an existing task. Some operations allow combinations of these actions in a single step. Examples of Task operations include:
When a new Task Instance is created, the Worklist system assigns a unique ID (a taskID) to that instance. The Task state can be defined at creation time as Assigned or Claimed, depending on the operation. Certain Task data values are specified at the time an instance of a Task is created and cannot be changed after the instance is created.
You can use get task operations to access the properties of any Task Instance at any point in its lifecycle.
To learn about the operations on Task and Task Worker controls, see Using Worklist Controls.
WebLogic Integration supports the recording of tracking data for business-process instance history, trading-partner message history, and task instance history.
As tasks go through their lifecycle in enterprise processes, their properties are modified, their states change, their due dates expire, and so forth. Worklist task instances generate events that can be logged in Worklist history tables in the run-time repository. The records created in the history tables are intended for use by reporting applications. Those applications can query the tables to generate reports or statistical analyses of historical task processing. The following types of events can be tracked:
To optimize performance, the amount of tracking data stored in the run-time database should be kept to a minimum. To help ensure this, the tracking and purge process can be configured to run at regular intervals by an administrator. Additionally, the reporting data policy for a process can be set to on or off. If on, the data is transmitted to the reporting database if the reporting data stream is enabled; if off, the data is not transmitted to the reporting database.
Stored information can be used for generating reports and compiling statistics about task processing in your WebLogic Integration application. To learn more about configuring your application for tracking and purging Task data, see System Configuration in Managing WebLogic Integration Solutions.
Stored information can be used for generating reports and compiling statistics about task processing in your WebLogic Integration application. To learn more about tracking and purging Task data, see System Configuration in Managing WebLogic Integration Solutions.
Task Queries allow an application to find all tasks in the run-time Worklist system that meet a specified set of criteria. These queries are directly analogous to SQL and Databases Tables. The results returned by the queries contain information about all tasks that meet the specified criteria.
For example, you can create a custom user-interface to show all tasks in the system that are assigned to the current user, have a priority equal to one, and are due in the next three days.
The Worklist API provides operations to leverage all of the functionality available in the Worklist for creating and operating tasks. WebLogic Integration provides two controls to support the Worklist system: the Task control and the Task Worker control. Although the Task and Task Worker controls provide a subset of the available functionality in the API, they provide the convenience of the WebLogic Workshop controls framework and you can easily use them in your business processes.
The Worklist controls are server-side components managed by the Workshop framework. They expose Java interfaces that can be invoked directly from your business processes. The Task control enables a business process to create a single Task instance, manage its state and data, and provide callback methods that report status. The Task Worker control allows specified users to acquire ownership of Tasks, work on the task, and complete the task. This control also provides administrative privileges, such as starting, stopping, deleting, and assigning of tasks. Access to the Task Worker control can be done through a business process or a user interface.
In an office environment, managers usually create, specify, and monitor the work that is done. The Task control is designed to provide the common operations required by the manager of a work item, such as creating the work, assigning the work, and receiving notifications when work completes or becomes overdue for completion. The most common usage of the Task Control is in business processes.
The Task Worker control is designed to provide the most common operations needed by the people who receive assignments and perform the work. For example, workers can query for their assigned tasks that are due before the end of the week. The Task Worker control allows workers to mark ownership of a task (that is, claim the task) and mark its completion. In addition, the Task Worker control has operations of an administrative nature, such as claiming a task on another user's behalf. The Task Worker control is most commonly used in the implementation of a custom Worklist user interface.
Task Controls can notify a process when a Task's state changes. Common callbacks include the expiration of a completion due date, aborting the task, or task completion. Callbacks allow processes to block within their logic, effectively waiting until that event takes place.
Controls methods are the mechanism by which a business process or a user interface creates new tasks, reads or alters the task data values, reads the current state, causes a transition to a new state, or deletes a task instance.
Task and Task Worker controls have a built-in set of methods and callbacks. Controls are extensible through Java annotations. For example, you can define custom operations with custom signatures and custom callbacks for your controls. Through the annotations on these methods, you can configure a control's data values, create new tasks, update existing tasks, and so forth. You can also extend controls in the following ways:
Using the Worklist Administration module in the WebLogic Integration Administration Console, you can administer and manage the tasks in the Worklist, business calendars, task properties, and other features. With Worklist controls and the Worklist API, you can create a custom Worklist client. The Worklist API is available as Enterprise JavaBeans (EJBs) and MBeans. These topics are discussed more fully in the following sections:
The Worklist Administration module in the WebLogic Integration Administration Console allows application administrators to administer and monitor the task instances in your WebLogic Integration application. The Worklist-specific administration and management functions you can perform include:
To learn more about managing your Worklist Tasks, see Worklist Administration in Managing WebLogic Integration Solutions.
Worklist user interfaces enable end users—task creators, task workers, task administrators—to interact with running business processes, including handling process exceptions, approvals, and status tracking. Typically, in real-world applications, people interact with tasks that require custom user-interfaces. For example, you could add a page to an existing order fulfillment user interface on a company's intranet that allows a manager to approve very large orders.
WebLogic Integration contains a sample Worklist user interface. This sample interface provides basic out-of-the-box functionality for inspecting and updating tasks.
The WorklistScrollableResultManager Interface allows you to query Worklist tasks. This interface allows client applications, especially user interface (UI) applications, to retrieve a specified number of records rather than returning all query results. This improves scalability and performance for querying operations. For an example of using the WorklistScrollableResultManager, see "Use Case 2" in the Worklist Sample in the Solution Samples.
To learn more about Worklist user interfaces, see Worklist User Interface and Enterprise JavaBeans API.
With the EJB API, you can use the Worklist EJB to create and manage tasks independent of the business processes (JPD) created in WebLogic Workshop. Code samples are included in Worklist User Interface and Enterprise JavaBeans API.
|
|
|