Arthur Ria
b7151b3bc7
Le serveur traite les tools/call en concurrence. Les trois services a cache chargent paresseusement sans se coordonner : le premier appelant qui trouve le cache invalide lance le fetch, et tous ceux qui arrivent pendant ce fetch le trouvent *encore* invalide et lancent le leur. Une rafale de 6 appels identiques declenchait donc 6 chargements complets pour une seule cle. Ce n'est pas qu'un gaspillage : la duplication surcharge l'API AD au point de la faire echouer. Rafale mixte de 14 appels, avant correction — les 4 appels EasyWMS (~4000 workflows) reviennent en erreur, les memes passent en sequentiel : [Workflow] Error fetching workflows for "EasyWMS": POST https://10.255.255.2/AD/api/Workflow/GetByApplication failed (HTTP 500) fetching from API: 8 | EntityResolver Cache expired or empty: 3 Motif commun extrait dans src/services/single-flight.js — une Map de promesses, pas de dependance externe. Une cle par entree de cache (workflows::<app>, applications, <app>::<type>, metadata) : deux cles distinctes se chargent toujours en parallele, aucun prechargement (D26 intact). La promesse est retiree au reglement, succes *ou* echec, pour qu'un fetch en erreur ne reste pas coince. Le log de fetch reste l'observable (un par chargement reel) ; les appelants joints emettent une ligne distincte "Fetch already in flight ... joining it". --- Verifications (LIMAGRAIN), rafales rejouees 3 fois --- Phase 0, reproduction avant correction : 6 x search_workflows CustomApp -> count 44 x6, 'fetching from API' : 6 6 x query_wms_entities Container -> 6 succes, 'EntityResolver] Cache expired or empty' : 6 Rafale de 6 search_workflows {"query":"CST_","application":"CustomApp"} : ===== RUN 1 ===== ===== RUN 2 ===== ===== RUN 3 ===== id 10 success=true application=CustomApp count=44 (idem RUN 2 et RUN 3, id 11 success=true application=CustomApp count=44 les 6 reponses a 44) id 12 success=true application=CustomApp count=44 id 13 success=true application=CustomApp count=44 id 14 success=true application=CustomApp count=44 id 15 success=true application=CustomApp count=44 -- 'fetching from API' : 1 | 'joining it' : 5 [RUN 1] -- 'fetching from API' : 1 | 'joining it' : 5 [RUN 2] -- 'fetching from API' : 1 | 'joining it' : 5 [RUN 3] Rafale de 6 query_wms_entities {"entity_type":"Container","limit":1} : RUN 1/2/3 : id 10..15 success=true count=1 (6/6) -- 'EntityResolver] Cache expired or empty' : 1 | joins : 5 | GET Metadata/Entities : 5 [identique RUN 1, RUN 2, RUN 3] (avant : 6 chargements, soit 30 GET Metadata) Rafale mixte EasyWMS + CustomApp (3 + 3) — un fetch par application : RUN 1/2/3 : CustomApp count=44 x3, EasyWMS count=50 x3 [Workflow] Cache expired or empty for "CustomApp", fetching from API... [Workflow] Cache expired or empty for "EasyWMS", fetching from API... total fetch=2 joins=4 [identique RUN 1, RUN 2, RUN 3] Plus aucun HTTP 500 : un seul fetch EasyWMS concurrent au lieu de 4. Chemin sequentiel nominal, strictement inchange (driver sequentiel) : [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 Liberation de la Map sur echec (test direct, apiService.post substitue : echoue au 1er appel, reussit ensuite) : [Workflow] Cache expired or empty for "TestApp", fetching from API... [Workflow] Fetch already in flight for "workflows::TestApp", joining it (x2) --- rafale de 3 sur un fetch en echec : appelant 0/1/2: rejected - Failed to fetch workflows ... panne reseau simulee appels reseau reels: 1 (attendu 1 : les 3 partagent le meme fetch) cache pose ? {} (attendu {} : rien en cache sur echec) --- appel suivant (la Map doit avoir ete liberee) : resultat: 1 workflow(s), appels reseau cumules: 2 Baseline : tools/list 23, resources/list 6 ; npm test 4/4 exit 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.