Przeglądasz dokumentację Apigee Edge.
Otwórz dokumentację Apigee X. Informacje
Co
Zasada Objaśnienia do usługi umożliwia wywoływanie innej usługi z przepływu proxy interfejsu API. Możesz wysyłać wywołania do usługi zewnętrznej (takiej jak zewnętrzny punkt końcowy usługi REST) lub usług wewnętrznych (takich jak serwer proxy interfejsu API w tej samej organizacji i tym samym środowisku).
- W przypadku zewnętrznego zastosowania tworzysz wywołanie do interfejsu API innej firmy, który jest zewnętrzny w stosunku do Twojego serwera proxy. Odpowiedź z interfejsu API innej firmy jest analizowana i umieszczana w wiadomości z odpowiedzią interfejsu API, co wzbogaca i „tworzy połączenie” danych dla użytkowników aplikacji. Możesz też wysłać żądanie z użyciem zasady objaśnienia usługi w przepływie żądania, a następnie przekazać informacje w odpowiedzi do docelowego punktu końcowego serwera proxy interfejsu API.
- W innym przypadku wywołujesz serwer proxy z tej samej organizacji i środowiska co serwer, z którego nawiązujesz połączenie. Może to być przydatne na przykład, gdy korzystasz z serwera proxy, który oferuje pewne dyskretne, niskopoziomowe funkcje, z których będzie korzystać co najmniej jeden inny serwer proxy. Na przykład serwer proxy, który udostępnia operacje tworzenia, odczytu, aktualizacji i usuwania z magazynem danych backendu, może być docelowym serwerem proxy dla wielu innych serwerów proxy, które udostępniają dane klientom.
Zasada obsługuje żądania przesyłane przez HTTP i HTTPS.
Przykłady
Lokalne połączenie z wewnętrznym serwerem proxy
<LocalTargetConnection> <APIProxy>data-manager</APIProxy> <ProxyEndpoint>default</ProxyEndpoint> </LocalTargetConnection>
W tym przykładzie tworzymy wywołanie lokalnego serwera proxy interfejsu API (czyli jeden w tej samej organizacji i środowisku) o nazwie data-manager
, które wskazuje jego punkt końcowy serwera proxy o nazwie default
.
URL jako zmienna
<HTTPTargetConnection> <URL>http://example.com/{request.myResourcePath}</URL> </HTTPTargetConnection>
W tym przykładzie użyto zmiennej w adresie URL do dynamicznego wypełnienia adresu URL celu. Fragmentu protokołu adresu URL (http://) nie można określić za pomocą zmiennej. Musisz też użyć oddzielnych zmiennych dla części adresu URL związanej z domeną i dla pozostałej części adresu URL.
Geokodowanie / definiowanie żądań Google
<ServiceCallout name="ServiceCallout-GeocodingRequest1"> <DisplayName>Inline request message</DisplayName> <Request variable="authenticationRequest"> <Set> <QueryParams> <QueryParam name="address">{request.queryparam.postalcode}</QueryParam> <QueryParam name="region">{request.queryparam.country}</QueryParam> <QueryParam name="sensor">false</QueryParam> </QueryParams> </Set> </Request> <Response>GeocodingResponse</Response> <Timeout>30000</Timeout> <HTTPTargetConnection> <URL>http://maps.googleapis.com/maps/api/geocode/json</URL> </HTTPTargetConnection> </ServiceCallout>
http://maps.googleapis.com/maps/api/geocode/json
Zamiast używać zasady takiej jak Przypisz wiadomość do utworzenia obiektu żądania, możesz zdefiniować ją bezpośrednio w zasadzie objaśnienia usługi. W tym przykładzie zasada Objaśnienie usługi ustawia wartości 3 parametrów zapytania przekazywanych do usługi zewnętrznej. Za pomocą zasady objaśnienia usługi możesz utworzyć całą wiadomość żądania, która określa ładunek, typ kodowania, np. application/xml, nagłówki, parametry formularza itp.
Oto kolejny przykład, w którym żądanie jest tworzone przed osiągnięciem zasady objaśnienia usługi.
<ServiceCallout name="ServiceCallout-GeocodingRequest2"> <Request clearPayload="false" variable="GeocodingRequest"/> <Response>GeocodingResponse</Response> <Timeout>30000</Timeout> <HTTPTargetConnection> <URL>http://maps.googleapis.com/maps/api/geocode/json</URL> </HTTPTargetConnection> </ServiceCallout>
Treść komunikatu żądania jest wyodrębniana ze zmiennej o nazwie GeocodingRequest (która może być wypełniona, np. przez zasadę AssignMessage). Komunikat z odpowiedzią jest przypisany do zmiennej o nazwie GeocodingResponse, która jest dostępna do analizy przez zasadę Wyodrębnianie zmiennych lub przez niestandardowy kod napisany w języku JavaScript lub Javie. Zasada czeka 30 sekund na odpowiedź z interfejsu Google Geocoding API, zanim przekroczy limit czasu.
Kompletny przykładowy serwer proxy interfejsu API, który korzysta z tego przykładowego objaśnienia usługi, wraz z zasadami przypisywania wiadomości i wyodrębniania zmiennych znajdziesz w artykule o korzystaniu z struktury zasad.
Serwery docelowe połączeń
<ServiceCallout async="false" continueOnError="false" enabled="true" name="service-callout"> <DisplayName>service-callout</DisplayName> <Properties/> <Request clearPayload="true" variable="myRequest"> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> </Request> <Response>myResponse</Response> <HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="httpbin"/> <Server name="yahoo"/> </LoadBalancer> <Path>/get</Path> </HTTPTargetConnection> </ServiceCallout>
Ta zasada wykorzystuje atrybut LoadBalancer do wywoływania serwerów docelowych i równoważenia obciążenia między nimi. W tym przykładzie obciążenie jest rozkładane na 2 serwery docelowe o nazwach „httpbin” i „yahoo”. Informacje o konfigurowaniu serwerów docelowych dla serwera proxy i konfigurowaniu równoważenia obciążenia znajdziesz w artykule o równoważeniu obciążenia między serwerami backendu.
Zasady dotyczące objaśnień dotyczących usług
Istnieje wiele scenariuszy, w których można używać zasad dotyczących objaśnień usługi na serwerze proxy interfejsu API. Możesz na przykład skonfigurować serwer proxy interfejsu API do wykonywania wywołań do usługi zewnętrznej w celu dostarczania danych geolokalizacji, opinii klientów, produktów z katalogu sklepów detalicznych partnera itd.
Objaśnienie jest zwykle używane z dwiema innymi zasadami: przypisywanie wiadomości i wyodrębnianie zmiennych.
- Request (Żądanie): przypisanie wiadomości wypełnia wiadomość z żądaniem wysłaną do usługi zdalnej.
-
Odpowiedź: wyodrębnianie zmiennych analizuje odpowiedź i wyodrębnia określone treści.
Typowy skład zasad dotyczących objaśnienia usługi obejmuje:
- Przypisz zasadę dotyczącą wiadomości: tworzy wiadomość żądania, wypełnia nagłówki HTTP, parametry zapytania, ustawia czasownik HTTP itp.
- Zasada Service Callout: odwołuje się do wiadomości utworzonej przez zasadę przypisywania wiadomości, określa docelowy URL wywołania zewnętrznego i określa nazwę obiektu odpowiedzi zwracanego przez usługę docelową.
Aby zwiększyć wydajność, możesz też zapisywać w pamięci podręcznej odpowiedzi dotyczące wywołań usługi w sposób opisany w tym wątku społeczności Apigee: https://community.apigee.com/questions/34110/how-can-i-store-the-results-of-the-servicecallout.html. - Zasada wyodrębniania zmiennych: zwykle definiuje wyrażenie JSONPath lub XPath, które analizuje wiadomość wygenerowaną przez objaśnienie usługi. Zasada ustawia zmienne zawierające wartości uzyskane z odpowiedzi objaśnienia usługi.
W sekcji Korzystanie z kompozycji zasad znajdziesz kompletny przykładowy serwer proxy interfejsu API, który korzysta z zasady objaśnienia usługi oraz zasad przypisywania wiadomości i wyodrębniania zmiennych.
Niestandardowa obsługa błędów
Odwołanie do elementu
Oto elementy i atrybuty, które możesz konfigurować w tej zasadzie:
<ServiceCallout async="false" continueOnError="false" enabled="true" name="Service-Callout-1"> <DisplayName>Custom label used in UI</DisplayName> <Request clearPayload="true" variable="myRequest"> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> <Remove> <ReasonPhrase/> <StatusCode/> <Path/> <Version/> <Verb/> </Remove> <Copy> <ReasonPhrase/> <StatusCode/> <Path/> <Version/> <Verb/> </Copy> <Add> <Headers/> <QueryParams/> <FormParams/> </Add> <Set> <Headers/> <QueryParams/> <FormParams/> <Payload/> <ReasonPhrase/> <StatusCode/> <Path/> <Version/> <Verb/> </Set> </Request> <Response>calloutResponse</Response> <Timeout>30000</Timeout> <HTTPTargetConnection> <URL>http://example.com</URL> <LoadBalancer/> <SSLInfo/> <Properties/> </HTTPTargetConnection> <LocalTargetConnection> <APIProxy/> <ProxyEndpoint/> <Path/> </LocalTargetConnection> </ServiceCallout>
Atrybuty <ServiceCallout>
<ServiceCallout async="false" continueOnError="false" enabled="true" name="Service-Callout-1">
Tabela poniżej zawiera opis atrybutów wspólnych dla wszystkich elementów nadrzędnych zasad:
Atrybut | Opis | Domyślne | Obecność |
---|---|---|---|
name |
Wewnętrzna nazwa zasady. Wartość atrybutu Opcjonalnie możesz użyć elementu |
Nie dotyczy | Wymagane |
continueOnError |
Ustaw wartość Ustaw jako |
false | Opcjonalnie |
enabled |
Ustaw jako Ustaw wartość |
prawda | Opcjonalnie |
async |
Ten atrybut został wycofany. |
false | Wycofano |
Element <DisplayName>
Użyj oprócz atrybutu name
, aby oznaczyć zasadę w edytorze serwera proxy interfejsu zarządzania inną nazwą w języku naturalnym.
<DisplayName>Policy Display Name</DisplayName>
Domyślne |
Nie dotyczy Jeśli pominiesz ten element, zostanie użyta wartość atrybutu |
---|---|
Obecność | Opcjonalnie |
Typ | Ciąg znaków |
Element <Request>
Określa zmienną zawierającą komunikat z żądaniem, który jest wysyłany z serwera proxy interfejsu API do innej usługi. Zmienna może zostać utworzona na podstawie poprzedniej zasady zawartej w procesie lub w treści zasady dotyczącej objaśnienia usługi.
<Request clearPayload="true" variable="myRequest"> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> <Remove> <ReasonPhrase/> <StatusCode/> <Path/> <Version/> <Verb/> </Remove> <Copy> <ReasonPhrase/> <StatusCode/> <Path/> <Version/> <Verb/> </Copy> <Add> <Headers/> <QueryParams/> <FormParams/> </Add> <Set> <Headers/> <QueryParams/> <FormParams/> <Payload/> <ReasonPhrase/> <StatusCode/> <Path/> <Version/> <Verb/> </Set> </Request>
Składnia tagów <Remove>, <Copy>, <Add> i <Set> jest taka sama jak w przypadku zasad przypisywania wiadomości.
Zasada zwraca błąd, jeśli nie można rozpoznać komunikatu żądania lub ma on nieprawidłowy typ komunikatu.
W najprostszym przykładzie przekazujesz zmienną zawierającą komunikat żądania, który został wypełniony wcześniej podczas procesu proxy interfejsu API:
<Request clearPayload="true" variable="myRequest"/>
Możesz też wypełnić wiadomość z prośbą wysłaną do usługi zewnętrznej w samych zasadach dotyczących objaśnienia usługi:
<Request> <Set> <Headers> <Header name="Accept">application/json</Header> </Headers> <Verb>POST</Verb> <Payload contentType="application/json">{"message":"my test message"}</Payload> </Set> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> </Request>
Domyślnie | Jeśli pominiesz element Request lub którykolwiek z jego atrybutów, Edge przypisze te wartości domyślne:
<Request clearPayload="true" variable="servicecallout.request"/> Przyjrzyjmy się, co oznaczają te wartości domyślne. Po pierwsze,
Ta nazwa domyślna jest ważne, jeśli używasz maskowania danych. Jeśli pominiesz nazwę zmiennej, musisz dodać |
Obecność | Opcjonalnie. |
Typ | Nie dotyczy |
Atrybuty
Atrybut | Opis | Domyślne | Obecność |
---|---|---|---|
zmienna |
Nazwa zmiennej, która będzie zawierać wiadomość z żądaniem. |
servicecallout.request |
Opcjonalnie |
clearPayload |
Jeśli ma wartość Ustaw opcję clearPayload na „false” tylko wtedy, gdy po wywołaniu wywołania usługi komunikat żądania jest wymagany. |
prawda | Opcjonalnie |
Element <Request>/<IgnorujUnresolvedVariables>
Gdy ma wartość true, zasada ignoruje wszystkie nierozwiązane błędy zmiennych w żądaniu.
<Request clearPayload="true" variable="myRequest"> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> </Request>
Domyślnie | false |
Obecność | Opcjonalnie |
Typ | Wartość logiczna |
Element <Response>
Uwzględnij ten element, jeśli logika serwera proxy interfejsu API wymaga odpowiedzi z wywołania zdalnego w celu dalszego przetwarzania.
Ten element określa nazwę zmiennej, która będzie zawierać odpowiedź otrzymaną z usługi zewnętrznej. Odpowiedź z celu jest przypisywana do zmiennej tylko wtedy, gdy zasada zostanie prawidłowo odczytana z całej odpowiedzi. Jeśli wywołanie zdalne nie powiedzie się z jakiegoś powodu, zasada zwraca błąd.
Jeśli pominiesz ten element, serwer proxy interfejsu API nie będzie czekać na odpowiedź. Wykonanie procedury serwera proxy interfejsu API jest kontynuowane w kolejnych krokach procesu. Jest to oczywiste, bo bez elementu Response
odpowiedź z środowiska docelowego nie jest dostępna do przetwarzania w kolejnych krokach i nie ma sposobu, aby przepływ serwera proxy wykrył błąd w wywołaniu zdalnym.
Typowe zastosowanie pomijania elementu Response
przy korzystaniu z wywołania ServiceCallout: w celu logowania komunikatów do systemu zewnętrznego.
<Response>calloutResponse</Response>
Domyślnie | Nie dotyczy |
Obecność | Opcjonalnie |
Typ | Ciąg znaków |
Element <Timeout>
Czas (w milisekundach) oczekiwania na odpowiedź od celu przez zasadę objaśnienia usługi. Nie możesz ustawić tej wartości dynamicznie w czasie działania. Jeśli wywołanie usługi przekroczy limit czasu, zwracany jest kod HTTP 500, zasada nie działa, a serwer proxy interfejsu API przechodzi w stan błędu, jak opisano w sekcji Obsługa błędów.
<Timeout>30000</Timeout>
Domyślnie | 55 000 milisekund (55 sekund) – domyślny limit czasu HTTP dla Apigee Edge |
Obecność | Opcjonalnie |
Typ | Liczba całkowita |
Element <HTTPTargetConnection>
Zawiera szczegółowe informacje dotyczące transportu, takie jak właściwości URL, TLS/SSL i HTTP. Więcej informacji znajdziesz w dokumentacji konfiguracji <TargetEndpoint>
.
<HTTPTargetConnection> <URL>http://example.com</URL> <LoadBalancer/> <SSLInfo/> <Properties/> </HTTPTargetConnection>
Domyślnie | Nie dotyczy |
Obecność | Wymagane |
Typ | Nie dotyczy |
Element <HTTPTargetConnection>/<URL>
Adres URL wywoływanej usługi:
<HTTPTargetConnection> <URL>http://example.com</URL> </HTTPTargetConnection>
Część adresu URL możesz podawać dynamicznie za pomocą zmiennej. Jednak części protokołu adresu URL (http:// poniżej) nie można określić za pomocą zmiennej. W następnym przykładzie używasz zmiennej, aby określić wartość parametru zapytania:
<URL>http://example.com/forecastrss?w=${request.header.woeid}</URL>
Możesz też ustawić część ścieżki adresu URL za pomocą zmiennej:
<URL>http://example.com/{request.resourcePath}?w=${request.header.woeid}</URL>
Jeśli chcesz użyć zmiennej do określenia domeny i portu adresu URL, użyj jednej zmiennej dla domeny i portu, a drugiej dla dowolnej innej części adresu URL:
<URL>http://{request.dom_port}/{request.resourcePath}</URL>
Domyślnie | Nie dotyczy |
Obecność | Wymagane |
Typ | Ciąg znaków |
Element <HTTPTargetConnection>/<SSLInfo>
Konfiguracja TLS/SSL w usłudze backendu. Informacje o konfiguracji TLS/SSL znajdziesz w sekcjach o konfigurowaniu protokołu TLS z brzegu do backendu (chmura i chmura prywatna) oraz w sekcji „Konfiguracja punktu końcowego TLS/SSL” w dokumentacji dotyczącej konfiguracji serwera proxy interfejsu API.
<HTTPTargetConnection> <URL>https://example.com</URL> <SSLInfo> <Enabled>true</Enabled> <ClientAuthEnabled>true</ClientAuthEnabled> <KeyStore>ref://mykeystoreref</KeyStore> ## Use of a reference is recommended <KeyAlias>myKey</KeyAlias> <TrustStore>myTruststore</TrustStore> <Ciphers/> <Protocols/> </SSLInfo> </HTTPTargetConnection>
Domyślnie | Nie dotyczy |
Obecność | Opcjonalnie |
Typ | Nie dotyczy |
Element <HTTPTargetConnection>/<Właściwości>
Właściwości transportu HTTP do usługi backendu. Więcej informacji znajdziesz w dokumentacji właściwości punktów końcowych.
<HTTPTargetConnection> <URL>http://example.com</URL> <Properties> <Property name="allow.http10">true</Property> <Property name="request.retain.headers"> User-Agent,Referer,Accept-Language </Property> </Properties> </HTTPTargetConnection>
Domyślnie | Nie dotyczy |
Obecność | Opcjonalnie |
Typ | Nie dotyczy |
Element <HTTPTargetConnection>/<LoadBalancer>
Wywołaj co najmniej 1 serwer docelowy i wykonaj na nich równoważenie obciążenia. Zapoznaj się z przykładem serwerów docelowych wywołań w sekcji Przykłady. Zobacz też Równoważenie obciążenia między serwerami backendu. Zapoznaj się też z tym postem na forum, w którym znajdziesz omówienie sposobów wywoływania serwerów docelowych zarówno z użyciem zasad objaśnień usługi, jak i reguł tras.
<HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="httpbin"/> <Server name="yahoo"/> </LoadBalancer> <Path>/get</Path> </HTTPTargetConnection>
Domyślnie | Nie dotyczy |
Obecność | Opcjonalnie |
Typ | nie dotyczy |
Element <LocalTargetConnection>
Określa lokalny serwer proxy – czyli serwer proxy w tej samej organizacji i środowisku – jako miejsce docelowe wywołań usługi.
Aby dokładniej określić wartość docelową, użyj elementów <APIProxy>
i <ProxyEndpoint>
lub elementu <Path>
.
<LocalTargetConnection> <APIProxy/> <ProxyEndpoint/> <Path/> </LocalTargetConnection>
Domyślnie | Nie dotyczy |
Obecność | Wymagane |
Typ | Nie dotyczy |
Element <LocalTargetConnection>/<APIProxy>
Nazwa serwera proxy interfejsu API, który jest celem wywołania lokalnego. Serwer proxy musi być w tej samej organizacji i środowisku co serwer proxy wywołujący połączenie.
<LocalTargetConnection> <APIProxy>data-manager</APIProxy> <ProxyEndpoint>default</ProxyEndpoint> </LocalTargetConnection>
Wraz z elementem <APIProxy>
uwzględnij element <ProxyEndpoint>
, by określić nazwę punktu końcowego serwera proxy, na który należy kierować wywołanie dla wywołania.
<LocalTargetConnection> <APIProxy/> <ProxyEndpoint/> </LocalTargetConnection>
Domyślnie | Nie dotyczy |
Obecność | Wymagane |
Typ | Ciąg znaków |
Element <LocalTargetConnection>/<ProxyEndpoint>
Nazwa punktu końcowego serwera proxy, który powinien być celem wywołań. To jest punkt końcowy serwera proxy interfejsu API określony za pomocą elementu <APIProxy>
.
<LocalTargetConnection> <APIProxy>data-manager</APIProxy> <ProxyEndpoint>default</ProxyEndpoint> </LocalTargetConnection>
Domyślnie | Nie dotyczy |
Obecność | Opcjonalnie |
Typ | Nie dotyczy |
Element <LocalTargetConnection>/<Path>
Ścieżka do punktu końcowego, na który jest kierowany. Punkt końcowy musi odwoływać się do serwera proxy w tej samej organizacji i środowisku co serwer proxy wywołujący połączenie.
Używaj jej zamiast pary <APIProxy>/<ProxyEndpoint>
, gdy nie znasz nazwy serwera proxy lub nie możesz na niej polegać. Ścieżka może być niezawodnym celem.
<LocalTargetConnection> <Path>/data-manager</Path> </LocalTargetConnection>
Domyślnie | Nie dotyczy |
Obecność | Opcjonalnie |
Typ | Nie dotyczy |
Schematy
Zmienne przepływu
Zmienne przepływu umożliwiają dynamiczne zachowanie zasad i przepływów w czasie działania w zależności od nagłówków HTTP, treści wiadomości lub kontekstu przepływu. Poniższe wstępnie zdefiniowane zmienne przepływu są dostępne po wykonaniu zasady objaśnienia usługi. Więcej informacji o zmiennych przepływu znajdziesz w artykule Informacje o zmiennych.
Objaśnienia dotyczące usługi mają własne żądania i odpowiedzi, a dostęp do tych danych można uzyskać za pomocą zmiennych. Główny komunikat zawiera prefiksy zmiennych request.*
i response.*
, dlatego użyj prefiksów myrequest.*
i calloutResponse.*
(wartości domyślne w konfiguracji objaśnienia usługi), aby uzyskać dane wiadomości specyficzne dla objaśnienia usługi. Pierwszy przykład w poniższej tabeli pokazuje, jak uzyskać nagłówki HTTP w objaśnieniu usługi.
Zmienna | Opis |
---|---|
Poniżej znajdziesz przykład pobierania nagłówków żądań i odpowiedzi objaśnienia usługi w podobny sposób, jak w przypadku nagłówków głównego żądania i odpowiedzi.
gdzie calloutResponse to nazwa zmiennej odpowiedzi w objaśnieniu do usługi, a myRequest to nazwa zmiennej żądania. Na przykład:
zwraca nagłówek Content-Length w odpowiedzi objaśnienia usługi. |
Zakres: od objaśnienia usługi do przodu Nagłówek wiadomości w żądaniu lub odpowiedzi objaśnienia usługi. Jeśli na przykład docelowym adresem serwera proxy interfejsu API jest http://example.com, a miejscem docelowym objaśnienia usługi jest http://mocktarget.apigee.net, te zmienne są nagłówkami wywołania http://mocktarget.apigee.net. |
servicecallout.requesturi |
Zakres: z przodu żądania objaśnienia usługi Identyfikator URI elementu TargetEndpoint dla zasady ServiceCallout. Identyfikator URI to docelowy adres URL punktu końcowego bez specyfikacji protokołu i domeny. |
servicecallout.{policy-name}.target.url |
Zakres: z przodu żądania objaśnienia usługi Docelowy URL objaśnienia usługi. |
gdzie |
Zakres: od odpowiedzi z objaśnieniem usługi dalej Treść odpowiedzi z objaśnienia usługi. |
servicecallout.{policy-name}.expectedcn |
Zakres: z przodu żądania objaśnienia usługi Oczekiwana wspólna nazwa punktu końcowego docelowego określona w zasadzie ServiceCallout. Jest to przydatne tylko wtedy, gdy docelowy punkt końcowy odnosi się do punktu końcowego TLS/SSL. |
servicecallout.{policy-name}.failed |
Zakres: od odpowiedzi z objaśnieniem usługi dalej Wartość logiczna wskazująca, czy zasada: powodzenie, fałsz, czy niepowodzenie, true (prawda). |
Błędy
W tej sekcji opisujemy kody błędów i komunikaty o błędach, które są zwracane, oraz zmienne błędów ustawiane przez Edge, gdy ta zasada wywołuje błąd. Te informacje są ważne, jeśli opracowujesz reguły dotyczące błędów do obsługi takich błędów. Więcej informacji znajdziesz w sekcjach Co musisz wiedzieć o błędach zasad i Postępowanie w przypadku 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.servicecallout.ExecutionFailed |
500 |
Ten błąd może wystąpić, gdy:
|
build |
steps.servicecallout.RequestVariableNotMessageType |
500 | Zmienna żądania określona w zasadzie nie jest typu Message. Ten błąd wystąpi na przykład, jeśli jest to ciąg znaków lub inny typ, który nie jest wiadomości. | build |
steps.servicecallout.RequestVariableNotRequestMessageType |
500 | Zmienna żądania określona w zasadzie nie jest typu „Request Message” (Wiadomość żądania). Jeśli jest to na przykład Typ odpowiedzi, wystąpi ten błąd. | build |
Błędy wdrażania
Te błędy mogą wystąpić podczas wdrażania serwera proxy zawierającego te zasady.
Nazwa błędu | Przyczyna | Napraw |
---|---|---|
URLMissing |
Brak elementu <URL> w elemencie <HTTPTargetConnection> lub jest on pusty. |
build |
ConnectionInfoMissing |
Ten błąd występuje, jeśli zasada nie ma elementu <HTTPTargetConnection> ani <LocalTargetConnection> . |
build |
InvalidTimeoutValue |
Ten błąd występuje, jeśli wartość <Timeout> jest ujemna lub zero. |
build |
Zmienne błędów
Te zmienne są ustawiane, gdy wystąpi błąd środowiska wykonawczego. Więcej informacji znajdziesz w artykule Co musisz wiedzieć o błędach związanych z naruszeniem zasad.
Zmienne | Gdzie | Przykład |
---|---|---|
fault.name="fault_name" |
fault_name to nazwa błędu podana w tabeli Błędy środowiska wykonawczego powyżej. Nazwa błędu to ostatnia część kodu. | fault.name = "RequestVariableNotMessageType" |
servicecallout.policy_name.failed |
policy_name to określona przez użytkownika nazwa zasady, która spowodowała błąd. | servicecallout.SC-GetUserData.failed = true |
Przykładowa odpowiedź na błąd
{ "fault":{ "detail":{ "errorcode":"steps.servicecallout.RequestVariableNotMessageType" }, "faultstring":"ServiceCallout[ServiceCalloutGetMockResponse]: request variable data_str value is not of type Message" } }
Przykładowa reguła błędu
<faultrule name="VariableOfNonMsgType"></faultrule><FaultRule name="RequestVariableNotMessageType"> <Step> <Name>AM-RequestVariableNotMessageType</Name> </Step> <Condition>(fault.name = "RequestVariableNotMessageType")</Condition> </FaultRule>
Powiązane artykuły
- Generowanie i modyfikowanie wiadomości: Przypisywanie zasad dotyczących wiadomości
- Wyodrębnianie zmiennych: zasady wyodrębniania zmiennych
- Zmienne: odniesienie do zmiennych
- Konfiguracja TLS/SSL
- Konfigurowanie protokołu TLS z brzegu do backendu (chmura i chmura prywatna)
- „TLS/SSL TargetEndpoint Configuration” (Konfiguracja punktu końcowego TLS/SSL) w dokumentacji dotyczącej konfiguracji serwera proxy interfejsu API
- Właściwości transportu HTTP: dokumentacja właściwości punktu końcowego
- Alternatywa dla objaśnienia usługi: klient HTTPClient napisany w języku JavaScript; patrz model obiektu JavaScript.