Partager via

Exécution de l’exemple de traitement ESB du routage des messages BizTalk en échec

  • Article

L’exemple de traitement ESB du routage des messages ayant échoué de Microsoft BizTalk montre comment utiliser l’infrastructure de gestion des exceptions microsoft BizTalk ESB Toolkit comme mécanisme universel pour gérer, sérialiser et afficher les exceptions qui se produisent dans toutes les conditions dans BizTalk Server. Cela inclut les exceptions générées par le mécanisme de routage des messages ayant échoué bizTalk et les messages d’erreur générés par l’infrastructure de gestion des exceptions à partir d’une orchestration.

Le mécanisme de routage des messages ayant échoué dans BizTalk est la fonctionnalité de gestion des erreurs de BizTalk Server ; en l’utilisant, le concepteur peut désigner la gestion automatisée des échecs de messagerie comme alternative au comportement traditionnel (désormais par défaut) qui consiste à placer les messages ayant échoué dans la file d’attente « Suspendu ». Cette gestion automatisée achemine un message d’erreur vers n’importe quelle destination de routage d’abonnement, telle qu’un port d’envoi ou une orchestration. Le message d’erreur est un clone du message d’origine avec toutes les propriétés précédemment promues rétrogradées et avec les propriétés sélectionnées liées à l’échec de messagerie spécifique promues dans le contexte du message.

Pour activer le mécanisme de routage des messages ayant échoué bizTalk sur un port de réception ou un port d’envoi, sélectionnez la zone Activer le routage des messages ayant échoué case activée, comme illustré dans la figure 1.

Routage activé

Figure 1

Activation du mécanisme de routage des messages ayant échoué BizTalk

Toutefois, il n’existe pas de mécanisme similaire pour les erreurs ou les défaillances qui se produisent dans une orchestration. Au lieu de cela, le code dans le gestionnaire d’exceptions d’une orchestration peut tirer parti de l’API Du framework de gestion des exceptions pour émuler les fonctionnalités du mécanisme de routage des messages bizTalk ayant échoué.

Dans cet exemple, l’emplacement de réception nommé EAIProcess.RequestPort_FILE récupère les fichiers copiés à l’emplacement \Source\Samples\Exception Handling\Test\Filedrop\EAIProcess.RequestPort.

En outre, il existe un port d’envoi générique nommé ALL. Exceptions_FILE configuré pour utiliser le pipeline GlobalFaultProcessor installé dans le cadre de l’infrastructure de gestion des exceptions. Ce port s’abonne à toutes les exceptions qui se produisent dans le système, à la fois les messages de routage de messages bizTalk ayant échoué et les messages d’erreur ESB, comme illustré dans la figure 2.

Envoyer le port

Figure 2

The ALL. Les exceptions envoient un abonnement au port pour tous les types d’échec ou d’exception

L’infrastructure de gestion des exceptions normalise toutes les exceptions dans un format unique et les sérialise à l’aide d’une instruction de traitement Microsoft InfoPath à l’emplacement \Source\Samples\Gestion des exceptions\Test\Filedrop\All_Exceptions.

Installation

Tous les exemples de gestion des exceptions utilisent le même ensemble de services de base et d’artefacts d’application BizTalk. Par conséquent, vous devez installer les artefacts d’exemples de gestion des exceptions une seule fois pour pouvoir exécuter tous les exemples de gestion des exceptions. Pour plus d’informations sur l’installation des exemples de gestion des exceptions, consultez Installation des exemples de gestion des exceptions.

Exécution de l'exemple d'application

Pour exécuter l’exemple de traitement ESB du routage des messages bizTalk ayant échoué

  1. Avant d’exécuter cet exemple pour la première fois, assurez-vous que l’emplacement de réception et l’URL de port d’envoi pointent vers les répertoires appropriés dans le dossier \Source\Samples\Gestion des exceptions\Test\Filedrop. L’emplacement de réception doit spécifier le dossier EAIProcess.RequestPort, et l’URL du port d’envoi doit spécifier le dossier All_Exceptions.

  2. Si l’application GlobalBank.ESB n’est pas déjà en cours d’exécution, utilisez la console d’administration BizTalk pour la démarrer.

  3. Copiez le fichier nommé FlatFileReceive_in.txt du dossier \Source\Samples\Exception Handling\Test\Data dans le dossier d’emplacement de réception nommé EAIProcess.RequestPort (dans le dossier \Source\Samples\Exception Handling\Test\Filedrop).

  4. Ce message est un fichier texte qui provoque une exception. Ouvrez le dossier nommé All_Exceptions (dans le dossier \Source\Samples\Exception Handling\Test\Filedrop), puis double-cliquez sur le message d’erreur pour l’ouvrir dans InfoPath à l’aide du modèle approprié. Vous verrez que le mécanisme de gestion des exceptions ESB sérialise le contenu de manière appropriée pour permettre à InfoPath de le restituer.

  5. Ensuite, copiez le fichier nommé soapmessage[1].xml du dossier \Source\Samples\Exception Handling\Test\Data dans le dossier d’emplacement de réception EAIProcess.RequestPort.

  6. Ce message est un document XML qui contient une section CDATA et provoque une exception. Ouvrez le dossier de sortie All_Exceptions et double-cliquez sur le message d’erreur pour l’ouvrir dans InfoPath. Vous verrez que le mécanisme de gestion des exceptions ESB sérialise ce contenu de manière appropriée pour permettre à InfoPath de le restituer.

  7. Enfin, copiez le fichier nommé Csqzav01.pdf du dossier \Source\Samples\Exception Handling\Test\Data dans l’emplacement de réception EAIProcess.RequestPort.

  8. Ce message est un fichier PDF qui provoque une exception. Ouvrez le dossier de sortie All_Exceptions et double-cliquez sur le message d’erreur pour l’ouvrir dans InfoPath. Vous verrez que le mécanisme de gestion des exceptions ESB sérialise et encode en base 64 le contenu pour permettre à InfoPath de le restituer.