これまでに説明したすべてのコンポーネントは、BizTalk Server を通過するメッセージの処理の一環として機能します。 このセクションでは、メッセージの受信から始めて、これらのコンポーネントがどのように機能するかについて詳しく説明します。 次の図は、受信ポートの構成と、受信プロセスを介したメッセージのフローを示しています。
受信ポートは、1 つ以上の受信場所と 0 個以上のマップで構成されます。 マップは、XML メッセージをある構造または形式から別の構造または形式に変換するために使用される拡張スタイルシート言語変換 (XSLT) スタイル シートであり、メッセージを内部形式に正規化するために受信プロセスでよく使用されます。 受信場所は、メッセージを受信するエンドポイントを制御します。 受信場所は、受信アダプターのエンドポイントと受信パイプラインの構成で構成されます。
アダプターの役割
受信アダプターは、データストリームを読み取り、メッセージを作成することで、メッセージを受信するプロセスを開始します。 たとえば、ファイル アダプターは、ファイルが構成された場所に配置されていることを確認し、ストリームでそのファイルを読み取ります。 アダプターは、メッセージ (Microsoft.BizTalk.Message.Interop.IBaseMessage インターフェイスの実装) を作成し、そのメッセージにパーツ (Microsoft.BizTalk.Message.Interop.IBasePart インターフェイスの実装) を追加し、データのストリームをパーツ コンテンツとして提供します。
さらに、アダプターは、場所、アダプターの種類、およびアダプターに関連するその他の情報について、メッセージ コンテキスト プロパティを書き込み、昇格させます。 メッセージとそのコンテキストが作成されると、アダプターはメッセージをエンドポイント マネージャーに渡します。 その後、メッセージは受信パイプラインを介して処理されます。受信パイプラインは、受信場所用に構成されています。 メッセージがパイプラインによって処理された後、エンドポイント マネージャーがメッセージ エージェントを使用してメッセージを発行する前に、マップを使用してメッセージを目的の形式に変換できます。
パイプラインの役割
初期メッセージを作成するアダプターですが、受信メッセージで発生する処理のほとんどは受信パイプラインで行われます。 パイプライン処理では、メッセージの内容とメッセージ コンテキストが処理されます。 メッセージ コンテンツは通常、デコード、逆アセンブル、検証の各ステージで処理されますが、メッセージ コンテキストはすべてのステージで処理できます。 ただし、パイプラインは必ずしもコンテンツまたはコンテキストに対して動作するとは限りません。 たとえば、既定のパススルー パイプラインにはコンポーネントが構成されておらず、メッセージの内容やコンテキストに対する処理は実行されません。 わかりやすくするために、このドキュメントでは、一般的にメッセージ ルーティングに最も大きな影響を与える分解コンポーネントに焦点を当てています。
逆アセンブラーのジョブは、アダプターからの受信メッセージを処理し、それを多数のメッセージに逆アセンブルして、メッセージ データを解析することです。 受信メッセージに多数の小さいメッセージがある場合、これはインターチェンジと呼 ばれます。 フラット ファイル逆アセンブラーと XML 逆アセンブラーの両方で、開発者がラップ コンテンツ (フラット ファイル逆アセンブラーのヘッダーと末尾のスキーマ、XML 逆アセンブラーのエンベロープ スキーマ) と (繰り返し可能な) 本文コンテンツに関する情報を構成できるようにすることで、インターチェンジを処理します。 さらに、これらの逆アセンブラーはどちらも元のメッセージを XML コンテンツに解析します。 BizTalk Server で追加の XML 処理が必要ない場合、カスタム逆アセンブラーはコンテンツを XML に解析するとは限りません。 シナリオの例としては、特定の受信場所でシステムに入るメッセージが、マッピングやその他の XML ベースの処理なしで特定の送信ポートに送信される単純なルーティング状況が含まれる場合があります。
メッセージの種類を使用したルーティング
ルーティングで使用される最も一般的なメッセージ プロパティの 1 つは、メッセージの種類です。 開発者がメッセージの構造を定義するスキーマを作成すると、このスキーマはそのメッセージのメッセージの種類を定義します。 型は、スキーマ定義のルート ノードと名前空間によって決まります。 たとえば、次のような XML ドキュメントのメッセージの種類は次のようになります。 http://tempuri.org/samples/MessageType#Message
<Message xmlns=http://tempuri.org/samples/MessageType>
<SomeOtherElement type="sample"/>
</Message>
ルーティングでメッセージの種類を使用するには、メッセージの種類をコンテキストに昇格させる必要があります。 逆アセンブラーは、メッセージ構造に関する最も具体的な知識を持つパイプライン コンポーネントだけでなく、メッセージ コンテキストにもこの値を昇格させるために使用されます。 XML 逆アセンブラーとフラット ファイル逆アセンブラーは、メッセージの処理時にメッセージの種類を昇格させ、カスタム逆アセンブラーもこのプロパティを昇格して、適切なルーティングを確保する必要があります。
メッセージに型を指定する必要はありません。 前述のように、メッセージの部分は任意のバイナリ データにすることができ、その構造を定義するスキーマは必要ありません。 この種類のメッセージ 部分は、通常、BizTalk Server 自体によって処理が行われることが多くなく、BizTalk Server を介して渡されますが、オーケストレーションから呼び出されたカスタム パイプライン コンポーネント、アダプター、またはコードは、これらの部分とやり取りする可能性があります。
パイプライン コンポーネント (アダプターなど) も、プロパティをメッセージ コンテキストに書き込んで昇格します。 実際、パイプライン コンポーネントは、ほとんどの開発者がメッセージ コンテキストにプロパティを取得するために使用する最も一般的なメカニズムです。 開発者はスキーマを作成し、スキーマ内のプロパティを昇格させることができます。 この情報は、パイプライン コンポーネントで使用できる注釈としてスキーマに格納されます。 組み込みの逆アセンブラーおよびアセンブラー コンポーネント (FlatFile、XML、BizTalk Framework) はすべて、昇格するプロパティに関する情報を取得するためにドキュメント スキーマを使用します。 注釈の XML パス言語 (XPath) ステートメントを使用して、逆アセンブラーはプロモートする要素のドキュメント内の場所を認識します。 ドキュメントをストリーミングするプロセス中に、逆アセンブラーは XPath ステートメントのいずれかに一致する要素を検索し、必要に応じて値をコンテキストに昇格または書き込みます。
カスタム パイプライン コンポーネントは、受信または送信されたメッセージ内の任意のデータのコンテキストへのプロパティの取得を処理するために書き込むこともできます。 プロパティをコンテキストに昇格させ、ルーティングに役立つためには、おそらく値が昇格される理由として、プロパティの定義を持つプロパティ スキーマを作成し、BizTalk Server に展開する必要があります。 カスタム コンポーネントで使用するプロパティ スキーマを定義する前に、さまざまな種類の昇格されたプロパティについて理解しておく必要があります。 プロパティ スキーマで定義されている昇格されたプロパティには、次の 2 つの基本型のいずれかを指定できます。
Microsoft.XLANGs.BaseTypes.MessageDataPropertyBase
基本型が MessageDataPropertyBase のプロパティは、このプロパティの値がメッセージの内容から取得されることを示します。 これは、プロパティ スキーマで定義されているプロパティの既定値であり、最も一般的な使用法です。 MessageContextPropertyBase は、メッセージ コンテキストの一部であることを意図したプロパティを示しますが、必ずしもメッセージ データから直接取得されるとは限りません。 基本型として MessageContextPropertyBase を持つプロパティは、多くの場合、アダプターと逆アセンブラーによって昇格され、メッセージの種類やアダプターの種類などの一般的なプロパティが含まれます。
さまざまな型を理解し、プロパティを定義するときに適切に使用することが重要です。 最も重要な影響の 1 つは、オーケストレーション内のメッセージのコンテキスト プロパティにアクセスするときに発生します。 プロパティが MessageDataPropertyBase として識別された場合、オーケストレーション デザイナーは受信するメッセージのスキーマを調べ、一致する昇格されたプロパティが定義されていることを確認します。 昇格されたプロパティに関連付けられたスキーマにプロパティが見つからない場合、デザイナーはそれへのアクセスを許可しません。 一方、プロパティが MessageContextPropertyBase として定義されている場合、メッセージの種類は重要ではなく、プロパティにアクセスできます。
カスタム パイプラインでは、プロパティをコンテキストに昇格または書き込むメカニズムは非常によく似ています。 プロパティを書き込むには、IBaseMessageContext Write メソッドの呼び出しを使用して、コンテキストに値を配置します。 昇格されたプロパティの場合は、代わりに IBaseMessageContext Promote メソッドを使用するだけです。 これらの各メソッドは、プロパティ名、名前空間、および値を受け取ります。 昇格されたプロパティの場合、名前と名前空間はプロパティ スキーマで定義されているプロパティの名前であり、プロパティ スキーマ アセンブリを参照し、プロパティ用に作成されたクラスのプロパティを使用して最も簡単にアクセスできます。 識別フィールドは共通の名前空間
http://schemas.microsoft.com/BizTalk/2003/btsDistinguishedFieldsを使用し、値の取得に使用される XPath 式は通常、名前として使用されます。次のコードは、プロパティの昇格とコンテキストへの書き込みの両方の例を示しています。 この例では、識別フィールドがコンテキストに書き込まれていることに注意してください。 これは、オーケストレーション デザイナーがフィールドについて認識できるように、メッセージ スキーマが識別フィールドを識別するオーケストレーションにのみ役立ちます。 受信側または送信側の他のパイプライン コンポーネントで使用するために、コンテキストにプロパティを書き込むのに役立つ場合があります。
//create an instance of the property to be promoted
SOAP.MethodName methodName = new SOAP.MethodName();
//call the promote method on the context using the property class for name
//and namespace
pInMsg.Context.Promote(methodName.Name.Name, methodName.Name.Namespace,
"theSOAPMethodName");
//write a distinguished field to the context
pInMsg.Context.Write("theDistinguishedProperty",
"http://schemas.microsoft.com/BizTalk/2003/btsDistinguishedFields",
"theDistinguishedValue");
コンテキストに値を記述または昇格する場合は、次の点に注意してください。
以前にプロパティの昇格に使用したのと同じ名前と名前空間を持つ値をコンテキストに書き込むと、そのプロパティは昇格されなくなります。 基本的に、書き込みによって昇格が上書きされます。
null 値のプロパティは許可されないため、値をコンテキストに書き込むと、値が削除されます。
昇格されたプロパティの長さは 256 文字に制限されますが、書き込まれたプロパティには長さの制限はありません。
昇格されたプロパティはメッセージ ルーティングで使用され、比較とストレージの効率上の理由からサイズが制限されます。 書き込まれたプロパティのサイズにハード制限はありませんが、コンテキストで過度に大きな値を使用するとパフォーマンスに影響します。これらの値は引き続き処理され、メッセージと共に渡される必要があるためです。
BizTalk Server からメッセージを送信する準備ができたら、送信ポートで補完的なプロセスが行われます。 マップは、送信パイプラインが実行される前にメッセージに適用され、パイプラインによって処理され、アダプターを介して送信される前に、メッセージを顧客またはアプリケーション固有の形式に変換できます。 送信パイプラインでは、プロパティをメッセージ コンテキストに昇格する代わりに、プロパティがコンテキストからメッセージに降格されます。
