Проблема медленного ответа API DocuSign,

Question

Я пытаюсь обновить содержимое документа конверта, используя DocuSign java API , но DocuSign отвечает на запрос в диапазоне от 4 до 38 секунд для того же конверта с теми же параметрами.

Например, однажды это займет 5 секунд, а второй или третий вызов API может занять 35 секунд.

Я использую эту конечную точку PUT /v2/accounts/{accountId}/envelopes/{envelopeId}/documents и в requestBody я помещаю EnvelopeDefinition с вложенным списком документов, которые имеют содержимое documentBase64.

Кроме того, параметры apply_document_fields и persist_tabs установлены на true.

Клиентская версия DocuSign Java - "2.9.0".

Я пытался запустить свой код в разных средах и в разных местах (сетях), и не могу понять, в чем причина такой большой разницы во времени выполнения этой конечной точки.

Может быть, кто-то сталкивался с такой проблемой и может подсказать мне некоторые пропущенные настройки или параметры, которые я не передал?

Для нашего проекта очень важно иметь постоянное время выполнения менее 30 сек c. Я ценю любые ваши предложения. Спасибо!

PS У меня проблема только с конечной точкой, упомянутой выше.

Другие конечные точки, такие как:

PUT /v2/accounts/{accountId}/envelopes/{envelopeId}/recipients/{recipientId}/tabs или ET/v2/accounts/{accountId}/envelopes/{envelopeId}/recipients/{recipientId}/tabs или некоторые другие выполняются одновременно более или менее.

Дублируется на github: https://github.com/docusign/docusign-java-client/issues/129

Answer 1

Добавление (или обновление) документов в системе DocuSign - большая работа, которая включает в себя следующее (и более):

• Если документ еще не в формате PDF, он преобразуется в формат PDF .
• PDF "сплющен" для удаления любых посторонних программ в PDF.
• PDF анализируется и обновляется для добавления вкладок и значений вкладок, соответствующих документу и конверту.
• Многое из вышеперечисленного сделано в выделенном экземпляре песочницы для указанного документа c, чтобы исключить любые шансы документа, вызывающие проблемы с безопасностью. (Помните, что файлы документов всех типов являются основным вектором для компьютерных вирусов.)
• Хранение документа в нескольких избыточных географически различных системах хранения файлов для обеспечения чрезвычайно высоких гарантий хранения данных.

Итог, вышесказанное требует времени. Время также масштабируется с размером документа. Этап преобразования также занимает много времени.

Если время, необходимое для одного и того же набора обновлений документов, варьируется, то это либо из-за загрузки системы, либо из-за многочисленных тестов A / B, которые мы предпринимаем для улучшения вышеуказанный поток обработки. - У нас есть активные инженерные проекты для улучшения всего вышеперечисленного.

Помочь ему go быстрее (или, кажется, go быстрее)

Если ваше приложение DocuSign отправляет файлы документов, которые больше пары МБ, тогда вы можете перейти к отправке документов в двоичном формате вместо Base64. Пример того, как сделать это с помощью Java, доступен .

Но реальная проблема заключается в том, что ваше приложение добавляет документы, когда человек крутит пальцы. Если это так, то:

• Обновляйте по одному документу за раз и предоставьте пользователю статус: «Загрузка документа 1 из 3 ... выполнена. Загрузка документа 2 из 3 ... выполнена . et c "
• Не блокируйте основной поток. Например, разрешите пользователю go выполнять другие задачи и разрешите документам обновляться в фоновом режиме.

• Если пользователь должен дождаться завершения загрузки, предоставьте его с индикатором занятости и обратного отсчета.

  Обратный отсчет: для моих приложений мое тестирование показывает, как долго длится максимальное время. (В вашем случае 35 se c). Затем я делаю таймер обратного отсчета javascript на более длительный период. И обновите счетчик два или три раза в секунду, чтобы ускорить процесс.

  Например, для максимальной задержки 35 сек. c, план на это займет, возможно, вдвое больше, 70 сек. c. Затем создайте счетчик, который начинается с 150 и уменьшается дважды в секунду. В результате задание будет всегда завершаться sh до того, как счетчик достигнет 0. И пользователь будет «счастлив», потому что он видит, что прогресс достигнут (счетчик уменьшается), и он заканчивается до достижения 0 («он закончил» рано '! ")

  Время обратного отсчета (гораздо больше, чем индикатор занятости) - это старая уловка фокусника, которая перемещает фокус пользователя с реального действия на что-то другое (обратный отсчет). Это работает хорошо. Ссылка: Включение интерфейса .