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
Perte de la connexion à l'application
Etat d'agent de connecteur inconnu
Echecs de connexion à la base de données
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.
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.
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.
La propriété RECOVERY_MODE comporte deux paramètres dont les effets sont les suivants, en cas d'échec et de reprise du serveur :
Les événements à l'état en cours d'exécution avant la panne du serveur passent à l'état Différé. Les événements de cette collaboration sont récupérés uniquement lorsque vous les soumettez à nouveau manuellement.
Les événements à l'état en cours d'exécution avant la panne du serveur sont récupérés. Les événements à l'état Différé restent différés jusqu'à ce que vous les soumettiez à nouveau.
La valeur par défaut est Toujours.
Pour définir la valeur du mode de reprise d'une collaboration, appliquez la procédure suivante :
La collaboration récupère tous les événements en cours dont l'état est en cours d'exécution, qu'elle possédait au moment de l'amorçage du serveur.
La collaboration passe l'événement en cours à l'état de reprise différée. Vous devez traiter ces événements ultérieurement, à l'aide de Flow Manager ou Failed Event Manager. Pour plus d'informations, voir Gestion des événements ayant échoué.
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.
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.
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.
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.
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é.
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.
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é.
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é.
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 :