Les logs de production ont tranché les trois causes. 1. La recherche de list object Qlik applique un OU entre les mots : « tapis anti » ramenait 17 696 libellés sur 1 070 645 — presque tous ne contenant que « anti ». On cherche désormais mot par mot pour retenir le plus sélectif, on filtre en ET côté client (tous les mots présents, insensible casse/accents), et on ne sélectionne que les valeurs retenues. 2. Sélectionner ces 17 694 valeurs faisait abandonner le cube suivant (code 15 « Request aborted »), d'où le repli systématique sur le catalogue local. La sélection est maintenant plafonnée à 1 000 valeurs, faite par numéro d'élément (SelectListObjectValues) plutôt que par texte, et les appels Engine retentent trois fois sur code 15. 3. Les champs détectés étaient les mauvais : article_libelle_ticket (libellé ticket tronqué) au lieu d'Article, et code_fournisseur (le code, d'où les « F005 » affichés) au lieu de Fournisseur. Une liste de préférences précède désormais l'heuristique, avec repli automatique sur le candidat suivant si un champ ne ramène rien. Aussi : - Un repli catalogue n'est plus mis en cache 10 min : une panne Qlik passagère se corrigeait uniquement avec « Relancer ». - Le code 15 est traduit en message actionnable, et un terme trop large pour le moteur est signalé au lieu d'un « aucun résultat » trompeur. - Les logs de la page ne relaient plus le bruit du client Qlik (thèmes, extensions). Co-Authored-By: Claude Opus 5 <noreply@anthropic.com> Claude-Session: https://claude.ai/code/session_01DfqUihgixw4K1AmJhizWiu
CollectFlow
CollectFlow est une application de révision d'assortiment et d'analyse de performances des produits en point de vente, conçue pour consolider les données issues de plusieurs fournisseurs et magasins.
Prérequis
- Node.js 18+ (pour le développement local)
- Docker et Docker Compose (pour le déploiement conteneurisé)
- PostgreSQL 16+
Lancer avec Docker
Le projet est configuré pour tourner dans un conteneur Docker optimisé (mode standalone de Next.js). Note : Vous devez disposer d'une base de données PostgreSQL séparée (le conteneur ne lance que l'application web).
1. Démarrer l'application
À la racine du projet, lancez :
npm run docker:build
# ou directement
docker-compose up -d --build
L'application sera accessible sur http://localhost:5643.
L'application sera attachée au réseau Docker externe nginx_default afin d'être exposée derrière votre reverse proxy Nginx. Assurez-vous que ce réseau existe (docker network create nginx_default).
2. Arrêter l'application
npm run docker:down
# ou directement
docker-compose down
Développement Local (Sans Docker)
Si vous préférez développer en local, vous devrez configurer votre propre base de données PostgreSQL.
- Installer les dépendances :
npm install
-
Configurer la connexion DB : Allez sur la page des Paramètres (
/settings) dans l'application pour configurer l'accès à votre PostgreSQL local. -
Lancer le serveur de développement :
npm run dev
Structure du Projet (BMAD)
Ce projet respecte l'architecture BMAD (Business, Model, Application/API, Data) :
src/features/*: Logique métier (Business) isolée par feature (ex:grid,snapshots)src/types/*: Interfaces TypeScript (Model)src/app/*: Routeurs Next.js UI et endpoints d'API (Application/API)src/db/*: Schémas Drizzle ORM et connexions (Data)