BizTalk Server メッセージ
BizTalk Serverは、その中核となるメッセージ処理エンジンです。 BizTalk Serverの詳細を理解するには、メッセージとそのメッセージがBizTalk Serverによってどのように表され、格納され、処理されるかを理解することが重要です。 メッセージの概要を理解すると、BizTalk Server でのメッセージ処理の詳細が理解しやすくなります。
BizTalk Server の各メッセージは、マルチパート メッセージと見なされ、0 個以上の部分で構成されます。 1 つ以上の部分で構成される各メッセージには、ボディ部として認識される部分があります。 各部分は、バイナリ データで構成され、XML ドキュメント、フラット ファイル、シリアル化された .NET クラス、または他のバイナリ ストリームのデータを表すことができます。 メッセージのボディ部を使用して、ルーティングに使用できるメッセージの種類を確認します。
理解すべき非常に重要な概念は、すべてのメッセージがBizTalk Serverで不変であるということです。 つまり、いったん構築したメッセージは、変更することができません。 メッセージがメッセージ ボックス データベースに格納されると、メッセージは構築されたと見なされます。 メッセージを変更するには、新しいメッセージを作成して、使用する必要があります。 これは、オーケストレーション デザイナーで特に明白です。オーケストレーション デザイナーでは、コンパイル ルールを使用して、メッセージを使用する前にメッセージの構築に関する厳密なガイドラインに従います。また、構築ブロックの外部でのメッセージの変更を許可しません。 メッセージを変更する必要がある場合、同じ種類のメッセージを作成する新しい構築ブロックを作成し、元のメッセージを新しいメッセージにコピーし、構築ブロックから出る前に新しいメッセージに変更を加える必要があります。
メッセージ プロパティ
メッセージを構成する部分に加えて、システム内の各メッセージには、 メッセージ コンテキストと呼ばれる一連のプロパティがあります。 これらのプロパティは、メッセージから抽出される値またはメッセージに関連する値です。 たとえば、アダプターは、メッセージを受信した場所やメッセージの受信に使用したアダプターの種類などのメッセージの受信に関連するコンテキストにプロパティを配置します。 プロパティは、コンテキストに書き込むか、コンテキストに 昇格 させることができます。 この 2 つのオプションの違いは、メッセージのルーティングの条件として、昇格したプロパティを使用できることです。書き込まれたプロパティは使用できません。
コンテキストへの値の書き込みまたは昇格というこの概念は、BizTalk エディターのプロパティの昇格に関連しています。ただし、同じではありません。 BizTalk エディターで、スキーマの要素または属性は、昇格させたプロパティまたは識別フィールドとしてフラグを付けることができます。 メッセージ スキーマ内のプロパティ フィールドの注釈が付いたアイテムは、コンテキスト内の昇格させたプロパティを設定するパイプラインの逆アセンブラーになります。 メッセージ スキーマ内の識別フィールドの注釈が付いたアイテムは、コンテキストに書き込まれたプロパティを設定するパイプラインの逆アセンブラーになります。
昇格されたプロパティの設計は、 メッセージの関連付けの設計から始まりました。受信しているメッセージを既に実行中のオーケストレーション インスタンスに関連付ける機能です。 関連付けを行う場合、オーケストレーションのメッセージ間のリンクを提供するプロパティまたはプロパティ セットを定義する必要があります。 たとえば、購入処理の場合、PurchaseOrderID に基づいてメッセージを関連付ける必要があります。 ただし、多くのビジネス ケースで、メッセージの特定のフィールドまたは属性の名前が一致しない場合があります。 たとえば、注文書のスキーマに POId という要素が含まれ、それと対になる請求書のスキーマに OrderID という要素が含まれる場合があります。 この状況で PurchaseOrderID などの名前付きプロパティにメッセージを関連付けるには、開発者は、関連付けるプロパティの名前を値のソースから抽出する必要があります。 プロパティ スキーマは、この抽出をサポートしています。
プロパティ スキーマを使用すると、昇格されたプロパティを共通の場所に定義し、他のスキーマで参照することができます。 他のスキーマと同様に、プロパティ スキーマには名前空間があります。他のスキーマと異なるのは、定義された要素しか使用できないことです (つまり、レコードや属性は使用できません)。 プロパティ スキーマに定義される各要素には、名前と型があります。 プロパティ スキーマは複数のスキーマから参照される可能性があるので、プロパティ スキーマの情報を実行時にコンポーネントが使用できるようにするため、他のすべてのスキーマと同様に BizTalk Server にプロパティ スキーマを展開する必要があります。 通常のスキーマ展開手順に加えて、昇格されたプロパティに関する情報が抽出され、管理データベースのbt_documentSpec テーブルに格納されます。
プロパティ スキーマを作成した後、同じ型 (たとえば、整数型) の要素および属性は、プロパティ スキーマの名前付きプロパティとして昇格できます。
上記の例を実行するには、開発者は次の手順を実行して、関連付けに必要な共有プロパティを定義します。
プロパティ スキーマを作成し、PurchaseOrderId という xs:int 型の要素を定義します。
PurchaseOrder スキーマを作成し、POId という xs:int 型の要素または属性を追加します。
開発者は、BizTalk エディターの昇格の表示コマンドを使用して、昇格させたプロパティの一覧に POId フィールドを追加し、一覧から PurchaseOrderId 名前付きプロパティを選択して、プロパティ スキーマで定義された PurchaseOrderId プロパティとして昇格することを示します。
Invoice スキーマを作成し、OrderId という xs:int 型の要素または属性を追加します。
開発者は、BizTalk エディターの昇格の表示コマンドを使用して、OrderId フィールドを昇格させたプロパティの一覧に追加し、一覧から PurchaseOrderId 名前付きプロパティを選択して、プロパティ スキーマで定義された PurchaseOrderId プロパティとして昇格することを示します。
この定義がドキュメント スキーマに存在するので、パイプライン コンポーネントは、名前付きプロパティ PurchaseOrderID として OrderId と POId を正しく昇格できます。これにより、ルーティングおよび関連付けにこれらのプロパティを使用できます。 昇格プロセスの詳細については、このドキュメントの「メッセージ処理」を参照してください。
昇格させたプロパティには、昇格させた要素の値をメッセージのコンテキストで使用できる利点があります。 つまり、メッセージの XPath ステートメントを実行するためにメッセージをメモリに読み込む必要がないので、この値を取得する負担が少なくなります。 代わりに、値を取得するため、キーと一緒に単純なプロパティ バッグを使用できます。 このような動作は、メッセージのルーティング以外の状況に適しています。また、識別フィールドを作成する理由にもなります。 昇格させたプロパティをメッセージ コンテキストに昇格すると、識別フィールドがメッセージ コンテキストに書き込まれます。 ただし、昇格させたプロパティと異なり、識別フィールドにプロパティ スキーマはありません。 このため、識別フィールドはルーティングで使用できないので、送信ポートまたはオーケストレーションの受信図形のフィルター条件として使用できません。 ただし、メモリにメッセージを読み込んで値を抽出する代わりにメッセージ コンテキストで値の読み込みまたは書き込みを行うため、識別フィールドはオーケストレーションで使用できます。
プロパティをメッセージ コンテキストに昇格させるまたは書き込む以外に、メッセージの述語もコンテキストに追加できます。 メッセージの述語は、BizTalk Server のセキュリティ対策として使用されます。また、メッセージをルーティングするホストに指定された値と一致させる必要のあるメッセージに関するコンテキスト情報を提供します。 このセキュリティ対策を使用すると、特定のメッセージの受信および処理を行えるホストを限定して、BizTalk Server 環境を構成できます。 例として、BizTalk Server 管理コンソールで、メッセージのデコードおよび解読を行うために使用される証明書の拇印を使用して、ホストを構成できます。 このプロパティを構成すると、メッセージ ボックス データベースにこのホストのアプリケーション プロパティが作成されます。 この拇印で受信および解読されるセキュリティで保護されたメッセージでは、この拇印で構成されたホストに対して、ルーティングのみ行います。