Kebijakan ServiceInfo

Anda sedang melihat dokumentasi Apigee Edge.
Lihat dokumentasi Apigee X.

Apa

Kebijakan Info Layanan memungkinkan Anda melakukan panggilan ke layanan lain dari alur proxy API Anda. Anda dapat membuat pemanggilan ke layanan eksternal (seperti endpoint layanan RESTful eksternal) atau layanan internal (seperti proxy API di organisasi dan lingkungan yang sama).

  • Dalam kasus penggunaan eksternal, Anda membuat info ke API pihak ketiga yang berada di luar proxy Anda. Respons dari API pihak ketiga diuraikan dan dimasukkan ke dalam pesan respons API Anda, yang akan memperkaya dan "menyatukan" data untuk pengguna akhir aplikasi. Anda juga dapat membuat permintaan menggunakan kebijakan Info Layanan dalam alur permintaan, lalu meneruskan informasi tersebut dalam respons ke TargetEndpoint proxy API.
  • Dalam kasus penggunaan lain, Anda memanggil proxy yang berada di organisasi dan lingkungan yang sama dengan tempat Anda menelepon. Misalnya, ini mungkin akan berguna saat Anda memiliki proxy yang menawarkan beberapa fungsi tingkat rendah terpisah yang akan digunakan oleh satu atau beberapa proxy lain. Misalnya, proxy yang mengekspos operasi buat/baca/perbarui/hapus dengan penyimpanan data backend dapat berupa proxy target untuk beberapa proxy lain yang mengekspos data ke klien.

Kebijakan ini mendukung permintaan melalui HTTP dan HTTPS.

Contoh

Panggilan lokal ke proxy internal

<LocalTargetConnection>
    <APIProxy>data-manager</APIProxy>
    <ProxyEndpoint>default</ProxyEndpoint>
</LocalTargetConnection>

Contoh ini membuat info ke proxy API lokal (yaitu, yang ada di organisasi dan lingkungan yang sama) yang disebut data-manager, yang menentukan endpoint proxy yang namanya default.

URL sebagai variabel

<HTTPTargetConnection>
    <URL>http://example.com/{request.myResourcePath}</URL>
</HTTPTargetConnection>

Contoh ini menggunakan variabel di URL untuk mengisi URL target secara dinamis. Bagian protokol URL, http://, tidak dapat ditentukan oleh variabel. Selain itu, Anda harus menggunakan variabel terpisah untuk bagian domain URL dan untuk URL lainnya.

Melakukan geocoding Google / menentukan permintaan

<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

Anda dapat menentukannya langsung di kebijakan Info Layanan, bukan menggunakan kebijakan seperti Tetapkan Pesan untuk membuat objek permintaan. Dalam contoh ini, kebijakan Info Layanan menetapkan nilai tiga parameter kueri yang diteruskan ke layanan eksternal. Anda dapat membuat seluruh pesan permintaan dalam kebijakan Info Layanan yang menentukan payload, jenis encoding seperti application/xml, header, parameter formulir, dll.

Berikut adalah contoh lain tempat permintaan dibuat sebelum mencapai kebijakan Info Layanan.

<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>

Konten pesan permintaan diekstrak dari variabel yang disebut GeocodingRequest (yang dapat diisi, misalnya, oleh kebijakanassignMessage). Pesan respons ditetapkan ke variabel yang disebut GeocodingResponse, yang pesannya dapat diurai oleh kebijakan Extract Variables atau kode kustom yang ditulis dalam JavaScript atau Java. Kebijakan ini menunggu respons selama 30 detik dari Google Geocoding API sebelum waktu habis.

Untuk contoh lengkap proxy API yang menggunakan contoh Info Layanan ini, beserta kebijakan Tetapkan Pesan dan Ekstrak Variabel, lihat Menggunakan komposisi kebijakan.

Server target panggilan

<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>

Kebijakan ini menggunakan atribut LoadBalancer untuk memanggil server target dan melakukan load balancing di seluruh server. Dalam contoh ini, beban didistribusikan di dua server target yang bernama "httpbin" dan "yahoo". Untuk informasi tentang cara menyiapkan Server Target untuk proxy Anda dan mengonfigurasi load balancing, lihat Load balancing di seluruh server backend.


Tentang kebijakan Info Layanan

Ada banyak skenario yang memungkinkan Anda menggunakan kebijakan Info Layanan di proxy API. Misalnya, Anda dapat mengonfigurasi proxy API untuk melakukan panggilan ke layanan eksternal guna mengirimkan data geolokasi, ulasan pelanggan, item dari katalog retail partner, dan sebagainya.

Info biasanya digunakan dengan dua kebijakan lainnya: Menetapkan Variabel Pesan dan Ekstrak.

  • Request: Tetapkan Pesan akan mengisi pesan permintaan yang dikirim ke layanan jarak jauh.
  • Respons: Ekstrak Variabel akan menguraikan respons dan mengekstrak konten tertentu.

Komposisi kebijakan Info Layanan standar mencakup:

  1. Tetapkan kebijakan Pesan: Membuat pesan permintaan, mengisi header HTTP, parameter kueri, menetapkan kata kerja HTTP, dll.
  2. Kebijakan Pemanggilan Layanan: Mereferensikan pesan yang dibuat oleh kebijakan Tetapkan Pesan, menentukan URL target untuk panggilan eksternal, dan menentukan nama untuk objek respons yang ditampilkan oleh layanan target.

    Untuk meningkatkan performa, Anda juga dapat menyimpan respons Pemanggilan Layanan dalam cache, seperti yang dijelaskan dalam rangkaian Komunitas Apigee ini: https://community.apigee.com/questions/34110/how-can-i-store-the-results-of-the-servicecallout.html.
  3. Mengekstrak kebijakan Variabel: Biasanya menentukan ekspresi JSONPath atau XPath yang menguraikan pesan yang dihasilkan oleh Info Layanan. Kebijakan ini kemudian menetapkan variabel yang berisi nilai yang diuraikan dari respons Info Layanan.

Lihat Menggunakan komposisi kebijakan untuk contoh proxy API lengkap yang menggunakan kebijakan Panggilan Layanan beserta kebijakan Tetapkan Pesan dan Ekstrak Variabel.

Penanganan error kustom

Referensi elemen

Berikut adalah elemen dan atribut yang dapat Anda konfigurasikan pada kebijakan ini:

<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>

Atribut <ServiceInfo>

<ServiceCallout async="false" continueOnError="false" enabled="true" name="Service-Callout-1">

Tabel berikut menjelaskan atribut yang sama untuk semua elemen induk kebijakan:

Atribut Deskripsi Default Ketersediaan
name

Nama internal kebijakan. Nilai atribut name dapat berisi huruf, angka, spasi, tanda hubung, garis bawah, dan titik. Nilai ini tidak boleh melebihi 255 karakter.

Secara opsional, gunakan elemen <DisplayName> untuk memberi label kebijakan di editor proxy UI pengelolaan dengan nama bahasa alami yang berbeda.

T/A Wajib
continueOnError

Tetapkan ke false untuk menampilkan error saat kebijakan gagal. Hal ini wajar untuk sebagian besar kebijakan.

Tetapkan ke true agar eksekusi flow dapat dilanjutkan bahkan setelah kebijakan gagal.

false Opsional
enabled

Tetapkan ke true untuk menerapkan kebijakan.

Tetapkan ke false untuk menonaktifkan kebijakan. Kebijakan ini tidak akan diterapkan meskipun tetap dilampirkan ke flow.

benar Opsional
async

Atribut ini tidak digunakan lagi.

false Tidak digunakan lagi

Elemen <DisplayName>

Selain atribut name, beri label pada kebijakan di editor proxy UI pengelolaan dengan nama bahasa natural yang berbeda.

<DisplayName>Policy Display Name</DisplayName>
Default

T/A

Jika Anda menghilangkan elemen ini, nilai atribut name kebijakan akan digunakan.

Ketersediaan Opsional
Type String

Elemen <Request>

Menentukan variabel yang berisi pesan permintaan yang dikirim dari proxy API ke layanan lainnya. Variabel dapat dibuat oleh kebijakan sebelumnya dalam alur, atau Anda dapat membuatnya inline di kebijakan Info Layanan.

<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>

Sintaksis untuk tag <Remove>, <Copy>, <Add>, dan <Set> sama dengan kebijakan Tetapkan Pesan.

Kebijakan ini akan menampilkan error jika pesan permintaan tidak dapat diselesaikan atau jenis pesan permintaan tidak valid.

Pada contoh paling sederhana, Anda meneruskan variabel yang berisi pesan permintaan yang diisi sebelumnya dalam alur proxy API:

<Request clearPayload="true" variable="myRequest"/>

Atau, Anda dapat mengisi pesan permintaan yang dikirim ke layanan eksternal di kebijakan Info Layanan itu sendiri:

<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>
Default Jika Anda menghapus elemen Permintaan, atau salah satu atributnya, Edge menetapkan nilai default berikut:

<Request clearPayload="true" variabel="servicecallout.request"/>

Mari kita lihat arti nilai default ini. Pertama, clearPayload=true berarti objek permintaan baru dibuat setiap kali kebijakan ServiceInfo dijalankan. Artinya, permintaan dan jalur URI permintaan tidak akan pernah digunakan kembali. Kedua, nama variabel default, servicecallout.request, adalah nama yang dicadangkan yang ditetapkan ke permintaan jika Anda tidak memberikan nama.

Penting untuk mengetahui nama default ini jika Anda menggunakan penyamaran data. Jika Anda menghapus nama variabel, Anda perlu menambahkan servicecallout.request ke konfigurasi mask Anda. Misalnya, jika ingin menyamarkan header Authorization agar tidak muncul di sesi Trace, Anda harus menambahkan baris berikut ke konfigurasi masking untuk mengambil nama default:

servicecallout.request.header.Authorization.

Kehadiran Opsional.
Jenis T/A

Atribut

Atribut Deskripsi Default Ketersediaan
variabel

Nama variabel yang akan berisi pesan permintaan.

servicecallout.request Opsional
clearPayload

Jika true, variabel yang berisi pesan permintaan akan dihapus setelah permintaan dikirim ke target HTTP untuk mengosongkan memori yang digunakan oleh pesan permintaan.

Tetapkan opsi clearPayload ke false hanya jika pesan permintaan diperlukan setelah Info Layanan dieksekusi.

true Opsional

Elemen <Request>/<IgnoreUnresolvedVariables>

Jika disetel ke true, kebijakan akan mengabaikan error variabel yang belum terselesaikan dalam permintaan.

<Request clearPayload="true" variable="myRequest">
    <IgnoreUnresolvedVariables>false</IgnoreUnresolvedVariables>
</Request> 
Default false
Kehadiran Opsional
Jenis Boolean

Elemen <Response>

Sertakan elemen ini jika logika proxy API memerlukan respons dari panggilan jarak jauh untuk pemrosesan lebih lanjut.

Jika ada, elemen ini akan menentukan nama variabel yang akan berisi pesan respons yang diterima dari layanan eksternal. Respons dari target ditetapkan ke variabel hanya jika seluruh respons berhasil dibaca oleh kebijakan. Jika panggilan jarak jauh gagal karena alasan apa pun, kebijakan akan menampilkan error.

Jika elemen ini dihilangkan, proxy API tidak menunggu respons; Eksekusi alur Proxy API berlanjut dengan langkah-langkah alur berikutnya. Selain itu, untuk menyatakan dengan jelas, tanpa elemen Response, respons dari target tidak tersedia untuk diproses oleh langkah berikutnya, dan tidak ada cara bagi alur proxy untuk mendeteksi kegagalan dalam panggilan jarak jauh. Penggunaan umum untuk menghilangkan elemen Response saat menggunakan ServiceInfo: untuk mencatat pesan ke sistem eksternal ke dalam log.

 <Response>calloutResponse</Response> 
Default TA
Kehadiran Opsional
Jenis String

Elemen <Timeout>

Waktu dalam milidetik saat kebijakan Info Layanan akan menunggu respons dari target. Anda tidak dapat menetapkan nilai ini secara dinamis saat runtime. Jika Info Layanan mengenai waktu tunggu, HTTP 500 akan ditampilkan, kebijakan akan gagal, dan proxy API akan mengalami error, seperti yang dijelaskan dalam Menangani kesalahan.

<Timeout>30000</Timeout>
Default 55000 milidetik (55 detik), setelan waktu tunggu HTTP default untuk Apigee Edge
Kehadiran Opsional
Jenis Bilangan bulat

Elemen <HTTPTargetConnection>

Memberikan detail transpor seperti properti URL, TLS/SSL, dan HTTP. Lihat referensi konfigurasi <TargetEndpoint>.

<HTTPTargetConnection>
    <URL>http://example.com</URL>
    <LoadBalancer/>
    <SSLInfo/>
    <Properties/>
</HTTPTargetConnection>
Default T/A
Kehadiran Wajib diisi
Jenis T/A

Elemen <HTTPTargetConnection>/<URL>

URL ke layanan yang dipanggil:

<HTTPTargetConnection>
    <URL>http://example.com</URL>
</HTTPTargetConnection>

Anda dapat menyediakan bagian URL secara dinamis dengan variabel. Namun, bagian protokol dari URL, http:// di bawah, tidak dapat ditentukan oleh variabel. Pada contoh berikutnya, Anda menggunakan variabel untuk menentukan nilai parameter kueri:

<URL>http://example.com/forecastrss?w=${request.header.woeid}</URL>

Atau, tetapkan bagian dari jalur URL dengan variabel:

<URL>http://example.com/{request.resourcePath}?w=${request.header.woeid}</URL>

Jika Anda ingin menggunakan variabel untuk menentukan domain dan port URL, gunakan satu variabel untuk domain dan port saja, serta variabel kedua untuk bagian URL lainnya:

<URL>http://{request.dom_port}/{request.resourcePath}</URL>
Default T/A
Kehadiran Wajib diisi
Jenis String

Elemen <HTTPTargetConnection>/<SSLInfo>

Konfigurasi TLS/SSL ke layanan backend. Untuk mendapatkan bantuan terkait konfigurasi TLS/SSL, lihat Mengonfigurasi TLS dari Edge ke backend (Cloud dan Cloud Pribadi) dan "TLS/SSL TargetEndpoint Configuration" di Referensi konfigurasi proxy 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>
Default T/A
Kehadiran Opsional
Jenis T/A

Elemen <HTTPTargetConnection>/<Properties>

Properti transportasi HTTP ke layanan backend. Untuk informasi selengkapnya, lihat Referensi properti endpoint.

<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>
Default T/A
Kehadiran Opsional
Jenis T/A

Elemen <HTTPTargetConnection>/<LoadBalancer>

Panggil satu atau beberapa server target, lalu lakukan load balancing pada server tersebut. Lihat contoh Server target panggilan di bagian Contoh. Lihat juga Load balancing di seluruh server backend. Lihat juga postingan komunitas ini yang membahas cara memanggil server target dari kebijakan Panggilan Layanan dan menggunakan Aturan Rute.

<HTTPTargetConnection> <LoadBalancer> <Algorithm>RoundRobin</Algorithm> <Server name="httpbin"/> <Server name="yahoo"/> </LoadBalancer> <Path>/get</Path> </HTTPTargetConnection>
Default T/A
Kehadiran Opsional
Jenis T/A

Elemen <LocalTargetConnection>

Menentukan proxy lokal -- yaitu, proxy di organisasi dan lingkungan yang sama -- sebagai target info layanan.

Untuk menentukan target lebih lanjut, gunakan elemen <APIProxy> dan <ProxyEndpoint>, atau elemen <Path>.

<LocalTargetConnection>
   <APIProxy/>
   <ProxyEndpoint/>
   <Path/>
</LocalTargetConnection>
Default T/A
Kehadiran Wajib diisi
Jenis T/A

Elemen <LocalTargetConnection>/<APIProxy>

Nama proxy API yang merupakan target panggilan lokal. Proxy harus berada di organisasi dan lingkungan yang sama dengan proxy yang melakukan panggilan.

<LocalTargetConnection>
   <APIProxy>data-manager</APIProxy>
   <ProxyEndpoint>default</ProxyEndpoint>
</LocalTargetConnection>

Bersama dengan elemen <APIProxy>, sertakan elemen <ProxyEndpoint> untuk menentukan nama endpoint proxy yang harus ditargetkan untuk panggilan.

<LocalTargetConnection>
   <APIProxy/>
   <ProxyEndpoint/>
</LocalTargetConnection> 
Default T/A
Kehadiran Wajib diisi
Jenis String

Elemen <LocalTargetConnection>/<ProxyEndpoint>

Nama endpoint proxy yang harus menjadi target panggilan. Ini adalah endpoint proxy dalam proxy API yang ditentukan dengan elemen <APIProxy>.

<LocalTargetConnection>
   <APIProxy>data-manager</APIProxy>
   <ProxyEndpoint>default</ProxyEndpoint>
</LocalTargetConnection>
Default T/A
Kehadiran Opsional
Jenis T/A

Elemen <LocalTargetConnection>/<Path>

Jalur ke endpoint yang ditargetkan. Endpoint harus merujuk ke proxy di organisasi dan lingkungan yang sama dengan proxy yang melakukan panggilan.

Gunakan nama ini, bukan pasangan <APIProxy>/<ProxyEndpoint>, jika Anda tidak tahu -- atau tidak dapat mengandalkan -- nama proxy. Jalur mungkin menjadi target yang andal.

<LocalTargetConnection>
   <Path>/data-manager</Path>
</LocalTargetConnection>
Default T/A
Kehadiran Opsional
Jenis T/A

Skema

Variabel flow

Variabel Flow memungkinkan perilaku kebijakan dan Flow dinamis saat runtime, berdasarkan header HTTP, konten pesan, atau konteks Flow. Variabel Flow yang telah ditetapkan berikut ini tersedia setelah kebijakan Info Layanan dieksekusi. Untuk informasi selengkapnya tentang Variabel alur, lihat Referensi variabel.

Info Layanan memiliki permintaan dan responsnya sendiri, dan Anda dapat mengakses data tersebut melalui variabel. Karena pesan utama menggunakan awalan variabel request.* dan response.*, gunakan awalan myrequest.* dan calloutResponse.* (setelan default dalam konfigurasi Info Layanan) untuk mendapatkan data pesan khusus untuk Info Layanan. Contoh pertama dalam tabel berikut menunjukkan cara mendapatkan header HTTP di Info Layanan.

Variabel Deskripsi

Berikut adalah contoh cara mendapatkan header permintaan dan respons Info Layanan yang mirip dengan cara Anda mendapatkan header dari permintaan dan respons utama.

calloutResponse.header.HeaderName

myRequest.header.HeaderName

dengan calloutResponse adalah nama variabel untuk Respons dalam Pemanggilan Layanan, dan myRequest adalah nama variabel untuk Permintaan. Contoh:

calloutResponse.header.Content-Length

menampilkan header Content-Length pada respons Info Layanan.

Cakupan: Dari penerusan Info Layanan
Jenis: String
Izin: Baca/Tulis

Header pesan di permintaan atau respons Info Layanan. Misalnya, jika target proxy API adalah http://example.com, dan target Info Layanan adalah http://mocktarget.apigee.net, variabel ini adalah header untuk info untuk http://mocktarget.apigee.net.

servicecallout.requesturi

Cakupan: Dari permintaan Info Layanan ke depan
Jenis: String
Izin: Baca/Tulis

URI TargetEndpoint untuk kebijakan ServiceInfo. URI adalah URL TargetEndpoint tanpa spesifikasi protokol dan domain.

servicecallout.{policy-name}.target.url

Cakupan: Dari permintaan Info Layanan ke depan
Jenis: String
Izin: Baca/Tulis

URL target untuk Info Layanan.

calloutResponse.content

dengan calloutResponse adalah <Response>nama variabel dalam konfigurasi Info Layanan.

Cakupan: Dari depan respons Info Layanan
Jenis: String
Izin: Baca/Tulis

Isi respons dari Info Layanan.

servicecallout.{policy-name}.expectedcn

Cakupan: Dari permintaan Info Layanan ke depan
Jenis: String
Izin: Baca/Tulis

Nama Umum TargetEndpoint yang diharapkan sebagaimana dimaksud dalam kebijakan ServiceInfo. Hal ini hanya berguna jika TargetEndpoint merujuk ke endpoint TLS/SSL.

servicecallout.{policy-name}.failed

Cakupan: Dari respons Info Panggilan Layanan ke depan
Jenis: Boolean
Izin: Baca/Tulis

Boolean yang menunjukkan apakah kebijakan berhasil, salah, atau gagal, adalah benar (true).

Error

Bagian ini menjelaskan kode kesalahan dan pesan error yang dikembalikan, serta variabel kesalahan yang disetel oleh Edge saat kebijakan ini memicu error. Informasi ini penting untuk diketahui jika Anda mengembangkan aturan fault untuk menangani fault. Untuk mempelajari lebih lanjut, lihat Yang perlu Anda ketahui tentang error kebijakan dan Menangani kesalahan.

Error runtime

Error ini dapat terjadi saat kebijakan dijalankan.

Kode kesalahan Status HTTP Penyebab Perbaiki
steps.servicecallout.ExecutionFailed 500

Error ini dapat terjadi jika:

  • kebijakan ini diminta untuk menangani input yang salah format atau tidak valid.
  • layanan target backend menampilkan status error (secara default, 4xx atau 5xx).
steps.servicecallout.RequestVariableNotMessageType 500 Variabel Permintaan yang ditentukan dalam kebijakan bukan jenis Pesan. Misalnya, jika berupa string atau jenis non-pesan lainnya, Anda akan melihat error ini.
steps.servicecallout.RequestVariableNotRequestMessageType 500 Variabel Permintaan yang ditentukan dalam kebijakan bukan merupakan jenis Pesan Permintaan. Misalnya, jika jenis Respons, Anda akan melihat error ini.

Error deployment

Error ini dapat terjadi saat Anda men-deploy proxy yang berisi kebijakan ini.

Nama error Penyebab Perbaiki
URLMissing Elemen <URL> di dalam <HTTPTargetConnection> tidak ada atau kosong.
ConnectionInfoMissing Error ini terjadi jika kebijakan tidak memiliki elemen <HTTPTargetConnection> atau <LocalTargetConnection>.
InvalidTimeoutValue Error ini terjadi jika nilai <Timeout> negatif atau nol.

Variabel kesalahan

Variabel ini ditetapkan saat terjadi error runtime. Untuk informasi selengkapnya, lihat Yang perlu Anda ketahui tentang error kebijakan.

Variabel Lokasi Contoh
fault.name="fault_name" fault_name adalah nama fault, seperti yang tercantum pada tabel Error runtime di atas. Nama fault adalah bagian terakhir dari kode fault. fault.name = "RequestVariableNotMessageType"
servicecallout.policy_name.failed policy_name adalah nama kebijakan yang ditentukan oleh pengguna yang melemparkan kesalahan. servicecallout.SC-GetUserData.failed = true

Contoh respons error

{  
   "fault":{  
      "detail":{  
         "errorcode":"steps.servicecallout.RequestVariableNotMessageType"
      },
      "faultstring":"ServiceCallout[ServiceCalloutGetMockResponse]: 
            request variable data_str value is not of type Message"
   }
}

Contoh aturan kesalahan

<faultrule name="VariableOfNonMsgType"></faultrule><FaultRule name="RequestVariableNotMessageType">
    <Step>
        <Name>AM-RequestVariableNotMessageType</Name>
    </Step>
    <Condition>(fault.name = "RequestVariableNotMessageType")</Condition>
</FaultRule>

Topik terkait