Introduction à Windows Communication Foundation

Ce billet est le dernier de ma série d’articles d’introduction à Windows Communication Foundation. Vous pouvez lire les 4 précédents via cette page.

Ici, nous allons nous intéresser à un point que je n’ai volontairement pas abordé dans les articles précédents : la gestion des exceptions et des fautes SOAP.

Commençons par un cas simple, où le service va simplement définir une opération levant une exception.

Cas simple

Nous allons créer un service ExceptionService. Il mettra en jeu les différentes entités fondamentales de WCF, à savoir un contrat de service, une implémentation, une hôte et un client. Les deux dernières applications seront des applications console classique utilisant respectivement les classes ServiceHost et ChannelFactory.

Le contrat de service est lui très simple, puisqu’il ne définit qu’une seule méthode : ThrowException :

L’implémentation du service quant à elle redéfinie bien évidemment la méthode ThrowException est lève tout simplement une Exception:

Vous pourrez retrouver tout le code de cette mise en situation au base de cet article.

Notre client est très simple puisqu’il appel tout simplement la méthode ThrowException du service, au travers de l’instance de ChannelFactory.

Le service est exposé sur un endpoint ayant un binding de type BasicHttpBinding. Voyons le résultat d’exécution du client :

Vous pouvez constater ici que bien que ce soit une exception de type Exception qui soit levée dans la méthode ThrowException du service, notre client intercepte ici un autre type d’exception : FaultException. Quoi qu’il en soit, nous voyons qu’il y a bien une erreur côté serveur, mais nous n’avons aucun détail quant la nature de celle-ci.

Si nous plaçons un espion au niveau de l’exception levée dans le client WCF, nous pouvons voir qu’il ne s’agit bien évidemment pas d’une simple Exception mais d’une FaultException :

Définie dans l’espace de noms System.ServiceModel, FaultException est une exception permettant de représenter une faute SOAP. En effet, SOAP, le dérivée du XML utilisé pour transporter nos messages Windows Communication Foundation ne fonctionne pas comme un langage .NET avec un système d’exception. Voilà à quoi ressemble une faute SOAP :

Par défaut, le détail de la faute SOAP n’est pas en relation avec l’exception qui a réellement été levée et ce pour des raison de sécurité. Comme l’exception est envoyée côté client, il sera dangereux de donner trop de détails !

Cependant, en debug notamment, il peut être utile de connaître la nature de l’erreur qui s’est produit sur le serveur. Pour obtenir ce résultat, nous allons devoir redéfinir le comportement par défaut de notre service et lui ajouter une behavior de type serviceDebug afin d’inclure le détail dans la faute SOAP :

Dès lors, vous aurez accès aux détails de l’exception qui a été levée côté serveur, au niveau du client, comme le montre la capture ci-dessous :

Personnalisation des FaultException

Dans le cadre d’un projet, il est souvent utile de donner des informations aux clients de notre service, sans pour autant dévoiler tout le contenu de l’exception où même toutes les exceptions. Pour cela, le .NET Framework offre une version générique de la classe FaultException, elle aussi définie dans l’espace de noms System.ServiceModel.

Le type T de la classe FaultException est une classe sérialisable (un contrat de données) permettant d’obtenir plus d’informations sur l’erreur.

Ici, nous créeons un classe CustomFault ayant une propriété Reason représentant le détail de l’erreur à afficher :

Nous allons créer une nouvelle opération à notre service WCF, celle-ci sera chargée de lever une exception de type FaultException. Nous choisissons d’appeler cette méthode ThrowFaultException :

En voici l’implémentation :

Il reste une petite modification à apporter à notre contrat de service afin que l’exception de type FaultException puisse se propager via SOAP jusqu’au client : l’ajout de l’attribut FaultContractAttribute au dessus de la définition de l’opération ThrowFaultException. Défini dans l’espace de nom System.ServiceModel, cet attribut va nous permettre de spécifier au moteur WCF le type T des FaultException levées au sein de l’opération :

Dès lors, nous pouvons modifier le code de notre client afin qu’il affiche l’information dans le cas où une FaultException est levée sur le service WCF :

Et voici le résultat en exécution, nous obtenons bien le résultat escompté, à savoir une exception gérée par notre service WCF puisque ne dévoilant que les informations nécéssaires :

Je tiens à préciser ici que la directive qui nous permettait de propager le détail des exceptions en debug est cette fois ci évaluée à false et ce pour la sécurité d’exécution de notre service : seules les erreurs que nous souhaitons propager de manière détaillées le seront !

J’espère que ce billet vous aura permis de comprendre les bases de la gestion des exceptions en WCF et surtout comment faire transiter celles-ci via SOAP, base des échanges entre client et service WCF, sans trop exposer notre service à des vulnérabilités en faisant le choix de tout envoyer !

A bientôt