Arthur Ria
097b76c7ef
Un fetch parti AVANT une invalidation (clearCache/invalidateCache, declenchees
par onSwitch a la bascule de profil, D8) terminait APRES elle et ecrivait quand
meme son resultat : le cache repartait peuple avec les donnees de l'ancien
tenant, timestamp neuf, valid: true. Defaut latent avant L6.1 ; deterministe
apres, puisque la promesse en vol survit desormais a l'invalidation.
Compteur de generation par service, incremente a chaque invalidation. Le fetch
capture la generation au depart et, au moment de publier, jette son resultat si
elle a bouge. Surtout : les fonctions de chargement n'ecrivent plus rien en
cache — la publication est un `commit` passe a singleFlight.run, appele
seulement si la generation n'a pas change. La garde devient structurelle, pas
conventionnelle : un chargement ne peut plus publier par inadvertance.
L'invalidation vide aussi la Map des promesses en vol. L'appelant deja en
attente recoit quand meme son resultat — il l'a demande avant la bascule ;
c'est sa mise en cache qui est refusee.
--- Verifications (LIMAGRAIN) ---
Rafale [search_workflows(EasyWMS), switch_wms_profile(EUROTRAFIC)] envoyee d'un
bloc, puis get_application_summary SEQUENTIEL apres les deux reponses.
AVANT la garde (HEAD = L6.1), 3 rejeux — le cache survit a la bascule :
===== RUN 1 =====
search_workflows : success=true count=50
switch_wms_profile : success=true
get_application_summary -> workflowCachesByApplication =
{"EasyWMS":{"cached":true,"count":3944,"timestamp":1787665677594,
"age":0,"valid":true}}
adElementsByApplication = {}
=> caches peuples : 1 (attendu 0)
===== RUN 2 ===== idem, count 3944, timestamp 1787665687744, valid true
===== RUN 3 ===== idem, count 3944, timestamp 1787665703945, valid true
APRES la garde, 3 rejeux — aucun cache peuple :
===== RUN 1 =====
search_workflows : success=true count=50
switch_wms_profile : success=true
get_application_summary -> workflowCachesByApplication = {}
adElementsByApplication = {}
=> caches peuples : 0 (attendu 0)
-- stderr : 1 resultat(s) jete(s) | 2 'Cache cleared'
===== RUN 2 ===== identique : caches peuples 0, 1 resultat jete
===== RUN 3 ===== identique : caches peuples 0, 1 resultat jete
Test direct et deterministe (invalidation declenchee pendant un fetch tenu
ouvert par une porte) :
[Workflow] Cache expired or empty for "TestApp", fetching from API...
--- invalidation PENDANT le fetch (clearCache) ---
[Workflow] Cache cleared
[Workflow] Fetched 1 workflows (total: 1)
[Workflow] Result for "workflows::TestApp" discarded, not cached:
cache invalidated during fetch (generation 0 -> 1)
l'appelant recoit bien son resultat : 1 workflow(s)
cache apres coup : {} (attendu {})
Non-regression L6.1, 3 rejeux de la rafale de 6 (CustomApp) :
== RUN 1 : 6 reponses a 44 | fetch=1 joins=5 caches=1
== RUN 2 : 6 reponses a 44 | fetch=1 joins=5 caches=1
== RUN 3 : 6 reponses a 44 | fetch=1 joins=5 caches=1
Chemin sequentiel nominal, inchange :
[search_workflows] success=true application=EasyWMS count=50 len=14220
[search_workflows] success=true application=EasyWMS count=50 len=14220
fetch=1 cached=1 joins=0
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
WMS MCP Server
Serveur MCP qui donne à Claude un accès en lecture à un WMS EasyWMS (Mecalux), pour le diagnostic et l'analyse.
Concrètement, dans Claude Desktop :
« Combien de commandes sont bloquées en statut Release sur LIMAGRAIN ? » « Trouve les workflows qui touchent au réapprovisionnement. » « Cherche
Order 4711dans les logs. » « Quels paramètres sont surchargés sur l'entrepôt 2 ? »
Architecture : 100 % API REST. Aucun accès direct à Oracle — voir D1 dans DECISIONS.md.
Ce que le serveur expose
23 outils répartis en 8 familles :
| Famille | Outils |
|---|---|
| Requêtes WMS | query_wms_entities, count_wms_entities, get_entity_schema, search_wms_data |
| API brutes | call_query_api, execute_command |
| Workflows | search_workflows, get_workflow_details, list_workflow_categories |
| Application Dictionary | get_application_summary, get_ad_elements, search_ad_elements, get_ad_element_details, list_ad_types |
| Métadonnées | get_entity_metadata, generic_search |
| Configuration | get_system_parameters |
| Profils | list_wms_profiles, get_current_wms_profile, switch_wms_profile |
| Logs | read_recent_logs, list_log_files, search_logs |
6 resources de contexte : wms://entities, wms://entity-schemas,
wms://query-examples, workflows://overview, api://catalog, logs://guide.
Multi-WMS. Plusieurs backends (clients, tenants) coexistent dans un seul
serveur ; Claude bascule à la demande avec switch_wms_profile.
Installation
Prérequis : Node.js 18+ et un accès réseau au WMS (VPN si nécessaire).
npm install
Copiez .env.example en .env et renseignez au moins un profil :
WMS_API_AUTH=Basic R05BOklFNGU3aXFoZHQ=
WMS_APPLICATION=EasyWMS
WMS_API_PATH=/ApplicationService/api
WMS_TOKEN_PATH=/EasySTS/OAuth/Token
WORKFLOW_API_PATH=/AD/api
WMS_PROFILES=AD
DEFAULT_WMS_PROFILE=AD
AD_HOST=10.255.255.2
AD_USERNAME=...
AD_PASSWORD=...
AD_TENANT=AD
AD_SAAS=false
Vérifiez la connectivité — le test est en lecture seule :
npm test
Sortie attendue : 4/4 tests reussis. En cas d'échec, voir
MONITORING.md §7.
Brancher Claude Desktop
Éditez %APPDATA%\Claude\claude_desktop_config.json :
{
"mcpServers": {
"wms": {
"command": "node",
"args": ["D:\\chemin\\vers\\mcp-wms-api\\src\\index.js"]
}
}
}
Puis fermez et rouvrez complètement Claude Desktop. Les logs du serveur
apparaissent dans %APPDATA%\Claude\logs\.
Ajouter un WMS
- Ajoutez son nom à
WMS_PROFILES(séparateur : virgule). - Définissez
<NOM>_HOST,<NOM>_USERNAME,<NOM>_PASSWORD,<NOM>_TENANT. - Mettez
<NOM>_SAAS=truesi le WMS est hébergé dans le cloud Mecalux — les outils de log seront alors désactivés pour ce profil, à dessein.
Les URL se construisent à partir du host : rien d'autre à dupliquer. Testez
avec npm test -- <NOM>.
Compiler un exécutable Windows
npm run build
Produit dist/wms-mcp-server.exe (~76 Mo, autonome, cible node22-win-x64).
Placez le .env à côté de l'exe : en mode packagé, c'est là qu'il est lu,
et aucun credential n'est embarqué dans le binaire (D7). Les avertissements
Cannot find module '@modelcontextprotocol/sdk/…' pendant le build sont
normaux et sans effet (D18).
Déploiement type sur la VM :
C:\WMS\mcp\wms-mcp-server.exe
C:\WMS\mcp\.env
Documentation
| Fichier | Contenu |
|---|---|
| CLAUDE.md | Architecture, inventaire des outils, conventions de code |
| DECISIONS.md | Pourquoi le code est ainsi + pièges vérifiés en production |
| MONITORING.md | Superviser le serveur MCP : logs, token, caches, symptômes |
| ROADMAP.md | Travaux planifiés par lot, et ce qui a été écarté |
| docs/logs.md | Accès aux logs du WMS |
| docs/ | Références EasyWMS (API, entités) |
Sécurité
.envetdist/sont ignorés par git — ne les committez jamais.- La validation TLS est désactivée pour accepter les certificats auto-signés des WMS on-premise (D15).
- ⚠️ L'historique git contient un ancien fichier de configuration avec des mots
de passe en clair (commit
b59cbb3). Ces credentials sont à considérer comme compromis — voir D20.