Container type: AQ_File_Upload

With the container AQ_File_Upload it is possible to upload and store multiple files.

Note that all files that are selected will be handled as a bundle. That means that if at least one file can not be uploaded (e.g. because it has not the correct extension or because it is larger than specified) the entire set of files will not be uploaded.

Parameters

Name	Description	Direction	Type	Required
Connection	Specify the name of the connection (See How to setup a connection)	Input	String	Yes
FileExtension	Only file extensions that are specified can be uploaded. When none is specified, all file types are allowed. File extensions should be without a dot, e.g. txt.	Input	Expression	No
MaxFileSize	Only files smaller than the specified file size can be uploaded. This integer should be in bytes, e.g. 1048576.	Input	Expression	No
Persistence	The persistence parameter indicates whether the system should clean up files at the end of the session/request.	Input	Domain	Yes
MaxFileAmount	Provide how many files can be uploaded to this container. If -1 is provided there will be no limit.	Input	Expression	Yes
UpdateFileID	Specify the attribute containing the File ID when using the upload container for an update action. This is only relevant when using a single file upload.	Input	Attribute	No
CaseID	Specify the CaseId where the uploaded files belong to. When using the Process-Engine the value of this field is set as process_id in the metadata When using the Case-Engine, this field must be omitted. It will automatically be filled with the caseId during task execution.	Input	Expression	No
FileID	The returned file id should be put in the specified attribute.	Output	Attribute	Yes
FileName	The returned file name should be put in the specified attribute. The entity of the attribute should be same as that of the FileID parameter.	Output	Attribute	No
FileType	The returned file type should be put in the specified attribute. The entity of the attribute should be same as that of the FileID parameter.	Output	Attribute	No
FileSize	The returned file sizeshould be put in the specified attribute. The entity of the attribute should be same as that of the FileID parameter.	Output	Attribute	No
FileCreatedBy	The returned user that created the file should be put in the specified attribute. The entity of the attribute should be same as that of the FileID parameter.	Output	Attribute	No
FileCreationDate	The returned file creation date should be put in the specified attribute. The entity of the attribute should be same as that of the FileID parameter.	Output	Attribute	No
AuthorizedRoles	Select roles that are authorized for this document	Input	Role(s)	No
Required	When specified and evaluates to TRUE, the container validates if a file has been successfully uploaded before flowing to the next page.	Input	Expression	No

Event

This container can contain an event: FileUploaded. With this event it is possible to perform a flow action after the upload of each file (only applicable when the set of files is ok). Note that for multiple files a repeat condition has to be stated which should be put on a sub-flow.

The Unauthorized exit is triggered when updating a file for which the user does not have one of the needed roles.

Validation

Files that are uploaded through the file upload container are validated against the following checks:

FileSize is validated against the MaxFileSize, which can be set as a parameter of the container.
File extension is validated against the allowed extensions, which can be set as a parameter of the container.
File names can only consist of the following allowed specific set of characters and digits:
- a-z lowercase and uppercase and with or without diacritics
- digits zero until nine
- special characters _!@#$€%^&,.-+`~"-[]() and space
File ContentType is validated against the allowed extensions.
The amount of files is validated against the MaxFileAmount, which can be set as a parameter to the container.

Maximum file size

The maximum file size that can be uploaded is determined by a number of factors, of which not every factor is in control of Blueriq.

MaxFileSize on the AQ_File_Upload container
the blueriq.fileupload.maxuploadsize property (see Miscellaneous Properties)
the network infrastructure
the (application) server settings

Only the first two can be controlled by Blueriq.

The MaxFileSize on a container is enforced by the frontend (e.g. the Material theme) and the Blueriq Runtime. If a custom frontend is used, it is strongly advised to validate the file size for uploads.

The blueriq.fileupload.maxuploadsize property is enforced by the Runtime backend. If the size of a request is higher than this property, the request is aborted. This is a security feature, as it is otherwise possible to attack a server with very large requests. We strongly advise to set this property. It is important to note that contrary to the MaxFileSize on a container, which is per file, this property is per request, meaning that when you upload multiple files, the total size is counted.

Note that an aborted file upload request means that the progress bar in the UI will hang. Therefore, we recommend to set the blueriq.fileupload.maxuploadsize property to a sufficiently high value, so that this limit is not easily reached with normal use.

Regardless of what you set in Blueriq, there can still be network and application server limits that are imposed on uploads. When an upload fails, this should be taken into account when investigating the cause of the problem. As a general rule, Blueriq should be more restrictive than the network/server settings, so that if an upload is too large, Blueriq can handle it. For example:

MaxFileSize: 10485760 (= 10 MB)
blueriq.fileupload.maxuploadsize=26214400 (= 25 MB)
network/server restrictions 50 MB

Note that in this scenario if you upload 3 files in one go which are each a little less than 10 MB, your upload will still get aborted because it exceeds the blueriq.fileupload.maxuploadsize parameter.

Required file upload container

Since 16.1 the AQ_File_Upload container has the capability to be marked as a required container. Meaning that a file has to have been successfully uploaded to the container for page to continue flowing.

The AQ_File_Upload container contains the Required parameter, if the parameter evaluates to TRUE the container will validate if a file has been successfully uploaded to that container. When no files have successfully been uploaded the container will display a validation error.

Messages

Labels, descriptions, validations (such as "File is too large"), and status messages can be changed in the messages.properties files. An example can be found here: Reference Guide: Properties.

Note on persistence

The following rules apply for the Persistence parameter:
Connection Type Persistence Clustered Notes
Memory Temporary No The file is stored temporarily for the duration of the current request. At the end of the request the file is deleted. Memory connections and temporary persistence should be used when an uploaded/received file is immediately sent to a 3rd party system during the same request.
Memory Temporary Yes
Memory Permanent No Permanently storing files in a memory connections is not allowed. The Runtime will throw an exception when trying to permanently store files in a memory connection
Memory Permanent Yes
Other / FileSystem Temporary No The file is stored temporarily for the duration of the current session. At the end of the session the file is deleted.
Other / FileSystem Temporary Yes The file is stored temporarily for the duration of the current session and a Quartz job is scheduled to delete the file.
Other / FileSystem Permanent No The file is permanently stored in the connection and must be explicitly deleted when no longer needed.
Other / FileSystem Permanent Yes

Space shortcuts

Page tree

Maximum file size

Required file upload container

Messages

Note on persistence

Related articles

Connection Type	Persistence	Clustered	Notes
Memory	Temporary	No	The file is stored temporarily for the duration of the current request. At the end of the request the file is deleted. Memory connections and temporary persistence should be used when an uploaded/received file is immediately sent to a 3rd party system during the same request.
Memory	Temporary	Yes
Memory	Permanent	No	Permanently storing files in a memory connections is not allowed. The Runtime will throw an exception when trying to permanently store files in a memory connection
Memory	Permanent	Yes
Other / FileSystem	Temporary	No	The file is stored temporarily for the duration of the current session. At the end of the session the file is deleted.
Other / FileSystem	Temporary	Yes	The file is stored temporarily for the duration of the current session and a Quartz job is scheduled to delete the file.
Other / FileSystem	Permanent	No	The file is permanently stored in the connection and must be explicitly deleted when no longer needed.
Other / FileSystem	Permanent	Yes