サードパーティのクライアントが定期的に (10 分ごとに) 呼び出して (プッシュを使用するのではなく、呼び出しを行う必要があります)、まだ受け取っていない新しい注文を取得できる Web API サービス (注文通知) がある場合、失敗にどう対処するか？
たとえば、クライアントが最後に呼び出してから受け取っていない新しい注文が 10 件あるとします。クライアントは注文通知サービスを呼び出します。送信していない注文 (この場合は 10) を取得します。これらの 10 件の注文を送信済みとして更新し、クライアントに応答を返します。
ただし、クライアントは応答を受信しませんでした (http タイムアウトなどの理由で、私たちを離れた後に発生したことがあります)。
そのため、私たちの側で注文を送信済みとしてマークしたのに、クライアントが注文を受け取っていないという問題があります。
これを解決する方法について何か考えはありますか？
ちょっとしたアイデアですが、発信者に何らかの識別子を割り当てて、発信者が成功すると、要求を確認したと返信することはできますか? クライアントが報告しない限り、サーバーはクライアント側で何かが失敗したかどうかを知ることはありません。
たとえば、発信者 A がリクエストを呼び出すと、次のようになります。
call -> http://server/requests
サーバーは、特定の呼び出しに応答があったかどうかを知るために追跡する一意の識別子とともに、この呼び出し元の結果セットを含む xml を返します (妥当な期間が経過したら、この識別子をタイムアウトにすることができます)。
クライアントがリクエストを受け取ると、再度コールバックできます
call -> http://server/requestComplete?id=[generatedID]
サーバーはそれを成功とマークします。
多くの API はある種の識別トークンを必要とするため、この種の送信/確認メッセージ システムにはすでに適しています。
システムの両側にアクセスできる場合は、受信したリクエストを作成できるため、クライアントがデータを取得すると、元のホストにリクエストを送信して、正常に受信したことを伝えます。