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

About Worklist

WebLogic Integration Worklist provides mechanisms to interact with human actors from WebLogic platform applications. Worklist is intended to complement BEA WebLogic Integration Java Process Definition (JPD) component. JPD is intended to handle automated business processes and does not directly concern itself with the nuances of human interaction. Worklist extends the reach of the JPD component to include human actors where required.

JPD and Worklist components available with WebLogic Integration enables integration of diverse systems, applications, and human participants. Worklist enables human interaction, via the capability of assigning tasks to human users, with business processes. Based on the assigned task, human users can perform actions on the tasks, which can trigger new task assignments to other users or system events. This process flow depends on the higher level business processes.

Worklist may also be used in a stand-alone fashion. In this case, the Worklist User Portal becomes the primary interface for the user into Worklist. Worklist manages tasks and updates them as human users complete the steps needed to complete them.

Worklist enables modeling of task flow via a task plan. The main features of Worklist are:

A task plan can include one or more 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. Actions include "work actions" that have 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 defined steps in a manner dictated by the actions taken on the task.

Tasks can be assigned to and claimed by a human actor, and can maintain a number of system and user-defined properties representing data for the task. Human actors specify and alter properties (both user and system) as the steps in a task are completed.

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

 


Key Terms in Worklist

Term
Definition
Task
Represents a unit of work requiring one or more human actors to assist in its completion.
Task Plan
A description of the steps, properties, task assignment rules, and so on that are common to a class of tasks for a given purpose. For more information, see Creating and Managing Worklist Task Plans.
Task Plan Host Application
An application that hosts or deploys task plan modules and uses Worklist via a Worklist system instance. In most cases, a Worklist application is also a task plan host application.
Task Plan Path
A hierarchical name representing a task plan's location in the abstract file system for the task plan registry being used by a Worklist system instance. This path is of the form /Folder1/Folder2/.../FolderN/TaskPlanFileName (minus .task extension) and is derived from the location of the .task file in task plan host application, relative to the application's root folder.
Task Instance
A task instance created from a task plan. For more information, see "Creating a Task Instance" in Worklist User Portal in Using Worklist User Portal.
Step
A phase in the overall completion of a task. The steps for a task are defined by the task plan for the task. Task assignment can occur at any step in a task. For more information, see Steps.
Action
A discrete operation that can alter the properties or working state of a task. Some actions (work actions) cause a transition to another step defined for the task (can be to the same or current step), whereas others (assign, return actions) simply change the working state of the task. For more information, see Actions and Connections.
User Property
A named or typed data value associated with a task plan. A task plan may have any number of properties to hold data that is required to define the state of a task. All steps in a task plan share access to the same set of user properties. For more information, see User Properties.
System Property
A named or typed data value defined by Worklist for all tasks. Some system properties can be edited while others cannot be edited. For more information, see System Properties.
Assignee
A human actor or group of actors that have been designated as candidates to work on a task or tasks of a given task plan.
Claimant
A single human actor who has assumed responsibility for completing a step for a given task. An user with sufficient privileges can claim a task on behalf of another user from Worklist Console. For more information, see "Claiming a Task for a User" in Worklist Administration in Using Worklist Console.
Administrative State
A value that describes how the Worklist system is currently treating the task instance. Active tasks are allowed to operate normally, whereas suspended tasks cannot be interacted with (except to resume them). Tasks in an error state can be interacted with in a limited way, or have their error state cleared. For more information, see Administrative and Working States.
Working State
A value describing the current association of a task with human actors who can work on the task. Working state can be "Unassigned", "Assigned", or "Claimed". For more information, see Administrative and Working States.
Worklist Application
An application that makes use of Worklist via a Worklist system instance. In most cases, a Worklist application hosts its own Worklist system instance, its own task plans, and its own Worklist user portals. In this case, the Worklist application is called a stand-alone Worklist application. For more information, see Worklist Application.
Stand-alone Worklist Application
A 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. This is the most common type of application for Worklist, and the type of application that Worklist documentation advocates using in most cases.
Worklist Host Application
An application that hosts a Worklist system instance. In most cases, a Worklist application is also a Worklist host application.
Worklist Portal Host Application
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.
Worklist System Instance
An instance of the Worklist API and its implementation. A Worklist system instance is configured to connect to a database instance hosting the Worklist system tables. The tasks being managed by a Worklist system instance are the tasks contained in the database instance. In addition, a Worklist system instance can be configured with its own security policies, runtime configuration, and so on.
Worklist Portal Instance
An instance of the Worklist user portal. This is a web application that present a WebLogic Portal user interface for interacting with a Worklist system instance and the tasks it is managing.

 


Worklist Scenario

In Worklist, a task plan can be modeled using the Workshop for WebLogic design-time environment and then be deployed to run on the server. Once the task plan is deployed, the task instances can be created either by authorized systems or human entities using Worklist Console. Task Instances or tasks are based on the task plan and actions performed by employees or the system.

Worklist User Portal provides facilities for Worklist users (not administrators/designers) and allows them to see the tasks assigned to them or the groups they belong to. Worklist User Portal allows users to claim tasks, take actions on them, and alter their properties.

The various stages in a typical Worklist scenario are:

  1. Designers create a task plan using the design-time environment.
  2. To address your business specific scenario using Worklist, the first step is to design the tasks required by your organization and then use the Task Plan Editor to create and edit task plans. The Task Plan Editor gives a graphical representation of the steps and actions designed for the task. Since task plans are XML documents, you can also view the task plan details by opening it with the XML Editor or the Text Editor in the Workshop for WebLogic Platform IDE.

    The Task Plan Editor provides a drag-and-drop editor for defining the steps of a task plan, and then defining the properties of individual steps and actions in that model. In addition, other Views in the Task Plan perspective are provided that allow you to edit the task plan configuration. For more information, see About Perspectives.

    After defining the task plan (.task file) using the Task Plan Editor, deploy it to the server in order to use it.

    For more information, see Creating and Managing Worklist Task Plans.

  3. Authorized entities create a task instance of the task plan using the Worklist User Portal. For more information, see Using and Customizing User Portal.
  4. Users work on tasks associated with them from
    • Worklist User Portal or a custom Task user interface (if a custom UI is developed for a step in the task plan or the entire task plan).
    • Worklist User Portal allows users to see the tasks assigned to them, claim tasks, take actions on tasks, and update the worklist properties (values) associated with the actions they perform. Worklist User Portal is used by Worklist users, not administrators or designers.

      If Worklist User Portal does not meet the needs of a given task plan, a custom task user interface can be designed and developed by a Developer and associated with the entire task plan or just a step in the task plan. This ensures that the required user interface can be designed without forcing the implementation of a completely new web user interface. For more information, see Customizing the Worklist User Portal in Using Worklist User Portal.

    • A JPD business process (using methods in Worklist Task or Task Batch control). For more information, see Using Worklist Controls.
  5. Authorized entities manage and monitor Worklist tasks, users, and the business calendar. Worklist Console provides a navigation menu containing several modules for performing focused operations. For more information, see Using Worklist Console.

For a sample Worklist scenario, see Tutorial: Building a Worklist Application

 


About Perspectives

The window layout in the Workshop for WebLogic Platform IDE is called a perspective and can be extensively customized. Perspectives are intended to provide related tools for performing specific tasks with specific resources. The initial perspective is called the Workshop perspective (shown in the upper right corner of the window). Several other useful perspectives are provided. You can switch perspectives at any time by choosing Window > Open Perspective.

The Workshop perspective is the standard perspective for developing Java Platform, Enterprise Edition (Java EE) Version 5 (Java EE) enterprise applications with Workshop for WebLogic. Note the Package Explorer view at the left which allows you to move through the projects/folders/files of your workspace.

Information panes (Views) in the workbench can be moved, torn off, displayed side by side, stacked, minimized or maximized. Each file displayed in the editor can be maximized or minimized to icons at the edge of the window (fast views). Menu bars and tool bars can be added, removed or customized.

You can create and save your own perspectives. Workshop for WebLogic will also change the perspective when you perform other tasks. For example, a different perspective is typically used when creating a page flow or creating task plans.

For more information about Eclipse IDE features, access the Workbench User Guide from the Online Help available from Workshop for WebLogic Platform IDE.

Selecting a Perspective

To select a perspective:

  1. Click the icon at the top right corner of the screen. The Select Perspective dialog appears.


  2. Select the perspective and click OK. Although, you can work in any required perspective, Task Plan, Process, and Page Flow are perspectives that are relevant to working with Worklist.

Task Plan Perspective

The Task Plan perspective contains the following Views:

Process Perspective

The Process perspective contains the following Views:

Page Flow Perspective

The Page Flow perspective contains the following Views:

For more information, see The Page Flow Perspective in Workshop for WebLogic Platform Programmer's Guide.


  Back to Top       Previous  Next