Conception de l’infrastructure de gestion des exceptions ESB
Les modèles cohérents et réutilisables pour la gestion des exceptions sont au cœur de tout projet de développement. ils permettent d’optimiser la maintenance et de faciliter la prise en charge de l’application après le déploiement.
Une application BizTalk classique peut utiliser les fonctionnalités de messagerie BizTalk, démarrer éventuellement le traitement d’une orchestration, appeler le moteur de règles d’entreprise, interagir avec plusieurs systèmes métier (LOB) ou de planification des ressources d’entreprise (ERP) et retourner une réponse à un système tiers distinct. En outre, l’emplacement d’exécution de ces composants, y compris les sous-systèmes BizTalk, peut résider sur un ou plusieurs serveurs distribués dans l’environnement actuel. Il s’agit d’un scénario classique qui nécessite que le système prend en charge l’interception et la création de rapports d’exceptions qui peuvent se produire dans l’un des sous-systèmes découplés ESB ou BizTalk ou dans les différents systèmes métier tiers, chacun ayant ses propres contraintes de gestion des exceptions. Par exemple, l’ordinateur mainframe peut rejeter une commande envoyée à partir d’un site Web pendant un cycle de traitement normal ; le site Web doit compenser cette erreur et avertir l’utilisateur.
En raison de la complexité des applications ESB et de leur environnement, le développement d’une solution cohérente pour la gestion des exceptions d’application doit englober les objectifs de conception courants suivants :
Fournir une approche standardisée pour la détection et la gestion des exceptions qui se produisent dans l’environnement BizTalk Server (autrement dit, dans les sous-systèmes de messagerie et d’orchestration).
Fournissez des modèles courants qui permettent aux processus automatisés de réagir aux exceptions d’application et de les gérer.
Fournissez un modèle de gestion des exceptions faiblement couplé qui facilite la réutilisation.
Fournissez un mécanisme de création de rapports commun pour les exceptions d’application et leurs états de message disponibles qui peuvent s’appliquer à n’importe quel sous-système BizTalk.
Pour comprendre pourquoi microsoft BizTalk ESB Toolkit fournit un mécanisme d’erreur personnalisé, à savoir l’infrastructure de gestion des exceptions, et comment il fonctionne, il est nécessaire de comprendre les fonctionnalités de gestion des exceptions disponibles dans BizTalk Server et pourquoi ces fonctionnalités ne sont pas entièrement capables de répondre aux objectifs de conception précédents.
BizTalk Server rapport d’exceptions
BizTalk Server prend en charge les mécanismes de gestion des exceptions et de création de rapports suivants :
Échec du routage des messages
Console Administration de BizTalk Server
Journal des événements Microsoft
Options de développement personnalisées
Par défaut, les fonctionnalités de BizTalk Server pour gérer les exceptions reposent beaucoup sur l’intervention de l’opérateur. Par exemple, considérez la situation où un utilisateur envoie un message à BizTalk Server qui provoque une exception pendant la phase de validation. Par défaut, le message est publié dans la base de données Message Box, où il est routé vers une file d’attente suspendue. Cela signifie qu’un opérateur doit effectuer les opérations suivantes :
Détecter indépendamment qu’une exception s’est produite.
Enregistrez manuellement le message d’échec sur le disque à l’aide de la console d’administration BizTalk Server.
Modifiez et corrigez manuellement le message, puis envoyez-le à nouveau au système. Dans certains cas, ce processus risque de perdre des informations de contexte importantes.
Pour résoudre ces problèmes, BizTalk Server fournit le mécanisme de routage des messages ayant échoué. Les développeurs et les administrateurs peuvent l’utiliser pour créer des processus d’orchestration ou des ports d’envoi de messagerie configurés pour s’abonner à toutes les exceptions qui se produisent dans le sous-système de messagerie. Cela fournit un mécanisme automatisé de détection et de routage des erreurs qui conserve l’état du message d’origine et résout le problème de détection des exceptions.
Étant donné que le routage automatique des messages ayant échoué n’est pas fourni pour les processus d’orchestration, le développeur doit tenir compte des erreurs en ajoutant des blocs de gestionnaire d’exceptions aux formes d’étendue d’orchestration. Avec cette solution, chaque orchestration peut avoir sa propre gestion des exceptions, mais il n’existe aucun mécanisme pour réutiliser les fonctionnalités de gestion des exceptions sur plusieurs orchestrations.
Cela signifie qu’il existe maintenant deux façons très différentes de traiter et de gérer les exceptions de messagerie dans un système BizTalk Server, et une troisième manière de traiter les exceptions d’orchestration. Par conséquent, les développeurs doivent personnaliser le mécanisme de gestion des exceptions en fonction de leurs propres exigences s’ils souhaitent implémenter un système qui correspond aux exigences décrites plus haut dans cette section.
Console Administration de BizTalk Server
La console d’administration BizTalk Server fournit un ensemble de pages Vue d’ensemble du groupe, appelées hub de groupes BizTalk. À l’aide de ces pages, les administrateurs peuvent interroger les messages suspendus et les exceptions regroupées par application, nom de service, code d’erreur ou URI, comme illustré dans la figure 1.
Figure 1
Pages vue d’ensemble du groupe de consoles d’administration BizTalk Server
Bien que la fonctionnalité Vue d’ensemble du groupe fournisse une interface utilisateur commune pour afficher les exceptions, les vues sont limitées aux instances de service « actives ». L’examen de l’état peut être une tâche fastidieuse, car les administrateurs doivent explorer l’arborescence jusqu’à chaque élément. En outre, plusieurs autres facteurs limitent la BizTalk Server fonctionnalités de la console d’administration en tant qu’outil de création de rapports d’exceptions d’application :
Il n’existe aucune fonctionnalité d’exploration de données à des fins d’aide à la décision. Par exemple, vous ne pouvez pas rechercher les applications les plus incriminables sur une base mensuelle ou examiner les tendances trimestrielles pour les exceptions d’application.
L’entreprise peut exiger que des alertes soient déclenchées lorsque certaines exceptions d’application se produisent ou lorsqu’elles atteignent des seuils spécifiques, mais il n’est pas possible de s’abonner à ces types d’événements d’exception.
La console MMC (Microsoft Management Console) que la console d’administration utilise comme mécanisme d’interface utilisateur n’est pas une interface idéale et il n’est pas toujours pratique d’y accéder dans les environnements de production. Au minimum, les utilisateurs doivent être membres du rôle Opérateurs BizTalk ; et, dans les environnements de production, l’accès à la console MMC n’est généralement possible que via Terminal Server.
La console affiche uniquement les exceptions non gérées (instances de service suspendues). Si le développeur gère l’exception dans l’orchestration, ce qui permet à l’orchestration de se terminer normalement, les informations sur l’exception n’apparaîtront jamais dans la console d’administration.
Microsoft BizTalk ESB Toolkit résout ces limitations par le biais du mécanisme de routage des exceptions d’orchestration ayant échoué ESB. Cela ressemble étroitement au mécanisme de routage des messages ayant échoué de BizTalk Server. En outre, microsoft BizTalk ESB Toolkit inclut un composant de pipeline dans un port d’envoi qui s’abonne aux messages générés à la fois à partir du mécanisme de routage des exceptions d’orchestration en échec ESB et du mécanisme de routage des messages ayant échoué et les normalise.
L’infrastructure de gestion des exceptions ESB tire parti d’autres fonctionnalités de BizTalk Server, telles que le modèle d’abonnement et la supervision de l’activité métier basée sur les événements (BAM). Cela signifie que l’infrastructure de gestion des exceptions ESB peut suivre les points de données d’exception avec BAM, puis les publier sur le portail BIZTalk BAM à des fins de supervision.