Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.
Comment: inserted the rrelevant v6 API calls

...

Section

Custom Tagging Page

This page is fully implemented in the custom web application for DMS tagging. The fact that it looks like the eSignAnyWhere Web UI is just because it was implemented that in a sample code. This is purely part of the custom DMS tagging sample.



In a simple webform, this can look like:


Section

Serverside handling of Form Data

After clicking the "Send Envelope" button in the custom tagging page, notify the backend of the tagging page implementation (also called "BeforeSendRedirectPage") and let the backend do the following with the retrieved form data:

Update Metadata in Draft

Set the data collected via the form e.g. in draft metadata section, to make these data available for the later callback processing
This will make the data available for pushing the signed documents to the document management system (DMS)

...

POST /v6/draft/update

Code Block
languagejava
titlePOST body
{
  "DraftId": "...",
  "MetaData": "..."
}

Send Envelope

While being on the BeforeSendRedirectPage, we are still working on a draft. There was no envelope sent yet. To send the envelope, we use an API method for the transition from draft to envelope:

POST /v6/draft/send

Code Block
languagejava
titlePOST body
{
  "DraftId": "..."
}


Section

Document Inbox

After the envelope is sent, the custom web app should redirect to the eSignAnyWhere document inbox. This is standard eSignAnyWhere functionality; the custom web application just needs to redirect to that page once done.

Info

Note if you want to cancel the settings:

Disable the beforeSendRedirectUrl in Settings-Organization. After all pending envelopes (drafts) have been sent, disable the OAuth Application (prevent log-in via this OAuth App). When disabling the OAuth App, existing drafts still contain the beforeSendRedirectUrl, so the OAuth Application should not be blocked before those drafts have been sent.

Application Flow – Callback Handler

After the callback for finished envelope was received, the callback handler should check if it was a completed action. The handler has to retrieve the envelope ID from the HTTP GET parameters. Then, the callback handler should note down the envelope ID in a persisted storage for further processing and return with an HTTP 200 (success) to indicate the archiving request was noted down.

...