Zasady dotyczące objaśnień dotyczących usług

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:

  1. Przypisz zasadę dotyczącą wiadomości: tworzy wiadomość żądania, wypełnia nagłówki HTTP, parametry zapytania, ustawia czasownik HTTP itp.
  2. 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.
  3. 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 name może zawierać litery, cyfry, spacje, łączniki, podkreślenia i kropki. Ta wartość nie może przekraczać 255 znaków.

Opcjonalnie możesz użyć elementu <DisplayName>, aby oznaczyć zasadę w edytorze serwera proxy interfejsu zarządzania inną nazwą w języku naturalnym.

Nie dotyczy Wymagane
continueOnError

Ustaw wartość false, aby zwracać błąd w przypadku niepowodzenia zasady. Jest to normalne działanie większości zasad.

Ustaw jako true, aby wykonywanie przepływu było kontynuowane nawet po awarii zasady.

false Opcjonalnie
enabled

Ustaw jako true, aby wymuszać zasadę.

Ustaw wartość false, aby wyłączyć tę zasadę. Zasada nie będzie egzekwowana, nawet jeśli pozostanie dołączona do procesu.

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 name zasady.

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, clearPayload=true oznacza, że przy każdym uruchomieniu zasady ServiceCallout tworzony jest nowy obiekt żądania. Oznacza to, że żądanie ani ścieżka identyfikatora URI żądania nie są nigdy ponownie używane. Po drugie: domyślna nazwa zmiennej (servicecallout.request) jest nazwą zarezerwowaną, która jest przypisywana do żądania, jeśli jej nie podasz.

Ta nazwa domyślna jest ważne, jeśli używasz maskowania danych. Jeśli pominiesz nazwę zmiennej, musisz dodać servicecallout.request do konfiguracji maski. Jeśli na przykład chcesz zamaskować nagłówek autoryzacji, aby nie pojawiał się w sesjach śledzenia, dodaj ten nagłówek do konfiguracji maskowania, aby przechwycić nazwę domyślną:

servicecallout.request.header.Authorization.

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ść true, zmienna zawierająca komunikat żądania jest czyszczona po wysłaniu żądania do celu HTTP, aby zwolnić pamięć używaną przez wiadomość żądania.

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.

calloutResponse.header.HeaderName

myRequest.header.HeaderName

gdzie calloutResponse to nazwa zmiennej odpowiedzi w objaśnieniu do usługi, a myRequest to nazwa zmiennej żądania. Na przykład:

calloutResponse.header.Content-Length

zwraca nagłówek Content-Length w odpowiedzi objaśnienia usługi.

Zakres: od objaśnienia usługi do przodu
Typ: ciąg
Uprawnienie: do odczytu/zapisu

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
Typ: ciąg znaków
Uprawnienie: do odczytu/zapisu

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
Typ: ciąg znaków
Uprawnienie: do odczytu/zapisu

Docelowy URL objaśnienia usługi.

calloutResponse.content

gdzie calloutResponse to nazwa zmiennej <Response>w konfiguracji objaśnienia usługi.

Zakres: od odpowiedzi z objaśnieniem usługi dalej
Typ: ciąg znaków
Uprawnienie: do odczytu/zapisu

Treść odpowiedzi z objaśnienia usługi.

servicecallout.{policy-name}.expectedcn

Zakres: z przodu żądania objaśnienia usługi
Typ: ciąg znaków
Uprawnienie: do odczytu/zapisu

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
Typ: wartość logiczna
Uprawnienie: do odczytu/zapisu

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:

  • zasada prosi o obsługę danych wejściowych, które są zniekształcone lub z innego powodu nieprawidłowe.
  • docelowa usługa backendu zwraca stan błędu (domyślnie 4xx lub 5xx).
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.
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.

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.
ConnectionInfoMissing Ten błąd występuje, jeśli zasada nie ma elementu <HTTPTargetConnection> ani <LocalTargetConnection>.
InvalidTimeoutValue Ten błąd występuje, jeśli wartość <Timeout> jest ujemna lub zero.

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