Skip to content

File Uploading and Downloading

Lana edited this page Jul 18, 2017 · 8 revisions

This wiki page describes how the user can upload or download files associated with a certain attribute of a data object using the Chimera case engine and how they are stored and retreived.


Description

DataObject includes the hashmap of DataAttributeInstance s. If the data object has an attribute of file type, you can eventually upload or download it according to the process model.

Frontend

When executing and terminating an activity in the Chimera frontend, a modal window is shown, and it displays the data objects (and their respective attributes and the values) that are associated with said activity. The frontend now checks whether the attribute displayed in a row of the window is of type “File” or not and changes the properties of the row accordingly. If a File-Attribute is displayed, an Upload-Button as well as a Download-Button are shown instead of the attributes’ value that gets displayed normally.

When clicking the upload button, a file choosing window opens and the user can select the file that is to be stored and associated with the attribute. On successful file selection, (conceptually speaking) the file is uploaded into the database and stored there. When clicking the download button, the file will be retrieved and downloaded onto the client.

From a technical point of view, more things are happening in the background, which shall be explained below. The upload/download are implemented via REST.

REST and Angular

Clicking the upload button in the frontend dialogue, which is defined in the modalTerminateActivity.html, triggers the uploadFile-function that is defined in the scenarioInstanceController.js, it being the responsible angular-controller for the html-page. uploadFile takes the file from the frontend and the respective attributeID and creates a REST-Post with (JEngine_Server_URL + “/” + JCore_REST_Interface + “/files/” + attributeID +“/”) and the file as an appendix. The URL translates to localhost:8080/Chimera/interface/v2/files/attributeID when running Chimera locally. Server-wise the REST-request is then handled in ActivityRestService.java

/**
 * Uploads a file via the provided REST API into the database.
 *
 * @param attributeID	Id of attribute for which the file is to be stored.
 * @param uploadedInputStream	Stream representation of the file that is to be stored.
 * @param fileDetail	Details of said file.
 * @return 202 (ACCEPTED) means that the file was stored successfully.
 * Not only the file, but its file name and respective mime-type are stored in the database.
 */
@POST
@Path("files/{attributeID}/")
@Consumes(MediaType.MULTIPART_FORM_DATA)

In this POST-request, the uploaded file gets converted into a Byte-Stream and is then inserted into the database as a BLOB via a prepared JDBC Statement. The respective table fileUploads is defined in chimera_db_schema.sql and looks as follows:

fileUploads

  • attribute_id (int(11))
  • file (LONGBLOB)
  • filename (varchar(255))
  • filetype (varchar(255))

The decision to save files inside the database was made to simplify the explicit correlation between dataattribute_id in DataAttributeInstance and attribute_id in fileUploads. Also, the respective MIME-type for the file is determined when uploading and then stored in the database. This has to be done because sometimes issues arose when trying to access the content type from the file itself when downloading, now the content type gets transferred explicitly.

When the download file is clicked, the method downloadFile of the scenarioInstanceController is called, again with the attributeID corresponding to the attribute as a parameter. Then, firstly, a REST-GET is called, which returns the filename and the MIME content type of the file in question. After the result has been obtained, a second REST-GET is called, which returns the file itself. The resulting data is stored in an intermediate blob from where the contents that will be saved to the local machine with the proper file name are retrieved from, after the downloading dialogue has been accepted. Those requests are defined as follows, and they both execute a prepared JDBC Statement as well.

/**
 * Retreives the file that is stored in the database and associated with the given attributeID.
 *
 * @param attributeID   Id of attribute the file is associated with.
 * @return Returns the file as a response.
 */
@GET
@Path("/files/{attributeID}")
@Produces(MediaType.WILDCARD)


/**
 * Retreives the filename and its MIME-type for the file stored in the database with the given attributeID
 *
 * @param attributeID	Id of attribute for which the filename is to be retrieved.
 * @return Returns the filename and the mime-type comma-separated as a stream if present. 
 * Else, "null" as a stream is returned.
 */
@GET
@Path("/files/{attributeID}/filename")
@Produces(MediaType.APPLICATION_OCTET_STREAM)

Because of how the prepared SQL-Statement used for inserting the file into the database is written and because of our approach, a file can only be uploaded once and downloaded multiple times. This behaviour could be changed by modifying the Statement that gets executed in the REST-POST described above, should the need arise.


Architecture

Architecture


Upload/download workflow

To test the feature you can use the fragment modeled in Gryphon Modeler that demonstrates the data handling in Chimera. The model is packed in json file you can find here.

  1. Export to Chimera the process model that includes data objects with File attribute(-s). You can use Gryphon Modeler as well as Postman to send the data to Chimera.
  2. Start the new instance of case.
  3. Run the process till you come to the activity where data handling happens.
  4. When you click on terminate activity, you see the opened form where you can upload the file.
  5. Immediately after uploading you can download the file.
  6. The file after upload is saved to the database.

Modelled case

Paper Handling Process

Use Case: Master Seminar Planning

The documented feature was implemented within the scope of modeling and implementing the following use case.

Every semester the BPT Chair offers master seminars for students. The planning and execution of seminar consists of the various processes synchronized with each other. In order to simplify and automate the whole process group of students collaborating with the experts in the field created and executed business process using Gryphon Modeler and Chimera Engine.

Here you can find the results of the work: json file of models implemented in Gryphon, that can be deployed in Chimera engine directly - go to json file

archive with models from Signavio Modelling Tool - go to archive