Architecture
The above diagram represents how our application interacts with all possible agents.
Here is a small summary of it:
The forest client will expose a front-end application that our users can use. We currently have two types of users, internal user and external user.
All users will access the application through an exposed route from the OpenShift platform, that routes it to our frontend application. Both kinds of users will require authentication; for that, we use FAM to manage authentication through various methods. Once authenticated the user will be routed to its own screen where it can interact with the application.
The frontend application is built using Vue 3 with Typescript and managed using Vite. The application is tested using vue test utils, vitest and cypress.
To interact with the data, the frontend application communicates through a set of REST APIs with the backend service. This backend application is built using Java 17 and Spring Boot 3 and is deployed as a native image made using GraalVM.
The frontend-facing backend has access to the new Postgres database, and in order to be able to access legacy data, it will communicate through some REST APIs with another backend service that has access to the legacy Oracle database.
The backend application also consumes data from other external APIs, such as BC Registry for Company-related information, Canada Post for address resolution, FAM for authentication and CHES (Common Hosted Email Service) for email exchange.
Once a submission is created and saved on Postgres, another process will kick in to validate some of the data against the legacy database and will move the submission to its next phase. Once done, it will ping back the backend application to notify users of the changes made to the submission
This service is responsible for automatically processing submissions by checking data against the legacy database and making sure the new submission is not duplicated. It is also responsible for post-processing approvals and rejections, persisting data into the legacy database and sending emails (the email triggering happens on the backend service).
To have better flow control and reduce the coupling between parts, we used spring integration to create a queue-like structure and dispatch events that will be consumed by listeners, allowing us to focus on the code itself without worrying about tight coupling between classes.
The communication happens through a set of channels that emulate the queue behaviour and are described below by numbers. Keep in mind that even though each flow has a unique number, the actual channel can be shared by multiple processes, such as #5, #9 and #8 that point to the email triggering process and are described individually but are the same channel.
When a submission is created, it will have a status code of Submission Pending Processing, and it will be picked up by the processor for inspection. It will be sent on channel #1 where it will be loaded to extract the details of the submission for processing. After loading, it will then be dispatched through channel #2, where the processor will take hold of it and do the validations and verifications required for automatic approvals. In case of any pending scenarios, the submission will be marked for manual review and sent through channel #3 and if no pending review is required, it will go through channel #4 for auto-approval, and, once there, it will end up on the same flow as post review submissions described below through channel #7. For submissions marked for review, it will then move through channel #5 for email triggering for admin users.
After a submission is reviewed, it will be picked up by this process and loaded for post-processing. It will be sent through channel #6 for match loading, where it will be evaluated and sent to the correct channel. For approved submissions, it will move to channel #10 where it will be persisted into the legacy database and after it will be dispatched through channel #9 to trigger an email for the end user. For rejected submissions, its destination is also the email triggering process through channel #8.
TBD
TBD