Project Overview
The project entailed building an independent solution consisting of an admin portal and payment-processing omnichannel to enable bank tellers to manage the transactions of third-party vendors. The application featured an intuitive, role-based system capable of handling large transaction volumes while giving users the ability to pay via multiple methods.
Development Approach
Building an application for the bank requires implementing highly secure development practices. This informed the methodology and technology requirements for the project. Java was chosen as the programming language and a team of four was formed including a lead backend developer, 2 frontend developers and a project manager adopting an agile scrum approach.
Technology Stack:
Programming language: JAVA/Kotlin
Build system: Gradle
Development Server: Apache Tomcat Server
Testing: Postman, Swagger
Version Control: Git via Microsoft Azure Cloud
Deployment and Hosting: AWS (Test), Production (Apache Tomcat)
Insights
User-Centric Design Focus:
Implementing role-based access control (RBAC) is a crucial first step towards securing system assets and company resources. By granting or denying access based on defined roles and responsibilities, RBAC ensures that only authorized individuals have access to sensitive information and resources which also works great for system audits and compliance. I was able to achieve this by implementing a JWT authentication scheme as well as using the @rolesallowed annotation in JAVA, which helped to specify which classes or APIs each user group was allowed to access.
Problem-Solving Showcase:
The first problem I faced was trying to convert mission-critical, legacy SOAP APIs to modern HTTP REST standards. I performed detailed research leading me to discover and implement the maven JAXB plugin, which enabled me to conveniently "marshal" (write) and "unmarshal" (read) Java Objects into XML data and vice versa. The plugin essentially utilizes the Java API for XML Binding to generate Java classes from XML Schemas (and optionally binding files) or to create XML schema from an annotated Java class which made it simpler to consume and expose the necessary APIs via the REST standard which uses the much simpler JSON format as a means of communication.
I also created an Authorization queue which enabled tellers to approve or deny any transaction
The next challenge involved creating a module that would send automated bank statement reports to a particular email address at a specific time of day every week for reconciliation. To solve this problem, I implemented a Cron job. Using this approach also helped me take advantage of Java's multi-threaded nature. It ensured that the service would start on a separate thread without interrupting the application which was executing on the main thread, the service would then go on to query the necessary APIs to fetch the statements, compile/convert them into a .csv file, and send to the specified email address. All configurations (e.g. changing the client's email, specifying the frequency at which statements were generated, etc.) could be achieved by editing the .properties file which ensured a high level of flexibility.
Performance Metrics and Optimization:
Performance benchmarks were provided via the use of Spring Actuator, a tool that gave us access to endpoints allowing us to check the health, speed, and observability metrics of the application.
Testing and Quality Assurance:
As always, following a Test-Driven Development (TDD) strategy proved invaluable, especially since the project involved integrating over 300 APIs from numerous vendors across the payments landscape including Interswitch, Remita, and other financial service providers to pay bills, generate digital invoices and receipts, virtual NUBANs etc. I wrote unit tests for each module to ensure correctness, reducing the need to employ dedicated testers at the initial phase of development thereby saving cost. Documentation was also provided locally via Swagger. To test each API, one would simply be required to launch the app, navigate to the provided Swagger documentation URL, and test the endpoint after authenticating.
Project Achievements and Outcomes:
The project was concluded to resounding success and plans are currently underway for a conversion which will see improvements in areas such as usability and maintainability. GMB bank tellers were grateful to finally have a portal through which they could view all user actions and transactions made on the system. The source code has been moved to a private GitHub repository here for future reference.
Lessons Learned and Future Considerations:
In retrospect, I'd suggest placing as much emphasis on product planning/design in order to create a clearer picture and ease/speed up development efforts. Other than that, it was a great learning experience and I enjoyed getting the chance to build a product that helped make other people's jobs easier.
