|
|
ワークフローガイド |
この章では、サンプルワークフローアプリケーション(Issue Tracking)のインタラクティブデモを示し、アプリケーションソースを確認します。 この章は、次の節から構成されています。
既存のDirector EARプロジェクトがWorkbenchにあるか、または、このようなプロジェクトの作成および配備方法を習得している。 ヘルプが必要な場合は、『お使いになる前に』の節「 クイックスタート」を参照してください。
ワークフローの一般的な概要については、
第2章「基本的なワークフロー開発」を参照してください。
Issue Trackingは、ソフトウェア開発プロジェクトのバグ追跡システムをシミュレートするサンプルワークフローアプリケーションです。 このアプリケーションは、support、dev、およびqaという3人の認証されたユーザに関連付けられている、問題の作成および解決プロセスから構成されています。 問題のライフサイクルは、各ユーザに対してアクティビティを指定するワークフロープロセス内で定義されています。 各アクティビティは、ユーザが完了する特定のワークアイテム(この場合は、プロパティシート)に関連付けられています。
アプリケーションのしくみ supportユーザは、新しいプロセスを開始し、最初のワークアイテムを完了します。 ワークアイテムは、ユーザが問題を説明し、問題がバグであるかどうかを示し、それを次のアクティビティに転送するフォームから構成されています。 バグプロパティのステータスは、次のワークアイテムを決定します。 バグである場合は、devユーザのワークアイテムキューに移動し、バグでない場合は、supportユーザのキューに戻ります。 devユーザがバグを修正済みとしてマークし、作業を転送した場合、新しいワークアイテムがqaユーザのキューに追加されます。 qaユーザが修正箇所を確認すると、問題は解決済みとみなされ、プロセスインスタンスは完了します。
各ユーザには、各問題に対して単一のワークアイテムがありますが、複数の問題が同時に実行される場合もあります。 ワークフローエンジンでは、各プロセスインスタンスに対するアクティビティのルーティングを管理します。 複数のインスタンスがある場合、ユーザは、ワークアイテムキューからアクセスするワークアイテムを選択できます。
Issue Trackingは、WAR (Web Archive)としてパッケージ化されています。 Workbenchを使用すると、EARプロジェクトを作成し、Issue Trackingをサブプロジェクトとして追加できます。
EARプロジェクトの作成 EARウィザードを使用して、最初に新しいEARプロジェクトを作成する必要があります。 使用するセットアップオプションは、Typicalです。
注記: 新しいEARを作成し、既存のプロジェクトは使用しないことが推奨されます。これは、アプリケーションを実行するために必要なサポート機能が既存のプロジェクトには含まれていない可能性があるためです。
Director EARプロジェクトを作成する場合にヘルプが必要な場合は、『お使いになる前に』の節「
クイックスタート」を参照してください。
次のパネルで、DirectorインストールのIssue Trackingテンプレートに移動します。
Director_install_dir/Samples
［Next］をクリックします。 Samplesテンプレートを使用するかどうかを尋ねるポップアップが表示されたら、［Yes］をクリックします。
次のパネルで、［Issue Tracking］を選択します。
インストールにより、セキュリティサブシステムとワークフローサブシステムのIssue Trackingリソースセットを使用するようにプロジェクトが設定されることがメッセージで通知されます。 アプリケーションでの作業が完了したら、ワークフローサービスとセキュリティサービスのconfig.xml記述子を編集し、EARを配備することによって、設定を元の設定に変更し直すことができます。
詳細については、『コア開発ガイド』の
リソースセットへのサブシステムのバインドに関する節を参照してください。
Workbenchでは、Issue Tracking WARをEARプロジェクトに追加し、作成したものを実行します。 これには、数分かかる場合があります。終了すると、ナビゲーションペインの下部にIssueTrackingSampleが表示されます。
Issue Trackingアプリケーションは、アプリケーションサーバでエンジンを自動的に起動するように設定されています。 ここでは、設定について確認します。
［Service Entries］リストで、［Engine］をクリックします。
［Startup］ドロップダウンでは、［automatic］がデフォルトで選択されている必要があります。 選択されていない場合は、この時点で選択します。
［Project］メニューから［Deploy Archive］を選択します。
Workbenchにより、WARがサーバに配備されます。 このプロセスには、数分かかる場合があります。 配備が完了したら、アプリケーションを実行する準備ができたことになります。
Issue Trackingを実行するには、サーバのディレクトリ領域にsupportユーザ、devユーザ、およびqaユーザを追加する必要があります。 アプリケーションには、これを実行するためのサーブレットがあります。
注記: 希望する場合は、サーバ管理ツールを使用して、次の手順で説明する3人のユーザを追加することができます。
DirectoryInitServletを使用してサーバ領域にユーザを追加する
ブラウザを起動し、EARプロジェクトの次のURLを開きます。
http://server name/DirectorDB (該当する場合)/project name/IssueTracking/DirectoryInitServlet
注記: データベース仕様は、EARプロジェクトを外部データベースに配備した Novell Application Serverユーザに対してのみ必要です。
これによって、ユーザを追加し、ブラウザで確認メッセージを返すサーブレットが実行されます。 追加されるユーザは、次のとおりです。
|
ユーザ |
パスワード |
|---|---|
|
support |
support |
|
dev |
dev |
|
qa |
qa |
この節では、Issue Trackingアプリケーションのインタラクティブデモを示します。 ワークフロープロセスを2つ作成し、それぞれのプロセスでワークアイテムを完了します。 この操作では、3つの異なるブラウザを開いて、認証された各ワークフローユーザ( 28ページの「Issue Trackingアプリケーションについて」を参照)としてログインする必要があります。
ブラウザを開き、プロジェクトのIssue Trackingに移動します。
http://server name/DirectorDB (オプション)/project name/IssueTracking/main
注記: データベース仕様は、EARプロジェクトを外部データベースに配備した Novell Application Serverユーザに対してのみ必要です。
すると、プロセス開始コンポーネントとワークアイテムキューがsupportユーザに対して表示されます。
ブラウザには、2つのコンポーネントが表示されます。左側に表示されるものが開始プロセスコンポーネント、右側に表示されるものが(空の)ワークアイテムキューです。 プロセスを開始する前に、他の2人のユーザとしてログインする必要があります。
ブラウザインスタンスをもう2つ開き、次のようにログインします。
devユーザのページとqaユーザのページには、ワークフローキューコンポーネントが表示されますが、開始プロセスコンポーネントは表示されません。このアプリケーションでは、開始プロセスコンポーネントにアクセスできるのはsupportユーザのみです。 コンポーネントアクセスは、セキュリティ役割記述子によって決定されます( 36ページの「アプリケーションが構築されている方法」の表の説明を参照)。
supportユーザのワークアイテムの［Start Process］ボックスで、ドロップダウンリストから［Issue Tracking］を選択します。
これは、使用可能な唯一のオプションです。 他のワークフロープロセス定義がWARで定義されている場合は、それらの定義がこのリストに表示されます。
新しいワークアイテムが、supportユーザのワークアイテムキューに表示されます。
各ボタンの機能は、次のとおりです。
ワークアイテムを選択して、［View Item］をクリックします。
これにより、新しい問題に関する情報をsupportユーザが入力するためのフォームが表示されます。 各ボタンの機能は、次のとおりです。
［Save and Forward to Development］をクリックします。
この項目は、supportユーザのキューから削除されます。
supportユーザによって転送された2つの項目が、devユーザのキューに表示されます。
最初の問題を選択して、［View Item］をクリックします。
これにより、ワークアイテムウィンドウが開きます。 このウィンドウには、supportユーザによって入力されたデータが含まれます。 左下に［Forward to QA］というボタンが表示されます。
ボタンは［Forward to Support］に変わります。
バグステータスを［Yes］に変更し直して、［Forward to QA］をクリックします。
この項目は、devユーザのキューから削除されます。
バグステータスに対して［No］をクリックし、［Comments］ボックスに次を入力します。
It\xd5 a feature!
supportユーザのブラウザに戻り、［Refresh］をクリックします。
転送された項目が、supportユーザのキューに表示されます。
devユーザによって転送された最初の項目が、qaユーザのキューに表示されます。
これにより、ワークアイテムウィンドウが開きます。 このウィンドウには、前のユーザによって入力されたデータが含まれます。 左下に［Save and Forward to Development］というボタンが表示されます。 これは、修正の承認済みステータスが［No］の場合、プロセスパスになります。
ステータスを［Yes］に変更し、［Save and Forward as Completed］をクリックします。
これにより、問題が終了し、qaユーザのキューから項目が削除されます。
ワークフロープロセス: ワークフローエディタで定義されたアクティビティとリンクから構成されるワークフロープロセスの視覚的なマップ。 ワークフロープロセスは、XMLファイルとして保存されています。
ワークフロークライアント: プロセスおよびワークフローエンジンと通信するためにワークフローAPIを使用するカスタムJavaコード。 クライアントを構築するために、Issue Trackingアプリケーションでは、DirectorコンポーネントとJSPページの組み合わせを使用します。
アプリケーションソースのほとんどは、次のディスクの場所にあるJARファイル内にあります。
project_name/IssueTrackingSample.war/WEB-INF/lib.
|
アプリケーションソース/場所 |
説明 |
|---|---|
|
Issue Tracking Process.xml(resource.jar) |
ワークフローデザイナを使用して作成されたプロセス定義。 |
|
IssueTrackSupportUsers.xml(resource.jar) |
セキュリティ役割記述子。 これにより、IssueTrackStart Processコンポーネントへのアクセスが定義されます。
|
|
activitypolicy.xml(resource.jar) |
各ワークアイテムに対するクライアントタイプとソースを指定します。 |
|
IssueTrackTechSupport.jsp(IssueTracking.war/jsp) |
supportユーザのワークアイテムを定義するJSPページ。 techSupportIssue.javaというJavaBeanを使用します。 |
|
IssueTrackDevelopment(resource.jar) |
devユーザのワークアイテムを定義するポータルコンポーネント。 |
|
IssueTrackQA.jsp(IssueTracking.war/jsp) |
qaユーザのワークアイテムを定義するJSPページ。 このページでは、ワークフローJSPタグライブラリを使用します。
|
|
WorkflowStartProcess(workflow-components.jar) |
ユーザが選択したプロセスを開始するワークフローサブシステムコアコンポーネント。WorkflowStartProcessDefault.xslを使用します。 |
|
WorkflowQueue(workflow-components.jar) |
ユーザの使用可能なワークアイテムをリストするワークフローサブシステムコアコンポーネント。WorkflowQueueDefault.xslを使用します。 |
|
LoginComponent(portal_core_resource.jar) |
ユーザを認証するために使用されるポータルサブシステムコアコンポーネント。 |
|
ITCheckLogin(resource.jar) |
ユーザがアプリケーションにログインしていることを確認するコンポーネント。 |
|
UserDisplay(resource.jar) |
デモ目的で現在のユーザを表示するために使用されるコンポーネント。 |
このアプリケーションのプロセス定義は、ワークフロープロセスをレイアウトできるようにするグラフィカルツールのワークフローデザイナを使用して定義されています。 この節では、プロセスが定義される方法について説明します。
Workbenchで、EARプロジェクトのIssue Tracking Process.xmlを開きます。
IssueTrackingSample/IssueTracking.spf/resource.spf/data/workflow-process/Issue Tracking Process.xml
IssueTracking.war/WEB-INF/lib/resource.jar/workflow-process/Issue Tracking Process.xml
プロセスが、ワークフローデザイナで開きます。
必要な場合は、ウィンドウの上部および側面にあるスクロールキーを使用して、グラフィックを中央に移動します(次の図を参照)。
ワークフロープロセスは、開始アクティビティ(緑色の旗のアイコン)で開始し、終了アクティビティ(チェック模様の旗のアイコン)で終了します。 アクティビティをデザイナパレットに配置し、アクティビティ間にリンクを作成します。 使用できるアクティビティとリンクには、さまざまなタイプがあります。 Issue Trackingプロセスでは、「XORリンク」タイプにリンクされた3つの「ユーザアクティビティ」が定義されます。
ツールの使用の詳細については、
第5章「ワークフローデザイナ」を参照してください。
デザイナパレットの任意の場所にカーソルを置いた状態で右クリックし、［Properties］を選択します。
Nameプロパティは、このプロセスに対する固有な参照です。 Roleプロパティは、このプロセスでワークアイテムを作成することが認証されているセキュリティ役割をリストします。
境界に色が付いている場合、この項目は選択されていることを意味します。
右クリックして［Properties］を選択し、次に［Activity］タブを選択します。
Nameプロパティは、このアクティビティに対する固有な参照を指定します。
issue assignedというリンク(ラベルの部分ではありません)を選択します。
矢印の色が変わり、リンクが選択されていることが表示されます。
右クリックして［Properties］を選択し、次に［Destination］タブを選択します。
［Addressee］ボックスと［Expression］ボックスがあることに気付きます。
［Expression］ボックス内のデータをクリックします。
これにより、式エディタが表示されます。 ここでは、エディタによって、isbugプロパティがtrueの場合はdevユーザに作業を送信するように指示されます。
ワークフローデザイナでは、プロパティは作成されません。この操作は、ワークアイテムコードで実行されます。 ただし、ワークアイテムからは、デザイナで指定したプロパティ値にアクセスできます。 isbugプロパティにおけるこのしくみについては、章の後半で説明します。
cannot reproduce/need more infoというリンクを選択します。
デフォルトのボックスは、プロパティエディタでオンになっています。 つまり、trueと評価されるパスが他にない場合にこのパスをたどることを意味します。
［Expression］ボックス内のデータをクリックします。
エディタによって、isbugプロパティがfalseの場合はsupportユーザに作業を送信し直すように指示されます。
(オプション)エディタで他の項目をクリックし、プロパティシートを検査します。
ヒント: 終了しても、プロセスはWorkbenchで開いたままの状態にしておきます。これ は、クライアントの構築過程(次に説明します)でプロセスを再度確認する必要性が生じ る場合があるためです。
Issue Trackingワークフロークライアントは、ワークフローサブシステムコアコンポーネントと、このアプリケーションに固有なワークアイテムコードの組み合わせで構築されています。 コアコンポーネントは、次のとおりです。
各ワークアイテムでは、ワークフローAPIを使用してワークフロープロセスと通信します。 ワークアイテムは、ポータルコンポーネントまたはJSPページとして作成できます。IssueTrackingアプリケーションでは、両方の実装の使用が示されます。
Issue Trackingクライアントでは、com.ssssw.wf.clientパッケージのクラスを実装します。 APIのドキュメントにアクセスするには、次のクラス名をクリックしてください。
|
クラス名 |
使用目的 |
|---|---|
|
ワークフローエンジン委任とワークフローコンテキストをインスタンス化する |
|
|
Issue Trackingプロセスを開始する |
|
|
ワークアイテムプロパティを定義する |
|
|
ワークアイテムを取得し、次のアクティビティに作業を転送する |
WorkflowStartProcessは、任意のワークフローアプリケーションで使用できるDirectorコアコンポーネントです。 これは、EbiWorkflowEngineDelegateのメソッドを使用してプロジェクトリソースセットのプロセス定義のリストを取得し、ユーザがプロセスインスタンスを開始できるようにします。
WorkflowStartProcessのソースにアクセスする
コードをスキャンした後(この操作には、しばらく時間がかかります)、セグメント(50)に移動します(次を参照)。
注記: 括弧内の数字は、ファイル内でのおおよその行番号です。 行番号付けをオンにするには、［View］>［Line Numbers］の順に選択します。
// Get a list of processes
getRequestParameters( context );
wf_context = asWFContext( context );
EbiWorkflowEngineDelegate m_engineDelegate = com.sssw.wf.client.EboFactory.getWorkflowEngineDelegate();
m_doc = m_engineDelegate.getProcessDefinitions( wf_context );
コンポーネントでは、EboFactory.getWorkflowEngineDelegateを使用して、エンジン委任をインスタンス化します。
次に、コードによって、getProcessDefinitions()がエンジン委任で呼び出され、ワークフローコンテキストオブジェクトが渡されます。 ワークフローコンテキストは、ローカルメソッドのasWFContext()を使用して、ポータルコンテキストから取得されます。
getProcessDefinitions()メソッドは、org.w3c.dom./documentによって定義されたドキュメントを返します。 ドキュメントには、ワークフロープロセスのXML定義が含まれています。 DTDは、プロジェクト内のlibrary/WorkflowService/ DTD/workflow-process.dtdにあります。
if( !isProcessListEmpty( m_doc ) ) {
context.setContentType( EbiComponentConstants.MIME_TYPE_XMLDOM );
context.setComponentContent( m_doc );
このコードは、コンテンツタイプを設定し、コンテンツとしてDOMを返します。
コード(56)まで、上にスクロールして戻ります(次を参照)。
if( m_start ) {
m_start = false;
// The user has asked to start a process
m_engineDelegate.startProcess( m_processID, wf_context );
}
WorkflowQueueは、ユーザの使用可能なワークアイテムのリストを表示するコアコンポーネントです。 これは、ワークフローエンジンを照会し、実行中のプロセス内で使用可能なワークアイテムのリストを取得します。 また、ドロップダウンリストに項目を表示し、ユーザが選択したワークアイテムを取得します。
このコンポーネントでは、WorkflowStartProcessコンポーネントのコード論理に類似したものを使用します。
コードをスキャンした後(この操作には、しばらく時間がかかります)、セグメント(50)に移動します(次を参照)。
EbiQueueDelegate m_queueDelegate = com.sssw.wf.client.EboFactory.getQueueDelegate();
m_doc = m_queueDelegate.getWorklist( wf_context );
context.setContentType( EbiComponentConstants.MIME_TYPE_XMLDOM ); context.setComponentContent( m_doc );
private void unlock( EbiContext context ) {
try{
EbiQueueDelegate queue = com.sssw.wf.client.EboFactory.getQueueDelegate();
EbiWorkitemDelegate delegate = queue.getWorkitem( getWID( m_workitemID ), context );
delegate.unlock( context );
}
catch( Exception e ) {
// An exception means this user cannot unlock this item
m_wrongUser = true;
}
}
このコードによって、getWorkitem()が呼び出され、ワークアイテムIDが渡し入れられます。 この値は、ユーザが選択したワークアイテムを解析するローカルメソッドによって返されます。
getWorkItem()に関連付けられているワークアイテムクラスは、activitypolicy. xml内でユーザによって指定されます。 たとえば、devユーザとしてログインした場合、getWorkList()はIssueTrackDevelopmentコンポーネントを呼び出します。
詳細については、
47ページの「クライアントへのアクティビティのバインド」を参照してください。
最後に、コードによって、キュー委任でunlock()が呼び出されます。 これにより、ユーザはワークアイテムにアクセスできるようになります。 ユーザがワークアイテムにアクセスすると、ファイルが閉じられるまで、または次のアクティビティに作業が転送されるまで、このワークアイテムはそのユーザに対して自動的にロックされます。
Issue Trackingアプリケーションでは、各ワークフローユーザのワークアイテムプロパティが定義されます。 supportユーザの場合は、アプリケーションにより、JSPページと、サポートするBeanクラスが実装されます。
supportユーザのJSPページのBeanソースにアクセスする
コードディスカッションに従うために、JSPページソースにアクセスしなければならない場合もあります。
Beanソースで、コードセグメント(70)に移動します(次を参照)。
public void setWfid( String newWfid , HttpServletRequest request, HttpServletResponse response)
{
try {
m_wfid = newWfid;
EbiQueueDelegate queue = com.sssw.wf.client.EboFactory.getQueueDelegate();
com.sssw.wf.api.EbiContext WFcontext = com.sssw.wf.client.EboFactory.createEbiContext(request, response);
m_delegate = queue.getWorkitem( m_wfid , WFcontext);
}
catch( Exception e ) {
e.printStackTrace();
}
}
このコードは、ワークアイテムプロパティを定義しなければならない基本的なオブジェクトをインスタンス化する方法を示します。
try {
EbiProperty isbugProp = null;
EbiProperty issueidProp = null;
EbiProperty issuenameProp = null;
EbiProperty companynameProp = null;
EbiProperty issuedescProp = null;
EbiProperty commentsProp = null;
m_workitemID = request.getParameter( "wfid" ).trim();
m_issueid = request.getParameter("issueid").trim();
m_issuename = request.getParameter("issuename").trim();
m_companyname = request.getParameter("companyname").trim();
m_issuedescription = request.getParameter("issuedescription").trim();
m_isbug = request.getParameter("isbug").trim();
m_comments = request.getParameter("issuecomments").trim();
//EbiWorkitemDelegate delegate = queue.getWorkitem( m_wfid, context );
if( m_delegate.hasProperty("isbug")) {
isbugProp = m_delegate.getProperty("isbug");
isbugProp.setPropertyValue(m_isbug);
}
else {
isbugProp = (EbiProperty) new EboProperty("isbug", m_isbug, EbiProperty.TYPE_BOOLEAN, false);
}
...
m_delegate.setProperty(isbugProp, context); m_delegate.setProperty(issueidProp, context); m_delegate.setProperty(issuenameProp, context); m_delegate.setProperty(companynameProp, context); m_delegate.setProperty(issuedescProp, context); m_delegate.setProperty(commentsProp, context);
ワークアイテムのロック lock()メソッドは、現在のユーザのワークアイテムをロックします。 これにより、ワークアイテムにアクセスすることが認証されている複数のユーザの間で衝突を防ぐことができます。 このメソッドは、ユーザがワークアイテムを更新する前に呼び出される必要があります。
public void lockWorkitem(HttpServletRequest request, HttpServletResponse response)
{
try {
EbiQueueDelegate queue = com.sssw.wf.client.EboFactory.getQueueDelegate();
com.sssw.wf.api.EbiContext WFcontext = com.sssw.wf.client.EboFactory.createEbiContext(request, response);
getStrings(m_delegate);
m_delegate.lock( WFcontext );
}
catch( Exception e ) {
e.printStackTrace();
}
}
前に説明したように、コードは再びcreateEbiContext()を使用してワークフローコンテキストを取得し、lock()メソッドに渡します。 ワークアイテムをロックする前に、コードはローカルメソッドのgetStrings()を呼び出して、現在のワークアイテムプロパティを設定します。
ワークアイテムの転送 各ワークアイテムでは、forward()メソッドを呼び出して、プロセス内の次のアクティビティに作業を転送します。
private void forwardWorkitem( EbiQueueDelegate queue ) {
try {
queue.forward( m_delegate );
}
catch( Exception e ) {
e.printStackTrace();
}
}
ワークフローサブシステムでは、各ワークアイテムに対するクライアントタイプとクラスの関連付けを定義できます。 クライアントは、activitypolicy.xmlという記述子内でURLとして指定されます。
注記: このファイル名はハードコードされており、変更してはなりません。
Issue Trackingのアクティビティポリシー記述子にアクセスする
Workbenchで、次の場所からactivitypolicy.xmlを開きます。
IssueTrackingSample/IssueTracking.spf/resource.spf/data/workfllow-activity-policy/activitypolicy.xml
IssueTracking.war/WEB-INF/lib/resource.jar/workfllow-activity-policy/activitypolicy.xml
<?xml version="1.0"?>
<activitypolicy>
<activity name="TechSupport">
<client type="portal" uri="/jsp/issueTrackTechSupport.jsp">Portal</client>
</activity>
<activity name="Development">
<client type="portal" uri="/main/comp/IssueTrackDevelopment">Portal</client>
</activity>
<activity name="QA">
<client type="portal" uri="/jsp/issueTrackQA.jsp">Portal</client>
</activity>
</activitypolicy>
activity name (アクティビティ名)要素値は、ワークフロープロセスで定義されている名前に一致する必要があります。 クライアントタイプURLは、各アクティビティに対し、portalとして指定されます。 つまり、各ワークアイテムでは、クライアントUIに対してDirectorポータル表示サービスを使用することを意味します。 これは、現在サポートされている唯一のクライアントタイプです。
アクティビティポリシー機能は、その他のクライアントタイプ(Javaクライアントなど)を定義したり、そのURLをこの記述子内で指定したりすることを可能にします。
詳細については、
24ページの「クライアントタイプへのアクティビティのバインド」を参照してください。
ワークフローサブシステムには、次のようなワークフロー管理用のコアポータルコンポーネントが含まれています。
ブラウザで、WorkflowClientAdminのURLに移動します。
server name/DirectorDB (オプション)/project name/web application name/main/component/WorkflowAdminClient
注記: データベース仕様は、EARプロジェクトを外部データベースに配備した Novell Application Serverユーザに対してのみ必要です。
クライアント管理パネルが表示されます。ここでは、プロセスのステータスを変更したり、プロセスアクティビティに関する情報を取得したりすることができます。
［Process］ペインからIssue Trackingプロセスを選択します。
［Activities］ペインに、プロセスアクティビティに関する情報が表示されます。
アクティビティステータスは、次のとおりです。
|
ステータス |
説明 |
|---|---|
|
Completed |
このアクティビティのワークアイテムは完了しており、次のアクティビティに転送されている |
|
Running |
このワークアイテムはアクティブで、まだ転送されていない |
|
Open |
このアクティビティには現在ワークアイテムはない |
プロセスを選択した状態で、［Terminate Process］をクリックします。
これにより、このプロセスインスタンスは終了します。
ブラウザで、WorkflowClientAdminのURLに移動します。
server name/DirectorDB/project name/web application name/main/component/Workflow EngineAdmin
注記: データベース仕様は、EARプロジェクトを外部データベースに配備したNovell Application Serverユーザに対してのみ必要です。
エンジン管理パネルが表示されます。ここでは、エンジンおよびキューを起動/開始、一時停止、またはシャットダウンできます。
これにより、エンジンとキューがシャットダウンします。
管理コンポーネントの詳細については、
第6章「ワークフロー管理」を参照してください。
|
|
ワークフローガイド |
Copyright © 1997, 1998, 1999, 2000, 2001, 2002, 2003 SilverStream Software, LLC, a wholly owned subsidiary of Novell, Inc. All rights reserved.