Page History
...
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 | ||||
| RelationToFileInstance | An instance of the entity specified in the FileID parameter will be created with the details of the uploaded file. This parameter specifies in which relation this instance will be created. This can be useful for reasoning about files just uploaded, as well as validations which you can attach to the relation. Note that the relation should point to the same entity as the FileID. Also, when you allow uploading multiple files, the relation should be multivalued as well, as for every file an instance is stored in the relation. | Input | Relation | 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.
| Warning | ||
|---|---|---|
| ||
Modeling a precondition on the AQ_File_Upload container which bases its condition on the Output parameters, results into that the events of the containers will not be executed. |
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.
MaxFileSizeon the AQ_File_Upload container- the
blueriq.fileupload.maxuploadsizeproperty (see Miscellaneous Properties) - the network infrastructure
- the (application) server settings
...
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
...
Validations
The AQ_File_Upload container contains the the Required parameter, if. If the parameter evaluates to TRUE the container will validate if a file has been successfully uploaded to that container. When no files have been successfully been uploaded the container will display a validation error.
Note that with the RelationToFileInstance parameter, you can can add validations to the relation attribute. This is a more powerful mechanism than the Required parameter, as it allows to express requiredness, but also more detailed validations such as "at least one document of type X needs to be uploaded", or "if a document of type Y is uploaded than you also need to upload a document of type Z", etc. etc. Another benefit is that you can customize the validation message. So in general the RelationToFileInstance parameter in combination with validations is preferred over the Required parameter.
Validations added to the validation rule must be blocking, as the flowing mechanism is actively blocked when a validation rule is not met. This means that when you define non-blocking validation rules (e.g. warnings), they are ignored. As these non-blocking validation rules are more of a hint to the user, you should convey this information in another way in this use case.
When you have multiple upload containers on a page and validation is triggered (by submitting the page for example), only validations (if any) for the top upload container will be displayed. This is because flowing (and validating) stops right after a validation rule is not met. This means in practice that if you have multiple upload containers which each have validations on them, the top one will be displayed, then if you "fix" that, the next one will be displayed etc.
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
Include Page Note on Persistence Note on Persistence
...
Overview
Content Tools