The ITR is designed from the ground up as a secure multi-tenant system for high system loads in international environments.
This has lead to the following choices :
- every customer has their own database. This will increase performance and most importantly security
- central information is placed and maintained in the master database which is a central database. Some information like tests, reports et cetera can be place in this central database so that all tenants/customers can potentially make use of it
- processing is taken away from the central server as much as possible. The central server is responsible for : serving the website, storing and retrieving data, providing central server functions which cannot be executed from the browser (like sending mails). The central server is also responsible for serving ONLY the proper data to the webbrowser. This means for example that a test taking user can NOT access all information in the system. And as another example an office user can read and use test definitions but ONLY a test author can update the test defitions
- The API is split into TWO APIs. The internal API which is for usage only by the ITR webbrowsers and the external API which can be used by basically any calling system. If you do not want external API functionality then simply do not install it.
- All API calls are made to do whatever they need to do, but they are designed for short run times and high concurrency. This means that a webbrowser potentailly will have to make many calls to complete a function, but this does NOT block all the other web browsers
- Auto translation of the interface into the desired language using Microsoft Azure translation is supported
The website, internal API and external API can be placed on the same server or computer in its most simple form. They can also be installed and used in for example docker containers, in a docker swarm or kubernetes cluster, or in a load balanced server cluster. The conditions are the following.
- THe instance folder needs to be shared between all API containers (both internal and external)
- The database needs to be accessible for all API containers
- The internal API container needs to be on the same domain name for CORS checks by the browser.
- The API servers need internet access for retrieving updates and translations
database server considerations
The database back end is postgres. You can setup a read only postgres copy on each API server if required for scaling out. Please note that test run users mostly write to the database while taking tests. Office users tend to have a higher read behaviour.
Usage of postgres connections is limited to 1 or 2 connections per API instance, or at least as much as possible (in some cases more connections are needed), which means that a single database server can serve many API instances. If running out of connections then increase them. For sizing the database server please consult that postgres manuals. Postgres 10+ is supported.
To facilitate for slow connections the ITR site is a single page application where all code is fully loaded while the user is logging on. There is a multi stage load approach for the login screen with the option to load only the code required for test taking. All code is placed on the central server as much as possible. Fonts from google are for example loaded from the google site itself. This means that your browser needs internet connection for properly using the ITR (next to the connection to the central server), some functionality will be lost of no internet connection is available which may or may not be acceptable in your situation.
The ITR has some requirements on the browser. Sufficient HTML5 support is assumed, which means that Internet Explorer is not supported, nor are older versions of browsers supported. Examples of supported browser are recent versions of Opera, Edge, FireFox or Chrome.
The ITR is designed to support phone and tablet use, next to laptop and big screen use. This is a challenge for functionalities that require a lot of overview and screen space to work properly. This means that some screens and overviews in the office functionality work less well on small screens, like a phone.