2017-03-22 10 views
1

私たちは、アプリケーションでOAuth認証を使用してDocuSignアカウントを持つクライアントにDocuSignサービスを提供するインテグレータに過ぎません。私たちのクライアントの中には、他のクライアントよりも大幅にボリュームが大きいものもあります。Webhookの再試行と異なるアカウント

エンベロープのイベント通知にRequireAcknowledgementフラグを設定し、アカウント1(低ボリュームクライアント)のwebhook URLへの最初の投稿が失敗し(サーバーのダウンなどにより)、その後の投稿が成功しましたアカウント2(大量のクライアント)のアカウント1のポストは再試行されますか、アカウントの要求の間に不確定な時間(数時間または数日かかる可能性があります)を待たなければなりませんか?

つまり、成功した投稿を持っている個々のアカウントまたは投稿者が成功したインテグレータキーまたは通知URLに再試行していますか?

+0

ようこそStackOverflow!他人の質問を含め、すべての有益な回答をupvoteすることを忘れないでください。そして、自分の質問に対する最良の答えをチェックしてください。 –

答えて

2

アカウントレベルでの接続のサブスクリプションを作成している場合は、再試行ロジックは(も接続構成として知られている。)を接続購読

に基づいて、各アカウントには独自のサブスクリプションを持っています。

エンベロープ単位の購読を作成するためのエンベロープ単位eventNotificationのテクニックを使用している場合、各エンベロープは異なるサブスクリプションです。

Details on the retry logic.

+0

これを正しく理解していると、エンベロープイベント通知ごとに同じサブスクリプションURLを使用するエンベロープが成功するとすぐに、そのサブスクリプションURLの以前のエンベロープイベント通知違反がアカウントに関係なく再試行されます封筒のあれは正しいですか? – Fred

+0

いいえ、エンベロープ単位のサブスクリプションは互いに独立しています。さまざまなエンベロープの購読を再開することが心配な場合は、Failureキュー(アカウントごとに1つずつ)をポーリングし、APIを使用して失敗した通知を再開できます。また、信頼性の高いリスナーを構築してください。例:ロードバランサの背後にあるリスナーサーバーのプール。リスナーのみを使用して、通知を信頼性の高いキューシステムに配置します。 –

+0

したがって、各エンベロープサブスクリプションは独立しているため、RequireAcknowledgementがtrueに設定されていても、そのサブスクリプションに次回の試みが成功することはないため、再試行されることはありません。 つまり、Connectと1つのアカウントでは、投稿が成功した後に再試行されます。ここでは決してそうではないようです。正しい?エンベロープ・レベルでのeventNotification設定については、このドキュメントでは正確ではありません。それか、私はそれがどこで扱われているか見ていません。 – Fred

関連する問題