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.
...
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.
...
Overview
Content Tools