Questa pagina si applica a Apigee e Apigee ibridi.
Visualizza documentazione di Apigee Edge.
Cosa
Il criterio ExtractVariables estrae contenuti da una richiesta o risposta e imposta il valore di una variabile per quei contenuti. Puoi estrarre qualsiasi parte del messaggio, tra cui intestazioni, percorsi URI, payload JSON/XML, parametri e parametri di ricerca. Il criterio funziona applicando un pattern di testo al messaggio e, quando viene trovata una corrispondenza, imposta una variabile con il contenuto del messaggio specificato.
Anche se spesso usi ExtractVariables per estrarre informazioni da un messaggio di richiesta o risposta, puoi utilizzarlo anche per estrarre informazioni da altre fonti, comprese le entità create Criterio AccessEntity, oggetti XML o JSON.
Dopo aver estratto i contenuti specificati del messaggio, puoi fare riferimento alla variabile in altri nell'ambito dell'elaborazione di richieste e risposte.
Questo criterio è una norma estendibile e il suo utilizzo potrebbe comportare costi o di utilizzo delle applicazioni, a seconda della licenza Apigee. Per informazioni sui tipi di norme e le implicazioni per l'utilizzo, consulta Tipi di criteri.
Video
Guarda i seguenti video per scoprire di più sul criterio ExtractVariables.
Video | Descrizione |
---|---|
Estrazione delle variabili dal payload XML | Estrai variabili da un payload XML utilizzando il criterio Estrai variabile. |
Estrazione delle variabili dal payload JSON | Estrai variabili da un payload JSON usando il criterio Estrai variabile. |
Estrazione delle variabili da parametri | Estrai variabili dai parametri, ad esempio parametri di query, intestazione, modulo o URI. |
Estrazione delle variabili da parametri con più valori | Estrai variabili da parametri multivalore. |
Esempi
Questi esempi di codice dei criteri illustrano come estrarre variabili dai seguenti tipi di artefatti:
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>
Considera il codice di esempio del criterio riportato sopra. L'elemento <URIPath>
indica
Criterio ExtractVariables per estrarre informazioni dal percorso dell'URI. La
L'elemento <Pattern>
specifica il pattern da applicare al percorso dell'URI. La
viene trattato come un semplice modello, con le parentesi graffe che indicano la parte variabile
del percorso dell'URI.
Il nome della variabile da impostare è determinato dal valore specificato nel
<VariablePrefix>
, nonché il valore racchiuso tra parentesi graffe {}
nell'elemento <Pattern>
. I due valori sono uniti da un punto intermedio,
generando, ad esempio, il nome di variabile urirequest.id
. In caso contrario,
<VariablePrefix>
, il nome della variabile è solo il valore
racchiuse tra parentesi graffe.
Considera che il codice del criterio di esempio riportato sopra funziona con la seguente richiesta in entrata:
GET http://example.com/svc1/accounts/12797282
Supponiamo che il percorso base per il proxy API sia /svc1
. Quando Apigee applica
Il codice del criterio ExtractVariables riportato sopra per questa richiesta in entrata imposta la variabile
Da urirequest.id
a 12797282
. Dopo che Apigee ha eseguito il criterio,
I criteri o il codice successivi nel flusso di elaborazione possono fare riferimento alla variabile denominata
urirequest.id
per ottenere il valore della stringa 12797282
.
Ad esempio, il seguente criterioAssignMessage incorpora il valore di quella variabile nel campo payload di un nuovo messaggio di richiesta:
<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>
Parametri di query
<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>
Considera che il codice del criterio di esempio riportato sopra funziona con la seguente richiesta in entrata:
GET http://example.com/accounts/12797282?code=DBN88271
Quando Apigee applica il codice del criterio ExtractVariables riportato sopra a questa richiesta in entrata,
imposta la variabile queryinfo.dbncode
su 88271
. Dopo Apigee
esegue il criterio, i criteri o il codice successivi nel flusso di elaborazione possono fare riferimento
denominata queryinfo.dbncode
per ottenere il valore della stringa 88271
.
Ora puoi accedere alla variabile queryinfo.dbncode
nel tuo proxy.
Ad esempio, il seguente criterioAssignMessage lo copia nel payload della richiesta:
<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>
Più parametri
<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>
Supponiamo che la progettazione dell'API consenta di specificare più parametri di ricerca con lo stesso . Puoi utilizzare un criterio ExtractVariables per estrarre il valore di più istanze di il parametro di query. Per fare riferimento parametri di ricerca con lo stesso nome nel criterio, utilizza indici in cui la prima istanza del parametro di query non ha un indice, la seconda all'indice 2, il terzo all'indice 3 e così via.
Considera che il codice del criterio di esempio riportato sopra funziona con la seguente richiesta in entrata:
GET http://example.com/weather?w=Boston&w=Chicago
Quando Apigee applica il codice del criterio ExtractVariables riportato sopra a questa richiesta in entrata,
Imposta la variabile queryinfo.firstWeather
su Boston
e
da queryInfo.secondWeather
a Chicago
.
Ora puoi accedere alla variabile queryinfo.firstWeather
e
queryinfo.secondWeather
pollici
il proxy. Ad esempio, il seguente criterioAssignMessage lo copia nel payload del
richiesta:
<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>
Intestazioni
<ExtractVariables name='ExtractVariable-OauthToken'> <Source>request</Source> <Header name="Authorization"> <Pattern ignoreCase="false">Bearer {oauthtoken}</Pattern> </Header> <VariablePrefix>clientrequest</VariablePrefix> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </ExtractVariables>
Supponiamo che l'API utilizzi token di connessione OAuth 2.0. Considera il codice del criterio di esempio riportato sopra
lavora con una richiesta contenente un token OAuth v2.0 che include un'intestazione come la seguente:
Authorization: Bearer TU08xptfFfeM7aS0xHqlxTgEAdAM.
In qualità di progettista dell'API, supponiamo di voler utilizzare il valore del token, ma non l'intero intestazione) come chiave in una ricerca cache. Puoi usare il codice del criterio ExtractVariables qui sopra per per estrarre il token.
Quando Apigee applica il codice del criterio ExtractVariables riportato sopra a questa intestazione,
imposta la variabile clientrequest.oauthtoken
su
TU08xptfFfeM7aS0xHqlxTgEAdAM
.
Ora puoi accedere alla variabile clientrequest.oauthtoken
nel tuo
proxy. Ad esempio, il seguente criterioAssignMessage lo copia nel payload del servizio
richiesta:
<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>
Considera il seguente payload per la risposta JSON:
{ "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 } } } }] }
Quando Apigee applica il codice del criterio ExtractVariables riportato sopra a questo messaggio JSON,
imposta due variabili: geocoderesponse.latitude
e
geocoderesponse.longitude
. Entrambe le variabili utilizzano lo stesso prefisso di variabile
geocoderesponse
. Il suffisso per queste variabili è specificato esplicitamente dal
Attributo name
dell'elemento <Variable>
.
La variabile geocoderesponse.latitude
ottiene il valore
37.42291810
. La variabile geocoderesponse.longitude
ottiene il valore
-122.08542120
.
Ora puoi accedere alla variabile geocoderesponse.latitude
nel tuo
proxy. Ad esempio, il seguente criterioAssignMessage lo copia in un'intestazione denominata
latitude
nella risposta:
<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>
Considera il seguente payload di risposta XML:
<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>
Quando Apigee applica il codice del criterio ExtractVariables riportato sopra a questo messaggio XML, imposta tre variabili:
directionsresponse.travelmode
: ottiene il valoreDRIVING
directionsresponse.duration
: ottiene il valore19
directionsresponse.timeunit
: ottiene il valoreminutes
Tutti
utilizzano lo stesso prefisso di variabile directionsresponse
. Il suffisso per
queste variabili vengono specificate esplicitamente dall'elemento <Variable>
Attributo name
.
Ora puoi accedere alla variabile directionresponse.travelmode
in
il proxy. Ad esempio, il seguente criterioAssignMessage lo copia in un'intestazione denominata
tmode
nella risposta:
<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>
Informazioni sul criterio ExtractVariables
Gli sviluppatori di API creano proxy API che si comportano diversamente in base ai contenuti dei messaggi. come intestazioni, percorsi URI, payload e parametri di ricerca. Spesso, il proxy estrae alcune di questi contenuti per l'utilizzo in un'istruzione di condizione. Per farlo, utilizza il criterio ExtractVariables. questo.
Quando definisci il criterio ExtractVariables, puoi scegliere:
- Nomi delle variabili da impostare
- Origine delle variabili
- Numero di variabili da estrarre e impostare
Una volta eseguita, la norma applica un pattern di testo ai contenuti e, quando viene trovata una corrispondenza, imposta il valore della variabile designata con i contenuti. Altri criteri e codice possono quindi consumare per abilitare il comportamento dinamico o inviare dati aziendali ad analisi delle API Apigee.
Ambito
Le variabili impostate con il criterio ExtractVariables hanno un ambito globale. Cioè, dopo che Il criterio ExtractVariables definisce una nuova variabile, puoi accedervi da qualsiasi criterio o in qualsiasi fase del flusso (che viene eseguita dopo il criterio ExtractVariables). Questo include:
- PreFlow: ProxyEndpoint e TargetEndpoint (richiesta e risposta)
- PostFlow: ProxyEndpoint e TargetEndpoint (richiesta e risposta)
- PostClientFlow: ProxyEndpoint (solo risposta, utilizzando Criterio MessageLogging>)
- Flussi di errori
Informazioni sulla corrispondenza e sulla creazione di variabili
Il criterio ExtractVariables estrae informazioni da una richiesta o risposta e scrive che a una variabile. Per ogni tipo di informazione che si può estrarre, come il percorso URI dati XML, devi specificare il pattern da abbinare e il nome della variabile utilizzata per contenere il le informazioni estratte.
Tuttavia, il funzionamento della corrispondenza dei pattern dipende dall'origine dell'estrazione. Le seguenti descrivono le due categorie base di informazioni che è possibile estrarre.
Percorsi degli URI, parametri di ricerca, intestazioni, parametri del modulo e variabili corrispondenti
Quando si estrae informazioni da un percorso URI, parametri di ricerca, le intestazioni, i parametri del modulo
variabili che utilizzi il tag <Pattern>
per specificare una o più
pattern corrispondenti. Il seguente criterio di esempio mostra un singolo pattern di corrispondenza per
il percorso dell'URI:
<ExtractVariables name="ExtractVariables-1"> <Source>request</Source> <URIPath> <Pattern ignoreCase="true">/a/{pathSeg}</Pattern> </URIPath> <VariablePrefix>urirequest</VariablePrefix> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </ExtractVariables>
In questo esempio, la variabile urirequest.pathSeg
è impostata
a qualsiasi valore visualizzato nel proxy.pathsuffix dopo /a/
. Ad esempio, supponiamo che
il percorso di base del proxy API è /basepath/v1
. Con una richiesta in entrata
per http://myCo.com/basepath/v1/a/b
il
è impostata su b
.
Specificare più pattern
Puoi specificare più pattern da abbinare, corrispondenti ai tag <Pattern>
,
dove:
- Tutti i pattern vengono testati per rilevare la corrispondenza.
- Se nessuno dei pattern corrisponde, il criterio non fa nulla e la variabile o le variabili non è stato creato.
- Se più pattern corrispondono, quello con i segmenti di percorso più lunghi viene utilizzato l'estrazione dei contenuti.
- Se due pattern corrispondenti hanno gli stessi segmenti di percorso più lunghi, il pattern specificato per primo in il criterio viene usato per l'estrazione.
Nel prossimo esempio, creerai un criterio che contiene tre pattern corrispondenti per l'URI percorso:
<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>
Supponiamo, per un proxy API con percorso base /basepath/v1
, che l'URL della richiesta in entrata
al proxy API ha il seguente formato:
http://myCo.com/basepath/v1/a/b
In questo esempio, il primo pattern corrisponde all'URI e al urirequest.pathSeg
è impostata su b
.
Se l'URL della richiesta è:
http://myCo.com/basepath/v1/a/b/c/d
...il terzo pattern corrisponde e la variabile urirequest.pathSeg
è
impostato su d
.
Specificare i pattern con più variabili
Puoi specificare più variabili nel pattern corrispondente. Ad esempio, specifichi un pattern corrispondente con due variabili:
<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>
Di nuovo se supponiamo un proxy API con un percorso di base /basepath/v1
per la richiesta in entrata
URL:
http://myCo.com/basepath/v1/a/b/c/d
...la variabile urirequest.pathSeg1
è impostata su b
e la
La variabile urirequest.pathSeg2
è impostata su d
.
Corrispondenza di più istanze nel pattern
Puoi anche far corrispondere i pattern quando sono presenti più istanze di un elemento con lo stesso nome. Ad esempio, puoi effettuare una richiesta contenente più parametri di ricerca o più intestazioni con lo stesso nome. La seguente richiesta contiene due parametri di ricerca denominati "w":
http://myCo.com/basepath/v1/a/b/c/d?w=1&w=2
Per fare riferimento a questi parametri di ricerca nel criterio ExtractVariables, puoi usare gli indici, dove la prima istanza del parametro di query non ha un indice, la seconda si trova all'indice 2, la terza all'indice indice 3 e così via. Ad esempio, il seguente criterio estrae il valore del secondo parametro di query denominato "w" nella richiesta:
<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 variabile urirequest.secondW
è
impostato su "2". Se il secondo parametro di query viene omesso dalla richiesta,
La variabile urirequest.secondW
è
vuoto. Utilizza l'indicizzazione ogni volta che nella richiesta sono presenti più elementi con lo stesso nome.
Utilizzo di caratteri speciali nel pattern
Quando cerchi corrispondenze per i percorsi degli URI, puoi utilizzare il carattere "*" e "**" caratteri jolly nel pattern, dove:
- "*" corrisponde a qualsiasi segmento del percorso
- "**" corrisponde a più segmenti del percorso
Ad esempio, specifichi i pattern per l'elemento <URIPath>
come mostrato
sotto:
<URIPath> <Pattern ignoreCase="true">/a/*/{id}</Pattern> <Pattern ignoreCase="true">/a/**/{id}</Pattern> </URIPath>
Il primo pattern associa le richieste ai pathuffix (la parte del percorso dell'URI che segue basepath) come "/a/b/c", "/a/foo/bar" e così via. Il secondo pattern corrisponde a un numero qualsiasi di percorsi segmenti dopo "/a/", ad esempio "/a/foo/bar/baz/c", nonché "/a/b/c" e "/a/foo/bar".
Quando specifichi i pattern per parametri di ricerca, le intestazioni e i parametri del modulo, il carattere "*" che deve corrispondere a un qualsiasi numero di caratteri. Ad esempio, quando cerchi una corrispondenza per un'intestazione, specifica come:
*;charset={encoding}
Questo pattern corrisponde ai valori "text/xml;charset=UTF-16" e "application/xml;charset=ASCII".
Se il valore passato al criterio ExtractVariables contiene un carattere speciale, come "{", utilizza "%" come carattere di escape. L'esempio seguente fa precedere da una sequenza di escape "{" e "}" caratteri nel pattern perché vengono usati come caratteri letterali nel valore della query :
<QueryParam> <Pattern ignoreCase="true">%{user%} {name}</Pattern> </QueryParam>
In questo esempio, il pattern corrisponde al valore "{user}" Steve" ma non il valore "utente Stefano".
JSON e XML corrispondenti
Quando estrai i dati da JSON e XML, devi specificare uno o più <Variable>
tag nel criterio.
Il tag <Variable>
specifica
nome della variabile di destinazione in cui sono archiviate le informazioni estratte e JsonPath
(JSON) o XPATH (XML) alle informazioni estratte.
Tutti i <Variable>
tag nel criterio
vengono valutati, in modo da poter completare più variabili da un unico criterio. Se
il tag <Variable>
non
restituisce un campo valido nel file JSON o XML, la variabile corrispondente non
è stato creato.
L'esempio seguente mostra un criterio ExtractVariables che compila due variabili dalla Corpo JSON di una risposta:
<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>
Scrivendo al stessa variabile in più posizioni
Fai attenzione quando scegli i nomi delle variabili da impostare. Il criterio viene eseguito in sequenza da dal primo pattern di estrazione all'ultimo. Se il criterio scrive un valore nella stessa variabile da più posizioni, l'ultima scrittura nel criterio determina il valore della variabile. (Potrebbe trattarsi ovvero ciò che vuoi.
Ad esempio, vuoi estrarre un valore del token che può essere passato in un parametro di query o in un'intestazione, come mostrato di seguito:
<!-- 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>
Controllo di ciò che accade in assenza di corrispondenze
Se il pattern non corrisponde, la variabile corrispondente non viene creata. Pertanto, se un altro criterio fa riferimento alla variabile, questo può causare un errore.
Un'opzione è impostare <IgnoreUnresolvedVariables>
su
true in un criterio che fa riferimento alla variabile per configurare il criterio da trattare
qualsiasi variabile non risolvibile come stringa vuota (null):
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
Riferimento elemento
Il riferimento all'elemento descrive gli elementi e gli attributi di ExtractVariables .
<ExtractVariables async="false" continueOnError="false" enabled="true" name="Extract-Variables-1"> <DisplayName> 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>
<ExtractVariables> attributi
<ExtractVariables async="false" continueOnError="false" enabled="true" name="Extract-Variables-1">
La tabella seguente descrive gli attributi comuni a tutti gli elementi principali dei criteri:
Attributo | Descrizione | Predefinito | Presenza |
---|---|---|---|
name |
Il nome interno della norma. Il valore dell'attributo Facoltativamente, utilizza l'elemento |
N/A | Obbligatorio |
continueOnError |
Impostalo su Imposta su |
false | Facoltativo |
enabled |
Imposta il criterio su Impostala su |
true | Facoltativo |
async |
Questo attributo è obsoleto. |
false | Deprecata |
Elemento <DisplayName>
Utilizzalo in aggiunta all'attributo name
per etichettare il criterio nell'editor proxy dell'interfaccia utente di gestione con un nome diverso in linguaggio naturale.
<DisplayName>Policy Display Name</DisplayName>
Predefinito |
N/A Se ometti questo elemento, viene utilizzato il valore dell'attributo |
---|---|
Presenza | Facoltativo |
Tipo | Stringa |
<Source> elemento
(Facoltativo) Specifica la variabile da analizzare. Il valore di
Il valore predefinito di <Source>
è message
. Il valore message
è sensibile al contesto. In un flusso di richiesta, message
si risolve nel messaggio di richiesta. Nel
un flusso di risposta, message
si risolve nel messaggio di risposta.
Anche se spesso utilizzi questo criterio per estrarre informazioni da un messaggio di richiesta o di risposta,
puoi utilizzarlo per estrarre informazioni da qualsiasi variabile. Ad esempio, puoi usarlo per estrarre
informazioni di un'entità creata dal criterio AccessEntity, dai dati
restituiti dal criterio ServiceCallout oppure estrarre informazioni da un oggetto XML o JSON.
Se non è possibile risolvere <Source>
o se viene risolto in un tipo non messaggio,
il criterio non risponderà.
<Source clearPayload="true|false">request</Source>
Predefinita: | messaggio |
Presenza: | Facoltativo |
Tipo: | Stringa |
Attributi
Attributo | Descrizione | Predefinito | Presenza | Tipo |
---|---|---|---|---|
clearPayload |
Impostalo su true se vuoi cancellare il payload specificato in
Utilizza l'opzione |
falso |
Facoltativo | Booleano |
<VariablePrefix> elemento
(Facoltativo) Il nome completo della variabile viene creato unendo il valore
<VariablePrefix>
, un punto e il nome che definisci tra {parentesi graffe} in
Elemento <Pattern>
o elemento <Variable>
. Ad esempio:
myprefix.id
, myprefix.dbncode
o myprefix.oauthtoken.
<VariablePrefix>myprefix</VariablePrefix>
Ad esempio, supponiamo che il valore del nome sia "utente".
- Se
<VariablePrefix>
non viene specificato, i valori estratti vengono assegnato a una variabile denominatauser
. - Se
<VariablePrefix>
viene specificato come mioprefisso, il valore estratto I valori sono assegnati a una variabile denominatamyprefix.user
.
Predefinita: | N/D |
Presenza: | Facoltativo |
Tipo: | Stringa |
<IgnoreUnresolvedVariables> elemento
(Facoltativo) Imposta su true
per trattare qualsiasi variabile non risolvibile come stringa vuota
(nullo). Imposta su false
se vuoi che il criterio generi un errore quando viene fatto riferimento
non è risolvibile.
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
Predefinita: | Falso |
Presenza: | Facoltativo |
Tipo: | Booleano |
<URIPath> elemento
(Facoltativo, ma per saperne di più consulta la riga Presenza nella tabella seguente). Estrae un valore
dal proxy.pathsuffix di un messaggio di origine request
. Il percorso applicato a
il pattern è proxy.pathsuffix, che non include il basepath per il proxy API. Se
il messaggio di origine si risolve in un tipo di messaggio di response
, questo elemento non fa nulla.
<URIPath> <Pattern ignoreCase="false">/accounts/{id}</Pattern> </URIPath>
È possibile utilizzare più elementi <Pattern>
:
<URIPath> <Pattern ignoreCase="false">/accounts/{id}</Pattern> <Pattern ignoreCase="false">/accounts/{id}/transactions/{index}</Pattern> </URIPath>
Predefinita: | N/D |
Presenza: | Facoltativo. Tuttavia, devi includere almeno uno dei seguenti elementi:
<URIPath> , <QueryParam> , <Header>
<FormParam> , <JSONPayload> o
<XMLPayload>. |
Tipo: | N/D |
Attributi
Attributo | Descrizione | Predefinito | Presenza | Tipo |
---|---|---|---|---|
ignoreCase | Specifica di ignorare le maiuscole e le minuscole quando corrisponde alla descrizione. |
falso |
Facoltativo | Booleano |
<QueryParam> elemento
(Facoltativo, ma per saperne di più consulta la riga Presenza nella tabella seguente). Estrae un valore
dal parametro di query specificato di un messaggio di origine request
. Se
il messaggio di origine si risolve in un tipo di messaggio di response
, questo elemento
niente.
<QueryParam name="code"> <Pattern ignoreCase="true">DBN{dbncode}</Pattern> </QueryParam>
Se più parametri di ricerca hanno lo stesso nome, utilizza gli indici per fare riferimento ai parametri:
<QueryParam name="w.2"> <Pattern ignoreCase="true">{secondW}</Pattern> </QueryParam>
Predefinita: | N/D |
Presenza: | Facoltativo. Tuttavia, devi includere almeno uno dei seguenti elementi:
<URIPath> , <QueryParam> , <Header>
<FormParam> , <JSONPayload> o
<XMLPayload>. |
Tipo: | N/D |
Attributi
Attributo | Descrizione | Predefinito | Presenza | Tipo |
---|---|---|---|---|
nome | Specifica il nome del parametro di query. Se più parametri di ricerca hanno lo stesso nome, usa i riferimenti indicizzati, in cui la prima istanza del parametro di query non ha un indice, il secondo è all'indice 2, il terzo all'indice 3, ecc. |
N/D |
Obbligatorio | Stringa |
<Header> elemento
(Facoltativo, ma per saperne di più consulta la riga Presenza nella tabella seguente). Estrae un valore
dall'intestazione HTTP specificata dell'elemento request
specificato
response
messaggio. Se più intestazioni contengono
con lo stesso nome, i relativi valori sono archiviati in un array.
<!-- 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>
Se più intestazioni hanno lo stesso nome, utilizza gli indici per fare riferimento alle singole intestazioni nella array:
<Header name="myHeader.2"> <Pattern ignoreCase="true">{secondHeader}</Pattern> </Header>
o di seguito per elencare tutte le intestazioni nell'array:
<Header name="myHeader.values"> <Pattern ignoreCase="true">{myHeaders}</Pattern> </Header>
Predefinita: | N/D |
Presenza: | Facoltativo. Tuttavia, devi includere almeno uno dei seguenti elementi:
<URIPath> , <QueryParam> , <Header>
<FormParam> , <JSONPayload> o
<XMLPayload>. |
Tipo: | N/D |
Attributi
Attributo | Descrizione | Predefinito | Presenza | Tipo |
---|---|---|---|---|
nome | Specifica il nome dell'intestazione da cui estrai il valore. Se più
hanno lo stesso nome, usa riferimenti indicizzati, in cui la prima istanza
intestazione non ha un indice, la seconda è all'indice 2, la terza all'indice 3 e così via.
.values per ottenere tutte le intestazioni nell'array. |
N/D |
Obbligatorio | Stringa |
<FormParam> elemento
(Facoltativo, ma per saperne di più consulta la riga Presenza nella tabella seguente). Estrae un valore
dal parametro di modulo specificato del valore di request
o response
specificato
. Parametri modulo
può essere estratta solo quando l'intestazione Content-Type
del messaggio specificato è
application/x-www-form-urlencoded
.
<FormParam name="greeting"> <Pattern>hello {user}</Pattern> </FormParam>
Predefinita: | N/D |
Presenza: | Facoltativo. Tuttavia, devi includere almeno uno dei seguenti elementi:
<URIPath> , <QueryParam> , <Header>
<FormParam> , <JSONPayload> o
<XMLPayload>. |
Tipo: | N/D |
Attributi
Attributo | Descrizione | Predefinito | Presenza | Tipo |
---|---|---|---|---|
nome | Il nome del parametro del modulo da cui estrai il valore. |
N/D |
Obbligatorio | Stringa |
<Variable> elemento
(Facoltativo, ma per saperne di più consulta la riga Presenza nella tabella seguente). Specifica la il nome di una variabile da cui estrarre un valore.
<Variable name="myVar"> <Pattern>hello {user}</Pattern> </Variable>
Per estrarre due valori dalla variabile:
<Variable name="myVar"> <Pattern>hello {firstName} {lastName}</Pattern> </Variable>
Predefinita: | N/D |
Presenza: | Facoltativo. Tuttavia, devi includere almeno uno dei seguenti elementi:
<URIPath> , <QueryParam> , <Header>
<FormParam> , <JSONPayload> o
<XMLPayload>. |
Tipo: | N/D |
Attributi
Attributo | Descrizione | Predefinito | Presenza | Tipo |
---|---|---|---|---|
nome | Il nome della variabile da cui estrarre il valore. |
N/D |
Obbligatorio | Stringa |
<JSONPayload> elemento
(Facoltativo, ma per saperne di più consulta la riga Presenza nella tabella seguente). Specifica la
Messaggio in formato JSON da cui verrà estratto il valore della variabile. JSON
viene eseguita solo quando l'intestazione Content-Type
del messaggio
application/json
.
<JSONPayload> <Variable name="name" type="string"> <JSONPath>{example}</JSONPath> </Variable> </JSONPayload>
Predefinita: | N/D |
Presenza: | Facoltativo. Tuttavia, devi includere almeno uno dei seguenti elementi:
<URIPath> , <QueryParam> , <Header>
<FormParam> , <JSONPayload> o
<XMLPayload>. |
Tipo: | N/D |
<JSONPayload>/<Variable> elemento
(Obbligatorio all'interno dell'elemento JSONPayload). Specifica la variabile in cui il valore estratto è
assegnati. Puoi includere più tag <Variable>
nella
<JSONPayload>
elemento da compilare
più variabili.
<Variable name="name" type="string"> <JSONPath>{example}</JSONPath> </Variable>
Predefinita: | N/D |
Presenza: | Obbligatorio all'interno dell'elemento JSONPayload. |
Tipo: | N/D |
Attributi
Attributo | Descrizione | Predefinito | Presenza | Tipo |
---|---|---|---|---|
nome |
Specifica il nome della variabile in cui verrà estratto il valore assegnati. |
nome |
Obbligatorio | Stringa |
tipo | Specifica il tipo di dati del valore della variabile. | N/D | Facoltativo |
Stringa. Seleziona da:
|
<JSONPayload>/<Variable>/<JSONPath> elemento
(Obbligatorio all'interno dell'elemento JSONPayload:Variable.) Specifica il percorso JSON utilizzato per estrarre un da un messaggio in formato JSON.
<Variable name="name"> <JSONPath>$.rss.channel.title</JSONPath> </Variable>
Predefinita: | N/D |
Presenza: | Obbligatorio |
Tipo: | Stringa |
<XMLPayload> elemento
(Facoltativo, ma per saperne di più consulta la riga Presenza nella tabella seguente). Specifica il parametro
Messaggio in formato XML da cui verrà estratto il valore della variabile. Payload XML
vengono estratte solo quando l'intestazione Content-Type
del messaggio
è text/xml
, application/xml
,
o 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>
Predefinita: | N/D |
Presenza: | Facoltativo. Tuttavia, devi includere almeno uno dei seguenti elementi:
<URIPath> , <QueryParam> , <Header>
<FormParam> , <JSONPayload> o
<XMLPayload>. |
Tipo: | N/D |
Attributi
Attributo | Descrizione | Predefinito | Presenza | Tipo |
---|---|---|---|---|
stopPayloadProcessing |
Imposta su |
falso |
Facoltativo | Booleano |
<XMLPayload>/<Namespaces> elemento
(Facoltativo) Specifica lo spazio dei nomi da utilizzare nella valutazione di XPath. Se utilizzi nelle tue espressioni XPath, devi dichiarare gli spazi dei nomi qui, come mostrato dall'esempio seguente.
<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>
Se non utilizzi gli spazi dei nomi nelle espressioni XPath, puoi omettere o commentare il
<Namespaces>
, come mostrato nell'esempio seguente:
<XMLPayload stopPayloadProcessing="false"> <!-- <Namespaces/> --> <Variable name="legName" type="string"> <XPath>/Directions/route/leg/name</XPath> </Variable> </XMLPayload>
Predefinita: | N/D |
Presenza: | Facoltativo |
Tipo: | Stringa |
Attributi
Attributo | Descrizione | Predefinito | Presenza | Tipo |
---|---|---|---|---|
prefix |
Il prefisso dello spazio dei nomi. |
N/D |
Obbligatorio | Stringa |
<XMLPayload>/<Variable> elemento
(Facoltativo) Specifica la variabile a cui verrà assegnato il valore estratto.
<Variable name="name" type="boolean"> <XPath>/test/example</XPath> </Variable>
Predefinita: | N/D |
Presenza: | Facoltativo |
Tipo: | N/D |
Attributi
Attributo | Descrizione | Predefinito | Presenza | Tipo |
---|---|---|---|---|
nome |
Specifica il nome della variabile in cui verrà estratto il valore assegnati. |
nome |
Obbligatorio | Stringa |
tipo | Specifica il tipo di dati del valore della variabile. | Booleano | Facoltativo |
Stringa. Seleziona da:
|
<XMLPayload>/<Variable>/<XPath> elemento
(Obbligatorio all'interno dell'elemento XMLPayload:Variable.) Specifica l'XPath definito per . Sono supportate solo espressioni XPath 1.0.
<Variable name="name" type="boolean"> <XPath>/test/example</XPath> </Variable>
Esempio con uno spazio dei nomi. Se utilizzi gli spazi dei nomi nelle espressioni XPath, devi dichiarare
gli spazi dei nomi
Sezione <XMLPayload><Namespaces>
delle norme.
<Variable name="name" type="boolean"> <XPath>/foo:test/foo:example</XPath> </Variable>
Predefinita: | N/D |
Presenza: | Obbligatorio |
Tipo: | Stringa |
Messaggi di errore
This section describes the fault codes and error messages that are returned and fault variables that are set by Apigee when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.
Runtime errors
These errors can occur when the policy executes.
Fault code | HTTP status | Cause | Fix |
---|---|---|---|
steps.extractvariables.ExecutionFailed |
500 |
This error occurs when:
|
build |
steps.extractvariables.ImmutableVariable |
500 |
A variable used in the policy is immutable. The policy was unable to set this variable. | N/A |
steps.extractvariables.InvalidJSONPath |
500 |
This error occurs if an invalid JSON path is used in the JSONPath element of the
policy. For example, if a JSON payload does not have the object Name ,
but you specify Name as the path in the policy, then this error occurs. |
build |
steps.extractvariables.JsonPathParsingFailure |
500 |
This error occurs when the policy is unable to parse a JSON path and
extract data from the flow variable specified in Source element. Typically this
happens if the flow variable specified in the Source element does not exist in the current
flow. |
build |
steps.extractvariables.SetVariableFailed |
500 |
This error occurs if the policy could not set the value to a variable. The error generally happens if you try to assign values to multiple variables whose names start with the same words in a nested dot-separated format. | build |
steps.extractvariables.SourceMessageNotAvailable |
500 |
This error occurs if the message
variable specified in the Source element of the policy
is either:
|
build |
steps.extractvariables.UnableToCast |
500 |
This error occurs if the policy was unable to cast the extracted value to a variable. Typically this happens if you attempt to set the value of one data type to a variable of another data type. | build |
Deployment errors
These errors can occur when you deploy a proxy containing this policy.
Error name | Cause | Fix |
---|---|---|
NothingToExtract |
If the policy does not have any of the elements URIPath , QueryParam ,
Header , FormParam , XMLPayload , or JSONPayload ,
the deployment of the API Proxy fails, because there's nothing to extract. |
build |
NONEmptyPrefixMappedToEmptyURI |
This error occurs if the policy has a prefix defined in the
Namespace element under the XMLPayload element, but no URI is
defined. |
build |
DuplicatePrefix |
This error occurs if the policy has the same prefix defined more than
once in the Namespace element under the XMLPayload element. |
build |
NoXPathsToEvaluate |
If the policy does not have the XPath element within the
XMLPayload element, then the deployment of the API proxy fails with this error.
|
build |
EmptyXPathExpression |
If the policy has an empty XPath expression within the XMLPayload
element, then the deployment of the API proxy fails. |
build |
NoJSONPathsToEvaluate |
If the policy does not have the JSONPath element within the
JSONPayload element, then the deployment of the API proxy fails with this error. |
build |
EmptyJSONPathExpression |
If the policy has an empty XPath expression within the
XMLPayload element, then the deployment of the API proxy fails. |
build |
MissingName |
If the policy does not have the name attribute in any of the policy
elements like QueryParam , Header , FormParam or
Variable , where it is required, then the deployment of the API proxy fails. |
build |
PatternWithoutVariable |
If the policy does not have a variable specified within the Pattern element,
then the deployment of the API proxy fails. The Pattern element requires the name of
the variable in which extracted data will be stored. |
build |
CannotBeConvertedToNodeset |
If the policy has an XPath expression where the Variable type
is defined as nodeset,
but the expression cannot be converted to nodeset, then the deployment of the API proxy fails. |
build |
JSONPathCompilationFailed |
The policy could not compile a specified JSON Path. | N/A |
InstantiationFailed |
The policy could not be instantiated. | N/A |
XPathCompilationFailed |
If the prefix or the value used in the XPath element is not part of any of the
declared namespaces in the policy, then the deployment of the API proxy
fails. |
build |
InvalidPattern |
If the Pattern element definition is invalid in any of the elements like URIPath ,
QueryParam , Header , FormParam , XMLPayload
or JSONPayload within the policy, then the deployment of the
API proxy fails.
|
build |
Fault variables
These variables are set when this policy triggers an error at runtime. For more information, see What you need to know about policy errors.
Variables | Where | Example |
---|---|---|
fault.name="fault_name" |
fault_name is the name of the fault, as listed in the Runtime errors table above. The fault name is the last part of the fault code. | fault.name = "SourceMessageNotAvailable" |
extractvariables.policy_name.failed |
policy_name is the user-specified name of the policy that threw the fault. | extractvariables.EV-ParseJsonResponse.failed = true |
Example error response
{ "fault":{ "detail":{ "errorcode":"steps.extractvariables.SourceMessageNotAvailable" }, "faultstring":"request message is not available for ExtractVariable: EV-ParseJsonResponse" } }
Example fault rule
<FaultRule name="Extract Variable Faults"> <Step> <Name>AM-CustomErrorMessage</Name> <Condition>(fault.name = "SourceMessageNotAvailable") </Condition> </Step> <Condition>(extractvariables.EM-ParseJsonResponse.failed = true) </Condition> </FaultRule>
Schemi
Argomenti correlati
Riferimento per le variabili di flusso