Wyświetlasz dokumentację Apigee Edge.
Zapoznaj się z dokumentacją Apigee X. info
Co
Zasada Service Callout umożliwia wywoływanie innej usługi z poziomu przepływu proxy interfejsu API. Możesz wykonywać wywołania usług zewnętrznych (np. zewnętrznego punktu końcowego usługi RESTful) lub usług wewnętrznych (np. serwera proxy interfejsu API w tej samej organizacji i środowisku).
- W przypadku zewnętrznego przypadku użycia wywołujesz interfejs API innej firmy, który jest zewnętrzny w stosunku do Twojego serwera proxy. Odpowiedź z interfejsu API innej firmy jest analizowana i wstawiana do wiadomości odpowiedzi interfejsu API, co wzbogaca i „miesza” dane dla użytkowników aplikacji. Możesz też wysłać żądanie za pomocą zasady Service Callout w przepływie żądania, a następnie przekazać informacje z odpowiedzi do elementu TargetEndpoint w proxy interfejsu API.
- W innym przypadku użycia wywołujesz serwer proxy, który znajduje się w tej samej organizacji i środowisku co serwer, z którego wywołujesz. Może to być przydatne na przykład wtedy, gdy masz serwer proxy, który oferuje pewną dyskretną funkcję niskiego poziomu, z której korzysta co najmniej 1 inny serwer proxy. Na przykład serwer proxy, który udostępnia operacje tworzenia, odczytywania, aktualizowania i usuwania w przypadku zaplecza pamięci danych, może być serwerem proxy docelowym dla wielu innych serwerów proxy, które udostępniają dane klientom.
Zasada obsługuje żądania przesyłane za pomocą protokołów HTTP i HTTPS.
Próbki
Połączenie lokalne 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 serwera w tej samej organizacji i środowisku) o nazwie data-manager, określając 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 w adresie URL użyto zmiennej, aby dynamicznie wypełniać adres URL celu. Część adresu URL z protokołem, czyli http://, nie może być określona przez zmienną. Musisz też używać osobnych zmiennych dla części adresu URL zawierającej domenę i dla pozostałej części adresu URL.
Zapytanie o geokodowanie lub definicję w 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ć go bezpośrednio w zasadzie Wywołanie usługi. W tym przykładzie zasada wywołania usługi ustawia wartości 3 parametrów zapytania przekazywanych do usługi zewnętrznej. W zasadach wywołania usługi możesz utworzyć całą wiadomość z żądaniem, 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 wywołania 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ść wiadomości z żądaniem jest wyodrębniana ze zmiennej o nazwie GeocodingRequest (która może być wypełniana np. przez zasadę AssignMessage). Wiadomość z odpowiedzią jest przypisywana do zmiennej o nazwie GeocodingResponse, w której jest dostępna do analizowania przez zasadę wyodrębniania zmiennych lub przez niestandardowy kod napisany w JavaScript lub Javie. Zasada czeka 30 sekund na odpowiedź z interfejsu Google Geocoding API, zanim przekroczy limit czasu.
Pełny przykładowy serwer proxy interfejsu API, który korzysta z tego przykładu wywołania usługi oraz zasad przypisywania wiadomości i wyodrębniania zmiennych, znajdziesz w artykule Korzystanie z kompozycji zasad.
Wywoływanie serwerów docelowych
<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 używa atrybutu LoadBalancer do wywoływania serwerów docelowych i równoważenia obciążenia między nimi. W tym przykładzie obciążenie jest rozdzielane między 2 serwery docelowe o nazwach „httpbin” i „yahoo”. Informacje o konfigurowaniu serwerów docelowych dla serwera proxy i równoważenia obciążenia znajdziesz w artykule Równoważenie obciążenia na serwerach backendu.
Informacje o zasadzie wywołania usługi
W proxy interfejsu API możesz używać zasady wywołania usługi w wielu sytuacjach. Możesz na przykład skonfigurować serwer proxy interfejsu API, aby wywoływał zewnętrzną usługę w celu dostarczania danych geolokalizacyjnych, opinii klientów, produktów z katalogu detalicznego partnera itp.
Wywołanie zewnętrzne jest zwykle używane z 2 innymi zasadami: Przypisz wiadomość i Wyodrębnij zmienne.
- Żądanie: opcja Przypisz wiadomość wypełnia wiadomość z żądaniem wysłaną do usługi zdalnej.
-
Odpowiedź: funkcja Wyodrębnij zmienne analizuje odpowiedź i wyodrębnia z niej określone treści.
Typowa struktura zasad wywołań usługi obejmuje:
- Zasady przypisywania wiadomości: tworzy wiadomość z żądaniem, wypełnia nagłówki HTTP, parametry zapytania, ustawia czasownik HTTP itp.
- Zasada Wywołanie usługi: odwołuje się do wiadomości utworzonej przez zasadę Przypisz wiadomość, określa docelowy adres URL wywołania zewnętrznego i definiuje nazwę obiektu odpowiedzi, który zwraca usługa docelowa.
Aby zwiększyć wydajność, możesz też buforować odpowiedzi na wywołania usługi, jak opisano w tym wątku na forum społeczności Apigee: How can I store the results of the ServiceCallout policy in cache and later retrieve it from cache? (Jak mogę przechowywać wyniki zasady ServiceCallout w pamięci podręcznej i później je z niej pobierać?). - Extract Variables policy: zazwyczaj definiuje wyrażenie JSONPath lub XPath, które analizuje wiadomość wygenerowaną przez wywołanie usługi. Następnie zasada ustawia zmienne zawierające wartości przeanalizowane z odpowiedzi wywołania usługi.
Pełny przykładowy serwer proxy interfejsu API, który korzysta z zasad Service Callout wraz z zasadami Assign Message i Extract Variables, znajdziesz w artykule Korzystanie z kompozycji zasad.
Niestandardowa obsługa błędów
Odwołanie do elementu
Oto elementy i atrybuty, które możesz skonfigurować w tych zasadach:
<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">
W tej tabeli opisano atrybuty wspólne dla wszystkich elementów nadrzędnych zasad:
| Atrybut | Opis | Domyślny | Obecność |
|---|---|---|---|
name |
Wewnętrzna nazwa zasady. Wartość atrybutu Opcjonalnie możesz użyć elementu |
Nie dotyczy | Wymagane |
continueOnError |
Ustaw jako Ustaw jako |
fałsz | Opcjonalnie |
enabled |
Aby egzekwować zasadę, ustaw wartość Aby wyłączyć zasadę, ustaw wartość |
prawda | Opcjonalnie |
async |
Ten atrybut został wycofany. |
fałsz | Wycofano |
<DisplayName> element
Używaj oprócz atrybutu name do oznaczania zasady w
edytor proxy interfejsu zarządzania z inną nazwą w języku naturalnym.
<DisplayName>Policy Display Name</DisplayName>
| Domyślny |
Nie dotyczy Jeśli pominiesz ten element, atrybut |
|---|---|
| Obecność | Opcjonalnie |
| Typ | Ciąg znaków |
Element <Request>
Określa zmienną zawierającą wiadomość z żądaniem, która jest wysyłana z proxy interfejsu API do innej usługi. Zmienną może utworzyć poprzednia zasada w przepływie lub możesz ją utworzyć w zasadzie wywołania 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 zasady przypisywania wiadomości.
Zasady zwracają błąd, jeśli nie można rozpoznać wiadomości z żądaniem lub ma ona nieprawidłowy typ.
W najprostszym przykładzie przekazujesz zmienną zawierającą wiadomość żądania, która została wypełniona wcześniej w procesie serwera proxy interfejsu API:
<Request clearPayload="true" variable="myRequest"/>
Możesz też wypełnić wiadomość z prośbą wysyłaną do usługi zewnętrznej w samych zasadach wywołania 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ślna | Jeśli pominiesz element Request lub którykolwiek z jego atrybutów, Edge przypisze następujące wartości domyślne:
<Request clearPayload="true" variable="servicecallout.request"/> Sprawdźmy, co oznaczają te wartości domyślne. Po pierwsze,
Warto znać tę domyślną nazwę, jeśli używasz maskowania danych – jeśli pominiesz nazwę zmiennej, musisz dodać |
| Obecność | Opcjonalnie: |
| Typ | Nie dotyczy |
Atrybuty
| Atrybut | Opis | Domyślny | Obecność |
|---|---|---|---|
| zmienna |
Nazwa zmiennej, która będzie zawierać wiadomość z żądaniem. |
servicecallout.request |
Opcjonalny |
| clearPayload |
Jeśli Opcję clearPayload ustaw na wartość false tylko wtedy, gdy wiadomość z żądaniem jest wymagana po wykonaniu wywołania usługi. |
prawda | Opcjonalny |
Element <Request>/<IgnoreUnresolvedVariables>
Jeśli zasada ma wartość true, ignoruje ona wszelkie nierozwiązane błędy zmiennych w żądaniu.
<Request clearPayload="true" variable="myRequest"> <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables> </Request>
| Domyślna | fałsz |
| Obecność | Opcjonalny |
| Typ | Wartość logiczna |
Element <Response>
Użyj tego elementu, gdy logika proxy API wymaga odpowiedzi z wywołania zdalnego do dalszego przetwarzania.
Jeśli ten element jest obecny, określa nazwę zmiennej, która będzie zawierać wiadomość z odpowiedzią otrzymaną z usługi zewnętrznej. Odpowiedź z usługi docelowej jest przypisywana do zmiennej tylko wtedy, gdy zasada odczyta całą odpowiedź. Jeśli wywołanie zdalne zakończy się niepowodzeniem z jakiegokolwiek powodu, zasada zwróci błąd.
Jeśli ten element zostanie pominięty, serwer proxy interfejsu API nie będzie czekać na odpowiedź, a wykonywanie przepływu serwera proxy interfejsu API będzie kontynuowane z kolejnymi krokami przepływu. Ponadto, co oczywiste, bez elementu Response odpowiedź z usługi docelowej nie jest dostępna do przetworzenia w kolejnych krokach, a przepływ proxy nie może wykryć błędu w wywołaniu zdalnym.
Częstym zastosowaniem pomijania elementu Response podczas korzystania z elementu ServiceCallout jest rejestrowanie wiadomości w systemie zewnętrznym.
<Response>calloutResponse</Response>
| Domyślna | Nie dotyczy |
| Obecność | Opcjonalny |
| Typ | Ciąg znaków |
Element <Timeout>
Czas w milisekundach, przez jaki zasada wywołania usługi będzie czekać na odpowiedź z miejsca docelowego. Nie możesz ustawić tej wartości dynamicznie w czasie działania programu. Jeśli wywołanie usługi osiągnie limit czasu, zwracany jest kod HTTP 500, zasady nie działają, a proxy interfejsu API przechodzi w stan błędu, jak opisano w sekcji Obsługa błędów.
<Timeout>30000</Timeout>
| Domyślna | 55000 milisekund (55 sekund), domyślne ustawienie limitu czasu HTTP w Apigee Edge |
| Obecność | Opcjonalny |
| Typ | Liczba całkowita |
Element <HTTPTargetConnection>
Zawiera szczegóły transportu, takie jak URL, TLS/SSL i właściwości HTTP. Zapoznaj się z <TargetEndpoint> odniesieniem do konfiguracji.
<HTTPTargetConnection>
<URL>http://example.com</URL>
<LoadBalancer/>
<SSLInfo/>
<Properties/>
</HTTPTargetConnection>| Domyślna | 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 podać dynamicznie za pomocą zmiennej. Część adresu URL zawierająca protokół, czyli http://, nie może być jednak określona przez zmienną. W następnym przykładzie użyjesz 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 tylko dla domeny i portu, a drugiej zmiennej dla pozostałych części adresu URL:
<URL>http://{request.dom_port}/{request.resourcePath}</URL>| Domyślna | Nie dotyczy |
| Obecność | Wymagane |
| Typ | Ciąg znaków |
Element <HTTPTargetConnection>/<SSLInfo>
Konfiguracja TLS/SSL usługi backendu. Pomoc dotyczącą konfiguracji TLS/SSL znajdziesz w artykułach Konfigurowanie protokołu TLS od Edge do backendu (Cloud i Private Cloud) oraz „Konfiguracja TargetEndpoint TLS/SSL” w dokumentacji 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ślna | Nie dotyczy |
| Obecność | Opcjonalny |
| Typ | Nie dotyczy |
Element <HTTPTargetConnection>/<Properties>
Właściwości transportu HTTP do usługi backendu. Więcej informacji znajdziesz w dokumentacji właściwości punktu końcowego.
<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ślna | Nie dotyczy |
| Obecność | Opcjonalny |
| Typ | Nie dotyczy |
Element <HTTPTargetConnection>/<LoadBalancer>
wywoływać co najmniej 1 serwer docelowy i równoważyć na nim obciążenie; Zobacz przykładowy kod Wywoływanie serwerów docelowych w sekcji Przykłady. Zobacz też Równoważenie obciążenia na serwerach backendu. Zapoznaj się też z tym postem na forum, w którym omawiamy sposoby wywoływania serwerów docelowych zarówno za pomocą zasady Service Callout, jak i reguł routingu.
<HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="httpbin"/> <Server name="yahoo"/> </LoadBalancer> <Path>/get</Path> </HTTPTargetConnection>
| Domyślna | Nie dotyczy |
| Obecność | Opcjonalny |
| Typ | Nie dotyczy |
Element <LocalTargetConnection>
Określa lokalny serwer proxy – czyli serwer proxy w tej samej organizacji i środowisku – jako cel wywołań usługi.
Aby dokładniej określić cel, użyj elementów <APIProxy> i <ProxyEndpoint> lub elementu <Path>.
<LocalTargetConnection> <APIProxy/> <ProxyEndpoint/> <Path/> </LocalTargetConnection>
| Domyślna | Nie dotyczy |
| Obecność | Wymagane |
| Typ | Nie dotyczy |
Element <LocalTargetConnection>/<APIProxy>
Nazwa proxy interfejsu API, który jest celem wywołania lokalnego. Serwer proxy musi znajdować się w tej samej organizacji i środowisku co serwer proxy, który wykonuje wywołanie.
<LocalTargetConnection> <APIProxy>data-manager</APIProxy> <ProxyEndpoint>default</ProxyEndpoint> </LocalTargetConnection>
Oprócz elementu <APIProxy> dodaj element <ProxyEndpoint>, aby określić nazwę punktu końcowego serwera proxy, do którego ma być kierowane połączenie.
<LocalTargetConnection> <APIProxy/> <ProxyEndpoint/> </LocalTargetConnection>
| Domyślna | Nie dotyczy |
| Obecność | Wymagane |
| Typ | Ciąg znaków |
Element <LocalTargetConnection>/<ProxyEndpoint>
Nazwa punktu końcowego serwera proxy, który ma być celem połączeń. Jest to punkt końcowy proxy w proxy interfejsu API określony za pomocą elementu <APIProxy>.
<LocalTargetConnection> <APIProxy>data-manager</APIProxy> <ProxyEndpoint>default</ProxyEndpoint> </LocalTargetConnection>
| Domyślna | Nie dotyczy |
| Obecność | Opcjonalny |
| Typ | Nie dotyczy |
Element <LocalTargetConnection>/<Path>
Ścieżka do punktu końcowego, na który kierowane są reklamy. Punkt końcowy musi odwoływać się do serwera proxy w tej samej organizacji i środowisku co serwer proxy, który wykonuje wywołanie.
Używaj tego tagu zamiast pary <APIProxy>/<ProxyEndpoint>, gdy nie znasz nazwy serwera proxy lub nie możesz na niej polegać. Ścieżka może być wiarygodnym celem.
<LocalTargetConnection> <Path>/data-manager</Path> </LocalTargetConnection>
| Domyślna | Nie dotyczy |
| Obecność | Opcjonalny |
| Typ | Nie dotyczy |
Schematy
Zmienne przepływu
Zmienne przepływu umożliwiają dynamiczne działanie zasad i przepływów w czasie działania na podstawie nagłówków HTTP, treści wiadomości lub kontekstu przepływu. Po wykonaniu zasady wywołania usługi dostępne są te wstępnie zdefiniowane zmienne Flow: Więcej informacji o zmiennych przepływu znajdziesz w dokumentacji zmiennych.
Wywołania usługi mają własne żądanie i odpowiedź, a dostęp do tych danych możesz uzyskać za pomocą zmiennych. Główna wiadomość używa prefiksów zmiennych request.* i response.*, więc użyj prefiksów myrequest.* i calloutResponse.* (domyślnych w konfiguracji wywołania usługi), aby uzyskać dane wiadomości specyficzne dla wywołania usługi. Pierwszy przykład w tabeli poniżej pokazuje, jak uzyskać nagłówki HTTP w wywołaniu usługi.
| Zmienna | Opis |
|---|---|
|
Poniżej znajdziesz przykład pobierania nagłówków żądania i odpowiedzi wywołania usługi w sposób podobny do pobierania nagłówków z głównego żądania i odpowiedzi.
gdzie calloutResponse to nazwa zmiennej odpowiedzi w wywołaniu usługi, a myRequest to nazwa zmiennej żądania. Na przykład:
zwraca nagłówek Content-Length odpowiedzi wywołania usługi. |
Zakres: od wywołania usługi Nagłówek wiadomości w żądaniu lub odpowiedzi wywołania usługi. Jeśli np. miejscem docelowym serwera proxy interfejsu API jest http://example.com, a miejscem docelowym wywołania usługi jest http://mocktarget.apigee.net, te zmienne są nagłówkami wywołania do http://mocktarget.apigee.net. |
servicecallout.requesturi |
Zakres: od żądania wywołania usługi Identyfikator URI TargetEndpoint dla zasady ServiceCallout. Identyfikator URI to adres URL TargetEndpoint bez protokołu i specyfikacji domeny. |
servicecallout.{policy-name}.target.url |
Zakres: od żądania wywołania usługi Docelowy adres URL wywołania usługi. |
|
gdzie |
Zakres: od odpowiedzi wywołania usługi Treść odpowiedzi z wywołania usługi. |
servicecallout.{policy-name}.expectedcn |
Zakres: od żądania wywołania usługi Oczekiwana nazwa pospolita TargetEndpoint, do której odwołuje się zasada ServiceCallout. Ma to znaczenie tylko wtedy, gdy TargetEndpoint odnosi się do punktu końcowego TLS/SSL. |
servicecallout.{policy-name}.failed |
Zakres: od odpowiedzi wywołania usługi Wartość logiczna wskazująca, czy zasada została zastosowana (fałsz) czy nie (prawda). |
Błędy
This section describes the fault codes and error messages that are returned and fault variables that are set by Edge when this policy triggers an error. This information is important to know if you are developing fault rules to handle faults. To learn more, see What you need to know about policy errors and Handling faults.
Runtime errors
These errors can occur when the policy executes.
| Fault code | HTTP status | Cause | Fix |
|---|---|---|---|
steps.servicecallout.ExecutionFailed |
500 |
This error can occur when:
|
build |
steps.servicecallout.RequestVariableNotMessageType |
500 | The Request variable specified in the policy is not of type Message. For example, if it's a string or other non-message type, you'll see this error. | build |
steps.servicecallout.RequestVariableNotRequestMessageType |
500 | The Request variable specified in the policy is not of type Request Message. For example, if it's a Response type, you'll see this error. | build |
Deployment errors
These errors can occur when you deploy a proxy containing this policy.
| Error name | Cause | Fix |
|---|---|---|
URLMissing |
The <URL> element inside <HTTPTargetConnection>
is missing or empty. |
build |
ConnectionInfoMissing |
This error happens if the policy does not have an
<HTTPTargetConnection> or <LocalTargetConnection>
element. |
build |
InvalidTimeoutValue |
This error happens if the <Timeout> value is negative or zero. |
build |
Fault variables
These variables are set when a runtime error occurs. For more information, see What you need to know about policy errors.
| Variables | Where | Example |
|---|---|---|
fault.name="fault_name" |
fault_name is the name of the fault, as listed in the Runtime errors table above. The fault name is the last part of the fault code. | fault.name = "RequestVariableNotMessageType" |
servicecallout.policy_name.failed |
policy_name is the user-specified name of the policy that threw the fault. | servicecallout.SC-GetUserData.failed = true |
Example error response
{ "fault":{ "detail":{ "errorcode":"steps.servicecallout.RequestVariableNotMessageType" }, "faultstring":"ServiceCallout[ServiceCalloutGetMockResponse]: request variable data_str value is not of type Message" } }
Example fault rule
<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 Extract Variables
- Zmienne: Zmienne odwołanie
- Konfiguracja TLS/SSL
- Konfigurowanie protokołu TLS od Edge do backendu (Cloud i Private Cloud)
- „Konfiguracja TLS/SSL TargetEndpoint” w dokumentacji konfiguracji proxy interfejsu API
- Właściwości transportu HTTP: Dokumentacja właściwości punktu końcowego
- Alternatywa dla wywołania usługi: HTTPClient napisany w JavaScript, patrz model obiektów JavaScript