# Logs du WMS Comment le serveur MCP accède aux fichiers de logs du WMS, ce qu'il sait faire et ce qu'il ne peut pas faire. Pour superviser **le serveur MCP lui-même**, voir [MONITORING.md](../MONITORING.md). --- ## 1. Où sont les logs Les logs sont lus **directement sur le système de fichiers** du serveur WMS, via des partages réseau Windows — jamais par API. | Emplacement | Contenu | |---|---| | `\\\inetpub\logs\LogFiles\Mecalux` | logs applicatifs IIS, organisés en sous-dossiers par composant | | `\\\ProgramData\Mecalux\ETLLogs` | logs du middleware ETL | Configuration dans `.env`, plusieurs chemins séparés par des `;` : ```env LOGS_PATH=\\{host}\inetpub\logs\LogFiles\Mecalux;\\{host}\ProgramData\Mecalux\ETLLogs ``` **Le placeholder `{host}` est remplacé à chaque appel** par le host du profil actif. Il n'y a donc pas de chemin de logs à redéfinir par profil : un seul gabarit suffit, et il suit automatiquement `switch_wms_profile`. Le scan est **récursif** et ne retient que les fichiers dont le nom se termine par `.log`. Un dossier absent ou inaccessible n'interrompt pas le scan : il est journalisé (`[Logs] Cannot scan directory …`) et ignoré. --- ## 2. Prérequis d'accès Les partages `\\\...` doivent être joignables **depuis la machine qui exécute le serveur MCP**, avec les droits de lecture du compte Windows courant. Le serveur ne présente aucun credential propre pour SMB — il hérite de la session Windows. Vérification rapide, hors serveur MCP : ```bash Test-Path "\\10.255.255.2\inetpub\logs\LogFiles\Mecalux" ``` Si cette commande renvoie `False`, aucun outil de log ne fonctionnera : le problème est réseau ou droits, pas applicatif. --- ## 3. Profils SaaS : les logs ne sont pas accessibles Quand le profil actif est déclaré `_SAAS=true`, les trois outils de log **échouent volontairement** avec : > Log access is disabled for SaaS profile "X". The WMS is cloud-hosted — local > log files are not reachable. Use the WMS API (query/command/workflow tools) > instead. C'est un choix explicite, pas une régression : le WMS est hébergé dans le cloud Mecalux, son système de fichiers n'est pas exposé. Retourner « 0 fichier » laisserait croire à une absence d'erreurs — un faux négatif dangereux en diagnostic. Voir D9 dans [DECISIONS.md](../DECISIONS.md). **Sur un profil SaaS, le diagnostic passe donc uniquement par les API** : `query_wms_entities`, `count_wms_entities`, `search_wms_data`, les outils AD et `get_system_parameters`. --- ## 4. Les trois outils ### `list_log_files` Liste tous les `.log` trouvés sous `LOGS_PATH`, **triés du plus récent au plus ancien**, avec taille, date de modification et dossier d'origine. Point de départ naturel : il montre quels composants ont écrit récemment. Si aucun fichier n'est trouvé, l'erreur **énumère les chemins scannés** — c'est généralement suffisant pour diagnostiquer un `{host}` mal résolu. ### `read_recent_logs(count, log_file)` Renvoie les `count` dernières lignes (100 par défaut). Sans `log_file`, prend **le fichier le plus récemment modifié, tous dossiers confondus** — ce qui n'est pas forcément celui que l'on croit sur un serveur multi-composants ; préférez nommer le fichier. La résolution de `log_file` se fait en trois passes, de la plus stricte à la plus permissive : 1. chemin direct sous le premier `LOGS_PATH` (ex. `ApplicationDictionary\ApplicationDictionary.log`) ; 2. nom exact recherché dans chaque sous-dossier immédiat ; 3. correspondance partielle, insensible à la casse. En cas d'échec, l'erreur liste les fichiers disponibles. ### `search_logs(keyword, max_results, context_lines)` Recherche insensible à la casse dans **tous** les fichiers, du plus récent au plus ancien, en s'arrêtant à `max_results` (50 par défaut). Chaque résultat porte son fichier, son numéro de ligne et `context_lines` lignes avant/après (2 par défaut), la ligne trouvée étant marquée `isMatch`. C'est l'outil à privilégier pour tracer un identifiant métier (numéro de commande, code produit, id de tâche) à travers les composants. --- ## 5. Format des lignes `ApplicationService.log` suit ce format : ``` YYYY-MM-DD HH:MM:SS.ffff [thread] [Level] [Component] [message] ``` Exemple : ``` 2026-08-24 09:14:22.1873 [42] [ERROR] [OutboundOrderService] [Order 4711 not found] ``` Conséquence pratique : une recherche par **date préfixe** (`2026-08-24 09:`) fonctionne bien, et le niveau se filtre par `[ERROR]` — crochets inclus, pour éviter les faux positifs sur le mot « error » dans un message. Les logs ETL n'ont pas le même format ; ne présumez pas d'une structure commune entre les deux emplacements. --- ## 6. Limites à connaître - **Lecture intégrale en mémoire.** `read_recent_logs` et `search_logs` chargent chaque fichier entier avant de le découper. Sur un log de plusieurs centaines de Mo, c'est lent et coûteux en RAM. Vérifiez les tailles avec `list_log_files` avant de lancer une recherche large. - **Recherche par sous-chaîne uniquement**, pas d'expression régulière. - **Pas de filtre temporel** : `search_logs` ne sait pas restreindre à une plage horaire. Le contournement est d'inclure le préfixe de date dans le mot-clé. - **Aucun filtre de nom de fichier configurable.** Le scan retient tous les `.log`. (Une variable `LOG_FILE_PATTERN` a existé dans `.env` sans jamais être appliquée ; elle a été supprimée — voir D20.) - **Pas de rotation ni de purge** : le serveur MCP lit, il n'écrit ni ne supprime rien. --- ## 7. Hors périmètre : l'historique des shipment templates Les logs `ApplyShipmentTemplates` **ne sont pas présents** sur l'hôte joignable (`10.255.255.2`) : ils résident sur les serveurs de production / ETL des clients. Aucun outil ne les analyse, car il n'y aurait rien à lire. Ce que l'on peut obtenir par API se limite à la **dernière** exécution, via l'entité Reading `ShipmentTemplate` (`LastExecuteDate`, `Status`, `IsEnabled`). Voir D16 dans [DECISIONS.md](../DECISIONS.md) et les recettes de la resource `wms://query-examples`.