POS software code audit for Palmers Textil
Project overview
Palmers Textil AG, the Austrian fashion & clothing brand, actively uses point of sale (POS) solutions. In 2017, the company had a legacy POS system called Pcash based on unoptimized language – Groovy. DICEUS analyzed the code, identified problems with the current solution, and proposed improvements.
Client information
Palmers Textil AG is an international clothing brand that originated in Austria. Ludwig Palmers started it as a laundry back in 1914. In 2000, the company opened its first online shop. Since 2015, Palmers is owned by P Tex Holding GmbH. Today, the brand sells underwear, clothes, and accessories in more than 300 stores in 17 countries.
Business challenge
Palmers Textil started building its digital infrastructure in 2000. The company integrated SAP, launched the website, added POS and payment providers. Nevertheless, by 2017, all these modules became outdated. Particularly, the legacy POS solution was slowing down the sales process, worsening customer experience. It was required to review the code and help the company to improve its sales.
Technical challenges
The existing POS system was built on Groovy. Overall, this code is hard to maintain or refactor. There are a few reasons, including the naming convention violation, much abbreviation, and code instability. By analyzing Pcash, we divided issues by their severity: major, middle, and minor.
Audit areas
Back end
The main issue with the system was the lack of the system requirements list. The POS app needed a lot of specific Groovy modules that couldn’t be accessed directly. Other issues included explicit app builders and missing guides. As for security, we found one bad practice: passwords were stored without hashing. In total, there were 8 issues with the main system and 6 problems with custom modules.
Suggested improvements:
- Add the logging module and transfer the related logic
- Hash passwords for better security of the system
- Structure the code according to Java packaging best practices
Front end
The front part of the system was implemented using Vaadin with UI components described in Groovy classes. The project had the main component for the main app page. Only one middle issue was identified because the solution featured too many small ungrouped files.
Suggested improvements:
- Group small components to optimize the structure
- Make another module for Vaadin classes to separate UI from logic
Database
The problem with databases was that the tables didn’t feature unique or foreign constraints. Thus, data was stored without consistency, there were issues with broken data. The overall setup was too complicated, as well. There were only 2 problems, but both of them were classified as major.
Suggested improvements:
- Add the required indexes for key queries
- Keep the SQL scripts in the main project repository
- Setup the constraints properly
Version control system
The version control was based on Mercurial. It featured only one issue – inefficient branching without observing. It was necessary to fix this thing to enable multi-development and make the version management more structured.
Suggested improvement:
- Distinguish branches, make the version control system structured
Infrastructure
Although the work inside the environment was established and integrated, there was no documentation related to infrastructure and Pcash services. The database system wasn’t ideal, and the disaster recovery procedures were absent at all. As well, performance and stability could be much better. We found 5 issues, including 3 major ones.
Suggested improvements:
- Add load, network, total process, system default, and PostgreSQL metrics
- Change legacy services and tools to more efficient solutions: Mercurial to Bitbucket; Redmine to Jira; FTP server to storageBucket; Zimbra to SendGrid; Postgre to AWS RDS
- Develop disaster recovery procedures for separate elements and the whole system
- Install a more flexible environment for better monitoring
- Migrate database servers to cloud, optimize them
- Prepare the detailed documentation, description of services, deployment
Audit results
In total, we found 24 issues divided by their urgency and severity. For each problem, we proposed the relevant solution, including development updates, infrastructure optimization, and tool migration. After implementation, these suggested changes could make the POS solution much more efficient, profitable, and reliable.
Let’s discuss how we can help with your project
Value to our client
Our tech stack
AWS
Bitbucket
Gradle
Groovy
Jira
Mercurial
PostgreSQL
Redmine
SAP
SendGrid
Vaadin
Zabbix
