-
Notifications
You must be signed in to change notification settings - Fork 0
3.1.3 SUBMOD.001.003 : Get AML File by id
- Changelog
- 1. Scope
- 2. Definitions
- 3. Module Requirements
- 4. Analysis
- 5. Design
- 6. Implementation
- 7. Module Test
- 8. Summary
- 9. Appendix
Version | Date | Author | Comment |
---|---|---|---|
0.1 | 17.01.2021 | Namid Marxen und Nils-Christopher Wiesenauer | created |
1.0 | 14.05.2021 | Namid Marxen und Nils-Christopher Wiesenauer | finished |
The Module Documentations (MODs) describes the architecture, the interfaces and the main features of the module. It also describes the module/component test including the results. It can also serve as a programming or integration manual for the module. If there are some risks related to the module itself, they shall be noted and commented within this document.
AML: Automation Markup Language
CRUD: Create Read Update Delete
GUI: Graphical User Interface
JSend: A specification that lays down some rules for how JSON responses from web servers should be formatted
SAS: System Architecture Specification
SRS: System Requirements Specification
This submodule contains the endpoint for getting one AML file by an ID.
This REST API is the most important module because it contains the logic for converting the AML file to JSON. It also includes the authorization to the database. When a file is uploaded to the server it is converted from an AML format to a JSON format so that it can be saved in the MongoDB database. The content of the files are saved as a string and then converted into one JSON object, so that each file has their own database entry, with the JSON object as the content.
In order for the user to display a specific AML file, the REST API needs to have the functionality to return one AML file with a given ID. This is needed when the user wants to edit a file. Before editing, the content of the saved file needs to be put in a dialog. This content is provide by this submodule.
The requirement for this submodule is in part LF70
, because this submodule is needed in order for the user to get file he wants to edit. When the user clicks on a file in the list of files he wants to edit, a dialogue with the content of the file is opened in the GUI. This content is gathered by this submodule.
The submodule to get an AML file by id provides the functionality to get a file by id. This function is needed when the user wants to edit a specific AML file. He opens the file and provides an id from the GUI.
This function is required to give the user the ability to edit files. The function provides the interface between GUI and database in order to edit saved files. This function is part of the edit file submodule.
We included all /file
routes into our server.js
where the FILE
schema is imported to have every endpoint together and clear.
When this submodule is not available anymore, the user can no longer edit saved files. So this submodule is an essential part of the editing saved files.
Link to sourcecode: server.js
The needed /file/:id
and /file/:id/download
GET endpoints are defined below. Here we are using the created FILE model to get a file document by _id from MongoDB by using ´FILE.getFile(_id, callback)´.
const FILE = require('./models/file');
...
app.get('/file/:id', (req, res) => {
FILE.getFile(req.params.id, (err, file) => {
>> 6.2 Response data
});
});
app.get(`/file/:id/download`, (req, res) => {
FILE.getFile(req.params.id, (err, file) => {
>> 6.3 Response download
});
});
...
After finding the document we need to check if there is no error. If an error ocurred, we are sending a JSend with status 'error' and a defined message back. If everything was correct and a file could we found, we are modifying our base64 to ASCII. That because we need ASCII to modify our content of the file.
...
if (!err && file) {
let newObj = {name: file.name, content: Buffer(file.base64, 'base64').toString('ascii')}
res.status(200).send({ status: 'success', data: newObj });
} else {
res.status(200).send({ status: 'error', message: 'Unable to get file' });
}
...
After finding the document we need to check if there is no error. If an error ocurred, we are sending a JSend with status 'error' and a defined message back. If everything was correct and a file could we found, we are sending it as a JSend with status 'success' back.
...
if (!err && file) {
res.status(200).send({status: 'success', data: file});
} else {
res.status(200).send({status: 'error', message: 'Unable to download file'});
}
...
The endpoint/submodule to get an AML file by an ID is neccessary to provide the user with the ability to get the content of a specific file. It is triggered by a request from the GUI when the user presses the edit button on a specific file. The request is processed by the REST API and another request is sent to the database. The response of the database is sent back to the user via JSend. The recieved content is then shown in a dialog where he can edit the file.
The implementation of the module is descriped with SwaggerUI.
The source code of this module can be found here: aml-database-management-api/server.js
Testcase ID: | TC.REST.001.F |
---|---|
Testcase Name: | GET calls |
Requirement ID(s): |
LF110 , LF100 , LF30
|
Description: | The test case verifies that the REST API GET calls work as documented in the SRS |
Test Steps:
Step | Action | Expected Result |
---|---|---|
1 | Use the GUI to upload two files | Two files are uploaded and visible in the table in the home page |
2 | Open Postman and send the following GET request: localhost:3000/file | The two files that are present in the database are returned in the format as seen below, along with HTTP-Code 200. |
3 | Send the following GET request: localhost:3000/file/{mongoDBID}, where {mongoDBID} is the _id attribute of the first file that has been received in step 2 | Verify that only the first uploaded file is returned in the format below, along with HTTP-Code 200. |
{
"status": "success",
"data": {
"name": "TINF19C_AML_Library.aml",
"content": string
}
}
© LMF.software - Jonas Bihr, Namid Marxen, Johannes Emanuel Timter & Nils-Christopher Wiesenauer
For any question regarding our software contact us on here on GitHub.
- Home
- 1. SRS (System Requirements Specification)
- 2. SAS (System Architecuture Specification)
- 3. MODs (Modul Documentations)
- 4. MM (Meeting Minutes)
- 5. User Manual
- 6. Systemtestplan
- 7. Systemtestreport