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.
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.
Dans notre cas métier, nous optimisons un processus BPEL pour le processus AccountCreation.
Les processus de courte durée sont appelés des microflux.
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) :
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.
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.
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
et modifier la valeur dans la zone Nombre maximum d'échecs de livraison.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.
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 |
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 |
Vous trouverez également des informations supplémentaires pour afficher et resoumettre les événements ayant échoué à la section Resoumettre les événements ayant échoué.
Destination de module SCA
Nous revenons ici à notre cas d'utilisation.
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
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 :
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
Nom du noeud : WESBNode Nom du serveur : server1 Destination d'exception de reprise : WBI.FailedEvent.WESBNode.server1De 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.
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.
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. |