ビジネス プロセスの定義
異なるシステム間でのメッセージ交換は、BizTalk Serverが対処する問題を解決する上で必要な部分です。 ただし、実際の目標は、アプリケーションに基づいてビジネス プロセスを定義および実行することになります。 BizTalk Server エンジンはオーケストレーションを使用して、これらのビジネス プロセスのロジックを定義します。 また、ビジネス ルールのグループを作成および評価するには、ビジネス ルール エンジンを使用します。 ここでは、オーケストレーションとビジネス ルール エンジンの両方について説明します。
オーケストレーションの使用
自動化されたビジネス プロセスのロジックは、Microsoft Visual Basic または Microsoft Visual C# などの言語で直接実装できます。 ただし、従来のプログラミング言語を使用した場合、複雑なビジネス プロセスの作成、保守、および管理は困難になることがあります。 前任者とは異なり、BizTalk Serverは異なるアプローチを取ります。 これにより、ビジネス マネージャーまたは開発者はビジネス プロセスをグラフィカルに定義できます。 グラフィカルなビジネス プロセスの作成は、プログラミング言語で直接作成するよりも速く、プロセスの理解、説明、変更も容易です。 この方法で作成されたビジネス プロセスは、監視もより簡単になります。監視は、ビジネス アクティビティ監視 (BAM) テクノロジを利用して行います。
開発者はオーケストレーションを作成する場合、3 つの主要なツールを利用します。XML スキーマを作成するには BizTalk エディタを、これらのスキーマ間での変換を定義するには BizTalk マッパーを、ビジネス プロセスのロジックを指定するにはオーケストレーション デザイナを利用します。 これらのツールはすべて Visual Studio 内でホストされ、開発者に一貫した環境を提供します。 このセクションでは、これらの各ツールが何を行うか、およびこれらのツールがどのように連動するかについて説明します。
スキーマの作成: BizTalk エディター
オーケストレーションは、何らかの XML スキーマに準拠した各 XML ドキュメントに基づいて機能します。 開発者は BizTalk エディタを使用して、これらのスキーマを定義できます。スキーマは基本的にドキュメント情報の構造と種類を定義するもので、ここでは XSD (XML Schema Definition) 言語を使用して定義します。
ツールのサポートなしで生の XSD スキーマを作成することは簡単ではありません。 ユーザー (通常は開発者) にとってこの必須の手順を容易にするために、BizTalk エディタでは、グラフィカルな階層でスキーマの要素を定義してスキーマを構築できるようになっています。 また、ファイルやアクセス可能な Web サービスから既存のスキーマをインポートすることもできます。 どのような方法で取得した場合も、スキーマは BizTalk のマップのベースとして使用されます。
スキーマ間のマッピング: BizTalk マッパー
通常、ビジネス プロセスを実装するオーケストレーションは、特定のドキュメントを受信し、特定のドキュメントを送信します。 多くの場合、受信したドキュメント内の情報の一部が送信されたドキュメントに転送され、おそらく何らかの方法で変換されます。 たとえば、注文調達プロセスでは、いくつかの商品が受注された後、何らかの理由で注文が拒否されたことを示すメッセージが返されることがあります。 このとき、要求 ID や注文数など注文時に提供された情報が、適宜、受注メッセージのフィールドから拒否メッセージのフィールドにコピーされます。 BizTalk マッパーは、あるドキュメントから他のドキュメントへの変換、つまりマップを定義するときに使用できます。
上の図に示すように、それぞれのマップは、2 つの XML スキーマ間のグラフィカルな関連付けとして表されます。マップによって、これらのスキーマの要素間の関係が定義されます。 World Wide Web Consortium (W3C) は、XML スキーマ間でこれらの種類の変換を表す標準的な方法として拡張スタイルシート言語変換 (XSLT) を定義しているため、BizTalk Serverのマップは XSLT 変換として実装されます。
マップで定義する変換には、あるドキュメントから別のドキュメントに値をそのままコピーするなどの単純なものを指定できます。 このような、データの単純なコピーはリンクを使用して表されます。BizTalk マッパーでは、リンクは変換元スキーマの要素と変換先スキーマの対応要素を結ぶ線として表示されます。 また、Functoid を使用して、より複雑な変換を指定することもできます。 Functoid は実行可能コードの集合で、XML スキーマ間の任意の複雑なマッピングを定義できます。上に示すように、BizTalk マッパーでは、Functoid は変換される要素間を結ぶ線上の四角形として表示されます。 これらの変換の一部はかなり一般的であるため、BizTalk Serverには多数の組み込み Functoid が含まれています。 これらの組み込みの Functoid は、次のカテゴリに分類されます。
数値演算 Functoid。送信元ドキュメントのフィールドの値の追加、乗算、除算、および送信先ドキュメントのフィールドへの結果の格納などの操作を実行します。
変換 Functoid。数値を対応する ASCII 値に変換します。また、その逆の処理を行います。
論理 Functoid。要素や属性を送信先ドキュメントに作成する必要があるかどうかを判断するために使用します。判断は、送信元ドキュメントで指定された値の論理比較に基づいて行われます。 これらの値は、等しい、大きい、小さい、またはその他の基準で比較できます。
累積 Functoid。送信元ドキュメントのさまざまなフィールドから、平均値、合計値、またはその他の値を算出し、送信先ドキュメントの 1 つのフィールドに結果を格納します。
データベース Functoid。データベースに格納されている情報にアクセスします。
カスタム Functoid を作成することもできます。カスタム Functoid は、XSLT で直接作成するか、Visual C# や Visual Basic などの .NET 対応言語を使用して作成できます。 また、1 つの Functoid の出力を別の Functoid の入力とすることで、Functoid を順に組み合わせることもできます。
ドキュメントの XML スキーマを定義する手段と、スキーマの異なるドキュメントの間で情報をマップするメカニズムを用意しておくことは非常に重要です。 BizTalk エディターと BizTalk マッパーは、これら 2 つの問題に対処します。 ただし、スキーマの定義とマップはプロセスの一部であり、 さらに、スキーマを使用してマップを呼び出すビジネス ロジックを指定することも必要です。
ビジネス ロジックの定義: オーケストレーション Designer
ビジネス プロセスとは、ビジネスの有益なニーズを満たすアクションのセットです。 BizTalk Serverを使用すると、開発者はオーケストレーション Designerを使用してこれらのアクションをグラフィカルに定義できます。 開発者は、各ステップをプログラミング言語で記述するのではなく、オーケストレーションを作成して、論理的な方法で一連の図形を接続します。 オーケストレーション デザイナでは、次の図形を使用できます。
受信図形。オーケストレーションでメッセージを受信することを示します。 受信図形には、受信するメッセージの種類を定義するフィルタを設定できます。さらに、新しいメッセージが到着したときにオーケストレーションの新しいインスタンスを開始するよう構成することもできます。
送信図形。オーケストレーションでメッセージを送信することを示します。
ポート図形。メッセージの送信方法を定義します。 ポート図形の各インスタンスは、送信図形または受信図形のどちらかに接続する必要があります。 各ポートには、種類、方向、バインドを指定します。種類では、ポートがどのようなメッセージを受信できるかを示し、方向では、送信や受信などを示します。バインドでは、メッセージの送信または受信方法を示します。たとえば、特定の URL やその他の情報を指定します。
判断図形。if-then-else ステートメントを表します。オーケストレーションがブール値条件に基づいて異なるタスクを実行することを示します。 この条件ステートメントは、オーケストレーション デザイナに含まれている式エディタを使用して指定できます。
ループ図形。条件が True の間、繰り返し実行されるアクションを制御します。
メッセージの構築図形。メッセージを構築できます。
変換図形。1 つのドキュメントの情報を、BizTalk マッパーで定義されたマップを呼び出して変換し、別のドキュメントに転送できます。
並列アクション図形。開発者は、複数の操作を順番に実行するのではなく、並列して実行する必要があることを指定できます。 並列アクション図形の後に続く図形は、すべての並列アクションが完了するまで実行されません。
スコープ図形。操作をトランザクションにまとめ、エラー処理の例外ハンドラを定義できます。 従来のアトミックなトランザクションと長時間実行されるトランザクションの両方がサポートされます。 長時間実行されるトランザクションでは、アトミックなトランザクションとは異なり、予期しないイベントの処理にロールバックではなく補正ロジックが使用されます。
メッセージの割り当て図形。オーケストレーション変数に値を割り当てることができます。 この変数は、オーケストレーションで使用される状態情報を格納するために使用できます。たとえば、作成メッセージや文字列などを格納できます。
下の図は、オーケストレーション デザイナでこれらの図形をいくつか使用して作成したオーケストレーションを示しています。 この例は、メッセージを受信して、メッセージの内容に基づき決定を行い、決定の結果として 2 つのパスのうち 1 つを実行するという単純なものです。 実際の問題を解決するオーケストレーションは、これよりも大幅に複雑になる可能性があります。これらのより複雑な図を操作しやすくするために、オーケストレーション Designerには拡大/縮小機能が含まれています。開発者は、現在関心のあるオーケストレーションの部分のみを表示できます。
開発者がオーケストレーションを定義したら、図形のグループと図形間の関係を、.NET Framework の共通言語ランタイム (CLR) で使用される MSIL (Microsoft Intermediate Language) に変換します。 BizTalk Server の開発者が定義した図形のグループは、最終的に .NET 対応の標準アセンブリになります。 また、必要に応じて明示的なコードをオーケストレーションに追加することもできます。これには、図形内部から COM オブジェクトまたは .NET オブジェクトを呼び出します。
Web サービスの役割
Web サービスを使用すると、SOAP によってアプリケーション間の XML ドキュメントを交換できます。このことは、統合プラットフォームに大きな影響を与えます。 外部 Web サービスにアクセスするために、オーケストレーションの作成者は、Visual Studio の [Web 参照の追加] オプションと Web サービス アダプターを使用して、操作を直接呼び出すことができます。 同様に、BizTalk Serverは、1 つ以上のオーケストレーションの操作を SOAP 呼び出し可能な Web サービスとして公開する ASP.NET Web サービス プロジェクトを生成できる Web サービス発行ウィザードを提供します。 この 2 つの方法を使用すると、開発者はビジネス プロセス内部から既存の Web サービスにアクセスすることも、オーケストレーションの機能を Web サービスとして他のビジネス プロセスに公開することもできます。
Web サービスが普及するにつれ、ビジネス プロセスの定義方法も変化します。 たとえば、Web サービスを使用して連携する 2 つの組織があるとします。 効果的に相互運用するには、相手が使用しているビジネス プロセスに関する情報を各パーティが知る必要がある場合があります。 両方の組織がBizTalk Serverを使用している場合、これは大きな問題ではありません。取引先管理テクノロジなどのツールを使用して、この知識を配布できます。 しかし、これらの組織が異なる製品を使用している場合などは、 ベンダに依存しない方法でビジネス プロセスの側面を記述する方法があると便利です。
Microsoft、IBM、およびその他の企業では、このような処理を行うために、BPEL (Business Process Execution Language) を開発しました。 オーケストレーション Designerを使用して定義されたビジネス プロセスは BPEL にエクスポートでき、BizTalk Serverは BPEL で定義されたプロセスをインポートすることもできます。 BPEL はビジネス プロセスの外部から参照可能な部分を記述したり共有する場合に便利です。BPEL の主な目的は、クロスプラットフォームでビジネス プロセス全体を実行することよりも、この問題を解決することです。 また、BPEL は Web サービス上に完全に構築されていますが、この言語をサポートするBizTalk Serverやその他の製品ではさらに多くの機能が提供されることを理解しておくことも重要です。 たとえば、BizTalk Serverでは、さまざまな XML スキーマ間のマッピング、ローカル オブジェクトでのメソッドの呼び出し、BPEL で使用できないその他の機能がサポートされています。 他にもさまざまな理由から、BPEL はビジネス プロセスを定義するための言語としては完璧ではありません。 BPEL がまだ OASIS (Organization for the Advancement of Structured Information Standards) による標準化の途中段階にあるという点も考慮すると、現時点で BPEL が完全に成熟したテクノロジであると言うことはできません。
オーケストレーションは、BizTalk Server でビジネス プロセスを作成するための基本的なメカニズムです。 ただし、オーケストレーション内には、他に比べて頻繁に変更される部分があります。 特に、ビジネス プロセスに埋め込まれている決定部分、つまりビジネス ルールは、通常最も変更されやすい部分です。 マネージャーの使用制限は先週$100,000でしたが、彼女のプロモーションはこれを最大50万ドルに引き上げるか、支払いが遅い顧客の最大許容注文数が100ユニットから10ユニットに減少します。 ビジネス ルール エンジンを使用して、これらのルールを指定および更新できます。
ビジネス ルール エンジンの使用
オーケストレーション デザイナと BizTalk エディタおよび BizTalk マッパーを使用すると、ビジネス プロセスおよびビジネス プロセスで使用されるルールを効率的に定義できます。 しかし、ビジネス ルールをより簡単な方法で定義および変更できるようにするため、 BizTalk Server にはビジネス ルール エンジン (BRE) が用意されています。 開発者が最も多く使用するのは BRE ですが、よりビジネス指向の強いユーザーであれば、ビジネス ルール作成ツールと呼ばれるツールを使用してビジネス ルールのセットを作成および変更できます。
BRE が役立つ状況としては、ビジネス ルールの複雑なセットの評価が必要とされる状況が挙げられます。 たとえば、貸し付けを行うかどうかを決定するときには、顧客の信用利用の履歴、収入、およびその他の要因に基づく大きなルール セットを検討する必要があります。 同様に、生命保険商品を申請者に販売するかどうかを決定するときには、申請者の年齢、性別、健康状態などさまざま要素を考慮する必要があります。 これらすべてのルールを、オーケストレーションの判断図形などを使用し条件ステートメントとして表現することは可能ですが、実装は非常に複雑になります。 このようにルール数が多いプロセスの場合は、BRE を使用することによって開発者の作業が単純になります。
BRE を使用すると、開発者は必要に応じてすばやく簡単にルールを変更できます。 これとは逆に、オーケストレーション内部に実装されているビジネス ルールを変更するには、多くの作業が必要になります。 開発者は、まず Visual Studio でオーケストレーションを開き、適切な図形 (および呼び出す .NET または COM オブジェクト) を変更してから、変更されたアセンブリをビルドして配置する必要があります。 この作業を行うには、オーケストレーションが含まれている BizTalk Server アプリケーションを停止して再起動する必要もあります。 代わりに BRE を使用してこのビジネス ルールを実装している場合は、何も再コンパイルまたは再起動せずに、ビジネス ルールを変更できます。 ビジネス ルールを変更するには、ビジネス ルール作成ツールを使用して目的のルールを変更し、新しいルールのセットを再展開するだけです。 変更はすぐに適用されます。 通常、オーケストレーションは開発者が作成および管理しますが、ビジネス ルールは簡単に読み取れる場合もあり、技術担当者が介入しなくてもビジネス アナリストが変更できる場合もあります。
通常、ビジネス ルールのセットの作成者は、最初にビジネス ルール作成ツールを使用して、ルールの指定に使用するボキャブラリを定義します。 ボキャブラリの各用語では、特定の情報に対するユーザー フレンドリ名を指定します。 たとえば、ボキャブラリで、出荷数、項目の最大数量、承認制限などの用語を定義します。 これらの用語には、定数を設定したり、XML スキーマ内 (したがって受信メッセージ内) の特定の要素や属性、またはデータベースに対する SQL クエリの結果へのマッピングを指定することができます。また、.NET オブジェクト内の値へのマッピングも指定できます。
ボキャブラリを定義したら、ビジネス ルール作成ツールを使用して、このボキャブラリを使用するビジネス ポリシーを作成できます。 各ポリシーには、1 つ以上のビジネス ルールを含めることができます。 各ルールでは、ボキャブラリで定義した用語を、より大きい、より小さい、等しいなどの論理演算子と共に使用して、ビジネス プロセスの動作方法を定義します。 ビジネス ルールでは、受信 XML ドキュメント内に含まれる値を送信 XML ドキュメント内に作成される値にどのように使用するかや、これらの値をデータベースに書き込む値にどのように反映するかなどを定義できます。
ビジネス ポリシーを実行するには、オーケストレーションでルールの呼び出し図形を使用します。 この図形によって、BRE のインスタンスが作成され、実行するポリシーが指定された後、受信する XML ドキュメントなどポリシーに必要な情報が渡されます。 BRE は、 を使用してプログラムで呼び出すこともできます。NET ベースのオブジェクト モデル。これにより、BizTalk Serverを使用しないアプリケーションから呼び出すことができます。 つまり、Windows フォーム アプリケーション、Web サービスを公開するソフトウェア、および .NET Framework で構築されたその他のアプリケーションでは、問題の解決に BRE を使用できる可能性があります。
ボキャブラリとビジネス ルールは両方とも、ここで説明する例よりはるかに複雑で強力です。 しかし、ボキャブラリを定義して、ボキャブラリを使用するルールのセットを定義するという考え方は、ビジネス ルール エンジンの中核になります。