IBM WebSphere 開発者向け技術ジャーナルより。

はじめに

この連載のこれまでの記事では、ビジネス・プロセスおよびステート・マシンを使ってサービス・コンポーネントを実装する方法を説明しました。さらに、アプリケーションのデプロイメント後にパラメーターを変更することが可能なビジネス・ルールとセレクターを使ったその他のコンポーネントを実装して、ビジネス条件の変更に迅速に対応する方法も説明しました。この記事では、WebSphere Integration Developer のサポート機能をさらに詳しく見ていきます。

サービス指向アプリケーションでは、ある 1 つの難題が持ち上がることは確かです。それは、2 つのサービスがうまく連動しなければならないのに、これらのサービスが互いに通信する方法を認識していないという事態です。連載の始めの頃に、コンポーネントの実装は、参照を使用して別のコンポーネントを呼び出すと説明しました。この参照のインターフェースは、接続先のコンポーネントのインターフェースと一致している必要がありますが、インターフェースが一致しない場合はどうなるでしょう。

例えば、参照のインターフェースには retrieveCustomerData 操作があり、この参照の接続先となるコンポーネントのインターフェースには getCustomerData 操作があるとします。もう少し詳しく見てみると、getCustomerData 操作が返すビジネス・オブジェクトの 1 つには custId というフィールドがありますが、retrieveCustomerData 操作は単に id という名前のリターン・パラメーターを期待しています。こうなると、問題はさらに複雑になります。

この問題は、ローカライズされた小規模なアプリケーションでは簡単に解決できます。つまり、すべてが一致するようにインターフェースを変更すれればいいだけのことです。ただし実際には、ビジネス・パートナーは使用するサービスのインターフェースを例えば WSDL (Web Service Definition Language) ファイルなどに定義する場合が多いため、インターフェースの変更は手に負えないものになります。たとえインターフェースを変更できたとしても、サービスの既存の利用者を捨て去ることになりかねません。クライアント側で参照のインターフェースを変更するのも問題外です。なぜなら、異なる名前を使用するように実装を変更する必要が生じるからです。このような障害を容易に回避できるようにするため、WebSphere Integration Developer にはインターフェース・マップとビジネス・オブジェクト・マップの作成機能が用意されています。

これまで参照をコンポーネントに接続しようとして、その 2 つのインターフェースに不一致があった場合には、インターフェース・マップを作成するかどうかを尋ねるダイアログ・ボックスが表示されたはずです。この記事では、さまざまなタイプのマップをどれほど簡単に作成できるかを披露します。

マッピングの他、ヒューマン・タスクについても説明します。ビジネス・プロセスの自動化は企業の効率とその効果を考えると欠かせませんが、ビジネス・プロセスが未だに人手を必要とすることも珍しくありません。例えば、銀行ローンの承認プロセスでは、経験豊富なローン専門家が不明確なローン申し込みを評価しなければなりません。在庫レベルが特定の下限を下回ると自動的に在庫を再発注するという小売店プロセスでも、金額が高い注文については店長が承認する必要があります。人間の介入は、ビジネス・プロセス中に例外を処理する際にも必要になる場合があります。このような場合には、統合アプリケーションの設計時にヒューマン・タスク・コンポーネントを使用できます。

ヒューマン・タスクとはその名前が示すとおり、人間が関与するタスクのことです。ビジネス・プロセス、ビジネス・ステート・マシン、ビジネス・ルールなど、今まで説明してきたその他のコンポーネントと同じく、ヒューマン・タスクもモジュール内のコンポーネントです。WebSphere Studio Application Developer Integration Edition バージョン 5.1 でのスタッフ・アクティビティーとヒューマン・タスク・コンポーネントはどこが違うのか疑問に思うかもしれませんが、スタッフ・アクティビティーを使用するのはビジネス・プロセス内からのみで、その機能は限られています。例えば、スタッフ・アクティビティーではエスカレーション (要求または完了されていないタスクの自動再割り当て) を許可していませんでした。一方、ヒューマン・タスクはバージョン 6 のファースト・クラス・コンポーネントで、ビジネス・プロセス内での内部アクティビティーとして制限されることはありません。さらに、ヒューマン・タスク・コンポーネントではコンピューターが人間に対して対話するだけでなく、人間からコンピューターへの対話、そして人間同士の対話も可能です。

この記事ではまず、ヒューマン・タスク、インターフェース・マップ、そしてビジネス・オブジェクト･マップについて説明してから、実際の作業を行ってもらいます。今回はマッピングを使用したヒューマン・タスクの作成です。このマッピングによって、異なるインターフェースを持つ 2 つのコンポーネントの相互通信を可能にします。

以降のセクションでは、WebSphere Integration Developer を使って以下の追加タスクを実行する方法について説明します。

• インターフェースとパラメーターのマッピング
• ビジネス・オブジェクトのマッピング
• ヒューマン・タスクとしてのコンポーネントの実装
• 独自のヒューマン・タスクの作成
• 独自のインターフェース・マップとビジネス・オブジェクト・マップの作成

上に戻る

インターフェース・マップ

インターフェース・マップは、異なるインターフェースを持つ 2 つのコンポーネント間に位置しています。このマップを使用して、「InterfaceA の OperationX を呼び出したら、InterfaceB の OperationY に要求を送信する」というように指定します。もちろん、両方の操作のパラメーターが一致しないこともあります。そのため、インターフェース・マップには「OperationX の Parameter1 の値を OperationY の Parameter2 に渡す」といった指示もできるようになっています。両方の操作のパラメーターが同じ型であれば、インターフェース・マップにとって何の問題もありませんが、パラメーターの型が異なる場合もよくあることです。そのような場合に使用できる各種のマッピング・ツールについては、「パラメーターのマッピング」セクションで説明します。

例えば、注文処理コンポーネントが、出荷コンポーネントの shipOrder 操作を呼び出さなければならないとします。ただし、出荷コンポーネントのインターフェースにあるのは ship という名前の操作で、パラメーターの名前もそれぞれの操作で異なります。図 1 に示す 2 つのインターフェースには、一方に shipOrder 操作が含まれ、もう一方に ship 操作が含まれています。それぞれの操作のパラメーター名が異なることに注目してください。図 2 に、この違いを解決するインターフェース・マップを示します。

インターフェース・マッピング・エディターの上部で、左側にあるインターフェースの操作を右側にあるインターフェースの操作に接続します。操作パラメーターについては、エディターの下部に、各操作のそれぞれのパラメーター (入力と出力) を接続した結果作成されたマッピングが表示されます。パラメーターを接続すると、move というマッピング・タイプがデフォルトで作成されます。パラメーターの各マッピング・タイプについては、この後すぐに説明します。

マッピング・タイプは、マッピングの方向を示すために片側が尖っています。上記の例では、上の move は orderInfo 入力値が order パラメーターに渡されることを示し、下の move は出力パラメーター ok が shipped パラメーターに渡されることを示します。

インターフェース・マップを作成するには 2 通りの方法があります。まず 1 つは、図 3 に示すインターフェース・マップ・ウィザード (File → NewInterfaceMap) を使用する方法です。この方法では、ソースとターゲットのインターフェースを選択あるいは作成します。ソース・インターフェースとはコンポーネントの参照に属するインターフェースのことで、ターゲット・インターフェースとは参照によって呼び出されるコンポーネントに属するインターフェースのことです。

もう 1 つのインターフェース・マップの作成方法は、一方のコンポーネントの参照をもう一方のコンポーネントに接続することです。この方法は、参照とコンポーネントのインターフェースが異なる場合に使用します。アセンブリー・エディターによって、ソース・ノードとターゲット・ノード (それぞれ、参照となるノードとコンポーネントとなるノード) 間のインターフェース・マップを作成するかどうか尋ねられます。

操作のマッピング

インターフェース・マップを作成した後に必要となるのは、図 4 の上部を見るとわかるように、インターフェースの操作間のマッピングを定義することです。左側にある操作の横をクリックして、接続の終端を右側の対応するインターフェースにドラッグします。2 つの操作間の接続を選択すると、パラメーター・マップがエディターの下半分に表示されます。次のステップは、対応するパラメーター間に接続線を引くことです。

パラメーターのマッピング

一方のインターフェースのどの操作がもう一方のインターフェースのどの操作に対応するかを指定したら、次に、操作パラメーターをマッピングします。操作のマッピングと同じく、一方の操作の入力と出力を、もう一方の操作の対応する入力と出力に接続します。ただし、対応する操作をマッピングするには操作間を線で結ぶだけで済みましたが、データのマッピングはそれより複雑になる場合があります。パラメーターの型が一致する場合は、図 4 に示すように、対応する入力または出力を接続するだけで済みます。一方、パラメーターの型が一致しないことはよくありますが、そんな場合には、「ビジネス・オブジェクト・マップ」のセクションで説明するように、ビジネス・オブジェクト･マップ・エディターがデータのマッピングを支援してくれます。

それではまず、パラメーター・マップの作成方法について説明しましょう。入力パラメーターをマッピングする場合、左側にある入力パラメーターの接続を右側の対応する入力パラメーターにドラッグします。出力パラメーターをマッピングする場合は、接続を右側から左側にドラッグします。マップを作成したら、次にマッピング・タイプを指定します。マッピング・タイプは、Properties ビューの Description タブに表示されたリストから選択できます。以降のセクションでは、以下の 5 つのマッピング・タイプについて説明します。

• 移動 (move)
• 抽出 (extract)
• マッピング (map)
• 割り当て (assign)
• Java

移動 (move)

デフォルトでは、2 つのパラメーターを接続すると、move パラメーター・マッピングというマッピング・タイプが作成されます。上記の例に示されているのは、move パラメーター･マッピングです。move パラメーター・マッピングでは、ソース・パラメーターの値がそのままターゲット・パラメーターに渡されます。それぞれのパラメーターの型は、ストリングであろうとビジネス・オブジェクトであろうと同じでなければなりません。move マッピング・タイプは 1 対多であるため、ソース・パラメーターを 1 つ以上のターゲット・パラメーターにマッピングすることができます。

抽出 (extract)

時として、ターゲット・パラメーターにはソース・パラメーターの一部のデータだけが必要な場合があります。このような場合に使用できるのが、extract です。extract パラメーター・マッピングは、ビジネス・オブジェクトの属性 (単純な型でもネストされたビジネス・オブジェクトでも可) の値を取得してターゲットに渡します。図 5 に示すのは上記の例のバリエーションで、ship 操作に Item と Address という型の 2 つのパラメーターがあります。図の下部にある XPath ツリーを見ると分かるように、shipOrder 操作で使用する Order ビジネス・オブジェクトにも同じく Item と Address という型の属性が含まれています。Properties ビューには、orderInfo から item 属性を選択する XPath 式が表示されています。このマッピングを使用すると、orderInfo.item の値が item パラメーターに渡されます。orderInfo をソースとするもう 1 つの extract を使用して、orderInfo.address の値を address パラメーターに転送しています。

マッピング (map)

パラメーターの型が一致しない場合は、move の代わりに map を使用します。map パラメーター・マッピングを使用すると、異なるビジネス・オブジェクト・パラメーターを一致させることができます。2 つのビジネス・オブジェクトが互いに相手が必要な情報を含んでいるとしても、オブジェクト間に存在する可能性のある不一致は数え切れないほどあります。このような不一致は、属性の順序や名前がビジネス・オブジェクト間で異なると発生します。あるいは不一致がかなり複雑になることもあります。例えば一方のビジネス・オブジェクトが提示する名前には 3 つの属性 (salutation、firstName、および lastName) があり、もう一方のビジネス・オブジェクトが提示する名前には属性が 1 つしかなく、この属性にコンマで区切られたストリングを保持させているといった具合です。また、複数のビジネス・オブジェクトのそれぞれの部分を 1 つのビジネス・オブジェクトにマッピングしなければならないという場合もあります。map を使用する場合はビジネス・オブジェクト・マップを指定して、このマップによって属性をビジネス・オブジェクト間でマッピングします。このマッピング・タイプの詳細は、「ビジネス・オブジェクト・マップ」のセクションで説明します。

割り当て (assign)

ターゲット・パラメーターに一定の値をマッピングすることもできます。assign パラメーター・マッピングでは、ターゲット・パラメーターに書き込む規定の値を指定できます。このタイプのマッピングには、ターゲットしかありません。そのため、2 つのパラメーターを接続してマッピング・タイプを assign に変更しても、assign マッピングは作成できません (両端との接続は assign マッピングにならないため)。assign マッピングを作成するには、ターゲット・パラメーター (右側にある入力、または左側にある出力) を右クリックして、Create Transform → Assign を選択します。これによって、Properties ビューで規定値を入力できるようになります。

assign マッピングは、ターゲット操作にソース操作にはないパラメーターが含まれている場合に使用します。この余分なパラメーターはもう使用されていない可能性があります。マップではすべてのターゲットにマッピングが必要なため、余分なパラメーターにはデフォルト値を割り当てます。また、余分なパラメーターをモジュールから呼び出すと、その値が常に同じになる可能性もあります。例えば、図 6 に示す ship 操作には、shipOrder 操作にはない orderType パラメーターがありますが、このマップが使用されるたびに、assign マッピング・パラメーターによって express の値が渡されます。

Java パラメーター・マッピング

カスタム・ロジックが必要なマップには、Java パラメーター・マッピングを使用します。Java パラメーター・マッピングでは、オブジェクトを変換する Java コードを自由に作成できます。Properties ビューの Details セクションにクラスの名前を指定すると、この名前によって Java クラス com.ibm.wbiserverspi.mediation.JavaMediation が拡張されます。JavaMediation クラスに含まれる仲介メソッドはオブジェクト (マッピングされる値) を入力として使用し、オブジェクト (変換後の値) を戻します。

上に戻る

ビジネス・オブジェクト・マップ

パラメーターのマッピング例では、move や extract などのマッピング・タイプを使って操作間でパラメーターをマッピングする方法を説明しました。今度は、パラメーターの型が同じでないため、パラメーター・マップを使用できない場合について取り上げます。前に述べたように、map パラメーターのマッピング・タイプには、2 つのビジネス・オブジェクトの属性間のマッピングを処理するビジネス・オブジェクト・マップを指定する必要があります。このセクションでは、ビジネス・オブジェクト・マップの内容とその使用方法について解説します。

変換タイプ

ビジネス・オブジェクトの属性をマッピングする方法は、パラメーターをマッピングする場合と同様に、ソース属性をターゲット属性に接続します。属性のマッピングは、属性の変換とも呼ばれます。属性の変換には通常、パラメーターのマッピングより柔軟性が求められるため、パラメーターのマッピングよりも変換のタイプは数多くあります。以降のセクションでは、以下の変換タイプについて説明します。

• 移動 (Move)
• サブマッピング (Submap)
• 抽出 (Extract)
• 割り当て (Assign)
• カスタム (Custom)
• 結合 (Join)
• リレーションシップ (Relationship)

移動 (Move)

Move 変換は、move パラメーター・マッピング・タイプと似ています。この変換では、ソース・ビジネス・オブジェクトのプリミティブ型の属性をターゲット・ビジネス・オブジェクトのプリミティブ型の属性に割り当てます。ストリングなどのプリミティブ型の属性を整数などのプリミティブ型の属性にマッピングできますが、ここで注意しておかなければならないのは、データが実行時に変換されないと例外が発生するということです。例えば、「123a」というストリングが整数にマッピングされている場合、サーバー・ログには NumberFormatException と表示されます。さらに、move パラメーター・マッピングとは異なり、Move 変換では複合型をマッピングすることはできません。ビジネス・オブジェクト間をマッピングする場合は、次に説明する Submap を使用する必要があります。

サブマッピング (Submap)

Submap は、ビジネス・オブジェクト間の変換に使用するもう 1 つのビジネス・オブジェクト・マップです。例えば図 8 の PO ビジネス・オブジェクトには、Address ビジネス・オブジェクトが含まれています。右側にある Order にも、Customer ビジネス・オブジェクトに Address が含まれています。Details タブでは、Address ビジネス・オブジェクト・マップによって Order/customer/address を PO/shipTo にマッピングするように指定しています。ソースとターゲットの型は同じ Address であるため、Submap は Address 属性を持つパラメーター間の Move 変換だけで構成されます。ここで、前述の extract パラメーター・マッピングを思い出す方もいることでしょう。PO が含まれるインターフェースに 1 つの PO パラメーターだけではなく、invoiceNum と shipToという2 つのパラメーターがあったとしたら、ここで extract パラメーター・マッピングを使用できます。

抽出 (Extract)

Extract 変換はこれに対応するパラメーター・マッピングとは多少異なり、ソース属性はストリングでなければなりません。Extract 変換は、ストリングを部分的に抽出して、これらの抽出部分を別のストリングや別のプリミティブ型に割り当てるために使用します。この変換についての注意事項は、Move 変換の場合と同じです。

例えば、図 9 に示す 2 つの Extract は、lastname, firstname 形式のストリングから名前と苗字を分けています。2 番目の Extract の詳細では、name string の最初のコンマまでの部分を Person オブジェクトの lastName 属性にコピーするように指定されています。サブストリング・インデックス (Substring index) によって、0 からストリングのどの部分までを使用するかが決まります。そのため、firstName の抽出の詳細は サブストリング・インデックスが 1 であるという点を除いて、lastName 抽出の詳細と同じになります (ストリングの 2 番目の部分である、最初のコンマと 2 番目のコンマの間にある文字が使用されます)。つまり、name 属性の値が「Smith, Joe」だとすると、firstName の値は「Joe」となり、lastName の値は「Smith」となります。

結合 (Join)

Join 変換は、複数のソース属性の値を組み合わせてターゲット属性にコピーします。Join 変換のターゲットは、ストリングでなければなりません。Join 変換は、Extract 変換の逆であると考えることができます。つまり、一連のストリング入力 (あるいは、1 つのストリングに変換されるその他すべてのプリミティブ型) を取得して 1 つのストリングに結合します。オプションで、ストリングを区切り文字で分離することもできます。

Extract 変換の例では、コンマで区切られたストリングを名前と苗字の属性に分けるマッピングを示しましたが、これと逆の方向でマッピングしなければならない場合もよくあります。図 10 に、Person ビジネス・オブジェクトから emp ビジネス・オブジェクトに逆方向でマッピングする方法を示します。firstName の値が「Joe」で、lastName の値が「Smith」の場合、firstName の区切り文字がコンマに設定されているため、name 属性の値は「Joe,Smith」となります。

Details タブの下部に表示された例を見ると、Join がどのように値を連結するかが分かります。区切り文字は、複数の文字で構成できることを覚えておいてください。Prefix およびPostfix フィールドには、結合されたストリングに追加する接頭辞と接尾辞となるストリングを入力できます。また、Reorder アイコンを使用して、属性を連結する順序を変更することもできます。

割り当て (Assign)

Assign 変換は、ターゲット属性に一定の値を設定します。図 11 に、Person の prefix 属性をヌルに設定する Assign 変換を示します。

カスタム (Custom)、カスタム割り当て、カスタム・コールアウト

ソース属性とターゲット属性間のマッピング・ロジックを指定する Java コードを作成するには、Custom 変換を使用します。ソース属性がない場合は、カスタム割り当て変換を使用します。これは、Java コードを使用して割り当てる値を計算するという点を除き、Assign 変換と同様です。一方、ターゲット属性がない場合には、カスタム・コールアウト変換を使用して値を初期化します。

リレーションシップ (Relationship)

リレーションシップ変換は、同じデータの名前や ID が異なる場合に使用します。リレーションシップ変換は、他のマッピングとは異なります。他のマッピングでは、同じデータを参照する異なる属性名やビジネス・オブジェクトを接続することを対象にしている一方、リレーションシップ変換はもう一歩進んで、異なるデータが同じ意味を持っている場合や、同じものを参照している場合も扱います。

リレーションシップ変換には、動的と静的の 2 つのタイプがあります。静的リレーションシップは、同じものを参照する異なる値を相関させます。このようなタイプの値は決して (あるいはめったに) 変更されません。典型的な例は行政区名で、あるシステムでは 2 文字の宛先 (ON など) を使用する一方、別のシステムではそれより長い略語 (Ont など) や、あるいはフルネーム (Ontario) を使用する場合があります。

属性間で静的リレーションシップを使用してデータをマッピングすると、リレーションシップ・エディターで作成したテーブルに従ってデータを変換することも可能になります。例えば、「ON」という値を持つあるビジネス・オブジェクトの州名属性を別のビジネス・オブジェクトの属性にマッピングして、「Ontario」という値を割り当てることができます。

動的リレーションシップは、主キーに基づいてデータを相関させます。次のような場合を考えてみてください。小売店のある製品の ID は、在庫追跡システム上にあり、別の製品の ID はサプライヤー・システム上にあります。一方、使用しているシステムの ID は汎用ビジネス・オブジェクトにあります。この汎用ビジネス・オブジェクトには、他のビジネス・オブジェクト内の ID に相当するデータだけでなく、どのデータが実際に同じであるかを追跡するために必要な情報も含まれています。例えば、値が「123」の itemNumber を (サプライヤーのインターフェースで使用されているビジネス・オブジェクトに含まれる) productCode にマッピングする際に、正しい商品がサプライヤー・システムから発注されるようにするため、「a234」という値を挿入する必要が生じたとします。WebSphere Process Server のリレーションシップ・マネージャーは、このようなケースに対処します。

「参考文献」セクションにリストした「WebSphere Process Server relationship service」の第 1 回と第 2 回では、この 2 つのタイプのリレーションシップ変換の使用方法を演習を通じて具体的に説明しています。

変数

再利用したいデータを保管するには、変数を作成します。変数は、前述した変換タイプそれぞれのソースであっても、ターゲットであっても構いません。例えば、ある値を多数のターゲットに割り当てるには、Assign を使用して値を変数に設定し、その変数から複数の属性への Move 変換を使用します。

一例として、図 12 に code という名前の変数を持つマップを示します。変数に入力されるのは orderInfo.code の値で、この値は、orderItems.code と shipTo.code で使用します。このマップを成功させるには、変数に対する Assign の実行順序 (変換タイプの左側にある数値によって示されています) が、変数のマッピング先となるターゲットの実行順序より先でなければならないことに注意してください。そうでないと、初期化されていない変数が使用されることになります。

上に戻る

ヒューマン・タスク

WebSphere Integration Developer は、異なるコンピューター・アプリケーションが互いに連動できるソリューションの開発を支援します。その一方で、統合情報システムの開発に人間との対話のサポートが必要になることも珍しくありません。

人間の関与には、いくつかの形があります。例えば、プロセスのインスタンスは人間が開始する必要があっても、開始後にはプロセス自体が自動的に実行するという場合があります。アプリケーションに組み込まれたロジックを処理することができないような例外的な場合は、あまりにも複雑または特殊であるため、人間が処理しなければならないかもしれません。また、何らかの理由で通常の処理が失敗したために、人間の介入が必要になることもあります。

開発者が、プロセスに人間を関与させなければならないと判断した場合、その機能の実装方法を決定する必要に迫られます。WebSphere Integration Developer にはヒューマン・タスク・コンポーネントが用意されているため、人間と SCA アプリケーションとの対話をサポートするために必要となる作業が大幅に単純化されます。

サービス指向アプリケーションでの人間の関与に関するシナリオとして、図 13 に 1 つのプロセスを示します。このプロセスでは、注文を処理する前に、人間がその注文を承認するかどうかを決定しなければなりません。

このシナリオには、以下の要件があります。

• ユーザーとデータをやり取りするメカニズム
• 非同期で長期間実行すること (人間がすぐに対応できない可能性があるため)
• 対話を可能にするインターフェース。複数のプロセス・インスタンスで一度に人間の関与が必要になる場合があるため、ユーザー・インターフェースが入力を待機中のプロセスを示すとともに、選択されたタスクの詳細を提供する必要があります。
• ユーザーに該当タスクを実行する権限があることを確認する方法

ヒューマン・タスクは上記の要件を満たし、スタンドアロン・コンポーネントをビジネス・プロセスやビジネス・ステート・マシンとまったく同じように提供します。また、インターフェースとビジネス・オブジェクトを使用してその他のコンポーネントと通信します。図 14 に、図 13 のプロセスが呼び出す ApprovalHumanTask というヒューマン・タスク・コンポーネントを示します。

一方、ヒューマン･タスク・コンポーネントは他のコンポーネントとは異なり、サポートするインターフェースは 1 つだけで、そのインターフェースには単一の操作しかない場合があります。これは、1 つのヒューマン・タスクは単一の対話だけを定義し、複数の対話には複数のヒューマン・タスクが必要になるという事実に反映されています。ファイル・フォルダーに例えると、フォルダーには該当タスクを識別し、そのタスクを完了するために必要な情報が含まれています。ユーザーが必要なコメントやデータをフォルダーのコンテンツに追加して、このフォルダーを戻します。

ヒューマン・タスクは本質的に非同期で、長時間実行します。人間がすべての要求をすぐに処理できると想定するのは非現実的なためです。それよりむしろ、人間の介入が必要なタスクは、人間が対応して完了するまでキューで管理されなければなりません。ファイル・フォルダーの例に当てはめて、処理を待機中のファイル・フォルダーが積み重なったトレイを想像してみてください。それぞれのファイル・フォルダーは、処理されて再提出できるようになるまでトレイに入ったままになります。

ヒューマン・タスクのタイプ

ヒューマン・タスクには以下の 3 つのタイプがあります。これらのタイプについて、以降のセクションで説明します。

• 参加型 (Participating)
• 開始型 (Originating)
• 純粋 (Pure)

参加型ヒューマン・タスク

参加型ヒューマン・タスクでは、図 14 の OrderProcessing のようなコンポーネントがヒューマン・タスク・コンポーネントを呼び出します。言い換えると、ヒューマン・タスクは作業の実行に参加します。

開始型ヒューマン・タスク

開始型ヒューマン・タスクは、他のコンポーネントを呼び出します。作業が割り当てられるのではなく、作業の実行プロセスを開始するということです。開始するヒューマン・タスクは、要求に対応する人間ではなく、要求を行う人間を表します。

純粋なヒューマン・タスク

純粋なヒューマン・タスクは、人間が要求するという点で開始型ヒューマン･タスクと似ています。ただし、純粋なヒューマン・タスクでは、コンピューター・アプリケーションではなく別の人間がサービス要求に対応します。この場合、アプリケーションが人間同士の対話を仲介します。

ヒューマン・タスクの作成

ヒューマン・タスクをモジュールに追加するには、File → New → Human Task を選択します。表示される New Human Task ウィザードで、まずタスクの名前とコンテナーを指定します。ウィザードの 2 番目と 3 番目のページでは、作成するタスクの種類を指示し、インターフェースを指定します。これで、新しく作成されたタスクを対象としたヒューマン・タスク・エディターが開始されます。

それでは、ヒューマン・タスクはどのように構成できるかを見ていきましょう。

スタッフ設定 (Staff settings) - 役割

ご想像のとおり、ヒューマン・タスクには、タスクを完了する資格と許可が与えられた特定の人間やグループのメンバーに関連付ける方法が必要となります。また、ヒューマン・タスクに役割 (潜在的所有者、読者など) を割り当て、特定のアクセス権を与えられるようにすることもできます。

クライアント設定 (Client settings)

WebSphere Process Server には、ヒューマン・タスク用の Web ベースのユーザー・インターフェース、BPC (Business Process Choreographer) Explorer が組み込まれています。このインターフェースは、テストと管理には適していますが、実世界のアプリケーションでのヒューマン・タスクのユーザー・インターフェース用としては設計されていません。タスクの内容を表示して、ユーザーが作業できるようにするには、開発者がカスタム・ユーザー・インターフェースを開発する必要があります。

WebSphere Integration Developer には 2 種類のユーザー・インターフェースの実装に対するサポートが組み込まれていますが、拡張機能を使用して追加することもできます。サポートされるユーザー・インターフェースのタイプは、JSP とポートレットです。エディターのクライアント設定域で、提供するインターフェースの種類を選択し、詳細域でインターフェースの実装を配置する場所を指定します。記事の終わりにある「参考文献」に、カスタム・インターフェースの実装についての詳細資料が記載されています。

エスカレーション設定 (Escalation settings)

ユーザーがタスクを要求するとき、そこには妥当な時間内にタスクを完了するという意図がありますが、時間内に完了できないという場合も珍しくありません。例えば、ユーザーが決定を下す前に追加資料を待っているというような場合です。タスクを呼び出しているプロセスが、特定期間内に応答が必要だとしたらどうなるでしょう。そのような場合に対応するため、ヒューマン・タスクでは特定期間内に要求または完了されないタスクに対してエスカレーションを実行することを開発者が指定できます。

ヒューマン・タスクが呼び出されると、その状態は準備済み (ただし、要求される前) または要求済みのいずれかになります。エスカレーションは、言わばビジネス・ステート・マシンのタイマーのようなものです。タスクがある状態になった場合、エスカレーションで指定された時間までにタスクがその状態を脱しないと、エスカレーションがトリガーされて指定されたアクションを実行します。一連のエスカレーションを指定して、期間が満了した時点や、タスクが特定の状態のままになっているときに、それぞれのエスカレーションをトリガーすることもできます。

ヒューマン・タスクのもう 1 つの状態として、サブタスク状態があります。ユーザーがタスクを要求するときに、そのタスクの一部を別のユーザーに代行させた場合、そのヒューマン・タスクはサブタスク状態となります。タスクの該当部分を確実に完了してタスク全体が続行できるようするには、サブタスク状態にエスカレーションを追加します。

図 20 に、タスクが 2 時間以内に終了しない場合に通知を送信するヒューマン･タスクを示します。Verb タブには、エスカレーションが発生した場合に通知する個人の名前が含まれます。以降のセクションでビルドするアプリケーションでは、エスカレーションについても説明します。ヒューマン・タスク・マネージャーの使用方法、そして独自のクライアントを開発してサブタスクを割り当て、エスカレーションに対応する方法については、記事の終わりにある「参考文献」セクションに記載した資料を参照してください。

インライン・ヒューマン・タスク

参加型ヒューマン・タスクのもう 1 つの形式として、個別のコンポーネントとしてではなく、インライン・ヒューマン・タスクとして存在するヒューマン・タスクをビジネス・プロセス内に定義できます。インライン・ヒューマン・タスクには、プロセス内からのみアクセスできます。このヒューマン・タスクの 1 つの利点は、プロセスのコンテキスト (変数の処理など) を使用して、プロセス内の複数のヒューマン・タスクに情報を共有させられることです。

上に戻る

すべてを組み立てる

インターフェースとビジネス・オブジェクトをマッピングしてヒューマン・タスクを呼び出す方法を理解するため、2 つのインターフェースをマッピングするプロセスを実演し、次にプロセスからヒューマン・タスクを要求する方法を説明します。最初のシナリオでは、注文処理システムがあり、出荷を扱うビジネス・パートナーがいることを前提とします。商品の出荷には、パートナーの Web サービスを使用します。モジュールで使用する Order ビジネス・オブジェクトには注文品を発送するのに十分な情報が含まれていますが、残念ながらフォーマットはパートナーの Web サービス入力とは互換していません。例えば、Order ビジネス・オブジェクトには CustomerInfo ビジネス・オブジェクトと Item オブジェクトのリストが含まれています (図 22)。

図 23 に、Web サービス・インターフェースにあるビジネス・オブジェクトを示します。図 24 を見ると分かるように、これらのビジネス・オブジェクトを使用するインターフェースも一致していません。

このシナリオでは、注文品は従業員の承認を得てからでないと出荷できません。タスクが特定の時間内に完了しない場合は、エスカレーションが発生します。説明を分かりやすくするため、ここではデフォルトを使って、誰でもタスクの要求やエスカレーションの処理を行えるようにします。

プロジェクト交換ファイル (記事の終わりにある「ダウンロード」セクションに記載) には、注文処理コンポーネントを持つモジュールが含まれています。このコンポーネントはビジネス・プロセスと一緒に実装され、ApproveOrder インターフェースと Shipping インターフェースをそれぞれ持つ ApproveOrder および ShippingPartner 参照があります。また、パートナーの Web サービスにアクセスする ShippingService WSDL ファイルが含まれるライブラリーもあります。

Business Integration ビューには、WSDL ファイル (Web サービスへのインターフェース) はその他のインターフェースと同じように表示されます。例えば、パラメーターの型 (WSDL メッセージ・パーツ) はビジネス・オブジェクトとして表示されます。さらに、ShippingService インターフェースを持つインポートがあり、これを使用して Web サービスを呼び出すことができます。

まず、サポートするコンポーネント、インターフェース、およびビジネス・オブジェクトが含まれるプロジェクト交換ファイルをインポートするところから始めましょう。

1. 記事の終わりにある「ダウンロード」セクションから、mappingexamplebegin.zip ファイルをダウンロードします。
2. File → Import → Project Interchange の順にクリックし、Next をクリックします。
3. Browse をクリックして、先ほどダウンロードした mappingexamplebegin.zip ファイルまでブラウズし、Open をクリックします。この zip ファイルは、プロジェクト交換ファイルです。
4. Select All にチェック・マークを付けてから、Finish をクリックします。インポートされたモジュールが Business Integration ビューに表示され、プロジェクトがビルドされるので、ワークベンチの右下隅にプロジェクトがビルドの最中であることを示す Building workspace というメッセージが表示されます。ワークスペースのビルドが完了するまで待ちます。

ヒューマン・タスクを実装する

ワークスペースがビルドされたら、次に New Human Task ウィザードでヒューマン・タスクを作成し、ApproveOrder インターフェースを実装します。

1. MappingExample プロジェクトの下にある Business Logic カテゴリーを右クリックし、New → Human Task を選択します。
2. 名前には ApprovalHumanTask と入力して、MappingExample モジュールに追加します。Next をクリックします。
3. デフォルト設定の Participating Human Task は変更せずに、Next をクリックします。
4. Select an existing Interface が選択されていることを確認し、インターフェースに ApproveOrder を選択して Finish をクリックします。

ApprovalHumanTask を対象としたヒューマン・タスク・エディターが開きます。ここで、必要なプロパティーを設定します。

1. Client settings セクションで Client settings を右クリックし、Add → BPC Explorer を選択します。
2. Escalation セクションで Claimed を右クリックし、Add → Escalation を選択します。
3. エスカレーションの Properties ビューにある Details タブで、Expected task 状態として Fnished が選択されていることを確認し、Duration until escalated に 2mins と入力します。
4. エディターの内容を保管します。

次の手順で、OrderProcessing コンポーネントがこの新しいヒューマン・タスクを参照できるようにします。

1. MappingExample - Mapping example をダブルクリックして、アセンブリー・エディターを開きます。
2. Human Tasks カテゴリーにある ApprovalHumanTask を選択し、アセンブリー・ダイアグラムにドラッグします。
3. OrderProcessing コンポーネントの OrderApprovalPartner 参照を ApprovalHumanTask に接続します (図 25)。
   
   図 25. MappingExample アセンブリー・ダイアグラム
   
   
   
   

インターフェース・マップを作成する

図 25 のアセンブリー・ダイアグラムを見ると、OrderProcessing は ShippingService を呼び出すことから、OrderProcessing 参照は Shipping service インポートに接続しなければなりません。ここで、ソース・インターフェースとターゲット・インターフェースが一致しない場合に接続を作成しようとするとどうなるかを見てみましょう。

1. OrderProcessing コンポーネントの右側にある参照にマウスのポインターを重ねます。
2. 表示されたハンドルを ShippingService コンポーネントにドラッグします。すると、Add Wire ボックスが開きます。

これは、アセンブリー・エディターが、ユーザーがインターフェースの異なるソースとターゲットを接続しようとしていることを検出したためです。これによって開いた Add Wire ダイアログ・ボックス (図 26 に示す) で、インターフェース・マップを作成するか、適切なインターフェースをインポートに追加するかを選択できます。次の手順で、インターフェース・マップの作成を開始します。

1. OK をクリックして Add Wire ダイアログ・ボックスを閉じます。このステップによって、新しいインターフェース・マップが作成されます (図 27)。
2. OrderProcessingToShippingServiceMap をダブルクリックしてインターフェース・マッピング・エディターを開きます。

次の手順で、OrderProcessing インターフェースと ShippingService インターフェース間のマッピングを定義します。

1. インターフェース・マッピング・エディター内の placeOrder 操作インターフェース (図 28に表示) にマウスのポインターを重ね、表示されたハンドルを shipOrder 操作にドラッグします。
2. 2 つのインターフェース間に作成した接続をクリックして、それぞれのインターフェースのパラメーターを表示します。
3. マウスのポインターを order パラメーターに重ね、ハンドルを shipTo パラメーターに接続します。

これで、order パラメーターと shipTo パラメーターのマッピングが作成できました。デフォルトで、マッピング・タイプは move に設定されています。ただし、order パラメーターの属性を shipTo パラメーターと orderInfo パラメーターにマッピングするには、ビジネス・オブジェクト・マップが必要です。

1. move マッピング・タイプにマウスのポインターを重ねて、ハンドルを orderInfo パラメーターにドラッグします。
2. move タイプのマッピングを選択し、Properties ビューで Description タブを開きます。
3. Parameter Mapping Type を map に変更します。
4. 同じようにして、shipOrder 操作の orderNumber パラメーターを placeOrder 操作の orderNumber パラメーターに接続します。マッピング・タイプは move のままにします。
5. エディターの内容を保管します。

この時点で、インターフェース・マップは図 28 に示すようになっているはずです。マップ接続には赤い X 印がありますが、これはビジネス・オブジェクト・マップがまだ定義されていないためです。次の手順で、ビジネス・オブジェクト・マップを作成します。

ビジネス・オブジェクト・マップを作成する

1. このマップを対象とした Properties ビューで Details タブを選択し、Business Object Map の横にある New をクリックします。
2. 表示された New Business Object Map ダイアログ・ボックスで、Name に PlaceOrderToShipOrderMap と入力して Next をクリックします。
3. 入力には Order ビジネス・オブジェクトが選択されていること、そして出力には destination と order が選択されていることを確認します (図 29)。これらの型は、マッピング対象として選択したソース (入力) とターゲット (出力) の各パラメーターに対応します。

1. Finish をクリックします。
2. PlaceOrderToShipOrderMap が、Business Object Map の設定値として表示されます。表示されない場合は、インターフェース・エディターを保管していったん閉じてからもう一度開き、リストから PlaceOrderToShipOrderMap を選択します。

これで空のビジネス・オブジェクト・マップが作成されたので、Order ビジネス・オブジェクトを Destination と Oder の各ビジネス・オブジェクトにマッピングします。次の手順に従って、さまざまなビジネス・オブジェクトの成果物同士をマッピングします。

1. このマップを対象としたビジネス・オブジェクト・マップ・エディターをまだ開いていない場合は、インターフェース・マッピング・エディター内の map タイプのマッピングをダブルクリックして開きます。
2. ビジネス・オブジェクト・マップ・エディターで、左側の Order ビジネス・オブジェクト内の items を、右側の order ビジネス・オブジェクト内の items に接続します。どちらの items もビジネス・オブジェクトであるため、Submap 変換が自動的に作成されます。
3. Submap 変換を対象とした Properties ビューの Details タブで、ビジネス・オブジェクト・マップの横にある New をクリックし、名前に ItemsMap と入力して Next をクリックします。
4. 入力には Item (名前空間 http://MappingExample/ が追加) が選択されていること、そして出力には item (名前空間 http://e.z.orders.com/ が追加) が選択されていることを確認します。
5. Finish をクリックします。
6. ItemsMap 用に開いたビジネス・オブジェクト・マップ・エディターで、図 31 に示すように属性を接続します。
7. サブマップ・エディターの内容を保管して、PlaceOrderToShipOrderMap エディターに戻ります。

これで、Submap 変換が実装されました (図 32)。次に、destination 情報に含まれる属性をマッピングします。

1. 左側の Order ビジネス・オブジェクトに含まれる firstName と lastName を、右側の destination に含まれる firstname と lastname にそれぞれ接続します (まだ展開されていない場合は、まず customerInfo を展開してください)。
2. 左側の Order に含まれる street、city、state、および zip を、右側の destination に含まれる address に接続します。これで、4 つのソース属性が 1 つのターゲット属性にマッピングされます。

この時点で、マップは図 32 のようになっているはずです。多数の属性を 1 つのターゲット属性に接続すると、エディターが Join 変換を作成し、すべてのターゲットを Join の入力として転送することに注意してください (ソース属性を直接 Join に接続することもできます)。

大規模なビジネス・オブジェクトの場合、マップはかなり複雑になりやすいため、どの属性がどこにマッピングされているのか見分けにくくなります。このため、ビジネス・オブジェクト・マップ・エディターでは、異なるビューでマップを表示できるようになっています。図 32 では変換がターゲットを基準にソートされているため、変換のソースがどこだか分かりにくくなっていますが、図 33 に示すマップでは、ソースを基準に変換がソートされています。

次の手順では、address 属性にマージする際に 4 つの属性をカスタマイズします。

1. Join 変換を対象とした Properties ビューで Details タブを開きます。
2. street、city、および state の区切り文字として「, 」(引用符を抜かしたコンマとスペース) を入力します。区切り文字を追加すると、図 34 の下部に示すように Example が更新されるため、マージされた属性がどのように表示されるかを確認できます。

これで手順は完了です。今度は以下の手順に従って、アプリケーションをテストします。

アプリケーションをテストする

1. MappingExample のアセンブリー・エディターに戻り、OrderProcessing、ApprovalHumanTask、および OrderProcessingToShippingServiceMap コンポーネントを選択します (Ctrl キーを押しながら各コンポーネントをクリックします)。
2. 選択したコンポーネントのいずれかを右クリックし、Test Components を選択します。これによって、統合テスト・クライアントが開きます。ShippingService はテスト対象として選択されていないため、エミュレーション対象となります。(ShippingService WSDL ファイルで記述された Web サービスは実際には存在しません。ツールを試しに使って作成してみてください)。テスト・クライアントの下部にある Configuration タブに切り替えると、Emulators の下に ShippingService がリストされていることを確認できます。
3. コンポーネント名として OrderProcessing が選択されていることを確認します。
4. Initial request parameters セクションの items の行を右クリックし、Add Element を選択して、Item ビジネス・オブジェクトを order の items リストに追加します。
5. それぞれの値フィールドに、例えば図 35 のような任意の値を入力し、Continue をクリックします。
6. デプロイメント場所の選択を求めるプロンプトが表示されたら、任意の WebSphere Process Server を選択して OK をクリックします。

アプリケーションがサーバーにデプロイされます。プロセスは最終的に、ヒューマン・タスクが呼び出される時点で停止します。

1. Server ビューでサーバーを選択し、Launch コンテキスト・メニューから Launch BPC Explorer を選択します。
2. My Tasks を選択します。タスク・リストに、該当タスクが完了を待機中であることが示されます (図 37)。タスクの横にあるボックスにチェック・マークを付け、Work on をクリックしてタスクを要求します。
   
   
   
   図 37. 要求を待機中のタスク・インスタンスのリスト
   
   
   
3. Available Actions の下にある Complete (図 38 を参照) はクリックしないで、エスカレーションがトリガーされるまで 2 分間待ちます。
   
   
   図 38. タスクの完了
   
   
   

タスクは要求済み状態になり、エスカレーションが発生するまで、あるいは元のタスクが完了するまでその状態のままになります。タスクが要求済み状態から完了状態へ移行するまでのエスカレーションの期間は 2 分に設定されているため、2 分が経過すると、タスクがエスカレーション・リストに表示されます。

1. BPC Explorer の左側にある My Escalations をクリックします。
2. ApprovalHumanTask をクリックし、続いて Work on をクリックします。図 38 と同じページが表示されます。
3. Complete をクリックします。

タスクが表示され、入力データを示してユーザーからの入力待機状態になります。Complete をクリックしてデフォルト値の true に戻します。

次に、ShippingService インポート (エミュレーション対象) の出力パラメーターに値を入力するよう求めるプロンプトが表示されます。図 39 に示すように、前の手順で入力した情報が shipTo パラメーターと orderInfo パラメーターにマッピングされていることに注意してください。プロセスを完了するには、orderNumber に任意の値を入力して Continue をクリックします。これで、ShippingService インターフェースの orderNumber パラメーターが OrderProcessing インターフェースの orderNumber パラメーターに再びマッピングされます。

上に戻る

まとめ

ヒューマン・タスク、インターフェース・マップ、そしてビジネス・オブジェクト・マップは、WebSphere Integration Developer に用意された各種コンポーネント・タイプを補うために役立ちます。この記事では、ヒューマン・タスクの主要な概念とさまざまなマッピング・タイプを紹介し、注文処理アプリケーションでの使用方法を説明しました。

上に戻る

ダウンロード

内容	ファイル名	サイズ	ダウンロード形式
MappingExample module	mappingexamplebegin.zip	15 KB	FTP|HTTP
Complete MappingExample module	mappingexamplecomplete.zip	19 KB	FTP|HTTP

ダウンロード形式について

参考文献

学ぶために

• A guided tour of WebSphere Integration Developer -- Part 1: Get a driver's view of the WebSphere Integration Developer landscape
  
  
• A guided tour of WebSphere Integration Developer -- Part 2: SOA development with WebSphere Integration Developer
  
  
• A guided tour of WebSphere Integration Developer -- Part 3: Building a simple service-oriented application
  
  
• A guided tour of WebSphere Integration Developer -- Part 4: Unleashing visual snippets and business state machines in your service-oriented application
  
  
• A guided tour of WebSphere Integration Developer -- Part 5: Business processes in a service-oriented world
  
  
• WebSphere Integration Developer のガイド・ツアー-- 第 6 回: 動的ビジネス・ルールを使用して一層オンデマンドに対応
  
  
• WebSphere Process Server relationship service, Part 1: Static relationships
  
  
• WebSphere Process Server relationship service, Part 2: Dynamic relationships
  
  
• How to embed a new client type into the human task editor
  
  
• Installing and starting Business Process Choreographer Explorer
  
  
• XML Path Language (XPath)
  
  
• Business Process Choreographer Samples (Human Task Features と Interaction with Processes → Custom JSF Client を選択してください。)
  
  
• WebSphere Process Server V6.0 Business Process Choreographer Programming Model (セクション 6.3 の「Human Task Editor」)
  
  
• Business Process Execution Language for Web Services version 1.1
  
  
• Business Process with BPEL4WS: Understanding BPEL4WS
  
  
• WebSphere Integration Developer 製品情報
  
  
• WebSphere Process Server 製品情報
  
  
• WebSphere Process Server: IBM's new foundation for SOA
  
  
• Build a Hello World SOA application
  
  
• Service Component Architecture
  
  
• Common Event Infrastructure
  
  
• developerWorks: WebSphere Process Server および WebSphere Integration Developer 資料
  
  
• developerWorks: WebSphere Business Integration zone
  
  
• developerWorks: WebSphere development tools ゾーン
  
  
• Meet the experts: WebSphere Integration Developer
  
  

製品や技術を入手するために

• WebSphere Business Modeler 試用版をダウンロードしてください。
  
  
• Rational Application Developer 試用版をダウンロードしてください。
  
  

議論するために

• WebSphere Integration Developer フォーラム
  
  
• developerWorks ブログ
  
  

著者について

Richard Gregory は、IBM Toronto Lab で WebSphere Integration Developer チームのソフトウェア開発者として活躍しています。WebSphere Integration Developer 用のテスト・ツールの展開と提供などに取り組んでいます。

Randy Giffen は、IBM Ottawa Lab で WebSphere Integration Developer チームの顧問ソフトウェア開発者として活躍しています。担当は、WebSphere Integration Developer のビジネス・ステート・マシン・ツールとビジュアル・スニペット・エディターです。それ以前は、WebSphere Studio Application Developer Integration Edition、Eclipse、および VisualAge for Java のユーザー・インターフェース・チームのメンバーでした。

Jane Fung は、IBM Canada Ltd. の顧問ソフトウェア開発者で、WebSphere Integration Developer の BPEL (Business Process Execution Language) およびビジネス・ルール・デバッガーを担当しています。それ以前は、WebSphere Studio Technical Support チームのチーム・リーダーでした。

Greg Adams は、賞を獲得した Eclipse プラットフォーム・ユーザー・インターフェースの主任アーキテクトとして活躍した経歴を持ち、最近では、WebSphere Studio Application Developer Integration Edition および WebSphere Integration Developer をはじめとしたコア WebSphere Business Integration Tools の主任アーキテクト兼開発リーダーとして迎えられています。IBM 初のサービス指向アーキテクチャー (SOA) ツール・スタック、そして Business Process Editor 対応の最初の BPEL4WS 標準を実現しました。いずれも、IBM のオンデマンド・ストラテジーのサポートには欠かせないものです。

この記事を評価する

コメント

上に戻る

目次

• はじめに
• インターフェース・マップ
• ビジネス・オブジェクト・マップ
• ヒューマン・タスク
• すべてを組み立てる
• まとめ
• ダウンロード
• 参考文献
• 著者について
• コメント