Questa pagina si applica ad Apigee e Apigee hybrid.
Visualizza la documentazione di Apigee Edge.
Cosa
Il criterio ExtractVariables estrae i contenuti da una richiesta o una risposta e imposta il valore di una variabile su questi contenuti. Puoi estrarre qualsiasi parte del messaggio, incluse intestazioni, percorsi URI, payload JSON/XML, parametri del modulo e parametri di ricerca. Il criterio funziona applicando un pattern di testo ai contenuti del messaggio e, quando viene trovata una corrispondenza, imposta una variabile con i contenuti del messaggio specificati.
Sebbene tu utilizzi spesso ExtractVariables per estrarre informazioni da un messaggio di richiesta o risposta, puoi utilizzarlo anche per estrarre informazioni da altre origini, tra cui entità create dal Regolamento AccessEntity, oggetti XML o oggetti JSON.
Dopo aver estratto i contenuti del messaggio specificati, puoi fare riferimento alla variabile in altre norme nell'ambito dell'elaborazione di una richiesta e di una risposta.
Questo criterio è un criterio estensibile e il suo utilizzo potrebbe comportare implicazioni in termini di costi o utilizzo, a seconda della licenza Apigee. Per informazioni sui tipi di criteri e sulle implicazioni per l'utilizzo, consulta Tipi di criteri.
Video
Guarda i seguenti video per saperne di più sulle norme relative a ExtractVariables.
Video | Descrizione |
---|---|
Estrarre le variabili dal payload XML | Estrai le variabili da un payload XML utilizzando il criterio Estrazione variabile. |
Estrarre le variabili dal payload JSON | Estrai le variabili da un payload JSON utilizzando il criterio Estrai variabile. |
Estrarre le variabili dai parametri | Estrai le variabili dai parametri, ad esempio parametri di query, intestazione, modulo o URI. |
Estrarre variabili dai parametri multivalore | Estrai le variabili dai parametri con più valori. |
Esempi
Questi esempi di codice delle norme mostrano come estrarre le variabili dai seguenti tipi di elementi:
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 delle norme di esempio riportato sopra. L'elemento <URIPath>
indica al
criterio ExtractVariables di estrarre informazioni dal percorso dell'URI. L'elemento
<Pattern>
specifica il pattern da applicare al percorso dell'URI. Il
pattern 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 nell'elemento
<VariablePrefix>
, nonché dal valore racchiuso tra parentesi graffe {}
nell'elemento <Pattern>
. I due valori sono uniti da un punto intermedio,
ad esempio il nome di una variabile è urirequest.id
. Se non è presente
Elemento <VariablePrefix>
, il nome della variabile è semplicemente il valore
racchiuso tra parentesi graffe.
Considera il codice del criterio di esempio riportato sopra che 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 a questa richiesta in arrivo, imposta la variabile urirequest.id
su 12797282
. Dopo che Apigee ha eseguito il criterio,
i criteri o il codice successivi nel flusso di elaborazione possono fare riferimento alla variabile urirequest.id
per ottenere il valore della stringa 12797282
.
Ad esempio, il seguente criterio AssignMessage incorpora il valore della variabile nel 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 il codice del criterio di esempio riportato sopra che 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 arrivo, imposta la variabile queryinfo.dbncode
su 88271
. Dopo che Apigee
ha eseguito il criterio, i criteri o il codice successivi nel flusso di elaborazione possono fare riferimento alla
variabile denominata queryinfo.dbncode
per ottenere il valore di stringa 88271
.
Ora puoi accedere alla variabile queryinfo.dbncode
nel proxy.
Ad esempio, il seguente criterio AssignMessage 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 il design dell'API ti consenta di specificare più parametri di ricerca con lo stesso nome. Puoi utilizzare un criterio ExtractVariables per estrarre il valore di più istanze del parametro di query. Per fare riferimento parametri di ricerca con lo stesso nome nel criterio, utilizza gli indici in cui la prima istanza del parametro di query non ha indice, la seconda è all'indice 2, la terza all'indice 3 e così via.
Considera il codice del criterio di esempio riportato sopra che 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 arrivo,
imposta la variabile queryinfo.firstWeather
su Boston
e la
variabile queryInfo.secondWeather
su Chicago
.
Ora puoi accedere alle variabili queryinfo.firstWeather
e
queryinfo.secondWeather
nel
tuo proxy. Ad esempio, il seguente criterio AssignMessage lo copia nel payload della
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 la tua API utilizzi token bearer OAuth 2.0. Considera il codice delle norme di esempio riportato sopra
che funziona con una richiesta contenente un token OAuth 2.0 che include un'intestazione come questa:
Authorization: Bearer TU08xptfFfeM7aS0xHqlxTgEAdAM.
In qualità di progettista dell'API, supponiamo che tu voglia utilizzare il valore del token (ma non l'intera intestazione) come chiave in una ricerca nella cache. Puoi utilizzare il codice delle norme ExtractVariables riportato sopra per estrarre il token.
Quando Apigee applica il codice del criterio ExtractVariables riportato sopra a questo intestazione, imposta la variabile clientrequest.oauthtoken
su TU08xptfFfeM7aS0xHqlxTgEAdAM
.
Ora puoi accedere alla variabile clientrequest.oauthtoken
nel
tuo proxy. Ad esempio, il seguente criterio AssignMessage lo copia nel payload della
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>
Prendi in considerazione il seguente payload della 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 variabile di
geocoderesponse
. Il suffisso per queste variabili viene specificato esplicitamente dall'attributo name
dell'elemento <Variable>
.
La variabile geocoderesponse.latitude
assume il valore
37.42291810
. La variabile geocoderesponse.longitude
assume il valore
-122.08542120
.
Ora puoi accedere alla variabile geocoderesponse.latitude
nel
tuo proxy. Ad esempio, la seguente norma AssignMessage 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 della 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 della norma ExtractVariables riportato sopra a questo messaggio XML, imposta tre variabili:
directionsresponse.travelmode
: restituisce il valoreDRIVING
directionsresponse.duration
: restituisce il valore19
directionsresponse.timeunit
: restituisce il valoreminutes
Tutte
le variabili utilizzano lo stesso prefisso directionsresponse
. Il suffisso per queste variabili è specificato esplicitamente dall'attributo name
dell'elemento <Variable>
.
Ora puoi accedere alla variabile directionresponse.travelmode
nel
tuo proxy. Ad esempio, la seguente norma AssignMessage la 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 sulle norme relative a ExtractVariables
Gli sviluppatori di API creano proxy API che si comportano in modo diverso in base ai contenuti dei messaggi, tra cui intestazioni, percorsi URI, payload e parametri di ricerca. Spesso il proxy estrae una parte di questi contenuti per utilizzarla in un'istruzione di condizione. Utilizza il criterio ExtractVariables per farlo.
Quando definisci il criterio ExtractVariables, puoi scegliere:
- Nomi delle variabili da impostare
- Origine delle variabili
- Il numero di variabili da estrarre e impostare
Quando viene eseguita, la norma applica un pattern di testo ai contenuti e, quando trova una corrispondenza, imposta il valore della variabile designata con i contenuti. Altre norme e altro codice possono quindi utilizzare queste variabili per attivare il comportamento dinamico o inviare dati aziendali ad Analytics dell'API Apigee.
Ambito
Le variabili impostate con il criterio ExtractVariables hanno un ambito globale. In altre parole, dopo che il criterio ExtractVariables definisce una nuova variabile, puoi accedere a questa variabile da qualsiasi criterio o codice in qualsiasi fase del flusso (che viene eseguito dopo il criterio ExtractVariables). Sono inclusi:
- PreFlow: ProxyEndpoint e TargetEndpoint (richiesta e risposta)
- PostFlow: ProxyEndpoint e TargetEndpoint (richiesta e risposta)
- PostClientFlow: ProxyEndpoint (solo risposta, utilizzando il MessageLogging policy>)
- Flussi di errori
Informazioni sulla corrispondenza e sulla creazione di variabili
Il criterio ExtractVariables estrae le informazioni da una richiesta o una risposta e le scrive in una variabile. Per ogni tipo di informazioni che puoi estrarre, ad esempio il percorso URI o i dati XML, specifica il pattern da associare e il nome della variabile utilizzata per memorizzare le informazioni estratte.
Tuttavia, il funzionamento della corrispondenza dei pattern dipende dall'origine dell'estrazione. Le sezioni seguenti descrivono le due categorie di informazioni di base che puoi estrarre.
Corrispondenza di percorsi URI, parametri di ricerca, intestazioni, parametri di modulo e variabili
Quando estrai informazioni da un percorso URI, da parametri di ricerca, intestazioni, parametri di modulo e variabili, utilizza il tag <Pattern>
per specificare uno o più pattern da associare. Ad esempio, il seguente esempio di norme mostra un singolo pattern di corrispondenza per il percorso 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 su ciò che appare in proxy.pathsuffix dopo /a/
. Ad esempio, supponiamo che il
percorso di base del proxy API sia /basepath/v1
. Con una richiesta in entrata
a http://myCo.com/basepath/v1/a/b
la
variabile è impostata su b
.
Specificare più pattern
Puoi specificare più pattern da associare, corrispondenti ai tag <Pattern>
,
dove:
- Viene verificata la corrispondenza di tutti i pattern.
- Se nessuno dei pattern corrisponde, il criterio non fa nulla e le variabili non vengono create.
- Se corrisponde più di un pattern, per l'estrazione viene utilizzato il pattern con i segmenti di percorso più lunghi.
- Se due pattern corrispondenti hanno gli stessi segmenti di percorso più lunghi, per l'estrazione viene utilizzato il pattern specificato per primo nel criterio.
Nell'esempio seguente viene creato un criterio che contiene tre pattern di corrispondenza per il percorso 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>
Supponiamo che, per un proxy API con un percorso base /basepath/v1
, l'URL della richiesta in entrata al proxy API sia di questo tipo:
http://myCo.com/basepath/v1/a/b
In questo esempio, il primo pattern corrisponde all'URI e la variabile urirequest.pathSeg
è impostata su b
.
Se l'URL della richiesta è:
http://myCo.com/basepath/v1/a/b/c/d
...quindi il terzo pattern corrisponde e la variabile urirequest.pathSeg
viene impostata su d
.
Specificare pattern con più variabili
Puoi specificare più variabili nel pattern di corrispondenza. Ad esempio, specifichi un pattern di corrispondenza 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>
Supponiamo ancora un proxy API con un percorso di base /basepath/v1
per l'URL della richiesta in entrata:
http://myCo.com/basepath/v1/a/b/c/d
...la variabile urirequest.pathSeg1
è impostata su b
e la variabile urirequest.pathSeg2
è impostata su d
.
Corrispondenza di più istanze nel pattern
Puoi anche associare pattern quando sono presenti più istanze di un elemento con lo stesso nome. Ad esempio, puoi inviare 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, utilizzi gli indici, dove la prima istanza del parametro di query non ha indice, la seconda è all'indice 2, la terza all'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
è impostata su "2". Se il secondo parametro di query viene omesso dalla richiesta, la variabile urirequest.secondW
è vuota. Utilizza l'indicizzazione ogni volta che nella richiesta sono presenti più elementi con lo stesso nome.
Utilizzo di caratteri speciali nel pattern
Quando corrispondi ai percorsi URI, puoi utilizzare i caratteri jolly "*" e "**" nel pattern, dove:
- "*" corrisponde a uno qualsiasi dei segmenti del percorso
- "**" corrisponde a più segmenti del percorso
Ad esempio, specifichi gli schemi per l'elemento <URIPath>
come mostrato di seguito:
<URIPath> <Pattern ignoreCase="true">/a/*/{id}</Pattern> <Pattern ignoreCase="true">/a/**/{id}</Pattern> </URIPath>
Il primo pattern corrisponde alle richieste con suffissi di percorso (la parte del percorso dell'URI che segue il percorso di base) come "/a/b/c", "/a/foo/bar" e così via. Il secondo pattern corrisponde a qualsiasi numero di segmenti di percorso dopo "/a/", ad esempio "/a/foo/bar/baz/c", nonché "/a/b/c" e "/a/foo/bar".
Quando specifichi pattern per parametri di ricerca, intestazioni e parametri di modulo, il carattere "*" specifica la corrispondenza con un numero qualsiasi di caratteri. Ad esempio, quando corrispondi a un'intestazione, specifica il pattern 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, ad esempio "{", utilizza il carattere "%" per eseguirne l'escape. L'esempio seguente esegue la fuga dei caratteri "{" e "}" nel pattern perché vengono utilizzati come caratteri letterali nel valore del parametro di query:
<QueryParam> <Pattern ignoreCase="true">%{user%} {name}</Pattern> </QueryParam>
In questo esempio, il pattern corrisponde al valore "{user} Steve", ma non al valore "user Steve".
Corrispondenza tra JSON e XML
Quando estrai i dati da JSON e XML, specifica uno o più tag <Variable>
nella norma.
Il tag <Variable>
specifica il nome della variabile di destinazione in cui vengono memorizzate le informazioni estratte e JsonPath (JSON) o XPATH (XML) per le informazioni estratte.
Tutti i tag <Variable>
nel criterio
vengono valutati, in modo da poter compilare più variabili da un singolo criterio. Se il valore del tag <Variable>
non corrisponde a un campo valido in JSON o XML, la variabile corrispondente non viene creata.
L'esempio seguente mostra un criterio ExtractVariables che compila due variabili dal 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>
Scrittura nella stessa variabile in più punti
Fai attenzione quando scegli i nomi delle variabili da impostare. Il criterio viene eseguito in sequenza 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 essere quello che vuoi.
Ad esempio, vuoi estrarre un valore 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>
Controllare cosa succede quando non viene trovata alcuna corrispondenza
Se il pattern non corrisponde, la variabile corrispondente non viene creata. Pertanto, se un'altra norma fa riferimento alla variabile, può verificarsi un errore.
Un'opzione è impostare <IgnoreUnresolvedVariables>
su
true in un criterio che fa riferimento alla variabile per configurare il criterio in modo da trattare
qualsiasi variabile irrisolvibile come una stringa vuota (null):
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
Riferimento elemento
Il riferimento all'elemento descrive gli elementi e gli attributi del criterio 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>
Attributi <ExtractVariables>
<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 del criterio. Il valore dell'attributo Se vuoi, utilizza l'elemento |
N/D | Obbligatorio |
continueOnError |
Imposta su Imposta su |
falso | Facoltativo |
enabled |
Imposta su Imposta |
true | Facoltativo |
async |
Questo attributo è stato ritirato. |
falso | Ritirato |
Elemento <DisplayName>
Da utilizzare insieme 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/D Se ometti questo elemento, viene utilizzato il valore dell'attributo |
---|---|
Presenza | Facoltativo |
Tipo | Stringa |
Elemento <Source>
(Facoltativo) Specifica la variabile da analizzare. Il valore di <Source>
è message
per impostazione predefinita. Il valore message
è sensibile al contesto. In un flusso di richieste, message
si risolve nel messaggio di richiesta. In un flusso di risposta, message
si risolve nel messaggio di risposta.
Sebbene tu utilizzi spesso questo criterio per estrarre informazioni da un messaggio di richiesta o risposta, puoi usarlo per estrarre informazioni da qualsiasi variabile. Ad esempio, puoi utilizzarlo per estrarre informazioni da un'entità creata dal regolamento AccessEntity, dai dati restituiti dal regolamento ServiceCallout o da un oggetto XML o JSON.
Se <Source>
non può essere risolto o se si risolve in un tipo di messaggio diverso,
il criterio non risponderà.
<Source clearPayload="true|false">request</Source>
Valore predefinito: | messaggio |
Presenza: | Facoltativo |
Tipo: | Stringa |
Attributi
Attributo | Descrizione | Predefinito | Presenza | Tipo |
---|---|---|---|---|
clearPayload |
Imposta su true se vuoi cancellare il payload specificato in
Utilizza l'opzione |
falso |
Facoltativo | Booleano |
Elemento <VariablePrefix>
(Facoltativo) Il nome completo della variabile viene creato unendo <VariablePrefix>
, un punto e il nome definito tra {parentesi graffe} nell'elemento <Pattern>
o <Variable>
. Ad esempio:
myprefix.id
, myprefix.dbncode
o myprefix.oauthtoken.
<VariablePrefix>myprefix</VariablePrefix>
Ad esempio, supponiamo che il valore di name sia "user".
- Se
<VariablePrefix>
non è specificato, i valori estratti vengono assegnati a una variabile denominatauser
. - Se
<VariablePrefix>
è specificato come myprefix, i valori estratti vengono assegnati a una variabile denominatamyprefix.user
.
Valore predefinito: | N/D |
Presenza: | Facoltativo |
Tipo: | Stringa |
Elemento <IgnoreUnresolvedVariables>
(Facoltativo) Imposta su true
per trattare qualsiasi variabile non risolvibile come una stringa vuota (null). Imposta su false
se vuoi che il criterio generi un errore quando una variabile a cui viene fatto riferimento non è risolvibile.
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
Valore predefinito: | Falso |
Presenza: | Facoltativo |
Tipo: | Booleano |
Elemento <URIPath>
(Facoltativo, ma per ulteriori informazioni, consulta la riga Presenza nella tabella di seguito). Estrae un valore
da proxy.pathsuffix di un messaggio di origine request
. Il percorso applicato al pattern è proxy.pathsuffix, che non include il percorso base per l'API Proxy. Se il messaggio di origine risolve in un tipo di messaggio 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>
Valore predefinito: | 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/minuscole durante la corrispondenza del pattern. |
falso |
Facoltativo | Booleano |
Elemento <QueryParam>
(Facoltativo, ma per ulteriori informazioni, consulta la riga Presenza nella tabella di seguito). Estrae un valore
dal parametro di query specificato di un messaggio di origine request
. Se il messaggio di origine risolve in un tipo di messaggio response
, questo elemento non fa nulla.
<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>
Valore predefinito: | 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, utilizza il riferimento indicizzato, in cui la prima istanza del parametro di query non ha indice, la seconda è all'indice 2, la terza all'indice 3 e così via. |
N/D |
Obbligatorio | Stringa |
Elemento <Header>
(Facoltativo, ma per ulteriori informazioni, consulta la riga Presenza nella tabella di seguito). Estrae un valore
dall'intestazione HTTP specificata del messaggio request
o
response
specificato. Se più intestazioni hanno lo stesso nome, i relativi valori vengono memorizzati 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 nell'array:
<Header name="myHeader.2"> <Pattern ignoreCase="true">{secondHeader}</Pattern> </Header>
In alternativa, puoi utilizzare il seguente comando per elencare tutte le intestazioni nell'array:
<Header name="myHeader.values"> <Pattern ignoreCase="true">{myHeaders}</Pattern> </Header>
Valore predefinito: | 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ù intestazioni hanno lo stesso nome, utilizza il riferimento indicizzato, in cui la prima istanza dell'intestazione non ha indice, la seconda è all'indice 2, la terza all'indice 3 e così via. Utilizza .values per ottenere tutte le intestazioni nell'array. |
N/D |
Obbligatorio | Stringa |
Elemento <FormParam>
(Facoltativo, ma per ulteriori informazioni, consulta la riga Presenza nella tabella di seguito). Estrae un valore
dal parametro del modulo specificato del messaggio request
o response
specificato. I parametri del modulo
possono essere estratti solo quando l'intestazione Content-Type
del messaggio specificato è
application/x-www-form-urlencoded
.
<FormParam name="greeting"> <Pattern>hello {user}</Pattern> </FormParam>
Valore predefinito: | 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 |
Elemento <Variable>
(Facoltativo, ma per ulteriori informazioni, consulta la riga Presenza nella tabella di seguito). Specifica 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>
Valore predefinito: | 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 |
Elemento <JSONPayload>
(Facoltativo, ma per ulteriori informazioni, consulta la riga Presenza nella tabella di seguito). Specifica il messaggio in formato JSON da cui verrà estratto il valore della variabile. L'estrazione di JSON viene eseguita solo quando l'intestazione Content-Type
del messaggio è application/json
.
<JSONPayload> <Variable name="name" type="string"> <JSONPath>{example}</JSONPath> </Variable> </JSONPayload>
Valore predefinito: | N/D |
Presenza: | Facoltativo. Tuttavia, devi includere almeno uno dei seguenti elementi:
<URIPath> , <QueryParam> , <Header> ,
<FormParam> , <JSONPayload> o
<XMLPayload>. |
Tipo: | N/D |
Elemento <JSONPayload>/<Variable>
(Obbligatorio all'interno dell'elemento JSONPayload). Specifica la variabile a cui viene assegnato il valore estratto. Puoi includere più tag <Variable>
nell'elemento <JSONPayload>
per compilare più variabili.
<Variable name="name" type="string"> <JSONPath>{example}</JSONPath> </Variable>
Valore predefinito: | N/D |
Presenza: | Obbligatorio all'interno dell'elemento JSONPayload. |
Tipo: | N/D |
Attributi
Attributo | Descrizione | Predefinito | Presenza | Tipo |
---|---|---|---|---|
nome |
Specifica il nome della variabile a cui verrà assegnato il valore estratto. |
nome |
Obbligatorio | Stringa |
tipo | Specifica il tipo di dati del valore della variabile. | N/D | Facoltativo |
Stringa. Seleziona una delle seguenti opzioni:
|
Elemento <JSONPayload>/<Variable>/<JSONPath>
(Obbligatorio all'interno dell'elemento JSONPayload:Variable.) Specifica il percorso JSON utilizzato per estrarre un valore da un messaggio in formato JSON.
<Variable name="name"> <JSONPath>$.rss.channel.title</JSONPath> </Variable>
Valore predefinito: | N/D |
Presenza: | Obbligatorio |
Tipo: | Stringa |
Elemento <XMLPayload>
(Facoltativo, ma per ulteriori informazioni, consulta la riga Presenza nella tabella di seguito). Specifica il messaggio in formato XML da cui verrà estratto il valore della variabile. I payload XML
vengono estratti 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>
Valore predefinito: | 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 |
Elemento <XMLPayload>/<Namespaces>
(Facoltativo) Specifica lo spazio dei nomi da utilizzare nella valutazione XPath. Se utilizzi gli spazi dei nomi nelle espressioni XPath, devi dichiararli qui, come mostrato nell'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 l'elemento <Namespaces>
, come illustrato nell'esempio seguente:
<XMLPayload stopPayloadProcessing="false"> <!-- <Namespaces/> --> <Variable name="legName" type="string"> <XPath>/Directions/route/leg/name</XPath> </Variable> </XMLPayload>
Valore predefinito: | N/D |
Presenza: | Facoltativo |
Tipo: | Stringa |
Attributi
Attributo | Descrizione | Predefinito | Presenza | Tipo |
---|---|---|---|---|
prefix |
Il prefisso dello spazio dei nomi. |
N/D |
Obbligatorio | Stringa |
Elemento <XMLPayload>/<Variable>
(Facoltativo) Specifica la variabile a cui verrà assegnato il valore estratto.
<Variable name="name" type="boolean"> <XPath>/test/example</XPath> </Variable>
Valore predefinito: | N/D |
Presenza: | Facoltativo |
Tipo: | N/D |
Attributi
Attributo | Descrizione | Predefinito | Presenza | Tipo |
---|---|---|---|---|
nome |
Specifica il nome della variabile a cui verrà assegnato il valore estratto. |
nome |
Obbligatorio | Stringa |
tipo | Specifica il tipo di dati del valore della variabile. | Booleano | Facoltativo |
Stringa. Seleziona una delle seguenti opzioni:
|
Elemento <XMLPayload>/<Variable>/<XPath>
(Obbligatorio all'interno dell'elemento XMLPayload:Variable.) Specifica l'XPath definito per la variabile. Sono supportate solo le 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 dichiararli nella sezione <XMLPayload><Namespaces>
delle norme.
<Variable name="name" type="boolean"> <XPath>/foo:test/foo:example</XPath> </Variable>
Valore predefinito: | N/D |
Presenza: | Obbligatorio |
Tipo: | Stringa |
Messaggi di errore
Questa sezione descrive i codici di errore e i messaggi di errore restituiti e le variabili di errore impostate da Apigee quando questo criterio attiva un errore. Queste informazioni sono importanti se stai sviluppando regole di errore per gestire gli errori. Per scoprire di più, consulta Informazioni importanti sugli errori relativi alle norme e Gestione degli errori.
Errori di runtime
Questi errori possono verificarsi durante l'esecuzione del criterio.
Codice guasto | Stato HTTP | Causa | Correggi |
---|---|---|---|
steps.extractvariables.ExecutionFailed |
500 |
Questo errore si verifica quando:
|
build |
steps.extractvariables.ImmutableVariable |
500 |
Una variabile utilizzata nel criterio è immutabile. Il criterio non è riuscito a impostare questa variabile. | N/D |
steps.extractvariables.InvalidJSONPath |
500 |
Questo errore si verifica se nell'elemento JSONPath del
criterio viene utilizzato un percorso JSON non valido. Ad esempio, se un payload JSON non contiene l'oggetto Name ,
ma specifichi Name come percorso nel criterio, si verifica questo errore. |
build |
steps.extractvariables.JsonPathParsingFailure |
500 |
Questo errore si verifica quando il criterio non è in grado di analizzare un percorso JSON ed estrarre i dati dalla variabile di flusso specificata nell'elemento Source . In genere questo accade se la variabile di flusso specificata nell'elemento Source non esiste nel flusso corrente. |
build |
steps.extractvariables.SetVariableFailed |
500 |
Questo errore si verifica se il criterio non è riuscito a impostare il valore su una variabile. In genere, l'errore si verifica se si tenta di assegnare valori a più variabili i cui nomi iniziano con le stesse parole in un formato nidificato separato da punti. | build |
steps.extractvariables.SourceMessageNotAvailable |
500 |
Questo errore si verifica se la variabile message
specificata nell'elemento Source del criterio è:
|
build |
steps.extractvariables.UnableToCast |
500 |
Questo errore si verifica se il criterio non è stato in grado di eseguire il casting del valore estratto in una variabile. In genere, questo accade se si tenta di impostare il valore di un tipo di dati su una variabile di un altro tipo di dati. | build |
Errori di deployment
Questi errori possono verificarsi quando esegui il deployment di un proxy contenente questo criterio.
Nome dell'errore | Causa | Correggi |
---|---|---|
NothingToExtract |
Se il criterio non contiene nessuno degli elementi URIPath , QueryParam ,
Header , FormParam , XMLPayload o JSONPayload ,
il deployment del proxy API non va a buon fine perché non c'è nulla da estrarre. |
build |
NONEmptyPrefixMappedToEmptyURI |
Questo errore si verifica se il criterio ha un prefisso definito nell'elemento Namespace all'interno dell'elemento XMLPayload , ma non è definito alcun URI. |
build |
DuplicatePrefix |
Questo errore si verifica se il criterio ha lo stesso prefisso definito più di
una volta nell'elemento Namespace nell'elemento XMLPayload . |
build |
NoXPathsToEvaluate |
Se il criterio non contiene l'elemento XPath all'interno dell'elemento
XMLPayload , il deployment del proxy API non va a buon fine con questo errore.
|
build |
EmptyXPathExpression |
Se il criterio contiene un'espressione XPath vuota all'interno dell'elemento XMLPayload , il deployment del proxy API non va a buon fine. |
build |
NoJSONPathsToEvaluate |
Se il criterio non contiene l'elemento JSONPath all'interno dell'elemento
JSONPayload , il deployment del proxy API non va a buon fine con questo errore. |
build |
EmptyJSONPathExpression |
Se il criterio contiene un'espressione XPath vuota all'interno dell'elemento
XMLPayload , il deployment del proxy API non va a buon fine. |
build |
MissingName |
Se il criterio non ha l'attributo name in nessuno degli elementi del criterio come QueryParam , Header , FormParam o
Variable , dove è obbligatorio, il deployment del proxy API non va a buon fine. |
build |
PatternWithoutVariable |
Se il criterio non ha una variabile specificata all'interno dell'elemento Pattern ,
il deployment del proxy API non va a buon fine. L'elemento Pattern richiede il nome della variabile in cui verranno memorizzati i dati estratti. |
build |
CannotBeConvertedToNodeset |
Se il criterio contiene un'espressione XPath in cui il tipo Variable è definito come nodeset, ma l'espressione non può essere convertita in nodeset, il deployment del proxy API non va a buon fine. |
build |
JSONPathCompilationFailed |
Il criterio non è riuscito a compilare un percorso JSON specificato. | N/D |
InstantiationFailed |
Impossibile creare un'istanza del criterio. | N/D |
XPathCompilationFailed |
Se il prefisso o il valore utilizzato nell'elemento XPath non fa parte di uno dei
spazi dei nomi dichiarati nel criterio, il deployment del proxy API
non va a buon fine. |
build |
InvalidPattern |
Se la definizione dell'elemento Pattern non è valida in uno degli elementi come URIPath ,
QueryParam , Header , FormParam , XMLPayload
o JSONPayload all'interno del criterio, il deployment del
proxy API non va a buon fine.
|
build |
Variabili di errore
Queste variabili vengono impostate quando questo criterio attiva un errore in fase di runtime. Per ulteriori informazioni, consulta Informazioni importanti sugli errori relativi alle norme.
Variabili | Dove | Esempio |
---|---|---|
fault.name="fault_name" |
fault_name è il nome dell'errore, come indicato nella tabella Errori di runtime sopra. Il nome dell'errore è l'ultima parte del codice dell'errore. | fault.name = "SourceMessageNotAvailable" |
extractvariables.policy_name.failed |
policy_name è il nome specificato dall'utente del criterio che ha generato l'errore. | extractvariables.EV-ParseJsonResponse.failed = true |
Esempio di risposta di errore
{ "fault":{ "detail":{ "errorcode":"steps.extractvariables.SourceMessageNotAvailable" }, "faultstring":"request message is not available for ExtractVariable: EV-ParseJsonResponse" } }
Esempio di regola di errore
<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 alle variabili di flusso