L’exemple que nous allons étudier aujourd’hui est qu’un Client envoie une requête à un backend via un middleware, Enterprise Integrator ou EI. Au milieu du processus vers l’Enterprise Integrator, un problème apparaît et une réponse d’erreur est envoyée au client. Pour ce faire, un médiateur makefault est la meilleure option. Cela génère une erreur SOAP personnalisée en modifiant l’adresse du message, dans cet exemple en tant que message de réponse. L’adresse change grâce à la propriété de l’en-tête TO qui indique où le message est envoyé.
Aux points 2, 3, 4 et 5, nous parlons respectivement des exemples 1 et 2, en nous référant au schéma joint à ces mêmes points.
1.Médiateur Makefault
Avec Fault Mediator, que l’on peut aussi appeler Médiateur Makefault, le message en cours se transforme en un message d’erreur qui est renvoyé au client. Après ce médiateur, un Médiateur Send est nécessaire pour répondre au client avec le message d’échec, Fault Mediator n’envoie pas la réponse au client par défaut. La demande d’origine provenant du client peut avoir un en-tête Fault-To dont le contenu est utilisé dans l’en-tête TO du message de réponse d’erreur, comme je l’ai dit uniquement si Fault-To existe dans la demande d’origine. Le message d’erreur peut être créé à l’aide de SOAP 1.1, SOAP 1.2 ou Simple XML (POX).
Example:
<makefault version=”soap12”>
<code xmlns:tns="http://www.w3.org/2003/05/soap-envelope" value="tns:Receiver"/>
<reason expression="get-property('ERROR_MESSAGE')"/>
</makefault>
Le code est renvoyé par le message d’erreur. De cette façon, vous spécifiez le message d’échec pour les erreurs côté serveur, c’est-à-dire les erreurs liées au serveur:
<code xmlns:tns="http://www.w3.org/2003/05/soap-envelope" value="tns:Receiver"/>
Le message d’erreur est spécifié en tant qu’expression. La propriété ERROR_MESSAGE peut être modifiée avec un message d’erreur personnalisé.
<reason expression="get-property('ERROR_MESSAGE')"/>
Remarque:
tns:Receiver - Pour les erreurs côté serveur. tns:Sender - Pour les erreurs côté Client.
2. Configuration de l’exemple 1 de l’Enterprise Integrator avec MSFT.
Tout ce code est déployé dans l’EI. La demande du côté client passe par la séquence principale (main sequence). Dans cette séquence, si une erreur se produit, la séquence myFaultHandler gère l’erreur, comme indiqué par onError dans la séquence principale. Maintenant, le message va au médiateur IN. Il existe un médiateur switch qui recherche la valeur du symbol dans la demande. Il peut avoir deux valeurs MSFT ou SUN. Si la valeur correspond à MSFT, le message est envoyé vers un endpoint dont le nom est écrit de mauvaise façon. Alors que si la valeur est SUN, la demande est envoyée au bon endpoint sur localhost.
Lorsque l’erreur survient, c’est-à- dire lorsque le message est envoyé au endpoint dont le nom est écrit de mauvaise façon, une erreur est renvoyée. Cet événement d’erreur est intercepté par la séquence myFaultHandler qui traite le message. Dans cette séquence, il y a un médiateur makefault qui génère un message d’erreur SOAP. La propriété RESPONSE est définie sur ‘true’ après le médiateur makefault. Cela indique à l’EI de changer la direction des messages pour
« répondre » lorsque les messages deviennent une erreur SOAP. La valeur de ReplyTo : http://www.w3.org/2005/08/addressing/anonymous, ça signifie que la réponse est envoyée au Client qui a envoyé la demande.
Code:
<definitions xmlns="http://ws.apache.org/ns/synapse">
<sequence name="myFaultHandler">
<makefault response="true">
<code xmlns:tns="http://www.w3.org/2003/05/soap-envelope" value="tns:Receiver"/>
<reason expression="get-property('ERROR_MESSAGE')"/>
</makefault>
<property name=”RESPONSE” value=”true”/>
<header name=”To” expression=”get-property(‘ReplayTo’)”/>
<send/>
</sequence>
<sequence name="main" onError="myFaultHandler">
<in>
<switch xmlns:m0="http://services.samples" source="//m0:getQuote/m0:request/m0:symbol">
<case regex="MSFT">
<send>
<endpoint>
<address uri="http://bogus:9000/services/NonExistentStockQuoteService"/>
</endpoint>
</send>
</case>
<case regex="SUN">
<send>
<endpoint>
<address uri="http://localhost:9009/services/NonExistentStockQuoteService"/>
</endpoint>
</send>
</case>
</switch>
<drop/>
</in>
<out>
<send/>
</out>
</sequence>
</definitions>
3. Exécution de l’exemple 1 de l’Enterprise Integrator avec MSFT.
Pour exécuter cet exemple, démarrez le serveur Axis2 avec le service backend SimpleStockQuoteService. Il y a une explication de la façon de le faire dans le premier blog dédié à l’ESB. D’autre part, le client utilisé pour envoyer les demandes est le Client Cotation boursière. SOAPUI peut également être utilisé pour envoyer des requêtes à EI. Le client envoie une demande de cotation boursière avec le symbole MSFT, celui avec le mauvais point de terminaison, et le backend répond avec une réponse d’hôte inconnue.
EI détecte l’erreur et génère un message d’erreur, réponse d’erreur SOAP, qui est envoyé au client. Si le client envoie une autre demande, le backend répond avec une exception de rejet de connexion en tant qu’autre réponse d’échec SOAP. Pour envoyer une demande d’actions MSFT à l ‘EI, exécutez la commande suivante à partir du répertoire <ESB_HOME>/samples/axis2Client.
Request: ant stockquote -Daddurl=http://localhost:9000/services/SimpleStockQuoteService -Dtrpurl=http://localhost:8280/
-Dsymbol=MSFT
Il s’agit de la demande ou request en anglais envoyée par le client (SOAPUI ou Stock Quote Client) :
Réponse de l’EI :
Une exception de rejet de connexion serait levée pour la demande de stock SUN. Exécutez la commande suivante à partir du répertoire <ESB_HOME> / samples/axis2Client pour déclencher une demande de cotation boursière SUN au service backend.
Demande ou Request:
ant stockquote -Daddurl=http://localhost:9000/services/SimpleStockQuoteService -Dtrpurl=http://localhost:8280/ -Dsymbol=SUN
C’est la requête qui est envoyée à l’EI et peut également être utilisée avec SOAPUI.
Réponse de l’EI :
4. Configuration de l’exemple 2 de l’Enterprise Integrator à l’aide du fichier WSDL.
Le client envoie la demande via un proxy. inSequence traite la demande. Il existe un médiateur log qui affiche le type de contenu du message qui est une propriété qui se déplace au niveau du transport du message. Ensuite, il y a un médiateur filter. Si le type de contenu du message n’est pas text/xml, il renvoie un message d’erreur envoyé au client. Sinon, envoyez le message à un point de terminaison. Dans cette partie du médiateur filter, il existe un autre médiateur log pour afficher le type de contenu et un message d’erreur indiquant : type de contenu incorrect.
Le prochain médiateur est makefault. Cela génère un message d’erreur indiquant que l’erreur provient du côté client, soap11Env:client. Après cela, l’en-tête TO est supprimé, indiquant qu’il s’agit d’un message de demande. Parce que maintenant c’est un message de réponse de bogue. Et enfin, un médiateur send( médiateur pour envoyer) renvoie le message de réponse d’échec au client. D’autre part, outSequence redirige les réponses du backend vers le côté client. PublishWSDL publie le fichier WSDL.
Code:
<proxy xmlns="http://ws.apache.org/ns/synapse" name="CheckContentType" transports="https http" startOnLoad="true" trace="disable">
<description/>
<target>
<inSequence>
<log level="custom">
<property name="_______Content-Type" expression="get-property('transport','Content-Type')"/>
</log>
<filter source="get-property('transport','Content-Type')" regex="application/xhtml\+xml">
<then>
<log>
<property name="Content-Type" expression="get-property('transport','Content-Type')"/>
<property name="Decision" value="Exception, due to unexpected Content-Type."/>
</log>
<makefault version="soap11">
<code xmlns:soap11Env="http://schemas.xmlsoap.org/soap/envelope/" value="soap11Env:Client"/>
<reason value="Content-Type Error"/>
<role/>
<detail>Content-Type: application/xhtml+xml is not a valid content type.</detail>
</makefault>
<header name="To" scope="default" action="remove"/>
<send/>
</then>
<else>
<log>
<property name="Content-Type" expression="get-property('transport','Content-Type')"/>
<property name="Decision" value="Continue the mediation flow..."/>
</log>
<send>
<endpoint>
<address uri="http://localhost:9000/services/SimpleStockQuoteService"/>
</endpoint>
</send>
</else>
</filter>
</inSequence>
<outSequence>
<send/>
</outSequence>
</target>
<publishWSDL uri="http://localhost:9000/services/SimpleStockQuoteService?wsdl"/>
</proxy>
5. Exécution de l’exemple 2 de l’Enterprise Integrator à l’aide du fichier WSDL.
Nous pouvons utiliser le fichier WSDL publié par le proxy pour générer des requêtes client. Pour ce faire, importez ce fichier WSDL dans SOAPUI, par exemple, en utilisant l’URL qui contient le proxy et ajoutez “? WSDL” à la fin de l’URL, comme indiqué en haut de l’image suivante. Le proxy nous publie les méthodes utilisées par le service. Le contenu du fichier WSDL est également visible via un navigateur :
Le même URI est utilisé dans SOAPUI pour générer les requêtes ou demandes:
Ceci est un exemple de requête SOAP contre le service utilisant un type de contenu correct (texte/xml) :
Le message est envoyé au backend. Maintenant, je vais envoyer la même demande mais avec un type de contenu invalide (app/xhtml + xml):
Comme vous pouvez le voir, et selon la configuration de l’EI, un message de panne/erreur est envoyé au client.
6. Conclusion
Comme cela a été montré, l’utilisation du médiateur de fautes gère la génération d’erreurs de message suivant les bonnes pratiques. Par contre, c’est très utile car l’utilisateur peut personnaliser le message d’erreur, en indiquant si l’erreur vient du côté serveur ou du côté client.
