入力されるメッセージの順序が非常に重要であり、保持する必要がある BizTalk アプリケーションがあります。つまり、同じ順序で出力する必要があります。通常、注文された配達はここでうまくいきます。
ただし、注文された配信は、受信場所を送信ポートに直接接続した場合にのみ保証されると読みました。オーケストレーションを使用した時点で、注文の配信は保証されなくなります。これを回避または修正する方法はありますか? この種のものはアプリケーション全体を台無しにするため、私たちは何ヶ月もこれに取り組んできました.
Microsoft からの回避策を読みました。ここでは、カウンターを持つ追加のフィールドを使用し、カウンターをチェックするエンド オーケストレーションを使用しています。しかし、これは私たちが今行うにはあまりにも多くの作業です。したがって、この回避策はありません。さらに、すべてのメッセージが翻訳されるわけではないため、フローに穴が開いたり、すべてのメッセージが同じソースから来ているわけではないため、この回避策はとにかく役に立たなくなります。
他のアイデアはありますか？
BizTalk での注文された配信の順序変更戦略:
最近、BizTalk で注文された配信オプションに関するLinkedIn ユーザーの質問に回答しました。
BizTalk を使用してメッセージの順序を変更するためのいくつかの戦略を理解することは、人々にとって役立つと思いました。
多くの場合、BizTalk 開発者は、変更不可能な基幹業務システムに統合する必要があります。これは、さまざまな理由の 1 つまたは複数が原因である可能性があります。たとえば、システムを変更するコストが高すぎる場合や、システムを変更するとサポートが取り消される可能性があるとベンダー ライセンスに記載されている場合があります。
これは通常、ベンダーが慎重に設計された API を統合ポイント エンドポイントとして提供している場合の問題ではありません。ただし、多くの統合開発者がすぐに習得するように、これが当てはまることはほとんどありません。
よく考えて設計された API とはどういう意味ですか? すべての SODA プリンシパル (サービス構成、フォールト コントラクトなど) は別として、API の最も重要な機能は、間違った順序で到着するデータの消費をサポートすることです。
これはかなり簡単なことです。たとえば、ベンダーが統合ポイントとして HTTP 操作を提供する場合、操作で公開できるフィールドの 1 つはタイムスタンプ、さらにはシーケンス番号です。これは、古いペイロードで呼び出しが行われた場合、関連する補償メカニズムが作動する可能性があることを意味します。これは、データを破棄するのと同じくらい簡単です。
この記事では、ベンダーがこの機能を API に組み込んでいない場合の対処方法について説明します。したがって、インテグレーターとして、統合ソリューションの一部としてエンド ツー エンドの注文済み配信を実装する必要があります。
LinkedIn でのユーザーの投稿 (上記のリンクを参照) に対する私の回答で述べたように、BizTalk では、最も単純なシナリオを除いて、注文された配信は良くても複雑であり、最悪の場合、開発と開発の両方の観点から、複雑さが増すことで莫大なコストがかかる可能性があります。サポート。基本的な理由は、BizTalk は高スループットを可能にするために大規模な同時実行を行うように設計されており、同時実行と順序付けの間に直接的かつ避けられない競合があるためです。BizTalk ソリューションへのシューホーニング E2E オーダー配信は、シングルトン オーケストレーションなどのアーティファクトに依存しており、複雑さをもたらし、障害率と障害あたりのコストの両方を増加させます。
はるかに優れたソリューションは、並行処理を基幹業務システムのエンドポイントにできるだけ近づけて維持し、データを正しい順序で配信する必要がある各エンドポイントの周りにリシーケンサー ラッパーと呼ばれるものを実装することです。 .
このようなラッパーを BizTalk に実装する方法は、次の表に示すいくつかの要因によって異なります。
|Sequencing |Messages|Database |Wrapper |
|field |are |integration?|strategy |
| |deltas? | | |
|--------------|--------|------------|----------------------------------|
|n of a total m| N | Y |Stored procedure |
|n of a total m| N | N |Singleton orchestration |
|n of a total m| Y | Y |Batched singleton orchestration |
|n of a total m| Y | N |Batched singleton orchestration |
|Timestamp | N | Y |Stored procedure |
|Timestamp | N | N |Singleton orchestration |
|Timestamp | Y | Y |Buffer table with staggered reader|
|Timestamp | Y | N |Buffer table with staggered reader|
最初の要素Sequencing フィールドは、あらゆる種類の再シーケンサー ラッパーを実装するために、最低限、メッセージ データに何らかのシーケンス情報が含まれている必要があるという考えに関連しています。これは、ソース タイムスタンプの形式を取ることができます。ただし、まれではありますが、より優れた種類のシーケンス情報は、メッセージの総数と組み合わせたシーケンス番号で構成されます。たとえば、10 のメッセージ 1、10 の 2 などです。
第 2 要素メッセージはデルタですか? メッセージのペイロードに、データに対する単一の状態変更が含まれているか、データに対する過去のすべての変更の合計が含まれているかどうかに関係します。別の言い方をすれば、このメッセージからデータの完全な現在の状態を再構築することは可能ですか? メッセージ ペイロードに含まれる変更が 1 つだけの場合、単一のメッセージからデータの状態を再構築できない可能性があります。この場合、メッセージはdeltaです。
第 3 要素データベースの統合？システムへの統合エントリポイントがデータベースであるかどうかに関係します。これが重要な理由は、データベース レイヤーでの統合はかなり一般的な統合シナリオであり、利用可能であれば再シーケンス処理を大幅に簡素化できるためです。
上記の表の戦略について、以下で詳しく説明します。
ストアド プロシージャ ラッパー これは、最も単純な再順序付け戦略です。ターゲット データを更新するかどうかを決定する前に、ターゲット データを照会する新しいストアド プロシージャが作成されます。決定は、次のように簡単に行うことができます。所有しているデータは、ターゲット システムのデータよりも新しいか?
もちろん、この戦略を実装するには、ターゲット データにソース データのシーケンス フィールドも含める必要があります。ストアド プロシージャ ラッパーは、ターゲット データベースに含めることも、理想的には別のデータベースに含めることもできます。
シングルトン オーケストレーション ラッパー この戦略の背後にあるアイデアは、シングルトン オーケストレーションです。これは、オーケストレーションのインスタンスが一度に 1 つだけ存在するようにするために実装できるパターンです。Web には、このパターンを BizTalk に実装する方法を示す記事が多数あります。
アイデアの核心は、シングルトンが、最近正常に処理されたメッセージシーケンス (またはタイムスタンプ)を単純に追跡することです。シングルトンが最新のシーケンスよりも古いメッセージを受信した場合、それは単純に破棄されます。これは、メッセージが非デルタであるため機能します。そのため、ターゲット システムは多数のメッセージのうち最新のもののみをコミットでき、データは最新の状態になります。データが正常にコミットされた場合にのみ、シングルトンが保持する最新のシーケンスが更新されます。
バッチ シングルトン オーケストレーション ラッパー この戦略は、上記のシングルトン オーケストレーション ラッパーに基づいていますが、より複雑です。シングルトンは、最新のシーケンス情報をメモリに保持するだけでなく、メモリにメッセージの作業セットを作成して保持する必要があります。これは、並べ替えて、バッチから予想されるすべてのメッセージが到着したら処理します。これは、メッセージがデルタであるため、ターゲット システムが各メッセージを意図した順序で受信する必要があるためです。バッチが正常に送信されると、シングルトンを終了できます。
これを行うには、ソース データに、メッセージのバッチを定義できる何らかの記述の相関識別子が含まれている必要があります。たとえば、定義された一連の顧客からの注文を処理する場合、インバウンド メッセージには顧客の識別子が含まれている必要があります。これを使用して、この顧客に関連付けられたシングルトン オーケストレーション インスタンスにメッセージをルーティングできます。さらに、使用可能なメッセージ シーケンス フィールドは、合計 m形式の n でなければなりません。
シングルトンが初期化されると、メモリ内でメッセージの作業セットが組み立てられ、新しいメッセージが到着すると、そのセットが作成されます。私が見た方法の 1 つは、ワーキング セットのコンテナーとしてSystem.Collections.Generic.Listを使用することです。リストが完全に読み込まれると (リストの長さ = m)、バッチ内のすべてのメッセージが受信されたと見なされ、オーケストレーションはワーキング セットを順番にループし、メッセージをターゲット システムに処理します。
バッチ シングルトン オーケストレーション ラッパーの利点の 1 つは、相関識別子による同時処理が可能になることです。上記の例では、2 人の顧客からのメッセージが同時に処理されることを意味します。
スタガード リーダー ラッパーを使用したバッファー テーブル おそらく提示された戦略の中で最も複雑なこのソリューションは、タイムスタンプ ベースのシーケンス フィールドを使用したデルタ メッセージングがある場合に使用されます。これは、再順序付けバッファとして機能する何らかの説明のデータベースを使用して実装できます。
ここで、このリシーケンシング ラッパーは順序どおりの配信を保証しないことに注意してください。
メッセージが到着すると、メッセージはバッファーに書き込まれ、同じ操作でバッファーが並べ替えられるため、バッファーに保持されているメッセージの順序は常に正しいものになります。
バッファ リーダーを作成するには、順序付けられた配信が有効になっている送信ポートにメッセージを渡す前に、バッファ内のメッセージを読み取る受信場所を用意します。送信ポートはメッセージをターゲット システムに処理します。ターゲット システムの API セマンティクスが送信ポートに対して複雑すぎる場合は、仲介としてシングルトン オーケストレーションを使用することもできます。
ただし、上で説明したようにこのラッパーを使用しても、メッセージはほぼ確実に間違った順序でバッファにコミットされるため、順序付けられた配信は有効になりません。 ） 注文。ここで、ずらしたクエリの出番です。これは、バッファー クエリが時間Tの間隔でのみデータを選択する必要があり、かつ行番号がバッファーの合計行数から C を引いた値よりも小さい行のみを選択する必要があることを示す凝った方法です。
これには、適切な期間にわたって順序付けを行うことができるという効果があります。Tは、ほとんどの BizTalk 開発者にとって、一部のアダプター ( WCF-SQLアダプターなど) のポーリング間隔としてよく知られています。Cは設定が少し難しくなりますが、この数値を大きくすることで、ポーリング時に、取得したデータ セット内の最新のメッセージよりも古いメッセージを見逃す可能性が低くなります。
TとCはさまざまな要因に依存しますが、これらの値はレイテンシ SLA とメッセージ ボリューム (またはスループット) に基づく必要があります。ガイドラインとして、ターゲット システムに 30 秒以内にデータを配信する SLA があり、1 秒あたり 10 メッセージを処理する場合、Tは約 10 秒、Cは約 100 行にする必要があります。
もちろん、これは、特定の相関 ID のメッセージがソース システムによって短時間 (理想的には連続して) 送信された場合にのみ機能します。送信間の間隔が長くなるほど、必要なCの値が大きくなり、ラッパーの効果が低下します。
この戦略の利点の 1 つは、データ ソースが重複したメッセージを送信する傾向があり、ターゲット システムのエンドポイントがべき等でない場合に、バッファー内のメッセージの重複除去を実行できることです。バッファーを使用して、FILOやその他の非標準のキューイング セマンティクスを実装することもできます。
結論 ここで説明した戦略は、BizTalk を目的外のタスクに曲げる方法です。その結果、それぞれにサポートするコストと複雑さに関する注意事項があり、特定のシナリオでは機能しない場合もあります。BizTalk で注文された配信の他のパターンを実装したことのある方からのご意見をお待ちしております。
このページをご覧ください。オーケストレーションのインスタンスが 1 つだけ存在することを保証するためにシングルトン パターンに従うオーケストレーションがあり、オーケストレーションの受信ポートを順序付き配信に設定していることを確認すると、有効なエンド ツー エンドの順序付き配信を取得する必要があることを説明しています。シナリオ
エンド ツー エンドの注文済み配送を提供するには、次の条件を満たす必要があります。
メッセージは、BizTalk Server に送信するときにメッセージの順序を保持するアダプターで受信する必要があります。BizTalk Server 2006 では、このようなアダプタの例として MSMQ、MQSeries、および MSMQT があります。さらに、HTTP または SOAP アダプタを使用してメッセージを順番に送信できますが、その場合、HTTP または SOAP クライアントはメッセージを 1 つずつ送信して順序を強制する必要があります。
これらのメッセージは、Ordered Delivery オプションが True に設定された送信ポートでサブスクライブする必要があります。
オーケストレーションを使用してメッセージを処理する場合は、オーケストレーションの 1 つのインスタンスのみを使用し、シーケンシャル コンボイを使用するようにオーケストレーションを構成し、オーケストレーションの受信ポートの Ordered Delivery プロパティを True に設定する必要があります。