Partager via

Exécution de l’exemple de gestionnaire d’exceptions personnalisé pour la réparation et le renvoi

  • Article

L’exemple De gestionnaire d’exceptions personnalisés de réparation et de soumission de nouveau illustre une technique extrêmement efficace pour intégrer l’intervention humaine dans les processus d’application basés sur ESB et Microsoft BizTalk, et implémente un modèle de conception utile. L’exemple de code s’intègre en toute transparence dans le système de gestion des exceptions ESB.

L’exemple montre comment utiliser un gestionnaire d’exceptions personnalisé dans une orchestration. Lorsqu’un processus de l’orchestration (EAIProcess.odx) rencontre une erreur, le gestionnaire d’exceptions génère et publie un message d’erreur ESB. Ce message d’erreur inclut dans sa charge utile les messages (y compris leurs propriétés de contexte liées à BizTalk) qui étaient « en cours d’exécution » lorsque l’exception s’est produite et que le System.Exception actuel instance intercepté par le moteur d’orchestration BizTalk. Dans ce cas, un message « Refusé » et un message « Approuvé » sont conservés avec le message d’erreur.

Une deuxième orchestration nommée EAIProcessHandler.odx, qui est déployée de manière découplée et qui agit comme un gestionnaire d’exceptions personnalisé, s’abonne au code d’erreur spécifique généré dans l’orchestration EAIProcess.odx et consomme le message d’erreur. Ce gestionnaire d’exceptions extrait les messages d’origine (sous forme de documents typés) et les instances System.Exception conservées à l’origine dans le message d’erreur.

Les messages d’origine sont désormais disponibles pour traitement avec toutes leurs propriétés de contexte d’origine. Le gestionnaire d’exceptions personnalisé (EAIProcessHandler.odx) écrit ensuite les messages « Refusé » et « Approuvé » dans le système de fichiers aux emplacements suivants :

  • Message approuvé :

    • \Source\Samples\Gestion des exceptions\Test\Filedrop\EAIProcess.PostApproval

  • Message refusé pour la réparation et le soumettre à nouveau :

    • \Source\Samples\Gestion des exceptions\Test\Filedrop\EAIProcessHandler.RepairSubmit

  • Message refusé :

    • \Source\Samples\Gestion des exceptions\Test\Filedrop\EAIProcessHandler.PostDecline

    Le gestionnaire d’exceptions sérialise le message « Refusé » pour réparer et soumettre à nouveau au système de fichiers à l’aide d’une instruction de traitement Microsoft InfoPath. Un modèle InfoPath permet à l’utilisateur de modifier le formulaire et de soumettre à nouveau le résultat (voir figure 1), ce qui démarre l’orchestration EAIProcess.odx qui valide le message.

    Réparer resubmit

    Figure 1

    Message de test généré par le modèle De réparation et de soumission d’InfoPath

    En outre, il existe un port d’envoi générique nommé ALL. Exceptions_FILE configuré pour utiliser le pipeline GlobalFaultProcessor. Ce port s’abonne à toutes les exceptions dans le système, les messages de routage de messages BizTalk ayant échoué et les messages d’erreur ESB. Le framework de gestion des exceptions les normalise tous dans un format unique et les sérialise à l’aide d’une instruction de traitement InfoPath dans le dossier \Source\Samples\Gestion des exceptions\Test\Filedrop\All_Exceptions.

Installation

Tous les exemples de gestion des exceptions utilisent le même ensemble de services principaux et d’artefacts d’application BizTalk. Par conséquent, vous ne devez installer les exemples d’artefacts de gestion des exceptions qu’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 gestionnaire d’exceptions personnalisées de réparation et de soumission de nouveau

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

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

  3. Démarrez l’exemple en copiant l’exemple de fichier nommé Request_EAIProcessHandler.xml, situé dans le dossier \Source\Samples\Exception Handling\Test\Data, vers le dossier spécifié pour l’emplacement de réception EAIProcess.RequestPort_FILE : \Source\Samples\Exception Handling\Test\Filedrop\EAIProcess.RequestPort.

  4. Ouvrez le dossier nommé EAIProcessHandler.PostDecline (dans le dossier \Source\Samples\Exception Handling\Test\Filedrop). Vous verrez le message « Refusé* » généré par l’orchestration de gestion des exceptions.

  5. Ouvrez le dossier nommé EAIProcessHandler.RepairSubmit (dans le dossier \Source\Samples\Exception Handling\Test\Filedrop). Vous verrez un message « RepairSubmit » généré par l’orchestration de gestion des exceptions.

  6. Double-cliquez sur le fichier RepairSubmit pour l’ouvrir dans le modèle InfoPath approprié. Vous verrez le message prêt pour la modification et la nouvelle soumission.

  7. Modifiez la valeur du champ Prix unitaire de 0 à 2, puis cliquez sur le bouton Envoyer situé dans la barre d’outils du formulaire InfoPath pour renvoyer le document modifié à BizTalk pour traitement. Le processus d’envoi utilise un emplacement de réception HTTP configuré pour BizTalk.

  8. Accédez au dossier EAIProcess.PostApproval (dans le dossier \Source\Samples\Exception Handling\Test\Filedrop). Vous voyez maintenant le document « Approbation* » contenant la valeur mise à jour pour le prix unitaire.

Fonctionnement de l’exemple

Le message que vous envoyez active l’orchestration EAIProcess. Lorsque l’orchestration EAIProcess traite le message, elle tente de diviser 1 par le prix unitaire. Étant donné que le prix unitaire est égal à zéro, une exception de division par zéro se produit. Le code dans le gestionnaire d’événements de l’orchestration intercepte cette exception et crée un message d’erreur. La quantité de commande dans le message est supérieure à 10, de sorte que la logique métier dicte que cette exception a une valeur de champ FaultCode de 1000.

L’orchestration EAIProcess publie ensuite le message d’erreur dans bizTalk Message Box via un port direct, et l’orchestration se termine.

Une orchestration de gestionnaire d’erreurs personnalisée nommée EAIProcessHandler, qui s’abonne aux messages avec une valeur de champ FaultCode de 1000, récupère le nouveau message d’erreur. Le code de l’orchestration crée le message « Refusé » et le fichier InfoPath, puis il le place dans les dossiers EAIProcessHandler.PostDecline et EAIProcessHandler.RepairSubmit prêts pour une intervention humaine.