次の方法で共有

送信処理用メッセージのバッチ処理

  • [アーティクル]

送信アダプターのバッチ管理

送信側でトランザクションを使用する際には、BizTalk Server によって作成され対象システムへの送信に使用されたトランザクションが、メッセージの正常な送信後に、そのメッセージの削除用にも使用されます。 エラーが発生してトランザクションが終了する場合もあります。その場合は削除が中断し、対象システムではなく BizTalk Server にデータが残ります。 これにより、メッセージの重複が防止されます。 トランザクションがサポートされるのは非同期送信アダプターに対してのみです。 同期送信アダプターではトランザクションを使用しないでください。

ただしアダプターは、トランザクションを終了するだけでなく、渡されたメッセージの状態も正しく処理する必要があります。 具体的には、アダプターは、再試行回数とバックアップ トランスポートが使用可能かどうかに応じて、メソッド Resubmit、 MoveToNextTransport、 および MoveToSuspendQ を適切に呼び出す必要があります。

Delete 操作と SubmitResponse 操作を、同じトランザクションを使用するバッチにまとめて配置することが重要です。 エラーはトランザクションを終了することによって処理されます (外部システムへのデータ送信を 1 回に限定するため)。 ただし、BizTalk Serverでメッセージの再送信または MoveToNextTransport の呼び出しを行う必要があります。 そのためには、別の標準のバッチ (トランザクション バッチではないバッチ) を使用してこれらの操作を行います。

次の図では、応答メッセージに対して別のバッチを使用しています。

応答メッセージに別のバッチを使用

送信側トランザクション バッチのエンドポイント別振り分け

BizTalk Server によってアダプターに送信されるメッセージのバッチは、複数の送信ポート (エンドポイント) にまたがっている場合があります。 アダプターは通常、単一のエンドポイントへのトランザクションを必要とするため、アダプターは送信ポート (SPName または OutboundTransportLocation) に基づいてメッセージを並べ替える必要があります。 そうすることで、特定の送信ポートのみを使用するトランザクションを作成できます。

たとえば、FTP 送信アダプターが BizTalk Server から受信するメッセージのバッチには、現在アクティブなすべての FTP 送信ポートのメッセージのバッチが混在しています。 これは、API がシングルトン ベースであるためです。つまり、読み込まれる FTP アダプターは 1 つだけであり、送信ポートごとにアダプターが読み込まれるわけではありません。

アダプターではまず、BizTalk Server によって渡されたメッセージのバッチを、エンドポイントごとに別のバッチに振り分ける必要があります。 これにより、各エンドポイントを交代で処理できるようになり、各エンドポイントの削除バッチを作成することも可能になります。 SDK サンプル コードの再利用可能な BaseAdapter ジェネリック クラスも同じように動作します。

動的送信のための振り分け

BizTalk Server オーケストレーションでは、メッセージ ヘッダーと URL 自体に十分な構成情報が含まれていれば、構成されていないポートにメッセージを送信できます。 BizTalk Server は、URL のプロトコルを認識する必要があります。

メッセージを振り分ける際には、エンドポイントがどのように定義されるのかを明確にしてください。 動的送信の場合には特にこれが重要になります。 エンドポイントを定義するのが URI だけである場合は簡単です。 しかし、FTP セッションでは、FTP サーバーがユーザー名のログオンの詳細を使用して実際のエンドポイントを定義する場合もあります。 その場合は、アダプターが別のアカウントとしてログインすると別のディレクトリに接続されてしまいます。

場合によっては、エンタープライズ シングル Sign-On (SSO) コマンド ValidateAndRedeemTicket を実行するまで、真のエンドポイントが認識されない場合があります。

MQSeries の場合は、トランザクションを使用するかどうかの決定は構成可能です。 このアーキテクチャと、リモートの COM+ オブジェクトが使用されることから、トランザクション エンドポイントを非トランザクション エンドポイントとは別のものと考えることをお勧めします。

つまり、メッセージを 1 つのエンドポイントのバッチに振り分けるのは必ずしも容易ではなく、場合によっては、コンテキスト値や SSO の呼び出しの結果も考慮に入れなければなりません。

静的送信のための振り分け

エンドポイントが静的に構成されたエンドポイントの場合、静的ポート ID (SPID) と呼ばれるメッセージ コンテキストに一意の GUID があります。 この値をエンドポイントの識別のために使用できます。 この値を取得するためのコードを以下に示します。

string spid = (string)message.Context.Read("SPID", "http://schemas.microsoft.com/BizTalk/2003/system-properties");

これは、XSD (XML スキーマ定義) ベースの構成フレームワークによる問題を検討する場合に便利です。 このフレームワークでは、エンドポイント キーの一部である可能性があるプロパティが、1 つのコンテキスト プロパティの XML に埋め込まれています。 そのコンテキストに SPID がある場合は、それを使用してバッチを振り分けることができます。 それ以外の場合は、動的送信が行われているため、バッチを振り分けるための別のキーを作成する必要があります。

次の図は、エンドポイントによるメッセージの振り分けを示しています。

EAWP_SortBatchエンドポイント

メッセージの再試行の回数にはバッチの成功や失敗は反映されないことに注意してください。 送信側では、バッチ内の少数のメッセージが失敗したためにそのメッセージのバッチが失敗になる場合があります。 アダプターでは、受信するすべてのメッセージについて判断を下す必要があります。 失敗したバッチのシナリオでは、すべてのメッセージが再送信されるように思われがちですが、 失敗したバッチのすべてのメッセージが再送信されると、失敗したメッセージとたまたま同じバッチに含まれていた成功したメッセージに対してまで再試行の回数 (BizTalk Server エンジンによって保持される) が加算されてしまいます。 この場合は、アダプターで送信バッチを作り直して、成功したメッセージを外部システムに対して再試行できます。