DookuG functions

The module is capable of generating documents in multiple ways. After generation, the module can also return the generated documents in gzip-compressed format.

Document generation consists of three steps. The table below shows which functions are available in each case:

The signing function is also available on a separate endpoint for signing an existing PDF. It accepts the document to be signed in multipart format. The signing is performed based on the profile name specified in the request, according to the parameters defined in the configuration. The process runs synchronously, and the signed file is returned as part of the response.

Generated documents saved in the module database can be downloaded individually by their identifier. The response to the request returns the document in octet-stream format, as well as the file name. Upon request, the document can also be delivered in gzip-compressed format.

Storing the generated document is not recommended with the DookuG module. See: Storage

The metadata of generated documents can be queried in bulk in a filterable and sortable list, if they have been stored in the module database. The metadata includes: the file name, format, and status (DONE/FAILED).

Storing the generated document is not recommended with the DookuG module. See: Storage

In the case of digital signatures, the operation can be either certify or sign.

For example, if a certify signature is applied to a PDF document by an organization or authority, it ensures that the document is official and cannot be significantly modified. If only a sign signature is used, others may sign the document later, and it can still be modified to some extent, within certain restrictions.

Templates stored in the DookuG database support handling large content, validity periods, multilingual templates, and interrelated template structures.

TEMPLATE: This is the main table that stores the basic metadata of each template (e.g., name, validity period, language, etc.). If a template needs to be stored in multiple languages, then one record per language is required. This applies to both HTML and XSLT templates, regardless of whether the XSLT itself includes multiple languages. This is how DookuG determines in how many languages a given template is available.

TEMPLATE_PART: If a template is composed of multiple parts, this table helps distinguish between them, such as header, footer, body, etc. If the template consists of only one part, only one record is required in this table, regardless of language or template format.

TEMPLATE_TEMPLATE_PART: This is a linking table between the above two tables. There will be one record for each unique combination of language and template part.

TEMPLATE_PART_CONTENT: This table has a one-to-one relationship with TEMPLATE_PART and stores the actual template content as a BLOB, for performance reasons. It facilitates handling larger content and helps template caching. In the case of an HTML template, you must store one record for each language variant of each template part. For an XSLT template consisting of a single part, only one record is sufficient, as the structure itself may contain the multilingual content.

For detailed information about the database, see the database documentation.

The first version of the documentation.

The module can also return the generated documents in gzip-compressed format.