Gestion des échecs

La gestion des échecs dans le système InterChange Server Express consiste à utiliser les ressources d'identification des incidents afin de résoudre ces derniers. Des erreurs graves pouvant entraîner l'échec d'événements peuvent se produire sur un composant système tel qu'un connecteur ou une collaboration ou sur un composant tiers comme, par exemple, une application intégrée.

Lorsqu'une erreur entraîne l'échec d'un événement, des fonctions intégrées au système InterChange Server Express vous permettent de résoudre les incidents. Vous pouvez configurer le système afin qu'il mette en pause des collaborations dans InterChange Server Express en cas d'échec. Cette section traite des points suivants :

Reprise sur incident pour les appels de service

Stratégies de reprise d'InterChange Server Express

Erreurs graves

Perte de la connexion à l'application

Etat d'agent de connecteur inconnu

Echecs de connexion à la base de données

Echecs de flux

Reprise sur incident pour les appels de service

Pour éviter d'envoyer des événements dupliqués à l'application cible, vous pouvez empêcher un processus de reprise de renvoyer automatiquement tous les appels de service qui étaient en transit lorsqu'un échec s'est produit. Avant la panne du serveur, vous pouvez configurer une collaboration non transactionnelle pour maintenir tout événement d'appel de service à l'état En transit, en cas d'échec puis de reprise. Après la reprise d'InterChange Server Express, les événements d'appel de service restent à l'état En transit et vous pouvez utiliser Flow Manager ou Failed Event Manager pour examiner chaque événement ayant échoué et déterminer quand (et si) il sera soumis à nouveau.

Pour configurer une collaboration afin de maintenir un appel de service en échec à l'état de transit, ouvrez System Manager et cochez la case Conserver l'appel de service à l'état de transit dans la fenêtre Propriétés générales de collaboration.

Remarque :
Si la collaboration fait partie d'un groupe, la définition de cette propriété s'applique implicitement à toutes les autres collaborations du groupe. Définissez une collaboration pour l'option Conserver l'appel de service à l'état de transit uniquement si vous souhaitez que toutes les autres collaborations du groupe soient également définies de même. Pour les collaborations transactionnelles, il est recommandé de ne pas activer cette propriété ; décochez la case Conserver l'appel de service à l'état de transit.

Stratégies de reprise d'InterChange Server Express

Si InterChange Server Express s'arrête brusquement lors du traitement d'événements, tous les événements se trouvant dans la file d'attente des opérations en cours doivent être récupérés ou ils seront traités après le réamorçage du serveur. Potentiellement, en raison de la quantité de mémoire requise, la reprise des événements en cours peut ralentir ou même interrompre le réamorçage du serveur. Le produit InterChange Server Express propose deux fonctions, la reprise différée et la reprise asynchrone, pour réduire la durée de réamorçage du serveur et rendre le serveur accessible pour d'autres travaux avant la reprise de tous les événements.

Le contrôle des flux et le stockage des clés d'objet métier intégrées aux données en cours augmentent l'efficacité de la reprise différée et de la reprise asynchrone. Les deux fonctions réduisent la quantité de mémoire nécessaire à la reprise d'InterChange Server Express et permettent donc d'écourter considérablement la durée de réamorçage d'InterChange Server Express pendant une reprise.

Le stockage des clés d'objet métier intégrées aux données en cours désigne l'extraction d'une clé d'objet métier, pendant la reprise, sans désérialiser l'objet métier, ce qui évite un aller-retour avec MQ ou la base de données. Le contrôle des flux est un service vous permettant de configurer des paramètres de longueur de files d'attente au niveau du système ou du composant afin de contrôler la quantité de mémoire requise sur InterChange Server Express. Pour plus d'informations sur la configuration du contrôle des flux, voir Procédure de configuration du contrôle des flux sur l'ensemble du système.

Procédure de reprise différée d'événements de collaboration

Dans la reprise différée, la reprise des événements en cours d'une collaboration est reportée après le réamorçage du serveur, ce qui permet de libérer la mémoire utilisée par ces événements.

Une fois le serveur réamorcé, vous pouvez soumettre ces événements manuellement. Prenez connaissance des recommandations suivantes :

Etablissez la reprise différée en définissant la propriété RECOVERY_MODE d'un objet de collaboration.

Remarque :
L'utilisation de la reprise différée affecte la séquence des événements, ce qui peut entraîner des problèmes de sécurité des données. Utilisez cette fonction uniquement si la séquence des événements n'est pas un élément important.

La propriété RECOVERY_MODE comporte deux paramètres dont les effets sont les suivants, en cas d'échec et de reprise du serveur :

La valeur par défaut est Toujours.

Remarque :
Le passage de la valeur du mode de reprise des collaborations de Différé à Toujours ne permet pas de récupérer les événements différés et ne met pas les événements différés existants à l'état en cours d'exécution. Les événements à l'état de reprise différée restent différés jusqu'à ce que vous les soumettiez à nouveau.

Pour définir la valeur du mode de reprise d'une collaboration, appliquez la procédure suivante :

  1. Dans System Manager, à l'aide du bouton droit de la souris, cliquez sur un objet de collaboration, puis sur Propriétés. La boîte de dialogue Propriétés apparaît (voir figure 63).
  2. Dans la boîte de dialogue Propriétés de la collaboration, cliquez sur l'onglet Propriétés générales de collaboration. La boîte de dialogue suivante apparaît :
    Figure 63. Boîte de dialogue Propriétés, onglet Propriétés générales de collaboration
  3. Dans la liste Mode de reprise, sélectionnez l'une des options suivantes :

Reprise asynchrone

InterChange Server Express n'attend pas la reprise des collaborations et des connecteurs pour terminer le processus d'amorçage ; la reprise asynchrone des collaborations et des connecteurs est autorisée après l'amorçage d'InterChange Server Express. Cela vous permet d'utiliser des programmes d'identification et de résolution des incidents, tels que comme System Monitor, Failed Event Manager et Flow Manager, lors de la reprise des connecteurs et des collaborations.

Erreurs graves

Des erreurs graves dans le système InterChange Server Express peuvent entraîner des incidents dans votre environnement d'exécution. Une erreur grave, telle qu'elle est définie dans le système InterChange Server Express peut être provoquée par l'un des cas suivants :

Par défaut, une collaboration continue de traiter les déclencheurs suivants après l'échec d'un flux. Toutefois, vous pouvez configurer le comportement d'une collaboration afin qu'elle se mette en pause automatiquement lorsqu'une erreur grave qui se produit risque de faire échouer les flux. Ce type de configuration d'une collaboration permet d'éviter que le flux suivant échoue pour la même raison, en ne traitant pas les déclencheurs qui suivent l'échec d'un flux. Cette opération est capitale si vous devez actualiser la séquence de traitement des déclencheurs. Si la collaboration se met en pause, l'ordre dans lequel les déclencheurs parviennent au serveur est maintenu. A ce stade, vous pouvez réparer l'erreur grave, corriger le flux ayant échoué, puis relancer la collaboration. Si les collaborations ne dépendent pas d'un déclencheur associé à un flux en échec, vous pouvez reprendre la collaboration et résoudre le flux ultérieurement. Voir Echecs de flux pour plus d'informations sur la soumission de flux ayant échoué.

Pour configurer la mise en pause d'un objet de collaboration lorsqu'une erreur grave se produit, cochez la case Mettre en attente lorsqu'une erreur grave se produit, dans l'onglet Propriétés générales de collaboration de la boîte de dialogue Propriétés.

Si cette valeur est définie, la collaboration est mise en pause lorsqu'une erreur grave se produit et ne redémarre que dans l'un des deux cas suivants :

Si vous ne configurez pas la mise en pause de la collaboration lorsqu'une erreur grave se produit, vous pouvez être confronté à la situation suivante :

Deux déclencheurs, E1 et E2, attendent d'être traités par une collaboration. E1 crée un client et E2 met à jour E1. Dans la mesure où E2 met à jour E1, E1 doit être traité avant E2. Si une erreur grave se produit lorsqu'une collaboration traite E1 et qu'E1 échoue, E1 est placé dans la file d'attente de nouvelle soumission des événements. Si vous ne sélectionnez pas l'option Mettre en attente lorsqu'une erreur grave se produit, la collaboration tente de traiter E2. E2 échoue car il est dépendant de l'aboutissement du traitement d'E1.

Si la propriété de collaboration CONVERT_UPDATE est définie par true, E2, qui met à jour E1, crée alors le client à partir des données mises à jour. Les données dans E1 sont désormais obsolètes et ne doivent pas être soumises manuellement car elles écraseraient les données fournies par E2.

Perte de la connexion à l'application

Les collaborations en cours d'exécution sont basées sur le fait que des connexions en direct sont établies entre les connecteurs et leurs applications. Si l'application d'un connecteur devient inaccessible, le connecteur ne peut plus rechercher d'événements dans l'application ni répondre aux demandes de collaboration.

Lorsqu'une application est indisponible, le connecteur qui recherche des événements dans cette application génère une erreur à chaque tentative d'interrogation. Si le connecteur détermine que la connexion à l'application est interrompue, l'agent de connecteur s'arrête et renvoie un état au contrôleur de connecteur demandant l'arrêt de ce contrôleur.

Si une collaboration envoie une requête à un connecteur lorsque ce connecteur est en cours d'exécution mais que son application est en échec, la requête est renvoyée à la collaboration avec un état d'échec. Cette situation se produit uniquement lorsque la propriété du connecteur ControlStoreAndForwardMode est définie par false. La collaboration échoue et consigne l'un des messages suivants : 17050, 17058, 17059 ou 17060. Si vous recevez l'un de ces messages, vérifiez l'état de l'application.

Etat d'agent de connecteur inconnu

L'état de l'agent de connecteur est capital pour le système InterChange Server Express car il représente un point de départ pour les événements d'application. Un contrôleur de connecteur gère l'état de son agent de connecteur et transmet cette information à System Manager.

Le contrôleur de connecteur gère l'état de son agent de connecteur en envoyant des requêtes de réponse à l'agent toutes les 15 secondes.

Si l'agent de connecteur ne répond pas après trois vérifications consécutives, son état est considéré comme inconnu. Un état d'agent de connecteur inconnu peut signifier un échec de l'agent de connecteur ou, si l'agent de connecteur est installé sur le réseau, cet état peut signifier une interruption de la connexion réseau.

Lorsque vous définissez la propriété du connecteur ControllerStoreAndForwardMode par true, le contrôleur de connecteur attend que l'agent de connecteur démarre pour envoyer les événements en attente. Lorsque vous définissez cette propriété par false, les requêtes de collaboration sur le contrôleur de connecteur échouent. Les requêtes de collaboration en échec sont placées dans la file d'attente de nouvelle soumission et peuvent être soumises à nouveau à l'aide de Flow Manager. Pour plus d'informations, voir Echecs de flux.

Remarque :
Les collaborations basées sur un agent dont l'état est inconnu peuvent cesser de répondre si la propriété ControllerStoreAndForwardMode est définie par true. Les collaborations ne répondent plus jusqu'à ce que l'agent de connecteur soit redémarré et réponde aux requêtes de collaboration.

Lorsque vous sélectionnez l'option Mettre en attente lorsqu'une erreur grave se produit pour les collaborations associées, les collaborations liées à ce connecteur se mettent en pause dès la réception de l'état inconnu de l'agent de connecteur. Un message d'erreur est consigné et un courrier électronique est envoyé si e-Mail Connector est configuré.

Echecs de connexion à la base de données

Lorsqu'InterChange Server Express requiert une connexion à la base de données pour l'un de ses services mais que le nombre maximal de connexions est utilisé, le serveur tente de libérer une connexion inactive. Si le serveur échoue, la tentative de connexion n'aboutit pas et InterChange Server Express consigne l'erreur 5010 : Impossible de trouver une connexion disponible dans la mémoire cache. Le nombre maximal de connexions valeur-connexions-max a été atteint.

Si vous avez défini une contrainte sur le nombre de connexions d'InterChange Server Express à l'aide du paramètre MAX_CONNECTIONS, vous devez contrôler les messages d'erreur 5010 car un échec de connexion peut entraîner des conséquences indésirables. Par exemple, lorsqu'InterChange Server Express ne peut pas obtenir de connexion pour son service de gestion des événements, il interrompt son exécution. Par défaut, cette contrainte est définie par un nombre de connexions illimité.

Les échecs de connexion indiquent que le nombre maximal de connexions allouées est insuffisant pour répondre aux besoins de la charge d'exécution. Si vous ne pouvez pas allouer davantage de connexions à InterChange Server Express dans la base de données en cours, envisagez le partitionnement de la charge de travail sur plusieurs bases de données.

Echecs de flux

Des échecs peuvent parfois se produire au niveau du système InterChange Server Express ou des applications associées. L'aboutissement du traitement des flux qui acheminent les données dans le système InterChange Server Express est capital, il est donc très important de maintenir la cohérence des données dans un environnement d'exécution. Les pannes système telles que les erreurs système, les erreurs de données et les erreurs graves peuvent causer l'échec du traitement des flux. Des fonctions intégrées au système InterChange Server Express vous permettent de traiter ces pannes système.

Une erreur de configuration du système, de définition d'un objet, une erreur spécifique d'une application ou de cohérence de données peuvent entraîner l'échec d'un flux lors de son traitement par le système InterChange Server Express. Des composants d'InterChange Server Express qui ne fonctionnent pas correctement, comme des erreurs de mappage d'objet métier ou l'indisponibilité d'un connecteur, peuvent générer des erreurs système qui, à leur tour, entraînent l'échec des flux. Les incohérences de données, telles qu'une violation d'isolement de données d'application pendant l'exécution d'une collaboration, génèrent des erreurs de données, lesquelles causent également l'échec des flux.

Si une erreur se produit lorsqu'un contrôleur de connecteur ou une collaboration traite un flux, ce dernier échoue et il est placé dans la file d'attente de nouvelle soumission d'événements. A ce stade, vous avez les choix suivants :

Pour plus d'instructions sur la résolution des flux en échec, voir Gestion des événements ayant échoué.

Présentation de l'échec des collaborations transactionnelles

Les erreurs système et de données peuvent entraîner l'échec d'une collaboration transactionnelle. Lorsque l'une de ces erreurs se produit, la collaboration tente une invalidation. Si l'invalidation des étapes de correction d'une collaboration échoue, la collaboration est mise "en attente de validation". Si une erreur se produit pendant la reprise d'exécution, la collaboration est placée dans une liste de collaborations transactionnelles ayant échoué, appartenant à la collaboration correspondante. Une collaboration transactionnelle ayant échoué est une collaboration dont les étapes de correction n'ont pas abouti.

Lorsqu'une collaboration transactionnelle échoue, vous devez la réparer. Vous pouvez traiter une collaboration transactionnelle en échec à l'aide Flow Manager. Pour plus d'instructions sur la résolution des collaborations transactionnelles en échec, voir Gestion des événements ayant échoué.

Procédure permettant d'empêcher la mise en pause des collaborations transactionnelles ayant échoué

Le comportement par défaut d'une collaboration transactionnelle ayant échoué est la mise en pause. Vous pouvez empêcher la mise en pause des collaborations transactionnelles ayant échoué en ajoutant la propriété PAUSE_ON_COMPENSATION_FAILURE au modèle de la collaboration et en modifiant le paramètre TRUE (par défaut) par FALSE.

Pour ajouter la nouvelle propriété et définir le paramètre par FALSE, appliquez la procédure suivante :

  1. Dans System Manager, cliquez deux fois sur le modèle de collaboration ayant échoué. Process Designer Express apparaît.
  2. Cliquez deux fois sur l'icône Définitions, sous Site Wrapper. La fenêtre Définitions de modèle apparaît dans le cadre de droite.
  3. Cliquez sur l'onglet Propriétés.
  4. Cliquez sur Ajouter. La boîte de dialogue Nom apparaît.
  5. Entrez PAUSE_ON_COMPENSATION_FAILURE dans la zone Nom, puis cliquez sur OK. La propriété PAUSE_ON_COMPENSATION_FAILURE apparaît sous le noeud Propriétés générales, dans le cadre de gauche.
  6. Sélectionnez PAUSE_ON_COMPENSATION_FAILURE dans le cadre de gauche, puis Booléen dans la liste Type de propriété.
  7. Sous Valeur, décochez la case Valeur par défaut dans la ligne True et sélectionnez la case Valeur par défaut dans la ligne False.
  8. Cliquez sur Appliquer.
  9. Fermez Process Designer Express.

Copyright IBM Corp. 2004, 2005