Asset Equipment Registry (ASER)
Transcript of Asset Equipment Registry (ASER)
Asset Equipment Registry
(ASER)
Tracking equipment in Universities
Ivy Bui and Frinze Erin Lapuz
Copyright System Health Lab 2021
Table of contents
31. Asset Equipment Registry (ASER) Documentation
42. User
42.1 Overview
53. Organisation Maintainer
53.1 Overview
64. Administrator
64.1 Overview
75. Developer
75.1 Technical Documentation for Developer
85.2 Requirements
155.3 Coding Patterns
165.4 Frontend/Client-Side App
215.5 Backend/Server-side App
275.6 Continous Integration Pipeline
285.7 Deployment
Table of contents
- 2/28 - Copyright System Health Lab 2021
1. Asset Equipment Registry (ASER) Documentation
1. Asset Equipment Registry (ASER) Documentation
- 3/28 - Copyright System Health Lab 2021
2. User
2.1 Overview
2. User
- 4/28 - Copyright System Health Lab 2021
3. Organisation Maintainer
3.1 Overview
3. Organisation Maintainer
- 5/28 - Copyright System Health Lab 2021
4. Administrator
4.1 Overview
4. Administrator
- 6/28 - Copyright System Health Lab 2021
5. Developer
5.1 Technical Documentation for Developer
5.1.1 Client-Side Application
React and NextJS (the specific React variant that is being used) is used for creating the client-side application for both the
"frontend-subsection" and "backend-subsection" of the website. The purpose of this application is to make an interactive and
intuitive web application design.
The design is carried over from Material UI with templates from Creative Tim Material Dashboard (for the sponsor-facing
website) + Material Kit (for the front-facing website).
5.1.2 Server-Side Application
ExpressJS/FeathersJS is used to create the server-side application that the client-side application connects to. The purpose of this
application is to facilitate permission and data transformation and retrieval from the database. The database will be using a
MongoDB, a NoSQL database that is excellent for OLTP operation and fast-protyping.
5.1.3 Simple Changes
React is mostly just a better HTML. If you require very simple changes in the website such as just a tagline or information, just
go to the client folder and perform a find . Find the place you want to replace, and change it as you see fit.
Branch out from the main branch. Commit the change that you made. Go to Github Pull Request, and create a pull request. Get
the change reviewed and merge. Then go to the deployment server, and do a git pull , and follow the deployment procedure.
5. Developer
- 7/28 - Copyright System Health Lab 2021
5.2 Requirements
5.2.1 Acronyms, Abbreviations and Definitions
UWA: The University of Western Australia
SHL: System Health Lab
Organisation: A club, lab, or group of people at UWA, for example, the Makers club, Motorsports club, System Health Lab,
unit coordinators, etc.
Asset/equipment: These terms will be used interchangeably, and will refer to ready-to-use engineering equipment owned by
organisations at UWA. Assets include 3D printers, portable microscopes, slamsticks, motors, and other large equipment. It
will not include infrastructure-based equipment or assets, or equipment parts.
Administrators: The users that have access to creating organisations and adding users to particular organisations.
Maintainers: Also known as organisation maintainers. A member of a UWA organisation responsible for maintaining the
equipment database of their organisation.
Users: General users of the system, specifically pheme authenticated UWA staff and students.
MERN - MongoDB, ExpressJS, ReactJS, NodeJS - a JavaScript set of technologies to build full-stack web applications
5.2.2 Aim and Scope
UWA currently houses thousands of engineering equipment across the multiple disciplines. However, this proposes a problem as
there is no database of the existing equipment that can be searched through by UWA staff and students. The ASER project aims
to develop a central, consolidated equipment database that can be searched by the university's staff and students. This gives staff
and students the opportunity to locate and request access to tools and equipment that they wouldn't otherwise be able to use
outside of their enrolled units and university clubs.
ASER will only track pieces of equipment that are ready to use, for example, 3D printers, portable microscopes, ovens,
slamsticks, motors, and other large equipment. It will not track infrastructure-based equipment or assets, or parts, for example
pumps, sensors, screwdrivers, and dremels.
This will replace the current system which consists of private, non-accessible data from the finance department (asset IDs) and
Matt Arpin's Excel spreadsheet, neither of which include complete lists of the equipment. The issues with this current system is
outlined in Table 1 below.
•
•
•
•
•
•
•
•
5.2 Requirements
- 8/28 - Copyright System Health Lab 2021
Table 1: Issues with the current system
5.2.3 Requirements
Stage 1 Functional Requirements
The following are the core functional requirements for the first stage application, which will support all user levels:
administrators, maintainers, and users
ADMINISTRATORS
MAINTAINERS
Issue Description / impact The Solution
Non-accessible
data
Staff and students aren't able to search for the equipment
they require as information regarding the equipment is
only available through Matt Arpin's Excel spreadsheet or
the finance department, neither of which is publicly
available.
Will be able to be accessed by UWA
staff and students using their PHEME
credentials.
Non-centralised
data
The assets or equipment in UWA is recorded in many
places or not even recorded in some case.
Will be a centralised system that
consolidates all the equipment in
different organisations
Isn't regularly
updated
Staff and students may go to the specified equipment
location, only for it to not be there as the spreadsheet
hasn't been updated.
Will have an intuitive user interface,
so that it will be easy for users to
update information about an
equipment.
Doesn't keep
track of all
equipment
The finance department only has asset IDs for equipment
meeting a certain crtieria. Matt Arpin's Excel spreadhseet
doesn't include some equipment from research labs,
although it is unclear what equipment is included and what
isn't.
Will become the only database to keep
track of all equipment outlined, and
should therefore be kept up-to-date
with any new equipment.
Identifier Name Description
FRA1 Administrator login The user can login using pheme
FRA2 Add administrators
FRA3 Add organisations
FRA4 Add maintainers to organisations
Identifier Name Description
FRM1 Maintainer login The user can login using pheme
FRM2 View organisation's equipment
FRM3 Add new equipment
FRM4 Edit/update equipment information e.g. location, quantity
FRM5 Remove equipment
FRM6 Add maintainers to the organisation
5.2.3 Requirements
- 9/28 - Copyright System Health Lab 2021
USERS
Stage 2 Functional Requirements
"Nice to have"
The "nice to haves" of this project will not be covered in this requirements documents. This is because the "nice to haves" will
come along as the users of the system see fit. This will be documented in the Issue Tracking Management sytem of the code
repository.
Some of the "nice-to-haves" as of this writing are:
Ability to click the location and show the location in the UWA Campus
Ability to scan the barcode of an equipment which will show the equipment's information on the ASER webapp
Ability to ensure that prior to items being deleted, either the finance department or Matt Arpin have been contacted. Also
link the Asset Disposal Form.
Ability to have parent and child assets, and automatically update the parent and/or child assets, depending on the status of
the related parts. For example, an asset may be made up of multiple child assets. If the asset goes missing, all the child
assets should also be marked as missing.
Identifier Name Description
FRU1 User login The user can login using pheme
FRU2 Equipment search
FRU3 Contact the maintainer about equipment
FRU4 Request equipment location update
Identifier Name Description
FRG1 Transfer
Ownership
Organisations can give equipment to another organisation. This typically occurs
when an organisation is dissolved.
FRG2 Loan Organisation can loan equipment to users in the system and should be able to record
which equipment has been loaned, to who, and for how long.
FRG3 Automated
Reminder System
The maintainers should receive a list of equipment that needs to be updated based
on the last updated time at a certian period in the year.
FRG4 Sync the data
from Finance
System
As mentioned, the Finance department tracks of certain equipment as well that fits a
certain criteria. Since, this is one of the existing procedures in UWA. It would be
great if the system can sync data in the Finance System especially for new
equipment that comes in.
•
•
•
•
5.2.3 Requirements
- 10/28 - Copyright System Health Lab 2021
Non-functional Requirements
5.2.4 Proposed Solution
The proposed solution is to build a custom web application that will encompass and satisfy the requirements (by completing the
suggested "ideal solution" as per the Aim and Scope).
Some research for existing design solution has been done for this project see Appendix: Existing Design Solution. The beauty of
custom web application for the UWA SHL is that it upskills the current software engineers in the lab as aligned in the values of
SHL, and the high possibility of extending application depending on the requirements without being constrained with the bulk of
codebase of other unmaintained opensource projects. Comparatively to enterprise systems, most enterprise systems will charge
per users that use the system, this easily becomes expensive because the amount of users that will use the system should be able
to accomodate the number of users that are interested in looking for the assets.
Core Technologies
The custom web application will aim to satisfy all the requirements in here along with the "Nice to haves" as they come up. The
application will be built using the MERN stack, the same stack used by the IndEAA (of UWA SHL) and AMIRA (UWA Future Tails)
project. By using the same stack, the codebase can be share such that development in one codebase will easily be transferred or
translated to another codebase, essentially reducing the total development time while delivering high value in this project and
other projects.
The authentication system will be outsourced to the UWA Pheme Authentication API to allow any users in with a UWA Pheme
account to login.
REACTJS/NEXTJS
React is a popular frontend technology to create website divided into components and utilizes client-side rendering to allow fast
loading speed with the trade-off of slower initial load speed (NFR2 - Performance).
The division of UI into components allows easier re-usability of UI components such as a header and a footer that appears in
every page, and allow easy to change for update - "one change, change it all" (NFR3 - Maintenance and Extensibility).
The main power of React is the ecosystem and libraries that are available on top of it such as NextJS and Material UI which can
ultimately cut the development speed, and allows easier upgrade than other technologies (NFR5 - Maintenance and
Extensibility). Two of the common technology used with React is Babel Transpiler for cross-compatibility (NFR6 - Compatibility)
and webpack bundler/minifier for lower bundle or required downloads size (NFR2 - Performance).
Identifier Name Description
NFR1 Security Only authenticated and authorised users should be able to perform actions such as
adding equipment, updating equipment location and information, or searching for
specific equipment.
NFR2 Performance The loading time should not hinder the user experience and productivity of the user
in the website. The page and actions should have a loading time < 5 seconds on
most computing environments on standard internet connections
NFR3 Maintainable and
extensible
The website should be relatively easy to update and extended to accomodate for
new contexts.
NFR4 Recoverable In the event of the web server or database server crashing, all stored data should be
fully recoverable.
NFR5 Intuitive user
interface
The website should have an intuitive / easy-to-use user interface, so that users will
be able to easily use the website and update the equipment database
NFR6 Compatibility The application should be compatible with recent versions of the major browsers
(Safari, Chrome, Firefox and Edge) on laptop and desktop computers
NFR7 Deployability The application should be compatible with deployment in the SHL VPS
5.2.4 Proposed Solution
- 11/28 - Copyright System Health Lab 2021
NextJS is a library for React that allow server-side static web generation, handling web routes, and code splitting. Server-side
static web generation allows the processing of HTML, CSS and JS in the server for the initial serving of web content, and allows
web crawlers to read content. Furthermore, NextJS handles web routing with hot reloading - loading only components that has
not been downloaded by the browser to allow fast navigation (NFR2 - Performance). Code Splitting is used by NextJS to allows
faster initial load speed by only loading code that will be used for the initial session (NFR2 - Performance).
BACKEND: MONGODB
MongoDB is a noSQL database solution that is efficient and flexible with minimal overhead. It would fulfil all data storage
requirements of the system.
Backend: ExpressJS/FeathersJS
Express is a library on Nodejs (a platform to run JavaScript outside of the browser) to easily create HTTP servers.
Feathersjs is a wrapper for application in Express, essentially to make development easier by loosely enforcing developers on
creating RESTFul API (following uniformity of HTTP methods). It makes development easier by making route to database call
uniform.
MATERIAL UI/MATERIAL KIT
CSS libraries allows cutting the development time for design such as Material UI that contains ready-to-use UI components that
are compatible to cross-browsers (NFR6 - Compatibility), excellent in design (NFR5 - Intuitive user interface), easy to use, and
extensible (NFR3 - Maintenance and Extensibility).
Material Kit is an extension of Material UI that provides a base template for few pages, and a package of configuration for the
most common UI component.
DOCKER
Docker is a deployment technology that allows virtualization in a server to allow the packaging of software into containers for
deployment. To satisfy NFR7 - Deployability, the web platform will use docker to allow the deployment through the SHL VPS
Server.
Furthermore, Docker will be used for orchestration of different services in development to increase speed of development, and
reduce inconsistency between developers devices (NFR3 - Maintainable and extensible).
CODE QUALITY
The code quality will be ensured by peer reviews between the developers in the team.
CODE STORAGE AND DEVELOPMENT CONTROL
Git source control will be used, using the remote UWA System Health Lab organisational GitHub (NFR3 - Maintenace and
Extensibility).
Prototype
See the Prototype mentioned in Figma Interface Prototype
Execution Team
The development of the web platform will be performed by the UWA System Health Lab Redbacks Team: Ivy Bui, Michael
Nefiodovas, with the lead of Frinze Erin Lapuz, and the guidance of Melinda Hodkiewicz.
5.2.5 Development and Methodology
As per the staged requirement, majority of the development will take place on the stage 1 whereas stage 2 are feature-based
requirements for the syste,.
Below is the rough development methodology:
5.2.5 Development and Methodology
- 12/28 - Copyright System Health Lab 2021
flowchart TB Requirements_Gathering --> S1:Development & Deployment subgraph S1:Development S1:Testing
S1:Authentication_Integration S1:Administrator_Pages S1:Maintainer_Pages S1:Centralised_Asset_Query_System
S1:Data_Engineering_Refinement end subgraph Deployment Setup_Domain_Name Dockerising_Container
Acquiring_Cloud_Based_Database end S1:Development <--> S1:UAT Deployment & S1:UAT --> S1:Website_Launch
S1:Development --> Codebase_Refinement --> S2:Development subgraph S2:Development S2:Transfer_Ownership S2:Loan
S2:Automamted_Reminder_System S2:Finance_System_Data_Sync end S2:Development <--> S2:UAT --> S2:Website_Launch
S2:Website_Launch --> Steady_State_Development_Fixes_Testing_Deployment
5.2.6 Appendix
Existing Design Solutions
Some of the design solutions that have been considered with great detail and justification are here.
MYOB
MYOB is known for its accounting software that is integrated with inventory systems. However, the functionalities for registry of
equipment and asset differs from inventory systems. Furthermore the cost for the features for MYOB starts at $109.00/month.
The biggest problem faced would be the difficulty to make the system accessible for multiple users. Hence, it is ruled out in the
possible design.
GOOGLE SHEETS / EXCEL SHEETS IN ONEDRIVE
Excel sheets and google sheets are one of the most flexible systems out there. Authentication within someone that has
"uwa.edu.au" account is automatically enforced within documents shared within the campus. However, the biggest problem that
can easily be seen are:
the ease of use. This is especially visible if the excel sheet will have so many columns to accomodate all possible information
that is there.
Authorisation/permission. A system being centralised requires that maintainers can only edit information regarding their
own assets. This is hard to enforce in either Google Sheets or Excel sheets, as the only permissions are "write" and "read"
Consistency - because Excel does not enforce any types or columns in the Excel sheet, if a maintainer cannot find a field that
satisfies their information, they will create another column which increases inconsistency since not all equipment/asset will
have that field
Difficulty to display Many-to-Many data relationships. This is easily thought of for "Tags" system (ability for users to see
equipment at a particular category), that is very hard to display in flat-file tabular format.
MAZEMAP ASSET TRACKING
Mazemap Asset Tracking is an API designed by Mazemap to visualise and track assets in real-time. According to the case study,
the example use cases are:
Shopping mall kiosks / map stations
Hospital self-service kiosks
Conference venue mobile applications
Hotel customer program applications
Facility management applications
Facility cleaning service applications
The cost is unknown. It looks perfect for this project, however there are too many unknowns in terms of its limitation. It has a lot
of shiny features such as real-time equipment tracking (that possibly may require sensors), which means that there are a lot
features that may not be used. By practice, this will usually complement the cost, not to mention the setup to integrate the UWA
Authentication system (either UWA Pheme Authentication API or UWA SAML SSO) with a third-party application. It is presumed
with these assumptions that the API may be "overkill" for this project.
•
•
•
•
•
•
•
•
•
•
5.2.6 Appendix
- 13/28 - Copyright System Health Lab 2021
However, it is worth pointing out that UWA already uses a MazeMap product see UWA Campus Map. This means that although
the project might not use Mazemap Asset Tracking, it is possible to use the existing UWA Map API without extra costs. The Map
API can be seen here. More information about different API can by reverse engineering the Map API with network request
scanners.
5.2.6 Appendix
- 14/28 - Copyright System Health Lab 2021
5.3 Coding Patterns
5.3.1 Casing
This codebase will be using camel casing.
You will sometime see some variables that ends with _id such as user_id . This is not a camel casing, but rather indicates that this is
a MongoID reference.
5.3.2 Linters / Formatters
This will automatically format your code if you install ESLint in VS Code or type yarn lint in the specific folders.
Make sure you have installed the devDependencies so additional linters can be used.
5.3.3 Github Issues and Pull Requests
Most changes in the codebase can be matched to a github issue that contains description of the work that needs to be done. Each
of the pull request are matched to this github issue with the branch name that has a standard a{Issue Number}-{branch name} . The
issue number allows referencing especially when resolving reason for change.
5.3.4 Development with Docker
The development is done with Docker to orchestrate multiple services as defined in the docker-compose.yml file:
Mongo Database at localhost:27018
Database Administrator at localhost:27001
Client Side application at localhost:10015 (this is similar in deployment)
Server Side application at localhost:10016 (this is similar in deployment)
Documentation at localhost:8001
Snake case with _id
•
•
•
•
•
5.3 Coding Patterns
- 15/28 - Copyright System Health Lab 2021
5.4 Frontend/Client-Side App
5.4.1 Authentication and Authorisation (Levels of Permission)
Authentication refers to a user being recognised in the system (in this case being logged in). Authorisation refers to a user
having the permission or ability to do an action.
In the ASER web app, there are different levels of permission indicated by:
Administrator
Organisation Maintainer
User
Administrator
They can do whatever they want.
Organisation Maintainer
This specific role is tied with a specific organisation. They are mainly responsible for the organisation information and equipment
listing.
User (The General User)
This is the role dedicated for anyone that has Pheme access. Technically, this permission is automatically granted and does not
require a specific permission listed in the user. In other words, if a user does not have any permission listed in the table, and
permission that is supposed to go to a general user is granted for anyone.
Implementation
JWT AUTHENTICATION
The authentication is handled by Feathers (authentication documentation) for server-side user processing and in some extent
client side.
The authentication methods are:
local (email + password (hashed when stored))
Oauth with Auth0 (todo)
REDUX STORE
The authentication and user details is stored in the redux store with the auth reducer (refer to reducers/index.js and reducers/
auth.js )
AUTHGUARD COMPONENT
The AuthGuard component in components/Layout is responsible for checking:
authentication
authorisation
and is defined in client/components/layout/AuthGuard (the authenticated dashboard layout) and to wherever requires more levels
(usually used for authorisation eg. Administrator pages).
•
•
•
•
•
•
•
5.4 Frontend/Client-Side App
- 16/28 - Copyright System Health Lab 2021
By default AuthGuard will only test authentication
The flag enforcePermissionAccess is used to indicate Authorisation enforcement.
By implementation when the route starts with /administrator , it requires user to have administrator role in their permission.
When the route has organisation id, it will require user to have the right combination of org_id and role as a maintainer
Multi-Role Authorisation
5.4.1 Authentication and Authorisation (Levels of Permission)
- 17/28 - Copyright System Health Lab 2021
5.4.2 Notification with Redux-Saga and Notistack
The notification functionality is handled with Redux Saga and Notistack. To summarise, redux saga listens for "actions" that
happens in the application, and then sends a new action ADD_NOTIFICATION_MESSAGE to add to a redux store. This action to add a
notification to the store triggers the Notistack component to render a notification.
With reference to Feathers Redux, the action types are written in the documentation.
When a user is created in the frontend, the action services.users.types.SERVICES_USERS_CREATE_FULFILLED is called upon. See client/
store/feathersSaga.js
As it can be seen, a new action ADD_NOTIFICATION_MESSAGE is sent, and is automatically color coded (can be overwritten) with the
notification.
With reference to the SnackbarProvider in _app.js and the Notification component in components/Layout/Notification , it can be seen
that it performs action to enqueue Notifications.
Often times in the codebase you will see code that looks like this:
This means that notifications are handled when certain actions happen. You can certainly add more things when error occurs, but
this is something to note that every call that can result in an error should be caught.
How to add a new notification?
Based on what was said with how it works:
Add new listeners in the Redux Saga file on the name of the custom action
Example of Notification
Error Handling
1
2
3
4
5
6
7
8
9
try{
await services['monitoring-system'].patch(tech._id,{
...modalState
});
closeModal();
}
catch(error){
// Handled by Redux-Saga
}
1.
5.4.2 Notification with Redux-Saga and Notistack
- 18/28 - Copyright System Health Lab 2021
5.4.3 Forms
Forms are fundamentally one of the important elements in web apps.
Form Validation
Form validation does not exist in this app.
The frontend echoes the error received from the backend. In this specific example, the error that happened is while modifying the
model , and found that there is invalidation.
Custom Form Handlers
There exist components in components/custom/FormHandlers . These components help in generating functions that you can directly
use in your form component to modify the state in that particular component. Make life with forms easier!
How the heck do I get notification that my random string in the email field about what is wrong?
5.4.3 Forms
- 19/28 - Copyright System Health Lab 2021
5.4.4 Figma Inteface Prototype
The prototyping of the interface has been done in Figma. See here
The Figma designs is directly corresponding to the template ASER has been started with.
5.4.4 Figma Inteface Prototype
- 20/28 - Copyright System Health Lab 2021
5.5 Backend/Server-side App
5.5.1 Backend with FeatherJS
Feathers is a lightweight web framework for creating realtime applications.
There are only really a couple of things about Feathers as seen in the image:
Feathers has functions that are similar and you can run both client-side or server side. This means when you write tests, you use
the same functions as you would when you use it for client-side (almost, I'll talk about that in a second). There are 2 parts about
it as (I recommend reading the original documentation further):
5.5 Backend/Server-side App
- 21/28 - Copyright System Health Lab 2021
1. Services
Services are the endpoints in FeathersJS. Unless specified in this documentation, all services supports all the HTTP methods
GET (find + get service methods)
POST (create service method)
PATCH (patch service method)
UPDATE (update service method)
DELETE (remove service method)
2. Hooks
Hooks are just functions that runs before, after, or on error.
We know that there are a lot of services in this application that may require authentication. Hence, the idea is to be able to reuse a
single function that performs authentication before certain service methods.
Developer Tools with FeathersJS
Install the feathers cli , these will help you lot in extending the backend. You can use it to generate/bootstrap the boilerplate
codes when generating services, and hooks.
Feathers-Redux / The Frontend Wrapper around Redux
Feathers-redux is a wrapper around redux and feathers. The purpose of this is to map the feathers functions directly to your
store.
In effect, whenever you do let say "create" call, then it updates the database, and automatically updates your frontend.
With the original feathers call, the syntax is client.service('users').create(...) , in Feathers Redux it is
app.service.users.create(...) .
Mongoose/MongoDB
MongoDB is a NoSQL database used for this project. Mongoose is just an ORM to add types and validation. The customised
wrapper for Feathers is Feathers-Mongoose.
The main advantage of MongoDB is the whitelists parameters eg. $populate which can be used with Feathers (see example).
At the end of the day, the database doesnt really matter as much. If you'd like to change it, you can just replace it with many of
the Feathers Database Adapter.
•
•
•
•
•
Example: Authentication hooks
Difference of the service calls
Custom Queries from Endpoints
5.5.1 Backend with FeatherJS
- 22/28 - Copyright System Health Lab 2021
5.5.2 Testing
Testing is done with Mocha Assert + Chai, see here for more info.
Mocha provides describe and it , while Chai provides "english-like" syntax like expect(exampleArray).to.have.lengthOf(3);
Easy explanation
5.5.2 Testing
- 23/28 - Copyright System Health Lab 2021
5.5.3 Authentication with UWA Pheme
The authentication system is fitted with the System Health Lab's Pheme Authentication API that can be accessed in https://
auth.systemhealthlab.com.
See further information about the documentation.
Related files
The files that are related are:
/auth/pheme.strategy.js the custom strategy for handling authentication
authentication.js the endpoint for the authentication handler
The Authentication Fields
Look at the documentation for the specifics, but in ASER, the fields that we care about are:
username
firstName
lastName
Test Accounts
In non-production environment, there are 4 accounts that can be used, pheme numbers are the following:
00000001 (7 zeros and 1)
00000002 (7 zeros and 1)
22222221 (7 twos and 1)
22222222 (7 twos and 2)
with passwords demo .
•
•
•
•
•
•
•
•
•
•
5.5.3 Authentication with UWA Pheme
- 24/28 - Copyright System Health Lab 2021
5.5.4 Data Engineering
This covers the section all about data in the system: how it flows from and out of the system to the users, and how the data is
stored. This dictates fundamentally how the system would work.
See diagram below for illustration.
Entity Relationship Diagram
This illustrates how the data is structured with relation to one another.
5.5.4 Data Engineering
- 25/28 - Copyright System Health Lab 2021
Diagram
5.5.4 Data Engineering
- 26/28 - Copyright System Health Lab 2021
5.6 Continous Integration Pipeline
These are just scripts that run whenever you do pull requests and successful merges. There are a couple of scripts that are
currently configured see .github/workflows :
5.6.1 Automated Linting/Formatting Check lint.yml
This is checks formatting of your code both client and server folders. It can also help eliminate possible silly mistakes that
prevent the code from running.
5.6.2 Automated Documentation Deployment docs.yml
This automatically deploys this documentation whenever main is updated with new changes.
5.6 Continous Integration Pipeline
- 27/28 - Copyright System Health Lab 2021
5.7 Deployment
Deployment is done in the System Health Lab VPS, refer to this documentation anything about connecting to the VPS and
registering services in Binchicken.
5.7.1 Running services with Docker / Deployment of Website
The development and production services are handled with Docker. The services that will run in production is defined in the
docker-compose-prod.yml . Make sure that you have .env file in the same directory as the repository before proceeding.
Whenever changes are made, you can connect to the VPS instance, and go to the place where this repository can be found. Run git
pull to fetch the newest change, and then Either run the redeploy.sh or type
to be able to redeploy. This might take a few minutes before you see any changes.
The client-side and server-side applications are hosted in the VPS. You may need a Mongo Database. This is currently hosted in Atlas
Mongo (ask Frinze for details. He will be happy to help.). The details of the connection to the database should be in the .env file.
5.7.2 Deployment of Documentation
This is deployed in Github Pages. See CI Pipeline documentation.
5.7.3 Domain Name
The domain name is essentially just a holder for a specific URL name. Using your DNS provider such as NameCheap or
Cloudflare (when you connect the domain name with the UWA proxy). Direct the traffic in the domain name ( cf02.next-
dc.uwa.edu.au if using Cloudflare).
The setup with the VPS, NGINX/Binchicken and Domain Name is done only once on setup. Any future deployment, you just need to
use the documentation in the previous section.
Redeployment
1 docker-compose -f docker-compose-prod.yml
Services in Production
Additional Information
5.7 Deployment
- 28/28 - Copyright System Health Lab 2021