Tutorial: Building a Worklist Application

WebLogic Integration's business process management (BPM) functionality enables the integration of diverse applications and human participants. The WebLogic Integration Worklist system enables people to collaborate in business processes—including assigning tasks, tracking the status of tasks, handling approvals, and so on.

This tutorial provides a tour of the features available to design the interaction of people with business processes in the WebLogic Workshop graphical design environment. It describes how to create a business process that uses Worklist controls to orchestrate the resolution of a bug in a software company's bug tracking system.

Note: This document assumes a familiarity with building business processes in WebLogic Workshop. Before taking this tutorial, you should complete the following tutorials in the WebLogic Workshop online help system:

Tutorial Overview

The tutorial scenario is based on a portion of the life cycle of a software bug at a fictitious software company named SoftCo. The following figure and sequence of events outlines the path of a software bug through the SoftCo organization and the actors in the scenario:

intro.html

A Quality Assurance engineer creates a bug report. To do so, they specify the following information in an online form: title of bug, description, a priority (1, 2, or 3), and the steps to reproduce the bug.

New bugs are assigned to a release manager with the fewest bugs in their queue. SoftCo policy states that the release manager must act on the bug report within two business days.

When a release manager receives a bug in their queue, they can reject it, pass it to the development engineers, or postpone to the next release:

Reject—If a release manager rejects a bug, they must provide documentation that records the reason for the rejection.
Postpone—Bugs that are postponed to a future release are reinstated to the release manager's queue when the next release cycle begins.
Assign—When a bug is assigned to the development engineers group, any development engineer can review the bug and claim it if it is appropriate to do so.

Development engineers can resolve a bug as rejected or fixed:

Reject—Development engineers can reject the bug if it cannot be reproduced or if for some other reason it will not be fixed. They must provide documentation that records the reason for the rejection.
Fix—Development engineers can fix the bug. They must record the details of the fix in the bug report.

When a bug is resolved as rejected or fixed, the Quality Assurance engineer who created the bug must either approve the resolution or appeal it. They must take action on the bug resolution within two business days.

Appeal—When a QA engineer appeals the resolution of a bug, they must provide documentation that describes the reason or reasons for the appeal. A bug that is appealed is routed back to the release manager who was originally assigned to review the bug. Bug resolutions that are not appealed or approved within two days are assumed approved.
Approve—When a QA engineer approves the resolution of a given bug, no further action is required for the bug.

Release managers can reject appeals, in which case the bug becomes permanently resolved.

Note: To keep the team apprised of due dates, tasks that become overdue cause emails to be sent. If a bug is not claimed by a developer engineer, the release manager receives an email every two business days. If a bug is claimed by a developer engineer, but is not resolved within four business days, the developer engineer receives an email every two business days.

Values That Describe the Status of Software Bugs Include

NEW, NOT_REPRO, WILL_NOT_FIX, FIXED, POSTPONED, APPEALED, APPEAL_REJECTED

SoftCo Business Hours

SoftCo engineers work Monday through Friday 10AM to 8PM, and on Saturdays from 10AM to 2PM.

SoftCo Users and Groups

The following groups compose the team at SoftCo company: Quality Engineers, Release Managers, Development Engineers. Each worker is a member of one of these groups.

Steps in This Tutorial

The steps in this tutorial describe how to create a business process that uses Worklist controls to orchestrate the part of the bug tracking process that starts with the bug being resolved, as described in steps 4 and 5 of the life cycle of the preceding section.

In this scenario, a document that describes the resolution of the bug is created by the developer engineer—the business process you create by following the steps in this tutorial starts when it receives this document. Subsequently, the task of accepting or rejecting the resolution of the bug must be assigned to the QA engineer who created the bug in the first place. The QA engineer either approves or appeals the resolution of the bug, the business process sends a message to the client indicating whether the resolution is approved or appealed, and the business process terminates.

The tutorial includes the following steps:

Step 1. Set Up Your Environment

Learn how to set up the actors in the tutorial. That is, learn how to set up the users and groups required to complete the tasks you design in the Resolution Approval business process that you create. You also learn how to create a business calendar for your SoftCo enterprise.

Step 2. Create Your Application

Learn how to create a WebLogic Workshop application that holds the files you create as you work through this tutorial. Specifically, you create the starting application, and add the XML Schema files that you need when building the bug tracking application.

Step 3. Design How to Start the Business Process

Begin the design of the Resolution Approval business process. Specifically, you design how the business process is started at run time.

Step 4. Create Task and Assign to User

Learn how to build the part of the business process that orchestrates the assignment of the task of approving the resolution of a bug in the SoftCo bug tracking system. Learn to create and use Task controls in the business process.

Step 5. Receive Resolution Approval From the Task Owner

Learn how to design the business process to handle the possible events returned by the Task control.

Step 6. Run the Resolution Approval Business Process

Run and test the functionality of the business process you created. You use the WebLogic Workshop's browser-based interface to start the business process and the Worklist user interface to play the role of a quality engineer assigned to the task of approving the resolution of the bug.