私は完璧に動作するBizTalk 2006 R2アプリケーションを持っています。 メッセージを受信して処理し、正しい応答を送信します。BizTalkのゾンビ
しかし、すべてが（メッセージがオーケストレーションによって成功裏にピックアップされ、応答がエラーなしで送信されます）正しいですが、BizTalkがまだ応答メッセージに関連する「メッセージ消費されなかった」エラーを生成...
私はアプリケーションのすべてのビットをデバッグしました。エラーはありません。メッセージは重複していません。何もメッセージが残っていません。私はそのエラーを調査しました。主題に関するいくつかのリンクの大多数は関連していますゾンビクリーンアップスクリプト。これは、これはのBizTalkでは一般的な問題ではない場合、私は誰もがこのエラーを引き起こす可能性のあるものに任意のアイデアを持っています
...思ってしまいますか？
これはゾンビのように聞こえる。あなたのオーケストレーションは相関と待ち時間を使用していますか？もしそうなら、あなたはゾンビランドにいます。問題は、どのトリガーが最初に表示されるのを待っている待っているとseocndaryの読書を持っているということです。待機が最初にトリガされ、相関の新しいメッセージが来たら...ゾンビ。
は、私たちはあなたのオーケストレーションについての詳細を知っていると我々はさらなる解決策を議論することができます。
うん...これは、ほとんどの時間のあなたのソリューションを一緒に入れている方法のわずかな変化によって克服することができる共通の課題です。相関やタイムアウト、だけでなく、時間を使用した場合
ゾンビは通常起こります。 オーケストレーションは、タイムアウトが発生した場合、相関セットへの応答またはタイムアウトが発生した場合に、相関関係のある応答を待機している受信場所を処理するために処理を続行します。今すぐメッセージボックスが応答を取得しますが、その応答を待っているものはもうありません。したがって、あなたのエラー。
Webサービスを呼び出して応答を待っているときにもこの現象が見られました。しかし、これは私がどのようにエラーを処理していたかと関係がありました。私のプロセスへの小さな変更は、その問題を解決しました。
この問題ののoccuranceを最小化する方法は、タイムアウト後にオーケストレーションが行う作業量を短縮することです。ゾンビのウィンドウができるだけ小さくなるようにします。
時には、この非決定論的な終了の問題を回避することができないため、私は自分自身がこれらのメッセージを受け取り、それ自身でクリーンアップする "ZombieHandler"プロセスを構築していることが分かりました。
あなたのプロセスに関する情報を投稿できる場合は、もう少しお手伝いしてください。
エラーがBizTalkグループパネルではなく、イベントログにあるとされ、「そのメッセージのすべてを消費することなく完了インスタンス。インスタンスとその未消費のメッセージが中断されています。」。基本的には、双方向ポート経由でメッセージを受信し、相関を初期化しながらメッセージボックスに送信するメインのオーケストレーションがあります。このオーケストレーションの次の図形は、（タイムアウトロジックなしの）メッセージを待機し、以前の送信シェイプで作成された相関に従います。応答が受信されると、それは元のリクエスターに転送されます。
ロジックがほとんどない非常に簡単なオーケストレーション（スクリーンショット：http://img139.imageshack.us/img139/2307/orchestration.jpg）です。要点は、私は常に正しい応答を得ているので、「メッセージを消費しない」というエラーが何を引き起こしているのか分かりません。ところで、消費されていないとフラグされたメッセージは応答メッセージです。
さらなるアイデアはありますか？
ps。あなたはZombieHandlerについて詳しく説明できますか？そのようなオーケストレーションをどのプロパティにバインドしますか？
ここでオーケストレーションのスナップショットを教えてもらえますか？それを簡単に見てみると助かります。双方向受信との相関に関するいくつかの問題があるかもしれません。 –
完了。メッセージを更新し、スクリーンショットを追加しました。 –
なぜ相関セットを使用していますか？相関セットの受信を初期化していますが、次の受信はどこですか？
あなたは一歩前進して、相関関係の要件は何かを説明できますか？あなたは何のメッセージをここに結びつけようとしていますか？あなたがこのオーケストレーションから相関を取り除くと、私は推測しています。それは完全に機能します。
相関チュートリアルをご覧になりたい場合はlinkです。
@ChrisLoris：オーケストレーションの
スクリーンショット：http://img139.imageshack.us/img139/2307/orchestration.jpg
あなた上のスクリーンショットで、私は/受信ポート送信するためにオーケストレーションをリンクしていることがわかります。基本的には、処理するメッセージを取得していて、その上にいくつかの属性を更新し、特定のプロパティ（MsgIdentifierと呼ぶ）に基づいて相関を初期化しながらメッセージボックスに送信します。他のオーケストレーションがこのメッセージを受け取って実際の処理を行います。応答が同じMsgIdentifier（カスタムプロパティ）を持つメッセージボックスにドロップされると、このオーケストレーションはそれをピックアップして元のリクエスタに返します。
相関は、メッセージボックスに要求を送信する送信シェイプで初期化され、次の受信シェイプは、同じ相関に従う、つまりMsgIdentifierプロパティで同じ値を持つ応答を待機します。
このオーケストレーションは、外部システムとBizTalkアプリケーションの内部動作との間の仲介者であると考えてください。
また、すべて正常に動作しており、問題なく正しいメッセージが選択されています。これは、分析しようとしているものとまったく変わった動作です。検出され、消費され、返されるため、レスポンスは消費されていないメッセージとしてマークするべきではありません。
ああ。私は相関が送信にあったとは考えていませんでした。私は考え直しましょう。 –
複数のオーケストレーションで元のメッセージが処理される可能性はありますか？この場合、私たちが議論しているオーケストレーションへの応答のために、メッセージボックスに2つのメッセージが戻ってくることがあります。この場合、第1のメッセージは、コリレーションセットによってピックアップされる。次の受信にループ構造がないため、2番目のメッセージにはどこに行く必要がありません - ゾンビ。
エラーの詳細を投稿できますか？何らかの応答を受け取るようにセットアップしていますか？メッセージボックスにメッセージがない場合、このメッセージが表示されます。 –