| Table of Contents | ||||
|---|---|---|---|---|
|
Introduction
Build out a high-level description of each service to complement the Application Architecture diagram
...
Revalidation is made up of an Angular 1.x UI app and a springboot application presenting a RESTful API to support the Revalidation UI. The Revalidation service uses Elastic Search indexes to hold a daily refreshed cache of trainee data and a MySQL database for the data that is persisted. The Elastic Search data is refreshed each evening by a combination of GMC Sync 615448587 and the Revalidation ETL 615448587
Where
The Revalidation Angular 1.x UI App and the Sprintboot microservice can both be found in the same repository: https://github.com/Health-Education-England/TIS-REVALIDATION
...
Concerns is made up of an Angular 1.x UI app and a springboot application presenting a RESTful API to support the Concerns UI. The Concerns service uses Elastic Search indexes to hold a daily refreshed cache of trainee data and a MySQL database for the data that is persisted. The Elastic Search data is refreshed each evening by GMC Sync 615448587 and the Revalidation ETL 615448587. - see question below. Each added/amended concern once saved to the MySQL db by the service is also refreshed into the ES Index.
...
Connection Discrepancies (Service and UI (within Admin UI))
Summary
As outlined in Revalidation 615448587 - The GMC treats HEE as 13 discrete entities or Designated Bodies and requires every trainee with a GMC licence to be assigned to one of these bodies. Whilst the trainees themselves are expected to self-manage their relationship with the GMC and inform them when they move locations to a new designated body, in practice HEE also needs to update the GMC's records - this is the Connection Discrepancies function.
Connection Discrepancies is a springboot application presenting a RESTful API to support the user interface which is found within the Admin UI
Where
The Connection Discrepancies Springboot microservice can both be found in the repository: https://github.com/Health-Education-England/TIS-CONNECTION-DISCREPANCIES. The UI is part of the Admin UI at: https://github.com/Health-Education-England/TIS-ADMINS-UI
...
- Provides a top menu (L1 menu) with access to People, Posts, Programmes, Concerns, Assessments and Admin sections (based on the users Role)
- Within each L1 menu dropdown, L2 items provide links to pages within each L1 section.
- Typically these consist of a 'Search' (effectively a filterable, searchable List page of records of the object in question, e.g. People) and a CRUD (Create, Read, Update, Delete) - effectively a form allowing the CRUD of an individual record of an object - e.g. a Person record.
- The List and CRUD pages will typically invoke the TCS or Assessment microservices to read, create and update data and use the Reference microservice to populate individual fields within the pages that display / search reference data
- For the more complex People and Assessment objects, a Level 3 (L3) navigation is provided - e.g. tabs within an individual Person record provide access to different data or objects directly related to that Person record (e.g. their contact details, or a list of their Programme Memberships, Placements or Assessments.) Where a list is provided within a tab, the records (e.g. Placements) are editable via an inline expanding form rather than a navigation to a full page.
- The Admin UI implements view/edit constraints for 5 Roles initially, the base HEE Admin, extensions to provide access to both Sensitive Data and Revalidation/Concerns, a full TIS Admin with access to reference data, and a Trust Admin with data access constrained to Trainees and Posts related to their Trust. Full details can be found on the Admin User Management (roles and permissions) page.
- The Admin UI was initially built using a JHipster autogeneration model and has been incrementally improved. Some elements such as the Admin sections List and CRUD pages are early versions and lacking functionality, whereas the more widely used objects such as Person/Post/Programmes have a richer interface. A full rewrite of the List functionality is currently in development initially for People which removes the last remnants of the JHipster 'scaffold'.
- The Admin UI also provides the user interface to the Document Management feature within TCS, allowing documents to be stored against a Person record with limited editable metadata.
- The Admin UI also provides the user interface to the Generic Upload microservice, more details can be found Generic Upload section
- For a user to access the Admin UI, they must authenticate via Keycloak and the Admin UI establishes their Roles and Permissions via the Profile service
...
TCS is a springboot application presenting a RESTful API to support the user interface which is found within the Admin UI
Where
The TCS microservice can be found in the repository: https://github.com/Health-Education-England/TIS-TCS.
...
Assessments is a springboot application presenting a RESTful API to support the user interface which is found within the Admin UI
Where
The Assessments microservice can be found in the repository: https://github.com/Health-Education-England/TIS-ASSESSMENTS
...
Generic Upload is a springboot application presenting a RESTful API to support the user interface which is found within the Admin UI.
Where
The Generic Upload springboot microservice can both be found in the repository: https://github.com/Health-Education-England/TIS-GENERIC-UPLOAD. The UI is part of the Admin UI at: https://github.com/Health-Education-England/TIS-ADMINS-UI
...
- The overall data flow and systems integration can be seen here: ESR-TIS Inbound and Outbound flows (MVP)
- A simplified flow and schedule details are shown below:
Where and When
The applications have their own github repositores.
- ESR Service: https://github.com/Health-Education-England/TIS-ESR
- ESR ETL: https://github.com/Health-Education-England/TIS-ESR-ETL
The ESR-ETL application is run from a Jenkins cron:
- The application cron job: https://build.tis.nhs.uk/jenkins/job/tis-esr-etl-cron/
- The details of the schedules for the cron job can be found here: ESR Schedules
- There is a FTP sync process which takes care of syncing files between Azure(TIS owned) and FTP server (ESR owned).
- This process is scheduled as a Jenkins job and runs multiple times a day and can be found here: https://build.tis.nhs.uk/jenkins/job/tis-esr-ftpsync-cron-prod/
- The schedule details are available under: ESR Schedules
What it does
- ESR-ETL receives and sends different files from and to ESR. The details of files and data sets are outlined here: ESR - Datasets
- It receives RMT files in changed (RMC) or full (RMF) mode. It processes and stores POR and POS records from the files.
- The POR and POS records are persisted in ESR database (mySQL) using ESR service.
- Each of the above files are received per deanery/local office and all the files produced are as well per deanery.
- For each of the deanery posts ESR requests corresponding APP file containing applicant records in placement for the post is generated. The following restriction applies for the selection:
- Only the future applicant placements are selected.
- The selected future placements should have a start date between 2 days from that day to 3 months.
- It uses TCS service to fetch the post, placement and trainee details.
- The applicant records are stored in ESR database using ESR service.
- A notification file (DNF - full notifications and DNC - changed notifications) is sent per deanery on a daily basis.
- The notification records tracks all the events happening in TIS and creates different notification types outlined in the ESR spec. This is a way of updating ESR about the changes happening in TIS.
- The TIS notification events are tracked and stored in TCS database in the EsrNotification table using the TCS service. This records only the TIS contents.
- All of the final notification records generated are stored in ESR database using the ESR service.
- An acknowledgement is generated for each RMT file processed and similarly an acknowledgement file (APC) is received from ESR for each APP file sent.
- These APC records are stored in the ESR database using the ESR service.
- The ESR service and ESR-ETL use profile/keycloak for user authentication and have an ESR specific user configured for the same.
SYNC (Service)
Summary
- TIS-SYNC is a container for background and long-running 'batch' jobs that synchronise data and update cached values.
- It currently .
- ESR ETL: A spring-boot application which runs on a daily basis multiple times with different load types.
- ESR service: A spring-boot application running as a service and is used to persist and retrieve ESR data.
- The overall data flow and systems integration can be seen here: ESR-TIS Inbound and Outbound flows (MVP)
- A simplified flow and schedule details are shown below:
Where and When
The applications have their own github repositores.
...
- The application cron job: https://build.tis.nhs.uk/jenkins/job/tis-esr-etl-cron/
- The details of the schedules for the cron job can be found here: ESR Schedules
- There is a FTP sync process which takes care of syncing files between Azure(TIS owned) and FTP server (ESR owned).
- This process is scheduled as a Jenkins job and runs multiple times a day and can be found here: https://build.tis.nhs.uk/jenkins/job/tis-esr-ftpsync-cron-prod/
- The schedule details are available under: ESR Schedules
What it does
- ESR-ETL receives and sends different files from and to ESR. The details of files and data sets are outlined here: ESR - Datasets
- It receives RMT files in changed (RMC) or full (RMF) mode. It processes and stores POR and POS records from the files.
- The POR and POS records are persisted in ESR database (mySQL) using ESR service.
- Each of the above files are received per deanery/local office and all the files produced are as well per deanery.
- For each of the deanery posts ESR requests corresponding APP file containing applicant records in placement for the post is generated. The following restriction applies for the selection:
- Only the future applicant placements are selected.
- The selected future placements should have a start date between 2 days from that day to 3 months.
- It uses TCS service to fetch the post, placement and trainee details.
- The applicant records are stored in ESR database using ESR service.
- A notification file (DNF - full notifications and DNC - changed notifications) is sent per deanery on a daily basis.
- The notification records tracks all the events happening in TIS and creates different notification types outlined in the ESR spec. This is a way of updating ESR about the changes happening in TIS.
- The TIS notification events are tracked and stored in TCS database in the EsrNotification table using the TCS service. This records only the TIS contents.
- All of the final notification records generated are stored in ESR database using the ESR service.
- An acknowledgement is generated for each RMT file processed and similarly an acknowledgement file (APC) is received from ESR for each APP file sent.
- These APC records are stored in the ESR database using the ESR service.
- The ESR service and ESR-ETL use profile/keycloak for user authentication and have an ESR specific user configured for the same.
...