File System and MongoDB
We can distinguish two families of data in our application:
- Data saved on database, such as file information, user information, repository information, folder information, temporary information for password changes
- Physical .bpmn files and folders managed by our local file system
The first information are stored and managed by MongoDB, a document-oriented NoSQL DBMS; while the latter are the physical .bpmn files and the folders that organize them and are managed by our file system and saved locally on our server. For example, if the user creates a new .bpmn template, this physical file is saved to the local file system on our server, while information such as file id, file name, author, creation date and version are stored inside a JSON document present remotely on MongoDB. The following image will show this concept:
In the left image “a”, we physically see the file saved on the server disk locally, while in the right image "b" all the information for this file: the structure of this JSON document is well dictated by the entity classes, called domain classes or POCO classes, which contain simply all the properties for what is called "Entity" and for every property a get method and a set method.
We have identified five entities: File, Folder, Repository, User and PasswordChange.
We have created a document-oriented NoSQL database in mongoDB called "C4":
To connect to this database we have to set a connection string from our server.
For each entity created by us, we find a collection of JSON documents:
Each collection list all the JSON documents, and each document contains information about a particular user, file, repository, folder or active password changing process.
For example we see Users documents:
For each User document, or let's say user stored in our database, we find properties like "id", "name", "surname", "email" and "password" that are, the properties defined in the POCO class User.java.
Click here to see the User.java file.
The other entities properties are defined by the following classes:
Files and folders are saved locally on the server and they are all contained within a folder called BPMFiles which is at the root level of the server. In the structure we thought, a file corresponds to a specific version of a .bpmn model, while the repositories and the folders correspond to the system folders. We can see the following abstraction:
For each registered user is created a dedicated system folder renamed with the id of that specific user. Within this "user" system folder we immediately find the repositories of that user, and each repository is a system folder renamed with the id of that repository. Within a "repository" system folder we can find a system folder "folder" renamed with the id of that folder, or a system "file" folder renamed the file id containing a .bpmn file for each version of that file. Each .bpmn file is renamed with the file id + version number. The "file" folder is an hidden system folder unknown to the user and is used by our file system as a container for all versions of a specific file. In turn, a "folder" system folder can contain several "file" system folders. This is an example of a possible scenario within our file system:
The path to access the first version of the only file for the first user is the following:
Root/idUser/idRepository/idFile/idFile.version
Example:
BPMFiles/5c6aee05250d3e3990f54044/5c6c4ddd270d3e4cac53cf05/5c6c4ddd270d3e4cac53cf06/5c6c4ddd270d3e4cac53cf06.1
The path to access the third version of a file for the second user conteined inside a folder is the following:
Root/idUser/idRepository/idFolder/idFile/idFile.version
Example:
BPMFiles/5c6aee05270d3e3990f54044/5c6c21f2270d3e2960cf8cae/5c6b10b8270d3e3990f54048/5c6b10b8270d3e3990f54048.3
These ids are only used by our file system and are stored inside MongoDB, in fact, the ids will never be shown to the user, while rather, the user will display the real names of other users, repositories, folders and files while using our application, also stored in the remote database.