WebSphere Enterprise Service Bus, Version 6.2.0 Systèmes d'exploitation: AIX, HP-UX, i5/OS, Linux, Solaris, Windows


Cas d'utilisation : récupération des données après un événement ayant échoué

Un cas d'utilisation fournit un contexte à un scénario de reprise. Dans ce cas d'utilisation, une entreprise dispose d'une application qui reçoit une requête pour créer un nouveau compte.

La solution se compose de plusieurs modules comme le recommandent les meilleures pratiques de modules.

Le premier module sert d'intermédiaire et délègue le travail à un processus de création de compte, Account Creation. Dans l'exemple ci-dessous, la solution a été implémentée en tant que modules séparés où le transfert de la requête entre le module de médiation (AccountRouting) et le module de traitement (AccountCreation) s'effectue via une importation/exportation SCA. La capture d'écran ci-dessous illustre les deux modules.

Figure 1. Diagramme d'assemblage d'un processus de routage de compte
Transfert de la requête du module de médiation (AccountRouting) au module de traitement (AccountCreation) depuis l'importation SCA jusqu'à l'exportation SCA.

Vous pouvez voir à partir du diagramme d'assemblage de la Figure 1, les emplacements dans le flux auxquels des incidents peuvent survenir. N'importe quel point d'appel du diagramme peut propager ou impliquer une transaction. Le flux comporte quelques zones où les données vont s'accumuler suite à un incident de l'application ou du système.

En général, les limites des transactions sont créées et gérées par l'interaction (synchrone et asynchrone) entre les composants et les liaisons d'importation/exportation et leurs qualificateurs. Le plus souvent, les données métier s'accumulent dans des emplacements de reprise spécifiques suite à une transaction défaillante, un blocage ou une annulation.

Les fonctions concernant les transactions dans WebSphere Application Server permettent à WebSphere ESB d'enregistrer les transactions avec les fournisseurs de services. Ces transactions sont particulièrement importantes pour comprendre les liaisons d'importation et d'exportation. Il est en effet important de comprendre l'utilisation des importations et des exportations dans vos cas d'utilisation pour pouvoir déterminer l'emplacement d'accumulation des événements nécessitant une reprise.

Les modèles d'interaction, de transactions utilisés et l'utilisation des importations et des exportations doivent être clairement définis avant le développement de l'application par une stratégie de traitement d'erreurs du projet. L'architecte de la solution doit identifier les préférences à utiliser, les instructions, qui sont ensuite utilisées lors de la création de l'application. Par exemple, l'architecte doit savoir quand utiliser les appels synchrones et les appels asynchrones, le traitement de fautes BPEL et ainsi de suite. Il doit savoir si tous les services peuvent participer, ou pas, dans les transactions et, pour ceux qui ne peuvent pas, comment compenser cette situation en cas de problèmes.

Par ailleurs, l'application représentée dans le diagramme d'assemblage à la Figure 1 optimise les groupes de connectivité et les meilleures pratiques de développement des modules. En optimisant ce modèle, nous pouvons maintenant arrêter le flux entrant des nouveaux événements en arrêtant le module AccountRouting .

Les sections suivantes traitent de l'emplacement des données métier en cas d'incident ou de reprise.

Business Flow Manager ou Human Task Manager

Dans notre cas métier, nous optimisons un processus BPEL pour le processus AccountCreation.

Concernant la reprise, vous devez vous poser des questions en termes de gestion BPEL et des tâches utilisateur :
  1. Le type de processus qui est exécuté (courte durée, longue durée, machine d'état métier, tâche utilisateur)

    Les processus de courte durée sont appelés des microflux.

  2. Le processus est-il développé correctement et utilise-t-il le traitement des erreurs pour promouvoir l'intégrité des données ?
  3. Comment les modèles d'appel et les propriétés des unités de travail sont-ils configurés pour prévoir et contrôler les limites des transactions ?

Les réponses à ces questions auront une incidence sur votre stratégie de reprise pour les appels 7 et 8 du diagramme d'assemblage (mis en évidence sur la capture d'écran ci-dessous) :

Figure 2. Diagramme d'assemblage du routage du compte - appels 7 et 8
Capture d'écran avec les appels 7 et 8 mis en évidence.

Les composants avec état, comme les processus BPEL de longue durée et les machines d'état métier, impliquent un grand nombre de transactions de base de données où les changements d'activité de processus et les changements d'état sont validés dans la base de données. Le travail progresse en mettant à jour la base de données et en plaçant un message dans une file d'attente interne qui décrit les opérations suivantes.

S'il y a des problèmes de traitement des messages internes au moteur de processus métier, ces messages sont déplacés dans une File d'attente de conservation. Le système essaie de poursuivre leur traitement. Si un message suivant est correctement traité, les messages de la file d'attente de conservation sont à nouveau soumis pour traitement. Si un même message a été placé cinq fois dans cette file d'attente, il est alors placé dans la file d'attente de stockage temporaire. .

Des informations supplémentaires sur l'affichage du nombre de messages et la réexécution de ces derniers se trouvent dans Réexécution des messages de la file d'attente de conservation/de stockage temporaire.

Gestionnaire d'événements ayant échoué

Il permet de réexécuter les événements ou les demandes d'appel de service effectués de manière asynchrone entre la plupart des types de composants.

Les événements ayant échoué sont créés si le composant AccountRouting effectue un appel asynchrone vers la liaison d'importation SCA AccountCreationSCAImport et que l'exception ServiceRuntimeException est renvoyée.

Il est important de noter que les événements ayant échoué ne sont pas générés la plupart du temps lorsque BPEL est le client dans l'interaction de services. Cela signifie que les appels 7 et 8 (comme indiqué à la Figure 2) n'entraîneront pas un événement ayant échoué. BPEL fournit des gestionnaires d'erreur ainsi que d'autres moyens de créer des modèles pour les incidents. Si un incident ServiceRuntimeException (SRE) appelant “JDBCOutboundInterface” se produit, il est donc renvoyé au BPEL pour traitement. La stratégie de traitement d'erreurs du projet doit définir comment les exceptions d'exécution sont systématiquement traitées dans BPEL.

Notez bien que les événements ayant échoué sont créés pour les messages de réponse asynchrones pour le client BPEL s'il n'est pas possible de livrer ces messages à l'instance de processus suite à un incident au niveau de l'infrastructure.

Le diagramme suivant illustre le fonctionnement du composant gestionnaire d'événement ayant échoué. Sa description détaillée par étape est donnée juste après.

Figure 3. Fonctionnement du gestionnaire d'événement ayant échoué
Diagramme du fonctionnement du gestionnaire d'événement ayant échoué. Chaque étape est numérotée puis détaillée à la suite du diagramme.
Fonctionnement du gestionnaire d'événement ayant échoué
  1. Le composant source effectue un appel en utilisant un modèle d'appel asynchrone
  2. Le MDB (bean géré par message) SCA extrait le message de la destination SCA
  3. Le MDB SCA appelle le bon composant cible
  4. Le composant cible émet une exception ServiceRuntimeException
  5. La transaction du MDB SCA est renvoyée vers la destination SCA
  6. Les informations concernant l'exception sont stockées dans la base de données du gestionnaire d'événement ayant échoué avec le statut non confirmé
  7. Le SIBus réessaie d'effectuer l'appel un nombre n de fois

    Par défaut, 5 tentatives maximum sont autorisées - l'opération d'origine et 4 tentatives. Vous pouvez modifier cette valeur dans la console d'administration. Par exemple, soit un module SCA M donné. Vous pouvez aller dans Bus > SCA.SYSTEM.<CELL>.BUS > Destinations > sca/M et modifier la valeur dans la zone Nombre maximum d'échecs de livraison.

  8. Lorsque le nombre maximum de tentatives est atteint, le message est envoyé à la destination du FEM.
  9. La base de données du FEM récupère le message
  10. La base de données du FEM met à jour l'événement ayant échoué dont le statut est alors défini sur échoué.

A quel moment les "événements ayant échoué" sont-ils créés ?

Comme indiqué précédemment, les événements ayant échoué ne sont créés ni pour les appels synchrones, ni pour les interactions de processus métier bilatérales.

Ils sont généralement créés lorsque les clients utilisent un modèle d'appel asynchrone et qu'une exception ServiceRuntimeException est émise par le fournisseur de services.

Si tout est effectué de manière synchrone et dans la même transaction, les données ne sont collectées nulle part. Tout est annulé pour le client qui a passé l'appel. Où qu'une validation soit effectuée, les données sont collectées. Si les appels sont tous synchrones, mais que plusieurs validations sont effectuées, celles-ci deviennent un problème.

De manière générale, vous devriez utiliser les appels de traitement asynchrone ou les processus BPEL de longue durée si plusieurs transactions sont nécessaires. Chaque appel ASYNC est ainsi une chance de pouvoir collecter les données. Les processus BPEL de longue durée sont un point de collecte.

Tableau 1. Modèles d'appels et création d'événements ayant échoué : Service Business Exceptions
Modèle d'appel Evénement ayant échoué O/N ? Remarques
Synchrone Non Les événements ayant échoué ne sont pas créés pour les SBE ni lorsqu'un modèle synchrone est utilisé
Asynchrone - sens unique Non Par définition, les appels à sens unique ne peuvent pas déclarer d'incidents, ce qui signifie qu'il est impossible qu'une exception ServiceBusinessException soit émise.
Asynchrone - réponse différée Non Les événements ayant échoué ne sont pas créés pour les SBE
Asynchrone - Rappel Non Les événements ayant échoué ne sont pas créés pour les SBE
Tableau 2. Modèles d'appels et création d'événements ayant échoué : Service Runtime Exceptions
Modèle d'appel Evénement ayant échoué O/N ? Remarques
Synchrone Non Les événements ayant échoué ne sont pas créés pour les SRE ni lorsqu'un modèle synchrone est utilisé
Asynchrone - sens unique Oui  
Asynchrone - réponse différée Oui  
Asynchrone - Rappel Oui  
BPEL - Double sens Non
Les événements ayant échoué ne sont pas créés lorsque le composant source est un processus métier
Remarque : Pour un appel asynchrone, si la réponse ne peut pas être renvoyée au BPEL, un événement ayant échoué est créé.
BPEL - sens unique Oui  
Pour de plus amples informations, consultez la rubrique Gestion des événements ayant échoué du centre de documentation.

Vous trouverez également des informations supplémentaires pour afficher et resoumettre les événements ayant échoué à la section Resoumettre les événements ayant échoué.

Destinations de bus d'intégration de services

Les messages en attente de traitement peuvent s'accumuler dans quelques destinations de bus d'intégration de services (SIBus). Dans la plupart des cas, ces destinations sont des destinations “système”. Les messages s'accumulant dans ces destinations sont généralement un mélange des trois types suivants :
  • Requêtes asynchrones de traitement
  • Réponses asynchrones aux requêtes
  • Messages asynchrones dont la résolution de la désérialisation ou du sélecteur de fonction a échoué
    Remarque : Les réponses asynchrones peuvent être des objets métier valides ou des erreurs renvoyés en tant que résultat d'une requête.

Destination de module SCA

Nous revenons ici à notre cas d'utilisation.

La solution comprend deux destinations de “module SCA” :
  • sca/AccountRouting
  • sca/AccountCreation

Ces destinations sont créées lors du déploiement du module sur un serveur d'applications ou un cluster.

Il est rare que les messages s'accumulent dans ce type de destination. En effet, l'accumulation de messages dans ces destinations est un indice de problème de performances ou d'incident lié à une application. Vous devez dans ce cas examiner le problème immédiatement. Il est important de surveiller la profondeur des destinations du module (avec la solution de surveillance de votre choix) car une sauvegarde des messages peut entraîner une indisponibilité du système ou un temps de recyclage prolongé.

Nous appelons ces destinations “Module SCA” car le nom généré correspond au nom du module apposé à “sca/”. Elles sont capitales dans le fonctionnement des appels asynchrones SCA (requêtes et réponses de courtier). Il existe un certain nombre d'autres destinations générées pendant l'installation de l'application sur le bus SCA.SYSTEM mais pour l'objet de cette présentation, nous nous en tiendrons à l'importance de la destination "Module SCA".

Nouvelle tentative de bus d'intégration système

Comme nous l'avons vu plus haut, le FEM intègre un mécanisme permettant de réessayer avec le bean géré par message (MDB) SCA. Vous pouvez contrôler ce comportement en modifiant l'attribut "Nombre maximum d'échec de livraison" sur la destination du module.
Remarque : Il n'y a en général pas de raison d'ajuster cette fonction. Ces informations sont fournies ici à titre exhaustif.

Dans notre cas d'utilisation, un certain nombre de destinations du bus d'intégration système sont créées par SCA pour la prise en charge des communications asynchrones.

Nous avons vu plus haut que l'une de ces destinations est appelée "sca/AccountRouting". Vous pouvez modifier le nombre de tentatives pendant une exception ServiceRuntimeException d'un appel de service asynchrone en modifiant la valeur de la propriété “Nombre maximum d'échec de livraison” sur la console d'administration. N'indiquez cependant pas de valeur inférieure à 2 dans les modules avec un processus BPEL. La deuxième tentative est en effet requise pour renvoyer les exceptions ServiceRuntimeException au BPEL pour traitement.

Destinations d'exception système

Le gestionnaire d'événement ayant échoué fait partie des endroits où gérer les incidents. Lorsque vous traitez des importations et exportations JMS ou EIS, vous devez envisager un autre emplacement important.

Les destinations sur le bus SCA.Application sont configurées pour acheminer pour ce bus les messages défaillants vers la destination d'exception du système SIB. Ainsi, si une exportation JMS récupère un message du bus SCA.Application et s'exécute dans une situation d'annulation, le message ayant échoué sera acheminé vers la destination d'exception du système SIB au lieu de la destination d'exception de reprise WBI. Ce scénario diffère de la discussion précédente sur les événements ayant échoué en ce sens qu'un échec de désérialisation d'un message sur le bus SCA.Application n'a pas pour conséquence un événement ayant échoué. Chaque bus de la solution comporte une destination d'exception du système. Vous pouvez contrôler et gérer ces destinations quasiment comme la “dead letter queue” commune aux infrastructures MQ.

Soit le scénario suivant :

Diagramme illustrant le traitement des exceptions système.
Un client JMS externe place un message sur une file d'attente entrante exposée via une exportation JMS. Le MDB de liaison d'exportation JMS récupère le message pour traitement. Deux situations sont possibles ici :
  1. L'exportation JMS analyse correctement le message et détermine quelle opération sur l'interface appeler, stade auquel le message est envoyé vers l'exécution SCA pour traitement.
  2. L'exportation JMS ne reconnaît pas le corps du message comme un objet métier valide ou la liaison d'exportation JMS désérialise le corps du message mais ne peut pas déterminer quelle opération sur l'interface appeler. A ce stade, le message est placé dans une destination d'exception du système pour le bus.

Ce type d'incident peut survenir lorsque vous tentez de recevoir des requêtes de l'exportation AccountRoutingJMSExport (1). Cette exportation est une exportation JMS et il est possible que des événements s'accumulent dans la destination d'exception du système sur le bus SCA.Application.Bus. Utilisez votre solution de surveillance pour observer la profondeur de cette destination.

Gestionnaire d'événements ayant échoué et destinations SIB

La destination des exceptions pour WebSphere ESB est définie sur la file d'attente de destination des exceptions deWebSphere ESB. Cette file d'attente suit une convention d'attribution de nom :
Nom du noeud : WESBNode
Nom du serveur : server1
Destination d'exception de reprise : WBI.FailedEvent.WESBNode.server1
De manière générale, toutes les destinations créées sur le bus SCA.System seront configurées pour acheminer les messages défaillants vers la destination d'exception de reprise.

Lorsqu'un incident système se produit, la fonction de reprise deWebSphere ESB capture non seulement le message défaillant dans cette destination d'exception, mais elle génère également un événement ayant échoué qui représente l'erreur système et le stocke dans la base de données Recovery comme indiqué à la section relative au gestionnaire d'événements ayant échoué de ce document.

Récapitulatif

En résumé, WebSphere ESB offre des fonctions d'administration au-dessus et au-delà de la plateforme WebSphere Application Server sous-jacente. Des mesures appropriées doivent être prises afin de comprendre et d'utiliser ces fonctions, tout en suivant les conseils de la section sur les pratiques préventives de Planification de la prévention d'erreurs et de la reprise sur incident.

Tableau 3. Fonctions d'administration permettant la gestion des incidents
Fonction d'administration Groupée avec WebSphere ESB O/N ? Récapitulatif
Gestionnaire d'événements ayant échoué Oui Accès en lecture/écriture/suppression. Emplacement central pour administrer les exceptions d'exécution de service et toute autre forme d'incidents d'infrastructure.

Navigateur de bus d'intégration de services

Oui

Lecture/suppression. Utilisez l'explorateur du bus d'intégration de services dans la console d'administration pour parcourir et effectuer des tâches opérationnelles au jour le jour sur les bus d'intégration de services.

Remarque : Le nombre d'événements/enregistrements pouvant être gérés simultanément par ces outils sont propres à des facteurs externes comme l'allocation de mémoire, les ensembles de résultats et l'optimisation de la base de données, le délai de connexion. Exécutez les tests et définissez les seuils appropriés afin d'éviter les exceptions (OOM, TransactionTimeOut).

concept Rubrique concept

Conditions d'utilisation | Commentaires en retour


Icône d'horodatage Dernière mise à jour: 07 juillet 2010


http://publib.boulder.ibm.com/infocenter/dmndhelp/v6r2mx/topic//com.ibm.websphere.wesb620.doc/doc/crec_use_case_recovery.html
Copyright IBM Corporation 2005, 2010. All Rights Reserved.
Ce centre d'information est mis en service par la technologie Eclipse (http://www.eclipse.org).