チュートリアル : Worklist アプリケーションの構築

WebLogic Integration の BPM (Business Process Management) 機能は、さまざまなアプリケーションと参加者の統合を可能にします。WebLogic Integration の Worklist システムによって、参加者はタスクの割り当て、タスクステータスの追跡、承認処理などのビジネスプロセスで共同作業できるようになります。

このチュートリアルでは、WebLogic Workshop のグラフィカルな設計環境で参加者とビジネスプロセスの対話を設計するために用意された機能を順を追って説明します。具体的には、あるソフトウェア会社のバグ追跡システムでのバグの解決をワークリストコントロールを使用して組織化するビジネスプロセスを作成する方法について説明します。

注意 : このドキュメントは、WebLogic Workshop でのビジネスプロセスの構築に関する知識があることを前提としています。その知識を習得するために、このチュートリアルの前に、WebLogic Workshop オンラインヘルプシステムで以下のチュートリアルを実行することができます。

チュートリアルの概要

このチュートリアルのシナリオは、SoftCo という架空のソフトウェア会社におけるソフトウェアバグのライフサイクルの一部分に基づいています。次に示す図と一連のイベントは、このシナリオにおける SoftCo 社でのソフトウェアバグの経路および関係者の概略を示しています。

品質保証エンジニアはバグレポートを作成します。その場合このエンジニアは、バグのタイトル、説明、優先度 (1、2、または 3)、およびバグを再現する手順をオンラインフォームに指定します。

新しいバグは、キュー内のバグが最も少ないリリース管理者に割り当てられます。SoftCo 社の方針として、リリース管理者は 2 営業日以内にバグレポートに対応する必要があります。

自分のキューにバグを受信したリリース管理者は、そのバグを拒否するか、開発エンジニアに渡すか、または次のリリースまで延期することができます。

拒否 — リリース管理者がバグを拒否する場合、その管理者は拒否の理由を記録したドキュメントを提出する必要があります。
延期 — 将来のリリースに延期されるバグは、次のリリースサイクルが始まる際にリリース管理者のキューに戻されます。
割り当て — バグが開発エンジニアのグループに割り当てられると、すべての開発エンジニアはバグを再調査し、適切であればバグを申告することができます。

開発エンジニアは、バグを拒否済みまたは修正済みとして解決することができます。

拒否 — 開発エンジニアは、再現できないバグや何らかの理由で修正する必要のないバグを拒否することができます。その場合、開発エンジニアは拒否の理由を記録したドキュメントを提出する必要があります。
修正 — 開発エンジニアはバグを修正することができます。その場合、修正の詳細をバグレポートに記録する必要があります。

バグが拒否済みまたは修正済みとして解決されると、バグを作成した品質保証 (QA) エンジニアはその解決を承認するか、反対する必要があります。バグ解決への対処は、2 営業日以内に行う必要があります。

反対 — QA エンジニアは、バグの解決に反対する場合にその理由を説明するドキュメントを提出する必要があります。反対されたバグは、最初にバグの検査を任命されたリリース管理者に戻されます。2 日以内に反対または承認されなかったバグの解決は、承認されたと見なされます。
承認 — QA エンジニアがバグの解決を承認した場合、そのバグにそれ以上のアクションは必要ありません。

リリース管理者は反対を拒否することができます。その場合、バグは永久的に解決されたことになります。

注意 : チームに期日を知らせるために、タスクの期日が過ぎると電子メールが送信されます。開発エンジニアからバグが申告されなければ、リリース管理者に電子メールが 2 営業日ごとに送信されます。開発エンジニアからバグが申告され、4 営業日以内に解決されなかった場合は、開発エンジニアに電子メールが 2 営業日ごとに送信されます。

ソフトウェアバグのステータスを記述する値の種類

NEW、NOT_REPRO、WILL_NOT_FIX、FIXED、POSTPONED、APPEALED、APPEAL_REJECTED

SoftCo 社の営業時間

SoftCo 社のエンジニアが勤務する時間は、月曜日から金曜日の午前 10 時～午後 8 時と、土曜日の午前 10 時～午後 2 時です。

SoftCo 社のユーザとグループ

SoftCo 社では、品質エンジニア、リリース管理者、開発エンジニアの各グループからチームが構成されます。各従業員は、これらのグループのいずれかに属しています。

このチュートリアルの手順

このチュートリアルの手順では、前節のライフサイクルの手順 4 および手順 5 で説明したように、解決対象のバグで始まるバグ追跡プロセスの一部分を、ワークリストコントロールを使って組織化するビジネスプロセスを作成する方法を説明します。

このシナリオでは、バグの解決を説明するドキュメントが開発エンジニアによって作成されます。このチュートリアルの手順に従って作成するビジネスプロセスは、このドキュメントを受け取るところから始まります。その後に、まずバグの解決を受け付ける、または拒否するタスクを、バグを作成した QA エンジニアに割り当てる必要があります。QA エンジニアがバグの解決について承認または反対すると、解決が承認または反対されたことを伝えるメッセージがビジネスプロセスからクライアントに送信され、ビジネスプロセスが終了します。

チュートリアルは次の手順で構成されます。

手順 1. 環境の設定

チュートリアルの関係者を設定する方法を学習します。関係者とは、作成する解決承認ビジネスプロセスで設計するタスクを実行するために必要なユーザとグループです。SoftCo 社のビジネスカレンダーを作成する手順も説明します。

手順 2. アプリケーションの作成

このチュートリアルで作成するファイルを保持する WebLogic Workshop アプリケーションを作成する方法を学習します。具体的には、開始アプリケーションを作成し、バグ追跡アプリケーションを構築する際に必要となる XML スキーマファイルを追加します。

手順 3. ビジネスプロセスの開始方法の設計

解決承認ビジネスプロセスの設計を開始します。具体的には、実行時にビジネスプロセスがどのように開始されるかを設計します。

手順 4. タスクの作成とユーザへの割り当て

SoftCo 社のバグ追跡システムでのバグの解決を承認するタスクの割り当てを組織化するビジネスプロセスの一部分を構築する方法を学習します。ビジネスプロセスでタスクコントロールを作成および使用する方法について説明します。

手順 5. タスク所有者からの解決承認の受信

タスクコントロールから返される可能性があるイベントを処理できるようにビジネスプロセスを設計する方法を学習します。

手順 6. 解決承認ビジネスプロセスの実行

作成したビジネスプロセスの機能を実行してテストします。WebLogic Workshop のブラウザベースのインタフェースを使って、ビジネスプロセスを開始します。また、ワークリストのユーザインタフェースを使って、バグの解決を承認するタスクに割り当てられた品質エンジニアとして作業します。