0

再試行のロジックを実装する必要があります。インバウンド エンドポイントは、メッセージを Rest (アウトバウンド) にプッシュします。REST が使用できない場合は、1 回再試行してキューに入れる必要があります。ただし、2 番目の今後のメッセージは再試行しないでください。REST サービスが利用可能になるまで、メッセージを直接キューに入れる必要があります。

サービスが利用可能になったら、すべてのメッセージを QUEUE から REST サービスに (順番に) バッチ ジョブでプッシュする必要があります。

質問:

  1. 2 番目のメッセージでサービスが利用できないことを確認するにはどうすればよいですか? 成功するまで使用すると、メッセージごとに再試行してキューに入れます。Plm は 2 番目のメッセージであり、リトライを行うべきではありません。

  2. バッチの場合、ポーリングを使用することを考えましたが、サービスが利用可能になったときにポーリングしてバッチ処理を開始する方法を教えてください。（bcz、ポーリングは、バッチを実行するタイミングを設定することでより多くなります）？

  3. 他のカチカチと混乱するのは、ここでは順序を維持する必要があることです。サービスが利用可能になったら。キュー メッセージ (つまり、バッチ) は、最初に REST サービスに移動し、次にリアルタイムで移動する必要があります。当てはまるか疑問です。

    ロジックを実装していただけると迅速な対応に大変助かります。

Mule の使用: 3.5.1

4

2 に答える 2

1

以下のようなことを試すことができます: フロー制御の使用

  1. メッセージを処理します。例外または不正な応答コードの場合は、serviceAvailable=false などの変数/プロパティを設定します。
  2. 後続のメッセージ処理では、最初にプロパティ serviceAvailable をチェックしてメッセージを処理します。プロパティが false の場合、status=new/unprocessed の DB テーブルにメッセージをエンキューします
  3. DB からのメッセージを順次処理するフロー/スケジューラを作成しますが、プロパティ serviceAvailable をチェックせず、残りのサービスを呼び出しません。サービスが例外をスローした場合、メッセージを db に再度保存することはありませんが、プロセスが正常にプロパティ serviceAvailable=true を変更し、メッセージをデキューするか、ステータスを変更した場合。moreDBMsg=true のように db テーブルにさらにメッセージがある場合は、別のプロパティを追加して true に設定します。新しいメッセージは、moreDBMsg=false と moreDBMsg=false および serviceAvailable=true がキューからのメッセージの処理を開始するまで、処理/消費されるべきではありません。
于 2014-09-08T18:35:52.437 に答える
0

タイムアウトについては、応答コードを調べてタイムアウトをキャッチし、呼び出しが成功したか、再試行が必要かを判断します。実際には、通常はとにかくマルチスレッドを実行するため、とにかく複数の呼び出しが並行して行われます。または、一方の通話が終了する前にもう一方の通話が開始されます。それはごく普通のことです。

ただし、タイムアウトになったキューで呼び出しを再試行するだけです。そして、x回のタイムアウトの後、再試行を「スキップ」または延期します。

ただし、これらはすべて、次のいずれかのような実際の Mule フロー コンポーネントを使用して行われています。

キューの 1 つの可能性は、データベースに永続化することです。Mule には、「ポーリング」機能を持つデータベース コネクタがあります。次を参照してください: http://www.mulesoft.org/documentation/display/current/JDBC+Transport+Reference#JDBCTransportReference-PollingTransport

于 2014-09-08T08:56:29.150 に答える