Research Grant Expenditure Application (RGEA)¶
[Team : Johnson Team] [Tech Lead : sw2187] [Service Owner : weer2] [Service Manager : weer2] [Product Manager : TBC]
This page gives an overview of the RGEA, describing its current status, where and how it's developed and deployed, and who is responsible for maintaining it.
Service Description¶
The RGEA application is a Grails web application that provides PIs (Principal Investigators) with an online "bank account" view of their grants. It shows, using CUFS data:
- How much money has been spent
- What it was spent on
- How much is left
- How much would be left if the spending profile was modified via future commitments
Service Status¶
The RGEA is currently live.
It is expected that the functionality provided by RGEA will be migrated as part of the Transforming Research Programme.
Contact¶
Technical queries and support should be directed to uis-devops-division@lists.cam.ac.uk and will be picked up by a member of the team working on the service. To ensure that you receive a response, always direct requests to uis-devops-division@lists.cam.ac.uk rather than reaching out to team members directly.
Issues discovered in the service or new feature requests should be opened as GitLab issues in the application repository.
Environments¶
The RGEA is currently deployed to the following environments:
Name | URL | Supporting VMs |
---|---|---|
Production | http://www.expenditure.admin.cam.ac.uk | rgea-live1.srv.uis.private.cam.ac.uk |
Staging | https://rgea-test.srv.uis.cam.ac.uk | rgea-test1.srv.uis.private.cam.ac.uk |
Unlike most systems, RGEA working on a single node and is not load balanced. Downtime should be planned around vulnerable periods and users should be informed.
Source code¶
The source code for the RGEA is spread over the following repositories:
Repository | Description |
---|---|
Application Server | The source code for the main application server |
GREB | ETL Batch processor |
Ansible Infrastructure Deployment | The Ansible infrastructure code for deploying the application server to on-prem hosts |
Cloud Infrastructure Deployment | The Terraform infrastructure code for deploying the application server to GCP (not currently in use) |
Technologies used¶
The following gives an overview of the technologies the RGEA is built on.
Category | Language/Technology | Framework(s) |
---|---|---|
Server | Java 8 | Grails, Spring, Spring Batch |
Database | MySQL | |
ETL (Greb) | Java 8 | Groovy |
We have some detailed documentation of the endpoints provided by the RGEA Grails application.
Data model¶
Operational documentation¶
The following gives an overview of how RGEA is deployed and maintained.
NOTE: There is some historic documentation in Confluence. This is mostly out-of-date but could provide some background information for troubleshooting.
How and where the RGEA is deployed¶
RGEA is deployed on a single node per environment.
The local MySQL database is used for all application data storage. The GREB process populates the database with up-to-date information from CUFS (via an intermediate datamart) every weekday morning (GREB polls the datamart until it detects that it has been rebuilt that morning, and then updates the local MySQL database).
If data corruption does occur, then GREB can be manually re-run with the following command (you should first ensure that a previous GREB process is not still running):
/scripts/greb/bin/greb --force >> /var/log/greb/greb.log
Deploying a new release¶
After tagging, new releases are deployed via
Ansible. The
run-ansible-playbook.sh
should be run to deploy new version. e.g.
# On client machine
eval $(op signin)
source ./rgea-live-setup
./run-ansible-playbook.sh -i rgea-live rgea-playbook.yml --diff
Disabling access¶
The GREB process has historically been fragile, often resulting in corrupted data in the MySQL database. While these issues are believed to be resolved, there may still be scenarios where blocking access with a maintenance page is necessary. To do this, contact the Traffic Manager team.
When the maintenance page is active, you can test the service by visiting this URL. This will set a cookie to proxy requests to the backend service instead of displaying the maintenance page.
Monitoring¶
RGEA is monitored by nagios. This checks that the status of the home page returns a 200 result.
Debugging¶
Further debugging instructions can be found on the RGEA Wiki.
Service Management¶
The Team responsible for this service is Johnson Team.
The Tech Lead for this service is sw2187.
The Service Owner for this service is weer2.
The Service Manager for this service is weer2.
The Product Manager for this service is TBC.
The following engineers have operational experience with this service and are able to respond to support requests or incidents: