Les stratégies personnalisées vous permettent de définir des comportements non couverts par les stratégies OOTB. Ils peuvent également recréer et développer ces politiques OOTB. Les politiques personnalisées peuvent également servir des cas d’utilisation métier spécifiques, tels qu’une authentification supplémentaire, des réponses personnalisées, etc.
Toute information que vous souhaitez traiter, ajouter ou supprimer sur la couche entrante ou sortante peut être effectuée avec des politiques personnalisées.
Ce didacticiel développera le didacticiel en utilisant l’archétype maven fourni par MuleSoft.
*Remarque : Ce didacticiel commencera là où se termine le didacticiel ci-dessus, c’est-à-dire que vous devriez déjà avoir le projet de modèle dans votre espace de travail !
Jetons un coup d’œil à notre cas d’utilisation de politiques personnalisées :
- Toutes les requêtes entrant dans cette API doivent avoir un en-tête nommé X-CALLBACK-URL
- La politique doit rejeter toutes les demandes qui ne contiennent pas cet en-tête, avec un code d’état 400 et la possibilité de définir un message personnalisé.
Vous pensez peut-être : « Cela n’est-il pas normalement fait dans l’application ? » et vous auriez raison, mais il y a quelques inconvénients. Le plus important est la réutilisation. Préférez-vous appliquer une politique à une API ou avoir le même code, la gestion des erreurs et les mêmes dépendances dans chacune de vos applications ? Pour moi, une politique est un moyen cohérent et simple de gérer ce type de cas d’utilisation (demande de validation).
La première chose à savoir sur la création de politiques personnalisées est qu’elle ne suit pas nécessairement la même syntaxe qu’une application mule classique. Bien que vous puissiez utiliser des composants trouvés dans une application MuleSoft, ce didacticiel couvrira les composants spécifiques à la politique. Il n’y a pas de glisser-déposer et les politiques sont créées directement en XML. Cela peut sembler étrange et inconnu, mais ne vous laissez pas intimider !
Pour commencer, nous allons configurer notre proxy de politique HTTP de base ; il s’agit de la pierre angulaire de notre politique personnalisée. Vous pouvez en savoir plus à ce sujet dans la documentation MuleSoft.
<http-policy:proxy name="callbackurl-policy-demo">
<http-policy:source>
<http-policy:execute-next/>
</http-policy:source>
</http-policy:proxy>L’extrait de code ci-dessus ne fait encore rien ; pour faire simple, nous avons une politique qui continue la chaîne d’exécution de l’événement (en fait l’envoi de la requête à l’application).
Pour ajouter notre fonctionnalité, nous pouvons ajouter dans notre module de validation qui vérifie qu’il existe et qu’il s’agit d’une URL valide :
<http-policy:proxy name="callbackurl-policy-demo">
<http-policy:source>
<choice>
<!-- Validate that X-CALLBACK_URL is not null or empty -->
<when
expression="#[ !isEmpty(attributes.headers.'X-CALLBACK-URL' default '')]">
<!-- Validate that X-CALLBACK-URL is a valid URL -->
<try>
<validation:is-url url="#[attributes.headers.'X-CALLBACK-URL']" />
<!-- If X-CALLBACK-URL is a valid URL continue the execution chain -->
<http-policy:execute-next />
<!-- If X-CALLBACK-URL was not valid, we never call execute next so our response in the error handler is sent back to the client-->
<error-handler>
<on-error-continue>
<http-transform:set-response
statusCode="#[400]">
<http-transform:body>#[ 'X-CALLBACK-URL value was not a valid URL' ]</http-transform:body>
</http-transform:set-response>
</on-error-continue>
</error-handler>
</try>
</when>
<otherwise>
<!-- Log value of the header -->
<logger
message="Avoiding execution; no callback url was provided.\nX-CALLBACK-URL: #[attributes.headers.'X-CALLBACK-URL']" />
</otherwise>
</choice>
</http-policy:source>
</http-policy:proxy>Nous utilisons:
<when expression="#[ !isEmpty(attributes.headers.'X-CALLBACK-URL' default '')]">
Pour vérifier que notre en-tête n’est pas nul ou vide.
Nous utilisons ensuite notre bloc try avec le module de validation d’URL pour vérifier qu’il s’agit d’une URL valide. Nous utilisons le module de transformation HTTP pour renvoyer une erreur 400 à notre utilisateur.
Notre dernière étape consiste à inclure notre exigence de pouvoir définir une charge utile personnalisée. Nous modifierons le fichier YAML pour inclure une charge utile personnalisée dans l’interface utilisateur du gestionnaire d’API lorsque vous l’appliquerez. Il va extraire la valeur définie dans API Manager dans notre application. La syntaxe est étrange et inconnue, mais c’est la manière dont les guides MuleSoft utilisent (je préférerais utiliser un routeur de choix, mais cela fonctionne aussi):
Notre YAML :
id: callbackurl-policy-demo
name: callbackurl-policy-demo
description: this is a policy demo
category: Custom
type: custom
resourceLevelSupported: true
encryptionSupported: false
standalone: true
requiredCharacteristics: []
providedCharacteristics: []
configuration:
- propertyName: payload
name: Payload
type: expression
description: Payload when X-CALLBACK-URL is not provided (a default is provided if this is left blank)
optional: true
sensitive: false
allowMultiple: false
Extraction de la propriété de charge utile que nous avons définie dans l’application :
<http-policy:proxy name="callbackurl-policy-demo">
<http-policy:source>
<choice>
<!-- Validate that X-CALLBACK_URL is not null or empty -->
<when
expression="#[ !isEmpty(attributes.headers.'X-CALLBACK-URL' default '')]">
<!-- Validate that X-CALLBACK-URL is a valid URL -->
<try>
<validation:is-url url="#[attributes.headers.'X-CALLBACK-URL']" />
<!-- If X-CALLBACK-URL is a valid URL continue the execution chain -->
<http-policy:execute-next />
<!-- If X-CALLBACK-URL was not valid, we never call execute next so our response in the error handler is sent back to the client-->
<error-handler>
<on-error-continue>
<http-transform:set-response
statusCode="#[400]">
<http-transform:body>#[ 'X-CALLBACK-URL value was not a valid URL' ]</http-transform:body>
</http-transform:set-response>
</on-error-continue>
</error-handler>
</try>
</when>
<otherwise>
<!-- Log value of the header -->
<logger
message="Avoiding execution; no callback url was provided.\nX-CALLBACK-URL: #[attributes.headers.'X-CALLBACK-URL']" />
{{#if payload}}
<!-- Set response defined in API manager -->
<http-transform:set-response
statusCode="#[400]">
<http-transform:body>{{{payload}}}</http-transform:body>
</http-transform:set-response>
{{else}}
<!-- Set default response -->
<http-transform:set-response
statusCode="#[400]">
<http-transform:body>#[ 'Please provide the callback url, X-CALLBACK-URL, in the request headers' ]</http-transform:body>
</http-transform:set-response>
{{/if}}
</otherwise>
</choice>
</http-policy:source>
</http-policy:proxy>Nous utilisons à nouveau le module de transformation HTTP pour renvoyer une réponse par défaut lorsqu’elle n’est pas définie dans le gestionnaire d’API.
La syntaxe de {{#if payload}} n’est pas familière, mais cela fonctionne et extrait les valeurs définies dans le gestionnaire d’API.
Notre prochaine étape consiste à connecter cette politique à l’échange.
Une fois cette politique déployée, nous pouvons appliquer cette politique à n’importe quelle API dans le gestionnaire d’API !
Et c’est tout ce dont nous avons besoin pour notre politique personnalisée ! Vous pouvez trouver le code complet ci-dessous :
<?xml version="1.0" encoding="UTF-8"?>
<mule
xmlns:validation="http://www.mulesoft.org/schema/mule/validation"
xmlns:ee="http://www.mulesoft.org/schema/mule/ee/core"
xmlns="http://www.mulesoft.org/schema/mule/core"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:http-policy="http://www.mulesoft.org/schema/mule/http-policy"
xmlns:http-transform="http://www.mulesoft.org/schema/mule/http-policy-transform"
xsi:schemaLocation="
http://www.mulesoft.org/schema/mule/validation http://www.mulesoft.org/schema/mule/validation/current/mule-validation.xsd
http://www.mulesoft.org/schema/mule/ee/core http://www.mulesoft.org/schema/mule/ee/core/current/mule-ee.xsd http://www.mulesoft.org/schema/mule/core http://www.mulesoft.org/schema/mule/core/current/mule.xsd
http://www.mulesoft.org/schema/mule/http-policy http://www.mulesoft.org/schema/mule/http-policy/current/mule-http-policy.xsd
http://www.mulesoft.org/schema/mule/http-policy-transform http://www.mulesoft.org/schema/mule/http-policy-transform/current/mule-http-policy-transform.xsd">
<validation:config name="Validation_Config"/>
<http-policy:proxy name="callbackurl-policy-demo">
<http-policy:source>
<choice>
<!-- Validate that X-CALLBACK_URL is not null or empty -->
<when
expression="#[ !isEmpty(attributes.headers.'X-CALLBACK-URL' default '')]">
<!-- Validate that X-CALLBACK-URL is a valid URL -->
<try>
<validation:is-url url="#[attributes.headers.'X-CALLBACK-URL']" />
<!-- If X-CALLBACK-URL is a valid URL continue the execution chain -->
<http-policy:execute-next />
<!-- If X-CALLBACK-URL was not valid, we never call execute next so our response in the error handler is sent back to the client-->
<error-handler>
<on-error-continue>
<http-transform:set-response
statusCode="#[400]">
<http-transform:body>#[ 'X-CALLBACK-URL value was not a valid URL' ]</http-transform:body>
</http-transform:set-response>
</on-error-continue>
</error-handler>
</try>
</when>
<otherwise>
<!-- Log value of the header -->
<logger
message="Avoiding execution; no callback url was provided.\nX-CALLBACK-URL: #[attributes.headers.'X-CALLBACK-URL']" />
{{#if payload}}
<!-- Set response defined in API manager -->
<http-transform:set-response
statusCode="#[400]">
<http-transform:body>{{{payload}}}</http-transform:body>
</http-transform:set-response>
{{else}}
<!-- Set default response -->
<http-transform:set-response
statusCode="#[400]">
<http-transform:body>#[ 'Please provide the callback url, X-CALLBACK-URL, in the request headers' ]</http-transform:body>
</http-transform:set-response>
{{/if}}
</otherwise>
</choice>
</http-policy:source>
</http-policy:proxy>
</mule>
Dans ce guide, nous avons examiné un cas d’utilisation pour…