<ph type="x-smartling-placeholder"></ph>
Vous consultez la documentation Apigee Edge.
Accédez à la page
Documentation sur Apigee X. En savoir plus
Quoi
La règle ExtractVariables extrait le contenu d'une requête ou d'une réponse, et définit la valeur d'une variable sur ce contenu. Vous pouvez extraire n'importe quelle partie du message, y compris les en-têtes, les chemins d'URI, les charges utiles JSON/XML, les paramètres de formulaire et les paramètres de requête. Lorsqu'elle est exécutée, la règle applique un modèle de texte au contenu du message et, lors de la recherche d'une correspondance, définit une variable avec le contenu du message spécifié.
Cette règle sert souvent à extraire des informations d'une requête ou d'un message de réponse, mais vous pouvez également l'utiliser pour extraire des informations d'autres sources, y compris des entités créées par la règle AccessEntity, des objets XML ou des objets JSON.
Après avoir extrait le contenu du message spécifié, vous pouvez référencer la variable dans d'autres règles lors du traitement d'une requête et d'une réponse.
Vidéos
Regardez les vidéos suivantes pour en savoir plus sur la règle ExtractVariables.
Vidéo | Description |
---|---|
Extraire des variables de la charge utile XML | Extrayez des variables d'une charge utile XML à l'aide de la règle Extract Variables. |
Extraire des variables de la charge utile JSON | Extraire les variables d'une charge utile JSON à l'aide de la règle Extract Variables. |
Extraire des variables de paramètres | Extraire des variables de paramètres, tels que les paramètres de requête, d'en-tête, de formulaire ou d'URI. |
Extraire des variables de paramètres à valeurs multiples | Extraire des variables de paramètres à valeurs multiples. |
Extraire des variables à partir du paramètre de requête (Classic Edge) | Extrayez des variables d'un paramètre de requête à l'aide de l'interface utilisateur Classic Edge. |
Extraire des variables à partir de la charge utile XML ou JSON (Classic Edge) | Extrayez des variables à partir d'une charge utile XML ou JSON à l'aide de l'interface utilisateur Classic Edge. |
Exemples
Ces exemples de code de règles montrent comment extraire des variables des types d'artefacts suivants :
GitHub
<ph type="x-smartling-placeholder">Ces liens pointent vers des exemples de proxy d'API fonctionnels que vous pouvez déployer et exécuter sur Edge. Ils utilisent ExtractVariables et se trouvent dans le dépôt api-platform-samples d'Apigee sur GitHub. Les fichiers README expliquent comment ExtractVariables est utilisé dans chaque cas, et comment déployer et exécuter chaque exemple.
- Extraction et attribuer des exemples de variables (extraire des données à partir de messages JSON et XML)
- Accès exemple d'entité
- Pagination et un exemple de mise en cache
- Recalculer l'itinéraire exemple d'URL cible
- Échantillon d'application composite de composition de règles
URI
<ExtractVariables name="ExtractVariables-1"> <DisplayName>Extract a portion of the url path</DisplayName> <Source>request</Source> <URIPath> <Pattern ignoreCase="true">/accounts/{id}</Pattern> </URIPath> <VariablePrefix>urirequest</VariablePrefix> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </ExtractVariables>
Prenons l'exemple de code de règle ci-dessus. L'élément <URIPath>
indique à la règle
ExtractVariables d'extraire des informations du chemin d'URI. L'élément <Pattern>
spécifie le modèle à appliquer au chemin d'URI. Le modèle est traité comme un format simple, les accolades représentant la partie variable du chemin d'URI.
Le nom de la variable à définir est déterminé par la valeur spécifiée dans l'élément <VariablePrefix>
, ainsi que la valeur placée entre accolades {} dans l'élément <Pattern>
. Les deux valeurs sont jointes par un point intermédiaire, ce qui donne un nom de variable tel que urirequest.id
. Si aucun élément <VariablePrefix>
n'est présent, le nom de la variable correspond simplement à la valeur indiquée entre accolades.
Prenons l'exemple de code de règle ci-dessus, qui fonctionne avec la requête entrante suivante :
GET http://org1-test.apigee.net/svc1/accounts/12797282
Supposons que le chemin de base du proxy d'API soit /svc1
. Lorsque Apigee Edge applique la
ExtractVariables ci-dessus à cette requête entrante, il définit la variable
De urirequest.id
à 12797282
. Après avoir exécuté la stratégie, Apigee Edge
les stratégies ou le code ultérieurs du flux de traitement peuvent faire référence à la variable nommée
urirequest.id
pour obtenir la valeur de chaîne 12797282
.
Par exemple, la règle Assign Message suivante intègre la valeur de cette variable dans la charge utile d'un nouveau message de requête :
<AssignMessage async="false" continueOnError="false" enabled="true" name="AssignPayload"> <DisplayName>AssignPayload</DisplayName> <Set> <Payload contentType="text/xml"> <IdExtractedFromURI>{urirequest.id}</IdExtractedFromURI> </Payload> </Set> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> <AssignTo createNew="true" transport="http" type="request">newRequest</AssignTo> </AssignMessage>
Paramètres de requête
<ExtractVariables name="ExtractVariables-2"> <DisplayName>Extract a value from a query parameter</DisplayName> <Source>request</Source> <QueryParam name="code"> <Pattern ignoreCase="true">DBN{dbncode}</Pattern> </QueryParam> <VariablePrefix>queryinfo</VariablePrefix> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </ExtractVariables>
Prenons l'exemple de code de règle ci-dessus, qui fonctionne avec la requête entrante suivante :
GET http://org1-test.apigee.net/accounts/12797282?code=DBN88271
Quand Apigee Edge applique le code de stratégie ExtractVariables ci-dessus à cette demande entrante,
la variable queryinfo.dbncode
est définie sur 88271
. Après Apigee Edge
exécute la stratégie, les stratégies ou le code ultérieurs du flux de traitement peuvent faire référence à
nommée queryinfo.dbncode
pour obtenir la valeur de chaîne 88271
.
Vous pouvez maintenant accéder à la variable queryinfo.dbncode
dans votre proxy.
Par exemple, la stratégie AffectMessage suivante le copie dans la charge utile de la requête:
<AssignMessage async="false" continueOnError="false" enabled="true" name="GetURIPath"> <DisplayName>GetQP</DisplayName> <Set> <Payload contentType="text/xml"> <ExtractQP>{queryinfo.dbncode}</ExtractQP> </Payload> </Set> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> <AssignTo createNew="false" transport="http" type="request"/> </AssignMessage>
Paramètres multiples
<ExtractVariables name="ExtractVariables-2"> <DisplayName>Extract a value from a query parameter</DisplayName> <Source>request</Source> <QueryParam name="w"> <Pattern ignoreCase="true">{firstWeather}</Pattern> </QueryParam> <QueryParam name="w.2"> <Pattern ignoreCase="true">{secondWeather}</Pattern> </QueryParam> <VariablePrefix>queryinfo</VariablePrefix> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </ExtractVariables>
Supposons que la conception de votre API vous permette de spécifier plusieurs paramètres de requête portant le même nom. Vous pouvez utiliser cette stratégie pour extraire la valeur de plusieurs instances de la requête "w". Pour référencer ces paramètres de requête dans la règle ExtractVariables, vous Utilisez des index, où la première instance du paramètre de requête n'a pas d'index, la seconde à l'emplacement l'index 2, le troisième à l'index 3, etc.
Prenons l'exemple de code de règle ci-dessus, qui fonctionne avec la requête entrante suivante :
GET http://org1-test.apigee.net/weather?w=Boston&w=Chicago
Quand Apigee Edge applique le code de stratégie ExtractVariables ci-dessus à cette demande entrante,
la variable queryinfo.firstWeather
est définie sur Boston
.
la variable queryInfo.secondWeather
à Chicago
.
Vous pouvez maintenant accéder à la variable queryinfo.firstWeather
.
queryinfo.secondWeather dans
à votre proxy. Par exemple, la règle AssignMessage suivante la copie dans la charge utile de la requête :
<AssignMessage async="false" continueOnError="false" enabled="true" name="GetURIPath"> <DisplayName>GetQP</DisplayName> <Set> <Payload contentType="text/xml"> <ExtractQP1>{queryinfo.firstWeather}</ExtractQP1> <ExtractQP2>{queryinfo.secondWeather}</ExtractQP2> </Payload> </Set> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> <AssignTo createNew="false" transport="http" type="request"/> </AssignMessage>
En-têtes
<ExtractVariables name='ExtractVariable-OauthToken'> <Source>request</Source> <Header name="Authorization"> <Pattern ignoreCase="false">Bearer {oauthtoken}</Pattern> </Header> <VariablePrefix>clientrequest</VariablePrefix> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </ExtractVariables>
Supposons que votre API utilise des jetons de support OAuth v2.0. Prenons l'exemple de code de règle ci-dessus lorsque vous travaillez avec une requête exécutant un jeton OAuth v2.0 qui comprend un en-tête comme celui-ci : Authorization: Bearer TU08xptfFfeM7aS0xHqlxTgEAdAM.
En tant que concepteur de l'API, supposons que vous souhaitiez utiliser la valeur du jeton (mais pas l'en-tête complet) comme clé de recherche dans le cache. Vous pouvez extraire le jeton à l'aide du code de la règle ExtractVariables ci-dessus.
Quand Apigee Edge applique le code de stratégie ExtractVariables ci-dessus à cet en-tête, il
définissez la variable clientrequest.oauthtoken
sur
TU08xptfFfeM7aS0xHqlxTgEAdAM
Vous pouvez maintenant accéder à la variable clientrequest.oauthtoken
dans votre proxy. Par exemple, la règle AssignMessage suivante la copie dans la charge utile de la requête :
<AssignMessage async="false" continueOnError="false" enabled="true" name="GetURIPath"> <DisplayName>GetHeader</DisplayName> <Set> <Payload contentType="text/xml"> <ExtractHeader>{clientrequest.oauthtoken}</ExtractHeader> </Payload> </Set> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> <AssignTo createNew="false" transport="http" type="request"/> </AssignMessage>
JSON
<ExtractVariables name="ExtractVariables-3"> <Source>response</Source> <JSONPayload> <Variable name="latitude" type="float"> <JSONPath>$.results[0].geometry.location.lat</JSONPath> </Variable> <Variable name="longitude" type="float"> <JSONPath>$.results[0].geometry.location.lng</JSONPath> </Variable> </JSONPayload> <VariablePrefix>geocoderesponse</VariablePrefix> </ExtractVariables>
<JSONPayload>
$
Examinons la charge utile de la réponse JSON suivante :
{ "results": [{ "geometry": { "location": { "lat": 37.42291810, "lng": -122.08542120 }, "location_type": "ROOFTOP", "viewport": { "northeast": { "lat": 37.42426708029149, "lng": -122.0840722197085 }, "southwest": { "lat": 37.42156911970850, "lng": -122.0867701802915 } } } }] }
Lorsque Apigee Edge applique le code de stratégie ExtractVariables ci-dessus à ce message JSON, il
définit deux variables: geocoderesponse.latitude
et
geocoderesponse.longitude
Les deux variables utilisent le même préfixe de variable geocoderesponse
. Le suffixe de ces variables est spécifié explicitement par l'attribut name
de l'élément <Variable>
.
La variable geocoderesponse.latitude
obtient la valeur de 37.42291810
. La variable geocoderesponse.longitude
obtient la valeur de -122.08542120
.
Vous pouvez maintenant accéder à la variable geocoderesponse.latitude
dans votre proxy. Par exemple, la règle AssignMessage suivante la copie dans un en-tête nommé "latitude" dans la réponse :
<AssignMessage async="false" continueOnError="false" enabled="true" name="GetURIPath"> <DisplayName>GetJSONVar</DisplayName> <Add> <Headers> <Header name="latitude">{geocoderesponse.latitude}</Header> </Headers> </Add> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> <AssignTo createNew="false" transport="http" type="response"/> </AssignMessage>
XML
<ExtractVariables name="ExtractVariables-4"> <Source>response</Source> <XMLPayload> <Namespaces> <Namespace prefix="dir">urn:43BFF88D-D204-4427-B6BA-140AF393142F</Namespace> </Namespaces> <Variable name="travelmode" type="string"> <XPath>/dir:Directions/dir:route/dir:leg/dir:step/@mode</XPath> </Variable> <Variable name="duration" type="string"> <XPath>/dir:Directions/dir:route/dir:leg/dir:step/dir:duration/dir:value</XPath> </Variable> <Variable name="timeunit" type="string"> <XPath>/dir:Directions/dir:route/dir:leg/dir:step/dir:duration/dir:text</XPath> </Variable> </XMLPayload> <VariablePrefix>directionsresponse</VariablePrefix> </ExtractVariables>
<XMLPayload>
Examinons la charge utile de la réponse XML suivante :
<Directions xmlns="urn:43BFF88D-D204-4427-B6BA-140AF393142F"> <status>OK</status> <route> <summary>I-40 W</summary> <leg> <step mode="DRIVING"> <start_location> <lat>41.8507300</lat> <lng>-87.6512600</lng> </start_location> <end_location> <lat>41.8525800</lat> <lng>-87.6514100</lng> </end_location> <duration> <value>19</value> <text>minutes</text> </duration> </step> </leg> </route> </Directions>
Quand Apigee Edge applique le code de stratégie ExtractVariables ci-dessus à ce message XML, il
définit trois variables: directionsresponse.travelmode,
directionsresponse.duration
et directionsresponse.timeunit
. Toutes les variables utilisent le même préfixe de variable directionsresponse
. Le suffixe de ces variables est spécifié explicitement par l'attribut name
de l'élément <Variable>
.
La variable directionsresponse.travelmode
obtient la valeur de DRIVING
. La variable directionsresponse.duration
obtient la valeur de 19
. La variable directionsresponse.timeunit
obtient la valeur de minutes
.
Vous pouvez maintenant accéder à la variable directionresponse.travelmode
dans votre proxy. Par exemple, la règle AffectMessage suivante le copie dans un en-tête nommé
"tmode" dans la réponse:
<AssignMessage async="false" continueOnError="false" enabled="true" name="GetURIPath"> <DisplayName>GetXMLVar</DisplayName> <Add> <Headers> <Header name="tmode">{directionsresponse.travelmode}</Header> </Headers> </Add> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> <AssignTo createNew="false" transport="http" type="request"/> </AssignMessage>
À propos de la règle ExtractVariables
Les développeurs d'API créent des proxys d'API qui se comportent différemment en fonction du contenu des messages, y compris les en-têtes, les chemins d'URI, les charges utiles et les paramètres de requête. Souvent, le proxy extrait une partie de ce contenu pour l'utiliser dans une instruction de condition. Pour ce faire, utilisez la règle ExtractVariables.
Lors de la définition de la règle ExtractVariables, vous pouvez choisir :
- Noms des variables à définir
- Source des variables
- Nombre de variables à extraire et à définir
Lorsqu'elle est exécutée, la règle applique un modèle de texte au contenu et, lors de la recherche d'une correspondance, définit la valeur de la variable désignée avec le contenu. D'autres stratégies et codes peuvent ensuite utiliser ces variables pour activer un comportement dynamique ou pour envoyer des données d'entreprise à Edge API Analytics.
Pour découvrir comment utiliser ExtractVariables afin de créer des rapports Analytics basés sur le contenu, consultez Analyser Contenu du message de l'API à l'aide d'analyses personnalisées
Champ d'application
Les variables définies avec la règle ExtractVariables ont un champ d'application global. En d'autres termes, une fois que la règle ExtractVariables a défini une nouvelle variable, vous pouvez y accéder depuis n'importe quelle règle ou code et à n'importe quelle étape du flux (qui s'exécute après la règle ExtractVariables). Par exemple :
- PreFlow : ProxyEndpoint et TargetEndpoint (requête et réponse)
- PostFlow : ProxyEndpoint et TargetEndpoint (requête et réponse)
- PostClientFlow : ProxyEndpoint (réponse uniquement, au moyen de l'aide de la règle Message Logging)
- Flux d'erreurs
À propos de la correspondance et de la création de variables
La règle ExtractVariables extrait les informations d'une requête ou d'une réponse et les écrit dans une variable. Pour chaque type d'information que vous pouvez extraire, par exemple le chemin d'URI ou les données XML, spécifiez le modèle à mettre en correspondance, ainsi que le nom de la variable utilisée pour stocker les informations extraites.
Cependant, le fonctionnement de la correspondance de modèles dépend de la source de l'extraction. Les sections suivantes décrivent les deux catégories d'informations de base que vous pouvez extraire.
Mise en correspondance de chemins d'URI, de paramètres de requête, d'en-têtes, de paramètres de formulaire et de variables
Lorsque vous extrayez des informations à partir d'un chemin d'URI, de paramètres de requête, d'en-têtes, de paramètres de formulaire et de variables, vous utilisez le tag <Pattern> pour spécifier un ou plusieurs modèles à mettre en correspondance. L'exemple de règle suivant affiche un seul modèle de correspondance pour le chemin d'URI :
<ExtractVariables name="ExtractVariables-1"> <Source>request</Source> <URIPath> <Pattern ignoreCase="true">/a/{pathSeg}</Pattern> </URIPath> <VariablePrefix>urirequest</VariablePrefix> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </ExtractVariables>
Dans cet exemple, la variable urirequest.pathSeg est définie à la valeur qui apparaît dans le proxy.pathsuffix après "/a/". Par exemple, supposons que le chemin de base pour votre proxy d'API est /basepath/v1 . Avec une demande entrante vers http://myCo.com/basepath/v1/a/b, le est définie sur "b".
Spécifier plusieurs modèles
Vous pouvez spécifier plusieurs modèles à mettre en correspondance, correspondant aux tags <Pattern>, où :
- Tous les modèles sont testés pour vérifier leur correspondance.
- Si aucun des formats ne correspond, la règle n'a aucun effet et la ou les variables ne sont pas créé.
- Si plusieurs modèles correspondent, celui qui possède aux segments de chemin d'accès les plus longs est utilisé pour l'extraction.
- Si deux modèles correspondant aux mêmes segments de chemin sont les plus longs, le modèle spécifié en premier dans la règle est utilisé pour l'extraction.
Dans l'exemple suivant, vous allez créer une règle contenant trois formats correspondants au chemin de l'URI :
<ExtractVariables name="ExtractVariables-1"> <Source>request</Source> <URIPath> <Pattern ignoreCase="true">/a/{pathSeg}</Pattern> <Pattern ignoreCase="true">/a/b/{pathSeg}</Pattern> <Pattern ignoreCase="true">/a/b/c/{pathSeg}</Pattern> </URIPath> <VariablePrefix>urirequest</VariablePrefix> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </ExtractVariables>
Supposons, pour un proxy d'API et un chemin de base /basepath/v1, que l'URL de requête entrante adressée au proxy d'API se présente comme suit :
http://myCo.com/basepath/v1/a/b
Dans cet exemple, le premier modèle correspond à l'URI et la variable urirequest.pathSeg est définie sur "b".
Si l'URL de la requête est :
http://myCo.com/basepath/v1/a/b/c/d
…le troisième modèle correspond et la variable urirequest.pathSeg est définie sur "d".
Spécifier des modèles avec plusieurs variables
Vous pouvez spécifier plusieurs variables dans le modèle correspondant. Par exemple, vous pouvez spécifier un modèle correspondant avec deux variables :
<ExtractVariables name="ExtractVariables-1"> <Source>request</Source> <URIPath> <Pattern ignoreCase="true">/a/{pathSeg}</Pattern> <Pattern ignoreCase="true">/a/b/{pathSeg}</Pattern> <Pattern ignoreCase="true">/a/{pathSeg1}/c/{pathSeg2}</Pattern> </URIPath> <VariablePrefix>urirequest</VariablePrefix> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </ExtractVariables>
À nouveau, supposons un proxy d'API et un chemin de base /basepath/v1. Pour l'URL de requête entrante :
http://myCo.com/basepath/v1/a/b/c/d
…la variable urirequest.pathSeg1 est définie sur "b" et la variable urirequest.pathSeg2 est définie sur "d".
Mise en correspondance de plusieurs instances dans le modèle
Vous pouvez également faire correspondre des modèles lorsque plusieurs instances d'un élément portent le même nom. Par exemple, vous pouvez envoyer une requête contenant plusieurs paramètres de requête ou plusieurs en-têtes portant le même nom. La requête suivante contient deux paramètres de requête nommés "w" :
http://myCo.com/basepath/v1/a/b/c/d?w=1&w=2
Pour référencer ces paramètres de requête dans la règle ExtractVariables, vous utilisez des index, où la première instance du paramètre de requête ne comporte pas d'index, la seconde se situe à l'index 2, la troisième à l'index 3, etc. Par exemple, la règle suivante extrait la valeur du deuxième paramètre de requête nommé "w" dans la requête :
<ExtractVariables name="ExtractVariables-1"> <Source>request</Source> <QueryParam name="w.2"> <Pattern ignoreCase="true">{secondW}</Pattern> </QueryParam> <VariablePrefix>urirequest</VariablePrefix> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </ExtractVariables>
La variable urirequest.secondW est définie sur "2". Si le deuxième paramètre de requête est omis de la requête, la variable urirequest.secondW est vide. Utilisez l'indexation chaque fois que plusieurs éléments portent le même nom dans la requête.
Utiliser des caractères spéciaux dans le modèle
Lors de la mise en correspondance des chemins d'URI, vous pouvez utiliser les caractères génériques "*" et "**" dans le modèle, où :
- "*" correspond à n'importe quel segment du chemin
- "**" correspond à plusieurs segments du chemin
Par exemple, vous spécifiez des modèles pour l'élément <URIPath> comme indiqué ci-dessous :
<URIPath> <Pattern ignoreCase="true">/a/*/{id}</Pattern> <Pattern ignoreCase="true">/a/**/{id}</Pattern> </URIPath>
Le premier modèle correspond aux requêtes comportant des suffixes de chemin (partie du chemin d'URI qui suit le chemin de base) tels que "/a/b/c", "/a/foo/bar", etc. Le second modèle correspond à n'importe quel nombre de segments de chemin d'accès après "/a/", par exemple "/a/foo/bar/baz/c", ainsi que "/a/b/c" et "/a/foo/bar".
Lorsque vous spécifiez des modèles de requêtes de paramètres, d'en-têtes et de paramètres de formulaire, le caractère "*" correspond à n'importe quel nombre de caractères. Par exemple, pour établir une correspondance avec un en-tête, spécifiez le modèle comme suit :
*; charset={encoding}
Ce modèle correspond aux valeurs "text/xml;charset=UTF-16" et "application/xml;charset=ASCII".
Si la valeur transmise à la règle ExtractVariables contient un caractère spécial, tel que "{", utilisez le caractère "%" pour l'échapper. L'exemple suivant échappe les caractères "{" et"}" dans le modèle, car ils sont utilisés en tant que caractères littéraux dans la valeur du paramètre de requête :
<QueryParam> <Pattern ignoreCase="true">%{user%} {name}</Pattern> </QueryParam>
Dans cet exemple, le modèle correspond à la valeur "{user} Steve", mais pas à la valeur "user Steve".
Mise en correspondance de JSON et XML
Lorsque vous extrayez des données JSON et XML, vous spécifiez un ou plusieurs tags <Variable> dans la règle. Le tag <Variable> spécifie le nom de la variable de destination où les informations extraites sont stockées, et les éléments JsonPath (JSON) ou XPATH (XML), les informations extraites.
Tous les tags <Variable> de la règle sont évalués, ce qui vous permet d'insérer plusieurs variables à partir d'une seule règle. Si le tag <Variable> ne renvoie pas un champ valide dans le fichier JSON ou XML, la variable correspondante n'est pas créée.
L'exemple suivant illustre une règle ExtractVariables qui insère deux variables à partir du corps JSON d'une réponse :
<ExtractVariables name="ExtractVariables-3"> <Source>response</Source> <JSONPayload> <Variable name="latitude" type="float"> <JSONPath>$.results[0].geometry.location.lat</JSONPath> </Variable> <Variable name="longitude" type="float"> <JSONPath>$.results[0].geometry.location.lng</JSONPath> </Variable> </JSONPayload> <VariablePrefix>geocoderesponse</VariablePrefix> </ExtractVariables>
Écrire dans la même variable à plusieurs emplacements
Soyez prudent lorsque vous choisissez les noms des variables à définir. La règle s'exécute de manière séquentielle du premier modèle d'extraction vers le dernier. Si la règle écrit une valeur dans la même variable à partir de plusieurs emplacements, la dernière écriture dans la règle détermine la valeur de la variable. (Il peut s'agir d'un choix volontaire.)
Par exemple, vous souhaitez extraire une valeur de jeton pouvant être transmise dans un paramètre de requête ou dans un en-tête, comme indiqué ci-dessous :
<!-- If token only in query param, the query param determines the value. If token is found in both the query param and header, header sets value. --> <QueryParam name="token"> <Pattern ignoreCase="true">{tokenValue}</Pattern> </QueryParam> <!-- Overwrite tokenValue even if it was found in query parameter. --> <Header name="Token"> <Pattern ignoreCase="true">{tokenValue}</Pattern> </Header>
Contrôler les étapes suivantes lorsqu'aucune correspondance n'est trouvée
Si le modèle ne correspond pas, la variable correspondante n'est pas créée. Par conséquent, si une autre règle fait référence à la variable, elle peut générer une erreur.
Une option consiste à définir <IgnoreUnresolvedVariables>
sur "true" dans une règle qui fait référence à la variable afin de configurer la règle pour qu'elle traite une variable non résolue comme une chaîne vide (null) :
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
Documentation de référence des éléments
La référence d'élément décrit les éléments et les attributs de la règle ExtractVariables.
<ExtractVariables async="false" continueOnError="false" enabled="true" name="Extract-Variables-1"> <DisplayName>Extract Variables 1</DisplayName> <Source clearPayload="true|false">request</Source> <VariablePrefix>myprefix</VariablePrefix> <IgnoreUnresolvedVariables>true|false</IgnoreUnresolvedVariables> <URIPath> <Pattern ignoreCase="false">/accounts/{id}</Pattern> </URIPath> <QueryParam name="code"> <Pattern ignoreCase="true">DBN{dbncode}</Pattern> </QueryParam> <Header name="Authorization"> <Pattern ignoreCase="false">Bearer {oauthtoken}</Pattern> </Header> <FormParam name="greeting"> <Pattern>hello {user}</Pattern> </FormParam> <Variable name="request.content"> <Pattern>hello {user}</Pattern> </Variable> <JSONPayload> <Variable name="name"> <JSONPath>{example}</JSONPath> </Variable> </JSONPayload> <XMLPayload stopPayloadProcessing="false"> <Namespaces/> <Variable name="name" type="boolean"> <XPath>/test/example</XPath> </Variable> </XMLPayload> </ExtractVariables>
Attributs <ExtractVariables>
<ExtractVariables async="false" continueOnError="false" enabled="true" name="Extract-Variables-1">
Le tableau suivant décrit les attributs communs à tous les éléments parents des règles :
Attribut | Description | Par défaut | Présence |
---|---|---|---|
name |
Nom interne de la règle. La valeur de l'attribut Vous pouvez également utiliser l'élément |
ND | Valeur |
continueOnError |
Définissez sur Définissez sur |
faux | Facultatif |
enabled |
Définissez sur Définissez sur |
vrai | Facultatif |
async |
Cet attribut est obsolète. |
faux | Obsolète |
Élément <DisplayName>
Utilisez-le, en plus de l'attribut name
, pour appliquer un libellé à la règle dans l'éditeur de proxys de l'interface de gestion en utilisant un nom différent, en langage naturel.
<DisplayName>Policy Display Name</DisplayName>
Par défaut |
ND Si vous omettez cet élément, la valeur de l'attribut |
---|---|
Présence | Facultatif |
Type | Chaîne |
Élément <Source>
(Facultatif) Indique la variable à analyser. La valeur <Source>
est définie sur message
par défaut. La valeur message
est sensible au contexte. Dans un flux de requête, message
renvoie le message de requête. Dans un flux de réponse, message
renvoie le message de réponse.
Cette règle sert souvent à extraire des informations d'un message de requête ou de réponse, mais vous pouvez l'utiliser pour extraire des informations de n'importe quelle variable. Par exemple, vous pouvez l'utiliser pour extraire
les informations d'une entité créée par la règle AccessEntity, à partir de données
renvoyées par la fonction Service
règle d'appel, ou extrayez des informations d'un objet XML ou JSON.
Si <Source>
ne peut être résolu ou est associé à un type qui n'est pas un message, la règle ne produira aucune réponse.
<Source clearPayload="true|false">request</Source>
Valeur par défaut : | Message |
Présence : | Facultatif |
Type : | Chaîne |
Attributs
Attribut | Description | Par défaut | Présence | Type |
---|---|---|---|---|
clearPayload |
Définissez la valeur sur true si vous souhaitez effacer la charge utile spécifiée par <Source> après en avoir extrait les données. |
faux |
Facultatif | Booléen |
Élément <VariablePrefix>
(Facultatif) Le nom complet de la variable est créé en associant <VariablePrefix>
, un point et le nom que vous définissez entre {accolades} dans l'élément <Pattern>
ou <Variable>. Par exemple, myprefix.id
, myprefix.dbncode
ou myprefix.oauthtoken.
.
<VariablePrefix>myprefix</VariablePrefix>
Supposons, par exemple, que la valeur du nom soit "user".
- Si
<VariablePrefix>
n'est pas spécifié, les valeurs extraites sont attribuées à une variable nomméeuser
. - Si
<VariablePrefix>
est spécifié sous la forme "myprefix", les valeurs extraites sont attribuées à une variable nomméemyprefix.user
.
Valeur par défaut : | ND |
Présence : | Facultatif |
Type : | Chaîne |
Élément <IgnoreUnresolvedVariables>
(Facultatif) Définissez la valeur sur true
pour traiter toute variable non résolue comme une chaîne vide (null). Définissez la valeur sur false
si vous souhaitez que la règle génère une erreur lorsqu'une variable référencée ne peut être résolue.
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
Valeur par défaut : | Faux |
Présence : | Facultatif |
Type : | Booléen |
Si une référence XPath n'est pas résolue dans un <XMLPayload>
, la stratégie renvoie
l'erreur suivante:
{ "fault":{ "faultstring":"Unresolved xpath path in policy policy_name.", "detail":{ "errorcode":"steps.extractvariables.InvalidXPath" } } }
Élément <URIPath>
(Facultatif ; consultez toutefois la ligne "Présence" du tableau ci-dessous pour en savoir plus.) Extrait une valeur du paramètre proxy.pathsuffix d'un message source de requête. Le chemin appliqué au modèle est proxy.pathsuffix, qui n'inclut pas le chemin de base du proxy API. Si le message source renvoie à un type de message response, cet élément n'a aucun effet.
<URIPath> <Pattern ignoreCase="false">/accounts/{id}</Pattern> </URIPath>
Il est possible d'utiliser plusieurs éléments <Pattern> :
<URIPath> <Pattern ignoreCase="false">/accounts/{id}</Pattern> <Pattern ignoreCase="false">/accounts/{id}/transactions/{index}</Pattern> </URIPath>
Valeur par défaut : | ND |
Présence : | Facultatif. Toutefois, vous devez inclure au moins l'un des éléments suivants : <URIPath> , <QueryParam> , <Header> , <FormParam> , <JSONPayload> , ou <XMLPayload>. |
Type : | ND |
Attributs
Attribut | Description | Par défaut | Présence | Type |
---|---|---|---|---|
ignoreCase | Spécifie si la casse doit être ignorée lors de la mise en correspondance du modèle. |
faux |
Facultatif | Booléen |
Élément <QueryParam>
(Facultatif ; consultez toutefois la ligne "Présence" du tableau ci-dessous pour en savoir plus.) Extrait une valeur à partir du paramètre de requête spécifié d'un message source de requête. Si le message source correspond à un type de message de réponse, cet élément n'effectue aucune action.
<QueryParam name="code"> <Pattern ignoreCase="true">DBN{dbncode}</Pattern> </QueryParam>
Si plusieurs paramètres de requête portent le même nom, utilisez des index pour les référencer :
<QueryParam name="w.2"> <Pattern ignoreCase="true">{secondW}</Pattern> </QueryParam>
Valeur par défaut : | ND |
Présence : | Facultatif. Toutefois, vous devez inclure au moins l'un des éléments suivants : <URIPath> , <QueryParam> , <Header> , <FormParam> , <JSONPayload> , ou <XMLPayload>. |
Type : | ND |
Attributs
Attribut | Description | Par défaut | Présence | Type |
---|---|---|---|---|
nom | Spécifie le nom du paramètre de requête. Si plusieurs paramètres de requête portent le même nom, utilisez le référencement indexé où la première instance du paramètre de requête n'a pas d'index, la deuxième correspond à l'index 2, la troisième à l'index 3, etc. |
ND |
Requis | Chaîne |
Élément <Header>
(Facultatif ; consultez toutefois la ligne "Présence" du tableau ci-dessous pour en savoir plus.) Extrait une valeur provenant de l'en-tête HTTP du message request ou response spécifié. Si plusieurs en-têtes portent le même nom, leurs valeurs sont stockées dans un tableau.
<!-- The name is the actual header name. --> <Header name="Authorization"> <!-- Provide a name for your new custom variable here. --> <Pattern ignoreCase="false">Bearer {oauthtoken}</Pattern> </Header>
Si plusieurs en-têtes portent le même nom, utilisez des index pour référencer des en-têtes spécifiques du tableau :
<Header name="myHeader.2"> <Pattern ignoreCase="true">{secondHeader}</Pattern> </Header>
La commande suivante permet d'obtenir la liste tous les en-têtes du tableau :
<Header name="myHeader.values"> <Pattern ignoreCase="true">{myHeaders}</Pattern> </Header>
Valeur par défaut : | ND |
Présence : | Facultatif. Toutefois, vous devez inclure au moins l'un des éléments suivants : <URIPath> , <QueryParam> , <Header> , <FormParam> , <JSONPayload> , ou <XMLPayload>. |
Type : | ND |
Attributs
Attribut | Description | Par défaut | Présence | Type |
---|---|---|---|---|
nom | Spécifie le nom de l'en-tête à partir duquel extraire la valeur. Si plusieurs en-têtes portent le même nom, utilisez le référencement indexé où la première instance de l'en-tête n'a pas d'index, la deuxième correspond à l'index 2, la troisième à l'index 3, etc. Utilisez .values pour obtenir tous les en-têtes du tableau. |
ND |
Requis | Chaîne |
Élément <FormParam>
(Facultatif ; consultez toutefois la ligne "Présence" du tableau ci-dessous pour en savoir plus.) Extrait une valeur
provenant du paramètre de formulaire spécifié du message request ou response spécifié. Les paramètres de formulaire ne peuvent être extraits que lorsque l'en-tête Content-Type
du message spécifié est application/x-www-form-urlencoded
.
<FormParam name="greeting"> <Pattern>hello {user}</Pattern> </FormParam>
Valeur par défaut : | ND |
Présence : | Facultatif. Toutefois, vous devez inclure au moins l'un des éléments suivants : <URIPath> , <QueryParam> , <Header> , <FormParam> , <JSONPayload> , ou <XMLPayload>. |
Type : | ND |
Attributs
Attribut | Description | Par défaut | Présence | Type |
---|---|---|---|---|
nom | Nom du paramètre de formulaire à partir duquel extraire la valeur. |
ND |
Requis | Chaîne |
Élément <Variable>
(Facultatif ; consultez toutefois la ligne "Présence" du tableau ci-dessous pour en savoir plus.) Spécifie le nom d'une variable à partir de laquelle extraire une valeur.
<Variable name="myVar"> <Pattern>hello {user}</Pattern> </Variable>
Pour extraire deux valeurs de la variable, procédez comme suit :
<Variable name="myVar"> <Pattern>hello {firstName} {lastName}</Pattern> </Variable>
Valeur par défaut : | ND |
Présence : | Facultatif. Toutefois, vous devez inclure au moins l'un des éléments suivants : <URIPath> , <QueryParam> , <Header> , <FormParam> , <JSONPayload> , ou <XMLPayload>. |
Type : | ND |
Attributs
Attribut | Description | Par défaut | Présence | Type |
---|---|---|---|---|
nom | Nom de la variable à partir de laquelle extraire la valeur. |
ND |
Requis | Chaîne |
Élément <JSONPayload>
(Facultatif ; consultez toutefois la ligne "Présence" du tableau ci-dessous pour en savoir plus.) Spécifie le message au format JSON dont la valeur de la variable sera extraite. JSON l'extraction n'est effectuée que lorsque l'en-tête Content-Type du message est application/json.
<JSONPayload> <Variable name="name" type="string"> <JSONPath>{example}</JSONPath> </Variable> </JSONPayload>
Valeur par défaut : | ND |
Présence : | Facultatif. Toutefois, vous devez inclure au moins l'un des éléments suivants : <URIPath> , <QueryParam> , <Header> , <FormParam> , <JSONPayload> , ou <XMLPayload>. |
Type : | ND |
Élément <JSONPayload>/<Variable>
(Obligatoire dans l'élément JSONPayload). Spécifie la variable à laquelle la valeur extraite est attribuée. Vous pouvez inclure plusieurs balises <Variable> dans l'élément <Variable> pour renseigner plusieurs variables.
<Variable name="name" type="string"> <JSONPath>{example}</JSONPath> </Variable>
Valeur par défaut : | ND |
Présence : | Obligatoire dans l'élément JSONPayload. |
Type : | ND |
Attributs
Attribut | Description | Par défaut | Présence | Type |
---|---|---|---|---|
nom |
Spécifie le nom de la variable à laquelle la valeur extraite sera attribuée. |
nom |
Valeur | Chaîne |
type | Spécifie le type de données de la valeur de la variable. | ND | Facultatif |
Chaîne. Sélectionnez parmi :
|
Élément <JSONPayload>/<Variable>/<JSONPath>
(Obligatoire dans l'élément JSONPayload:Variable). Spécifie le chemin JSON utilisé pour extraire une valeur d'un message au format JSON.
<Variable name="name"> <JSONPath>$.rss.channel.title</JSONPath> </Variable>
Valeur par défaut : | ND |
Présence : | Requis |
Type : | Chaîne |
Élément <XMLPayload>
(Facultatif ; consultez toutefois la ligne "Présence" du tableau ci-dessous pour en savoir plus.) Spécifie le message au format XML dont la valeur de la variable sera extraite. Les charges utiles XML ne sont extraites que lorsque l'en-tête Content-Type
du message est text/xml
, application/xml
ou application/*+xml
.
<XMLPayload stopPayloadProcessing="false"> <Namespaces> <Namespace prefix="apigee">http://www.apigee.com</Namespace> <Namespace prefix="gmail">http://mail.google.com</Namespace> </Namespaces> <Variable name="name" type="boolean"> <XPath>/apigee:test/apigee:example</XPath> </Variable> </XMLPayload>
Valeur par défaut : | ND |
Présence : | Facultatif. Toutefois, vous devez inclure au moins l'un des éléments suivants : <URIPath> , <QueryParam> , <Header> , <FormParam> , <JSONPayload> , ou <XMLPayload>. |
Type : | ND |
Attributs
Attribut | Description | Par défaut | Présence | Type |
---|---|---|---|---|
stopPayloadProcessing |
Définissez la valeur sur |
faux |
Facultatif | Booléen |
Élément <XMLPayload>/<Namespaces>
(Facultatif) Spécifie l'espace de noms à utiliser pour l'évaluation XPath. Si vous utilisez des espaces de noms dans vos expressions XPath, vous devez les déclarer ici, comme illustré dans l'exemple suivant.
<XMLPayload stopPayloadProcessing="false"> <Namespaces> <Namespace prefix="apigee">http://www.apigee.com</Namespace> <Namespace prefix="gmail">http://mail.google.com</Namespace> </Namespaces> <Variable name="legName" type="string"> <XPath>/apigee:Directions/apigee:route/apigee:leg/apigee:name</XPath> </Variable> </XMLPayload>
Si vous n'utilisez pas d'espaces de noms dans vos expressions XPath, vous pouvez omettre ou commenter l'élément <Namespaces>
, comme illustré par l'exemple suivant :
<XMLPayload stopPayloadProcessing="false"> <!-- <Namespaces/> --> <Variable name="legName" type="string"> <XPath>/Directions/route/leg/name</XPath> </Variable> </XMLPayload>
Valeur par défaut : | ND |
Présence : | Facultatif |
Type : | Chaîne |
Attributs
Attribut | Description | Par défaut | Présence | Type |
---|---|---|---|---|
prefix |
Préfixe d'espace de noms. |
ND |
Requis | Chaîne |
Élément <XMLPayload>/<Variable>
(Facultatif) Spécifie une variable à laquelle la valeur extraite sera attribuée.
<Variable name="name" type="boolean"> <XPath>/test/example</XPath> </Variable>
Valeur par défaut : | ND |
Présence : | Facultatif |
Type : | ND |
Attributs
Attribut | Description | Par défaut | Présence | Type |
---|---|---|---|---|
nom |
Spécifie le nom de la variable à laquelle la valeur extraite sera attribuée. |
nom |
Valeur | Chaîne |
type | Spécifie le type de données de la valeur de la variable. | Booléen | Facultatif |
Chaîne. Sélectionnez parmi :
|
Élément <XMLPayload>/<Variable>/<XPath>
(Obligatoire dans l'élément XMLPayload:Variable). Spécifie le chemin XPath défini pour la variable. Seules les expressions XPath 1.0 sont acceptées.
<Variable name="name" type="boolean"> <XPath>/test/example</XPath> </Variable>
Exemple avec un espace de noms. Si vous utilisez des espaces de noms dans vos expressions XPath, vous devez déclarer
Les espaces de noms de la section <XMLPayload><Namespaces>
de la règle.
<Variable name="name" type="boolean"> <XPath>/foo:test/foo:example</XPath> </Variable>
Valeur par défaut : | ND |
Présence : | Requis |
Type : | Chaîne |
Informations de référence sur les erreurs
Cette section décrit les codes d'erreur et les messages d'erreur qui sont renvoyés, ainsi que les variables d'erreur définies par Edge lorsque cette stratégie déclenche une erreur. Ces informations sont importantes si vous développez des règles de défaillance afin de gérer les pannes. Pour en savoir plus, consultez les pages Ce que vous devez savoir à propos des erreurs liées aux règles et Gérer les pannes.
Erreurs d'exécution
Ces erreurs peuvent se produire lors de l'exécution de la règle.
Code d'erreur | État HTTP | Cause | Corriger |
---|---|---|---|
steps.extractvariables.ExecutionFailed |
500 |
Cette erreur se produit dans les cas suivants :
|
build |
steps.extractvariables.ImmutableVariable |
500 | Une variable utilisée dans la règle est immuable. La règler n'a pas pu définir cette variable. | |
steps.extractvariables.InvalidJSONPath |
500 | Cette erreur se produit si un chemin JSON non valide est utilisé dans l'élément JSONPath de la règle. Par exemple, si une charge utile JSON ne contient pas l'objet Name , mais vous spécifiez Name comme chemin d'accès dans la règle, cette erreur se produit. |
build |
steps.extractvariables.JsonPathParsingFailure |
500 | Cette erreur se produit lorsque la règle ne peut pas analyser un chemin JSON et extraire les données de la variable de flux spécifiée dans l'élément Source . Cela se produit généralement si la variable de flux spécifiée dans l'élément Source n'existe pas dans le flux actuel. |
build |
steps.extractvariables.SetVariableFailed |
500 | Cette erreur se produit si la règle n'a pas pu définir la valeur sur une variable. L'erreur se produit généralement si vous essayez d'attribuer des valeurs à plusieurs variables dont les noms commencent par les mêmes mots dans un format imbriqué, séparés par un point. | build |
steps.extractvariables.SourceMessageNotAvailable |
500 | Cette erreur se produit si la variable message spécifiée dans l'élément Source de la règle est :
|
build |
steps.extractvariables.UnableToCast |
500 | Cette erreur se produit si la règle n'a pas pu convertir la valeur extraite en variable. Cela se produit généralement si vous tentez de définir la valeur d'un type de données sur une variable d'un autre type de données. | build |
Erreurs de déploiement
Ces erreurs peuvent se produire lorsque vous déployez un proxy contenant cette règle.
Nom de l'erreur | Cause | Corriger |
---|---|---|
NothingToExtract |
Si la règle ne comporte aucun des éléments URIPath , QueryParam , Header , FormParam , XMLPayload ou JSONPayload , le déploiement du proxy d'API échoue, car il n'y a rien à extraire. |
build |
NONEmptyPrefixMappedToEmptyURI |
Cette erreur se produit si la règle comporte un préfixe défini dans l'élément Namespace sous l'élément XMLPayload , mais qu'aucun URI n'est défini. |
build |
DuplicatePrefix |
Cette erreur se produit si le même préfixe est défini plusieurs fois dans l'élément Namespace sous l'élément XMLPayload . |
build |
NoXPathsToEvaluate |
Si la règle ne contient pas l'élément XPath au sein de l'élément XMLPayload , le déploiement du proxy d'API échoue avec cette erreur.
|
build |
EmptyXPathExpression |
Si la règle contient une expression XPath vide dans l'élément XMLPayload , le déploiement du proxy d'API échoue. |
build |
NoJSONPathsToEvaluate |
Si la règle ne contient pas l'élément JSONPath au sein de l'élément JSONPayload , le déploiement du proxy d'API échoue avec cette erreur. |
build |
EmptyJSONPathExpression |
Si la règle contient une expression XPath vide dans l'élément XMLPayload , le déploiement du proxy d'API échoue. |
build |
MissingName |
Si la règle ne comporte pas l'attribut name dans aucun des ses éléments, tels que QueryParam , Header , FormParam ou Variable , le cas échéant, le déploiement du proxy d'API échoue. |
build |
PatternWithoutVariable |
Si la règle ne comporte aucune variable spécifiée dans l'élément Pattern , le déploiement du proxy d'API échoue. L'élément Pattern requiert le nom de la variable dans laquelle les données extraites seront stockées. |
build |
CannotBeConvertedToNodeset |
Si la règle contient une expression XPath où le type Variable est défini sur nodeset, mais que l'expression ne peut pas être convertie en ensemble de nœuds, le déploiement du proxy d'API échoue. |
build |
JSONPathCompilationFailed |
La règle n'a pas pu compiler un chemin JSON spécifié. | |
InstantiationFailed |
Impossible d'instancier la règle. | |
XPathCompilationFailed |
Si le préfixe ou la valeur utilisée dans l'élément XPath ne fait partie d'aucun des espaces de noms déclarés dans la règle, le déploiement du proxy d'API échoue. |
build |
InvalidPattern |
Si la définition de l'élément Pattern est non valide dans les éléments tels que URIPath , QueryParam , Header , FormParam , XMLPayload ou JSONPayload contenus dans la règle, le déploiement du proxy d'API échoue.
|
build |
Variables de panne
Ces variables sont définies lorsque cette règle déclenche une erreur au moment de l'exécution. Pour en savoir plus, consultez la section Ce que vous devez savoir sur les erreurs liées aux règles.
Variables | Où | Exemple |
---|---|---|
fault.name="fault_name" |
fault_name est le nom de l'erreur, tel qu'indiqué dans le tableau Erreurs d'exécution ci-dessus. Le nom d'erreur est la dernière partie du code d'erreur. | fault.name = "SourceMessageNotAvailable" |
extractvariables.policy_name.failed |
policy_name est le nom spécifié par l'utilisateur de la règle qui a provoqué l'erreur. | extractvariables.EV-ParseJsonResponse.failed = true |
Exemple de réponse d'erreur
{ "fault":{ "detail":{ "errorcode":"steps.extractvariables.SourceMessageNotAvailable" }, "faultstring":"request message is not available for ExtractVariable: EV-ParseJsonResponse" } }
Exemple de règle de défaillance
<FaultRule name="Extract Variable Faults"> <Step> <Name>AM-CustomErrorMessage</Name> <Condition>(fault.name = "SourceMessageNotAvailable") </Condition> </Step> <Condition>(extractvariables.EM-ParseJsonResponse.failed = true) </Condition> </FaultRule>
Schémas
Articles associés
Analyser le contenu du message de l'API à l'aide de données analytiques personnalisées