Een multi-tenantapplicatie bouwen in Mendix betekent dat je één applicatie ontwikkelt die meerdere klanten of organisaties bedient, waarbij elke tenant zijn eigen afgeschermde omgeving heeft. Dit vraagt om doordachte keuzes op het gebied van datamodellering, beveiliging en architectuur. In dit artikel beantwoorden we de meest gestelde vragen over multi-tenancy in Mendix, van de basisconcepten tot de technische uitvoering.
Wat is een multi-tenantapplicatie en wanneer heb je er één nodig?
Een multi-tenantapplicatie is een systeem waarbij meerdere gebruikersgroepen, zogenaamde tenants, gebruikmaken van dezelfde applicatie-instantie, maar elkaars data niet kunnen zien of benaderen. Dit verschilt van een single-tenantopzet, waarbij elke klant een volledig eigen omgeving krijgt.
Bij een single-tenantarchitectuur draait voor elke klant een aparte applicatie. Dat geeft maximale isolatie, maar brengt hogere beheerkosten en meer infrastructuur met zich mee. Multi-tenancy is efficiënter: je beheert één applicatie, maar bedient meerdere klanten tegelijk.
Multi-tenancy is zinvol in situaties zoals:
- SaaS-producten waarbij je hetzelfde platform aan meerdere klantorganisaties aanbiedt
- Klantportalen waar externe partijen toegang krijgen tot hun eigen gegevens
- Interne platforms voor grote organisaties met gescheiden afdelingen of businessunits
Hoe werkt multi-tenancy technisch in Mendix?
In Mendix realiseer je multi-tenancy door een tenantentiteit centraal in je datamodel te plaatsen en alle relevante data daaraan te koppelen. Mendix biedt geen ingebouwde multi-tenancy out-of-the-box, maar het beveiligingsmodel biedt voldoende bouwstenen om dit zelf goed in te richten.
De kern van de technische aanpak bestaat uit drie elementen:
- Tenantentiteit: een object dat een klantorganisatie vertegenwoordigt, waaraan gebruikers en data worden gekoppeld
- XPath-constraints: beveiligingsregels op entiteitniveau die bepalen welke objecten een gebruiker mag ophalen, gebaseerd op de tenant waartoe hij behoort
- Modulerollen: via Mendix’ rolgebaseerde toegangscontrole stel je in welke acties een gebruiker binnen zijn tenant mag uitvoeren
Door XPath-constraints te koppelen aan de ingelogde gebruiker en diens tenantassociatie, zorg je ervoor dat elke gebruiker automatisch alleen zijn eigen data ziet. Dit is een krachtig en flexibel mechanisme dat diep in het Mendix-beveiligingsmodel is verankerd.
Welke architectuurkeuzes moet je maken bij een multi-tenant Mendix-applicatie?
De belangrijkste architectuurkeuze is of je werkt met een gedeelde database of aparte databases per tenant. In Mendix is een gedeelde database de standaardaanpak, waarbij tenantisolatie via de applicatielaag wordt afgedwongen. Aparte databases per tenant zijn technisch mogelijk, maar vereisen aanvullende infrastructuur buiten Mendix.
Andere afwegingen die je vroeg in het project moet maken:
- Configuratie per tenant: bepaal hoe tenants hun eigen instellingen, thema of workflows kunnen hebben zonder dat dit de codebase fragmenteert
- Scheiding van UI en bedrijfslogica: houd tenant-specifieke weergave gescheiden van de onderliggende proceslogica, zodat wijzigingen voor één tenant geen impact hebben op andere tenants
- Schaalbaarheid: denk na over hoe de applicatie zich gedraagt als het aantal tenants en gebruikers groeit, en richt je datamodel en microflows daar al vroeg op in
Een goed doordacht datamodel aan het begin van het project voorkomt veel technische schuld later. Kies bewust voor generieke oplossingen die voor alle tenants werken, in plaats van tenant-specifieke uitzonderingen in de code te bouwen.
Hoe zorg je voor veilige data-isolatie tussen tenants in Mendix?
Veilige data-isolatie in Mendix draait om het consequent koppelen van elk data-object aan een tenantentiteit en het afdwingen van toegang via XPath-beveiligingsregels. Zo zorg je ervoor dat gebruikers structureel alleen data van hun eigen tenant kunnen ophalen, ongeacht hoe de applicatie wordt gebruikt.
Praktische stappen voor goede isolatie:
- Koppel elke relevante entiteit via een associatie aan de tenantentiteit
- Definieer XPath-constraints op entiteitniveau, zodat Mendix automatisch filtert op de huidige gebruiker en diens tenant
- Vermijd het ophalen van data via onbeveiligde microflows of Java-acties zonder expliciete tenantcheck
- Test isolatie actief door als gebruiker van tenant A in te loggen en te controleren of data van tenant B volledig onzichtbaar is
Datalekkage ontstaat vaak niet door fouten in de beveiligingsinstellingen, maar door microflows die objecten ophalen zonder XPath-filtering. Controleer daarom ook de logica in je microflows en zorg dat retrieves altijd via beveiligde paden verlopen.
Hoe helpt Freelie bij het bouwen van een multi-tenantapplicatie in Mendix?
Wij helpen organisaties bij het ontwerpen en bouwen van multi-tenant Mendix-applicaties, van de eerste architectuurkeuzes tot de uiteindelijke oplevering. Onze aanpak is praktisch, iteratief en gericht op een oplossing die écht werkt voor jouw situatie.
- We brengen samen met jou de vereisten en tenantstructuur in kaart voordat we beginnen met bouwen
- We ontwerpen een datamodel en beveiligingsarchitectuur die schaalbaar en onderhoudbaar is
- We bouwen iteratief, zodat je vroeg in het proces al werkende functionaliteit ziet en kunt bijsturen
- We zorgen voor aantoonbare data-isolatie via gestructureerde tests per tenantrol
- We dragen kennis over, zodat jouw team de applicatie zelfstandig kan beheren en uitbreiden
Wil je weten hoe een multi-tenantapplicatie er voor jouw organisatie uit zou zien? Neem contact met ons op en we denken graag vrijblijvend met je mee.