Exceptions personnalisées
En cas d'erreur irrécupérable, la solution de gestion des processus d'entreprise utilise une combinaison de gestionnaires d'exception et d'exceptions personnalisées.
Gestion des exceptions
Au lieu d’utiliser des formes d’arrêt dans des orchestrations appelées, vous pouvez utiliser le modèle de levée d’exceptions gérées par l’orchestration racine. Ainsi, l'orchestration possédant la connaissance de contexte la plus étendue est en mesure de prendre une décision relative à la gestion de l'exception. Le fait que les orchestrations subordonnées lèvent des exceptions personnalisées permet de communiquer des informations plus spécifiques à l'orchestration racine.
La solution de gestion des processus d'entreprise suit ce modèle. Il existe quatre orchestrations racines ou non appelées dans la solution : OrderBroker, OrderManager, CableOrder1 et CableOrder2. Trois des orchestrations racines reçoivent et gèrent des exceptions personnalisées : OrderManager, CableOrder1 et CableOrder2.
Notez que certaines orchestrations racines utilisent la forme Terminate et que la forme Terminate apparaît juste avant le point de terminaison normal de l’orchestration. L’orchestration utilise toujours la forme Terminer en cas d’erreur afin que l’orchestration soit enregistrée comme terminée, plutôt que comme terminée, mais avec un message d’erreur. Ceci permet à la solution de suivre facilement les instances ayant échoué, en plus d'enregistrer l'erreur.
Pour plus d’informations sur la forme Terminate , consultez How to Configure the Terminate Shape. Pour plus d’informations sur la forme ThrowException , consultez How to Configure the Throw Exception Shape.
Exceptions personnalisées
Chacune des trois exceptions personnalisées suivantes suit le même modèle. Le fait d'avoir des types distincts permet au code de différencier les différentes exceptions.
| Exception | Levée par (Orchestration) |
|---|---|
| ActivateException | Changement |
| CableOrderException | Activate, CableOrder1 |
| InterruptException | CableOrder1, CheckInterrupt, ErrorHandlerOrch |
Toutes les exceptions personnalisées sont définies dans l’assembly Utilities . et appartiennent à la classe .NET. Toutes les classes d’exception personnalisées héritent de la classe ApplicationException .NET, qui hérite à son tour de la classe System.Exception . Comme il est possible que les exceptions puissent être mises en attente (sérialisées et stockées dans la base de données), elles doivent implémenter un constructeur de désérialisation. Un constructeur de désérialisation est un constructeur qui prend deux arguments : un objet SerializationInfo et un objet StreamingContext. Le constructeur de désérialisation est utilisé lors de la réactivation de l'exception. Étant donné que la classe ApplicationException implémente déjà un constructeur de désérialisation, le constructeur de l’exception personnalisée appelle simplement le constructeur de désérialisation de base (ApplicationException). Par exemple, l’exception InterruptException inclut le constructeur suivant :
// "info" is the object holding the serialized object data.
// "context" is the contextual information about the source
// or destination.
public InterruptException(SerializationInfo info,
StreamingContext context) : base(info, context) { }
Pour plus d’informations sur la sérialisation personnalisée, consultez Sérialisation personnalisée dans le Guide du développeur .NET Framework.
Gestionnaires d'exceptions imbriqués et blocs de compensation
Outre leur utilisation comme exceptions spécialisées, les exceptions personnalisées servent également d'indicateur de tri à plusieurs emplacements. Dans l’orchestration des modifications, l’opération Annuler doit être restaurée à deux endroits.
Notes
Vous pouvez lire cette section avec l’orchestration des modifications ouverte dans Visual Studio.
En haut de l’orchestration, si l’appel à l’orchestration Cancel échoue, le bloc CancelCompensation s’exécute et annule la transaction Cancel . Si tout se passe bien, l’orchestration appelle l’orchestration Activer .
Si l’opération Activate échoue, la transaction Cancel doit également être restaurée. Toutefois, le gestionnaire d’exceptions pour l’appel à Activate ne connaît rien de la transaction Cancel . Afin de gérer ce genre de situation, un gestionnaire d'exceptions est disponible pour l'intégralité de l'orchestration. Ce gestionnaire, parce qu’il contient l’étendue Cancel , connaît la transaction Cancel . Le gestionnaire intercepte l’exception levée à partir de l’étendue Activate ( ActivateException), annule la transaction Cancel , puis lève à nouveau l’exception afin que l’orchestration qui a appelé l’orchestration de modification puisse effectuer tout traitement supplémentaire.
Notez que cette conception ne compense l’annulation qu’en cas d’échec de l’activation . Si l’opération Cancel échoue et lève une exception, l’annulation n’a jamais eu lieu et ne doit pas être compensée.
Pour plus d’informations sur les blocs de compensation et la forme Compenser , consultez Guide pratique pour configurer la forme de compensation.
Voir aussi
Gestion des exceptions dans la solution de gestion des processus d’entreprise
Orchestration ExceptionHandler