DWH
L'écran DWH (Custom Queries dans la nomenclature interne) permet à chaque application de surcharger le SQL exécuté par défaut par Nomasx-1. Une ligne par couple (Application, Méthode) — Méthode est le hook du connecteur (par exemple get_users, get_assignments, get_object_usage) et SQL Blob porte le SQL de remplacement. Des champs JDBC / utilisateur / mot de passe optionnels permettent à la surcharge de viser un schéma différent de celui de l'application.
C'est le point d'extension. Quand un système source range ses tables de sécurité différemment de l'attente canonique de Nomasx-1, on surcharge la méthode ici plutôt que de toucher au produit.
Vue d'ensemble
Objectif de l'écran
- Surcharger par application. Une ligne remplace la requête par défaut que Nomasx-1 exécuterait pour la méthode nommée sur l'application nommée.
- Ajouter une connexion dédiée si besoin. Quand la requête surchargée vise un autre schéma ou d'autres identifiants, les colonnes JDBC / Utilisateur / Mot de passe les portent ; sinon la surcharge tourne sur la connexion principale de l'application.
- Tracer la modification. Utilisateur d'audit + Date d'audit enregistrent qui a introduit la surcharge et quand — utile quand un scan se met à se comporter différemment.
Colonnes
| Colonne | Source | Ce qu'on y lit |
|---|---|---|
| Application ID | SQL_APPS_ID — identifiant de l'application. Joint à Applications pour le nom convivial. | Application concernée par la surcharge. |
| Méthode | SQL_METHOD — nom du hook connecteur. | Emplacement de requête surchargé. |
| SQL Blob | SQL_BLOB — texte. Masqué par défaut. | Fragment SQL de remplacement. |
| JDBC / Utilisateur / Mot de passe | SQL_JDBC, SQL_USER, SQL_PASSWORD — optionnels. Masqués. | Connexion dédiée utilisée par la surcharge. |
| Audit utilisateur / date | SQL_AUDIT_USER, SQL_AUDIT_DATE — qui / quand. | Traçabilité de la modification. |
Boîte de dialogue
Cliquer sur Ajouter dans la barre d'outils pour déclarer une surcharge, ou double-cliquer une ligne pour la modifier. La boîte a trois onglets.
Onglet 1 — Propriétés
Couple qui identifie la surcharge. Les deux champs sont obligatoires.
| Champ | À renseigner |
|---|---|
| Application | Liste déroulante des applications déclarées. La surcharge s'applique uniquement à celle-ci. |
| Méthode | Nom du hook connecteur (get_users, get_assignments, get_object_usage, …) à surcharger. |
Onglet 2 — Base de données
Connexion dédiée optionnelle. Laisser les trois champs vides fait tourner la surcharge sur la connexion principale de l'application.
| Champ | À renseigner |
|---|---|
| Utilisateur | Compte en lecture utilisé pour exécuter le SQL surchargé. |
| Mot de passe | Mot de passe du compte. Stocké chiffré. |
| JDBC | URL JDBC quand la surcharge vise un schéma différent de celui de l'application. |
Onglet 3 — Requête
Le SQL de remplacement. Obligatoire.
| Champ | À renseigner |
|---|---|
| SQL Blob | Texte multi-ligne. Coller le SQL que Nomasx-1 doit exécuter à la place du défaut pour la méthode déclarée dans Propriétés. |
Conseils & bonnes pratiques
- Tester le SQL hors Nomasx-1 d'abord — une surcharge syntaxiquement cassée se traduit par une grille vide sur l'écran consommateur.
- Limiter le périmètre de la surcharge. Surcharger une méthode à la fois plutôt que réécrire une branche entière — plus simple à maintenir et à annuler.
- Documenter le pourquoi au moment de la revue ou dans un ticket — six mois plus tard, la surcharge doit pouvoir être relue par un autre administrateur.
- Retirer la ligne dès qu'elle n'est plus utile pour que Nomasx-1 retombe sur le comportement par défaut.