Dynamics AX 2012 et Dynamics 365 — la couche infrastructure

La pile de dépendances

Un environnement Dynamics AX 2012 repose sur une chaîne : poste client, serveur d’objets applicatifs, base SQL Server, service de reporting, services web, annuaire Active Directory, résolution DNS et liens réseau entre sites. Un incident perçu comme « AX est lent » se résout presque toujours à un maillon de cette chaîne. Isoler couche par couche évite de modifier l’ERP pour un problème qui n’y est pas.

• Le symptôme touche-t-il un utilisateur, un site, ou tout le monde ?
• Le ralentissement suit-il un traitement précis ou l’ensemble des écrans ?
• La même opération exécutée directement en SQL est-elle lente ?
• Le serveur d’application et la base sont-ils sur le même segment réseau ?

Performance des traitements par lots

Les traitements longs — clôtures, calculs de coûts, réapprovisionnement — concentrent les régressions. Leur durée dérive rarement d’un seul coup : elle augmente avec le volume de données, jusqu’à ce qu’un plan d’exécution bascule ou qu’une fenêtre de traitement soit dépassée. Le suivi de la durée de chaque tâche dans le temps vaut mieux qu’une analyse ponctuelle en situation de crise.

• Historiser la durée des tâches par lots pour repérer la dérive avant l’incident
• Vérifier la répartition des groupes de traitement entre serveurs
• Contrôler la contention entre les lots et l’activité interactive
• Rechercher les tables de journalisation et de trace qui grossissent sans purge

Reporting SSRS

Les états SSRS échouent le plus souvent pour des raisons qui n’ont rien à voir avec l’état lui-même : délégation Kerberos incomplète, compte de service dont le mot de passe a expiré, certificat arrivé à échéance, ou délai d’exécution dépassé sur une base sous charge. Les périodes de clôture révèlent ces défauts parce qu’elles combinent volume et concurrence.

• Noms de principaux de service et délégation, vérifiés plutôt que supposés
• Validité et chaîne de confiance des certificats utilisés par le service
• Délais d’exécution et de rendu configurés en cohérence avec la charge réelle
• Journaux du serveur de rapports, corrélés avec l’activité SQL au même horodatage

Ce qui casse après un changement d’infrastructure

Migration de serveur, changement de certificat, renommage de domaine, bascule de lien inter-sites : chacune de ces opérations touche des dépendances que la documentation Dynamics ne mentionne pas toujours. Établir la cartographie des comptes de service, des ports et des noms résolus avant la bascule coûte quelques heures ; le faire après un incident en coûte davantage.