Création de rapports pour une application Web multi-locataires

Question

Nous avons une application Web multi-locataires utilisant Hibernate sur MySQL. Nous utilisons les rapports Jasper pour tous les rapports dont nos clients ont besoin, mais nous devons maintenant proposer des rapports ad hoc afin que les utilisateurs puissent exécuter leurs propres requêtes.

Comment les autres ont-ils accompli cela?

Je pense que je peux soit:

1. Fournir une exportation complète en format Excel ou XML où je hydrate les entités de sorte que toute @ManyToOne est remplacé par le toString() de cette entité. Ce serait pour que les données aient un sens pour l'utilisateur plutôt que pour un grand nombre d'ID de clé étrangère. Laissez-les exécuter SQL contre une copie de la base de données. Assurez-vous que chaque table a un TENANT_ID, laissez-les accéder à la copie de la base de données mais ajoutez l'ID à à chaque requête en coulisse. Je pourrais même m'assurer que cette copie de base de données avait seulement leurs données dedans. Un peu de défaites toute l'approche multi-locataire cependant.

Answer 1

Quelle sera la complexité de ces requêtes utilisateur? SQL arbitraire? Ou pouvez-vous obtenir en utilisant HQL ou les critères (et ce que je veux dire par là, c'est que vous laisserez les utilisateurs définir une sorte de QBE dans l'interface utilisateur, mais vous serez celui qui construit la requête réelle)? Dans ce dernier cas, les filtres peuvent aider un peu aussi.

Je ne voudrais pas déranger avec (1) à moins que les résultats de la requête soient toujours des listes simples. Vous pouvez représenter les hiérarchies/relations en XML, mais je doute que vos utilisateurs l'apprécient car ils devraient le traiter. Et l'approche toString() est à peu près garantie de se retourner parce que différents utilisateurs sont intéressés par différents rendus du même objet (par exemple si vous renvoyez la liste de As qui est liée à Bs, user1 voudrait un résultat différent de B.toString () puis utilisateur2).

(2) devrait fonctionner si vous avez vraiment besoin de requêtes SQL arbitraires. En fonction de la complexité de votre base de données et du nombre d'utilisateurs, vous pouvez vous en sortir en créant des vues (par utilisateur) au lieu des copies de base de données réelles.

Answer 2

J'ai le même problème et je réfléchis (hard) à l'implémentation d'un driver ODBC personnalisé qui "cache" le multi-tenancy. Découvrez Data Direct OpenSDK ODBC ...

http://www.datadirect.com/products/odbc/index.ssp