Continuation of post: Building NT 11 app to listen for DocuSign events

[jking]

Hi Bruce,

     Two years ago I posted about building a NT app to listen for forms and form data coming from DocuSign.  It has worked well for two years and I continue to receive form data daily.  You mentioned previously that this is essentially a Webhook scenario, where DocuSign acts as a client and sends me a "request" when one is available.  My NT Service app (listener) acts as the server.
     Today, my local University DocuSign Administrator emailed saying DocuSign has an issue.  Here is what he received from DocuSign:

"Information from DocuSign:


SUMMARY:
This email is to inform you that your account has been identified for containing a DocuSign Connect configuration that is no longer working or has not been configured to the HTTP standards we require to be considered a successful configuration. This email provides important information and resources to assist you with removing or correcting this configuration. Failure to complete this update by this date may result in an interruption of this service.

OVERVIEW:
Administrators will often set up testing configurations and then forget that they have an active configuration that they are not intending to use. When this is done in our demo environment we automatically disable a configuration14 days after it begins to fail. Starting in September 2022 we are going to begin implementing this same protocol within our production environments.

CONFIGURATION ID(s):
11118409, 11118409
Here are the configuration IDs on this account that will need to be addressed.

UPDATE OPTIONS:
To review the Connect Configurations go to your Connect Dashboard for your account. If you find that these configurations are no longer relevant or not being used you can select the Actions button to the right of the configuration and select the Deactivate or remove it entirely by using the Delete option from the drop-down menu.

If you find that your listener appears to be working but the configuration Id for this listener has been identified as failing your listener may not be reporting a http 200 message back to DocuSign as we require. To review best practices for healthy Connect configurations, see the API Usage Guidelines.

Disabling a configuration stops Connect from sending new event messages to the endpoint. It does not affect API access to those envelopes, templates, or clickwraps. After you address the issue, you can reactivate the configuration."

     


     I checked the DocuSign API Usage Guidelines and here is the entry for web hooks:

"Webhooks

When receiving webhook notifications from DocuSign, your computer is the server. DocuSign makes POST requests to your server.

Status: your server must be designed to always return a 200 status response to DocuSign when the message is successfully received. If your application does not need a particular notification message, it should respond with a 200 to DocuSign, then discard the message.

Availability: your server should be designed for 99% or better availability. It can have limited maintenance windows. It should be designed to be available 24 hours a day, 7 days a week. If this is difficult to achieve, you can use a PaaS (cloud) system to receive the messages from DocuSign and buffer them for your application. This configuration also enables your application server to receive the notification messages behind your firewall with no changes to your firewall.

Speed: your server should be designed to respond to each request from DocuSign within five seconds. Your server should use an asynchronous architecture: add incoming notification messages to an internal non-volatile queue, then send a 200 response to DocuSign. Asynchronously, one or more worker processes should process the messages from the queue."

   
     I'm not sure I have all the information I need yet, but thought I would post here to get your input.  In the guidelines above, it mentions that the NT Service app (server/listener) should return a 200 status response to DocuSign when the message is received successfully.  Does a NT Service app do this automatically or do I need to add something to do this?  I'm not sure where to do this if it is not automatic.

Thanks,

Jeff King

[Bruce]

Hi Jeff,

The short answer is yes, the default response code is 200.

Unfortunately though the email you got is light on details, as is your report. I'm not sure how you've built your server - what procedure types you are using, and so on.

What I would recommend is that you inspect the log to see what is coming into the server. You can then repeat this call yourself and see what the server responds to you.

This might be a good question for the User Group Webinar where I can see what you have done, and we can go from there.

Cheers
Bruce

[jking]

Hi Bruce,

     Thanks for your response.  I don't think I can make the webinar on Thursday so will provide some details about this app I hope will provide you with some more information.

     This is a simple NT 12.41 app with a web service called BreastDatabase.  There is a single method called ClinicalHistory, generated from the wizard with no changes.  This method only has code in the ProcessCode embed to get three files created by the DocuSign system (XML, PDF and XFDF).  Once these files are obtained, a number of Procedure Routines parse out data from the XFDF file and insert this into a TPS file.  See the image DocSignListenerApp.png and DocSignListenerCode.png.

     I also ran a test form through the DocuSign web site and it sent back test versions of the XML, PDF and XFDF files.  The log results of this session are in image DocSignListenerLog.png.  I still don't see where a response 200 has been sent back to DocuSign.  Is there a way to see what is being sent back to DocuSign?

Thanks,

Jeff

[Jane]

Two quick suggestions, Jeff.

1. Compile the Web77 client/server demo. Run that. Look at the Response tab on the client when you make a request.  (Mine shows a 200)

You could then adapt the client app to point at your actual server.

Or

2.  Compile the NetDemo app and use the Web Client to connect to your API.  The Logging tab in the Web Client will show you what's sent and received.

[jking]

Hi Jane,

     I chose suggestion 2, and have attached the results.  Image NT_Demo_Client.png shows the results returned when I connect to my API.  It does show HTTP/1.1 200 OK.  Image My_API.png shows the results of my actual NT App out on my server.
     If I interpret things correctly, my API is indeed returning a 200 status code.  What do you think?

Thanks,

Jeff

[Jane]

Yes, it looks like a 200 to me, Jeff.

Also try using the Logging tab (top row, to the right of the Atomic Time Server).

And try using parameters to get actual data from your API (I can't tell what you're getting back in your pics).  It should be the same.

That netDemo app is a good trouble-shooting tool to keep in mind.

Cheers,

Jane

[jking]

Thanks Jane!

     I have two other methods in my Web Service, one for system date and one for system time.  Using Date as a parameter I get back what is seen in the attached image.  By the way, with the previous run I only had it return the header, that is why you saw nothing else in the image.
     Since I'm getting the 200 status message and the date back from my API, can I assume that when I actually get data back from DocuSign, they are getting the 200 status message as well?

Jeff

[Jane]

Jeff,

I would go out on a limb here and assume that if this is what your service is replying, then this is what your service is replying.  But don't quote me

Jane

[Bruce]

Hi Jeff,

I think you've proved you're barking up the wrong tree here. Your service returns 200. So that's not the issue Docusign has. I recommend contacting them to get more information on what about the reply they are unhappy with.

Perhaps search the web for any other users who might have encountered this issue with them and might have more specifics.

Cheers
Bruce

[jking]

Thanks Bruce.

My local admin has finally opened a support case with DocuSign.  Hopefully that will tell us more.

Jeff