WebSphere Business Modeler 6.02によるビジネス・モデルからBPELへの変換

ページオプション JavaScript を要するドキュメントオプションは表示されません 原文はこちら

レベル: 中級

Marc Fasbinder (mfasbind@us.ibm.com), Consulting I/T Specialist, WebSphere Software Technical Sales, IBM

2007年 06月 27日

IBM® WebSphere® Business Modeler（以降、Modelerと呼びます）は、ビジネス・アナリストが個々の独特なビジネス・プロセスを正確にモデリングするために使うことができる強力なツールです。さらに完成したモデルは、WS-BPELにエクスポートすることができます。I/Tで引き継ぐことができる成果物を生成することにより、ビジネス駆動型開発サイクルの時間を短縮し、それとともに最終的なプロセスがビジネスのニーズを確実に満たすようにします。

この記事では、Modelerのさまざまな構成体がどのようにWS-BPELに変換されるかについて説明します。ここに記載するWS-BPELプロセスの図は、IBM WebSphere Integration Developer（以降、Integration Developerと呼びます）で表示されるものを使用しています。

この記事は、皆さんがModelerおよびWS-BPELの基本的知識を持っていることを前提としています。

はじめに

Modelerは以下をはじめ、さまざまなタスクを支援できる強力なツールです。

• 文書化および法令遵守を目的としたモデリング: プロセスが十分に文書化されていないことは珍しくありません。文書化だけを目的にプロセスを把握しようとする企業もあれば、法規制準拠のためにプロセスの把握が必要な企業もあります。
• 再設計を目的としたモデリング: 一部の企業は、現状（as-is）のプロセスを把握して改善する必要を感じています。Modeler にはこのようなケースを支援する強力なシミュレーション・エンジンがあります。また、将来あるべき姿（to-be）のプロセスを定義するために動的レポートおよび静的レポートを作成することができます。
• 実装を目的としたモデリング: 企業によっては、ビジネス・アナリストがモデリングを行い、それをITで引き継ぐことができる成果物に落とし込んでいくという、ビジネス駆動型開発サイクルを実践する必要があります。このようなモデルは、開発サイクルの時間短縮、ビジネス要件を満たすプロセスの実装を実現します。

実装を目的としてモデリングを行う場合、ビジネス・アナリストがはじめにモデルを作成すると、そのモデルは、IT担当者に引き継がれます。IT担当者とビジネス・アナリストがプロセスの内容について合意した時点で、プロセスはビジネス契約と呼ばれるようになります。つまり、ITでの実装に落とし込む際には、きちんと当初のプロセス・モデルの内容が反映されなければならないということです。IT側でプロセスの内容を変更しようとすれば、それはビジネス側との契約を破ることになります。

ビジネス契約が確立されると、IT担当者は、このビジネス・モデルに技術的要素を付加していくことに着手できます。この技術的な情報は、プロセスをWS-BPELにエクスポートする際に使用されます。ただしModelerの基本モードでプロセスを表示すれば、ビジネス・アナリストは、これらの技術的な詳細を意識せずに済みます。

IT担当者がプロセスを編集するときには、技術属性が表示されるWebSphere Process ServerモードでModelerを使用します。Modelerをこのモードにした場合は、技術属性を表示するタブの他、プロセスの技術仕様を表示するタブも提供されます。開発者はこれらのタブを使って、プロセス・モデルに詳細を追加していきます。

この記事では、ビジネス・モデルの情報を、標準準拠のビジネス・プロセス実行言語である、WS-BPELに変換する方法について説明します（WS-BPEL仕様を参照（US））。記事の内容は、WebSphere Business Modeler version 6.0.2に基づいています。

上に戻る

Modelerプロジェクトのエクスポート

Modelerには、ビジネス・プロセス・モデルの作成に使用できる多彩なオブジェクトが用意されています。これらの構成体で、ビジネス・プロセスのステップ、制御フロー、データ、リソース、文書化などを表すことができます。

ビジネス・プロセスをエクスポートすると、該当する構成体は、WS-BPEL、WSDLおよびXSDに変換され、ITで引継ぐことができる成果物になります。ただし、Modelerに含まれる構成体の中には、相当するWS-BPELがないものもあります。このような構成体は無視されることもあれば、問題ビューにエラーまたは警告が表示されることもあります。各種オブジェクトは、次のセクションで紹介します。

ModelerプロジェクトをWS-BPELとしてエクスポートする手順は、以下のとおりです。

1. プロジェクト・ツリー内のプロジェクトを右クリックします。
2. Export…を選択します。
3. WebSphere Process Serverを選択し、Nextをクリックします。
4. Browse…を使ってターゲット・ディレクトリーを選択します。
5. Module project nameのチェック・ボックスを選択し、作成するモジュールの名前を入力します。モジュールが現行のワークスペースに作成されます。
6. オプションで、Library project nameのチェック・ボックスを選択して名前を入力します。エクスポートするライブラリーを選択すると、XSDなどの再使用可能な項目がライブラリー・プロジェクト内に配置されます。このライブラリーを、ここで作成するモジュールが参照することになります。
7. Modelerがスタンドアロンでインストールされている場合は、Project Interchange nameのチェック・ボックスが有効になります。このチェック・ボックスを選択すると、現行のワークスペースにエクスポートする代わりにIntegration Developerのワークスペースにインポート可能なZIPファイルを作成することができます。
8. プロセスに共通イベント・インフラストラクチャーのイベントを生成させたい場合は、Enable default eventsを選択します。
9. この時点で、Exportウィンドウは図1のようになっているはずです。Finishをクリックします。

上に戻る

ローカル・タスクとグローバル・タスク

Modelerで最もよく使用されるオブジェクトの1つは、タスクです。タスクは、ビジネス・プロセス内の1ステップを表し、手動のタスクと自動のタスクの場合があります。1つのリソースが同時に複数の作業を行う場合には、そのすべての作業を1つのタスクとしてグループ化することができます。

モデリングを行う際に重要なのは、タスクの粒度を考慮することです。タスクの「粒度が小さすぎる」場合、プロセス・モデルが複雑になりすぎて扱いきれないものになってしまう可能性があります。逆に「粒度が大きすぎる」とプロセスが単純になりすぎる恐れがあるので、その中間の程よい粒度になるようにしてください。

Modelerのローカル・タスクとグローバル・タスクは、エクスポートされるとどちらも同じように機能します。このセクションでは、それぞれのタイプのタスクがどのようにBPELにエクスポートされるかを見ていきます。

自動アクティビティー用のタスク

スタッフ・リソース定義のない Modelerタスクは、WS-BPELのinvoke（起動）アクティビティーとなります。また、invokeアクティビティー用のタスクとの接続も作成されます（図2を参照）。

ヒューマン・アクティビティー用のタスク

タスクのリソース定義がStaffに設定されている場合、生成されるプロセスで人による処理の介在をどのように扱うかを制御することができます。Technical Attributes Viewで実装タイプがHuman Taskに設定されているタスクについては、WebSphere Process Serverのヒューマン・タスク・マネージャー用のタスクと併せてWS-BPELのinvokeアクティビティーが生成されます（図3を参照）。実装タイプがNoneに設定されているか、あるいはリソース・タイプが個人の場合、ヒューマン・タスクにIBM WS-BPEL拡張を使用したタスクが生成されます。これは、インライン・ヒューマン・タスクとも呼ばれます。

複数の入力基準を持つタスク

これまで見てきたタスクではすべて、1つのビジネス項目が入力され、1つのビジネス項目が出力されていましたが、プロセスの1つのタスクが複数の入力を持つモデルもあります。それぞれの入力ごとに固有の入力基準を設定すると、いずれかの入力を受け取った場合にタスクが開始されるようにできます。これは、Input Logicタブで制御します（図4を参照）。

タスクが複数の入力を持つ場合、複数の操作を持つWSDLが生成されます（図5を参照）。

複数の操作を持つWSDLを生成する手順は、以下のとおりです。

1. Modelerでタスクをクリックして選択します。
2. Inputsタブで、Addをクリックして2番目の入力を作成します。新規入力に名前を指定し、ビジネス項目を関連付けます（図6を参照）。

3. Outputsタブで、Addをクリックして2番目の出力を作成します。新規出力に名前を指定し、ビジネス項目を関連付けます。
4. Input Logicタブで、Addをクリックして 2 番目の入力基準を作成します。
5. デフォルトでは、入力基準でAND演算が実行されるので、タスクは両方の入力を待機することになります。この例では一度に1つの入力しか使用しないため、ANDをORに変更します。新規入力基準と新規入力が関連付けられるようにチェック・ボックスを選択します。また、元の入力基準と新規入力との関連付けが解除されるように、該当するチェック・ボックスのチェック・マークを外します（図7を参照）。

6. タスクの入力基準と出力基準は同じ数でなければなりません。Output Logicタブでステップ4と5を繰り返して新規出力基準を追加し、OR演算を実行するように変更します。
7. Advanced Output Logicタブで、新規出力基準をクリックして選択します。新規入力基準のチェック・ボックスをクリックして出力基準に関連付けます（図8を参照）。

エクスポートすると、このタスクに対して生成されたWSDLに複数の操作が組み込まれます。

生成される参照パートナーとインターフェース・パートナー

WS-BPELプロセスの各invokeアクティビティーは、WSDLファイルを使って定義された参照パートナー・リンクと関連付けられます。ModelerはこのWSDLファイルを、バインディングをラップした文書リテラル・スタイルで生成します。さらにインターフェース・パートナー・リンクも作成して、プロセスの呼び出し方法を定義します。パートナー・リンクの名前は、invokeアクティビティーの名前の終わりに「Partner」を追加した形式となります（図9を参照）。Container（コンテナー） アクティビティー（ループなど）内での呼び出しの場合に生成される名前は、container activity name || invoke activity name || Partnerとなります。

大抵のIT組織には、WSDLファイルの命名規則などについて、従わなければならない標準があります。WSDLで生成される内容を制御するには、Technical Attributes Viewを使用します。このビューでは要求のWSDL操作名などを定義できます。これらの名前フィールドが入力されない場合、Modelerはデフォルト名を使用し、例えば生成されるポート・タイプの名前は Modelerでのタスクの名前に設定されます。

Modelerタスクの実装タイプ

Modelerは、WS-BPELプロセスの他、WebSphere Process ServerのSCAコンポーネントも生成します。その実装タイプは、それぞれのタスクに対応するTechnical Attributes ViewのImplementationタブで設定できます。デフォルトの [none] をそのまま使用すると、実装タイプを持たないSCAコンポーネントが生成されます。通常は、IT担当者がそのタスクに必要な実装方法を把握しているはずなので、いずれかの実装タイプを選択することになります。

ビジネス・ステート・マシン

実装タイプがState Machineに設定されているタスクの場合、Modelerは図12に示すように、1つの状態と1つの操作を持つビジネス・ステート・マシンを生成します。この図でエラー・アイコンが表示されているのは、生成された状態マシンがまだ不完全なためです。IT担当者が実装の詳細を定義する必要があります。

ルール・グループ

実装タイプがRule Groupに設定されているタスクの場合、Modelerは図13に示すように、空のルール・グループを作成します。実際のルールはIT担当者が実装します。この図でエラー・アイコンが表示されているのは、生成されたルール・グループに必須情報が含まれていないためです。

ヒューマン・タスク

実装タイプがHuman Taskに設定されているタスクの場合、Modelerはヒューマン・タスクを生成します（図14を参照）。

リソース定義がStaffに設定されている場合、Modelerはリソース情報を基にPotential Ownerを設定します（図15 を参照）。例えば、タスクの役割をRole 1に定義すると、生成されるヒューマン・タスクのスタッフ割り当てVerbはRole Members に設定され、Rolename属性はRole 1に設定されます。リソースが個人の場合、Modelerはスタッフ割り当てVerbにUsers by user IDを選択し、userID属性をperson IDに設定します。

Javaタスク

Modelerは、実装タイプにJavaが選択されているタスクに対してはSCA Javaコンポーネントを生成します。この場合、IT担当者がJavaプログラムを編集して、必要なビジネス・ロジックを追加しなければなりません（図16を参照）。

                                                            
package processes.process1;

import commonj.sdo.DataObject;
import com.ibm.websphere.sca.ServiceManager;

public class Task_0983731675Impl  {
/**
 * Default constructor.
 */
public Task_0983731675Impl() {
        super();
}
  /**
   * Return a reference to the component service instance for this implementation
   * class.  This method should be used when passing this service to a partner reference
   * or if you want to invoke this component service asynchronously.    
   *
   * @generated (com.ibm.wbit.java)
   */
        private Object getMyService() {
                return (Object) ServiceManager.INSTANCE.locateService("self");
        } 

/**
 * Method generated to support implemention of operation "InputCriterion" defined for
 * WSDL port type named "Task".
 * 
 * The presence of commonj.sdo.DataObject as the return type and/or as a parameter 
 * type conveys that its a complex type. Please refer to the WSDL Definition for more
 * information on the type of input, output and fault(s).
 */
public DataObject InputCriterion(DataObject Input)  {
                //TODO Needs to be implemented.
                return null;

}

}
                                                            
                                                            

プロセス・タスク

実装タイプにProcessが選択されているタスクに対してModelerが生成するのはWS-BPELプロセスです（図16を参照）。このプロセスは空で、シーケンス（Sequence）コンテナーにはReceiveとReplyしか配置されていません。プロセス・ロジックを指定したい場合には、代わりにグローバル・プロセスを使用してください。

上に戻る

グローバル・サービスとビジネス・サービス

グローバル・サービスはModelerの構成体の1つで、再利用可能なビジネス・サービスを定義できます。グローバル・サービスはプロジェクト・ツリーのプロセス・カタログ内に表示され、ドラッグ・アンド・ドロップでプロセスに追加することができます。

ビジネス・サービスはグローバル・サービスと同様ですが、ビジネス・サービスの場合はインポートしたWSDLファイルから取り込みます。このサービスが表すのは、ビジネス内の既存のサービスです。Modelerでは、IBM WebSphere Service Registry and Repositoryを検索してビジネス・サービスを見つけることもできます。

グローバル・サービスとビジネス・サービスが WS-BPELにエクスポートされると、どちらもinvokeアクティビティーになります。Modelerはグローバル・サービスに対しては新しいWSDLを作成し、ビジネス・サービスの場合にはインポートしたWSDLをそのままエクスポートします。

上に戻る

ローカル・サブプロセスとグローバル・プロセス

ローカル・サブプロセスは、一連のタスクをグループ化するために使用するContainerアクティビティーです。グローバル・プロセスは、プロジェクト・ツリーから別のプロセスの中にドラッグ・アンド・ドロップできるプロセスのことを指します。グローバル・プロセスは再利用できますが、ローカル・サブプロセスはそれが定義されているプロセス内で一度しか使用できません。

ローカル・サブプロセスを展開するには、対応する + アイコンをクリックします。ローカル・サブプロセスをWS-BPELにエクスポートすると、図17に示すようにScope（スコープ）アクティビティーになります。スコープとは、1つ以上のアクティビティーを収容するコンテナーのことです。WebSphere Process Serverでは、スコープ単位で補正を行えます。プロセス内でスコープの補正が必要な場合は、ローカル・サブプロセスを使ってスコープの境界を定義してください。

Modelerではそれぞれのグローバル・プロセスを別のプロセスに含まれるコンテナーとしてではなく、個々のWS-BPELプロセスとしてエクスポートします。

上に戻る

単純判定と多肢選択判定

単純判定にはyesかnoの2つの選択肢しかありませんが、多肢選択判定では2つ以上の選択肢を設定可能です。プロセス内の制御フローは、この両方を使って定義できます。Modelerで中間モードまたはそれ以上のモードを使用しているときは、式エディターで判定のロジックを定義できます。

プロセスをWS-BPELにエクスポートする前に、重要な属性を設定しておく必要があります。該当する判定のTechnical Attributes ViewでRepresent exclusive decision as BPEL Switch activityのチェック・ボックスにチェック・マークを付けてください（図18を参照）。

このチェック・ボックスが選択されていないと、Modelerは判定のロジックを前のアクティビティーから出ているコネクター上に配置します。コネクター・アイコンの途中が内側にひし形を含む膨らんだ形状となり、ロジックが関連付けられていることを示します（図19を参照）。

チェック・ボックスを選択した場合は、switch（スイッチ）アクティビティー（choice アクティビティーとも呼ばれます）を含んだWS-BPELが生成されます。判定のそれぞれの分岐はケースとして表されます。判定の各分岐に続くロジックは、ケースの内側に配置されます（図20を参照）。

複数のパスが単純に結合しないような複雑なプロセス・ロジックには、switchを使用しないほうが読みやすいWS-BPELを生成できる場合があることに注意してください（図21を参照）。

判定の属性ビューに含まれるGeneralタブには、Inclusive（包括）というチェック・ボックスがあります。このボックスにチェック・マークが付いていない場合、判定のパスのうち、trueに評価されるのは1つのパスだけです。ただし包括判定の場合には、パスのいずれか、またはすべてがtrueと評価される可能性があります。

WS-BPELのswitchアクティビティーでtrueに評価できるケースは1つだけです。そのため、Modelerで判定に対してInclusive チェック・ボックスにチェック・マークを付けると、その判定をWS-BPELのswitchアクティビティーとして表すための設定は無効になります（図22を参照）。

判定におけるotherwiseケースの生成

WS-BPELのswitchでは、switchアクティビティー内部にotherwise構成体が提供されます。それにより、他のケースがいずれもtrueでない場合には、otherwiseパスが採られます。Modelerではotherwiseパスの生成に関する明示的サポートを提供していませんが、以下の次善策を用いることができます。

1. Technical Attributes ViewのGeneralタブで、Represent exclusive decision as BPEL Switch activityチェック・ボックスを選択します。
2. 属性ビューのGeneralタブで、Inclusiveチェック・ボックスにチェック・マークが付いていないことを確認します。
3. Output Branchesタブで、それぞれの出力条件に式を定義します。ただし、リストの一番下にある最後の出力条件は除きます。
4. 最後の出力条件については、式をブール値trueに設定します。

この次善策によって、生成されたWS-BPELで選択項目がいずれもtrueに評価されない場合には、最後の選択項目がtrueに評価されます。WebSphere Process Serverはchoiceアクティビティー内のケースを左から右の順に評価するため、生成されるWS-BPEL はこれで正常に機能するようになります。WS-BPELを編集してotherwiseを追加してから、必要に応じてリンクを移動することも可能です。

上に戻る

fork、結合、マージ

forkは、フローを2つの並行したパスに分岐するModelerの構成体です。これと対をなすのが結合で、すべての入力パスが完了するのを待ってから単一のパスに遷移します。結合はいわば、入力パスでAND演算を行うようなものです。

生成されたWS-BPELプロセスでは、forkは条件なしの2つのコネクターになります。フローは両方のパスを評価して、タスクを並行して実行できるようにします。結合はJavaスニペットとなり、並行パスの同期点として機能します（図23を参照）。

Javaスニペットには、両方のタスクの出力を取得するためのデフォルト・コードが含まれます。両方のパスからのデータをマージして出力しなければならない場合は、IT担当者がその方法を決定しなければなりません。

if (ListOf2To2DatasVariable == null){
com.ibm.websphere.bo.BOFactory factory =  (com.ibm.websphere.bo.BOFactory) new
com.ibm.websphere.sca.ServiceManager().locateService
("com/ibm/websphere/bo/BOFactory");
    ListOf2To2DatasVariable = factory.create( "http://Businessitems", "ListOf2To2Datas"); 
}
ListOf2To2DatasVariable.getList("dataItem").add(0, DataVariable);
ListOf2To2DatasVariable.getList("dataItem").add(1, DataVariable2);
                       

リスト2のアンチパターンは重要なので、理解しておいてください。このアンチパターンが示しているのは、並行アクティビティーを処理する際には、デッドロックの恐れがあるので、2つの並行パスで同じWS-BPEL変数は使用できないということです。ベスト・プラクティスは、データ型が同じだとしても並行パスにはそれぞれ異なる変数を使用することです。

同じビジネス項目のマージ

マージは結合とは異なり、すべての入力パスが完了するまで待機しません。入力パスの1つがマージに到達すると、フローは次のアクティビティーに進みます。マージはいわば、入力パスでOR演算を行うようなものです。

マージへの入力パスが同じビジネス項目を持っている場合、生成されるWS-BPELは両方の出力パスをそのままプロセス内の次のアクティビティーに接続します（図24を参照）。

異なるビジネス項目のマージ

マージへ入力される2つのパスが異なるビジネス項目を持っている場合、Modelerは次のようにWS-BPELを作成します（図25を参照）。

• マージされるアクティビティーの一方は、次のアクティビティーに直接遷移します。
• マージされるもう一方のアクティビティーはJavaスニペットに遷移します。このスニペットでは、IT担当者がデータの処理内容を定義できます。フローはこのJavaスニペットを介して次のアクティビティーに進みます。

多数の入力パスをマージする場合も同様です。例えば、それぞれに異なるビジネス項目を持つ3つの入力パスがあるとすると、そのうちの1つのパスは直接アクティビティーに遷移し、他の2つはJavaスニペットを介して遷移します（図26を参照）。

上に戻る

通知ブロードキャスター、通知レシーバー、オブザーバー、タイマー、マップ

プロセス内でイベントを表現するために使用するのは、通知ブロードキャスターおよびレシーバーです。イベントは、通知ブロードキャスターによって通知レシーバーに送信されます。この2つの構成体は、WS-BPELにはエクスポートされません。そのため、エクスポートする前にモデルから除去する必要があります。

オブザーバーは、ある条件がtrueと評価された場合にフローを開始できる構成体です。この構成体もWS-BPELにはエクスポートされません。タイマーは一定の時間待機する構成体で、これも同じくエクスポートすることはできません。

マップは、フロー内のデータがあるビジネス項目から別のビジネス項目に変更されていることを示すために使用するModelerの構成体です。WS-BPELにエクスポートされたマップは、WS-BPEL（US）のIBM拡張であるJavaスニペットになります。このスニペットは空なので、必要なコードはすべて、IT担当者が作成しなければなりません。SCAは強力なインターフェース・マッピング・ツールを提供するので、マップのコードを作成するのは推奨されないのが通常ですが、生成するWS-BPELに「インライン」Javaスニペットが必要な場合にはマップを使用できます（図27を参照）。

上に戻る

whileループ、do-whileループ、forループ

WS-BPEL仕様には、forループとdo-whileループのサポートは含まれていません。このいずれかのループを使用すると、問題ビューにエラーが表示され、プロセスのエクスポートは不可能となります。

forループは、適切なループ条件を使用することによってwhileループに変換することができます。forループは定義された回数だけ処理を繰り返します（例えば、n回）。繰り返しごとにカウンターを使用すれば、counter <= n という条件を指定したwhileループで代用できます。

do-whileループはwhileループと同様ですが、異なる点は毎回繰り返しの後にループ条件がチェックされることです。whileループでは、ループ条件は繰り返しの前にチェックされ、ループ条件が最初にtrueであれば同じ動作になります。そのため、最初にtrueとなるループ条件を選択することで、do-whileループの代わりにwhileループを使用することができます。

whileループのモデリングとWS-BPELへのエクスポート方法についての詳細は、「Using Loops in WebSphere Business Modeler v6 to improve simulations and export to BPEL（US）」を参照してください。

上に戻る

ローカル・リポジトリー、グローバル・リポジトリー、ビジネス項目

ビジネス項目は、プロセス内を流れるデータを表します。このビジネス項目を保管するのに使用するのが、ローカル・リポジトリーとグローバル・リポジトリーです。この3つの構成体はWS-BPELにエクスポートされるといずれも変数になります。WS-BPEL内では、それぞれの変数がXSDまたはインターフェースに応じたデータ型に関連付けられます。

Modelerはビジネス・プロセス内でのビジネス項目ごとに、WS-BPEL変数とXSDを作成します。エクスポートされたプロセスは、アクティビティーごとに変数を作成するのではなく、既存の変数をできるだけ再利用します。変数名は、技術属性でデフォルト名をオーバーライドしない限り、business item name || Variable となります。変数はプロセス内の各リポジトリーに対しても作成されます（図28を参照）。

上に戻る

開始、停止、終了

開始、停止、および終了ノードはシミュレーション専用です。生成されたWS-BPELには一切作用しません。

上に戻る

プロセス・エッジへの接続

プロセスの最終タスクの出力を停止ノードに接続すると、データは最終タスクからは出力されません。生成されたWS-BPELアクティビティーはWS-BPEL変数から入力を読み取りますが、完了時に変数の設定は行いません。このタスクに対し生成されるWSDLの操作は単方向となります。

プロセスの最終タスクの出力をプロセス・エッジ（プロセス・ダイアグラムの境界）に接続すると、データは最終タスクから出力されます（図29を参照）。この場合、生成されるWS-BPELは、変数に対して読み取りと書き込みの両方を行うことになります。データをプロセスの最初のタスクへの入力として受け渡したい場合にも、同様にタスクをプロセス・エッジに接続します。

上に戻る

注釈

可視のコメントをプロセス・モデルに追加するには、注釈を使用します。注釈に含まれる情報はWS-BPELプロセスにエクスポートされるため、ビジネス側とIT側双方の担当者がコミュニケーションを図る上で役立ちます。

ビジネス・モデル内のオブジェクトと注釈を接続することで、コメントがどのオブジェクトに関するものなのかを示すことができます。接続された注釈のテキストは、生成されたWS-BPELアクティビティーのコメントとなります。接続されていない注釈のテキストは、プロセスのコメント領域に配置されます（図30を参照）。WS-BPELでは、コメント・フィールドが256文字に制限されていることに注意してください。それより長いコメントはエラーの原因となります。

上に戻る

SCAアセンブリー・ダイアグラム

Modelerはビジネス・プロセスとコンポーネントを生成するだけでなく、SCAアセンブリー・ダイアグラムも生成します。このダイアグラムは、プロセスに含まれるそれぞれのサービス呼び出しの参照をコンポーネントのインターフェースに接続するために使用します。コンポーネントのアセンブリーとは、ビルディング・ブロック同士を繋げて1つのソリューションを構築するようなものと言えます（図31を参照）。

上記の例では、ExportProcessというプロセスに2つのタスクならびにProcess 1という名前のグローバル・サブプロセスがあります。Modelerは、図31のプロセス・ダイアグラムの下に示されているように、両方のプロセスに対してWS-BPELを生成します。

それぞれのプロセスについて、下のアセンブリー・ダイアグラムには、SCAコンポーネントが表示されています。ExportProcessが接続されているのは、このプロセスが呼び出す3つのコンポーネント（Process1と2つのタスク）です。Process1には単一の参照があり、この参照は、別のSCAコンポーネントに接続されています。ダイアグラムの左端を見ると、どちらのプロセスにもSCAエクスポートが定義されていることが分かります。エクスポートは、プロセス・インターフェースをSCAモジュールの外部に公開するために使用します。

上に戻る

役割、リソース、タイムテーブル

WS-BPELはユーザー・ディレクトリーではないないため、Modelerは役割とリソースのエクスポートは行いません。ただし、役割およびリソースは、生成されたヒューマン・タスクのパラメーターとして使用されます。タイムテーブルについても、対応する構成体がWS-BPELにないため、エクスポートはされません。

上に戻る

複数の入力基準を持つプロセス

タスクとは異なり、Modelerのプロセスについては入力基準と出力基準の数を同じにする必要はありません。これをグローバル・プロセスで利用して、receive choice（受信選択）と呼ばれるWS-BPELアクティビティー（仕様の以前のバージョンでは、pick（選択）アクティビティーと呼ばれていました）を生成することができます。受信選択とは、n個のイベントのうちの1つが発生するまで待機するアクティビティーのことです。例えば、プロセスから要求が送信されると、受信選択は最初の要求を処理して返します（他の要求は破棄）。イベントとプロセスの対応を調べるには、WS-BPEL相関セットを使用します。

複数の入力基準を持つプロセスを作成する手順は、以下のとおりです。

1. Modelerで新規プロセスを作成します。
2. 属性ビューのInputsタブで 2 つの入力を追加し、それぞれのデータ型に対応するビジネス項目と関連付けます。すると、プロセス・ダイアグラムに追加された 2 つの入力が表示されます。
3. Outputsタブで、出力を追加してビジネス項目に関連付けます。
4. プロセスにアクティビティーを追加します（図32を参照）。
   
   図32 process activity（プロセス・アクティビティー）の例
   
   
   
5. Input Logicタブで、2番目の入力基準を追加します。新しい入力基準が2番目の入力に関連付けられるようにチェック・ボックスを選択します。また、新しい入力基準と元の入力との関連付けが解除されるように、該当するチェック・ボックスのチェック・マークを外します（図33を参照）。
   
   図33 Input Logic
   
   
   
6. Advanced Output Logicタブで、Output Criterionをクリックして選択します。Advanced Output Logicタブは、中間モード以上でのみ有効です。一番下までスクロールして、Input Criterion:2のチェック・ボックスを選択します。
7. プロセスを保管します。エラー・ビューに警告が表示される場合がありますが、無視して構いません。
8. WebSphere Process Serverをターゲットとして選択して、プロセスをエクスポートします。

エクスポートされたプロセス（図34）は、Modelerプロセスと同じ名前のreceive choiceアクティビティーから始まります。2つの入力基準は、receive choiceアクティビティーに含まれるreceive（受信）となります。プロセスには赤いエラー・インジケーターが表示されていますが、これは、必要な相関属性がまだ設定されていないためです。プロセスを完成させるには、IT担当者が相関属性を設定する必要があります。

ただし、この手法はグローバル・プロセスにのみ適用されます。Modelerはローカル・サブプロセスをscopeアクティビティーに変換するためです。

上に戻る

複数の出力基準を持つプロセス

グローバル・プロセスには複数の入力基準が許可されているのと同様に、複数の出力基準も許可されます。複数の基準を使うと、プロセスの開始時ではなくプロセスの途中にreceive choiceアクティビティーを生成することも可能になります。複数の出力基準を持つプロセスを別のプロセスに配置すると、そこにreceive choiceアクティビティーが生成されます。

複数の出力基準を持つプロセスを作成する手順は、以下のとおりです。

1. Modelerで、MultiOutputという名前の新規プロセスを作成します。
2. Inputタブで、入力を追加してビジネス項目に関連付けます。
3. Outputタブで、2つの出力を追加してビジネス項目に関連付けます。すると、この2つの出力がダイアグラムに表示されます。
4. プロセスにタスクを追加し、さらにコネクターを追加します（図35を参照）。
   
   図35 タスクが定義されたプロセス
   
   
   
5. Output Logicタブで、2番目の出力基準を追加します。
6. 2番目の出力のチェック・ボックスをクリックして最初の出力基準との関連付けを解除し、今作成した2番目の出力基準に関連付けます（図36を参照）。
   
   図36 出力基準の関連付け
   
   
   
7. Advanced Output Logicタブで、2番目の出力基準を選択します。チェック・ボックスをクリックして入力基準に関連付けます（図37を参照）。
   
   図37 入力基準の関連付け
   
   
   
8. プロセスを保管します。エラー・ビューに警告が表示されるのは通常のことです。
9. MainProcessという名前の2番目のプロセスを作成します。最初のプロセスをタスクと併せて新規プロセスにドラッグ・アンド・ドロップします（図38を参照）。
   
   図38 MainProcess
   
   
   
10. WebSphere Process Serverをターゲットとして選択し、WebSphere Process Serverをエクスポートします。これで、BPELプロセスの途中にreceive choiceが組み込まれます（図39を参照）。
    
    図39 WS-BPELにエクスポートされたプロセス
    
    
    

生成されたWS-BPELプロセスはMultiOutputを呼び出してから、2つの異なる応答のいずれかを受信するまで待機します。この場合もやはり、相関セットを構成する必要があるため、エラーが表示されます。

上に戻る

一般推奨事項

• WebSphere Process Serverモードでモデルを編集したら、エクスポートする前に必ずエラー・ビューをチェックしてください。警告が表示されてもプロセスはエクスポートできますが、エラーが表示されている場合はエクスポートできません。
• プロセスをエクスポートする前には必ず保管して、更新が確実に組み込まれるようにしてください。
• 大規模なプロジェクトをエクスポートする場合は、エクスポートするプロセスだけを選択するようにしてください。その際、プロセスに必要な参照はすべて一緒にエクスポートされます。反対に、古いas-isプロセスなどの不要なものは一切含まれないようにできます。
• 生成されるコンポーネントの名前を設定するには、技術属性を使用してください。技術属性を使用しない場合は、名前を固有にするために、Modelerでの名前に一連の数字を追加したコンポーネント名となります。

上に戻る

まとめ

この記事では、WebSphere Business Modelerの構成体を順に取り上げ、WS-BPELにエクスポートした際、それぞれがModelerによってどのように変換されるかを説明しました。Modelerの構成体を知り、理解することで、生成されるWS-BPELをより適切に扱えるようになります。また、意図したとおりのWS-BPELを生成する上で役立つ、プロセスのモデリング方法に関するヒントと手法も紹介しました。以下に、この記事の内容を要約します。

• テスト・ケースごとに生成されたWS-BPELはWebSphere Process Serverで正しく動作したものです。
• ModelerではすべてのWS-BPELアクティビティーを生成できるわけではありませんが、最もよく使われるアクティビティーは生成することができます。
• 生成されたWS-BPELに障害ハンドラー、補正ハンドラーなどの機能を組み込みたい場合には、追加の作業が必要となります。
• 生成されたSCAコンポーネントをWPSで使用可能な状態にするには、追加の作業が必要です。ただし、コンポーネントは正しいインターフェースと構造で生成されるので、開発が簡単になり、なおかつビジネスのニーズが確実に反映されるようにすることができます。

参考文献

• developerWorks Japan: WebSphere: WebSphereの日本の技術情報サイトです
  
  
• developerWorks: WebSphere(US) : WebSphereの英語の技術情報サイトです
  
  
• Why model business processes? (developerWorks, May 2007)
  
  
• End-to-end BPEL business activity monitoring with IBM SOA tools: Part 1: Modeling for process execution with WebSphere Business Modeler (developerWorks, June 2007)
  
  
• Using Loops in WebSphere Business Modeler v6 to improve simulations and export to BPEL (developerWorks, March 2007)
  
  
• Process anti-patterns: How to avoid the common traps of business process modeling, Part 1 (developerWorks, February 2007)
  
  
• Business Process Execution Language for Web Services version 1.1 (developerWorks, February 2007)
  
  
• Transforming models from WebSphere Business Modeler to WebSphere Integration Developer (developerWorks, May 2005)
  
  
• Using WebSphere Business Modeler, Monitor, and Process Server for BPM (WB170 or VB170)
  
  
• WebSphere Business Modeler: Process Mapping, Simulation, and Analysis (WB182 or VB182)
  
  
• WebSphere Business Modeler: Process Mapping and Analysis (BI184 or VB184)
  
  
• Designing for Performance Measurement Using WebSphere Business Monitor (WB189 or VB189)
  
  
• WebSphere Business Modeler information
  
  
• WebSphere Integration Developer information
  
  
• Redbook: Business Process Management: Modeling through Monitoring Using WebSphere V6 Products
  
  
• Redbook: Best Practices for Using WebSphere Business Modeler and Monitor
  
  
• Redbooks: Patterns: SOA Foundation - Business Process Management Scenario
  
  
• IBM Modeler User's Group (IMUG)
  
  
• Sharing business processes in a team environment using WebSphere Business Modeler and CVS (developerWorks, February 2007)
  
  
• developerWorks WebSphere development tools
  
  
• developerWorks Websphere business integration
  
  

• WebSphere Business Modeler Trial

著者について

		Marc Fasbinder は、ミシガン州サウスフィールドの WebSphere Technical Sales チームで統合ソリューション・アーキテクトとして活躍しています。連絡先は、mfasbind@us.ibm.com です。

記事の評価

サイト改善のため、ご意見をお寄せください。こちらのフォームからお願いいたします。 この情報はお客様が目的を達成するうえで役に立ちましたか？ はい いいえ わからない   お気軽にご意見・ご感想をお寄せください。   この記事は役に立ちましたか？ 1 2 3 4 5 不充分・不完全である 大変素晴らしい

この記事を共有する del.icio.us newsing FC2ブックマーク Choix！ ニフティクリップ Yahoo!ブックマーク MM/memo CZブックマーク livedoorクリップ はてなブックマーク Buzzurl（バザール）

上に戻る