A comprehensive guide to integrating document creation from templates, managing uploads, and configuring workflows for document processing.
User task nodes provide a flexible framework to defining and configuring UI templates and actions for specific template config nodes, such as an upload file button.
Before you begin, ensure the following prerequisites are met:
Access Permissions: Ensure that you have the necessary permissions to use the Documents Plugin. The user account used for these operations should have the required access rights.
Kafka Configuration: Verify that the Kafka messaging system is properly configured and accessible. The Documents Plugin relies on Kafka for communication between nodes.
To upload a document using this process, follow the steps outlined below.
In the previous section, you learned how to generate documents from HTML templates. This section focuses on creating a process where users can generate a document, review and sign it, and subsequently upload it.
This process involves several key nodes, each performing specific tasks to ensure smooth document creation, preview, and upload:
Document generation
Follow the steps outlined in Generating from HTML templates configure the document generation part of the process.
If you only need to upload a new file without generating it from templates, skip the template generation steps.
After configuration, your request and response messages should resemble the examples below.
This JSON structure represents a Kafka message sent through the ..in
topic to initiate a request in the Process Engine. It includes information for generating an “AccountCreation” document with a custom ID “119237” in English. Data specifies client details extracted dynamically from user input (first name, last name, age, country) and company information (name, registration date).
This an example of a message that follows the custom integration data model.
This JSON structure represents the response received on the ..out
Kafka topic, where the Process Engine expects a reply. It contains details about the generated PDF file corresponding to the custom ID “119237” and the “AccountCreation” template. The response provides file-related information such as file ID, document type, document label, storage path, download path, number of pages, and any potential errors (null if none). The paths provided in the response facilitate access and download of the generated PDF file.
Preview document
Configure the preview part of the process.
We will configure the service task node to construct the file path for the generated document.
Configure a business rule to construct a file path for the generated document. Ensure the base admin path is specified.
Ensuring the base admin path is specified is crucial, as it grants the required administrative rights to access the endpoint responsible for document generation.
Action Edit
Parameters
Explanation of MVEL code
Now we will configure the user task to preview the generated document.
Configure the Actions edit section:
Let’s see what we have until now.
The screen where you can fill in the client details:
The screen where you can preview and download the generated document:
Upload document
Configure the user task where we will upload the signed document genereated from the previous document template.
ai.flowx.updates.document.html.persist.v1
and its key: uploadedDocument
.Configure the following node actions:
This is a standard predefined FlowX Node Action for uploading files. This is done through Kafka and by using persist
topics.
Configuring the File Upload action
ai.flowx.in.document.persist.v1
.To identify your defined topics in your current environment, follow the next steps:
KafkaTopicsHealthCheckIndicator
line and then details → configuration → topic → document → persist. Here will find the in and out topics for persisting (uploading documents).BULK
.${processInstanceId}
(it will be replaced at runtime with a generated process instance id).callbacksForAction
- the value of this key is a string that specifies a callback action associated with the “upload_document” destination ID (node). This is part of an event-driven system (Kafka send action) where this callback will be called once the “upload_document” action is completed.
Now, configure the child actions of Upload File Action.
This is necessary to create the path to display the uploaded document.
Configuring the Business Rule action
Action Edit
Parameters
This is necessary to send the previously created information to the frontend.
Configuring the Send Data to User Interface action
Action Edit
Parameters
Configure the last node action to save all the data.
Action edit
To initiate the document processing, a Kafka request with the following JSON payload will be sent through ..in
topic:
This an example of a message that follows the custom integration data model.
Upon successful processing, you will receive a JSON response on the ..out
topic with details about the processed document:
Now the screen is configured for uploading the signed document:
The response, containing information about the generated and uploaded documents as mentioned earlier, is sent to the output Kafka topic defined in the Kafka Receive Event Node. The response includes details such as file IDs, document types, and storage paths.
The reply body is expected to contain the following values:
customId: A custom identifier associated with the document.
fileId: The ID of the file.
documentType: The document type.
minioPath: The path where the uploaded file is saved. It represents the location of the file in the storage system, whether it’s a MinIO path or an S3 path, depending on the specific storage solution.
downloadPath: The download path for the uploaded file. It specifies the location from where the file can be downloaded.
noOfPages: The number of pages in the document (if applicable).
filePath: The path to the file that we built in our example so we can display the document.
A comprehensive guide to integrating document creation from templates, managing uploads, and configuring workflows for document processing.
User task nodes provide a flexible framework to defining and configuring UI templates and actions for specific template config nodes, such as an upload file button.
Before you begin, ensure the following prerequisites are met:
Access Permissions: Ensure that you have the necessary permissions to use the Documents Plugin. The user account used for these operations should have the required access rights.
Kafka Configuration: Verify that the Kafka messaging system is properly configured and accessible. The Documents Plugin relies on Kafka for communication between nodes.
To upload a document using this process, follow the steps outlined below.
In the previous section, you learned how to generate documents from HTML templates. This section focuses on creating a process where users can generate a document, review and sign it, and subsequently upload it.
This process involves several key nodes, each performing specific tasks to ensure smooth document creation, preview, and upload:
Document generation
Follow the steps outlined in Generating from HTML templates configure the document generation part of the process.
If you only need to upload a new file without generating it from templates, skip the template generation steps.
After configuration, your request and response messages should resemble the examples below.
This JSON structure represents a Kafka message sent through the ..in
topic to initiate a request in the Process Engine. It includes information for generating an “AccountCreation” document with a custom ID “119237” in English. Data specifies client details extracted dynamically from user input (first name, last name, age, country) and company information (name, registration date).
This an example of a message that follows the custom integration data model.
This JSON structure represents the response received on the ..out
Kafka topic, where the Process Engine expects a reply. It contains details about the generated PDF file corresponding to the custom ID “119237” and the “AccountCreation” template. The response provides file-related information such as file ID, document type, document label, storage path, download path, number of pages, and any potential errors (null if none). The paths provided in the response facilitate access and download of the generated PDF file.
Preview document
Configure the preview part of the process.
We will configure the service task node to construct the file path for the generated document.
Configure a business rule to construct a file path for the generated document. Ensure the base admin path is specified.
Ensuring the base admin path is specified is crucial, as it grants the required administrative rights to access the endpoint responsible for document generation.
Action Edit
Parameters
Explanation of MVEL code
Now we will configure the user task to preview the generated document.
Configure the Actions edit section:
Let’s see what we have until now.
The screen where you can fill in the client details:
The screen where you can preview and download the generated document:
Upload document
Configure the user task where we will upload the signed document genereated from the previous document template.
ai.flowx.updates.document.html.persist.v1
and its key: uploadedDocument
.Configure the following node actions:
This is a standard predefined FlowX Node Action for uploading files. This is done through Kafka and by using persist
topics.
Configuring the File Upload action
ai.flowx.in.document.persist.v1
.To identify your defined topics in your current environment, follow the next steps:
KafkaTopicsHealthCheckIndicator
line and then details → configuration → topic → document → persist. Here will find the in and out topics for persisting (uploading documents).BULK
.${processInstanceId}
(it will be replaced at runtime with a generated process instance id).callbacksForAction
- the value of this key is a string that specifies a callback action associated with the “upload_document” destination ID (node). This is part of an event-driven system (Kafka send action) where this callback will be called once the “upload_document” action is completed.
Now, configure the child actions of Upload File Action.
This is necessary to create the path to display the uploaded document.
Configuring the Business Rule action
Action Edit
Parameters
This is necessary to send the previously created information to the frontend.
Configuring the Send Data to User Interface action
Action Edit
Parameters
Configure the last node action to save all the data.
Action edit
To initiate the document processing, a Kafka request with the following JSON payload will be sent through ..in
topic:
This an example of a message that follows the custom integration data model.
Upon successful processing, you will receive a JSON response on the ..out
topic with details about the processed document:
Now the screen is configured for uploading the signed document:
The response, containing information about the generated and uploaded documents as mentioned earlier, is sent to the output Kafka topic defined in the Kafka Receive Event Node. The response includes details such as file IDs, document types, and storage paths.
The reply body is expected to contain the following values:
customId: A custom identifier associated with the document.
fileId: The ID of the file.
documentType: The document type.
minioPath: The path where the uploaded file is saved. It represents the location of the file in the storage system, whether it’s a MinIO path or an S3 path, depending on the specific storage solution.
downloadPath: The download path for the uploaded file. It specifies the location from where the file can be downloaded.
noOfPages: The number of pages in the document (if applicable).
filePath: The path to the file that we built in our example so we can display the document.