When building a house, the walls and the roof seem to be the most important, but the real challenge lies in what we can't see: the foundations. Without a strong and properly constructed foundation, a house will stand, but it will be much more difficult to withstand external factors and changes in the future. The same is true in software development. It is important that applications are flexible, scalable and built on a solid technological foundation that will stand the test of time. Our team's focus in redesigning backoffice applications for the lottery is not just to solve problems, but to provide the best long-term solutions.

BackofficeX is the new technological basis for the management of a lottery system

We are currently working on a redesign of the backoffice system, called BackofficeX, which is built with the classic Quarkus-Angular stack. The choice of this technology was not accidental. Our priority was to find solutions that offer speed, performance and ease of maintenance, and Quarkus provides us with many advantages, particularly in terms of optimising application start-up times and efficient resource management. Angular, on the other hand, takes care of the development of modern, user-friendly interfaces.

BackofficeX will support several games such as Eurojackpot, Loto, VikkingLoto, keno and others. One of the major technical requirements we face is the heritage of the base schemes from the previous system. These schemes involve complex structures where each game uses its own tables, which are almost identical to each other, with the difference in the table names. For example, keno uses the table KENO_DRAW, which is almost identical to the table LOTO_DRAW. Except in the name, of course.

Abstract classes and simplification for better flexibility

In order for the system to process these data structures efficiently, we use abstract classes in our code. This means that common properties of tables, such as draw tables, are described in abstract classes, while concrete names take care of specific details, such as the name of each table. In this way, we can ensure that the system works with minimal code duplication, reducing complexity and facilitating maintenance. This approach has a number of advantages. In addition to simplifying development, it also allows for greater flexibility when adding new games or functionality, as existing components can easily be adapted to new requirements without having to be developed anew.

Technical challenges of inheritance and adaptation

When working with such complex systems as BackofficeX, developers are often faced with various technical challenges. One of the first ones we faced was related to the legacy modules. Initially, we detected compatibility issues with the existing entity modules, and after consulting with the team, we decided to rewrite the module and bring it in line with the latest Jakarta standards for better compatibility with modern technologies.

When we were troubleshooting the set-up of the project, we also encountered problems in the hibernate library, in particular when using the fetch graph functionality. The fetch graph allows hibernate to determine which entities to include in a query, thus reducing the number of database queries required. However, the functionality did not work properly when applied to an entity that was described as a parameterised property in an abstract class. Although this problem was not directly related to Quarkus, we had to open a bug report on Hibernate to fix it.

Solving problems through collaboration

Our team works together at all levels of development to solve technical challenges. When the developer pointed out problems with the development of the first CRUD functionalities of the application (tables and forms), we started looking for solutions to move the project forward. This is a prime example of the importance of collaboration within a team, as each member contributed his or her expertise to solving the problem.

We found that the problem was not only in Quarkus but also in the hibernate library, where lazy loading (an additional query to retrieve the associated entity) did not work properly when the entity was specified as a parameterised property in an abstract class. We have opened the corresponding bug reports on Quarkus and Hibernate, and have been able to fix all the problems.

Learning from the technical challenges

To be honest, technical challenges are inevitable in software development, which makes how we approach them all the more important. Although it may sound like a cliché, every problem is an opportunity to learn and improve. Our team understands that it's not enough to solve a single problem, it's important to understand why it happened in the first place and how we can prevent similar problems in the future.

That's why we continually reintroduce solutions based on the most up-to-date technologies and approaches. Our decision to use Quarkus and Angular is the result of analysis and past experience, which has shown us that we need to think long-term in our development. This reduces the risk of costly redesigns or maintenance work in the future, providing our partners and customers with greater stability and security.

A look into the future

Redesigning applications is always just the first step. Already at this stage, we are planning further improvements to the system and extensions to the functionality that will make it easier to adapt to new market and legislative needs. In addition, we will upgrade the system to make it even more powerful and easy to use, both for the people working with the system and for the end users.

Our main aim is to create a robust, flexible system that can cope with the growing demands of lottery gaming while maintaining the stability and security that are key to user confidence.