Oglądasz dokumentację Apigee Edge.
Wyświetl dokumentację Apigee X.

Co
Zasada ExtractVariables wyodrębnia treść z żądania lub odpowiedzi i ustawia w niej wartość zmiennej. Możesz wyodrębnić dowolną część wiadomości, w tym nagłówki, ścieżki URI, ładunki JSON/XML, parametry formularzy i parametry zapytania. Zasada działa poprzez zastosowanie wzorca tekstu do treści wiadomości. Po znalezieniu dopasowania ustawia zmienną ze określoną treścią wiadomości.
Chociaż często używasz tej zasady do wyodrębniania informacji z żądania lub odpowiedzi na żądanie, możesz za jej pomocą wyodrębniać informacje z innych źródeł, w tym elementów tworzonych przez zasady AccessEntity, obiekty XML i obiekty JSON.
Po wyodrębnieniu określonej treści wiadomości możesz odwołać się do zmiennej w innych zasadach podczas przetwarzania żądania i odpowiedzi.
Filmy
Aby dowiedzieć się więcej o zasadach ExtractVariables, obejrzyj te filmy.
Wideo | Opis |
---|---|
Wyodrębnianie zmiennych z ładunku XML | Wyodrębniaj zmienne z ładunku XML za pomocą zasady Extract Variables. |
Wyodrębnij zmienne z ładunku JSON | Wyodrębnij zmienne z ładunku JSON za pomocą zasady Extract Variables. |
Wyodrębnianie zmiennych z parametrów | Wyodrębniaj zmienne z parametrów, takich jak zapytanie, nagłówek, formularz czy parametry identyfikatora URI. |
Wyodrębnij zmienne z parametrów wielowartościowych | Wyodrębniaj zmienne z parametrów wielowartościowych. |
Wyodrębnianie zmiennych z parametru zapytania (Classic Edge) | Wyodrębniaj zmienne z parametru zapytania w interfejsie klasycznej wersji Edge. |
Wyodrębnianie zmiennych z ładunku XML lub JSON (Classic Edge) | Wyodrębniaj zmienne z ładunku XML lub JSON za pomocą interfejsu Classic Edge. |
Sample
Z przykładowego kodu zasad dowiesz się, jak wyodrębniać zmienne z następujących typów artefaktów:
GitHub
Te linki wskazują działające próbki proxy interfejsu API, które możesz wdrożyć i uruchomić na urządzeniu Edge. Wykorzystują one ExtractVariables i znajdują się w repozytorium api-platform-samples w Apigee na GitHubie. README wyjaśniają, jak w poszczególnych przypadkach używane jest narzędzie ExtractVariables, a także wyjaśnia, jak wdrażać i uruchamiać poszczególne przykłady.
- Wyodrębnij i przypisz próbkę zmiennych (wyodrębnij dane z komunikatów JSON i XML)
- Przykład encji dostępu
- Przykład podziału na strony i buforowania
- Przekierowywanie przykładowego docelowego adresu URL
- Przykładowa masowa kompozycja zasad
Identyfikatory 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>
Zobacz przykładowy kod zasad. Element <URIPath>
informuje zasadę ExtractVariables o wyodrębnianiu informacji ze ścieżki identyfikatora URI. Element <Pattern>
określa wzorzec, który należy zastosować do ścieżki identyfikatora URI. Wzorzec jest traktowany jako prosty szablon z nawiasami klamrowymi wskazującymi zmieniającą się część ścieżki identyfikatora URI.
Nazwa zmiennej, którą chcesz ustawić, jest określana na podstawie wartości określonej w elemencie <VariablePrefix>
oraz wartości znajdującej się w nawiasach klamrowych {} w elemencie <Pattern>
. Te dwie wartości są rozdzielone kropką, co skutkuje na przykład nazwą zmiennej urirequest.id
. Jeśli nie ma elementu <VariablePrefix>
, nazwa zmiennej jest tylko wartością w nawiasach klamrowych.
Zapoznaj się z powyższym przykładowym kodem zasad dotyczącym tego przychodzącego żądania:
GET http://org1-test.apigee.net/svc1/accounts/12797282
Załóżmy, że ścieżka bazowa serwera proxy interfejsu API to /svc1
. Gdy Apigee Edge stosuje do powyższego żądania kod zasady ExtractVariables, ustawia zmienną urirequest.id
na 12797282
. Po wykonaniu zasady Apigee Edge kolejne zasady lub kod w procesie przetwarzania mogą odwoływać się do zmiennej o nazwie urirequest.id
, aby uzyskać wartość ciągu 12797282
.
Na przykład zgodnie z tą zasadą AssignMessage umieszczana jest ta wartość zmiennej w ładunku nowej wiadomości z żądaniem:
<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>
Parametry zapytania
<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>
Zapoznaj się z powyższym przykładowym kodem zasad dotyczącym tego przychodzącego żądania:
GET http://org1-test.apigee.net/accounts/12797282?code=DBN88271
Gdy Apigee Edge stosuje do powyższego żądania kod zasady ExtractVariables, ustawia zmienną queryinfo.dbncode
na 88271
. Po wykonaniu zasady Apigee Edge kolejne zasady lub kod w procesie przetwarzania mogą odwoływać się do zmiennej o nazwie queryinfo.dbncode
, aby uzyskać wartość ciągu 88271
.
Zmienna queryinfo.dbncode
jest teraz dostępna na serwerze proxy.
Na przykład ta zasada AssignMessage kopiuje ją do ładunku żądania:
<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>
Wiele parametrów
<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>
Załóżmy, że projekt interfejsu API umożliwia określenie wielu parametrów zapytania o tej samej nazwie. Za pomocą tej zasady możesz wyodrębnić wartość wielu wystąpień parametru zapytania „w”. Aby odwołać się do tych parametrów zapytania w zasadzie ExtractVariables, użyj indeksów, w których pierwsze wystąpienie parametru zapytania nie ma indeksu, drugi to indeks 2, trzeci w indeksie 3 itd.
Zapoznaj się z powyższym przykładowym kodem zasad dotyczącym tego przychodzącego żądania:
GET http://org1-test.apigee.net/weather?w=Boston&w=Chicago
Gdy Apigee Edge stosuje do powyższego żądania kod zasady ExtractVariables, ustawia zmienną queryinfo.firstWeather
na Boston
, a zmienną queryInfo.secondWeather
na Chicago
.
Teraz na serwerze proxy możesz uzyskać dostęp do zmiennej queryinfo.firstWeather
i queryinfo.secondWeather. Na przykład ta zasada AssignMessage kopiuje ją do ładunku żądania:
<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>
nagłówków,
<ExtractVariables name='ExtractVariable-OauthToken'> <Source>request</Source> <Header name="Authorization"> <Pattern ignoreCase="false">Bearer {oauthtoken}</Pattern> </Header> <VariablePrefix>clientrequest</VariablePrefix> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </ExtractVariables>
Załóżmy, że Twój interfejs API wykorzystuje tokeny okaziciela OAuth 2.0. Możesz skorzystać z przykładowego kodu zasad podanego powyżej w przypadku żądania zawierającego token OAuth v2.0 zawierający nagłówek podobny do tego: Authorization: Bearer TU08xptfFfeM7aS0xHqlxTgEAdAM.
Jako projektant interfejsu API załóżmy, że chcesz użyć wartości tokena (ale nie całego nagłówka) jako klucza podczas wyszukiwania w pamięci podręcznej. Do wyodrębnienia tokena możesz użyć powyższego kodu zasady ExtractVariables.
Gdy Apigee Edge stosuje do tego nagłówka kod zasady ExtractVariables, ustawia zmienną clientrequest.oauthtoken
na TU08xptfFfeM7aS0xHqlxTgEAdAM
.
Zmienna clientrequest.oauthtoken
jest teraz dostępna na serwerze proxy. Na przykład ta zasada AssignMessage kopiuje ją do ładunku żądania:
<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>
$
Weź pod uwagę ten ładunek odpowiedzi 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 } } } }] }
Gdy Apigee Edge stosuje powyższy kod zasady ExtractVariables do tej wiadomości JSON, ustawia 2 zmienne: geocoderesponse.latitude
i geocoderesponse.longitude
. Obie te zmienne mają ten sam prefiks zmiennej geocoderesponse
. Przyrostek tych zmiennych jest wyraźnie określony w atrybucie name
elementu <Variable>
.
Zmienna geocoderesponse.latitude
otrzymuje wartość 37.42291810
. Zmienna geocoderesponse.longitude
otrzymuje wartość -122.08542120
.
Zmienna geocoderesponse.latitude
jest teraz dostępna na serwerze proxy. Na przykład poniższa zasada AssignMessage kopiuje go do nagłówka o nazwie „width”:
<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>
Weź pod uwagę ten ładunek odpowiedzi 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>
Gdy Apigee Edge stosuje do tej wiadomości XML kod zasady ExtractVariables, ustawia 3 zmienne: directionsresponse.travelmode,
directionsresponse.duration
i directionsresponse.timeunit
. Wszystkie zmienne mają ten sam prefiks zmiennej directionsresponse
. Sufiks tych zmiennych jest wyraźnie określony w atrybucie name
elementu <Variable>
.
Zmienna directionsresponse.travelmode
otrzymuje wartość DRIVING
. Zmienna directionsresponse.duration
otrzymuje wartość 19
. Zmienna directionsresponse.timeunit
otrzymuje wartość minutes
.
Zmienna directionresponse.travelmode
jest teraz dostępna na serwerze proxy. Na przykład poniższa zasada AssignMessage kopiuje go do nagłówka o nazwie „tmode” w odpowiedzi:
<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>
Zasady dotyczące zmiennych Extract
Programiści interfejsów API tworzą serwery proxy, które zachowują się inaczej w zależności od zawartości wiadomości, w tym nagłówków, ścieżek identyfikatorów URI, ładunków i parametrów zapytań. Serwer proxy często wyodrębnia część tych treści na potrzeby warunku. Aby to zrobić, użyj zasady ExtractVariables.
Podczas definiowania zasady ExtractVariables możesz wybrać:
- Nazwy zmiennych, które chcesz ustawić
- Źródło zmiennych
- Liczba zmiennych do wyodrębnienia i ustalenia
Gdy ta zasada jest egzekwowana, stosuje do tekstu wzorzec tekstowy, a po znalezieniu dopasowania ustawia wartość wyznaczonej zmiennej z treścią. Inne zasady i kod mogą wykorzystywać te zmienne, aby włączyć dynamiczne zachowanie lub wysyłać firmowe bazy danych do Analytics API.
Informacje o tym, jak korzystać z zmiennych wyodrębnionych do tworzenia raportów Analytics opartych na treści, znajdziesz w artykule Analizowanie treści komunikatów interfejsu API za pomocą niestandardowych statystyk.
Zakres
Zmienne ustawione w zasadzie ExtractVariables mają zakres globalny. Oznacza to, że gdy zasada ExtractVariables definiuje nową zmienną, masz do niej dostęp z dowolnej zasady lub dowolnego kodu na dowolnym etapie przepływu pracy (wykonywania zasady ExtractVariables). Obejmuje to:
- PreFlow: ProxyEndpoint i TargetEndpoint (żądanie i odpowiedź)
- PostFlow: ProxyEndpoint i TargetEndpoint (żądanie i odpowiedź)
- PostClientFlow: ProxyEndpoint (odpowiedź tylko za pomocą zasad rejestrowania wiadomości)
- Przepływy błędów
Dopasowywanie i tworzenie zmiennych
Zasada ExtractVariables wyodrębnia informacje z żądania lub odpowiedzi i zapisuje je w zmiennej. W przypadku każdego typu informacji, które możesz wyodrębnić, takich jak ścieżka identyfikatora URI czy dane XML, musisz określić wzorzec do dopasowania i nazwę zmiennej służącej do przechowywania wyodrębnionych informacji.
Jednak sposób dopasowania wzorców zależy od źródła wyodrębnienia. W poniższych sekcjach opisano 2 podstawowe kategorie informacji, które można wyodrębnić.
Pasujące ścieżki identyfikatora URI, parametry zapytania, nagłówki, parametry formularza i zmienne
Podczas wyodrębniania informacji ze ścieżki identyfikatora URI, parametrów zapytania, nagłówków, parametrów formularza i zmiennych używasz tagu <Pattern>, aby określić co najmniej jeden wzorzec do dopasowania. Poniższy przykład zasady pokazuje pojedynczy wzorzec dopasowania dla ścieżki identyfikatora URI:
<ExtractVariables name="ExtractVariables-1"> <Source>request</Source> <URIPath> <Pattern ignoreCase="true">/a/{pathSeg}</Pattern> </URIPath> <VariablePrefix>urirequest</VariablePrefix> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </ExtractVariables>
W tym przykładzie zmienna urirequest.pathSeg jest ustawiona na wartość widoczną w pliku proxy.pathsuffix po „/a/”. Załóżmy na przykład, że ścieżka bazowa serwera proxy interfejsu API to /basepath/v1 . W przypadku żądania przychodzącego kierowanego do http://myCo.com/basepath/v1/a/b zmienna jest ustawiona na „b”.
Określanie wielu wzorców
Możesz określić wiele wzorców do dopasowania, używając tagów <Pattern>, gdzie:
- Wszystkie wzorce są sprawdzane pod kątem dopasowania.
- Jeśli żaden z wzorców nie jest zgodny, zasada nie powoduje żadnych działań, a zmienne nie są tworzone.
- Jeśli pasuje więcej niż 1 wzór, do wyodrębnienia służy wzorzec z najdłuższymi segmentami ścieżek.
- Jeśli 2 pasujące wzorce mają te same najdłuższe segmenty ścieżki, do wyodrębnienia służy wzorzec określony w zasadzie.
W następnym przykładzie utworzysz zasadę zawierającą 3 pasujące wzorce ścieżki 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>
Załóżmy, że w przypadku serwera proxy interfejsu API z ścieżką bazową /basepath/v1 adres URL żądania przychodzącego do serwera proxy interfejsu API ma postać:
http://myCo.com/basepath/v1/a/b
W tym przykładzie pierwszy wzorzec pasuje do identyfikatora URI, a zmienna urirequest.pathSeg jest ustawiona na „b”.
Jeśli adres URL żądania to:
http://myCo.com/basepath/v1/a/b/c/d
...dopasowany jest trzeci wzorzec, a zmienna urirequest.pathSeg jest ustawiona na „d”.
Określanie wzorców z wieloma zmiennymi
W wzorcach możesz określić wiele zmiennych. Na przykład podajesz wzorzec dopasowania z 2 zmiennymi:
<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>
Ponownie dodaj serwer proxy interfejsu API ze ścieżką podstawową /basepath/v1 w przypadku adresu URL żądania przychodzącego:
http://myCo.com/basepath/v1/a/b/c/d
...Zmienna urirequest.pathSeg1 jest ustawiona na „b”, a zmienna urirequest.pathSeg2 na „d”.
Dopasowywanie wielu wystąpień we wzorze
Wzorce mogą być także używane w przypadku większej liczby wystąpień elementu o tej samej nazwie. Możesz na przykład utworzyć żądanie, które zawiera wiele parametrów zapytania lub wiele nagłówków o tej samej nazwie. To żądanie zawiera 2 parametry zapytania o nazwie „w”:
http://myCo.com/basepath/v1/a/b/c/d?w=1&w=2
Aby odwołać się do tych parametrów zapytania w zasadzie ExtractVariables, użyj indeksów, w których pierwsze wystąpienie parametru zapytania nie ma indeksu, drugie w indeksie 2, trzecie w indeksie 3 itd. Na przykład ta zasada wyodrębnia wartość drugiego parametru zapytania o nazwie „w” w żądaniu:
<ExtractVariables name="ExtractVariables-1"> <Source>request</Source> <QueryParam name="w.2"> <Pattern ignoreCase="true">{secondW}</Pattern> </QueryParam> <VariablePrefix>urirequest</VariablePrefix> <IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables> </ExtractVariables>
Zmienna urirequest.secondW ma wartość „2”. Jeśli drugi parametr zapytania jest pomijany w żądaniu, zmienna urirequest.secondW jest pusta. Indeksuj za każdym razem, gdy w żądaniu znajduje się wiele elementów o tej samej nazwie.
Używanie znaków specjalnych w wzorze
Dopasowując ścieżki identyfikatora URI, możesz używać w wzorcach symboli wieloznacznych „*” i „**”, gdzie:
- Symbol „*” odpowiada dowolnemu fragmentowi ścieżki
- Symbol „**” odpowiada wielu segmentom ścieżki
Na przykład w elemencie <URIPath> podajesz wzorce:
<URIPath> <Pattern ignoreCase="true">/a/*/{id}</Pattern> <Pattern ignoreCase="true">/a/**/{id}</Pattern> </URIPath>
Pierwszy wzorzec pasuje do żądań ze ścieżkami w postaci ścieżek (część ścieżki identyfikatora URI po ścieżce podstawowej), np. „/a/b/c”, „/a/foo/bar” itp. Drugi wzorzec pasuje do dowolnej liczby segmentów ścieżek po „/a/”, takich jak „/a/foo/bar/baz/c”, a także „/a/b/c” i „/a/foo/bar” lub „/a/foo/bar”.
Podczas określania wzorców do parametrów zapytania, nagłówków i parametrów formularzy znak „*” odpowiada dowolnej liczbie znaków. Na przykład podczas dopasowywania nagłówka określ wzorzec, używając:
*;charset={encoding}
Ten wzorzec pasuje do wartości „text/xml;charset=UTF-16” i „application/xml;charset=ASCII”.
Jeśli wartość przekazana do zasady ExtractVariables zawiera znak specjalny (np. „{), użyj znaku „%”, aby ją zmienić. Poniższy przykład zawiera znaczenie znaków „{" i "} w wzorze, ponieważ są one używane jako wartości literału w wartości parametru zapytania:
<QueryParam> <Pattern ignoreCase="true">%{user%} {name}</Pattern> </QueryParam>
W tym przykładzie wzorzec pasuje do wartości „{user} Steve”, ale nie do wartości „user Steve”.
Pasujące pliki JSON i XML
Podczas wyodrębniania danych z formatów JSON i XML musisz określić w zasadzie co najmniej 1 tag <Variable>. Tag <variable> określa nazwę zmiennej docelowej, w której są przechowywane wyodrębnione informacje, oraz ścieżkę JsonPath (JSON) lub XPATH (XML) do wyodrębnionych informacji.
Wszystkie tagi <variable> w zasadzie są oceniane, więc możesz wstawić wiele zmiennych z jednej zasady. Jeśli tag <variable> nie uzupełni poprawnego pola pliku JSON lub XML, odpowiednia zmienna nie zostanie utworzona.
Poniższy przykład pokazuje zasadę ExtractZmienne, która wypełnia 2 zmienne z treści JSON odpowiedzi:
<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>
Zapisywanie w tej samej zmiennej w wielu miejscach
Wybierając nazwy zmiennych, zachowaj ostrożność. Zasada jest wykonywana sekwencyjnie od pierwszego wzorca wyodrębniania do ostatniego. Jeśli zasada zapisuje wartość w tej samej zmiennej z wielu miejsc, wartość ostatniego zapisu określa zasada. To może być przydatne.
Na przykład chcesz wyodrębnić wartość tokena, którą można przekazać w parametrze zapytania lub w nagłówku, jak pokazano poniżej:
<!-- 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>
Kontrola, co się dzieje, gdy nie ma żadnego dopasowania
Jeśli wzór nie będzie się zgadzać, odpowiednia zmienna nie zostanie utworzona. Dlatego jeśli inna zasada odwołuje się do zmiennej, może to spowodować błąd.
Jedną z opcji jest ustawienie wartości <IgnoreUnresolvedVariables>
na wartość „true” w zasadzie, która odwołuje się do zmiennej, aby skonfigurować ją tak, aby traktowała każdą zmienną jako nierozwiązaną jako pusty ciąg:
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
Dokumentacja elementu
Dokumentacja elementu opisuje elementy i atrybuty zasady 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>
Atrybuty <ExtractVariables>
<ExtractVariables async="false" continueOnError="false" enabled="true" name="Extract-Variables-1">
Tabela poniżej opisuje atrybuty wspólne dla wszystkich elementów nadrzędnych zasad:
Atrybut | Opis | Domyślnie | Obecność |
---|---|---|---|
name |
Wewnętrzna nazwa zasady. Wartość atrybutu Opcjonalnie użyj elementu |
Nie dotyczy | Wymagany |
continueOnError |
Ustaw wartość Ustaw wartość |
fałsz | Opcjonalnie |
enabled |
Ustaw jako Ustaw zasadę |
prawda | Opcjonalnie |
async |
Ten atrybut został wycofany. |
fałsz | Wycofano |
Element <DisplayName>
Używaj atrybutu name
tak, aby oznaczyć zasadę w edytorze proxy interfejsu zarządzania inną nazwą w języku naturalnym.
<DisplayName>Policy Display Name</DisplayName>
Domyślnie |
Nie dotyczy Jeśli pominiesz ten element, zostanie użyta wartość atrybutu |
---|---|
Obecność | Opcjonalnie |
Typ | Ciąg znaków |
Element <Source>
(Opcjonalnie) Określa zmienną do przeanalizowania. Wartość <Source>
jest domyślnie ustawiona na message
. W wartości message
uwzględnia się kontekst. message
analizuje przepływ żądania. W przepływie odpowiedzi message
jest odpowiedzią na wiadomość odpowiedzi.
Chociaż często za pomocą tej zasady wyodrębniasz informacje z żądania lub wiadomości z odpowiedzią, możesz za jej pomocą wyodrębnić informacje z dowolnej zmiennej. Za jego pomocą możesz na przykład wyodrębnić informacje z elementu utworzonego na podstawie zasady AccessEntity z danych zwróconych przez zasady dotyczące objaśnień dotyczących usług lub informacje z obiektu XML lub JSON.
Jeśli zasada <Source>
nie jest rozpoznawana lub jej typ nie jest wiadomością, zasada nie odpowiada.
<Source clearPayload="true|false">request</Source>
Domyślne: | wiadomość |
Obecność: | Opcjonalnie |
Typ: | Ciąg znaków |
Atrybuty
Atrybut | Opis | Domyślna | Obecność | Typ |
---|---|---|---|---|
Czyszczenie danych |
Ustaw wartość true, jeśli chcesz wyczyścić ładunek określony w elemencie <Source> po wyodrębnieniu z niego danych. |
fałsz |
Opcjonalnie | Wartość logiczna |
Element <VariablePrefiks>
(Opcjonalnie) Aby utworzyć pełną nazwę zmiennej, utwórz połączenie z kropką <VariablePrefix>
, kropką i nazwą określoną w {curly braces} w elemencie <Pattern>
lub <variable>. Na przykład: myprefix.id
, myprefix.dbncode
lub myprefix.oauthtoken.
<VariablePrefix>myprefix</VariablePrefix>
Załóżmy na przykład, że wartość nazwy to „user”.
- Jeśli nie podasz wartości
<VariablePrefix>
, wyodrębnione wartości zostaną przypisane do zmiennej o nazwieuser
. - Jeśli
<VariablePrefix>
jest określony jako myprefix, wyodrębnione wartości są przypisywane do zmiennej o nazwiemyprefix.user
.
Domyślne: | Nie dotyczy |
Obecność: | Opcjonalnie |
Typ: | Ciąg znaków |
Element <ignoreUnresolvedVariables>
(Opcjonalnie) Ustaw wartość true
, aby traktować dowolną zmienną nierozwiązaną jako pusty ciąg znaków (null). Ustaw wartość false
, jeśli zasada ma zwracać błąd, gdy określona zmienna nie jest rozpoznawalna.
<IgnoreUnresolvedVariables>true</IgnoreUnresolvedVariables>
Domyślne: | Fałsz |
Obecność: | Opcjonalnie |
Typ: | Wartość logiczna |
Jeśli nie można rozpoznać odniesienia XPath w <XMLPayload>
, zasada zwraca następujący błąd:
{ "fault":{ "faultstring":"Unresolved xpath path in policy policy_name.", "detail":{ "errorcode":"steps.extractvariables.InvalidXPath" } } }
Element <URIPath>
(Opcjonalnie; więcej informacji znajdziesz w tabeli obecności). Wyodrębnia wartość z proxy.pathsuffix wiadomości źródłowej żądania. Ścieżka zastosowana do wzorca to proxy.pathsuffix, która nie zawiera ścieżki bazowej serwera proxy interfejsu API. Jeśli wiadomość źródłowa zostanie ustawiona na typ odpowiedzi response, ten element nie ma żadnego efektu.
<URIPath> <Pattern ignoreCase="false">/accounts/{id}</Pattern> </URIPath>
Możesz użyć wielu elementów <Pattern>:
<URIPath> <Pattern ignoreCase="false">/accounts/{id}</Pattern> <Pattern ignoreCase="false">/accounts/{id}/transactions/{index}</Pattern> </URIPath>
Domyślne: | Nie dotyczy |
Obecność: | Opcjonalnie. Musisz jednak uwzględnić co najmniej jedną z tych właściwości:
<URIPath> , <QueryParam> , <Header> ,
<FormParam> , <JSONPayload> lub
<XMLPayload>. |
Typ: | Nie dotyczy |
Atrybuty
Atrybut | Opis | Domyślna | Obecność | Typ |
---|---|---|---|---|
Ignoruj wielkość liter | Określa, czy zignorować wielkość liter, gdy patron jest dopasowany. |
fałsz |
Opcjonalnie | Wartość logiczna |
Element <QueryParam>
(Opcjonalnie; więcej informacji znajdziesz w tabeli obecności). Wyodrębnia wartość z określonego parametru zapytania w wiadomości źródłowej request. Jeśli wiadomość źródłowa zostanie ustawiona na typ odpowiedzi response, ten element nie ma żadnego efektu.
<QueryParam name="code"> <Pattern ignoreCase="true">DBN{dbncode}</Pattern> </QueryParam>
Jeśli wiele parametrów zapytania ma taką samą nazwę, użyj indeksów, aby się do nich odwoływać:
<QueryParam name="w.2"> <Pattern ignoreCase="true">{secondW}</Pattern> </QueryParam>
Domyślne: | Nie dotyczy |
Obecność: | Opcjonalnie. Musisz jednak uwzględnić co najmniej jedną z tych właściwości:
<URIPath> , <QueryParam> , <Header> ,
<FormParam> , <JSONPayload> lub
<XMLPayload>. |
Typ: | Nie dotyczy |
Atrybuty
Atrybut | Opis | Domyślna | Obecność | Typ |
---|---|---|---|---|
nazwa | Określa nazwę parametru zapytania. Jeśli wiele parametrów zapytania ma taką samą nazwę, użyj odwołania do indeksu. Pierwsze wystąpienie parametru nie ma indeksu, drugi – indeks 2, trzeci w indeksie 3 itd. |
Nie dotyczy |
Wymagany | Ciąg znaków |
Element <Header>
(Opcjonalnie; więcej informacji znajdziesz w tabeli obecności). Wyodrębnia wartość z określonego nagłówka HTTP określonego komunikatu request lub response. Jeśli wiele nagłówków ma tę samą nazwę, ich wartości są przechowywane w tablicy.
<!-- 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>
Jeśli wiele nagłówków ma tę samą nazwę, użyj indeksów, aby odwołać się do poszczególnych nagłówków w tablicy:
<Header name="myHeader.2"> <Pattern ignoreCase="true">{secondHeader}</Pattern> </Header>
Możesz też wykonać te czynności, aby wyświetlić wszystkie nagłówki w tablicy:
<Header name="myHeader.values"> <Pattern ignoreCase="true">{myHeaders}</Pattern> </Header>
Domyślne: | Nie dotyczy |
Obecność: | Opcjonalnie. Musisz jednak uwzględnić co najmniej jedną z tych właściwości:
<URIPath> , <QueryParam> , <Header> ,
<FormParam> , <JSONPayload> lub
<XMLPayload>. |
Typ: | Nie dotyczy |
Atrybuty
Atrybut | Opis | Domyślna | Obecność | Typ |
---|---|---|---|---|
nazwa | Określa nazwę nagłówka, z którego chcesz pobrać wartość. Jeśli wiele nagłówków ma tę samą nazwę, użyj odniesienia do indeksowania, gdzie pierwsze wystąpienie nagłówka nie ma indeksu, drugi w indeksie 2, trzeci w indeksie 3 itd. Użyj .values , aby pobrać wszystkie nagłówki w tablicy. |
Nie dotyczy |
Wymagany | Ciąg znaków |
Element <FormParam>
(Opcjonalnie; więcej informacji znajdziesz w tabeli obecności). Wyodrębnia wartość z określonego parametru formularza określonej wiadomości z żądania lub odpowiedzi. Parametry formularza można wyodrębnić tylko wtedy, gdy nagłówek Content-Type
określonej wiadomości to application/x-www-form-urlencoded
.
<FormParam name="greeting"> <Pattern>hello {user}</Pattern> </FormParam>
Domyślne: | Nie dotyczy |
Obecność: | Opcjonalnie. Musisz jednak uwzględnić co najmniej jedną z tych właściwości:
<URIPath> , <QueryParam> , <Header> ,
<FormParam> , <JSONPayload> lub
<XMLPayload>. |
Typ: | Nie dotyczy |
Atrybuty
Atrybut | Opis | Domyślna | Obecność | Typ |
---|---|---|---|---|
nazwa | Nazwa parametru formularza, z którego pobierasz wartość. |
Nie dotyczy |
Wymagany | Ciąg znaków |
Element <Zmienna>
(Opcjonalnie; więcej informacji znajdziesz w tabeli obecności). Określa nazwę zmiennej, z której ma zostać pobrana wartość.
<Variable name="myVar"> <Pattern>hello {user}</Pattern> </Variable>
Aby wyodrębnić 2 wartości ze zmiennej:
<Variable name="myVar"> <Pattern>hello {firstName} {lastName}</Pattern> </Variable>
Domyślne: | Nie dotyczy |
Obecność: | Opcjonalnie. Musisz jednak uwzględnić co najmniej jedną z tych właściwości:
<URIPath> , <QueryParam> , <Header> ,
<FormParam> , <JSONPayload> lub
<XMLPayload>. |
Typ: | Nie dotyczy |
Atrybuty
Atrybut | Opis | Domyślna | Obecność | Typ |
---|---|---|---|---|
nazwa | Nazwa zmiennej, z której chcesz wyodrębnić wartość. |
Nie dotyczy |
Wymagany | Ciąg znaków |
Element <JSONPayload>
(Opcjonalnie; więcej informacji znajdziesz w tabeli obecności). Określa komunikat w formacie JSON, z którego zostanie wyodrębniona wartość zmiennej. Ekstrakcja JSON jest przeprowadzana tylko wtedy, gdy nagłówek Content-Type wiadomości to application/json.
<JSONPayload> <Variable name="name" type="string"> <JSONPath>{example}</JSONPath> </Variable> </JSONPayload>
Domyślne: | Nie dotyczy |
Obecność: | Opcjonalnie. Musisz jednak uwzględnić co najmniej jedną z tych właściwości:
<URIPath> , <QueryParam> , <Header> ,
<FormParam> , <JSONPayload> lub
<XMLPayload>. |
Typ: | Nie dotyczy |
Element <JSONPayload>/<zmienne>
(Wymagane w elemencie JSONPayload). Określa zmienną, do której jest przypisana wyodrębniona wartość. W elemencie <JSONPayload> możesz umieścić wiele tagów <Variable>, aby uwzględnić wiele zmiennych.
<Variable name="name" type="string"> <JSONPath>{example}</JSONPath> </Variable>
Domyślne: | Nie dotyczy |
Obecność: | Wymagane w elemencie JSONPayload. |
Typ: | Nie dotyczy |
Atrybuty
Atrybut | Opis | Domyślna | Obecność | Typ |
---|---|---|---|---|
nazwa |
Określa nazwę zmiennej, do której zostanie przypisana wyodrębniona wartość. |
nazwa |
Wymagany | Ciąg znaków |
typ | Określa typ danych wartości zmiennej. | Nie dotyczy | Opcjonalnie |
Ciąg tekstowy. Do wyboru masz te opcje:
|
Element <JSONPayload>/<Zmienna>/<JSONPath>
(Wymagane w elemencie JSONPayload:Variable). Określa ścieżkę JSON używaną do wyodrębniania wartości z wiadomości w formacie JSON.
<Variable name="name"> <JSONPath>$.rss.channel.title</JSONPath> </Variable>
Domyślne: | Nie dotyczy |
Obecność: | Wymagany |
Typ: | Ciąg znaków |
Element <XMLPayload>
(Opcjonalnie; więcej informacji znajdziesz w tabeli obecności). Określa komunikat w formacie XML, z którego zostanie pobrana wartość zmiennej. Ładunki XML są wyodrębniane tylko wtedy, gdy nagłówek Content-Type
wiadomości to text/xml
, application/xml
lub 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>
Domyślne: | Nie dotyczy |
Obecność: | Opcjonalnie. Musisz jednak uwzględnić co najmniej jedną z tych właściwości:
<URIPath> , <QueryParam> , <Header> ,
<FormParam> , <JSONPayload> lub
<XMLPayload>. |
Typ: | Nie dotyczy |
Atrybuty
Atrybut | Opis | Domyślna | Obecność | Typ |
---|---|---|---|---|
stopPayloadProcessing |
Ustaw wartość |
fałsz |
Opcjonalnie | Wartość logiczna |
Element <XMLPayload>/<przestrzenie nazw>
(Opcjonalnie) Określa przestrzeń nazw, która ma być używana w ocenie XPath. Jeśli w wyrażeniach XPath używasz przestrzeni nazw, musisz zadeklarować je tutaj, jak pokazano w poniższym przykładzie.
<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>
Jeśli nie używasz przestrzeni nazw w wyrażeniach XPath, możesz pominąć lub dodać element <Namespaces>
, jak w tym przykładzie:
<XMLPayload stopPayloadProcessing="false"> <!-- <Namespaces/> --> <Variable name="legName" type="string"> <XPath>/Directions/route/leg/name</XPath> </Variable> </XMLPayload>
Domyślne: | Nie dotyczy |
Obecność: | Opcjonalnie |
Typ: | Ciąg znaków |
Atrybuty
Atrybut | Opis | Domyślna | Obecność | Typ |
---|---|---|---|---|
prefix |
Prefiks przestrzeni nazw. |
Nie dotyczy |
Wymagany | Ciąg znaków |
Element <XMLPayload>/<zmienna>
(Opcjonalnie) Określa zmienną, do której zostanie przypisana wyodrębniona wartość.
<Variable name="name" type="boolean"> <XPath>/test/example</XPath> </Variable>
Domyślne: | Nie dotyczy |
Obecność: | Opcjonalnie |
Typ: | Nie dotyczy |
Atrybuty
Atrybut | Opis | Domyślna | Obecność | Typ |
---|---|---|---|---|
nazwa |
Określa nazwę zmiennej, do której zostanie przypisana wyodrębniona wartość. |
nazwa |
Wymagany | Ciąg znaków |
typ | Określa typ danych wartości zmiennej. | Wartość logiczna | Opcjonalnie |
Ciąg tekstowy. Do wyboru masz te opcje:
|
Element <XMLPayload>/<Zmienna>/<ścieżka XX>
(Wymagane w elemencie XMLPayload:Variable). Określa ścieżkę XPath określoną dla zmiennej. Obsługiwane są tylko wyrażenia XPath 1.0.
<Variable name="name" type="boolean"> <XPath>/test/example</XPath> </Variable>
Przykład z przestrzenią nazw. Jeśli w wyrażeniach XPath używasz przestrzeni nazw, musisz je zadeklarować w sekcji <XMLPayload><Namespaces>
zasady.
<Variable name="name" type="boolean"> <XPath>/foo:test/foo:example</XPath> </Variable>
Domyślne: | Nie dotyczy |
Obecność: | Wymagany |
Typ: | Ciąg znaków |
Dokumentacja błędu
W tej sekcji opisano kody błędów i komunikaty o błędach, które są zwracane, a także wartości zmiennych ustawionych przez Edge w momencie aktywowania tej zasady. Ta informacja jest ważna, gdy opracowujesz reguły obsługi błędów. Więcej informacji znajdziesz w artykułach Co musisz wiedzieć o błędach zasad i Obsługa błędów.
Błędy w czasie wykonywania
Te błędy mogą wystąpić podczas wykonywania zasady.
Kod błędu | Stan HTTP | Przyczyna | Napraw |
---|---|---|---|
steps.extractvariables.ExecutionFailed |
500 |
Ten błąd występuje, gdy:
|
build |
steps.extractvariables.ImmutableVariable |
500 | Zmienna używana w zasadzie jest stała. Zasady nie udało się ustawić tej zmiennej. | |
steps.extractvariables.InvalidJSONPath |
500 | Ten błąd występuje, jeśli w elemencie JSONPath zasady użyto nieprawidłowej ścieżki JSON. Jeśli na przykład ładunek JSON nie ma obiektu Name , ale jako ścieżkę w zasadzie podasz Name , wystąpi ten błąd. |
build |
steps.extractvariables.JsonPathParsingFailure |
500 | Ten błąd występuje, gdy zasada nie może przeanalizować ścieżki JSON i wyodrębnić danych ze zmiennej przepływu podanej w elemencie Source . Zwykle dzieje się tak, gdy zmienna przepływu podana w elemencie Source nie istnieje w bieżącym procesie. |
build |
steps.extractvariables.SetVariableFailed |
500 | Ten błąd występuje, jeśli zasada nie może ustawić wartości na zmienną. Błąd zwykle występuje, gdy próbujesz przypisać wartości do wielu zmiennych, których nazwy zaczynają się od identycznych słów na początku. | build |
steps.extractvariables.SourceMessageNotAvailable |
500 | Ten błąd występuje, jeśli zmienna message określona w elemencie Source zasady wynosi:
|
build |
steps.extractvariables.UnableToCast |
500 | Ten błąd występuje, jeśli zasada nie może przesłać wyodrębnionej wartości do zmiennej. Zwykle dzieje się tak, gdy próbujesz ustawić wartość jednego typu danych na zmienną innego typu. | build |
Błędy wdrażania
Te błędy mogą wystąpić, gdy wdrażasz serwer proxy zawierający tę zasadę.
Nazwa błędu | Przyczyna | Napraw |
---|---|---|
NothingToExtract |
Jeśli zasada nie zawiera żadnego z elementów URIPath , QueryParam , Header , FormParam , XMLPayload ani JSONPayload , wdrożenie serwera proxy interfejsu API nie powiedzie się, ponieważ nie trzeba niczego wyodrębniać. |
build |
NONEmptyPrefixMappedToEmptyURI |
Ten błąd występuje, jeśli zasada ma prefiks zdefiniowany w elemencie Namespace w elemencie XMLPayload , ale nie jest zdefiniowany identyfikator URI. |
build |
DuplicatePrefix |
Ten błąd występuje, gdy zasada ma w elemencie Namespace w elemencie XMLPayload ten sam prefiks zdefiniowany więcej niż raz. |
build |
NoXPathsToEvaluate |
Jeśli zasada nie zawiera elementu XPath w elemencie XMLPayload , błąd serwera proxy interfejsu API kończy się niepowodzeniem.
|
build |
EmptyXPathExpression |
Jeśli zasada zawiera puste wyrażenie XPath w elemencie XMLPayload , nie udało się wdrożyć serwera proxy interfejsu API. |
build |
NoJSONPathsToEvaluate |
Jeśli zasada nie zawiera elementu JSONPath w elemencie JSONPayload , błąd serwera proxy interfejsu API kończy się niepowodzeniem. |
build |
EmptyJSONPathExpression |
Jeśli zasada zawiera puste wyrażenie XPath w elemencie XMLPayload , nie udało się wdrożyć serwera proxy interfejsu API. |
build |
MissingName |
Jeśli zasada nie ma atrybutu name w żadnym z elementów zasad, takich jak QueryParam , Header , FormParam lub Variable , w miejscu, w którym jest wymagana, wdrożenie serwera proxy interfejsu API nie powiedzie się. |
build |
PatternWithoutVariable |
Jeśli zasada nie ma zmiennej określonej w elemencie Pattern , wdrożenie serwera proxy interfejsu API nie powiedzie się. Element Pattern wymaga nazwy zmiennej, w której będą przechowywane wyodrębnione dane. |
build |
CannotBeConvertedToNodeset |
Jeśli zasada zawiera wyrażenie XPath , w którym typ Variable jest zdefiniowany jako nodeset, ale nie można go przekonwertować na zbiór węzłów, wdrożenie serwera proxy interfejsu API kończy się niepowodzeniem. |
build |
JSONPathCompilationFailed |
Zasady nie udało się skompilować określonej ścieżki JSON. | |
InstantiationFailed |
Nie udało się utworzyć zasady. | |
XPathCompilationFailed |
Jeśli prefiks lub wartość używana w elemencie XPath nie są częścią żadnej zadeklarowanej przestrzeni nazw w zasadzie, wdrożenie serwera proxy interfejsu API nie powiedzie się. |
build |
InvalidPattern |
Jeśli definicja elementu Pattern jest nieprawidłowa w przypadku któregokolwiek z elementów takich jak URIPath , QueryParam , Header , FormParam , XMLPayload lub JSONPayload w zasadzie, wdrożenie serwera proxy interfejsu API nie powiedzie się.
|
build |
Zmienne błędów
Zmienne te są ustawiane, gdy ta zasada powoduje błąd w czasie działania. Więcej informacji znajdziesz w artykule Co musisz wiedzieć o błędach zasad.
Zmienne | Gdzie | Przykład |
---|---|---|
fault.name="fault_name" |
fault_name to nazwa błędu, zgodnie z tabelą Błędy środowiska wykonawczego. Nazwa błędu jest ostatnią częścią kodu błędu. | fault.name = "SourceMessageNotAvailable" |
extractvariables.policy_name.failed |
policy_name to określona przez użytkownika nazwa zasady, która spowodowała błąd. | extractvariables.EV-ParseJsonResponse.failed = true |
Przykładowa odpowiedź na błąd
{ "fault":{ "detail":{ "errorcode":"steps.extractvariables.SourceMessageNotAvailable" }, "faultstring":"request message is not available for ExtractVariable: EV-ParseJsonResponse" } }
Przykładowa reguła awarii
<FaultRule name="Extract Variable Faults"> <Step> <Name>AM-CustomErrorMessage</Name> <Condition>(fault.name = "SourceMessageNotAvailable") </Condition> </Step> <Condition>(extractvariables.EM-ParseJsonResponse.failed = true) </Condition> </FaultRule>
Schematy
Powiązane artykuły
Analizowanie treści wiadomości interfejsu API za pomocą niestandardowych statystyk