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




2. User

2.1 Overview

2. User



3.1 Overview



4. Administrator

4.1 Overview

4. Administrator


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


https://reactjs.org/

https://nextjs.org/

https://material-ui.com/

https://www.creative-tim.com/learning-lab/nextjs/overview/material-dashboard

https://demos.creative-tim.com/nextjs-material-kit-pro/documentation/tutorial?_ga=2.127736269.1196819371.1625200365-198175297.1611663559

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


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


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


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.


FRU1 User login The user can login using pheme

FRU2 Equipment search

FRU3 Contact the maintainer about equipment

FRU4 Request equipment location update


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


https://github.com/uwasystemhealth/ASER/issues

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).


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


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


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


https://www.myob.com/au

https://www.mazemap.com/solutions/asset-tracking

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


https://www.web.uwa.edu.au/contact/map

https://api.mazemap.com/api/buildings/?campusid=309&srid=4326

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


https://docs.mongodb.com/manual/reference/bson-types/#objectid

https://marketplace.visualstudio.com/items?itemName=dbaeumer.vscode-eslint


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).

•

•

•

•

•

•

•



https://docs.feathersjs.com/api/authentication/

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)


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


https://redux-saga.js.org/

https://iamhosseindhv.com/notistack

https://github.com/feathersjs-ecosystem/feathers-redux#documentation-reduxifyservices

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


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


https://www.figma.com/file/Svwrs4svQrYYjQsj2YGAu4/ASER?node-id=1-3A6577


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):



https://feathersjs.com/

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


https://github.com/feathersjs/cli

https://www.mongodb.com/

https://mongoosejs.com/docs/index.html

https://github.com/feathersjs-ecosystem/feathers-mongoose

https://mongoosejs.com/docs/populate.html

https://github.com/feathersjs-ecosystem/feathers-mongoose#populate

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


https://www.codecademy.com/articles/bapi-testing-intro

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

email

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


https://auth.systemhealthlab.com/docs/

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.



Diagram




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.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


https://docs.systemhealthlab.com/

https://frinzelapuz.vercel.app

https://pages.github.com/

Documents

Asset Equipment Registry (ASER)