質問

したがって、ソリューションに必要なモデルは次のとおりです。

データベースをポーリングし、結果に基づいて、データベースへのリクエストを作成してさらにデータを要求し、応答を取得してポートのグループに渡します。動作します。

次のようになります:

ただし、「Temp Out」を割り当てた場合、送信ポートグループには、各ポートに設定されているフィルターに関係なく、グループ内のすべてのポートにメッセージが送信されます。私の理解では、これは予想される動作です(こちらを参照)。

>

だから、SDKのようなコンテンツベースルーティング(CBRサンプル)の使用など、他のオプションを検討しました。このこちらをご覧ください。

これを試し、オーケストレーションを完全に削除しました(実際には必要ありません)。ただし、主要なルーティング/サブスクリプションエラーがあり、さらに調査すると、応答ポートを要求している場合はこれを実行できないようです。 こちら this ユーザーと同じ問題がほとんどあります。

最終的に、オーケストレーションを使用するかどうかは関係ありません。ただし、複数の送信ポートにメッセージを渡すことができ、実際にメッセージを使用して送信できるのは1つだけであるソリューションが必要です。これは、他の何かを変更したり、オーケストレーションにハードコードで決定したりすることなく、ポートを簡単に編集および追加できるようにするために必要です。

役に立ちましたか?

解決 2

CBRサンプルモデルが実際に機能することがわかりました。ルーティングの問題はサブスクリプションでした。送信応答ポートに送信ポートをサブスクライブする場合、BTS.ReceivePortフィルターの代わりにBTS.SPName(送信ポート名)フィルターを設定する必要がありました。これにより、メッセージは正しくフィルター処理されました。あなたの答えもうまくいきましたが、それを避けるためにオーケストレーションを使用する必要があります。

他のヒント

オーケストレーションの送信ポートで直接バインドを使用して、メッセージを差し戻すことができます。メッセージボックスdbに。複数のポートグループを使用して、各ポートグループは目的のメッセージタイプを直接サブスクライブし、プロモートされたプロパティでフィルタリングできます。

ライセンス: CC-BY-SA帰属
所属していません StackOverflow
scroll top