Case study
Multitenant ERP Platform Engineering
Plexteq partnered with Comcube GmbH to modernize and extend their innovative custom ERP - a modern system modeled like the desktop of an operating system, into a true multi-customer enterprise platform.
The engagement drew on deep, in-house engineering expertise across enterprise Java ecosystem proficiency, PostgreSQL internals, enterprise SSO with Shibboleth and Kerberos, and an offline-first warehouse synchronization system - so that multiple independent customers could run securely on one codebase.
Along the way, Plexteq unified the platform's application architecture into a shared framework that made building new desktop applications markedly faster and less repetitive.
Project Highlights
Industry
Enterprise Software /
Enterprise Resource Planning (ERP)
Market
EU (DACH)
Cooperation
2014 – 2019
Expertise
Application Modernization, Software Architecture, Enterprise Security & SSO, Database Engineering, Data Synchronization, DevOps & CI/CD, Release Management
Technologies
Java, Spring, Hibernate, Apache Tomcat, PostgreSQL, Sencha Ext JS, Shibboleth, Kerberos, Active Directory, SymmetricDS, SQLite, ActiveMQ, WebSockets
Business Challenge
Comcube GmbH had built something unusual: a modern ERP modeled like the desktop of an operating system. Users saw clickable icons and worked with each application in its own window - transport management, stock management, product management, and quality assurance for servicing devices and mechanisms among them. The effect was closer to Lotus Notes than to a conventional web ERP, delivered on a modern Java and PostgreSQL stack with a rich Sencha front end.
Each application was its own separate Java-plus-Sencha application, and a user might have several open at once. For the operating-system illusion to hold, single sign-on was not a feature but a prerequisite: users could not be asked to log in again for every window, so many independent applications had to render and authenticate seamlessly as one desktop.
That design was a differentiator, but it made the platform hard to scale. The central difficulty was data isolation across multiple dimensions at once - cleanly separating shared core data from customer-specific data, consistently, across many loosely coupled applications that each touched the database differently. Isolation had to hold uniformly across the whole system, not module by module.
Comcube also needed the platform to behave like enterprise software: hosting multiple fully independent customers on one deployment; authenticating through customers' existing corporate identity, with coherent sign-out and session handling across the ecosystem; auditing every data change in a tamper-resistant way; and continuing to work on the warehouse floor where networks are unreliable.
Comcube engaged Plexteq to deliver this end-to-end. Modernizing a complex, already-live custom ERP without disrupting its distinctive design demands engineers fluent both in application architecture and in the low-level internals where the hardest problems live - exactly the depth Plexteq maintains in house.
Key Challenges
#1. Multi-Dimensional Data Isolation
Shared core data and per-customer data were spread across many independent desktop applications. The platform needed true multitenancy that isolated each customer's data reliably and uniformly across every application - without re-architecting each module by hand.
#2. Transparent SSO and SLO Across a Multi-App Desktop
Every application in the web desktop was a separate Java-plus-Sencha app, yet users had to move between windows without ever re-authenticating - logging into each individual app window was not an option. The ecosystem also needed coordinated single log-out (SLO) and consistent session-timeout behavior across all applications, so that signing out or timing out in one place was handled coherently everywhere, with no orphaned authenticated windows. All of this had to build on standards-based federated identity wired to Kerberos and Active Directory at each customer's office.
#3. Trustworthy, Reversible, Transaction-Aware Auditing
Auditing and change-control logic that lives only in the business layer can be bypassed and is easy to get inconsistent across modules. Comcube needed audit capture and manual-change restrictions enforced at a level no application code path could circumvent. It also had to go beyond recording who created, updated, or deleted a row: changes made together in a single transaction had to be linked, so the full set of related edits could be understood as one connected whole - and that history had to be visible to users inside the product, with the ability to revert.
#4. Offline-Capable Warehouse Operations
Warehouse areas frequently had no reliable network coverage. Workers needed the most recent data on their mobile device before starting a shift and a dependable way to reconcile their changes back to the central system afterwards - bidirectional synchronization that tolerated being offline for hours.
Solution Delivered
Plexteq approached the platform not as a set of features to bolt on, but as an exercise in engineering at the level where each problem is genuinely solved - often below the application, inside PostgreSQL itself, in the JDBC layer, and in the identity protocols. The result is a set of components that each reflect deep, specialist expertise applied directly to the client's product.
↳ Schema-Based Multitenancy on PostgreSQL
Plexteq implemented multitenancy using PostgreSQL schemas as the isolation boundary. Shared core data lived in its own schema, while each customer received a dedicated schema for their data, giving every tenant strong, database-level separation rather than isolation enforced only by application filtering. Because the boundary sat in the database, the same isolation guarantees held uniformly across all of the independent applications, resolving the multi-dimensional isolation problem at its root instead of module by module.
↳ Federated SSO and SLO with Shibboleth SAML and Kerberos
Enterprise security was woven through the application rather than bolted on.
Plexteq built the identity layer on Shibboleth SAML - starting on Shibboleth v2 and later migrating the platform to v3, to provide standards-based federated authentication. Shibboleth was then configured with Kerberos so that web applications running in an end customer's office transparently authenticated users already logged into the domain through Active Directory.
The result was true zero-touch single sign-on: a domain user reached the ERP desktop without a separate login step, using the corporate identity infrastructure the customer already operated. Because each application in the web desktop was a separate Java-plus-Sencha app, SSO was also what made the operating-system illusion work: many independent applications rendered and authenticated seamlessly as windows within one session, and users never had to log in again when opening another.
Plexteq extended this to the full session lifecycle, implementing single log-out (SLO) with Shibboleth and coordinating session timeouts across the application ecosystem - so that logging out or timing out was applied consistently everywhere, with no orphaned, still-authenticated windows left behind. Delivering this - including the migration from Shibboleth v2 to v3 and the Kerberos-to-Active-Directory integration, required working fluently at the level of the SAML and Kerberos protocols themselves, an area of enterprise-security expertise Plexteq holds in house.
↳ Database-Enforced Auditing, Transaction Graphs, and In-UI Revert
To make auditing trustworthy, Plexteq implemented a transparent data auditing layer inside PostgreSQL using triggers. This layer captured every data change - creations, updates, and deletions, along with who performed them, into shadow tables, and controlled or, where required, disabled manual data modifications directly at the database. Deliberately moving these checks out of the business logic layer and down into the database meant they could not be bypassed by an individual application or an ad-hoc query path, giving Comcube a consistent, tamper-resistant record and a single enforcement point across the whole platform.
The audit layer went further than recording individual row changes. It linked the multiple entities modified within a single transaction, so that a set of related changes could be understood together as a connected, graph-like structure rather than as isolated edits scattered across tables - making it possible to see the full shape of what one business action actually did.
Plexteq engineers then integrated viewing this shadow-table history directly into the mainline UI, so users could inspect what had changed without leaving the product, and perform reverts to restore previous states - turning the audit trail from a passive log into an operational tool.
↳ Concurrent-Edit Awareness via LISTEN/NOTIFY
On top of the audit layer, Plexteq implemented a component that analyzed data modifications happening concurrently in the database using PostgreSQL's LISTEN/NOTIFY mechanism. When a record was updated, users who might be editing that same, now-outdated data were notified - allowing the UI to warn them before they acted on stale information. This turned a classic multi-user editing hazard into a smooth, real-time experience.
↳ Custom Schema-Aware Migration Framework
Managing schema evolution across a shared core schema plus many per-customer schemas exposed a gap in existing tooling: Flyway had no way to control the interdependencies between schemas that this design required. Rather than compromise the architecture to fit the tool, Plexteq built a custom database migration framework in the spirit of Flyway, but capable of expressing and enforcing cross-schema interdependencies - so that migrations across core and tenant schemas could be applied in a correct, coordinated order as the platform evolved. Building a bespoke schema-versioning engine is precisely the kind of deep, from-scratch database work most teams avoid; for Plexteq it was the right, durable solution.
↳ Per-Tenant Query Measurement with a Custom p6spy JDBC Driver
To give Comcube immediate insight into database performance across a shared, multitenant platform, Plexteq implemented a dynamic query measurement system based on a custom JDBC driver built on p6spy. Working at the driver level - rather than relying on coarse external monitoring, the driver sat transparently in the data path, measured query execution, and attributed it to the originating tenant, giving an at-a-glance overview of which customers were experiencing degrading performance. This turned database performance from something discovered after users complained into something observable in real time and diagnosable down to the specific tenant and query, and demonstrates the level at which Plexteq is comfortable operating: writing custom JDBC instrumentation to solve a problem cleanly at its source.
↳ Offline-First Warehouse Sync with SymmetricDS
For the Sencha-based mobile application used in warehouses, Plexteq delivered a data synchronization system built on SymmetricDS and its C/C++ implementation, with a local SQLite database on the device as the on-device store. On demand, a warehouse worker synced the most recent data down from the central PostgreSQL database into SQLite before heading onto the floor, worked through periods of unreliable or absent connectivity against that local copy, and synced their changes back once they returned. To meet Comcube's requirements, Plexteq modified the existing SymmetricDS implementation and added a path to synchronize this data to the mobile application over WebSockets through an ActiveMQ broker - integrating robust offline replication with the product's modern, message-driven front end.
Because the same records could change centrally while a device was working offline, the sync-back step needed to handle divergence gracefully. Plexteq built a semi-automatic conflict-resolution mechanism that detected conflicting entries on synchronization back and merged them where possible, escalating only the cases that genuinely required a human decision - so warehouse changes reconciled into PostgreSQL reliably rather than being lost or blindly overwritten.
↳ Unified Application Framework for Faster Development
One of the most significant benefits Plexteq introduced was not a single feature but a unifying effect across the whole platform. The multitenancy, the SSO and inter-application messaging integration, and the schema-migration work were consolidated into a consistent, shared foundation for building applications. New applications for the web desktop are now built the same way, integrate authentication and messaging between one another through common mechanisms, and run their database migrations through the same framework - instead of each application reinventing this plumbing on its own.
By unifying the application architecture and standardizing these routine, cross-cutting concerns, Plexteq removed large amounts of duplicated infrastructure boilerplate and sped up the routine work of adding a new application. The practical effect is that Comcube can extend the ERP with far less repetitive infrastructure code and far more focus on actual business functionality - turning what had been bespoke effort per application into a fast, repeatable path.
↳ Architecture, CI/CD, and Release Management
Beyond the individual components, Plexteq helped Comcube strengthen the engineering foundations the platform depended on. This included improving the overall application architecture as the product grew into a multitenant platform, and modernizing the delivery process - establishing more robust CI/CD and release-management practices so that changes spanning the core and per-customer schemas and the many desktop applications could be built, tested, and shipped reliably and repeatably. The effect was to make an increasingly complex platform safer and faster to evolve, with Plexteq acting as a long-term engineering partner rather than a one-off supplier.
Key Results
Multi-tenant
multiple independent customers isolated at the PostgreSQL schema level on one platform
Zero-touch SSO
seamless authentication across every desktop app via Shibboleth, Kerberos, and Active Directory
DB-enforced
auditing and change control moved into the database, closing business-logic bypass paths
Offline-first
reliable warehouse operation with bidirectional device sync over unreliable networks
Business Outcome
The engagement transformed Comcube's innovative but single-customer ERP product into a secure, auditable, multitenant platform — without sacrificing the distinctive operating-system-like Sencha Web Desktop experience that set it apart.
Capabilities delivered through the engagement::
-
Schema-based multitenancy on PostgreSQL, isolating shared core data from per-customer data uniformly across all applications
-
Federated enterprise SSO on Shibboleth SAML, with Kerberos and Active Directory for transparent domain authentication - plus single log-out and coordinated session timeouts across the application ecosystem
-
Transparent, tamper-resistant auditing enforced at the database via triggers
-
Real-time concurrent-modification alerts built on PostgreSQL LISTEN/NOTIFY to prevent stale-data edits
-
A custom, Flyway-inspired migration framework capable of controlling cross-schema interdependencies
-
Per-tenant query performance measurement via a custom JDBC driver, surfacing degrading customers in real time
-
An offline-first warehouse synchronization system using a modified SymmetricDS (C/C++) implementation, syncing on demand between central PostgreSQL and an on-device SQLite store, with a semi-automatic mechanism to detect and merge conflicting entries on sync-back
-
A unified application framework that standardizes how new desktop applications are built, how they integrate authentication and inter-application messaging, and how migrations run - cutting infrastructure boilerplate and duplication and accelerating new-application development
-
Improvements to the overall application architecture, CI/CD, and release-management practices, strengthening the engineering foundations of the platform as it grew
For businesses running or building complex custom ERP systems, this engagement illustrates two things Plexteq brings to the table.
First, the ability to modernize and extend an existing, live, architecturally unconventional ERP - adding multitenancy, enterprise security, auditability, and mobility without discarding what made the product distinctive.
Second, genuine depth in the hard, low-level technologies these systems depend on: PostgreSQL internals, custom JDBC driver development, bespoke database schema versioning, and enterprise SSO with Shibboleth and Kerberos.
Plexteq maintains this expertise in house and applies it directly to clients' products - solving problems at the layer where they are actually solved, rather than working around them. And beyond building features, Plexteq strengthened the engineering foundations around the product - its architecture, CI/CD, and release management, acting as a long-term engineering partner invested in the platform's continued growth.