If an envelope-level (vs account-level) Connect event created via the API with RequireAcknowledgement set to TRUE exhausts all retries, what happens?
In the support article, "Connect Failures and Retries", it mentions, "Administrators can choose to receive email notifications. You receive two proactive emails and another email at deactivation.". However, it seems like that applies to account-level Connect configurations, not envelope-level Connect events created through the API.
Basically, I'm trying to determine what happens after the 15-day mark, when all retries have been exhausted. Ideally, I'd receive an email notification.
After 15 days we will no longer auto-retry events and those specific events will need to be manually retried via the republish tool in the UI or with our new Republish API call.
Envelope-level Connect configurations are not being auto-disabled at this time so there will be no email notification.
Related
Question
Does MsGraph give a lower priority to change notifications when running a subscribed webhook locally? If not, I'm open to hearing any theories as to why this extra delay (from MsGraph to the webhook) could be happening on the local machine, but not when running it in their cloud.
Some background info
When running an Azure Function webhook locally through ngrok (reverse proxy), there's considerable delay in MsGraph sending change notifications to the webhook. Once ngrok receives a notification, it's passed on almost instantly to the correct API call. Calling the ngrok url manually has an near-instant response time. The problem is in Microsoft Graph not sending the notification updates at all (or tens of minutes to hours later).
Forging my own change notifications and feeding them to an Azure Queue for now, but I'd rather just receive live updates to properly test the different paths.
I'm subscribing to the 'messages' change notifications.
Edit: One could work around the delay by forging notifications and manually feeding them to a queue.
I just have issues with the Connect notification "delivered" from my DocuSign demo account. I'm able to get other notifications like Sent or Completed via Backend and via API. I just tried to get the notification "delivered" via Backend and via API and the log details in the backend shows me this message: "Error loading log details. Try it again."
With other Notifications it shows me the XML with Status sent/completed or something else.
Is this behaviour expected because i just have a demo account? The other notifications like sent and completed seems to work.
This is the message i get if i try to get the notification "delivered".
And this is the message i get if i try to get the notification "sent" or "complete".
Please advise.
If you want a notification of when an envelope has been delivered to an individual recipient, it is better to use the event user.delivered rather than envelope.delivered.
Also, if you're using the default Connect queuing system, delivered statuses can be subsumed by the completed status if it occurs within a minute or so of the delivered status.
To ensure that you always get every notification, use the SIM queuing system. (Select via Admin tool / Updates screen.)
This behaviour is not related to you demo account and you should not see this error.
I tested myself and everything works as expected. Perhaps you can post a screenshot of the error.
I am using the official DocuSign java client 3.2.0. I have set the envelope level notification as listed below. Say the webhook URL is https://A.
EventNotification eventNotification = new EventNotification();
eventNotification.setIncludeHMAC("true");
eventNotification.setIncludeDocuments("true");
eventNotification.setRequireAcknowledgment("true");
eventNotification.setUrl("https://A");
EnvelopeEvent envelopeEvent = new EnvelopeEvent();
envelopeEvent.setEnvelopeEventStatusCode("completed");
eventNotification.setEnvelopeEvents(Arrays.asList(envelopeEvent));
envelopeDefinition.setEventNotification(eventNotification);
I am trying to test the retry logic for this webhook. After few successful push requests, I intentionally made the service to return non 200 code (Example 404) for one of the request. Then I reverted the logic, so that the service continue to return 200 response for new requests.
I checked after more than 24 hours, the failed request was never retried.
Is there any reason why the request was never retried eventhough there were successful requests after the failure?
I also have a connect listener configured to push the complete notification for all the envelopes to webhook URL https://B
Currently we have come issue with this webhook URL, so all the push notification to https://B is getting failed.
Is the continuous failure with the https://B connect webhook stop retries to envelope level notification webhook https://A ?
Also Is there any difference between the connect retry vs envelope notification retries?
For for global account events (all users and envelopes) make sure "Require Acknowledgement" option is selected in your Connect settings for the specific webhook for the failed to be re-pushed.
Connect webhook is global (all users and envelopes) for the account and you can select when is triggered for example "Envelope Sent", "Envelope Voided" etc. In this way you can have multiple webhooks handling different account events.
In your case you are setting webhook notification only for the specified envelope.
Also this could help you
https://developers.docusign.com/docs/esign-rest-api/reference/Connect/ConnectEvents/
Connect retries at the account level for Aggregate Messages (the default) after 24 hours after a subsequent message is sent. I will ask about envelope-level connect retries.
Better is to switch to Send Intermediate Messages (SIM) queuing. It retries faster.
Best is to have a 100% always up listener (server). An easy and cheap (free) technique for this is to use AWS PaaS to receive and enqueue the messages. See blog post and sample code. We also have sample code for Google Cloud and Azure.
I have successfully implemented a system that creates documents to be signed via a template using the .NET API, and then has a DocuSign Connect listener that gets called upon the envelope being signed (right now only have Connect reporting on envelope signatures and declines). I have the option set to "Include Documents" on my DocuSign Connect settings. When I create the envelope for signature programmatically with one signer it all works - my Connect listener gets called, the /DocuSignEnvelopeInformation/DocumentPDF/PDFBytes element has Base64 data in it, and I have successfully decoded that and stored it in our doc management system. Cool. Demos well, management loves it.
However, I have noticed at least two scenarios where the /DocuSignEnvelopeInformation/DocumentPDF section isn't being returned at all:
When there are multiple signers.
When the envelope is created manually, even if it uses the same template.
I can still use the Connect response to get the /DocuSignEnvelopeInformation/EnvelopeStatus/DocumentStatuses and extract the document IDs from the DocumentStatus child elements, and then go retrieve those programmatically using the .NET API. But I am wondering why the PDF bytes aren't being consistently returned all the time? Is the above expected behavior? Am I missing something?
I would prefer to save "round trips" and just have Connect deliver all the signed PDFs to me when it calls (and yes, I have read the Recommendations for Receiving Documents section of the DocuSign Connect Guide and understand the trade-offs. Just wondering if I need to code around this issue, or what I am missing?
Hmmm. Envelopes don't get "signed," they get "sent" and "completed." See the envelopeEvents vs the recipientEvents lists in the Connect::Create call.
Currently, there is an existing issue which is that the connect daemon can miss an event if it is quickly superseded by another event. This might be what is happening when you have multiple signers for an envelope. The safest thing to do is to subscribe to all events and then ignore the notifications that are not of interest to you.
The terminal event of an envelope being "completed" will always be sent if you've subscribed to it.
Also, to make your app more bulletproof, I suggest subscribing to the Connect events via the API call (link is above) rather than depending on the human to setup up the subscription correctly. Since an account can easily have more than one connect subscription, you can track which one is your app's by using a specific name for the subscription.
Added
Just now, I created a Connect subscription for just the Envelope Completed event, for all users in my account on demo.docusign.net. As the subscription (listener) url, I used a free account from requestb.in
Using the web user interface (not the API), I created an envelope with two signers. After I completed the envelope, the requestb.in received the notification, it included:
<DocumentPDFs>
<DocumentPDF>
<Name>House architectural overview.pdf</Name>
<PDFBytes>....
as expected. So I'm unable to reproduce your problem. I suggest that you use requestb.in to double-check exactly what is being sent in the notification messages.
In our DocuSign Demo environment, we noticed that when several envelopes were voided, we did not receive the corresponding connect events. We checked the connect logs and the envelope ID's are not listed. We checked the envelopes in DocuSign and verified that the envelopes were properly voided. We sent a couple more through and recieved the events successfully.
Has anyone else experienced this issue and if so, were you able to correct it?
I'd suggest you verify the following Connect settings via the DocuSign UI (Preferences >> Connect >> [Connect_Configuration_Name]).
Ensure that Allow Envelope Publish is selected:
Ensure that Envelope Voided is selected, and also that All Users Integrated is selected (assuming you want Connect to send notifications for all envelope void events, i.e., for all Envelope Senders)
Provided that the Connect configuration settings are specified as described above (and logs are enabled via the Enable Log checkbox), you should at least see the Envelope Id in the Connect Log file anytime an envelope is Voided (even if some connectivity issue prevented the message from actually reaching your listener). Also, keep in mind that the Log file only preserves the 100 most recent log file entries -- so if there have been more than 100 messages sent since the Envelope Void that you're looking for in the Connect log, it's expected that you wouldn't see that Envelope Id in the log file.
Working with enterprise support, we determined that our missing connect event problem was caused by using the 'Send on Behalf Of' feature. We were listing the authenticating user in the 'Select Users to Integrate', and needed to list the send on behalf of user.
Also, Require Acknowledgement is NOT mentioned here and can and generally does play into debugging connect issues.
Related article:
Docusign Connect retry frequency when require acknowledgement enabled