CODEWITHSUNDEEP
javadocusignapi
evilfred
evilfred

Reputation: 2416

Docusign: creating envelope with multiple documents in multipart request from Java

The Docusign Java SDK doesn't have built-in support for creating envelopes with multiple documents as binary. This is cumbersome for users. People asking about have been directed to this one-off example code using Java's native HttpsUrlConnection: Docusign Multipart Request To Create Envelope using java SDK (the current link for this source is here: https://raw.githubusercontent.com/docusign/code-examples-java/ee8489ca749a007767f07e1871ec9be100b5abb2/src/main/java/com/docusign/controller/eSignature/services/SendBinaryDocsService.java) or raw HTTP request as at Docusign - send envelope REST API (POST multipart/form-data ). The sample code uses the raw HttpsURLConnection class to make HTTP requests, different from how ApiClient uses Jersey to make requests.

Why is this common use case not just built into the SDK? The SDK does actually have some multipart support in ApiClient.java https://github.com/docusign/docusign-esign-java-client/blob/master/src/main/java/com/docusign/esign/client/ApiClient.java serialize() and invokeAPI() methods, using Jersey parts. Note that FormDataContentDisposition is used, which will result in individual parts having the name "form-data". Also this route is not available for the EnvelopesApi.createEnvelope() method.

It's tempting to just make a direct ApiClient.invokeAPI() call to try and make use of this, but the code starting "// Generate and add Content-Disposition header as per RFC 6266" seems like it overwrites the "entity" with each individual part, so this may not work with more than one part?

The documentation of the API is found here: https://developers.docusign.com/docs/esign-rest-api/how-to/send-binary/ Both the description and sample code use "Content-Disposition: file..." while the web spec states that for each individual part of a multipart body "The first directive is always form-data" (https://developer.mozilla.org/en-US/docs/Web/HTTP/Headers/Content-Disposition) - which ApiClient itself does for its own multipart support.

ETA: experimentation shows that using "Content-Disposition: form-data" actually works fine

Clients are also asked to include "documentid=N" in the Content-Disposition, but it appears difficult to add this extra parameter at least when using Jersey's FormDataContentDisposition. If you look inside the source of glassfish FormDataContentDisposition / ContentDisposition you can see that only a fixed list of parameters will be included in the string buffer.

It would greatly help SDK users if we could get:

this would make life much easier for Java SDK consumers. Apologies if I got anything wrong here.

Upvotes: 1

Views: 361

Answers (1)

Larry K
Larry K

Reputation: 49104

A well written question. To better register your sdk enhancement request, see feedback.docusign.com and request via your DocuSign sales person.

THE SDKs are autogenerated from our swagger file. So your request would be a large project and is not currently planned.

While uploading with base64 encoding is inefficient, it works fine.

Upvotes: 1

Related Questions