Referensi konfigurasi proxy API

Halaman ini berlaku untuk Apigee dan Apigee Hybrid.

Lihat dokumentasi Apigee Edge.

Sebagai developer yang bekerja dengan Apigee, aktivitas pengembangan utama Anda melibatkan konfigurasi proxy API yang berfungsi sebagai proxy untuk API atau layanan backend. Dokumen ini adalah referensi semua elemen konfigurasi yang tersedia bagi Anda saat membuat proxy API.

Jika Anda sedang mempelajari cara membuat proxy API, sebaiknya mulai dengan topik Membangun proxy API sederhana.

Edit konfigurasi proxy API Anda menggunakan salah satu metode berikut:

• Gunakan UI Apigee atau API.
• Download paket konfigurasi proxy API, edit secara manual, dan upload konfigurasi baru ke Apigee, seperti yang dijelaskan dalam Mendownload dan mengupload paket konfigurasi proxy API.

Struktur direktori konfigurasi proxy API

Struktur direktori konfigurasi proxy API ditunjukkan di bawah ini:

Konfigurasi proxy API terdiri dari konten berikut:

Konfigurasi dasar	Setelan konfigurasi utama untuk proxy API.
ProxyEndpoint	Setelan untuk koneksi HTTP masuk (dari aplikasi yang meminta ke Apigee), alur permintaan dan respons, serta lampiran kebijakan.
TargetEndpoint	Setelan untuk koneksi HTTP keluar (dari Apigee ke layanan backend), alur permintaan dan respons, serta lampiran kebijakan.
Alur	Pipeline permintaan dan respons ProxyEndpoint dan TargetEndpoint yang dapat dilampiri kebijakan.
Kebijakan	File konfigurasi berformat XML yang sesuai dengan skema kebijakan Apigee.
Resource	Skrip, file JAR, dan file XSLT yang dirujuk oleh kebijakan untuk menjalankan logika kustom.

Konfigurasi dasar

/apiproxy/weatherapi.xml

Konfigurasi dasar untuk proxy API, yang menentukan nama proxy API. Nama harus unik dalam organisasi.

Contoh konfigurasi:

<APIProxy name="weatherapi">
</APIProxy>

Elemen konfigurasi dasar

Nama	Deskripsi	Default	Wajib?
APIProxy
name	Nama proxy API, yang harus unik dalam organisasi. Karakter yang diizinkan untuk digunakan dalam nama dibatasi sebagai berikut: A-Za-z0-9_-	T/A	Ya
revision	Nomor revisi konfigurasi proxy API. Anda tidak perlu menetapkan nomor revisi secara eksplisit, karena Apigee secara otomatis melacak revisi saat ini dari proxy API.	T/A	Tidak
ConfigurationVersion	Versi skema konfigurasi proxy API yang sesuai dengan proxy API ini. Satu-satunya nilai yang didukung saat ini adalah majorVersion 4 dan minorVersion 0. Setelan ini dapat digunakan di masa mendatang untuk memungkinkan evolusi format proxy API.	4.0	Tidak
Description	Deskripsi tekstual proxy API. Jika disediakan, deskripsi akan ditampilkan di UI Apigee.	T/A	Tidak
DisplayName	Nama yang mudah digunakan yang mungkin berbeda dengan atribut name dari konfigurasi proxy API.	T/A	Tidak
Policies	Daftar kebijakan di direktori /policies proxy API ini. Anda biasanya hanya melihat elemen ini saat proxy API dibuat menggunakan UI Apigee. Ini hanyalah setelan manifest, yang dirancang untuk memberikan visibilitas ke konten proxy API.	T/A	Tidak
ProxyEndpoints	Daftar endpoint proxy di direktori /proxies proxy API ini. Anda biasanya hanya akan melihat elemen ini saat proxy API dibuat menggunakan UI Apigee. Ini hanyalah setelan manifest, yang dirancang untuk memberikan visibilitas ke isi proxy API.	T/A	Tidak
Resources	Daftar resource (JavaScript, Python, Java, XSLT) di direktori /resources proxy API ini. Biasanya Anda hanya akan melihat elemen ini saat proxy API dibuat menggunakan UI Apigee. Ini hanyalah setelan manifest, yang dirancang untuk memberikan visibilitas ke dalam konten proxy API.	T/A	Tidak
Spec	Mengidentifikasi Spesifikasi OpenAPI yang terkait dengan proxy API. Nilai ditetapkan ke URL atau ke jalur di toko spesifikasi.	T/A	Tidak
TargetServers	Daftar server target yang dirujuk di endpoint target proxy API ini. Anda biasanya hanya melihat elemen ini saat proxy API dibuat menggunakan Apigee. Ini hanyalah setelan manifest, yang dirancang untuk memberikan visibilitas ke konten proxy API.	T/A	Tidak
TargetEndpoints	Daftar endpoint target di direktori /targets proxy API ini. Anda biasanya hanya akan melihat elemen ini saat proxy API dibuat menggunakan UI Apigee. Ini hanyalah setelan manifest, yang dirancang untuk memberikan visibilitas ke isi proxy API.	T/A	Tidak

ProxyEndpoint

Gambar berikut menunjukkan alur permintaan/respons:

/apiproxy/proxies/default.xml

Konfigurasi ProxyEndpoint menentukan antarmuka inbound (yang menghadap klien) untuk proxy API. Saat mengonfigurasi endpoint proxy, Anda menyiapkan konfigurasi jaringan yang menentukan cara aplikasi klien (aplikasi) harus memanggil API yang di-proxy.

Konfigurasi ProxyEndpoint contoh berikut akan disimpan di /apiproxy/proxies:

<ProxyEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <HTTPProxyConnection>
    <BasePath>/weather</BasePath>
    <Properties/>
  </HTTPProxyConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <RouteRule name="default">
    <TargetEndpoint>default</TargetEndpoint>
  </RouteRule>
</ProxyEndpoint>

Elemen konfigurasi yang diperlukan di endpoint proxy dasar adalah:

Elemen konfigurasi ProxyEndpoint

Nama	Deskripsi	Default	Wajib?
ProxyEndpoint
name	Nama endpoint proxy. Harus unik dalam konfigurasi proxy API, saat (dalam kasus yang jarang terjadi) beberapa endpoint proxy ditentukan. Karakter yang diizinkan untuk digunakan dalam nama dibatasi sebagai berikut: A-Za-z0-9._\-$ %.	T/A	Ya
PreFlow	Menentukan kebijakan dalam alur PreFlow permintaan atau respons.	T/A	Ya
Flows	Menentukan kebijakan dalam alur bersyarat permintaan atau respons.	T/A	Ya
PostFlow	Menentukan kebijakan dalam alur PostFlow permintaan atau respons.	T/A	Ya
HTTPProxyConnection	Menentukan alamat jaringan dan jalur URI yang terkait dengan proxy API.
BasePath	String wajib yang mengidentifikasi jalur URI yang digunakan oleh Apigee secara unik untuk merutekan pesan masuk ke proxy API yang tepat. BasePath adalah fragmen URI (misalnya /weather) yang ditambahkan ke URL dasar proxy API (misalnya, http://apifactory-test.apigee.net). BasePath harus unik dalam suatu lingkungan. Keunikan divalidasi saat proxy API dibuat atau diimpor. Menggunakan karakter pengganti di jalur dasar Anda dapat menggunakan satu atau beberapa karakter pengganti "*" di jalur dasar proxy API. Misalnya, jalur dasar /team/*/members memungkinkan klien memanggil https://[host]/team/blue/members dan https://[host]/team/green/members tanpa Anda perlu membuat proxy API baru untuk mendukung tim baru. Perhatikan bahwa /**/ tidak didukung. Penting: Apigee TIDAK mendukung penggunaan karakter pengganti "*" sebagai elemen pertama dari jalur dasar. Misalnya, /*/search TIDAK didukung. Memulai jalur dasar dengan "*" dapat menyebabkan error yang tidak terduga karena cara Apigee mengidentifikasi jalur yang valid.	/	Ya
Properties	Kumpulan setelan konfigurasi HTTP opsional dapat ditentukan sebagai properti <ProxyEndpoint>. Properti yang tersedia meliputi hal berikut: request.queryparams.ignore.content.type.charset Gunakan properti request.queryparams.ignore.content.type.charset untuk memberi tahu proxy agar mengabaikan parameter charset dari header Content-Type saat memproses URL permintaan. Contoh: <Properties> <Property name="request.queryparams.ignore.content.type.charset">true</Property> </Properties> Tabel berikut menunjukkan contoh output bergantung pada setelan properti charset dan keberadaan parameter charset header Content-Type. Setelan properti Nilai header Contoh output charset=false charset param tidak ditetapkan [e-mail] charset=false charset=utf-8 john.doe [e-mail] charset=true dan tidak ada parameter charset di header. charset param tidak ditetapkan [e-mail] charset=true charset=utf-8 param set [e-mail] request.payload.parse.limit Gunakan properti request.payload.parse.limit untuk menetapkan ukuran payload maksimum yang dapat diproses dalam alur permintaan, dalam megabyte (M). Contoh: <Properties> <Property name="request.payload.parse.limit">30M</Property> </Properties> Batas yang dapat dikonfigurasi minimum adalah 10M dan batas yang dapat dikonfigurasi maksimum adalah 30M. Jika properti tidak ditetapkan, batas defaultnya adalah 10 Juta. Untuk mengetahui informasi selengkapnya, lihat Ukuran payload pesan.	T/A	Tidak
FaultRules	Menentukan cara endpoint proxy bereaksi terhadap error. Aturan kesalahan menentukan dua item: Kondisi yang menentukan kesalahan yang akan ditangani berdasarkan kategori, subkategori, atau nama kesalahan yang telah ditentukan sebelumnya Satu atau beberapa kebijakan yang menentukan perilaku aturan kesalahan untuk Kondisi yang sesuai Lihat Menangani kesalahan.	T/A	Tidak
DefaultFaultRule	Menangani semua error (sistem, transportasi, pesan, atau kebijakan) yang tidak ditangani secara eksplisit oleh aturan kesalahan lain. Lihat Menangani kesalahan.	T/A	Tidak
RouteRule	Menentukan tujuan pesan permintaan masuk setelah diproses oleh pipeline permintaan ProxyEndpoint. Biasanya, RouteRule mengarah ke endpoint target bernama, IntegrationEndpoint, atau URL.
Name	Atribut wajib diisi, yang memberikan nama untuk RouteRule. Karakter yang diizinkan untuk digunakan dalam nama dibatasi sebagai berikut: A-Za-z0-9._\-$ %. Misalnya, Cat2 %_ adalah nama resmi.	T/A	Ya
Condition	Pernyataan bersyarat opsional yang digunakan untuk perutean dinamis pada waktu proses. RouteRules bersyarat berguna, misalnya, untuk mengaktifkan perutean berdasarkan konten guna mendukung pembuatan versi backend.	T/A	Tidak
TargetEndpoint	String opsional yang mengidentifikasi konfigurasi TargetEndpoint bernama. Endpoint target bernama adalah endpoint target yang ditentukan dalam proxy API yang sama di direktori/targets). Dengan memberi nama endpoint target, Anda menunjukkan ke mana pesan permintaan harus diteruskan setelah diproses oleh pipeline permintaan ProxyEndpoint. Perhatikan bahwa ini adalah setelan opsional. Endpoint proxy dapat memanggil URL secara langsung. Misalnya, resource JavaScript atau Java, yang berfungsi dalam peran klien HTTP, dapat melakukan tugas dasar endpoint target, yaitu meneruskan permintaan ke layanan backend.	T/A	Tidak
URL	String opsional yang menentukan alamat jaringan keluar yang dipanggil oleh endpoint proxy, dengan melewati konfigurasi TargetEndpoint yang mungkin disimpan di /targets	T/A	Tidak

Cara mengonfigurasi RouteRules

Endpoint target bernama merujuk ke file konfigurasi di bagian /apiproxy/targets yang ke mana RouteRule meneruskan permintaan setelah diproses oleh endpoint proxy.

Misalnya, RouteRule berikut merujuk pada konfigurasi /apiproxy/targets/myTarget.xml:

<RouteRule name="default">
  <TargetEndpoint>myTarget</TargetEndpoint>
</RouteRule>

Pemanggilan URL langsung

Endpoint proxy juga dapat langsung memanggil layanan backend. Pemanggilan URL langsung melewati konfigurasi TargetEndpoint bernama di /apiproxy/targets). Oleh karena itu, TargetEndpoint adalah konfigurasi proxy API opsional, meskipun, dalam praktiknya, pemanggilan langsung dari endpoint proxy tidak direkomendasikan.

Misalnya, RouteRule berikut membuat panggilan HTTP ke http://api.mycompany.com/v2.

<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL> 
</RouteRule>

Rute bersyarat

RouteRules dapat dirangkai untuk mendukung pemilihan rute dinamis saat runtime. Permintaan masuk dapat dirutekan ke konfigurasi TargetEndpoint bernama, langsung ke URL, atau ke kombinasi keduanya, berdasarkan header HTTP, konten pesan, parameter kueri, atau informasi kontekstual seperti waktu dalam sehari, lokalitas, dll.

Conditional RouteRules berfungsi seperti pernyataan bersyarat lainnya di Apigee. Lihat Referensi kondisi dan Referensi variabel alur.

Misalnya, kombinasi RouteRule berikut pertama-tama mengevaluasi permintaan masuk untuk memverifikasi nilai header HTTP. Jika header HTTP routeTo memiliki nilai TargetEndpoint1, permintaan akan diteruskan ke endpoint target bernama TargetEndpoint1. Jika tidak, permintaan masuk akan diteruskan ke http://api.mycompany.com/v2.

<RouteRule name="MyRoute">
  <Condition>request.header.routeTo = "TargetEndpoint1"</Condition>
  <TargetEndpoint>TargetEndpoint1</TargetEndpoint>
</RouteRule>
<RouteRule name="default">
  <URL>http://api.mycompany.com/v2</URL>
</RouteRule>

Catatan: Lebih banyak pemilihan rute dinamis

Artikel komunitas Apigee tentang menentukan endpoint proxy menunjukkan pemilihan rute dinamis ke berbagai wilayah dunia berdasarkan variabel yang diekstrak dari URI permintaan.

Rute null

RouteRule null dapat ditentukan untuk mendukung skenario saat pesan permintaan tidak perlu diteruskan ke endpoint target. Hal ini berguna saat endpoint proxy melakukan semua pemrosesan yang diperlukan, misalnya dengan menggunakan JavaScript untuk memanggil layanan eksternal atau mengambil data dari pencarian ke penyimpanan nilai/kunci Apigee.

Misalnya, kode berikut menentukan Rute null:

<RouteRule name="GoNowhere"/>

Rute null bersyarat dapat berguna. Dalam contoh berikut, Rute null dikonfigurasi untuk dieksekusi saat header HTTP request.header.X-DoNothing memiliki nilai selain null.

<RouteRule name="DoNothingOnDemand">
  <Condition>request.header.X-DoNothing != null</Condition>
</RouteRule>

Ingat, RouteRules dapat dirangkai, sehingga Rute null bersyarat biasanya menjadi salah satu komponen dari serangkaian RouteRules yang dirancang untuk mendukung pemilihan rute bersyarat.

Penggunaan praktis Rute null bersyarat adalah untuk mendukung caching. Dengan menggunakan nilai variabel yang ditetapkan oleh kebijakan Cache, Anda dapat mengonfigurasi proxy API untuk menjalankan Rute null saat entri ditayangkan dari cache.

<RouteRule name="DoNothingUnlessTheCacheIsStale">
  <Condition>lookupcache.LookupCache-1.cachehit is true</Condition>
</RouteRule>

TargetEndpoint

Endpoint target adalah padanan keluar dari endpoint proxy. Endpoint target berfungsi sebagai klien ke layanan atau API backend—endpoint ini mengirim permintaan dan menerima respons.

Proxy API tidak harus memiliki endpoint target. Endpoint proxy dapat dikonfigurasi untuk memanggil URL secara langsung. Proxy API tanpa endpoint target biasanya berisi endpoint proxy yang memanggil layanan backend secara langsung, atau yang dikonfigurasi untuk memanggil layanan menggunakan Java atau JavaScript.

Konfigurasi TargetEndpoint

/targets/default.xml

Endpoint target menentukan koneksi keluar dari Apigee ke layanan atau resource lain.

Berikut adalah contoh konfigurasi TargetEndpoint:

<TargetEndpoint name="default">
  <PreFlow/>
  <Flows/>
  <PostFlow/>
  <EventFlow/>
  <HTTPTargetConnection>
    <URL>http://mocktarget.apigee.net</URL>
    <SSLInfo/>
    <Authentication/>
  </HTTPTargetConnection>
  <FaultRules/>
  <DefaultFaultRule/>
  <ScriptTarget/>
  <LocalTargetConnection/>
</TargetEndpoint>

Elemen konfigurasi TargetEndpoint

Endpoint target dapat memanggil target dengan salah satu cara berikut:

• HTTPTargetConnection untuk panggilan HTTP atau HTTPS
• LocalTargetConnection untuk penggabungan proxy-ke-proxy lokal

Konfigurasi hanya salah satu opsi ini di endpoint target.

Nama	Deskripsi	Default	Wajib?
TargetEndpoint
name	Nama endpoint target, yang harus unik dalam konfigurasi proxy API. Nama endpoint target digunakan dalam RouteRule ProxyEndpoint untuk mengarahkan permintaan untuk pemrosesan keluar. Karakter yang diizinkan untuk digunakan dalam nama dibatasi sebagai berikut: A-Za-z0-9._\-$ %.	T/A	Ya
PreFlow	Menentukan kebijakan dalam alur PreFlow permintaan atau respons.	T/A	Ya
Flows	Menentukan kebijakan dalam alur bersyarat permintaan atau respons.	T/A	Ya
PostFlow	Menentukan kebijakan dalam alur PostFlow permintaan atau respons.	T/A	Ya
EventFlow	Menentukan kebijakan dalam alur EventFlow respons. EventFlow digunakan untuk streaming peristiwa yang dikirim server. Untuk mengetahui informasi selengkapnya, lihat Streaming peristiwa yang dikirim server.	T/A	Tidak
HTTPTargetConnection	Dengan elemen turunannya, menentukan resource backend yang dijangkau melalui HTTP. Jika Anda menggunakan HTTPTargetConnection, jangan mengonfigurasi jenis koneksi target lainnya (ScriptTarget atau LocalTargetConnection). Catatan: Elemen <LocalTargetConnection> mendukung fitur penggantian string dinamis yang disebut pembuatan template pesan. Anda dapat menggunakan elemen turunan <Authentication> untuk melakukan panggilan yang diautentikasi ke layanan Google atau layanan kustom yang berjalan di produk Google Cloud tertentu, seperti Cloud Functions dan Cloud Run. Penggunaan elemen <Authentication> memerlukan langkah-langkah penyiapan dan deployment yang dijelaskan dalam Menggunakan autentikasi Google. Dengan penyiapan yang tepat, kebijakan akan membuat token autentikasi untuk Anda dan menambahkannya ke permintaan layanan. Lihat juga penggunaan elemen <Authentication>.
URL	Menentukan alamat jaringan layanan backend yang menjadi tujuan endpoint meneruskan pesan permintaan.	T/A	Tidak
LoadBalancer	Menentukan satu atau beberapa konfigurasi TargetServer bernama. Konfigurasi TargetServer bernama dapat digunakan untuk load balancing yang menentukan 2 koneksi konfigurasi endpoint atau lebih. Anda juga dapat menggunakan server target untuk memisahkan konfigurasi proxy API dari URL endpoint layanan backend konkret.	T/A	Tidak
Properties	Kumpulan setelan konfigurasi HTTP opsional dapat ditentukan sebagai properti <TargetEndpoint>. Gunakan properti response.payload.parse.limit untuk menetapkan ukuran payload maksimum yang dapat diproses dalam alur respons, dalam megabyte (M). Contoh: <Properties> <Property name="response.payload.parse.limit">15M</Property> </Properties> Batas yang dapat dikonfigurasi minimum adalah 10M dan batas yang dapat dikonfigurasi maksimum adalah 30M. Jika properti tidak ditetapkan, batas defaultnya adalah 10 Juta. Untuk mengetahui informasi selengkapnya, lihat Ukuran payload pesan.	T/A	Tidak
SSLInfo	Secara opsional, tentukan setelan TLS/SSL di endpoint target untuk mengontrol koneksi TLS/SSL antara proxy API dan layanan target. Lihat Konfigurasi TargetEndpoint TLS/SSL. Catatan: Elemen <SSLInfo> mendukung fitur penggantian string dinamis yang disebut pembuatan template pesan.	T/A	Tidak
LocalTargetConnection	Dengan elemen turunannya, menentukan resource yang akan dijangkau secara lokal, melewati karakteristik jaringan seperti load balancing dan pemroses pesan. Untuk menentukan resource target, sertakan elemen turunan APIProxy (dengan elemen ProxyEndpoint) atau elemen turunan Path. Untuk mengetahui informasi selengkapnya, lihat Menggabungkan proxy API. Jika Anda menggunakan LocalTargetConnection, jangan mengonfigurasi jenis koneksi target lainnya (HTTPTargetConnection atau ScriptTarget).
APIProxy	Menentukan nama proxy API yang akan digunakan sebagai target untuk permintaan. Proxy target harus berada di organisasi dan lingkungan yang sama dengan proxy yang mengirim permintaan. Ini adalah alternatif untuk menggunakan elemen Jalur.	T/A	Tidak
ProxyEndpoint	Digunakan dengan APIProxy untuk menentukan nama endpoint proxy target proxy.	T/A	Tidak
Path	Menentukan jalur endpoint proxy API yang akan digunakan sebagai target untuk permintaan. Proxy target harus berada di organisasi dan lingkungan yang sama dengan proxy yang mengirim permintaan. Ini adalah alternatif untuk menggunakan APIProxy.	T/A	Tidak
FaultRules	Menentukan cara endpoint target bereaksi terhadap error. Aturan kesalahan menentukan dua item: Kondisi yang menentukan kesalahan yang akan ditangani berdasarkan kategori, subkategori, atau nama kesalahan yang telah ditentukan sebelumnya Satu atau beberapa kebijakan yang menentukan perilaku aturan kesalahan untuk Kondisi yang sesuai Lihat Menangani kesalahan.	T/A	Tidak
DefaultFaultRule	Menangani error apa pun (sistem, transportasi, pesan, atau kebijakan) yang tidak ditangani secara eksplisit oleh FaultRule lain. Lihat Menangani kesalahan.	T/A	Tidak

Penggunaan elemen <Authentication>

Penggunaan elemen <Authentication> dalam <TargetEndpoint> identik dengan penggunaan elemen <Authentication> dalam kebijakan ServiceCallout. Di <TargetEndpoint> dan ServiceCallout, <Authentication> adalah subelemen dari <HttpTargetConnection>. Untuk mengetahui detailnya, lihat Elemen autentikasi dalam referensi kebijakan ServiceCallout.

Referensi error elemen <Authentication>

Jika menggunakan elemen <Authentication>, Anda dapat menemukan kemungkinan pesan error dan tips pemecahan masalah untuk error deployment dan runtime di bagian Error pada dokumentasi kebijakan ServiceCallout.

Contoh elemen <Authentication>

Contoh berikut menunjukkan cara memanggil layanan yang di-deploy di Cloud Run sebagai target menggunakan elemen Authentication untuk membuat token OpenID Connect yang diperlukan untuk mengautentikasi panggilan:

<TargetEndpoint name="TargetEndpoint-1">
  <HTTPTargetConnection>
      <Properties/>
      <URL>https://cloudrun-hostname.a.run.app/test</URL>
      <Authentication>
          <GoogleIDToken>
             <Audience>https://cloudrun-hostname.a.run.app/test</Audience>
          </GoogleIDToken>
     </Authentication>
  </HTTPTargetConnection>
</TargetEndpoint>

Contoh berikut menunjukkan cara memanggil TargetService yang mengarah ke Cloud Run menggunakan elemen Authentication untuk membuat token OpenID Connect yang diperlukan untuk mengautentikasi panggilan. Elemen HeaderName menambahkan token pembawa yang dihasilkan ke header bernama X-Serverless-Authorization yang dikirim ke sistem target. Header Authorization, jika ada, tidak diubah dan juga dikirim dalam permintaan.

<TargetEndpoint name="TargetEndpoint-1">
   <HTTPTargetConnection>
     <Authentication>
        <HeaderName>X-Serverless-Authorization</HeaderName>
        <GoogleIDToken>
            <Audience ref="flow.variable.audience">https://cloudrun-hostname.a.run.app</Audience>
        </GoogleIDToken>
     </Authentication>
      <LoadBalancer>
         <Server name="cloud-run-target" />
      </LoadBalancer>
   </HTTPTargetConnection>
</TargetEndpoint>

Contoh berikut menunjukkan cara memanggil TargetService yang mengarah ke layanan Secret Manager Google. Dalam contoh ini, elemen GoogleAccessToken dikonfigurasi untuk membuat Token Autentikasi Google untuk mengautentikasi permintaan target:

<HTTPTargetConnection>
   <Authentication>
      <GoogleAccessToken>
        <Scopes>
          <Scope>https://www.googleapis.com/auth/cloud-platform</Scope>
        </Scopes>
      </GoogleAccessToken>
    </Authentication>
    <URL>
      https://secretmanager.googleapis.com/v1/projects/project-id/secrets/secret-id
    </URL>
</HTTPTargetConnection>

Contoh berikut menunjukkan cara menyetel audiens GoogleIDToken secara otomatis. Jika useTargetUrl adalah true dan variabel yang dirujuk tidak di-resolve ke variabel yang valid, URL target (tidak termasuk parameter kueri) akan digunakan sebagai audiens. Misalkan jalur permintaan adalah /foobar dan URL server target adalah https://xyz.com, audiens GoogleIDToken akan otomatis ditetapkan ke https://xyz.com/foobar.

Pengguna Apigee Hybrid: Jika Anda menggunakan Apigee Hybrid, perhatikan bahwa atribut useTargetUrl tersedia di Apigee Hybrid versi 1.8 dan yang lebih baru.

<TargetEndpoint name="TargetEndpoint-1">
  <HTTPTargetConnection>
    <Authentication>
      <GoogleIDToken>
        <Audience ref='myvariable' useTargetUrl="true"/>
      </GoogleIDToken>
    </Authentication>
    <LoadBalancer>
      <Server name="TS" />
    </LoadBalancer>
  </HTTPTargetConnection>
</TargetEndpoint>

Konfigurasi TargetEndpoint TLS/SSL

Endpoint target sering kali perlu mengelola koneksi HTTPS dengan infrastruktur backend heterogen. Oleh karena itu, sejumlah setelan konfigurasi TLS/SSL didukung.

Catatan: TLS (Transport Layer Security) adalah versi terbaru dari spesifikasi SSL (Secure Sockets Layer) yang kini tidak digunakan lagi. Karena Apigee awalnya mendukung SSL, Anda mungkin melihat beberapa instance di UI Apigee dan di elemen konfigurasi Apigee yang menggunakan istilah SSL. Namun, Apigee hanya menggunakan TLS.

TLS/SSL Elemen konfigurasi TargetEndpoint

Nama	Deskripsi	Default	Wajib?
SSLInfo	Blok <SSLInfo> dapat digunakan untuk TLS/SSL satu arah dan dua arah.
Enabled	Jika disetel ke true, menentukan bahwa koneksi target harus menggunakan protokol SSL sesuai dengan parameter lain yang ditentukan dalam blok <SSLInfo> ini. Jika disetel ke false, menentukan bahwa koneksi target tidak boleh menggunakan SSL. Namun, jika blok <HTTPTargetConnection> yang melampirkan berisi elemen <URL> yang dievaluasi ke string yang dimulai dengan https://, maka protokol SSL akan digunakan meskipun <Enabled> bernilai salah. Dalam hal ini, seluruh blok <SSLInfo> diabaikan. Sebaliknya, jika ada elemen <URL> yang dimulai dengan http://, maka protokol SSL tidak akan digunakan meskipun <Enabled> benar.	false	Tidak
Enforce	Menerapkan SSL ketat antara Apigee dan backend target. Jika disetel ke true, koneksi akan gagal untuk target dengan sertifikat tidak valid, sertifikat yang masa berlakunya habis, sertifikat yang ditandatangani sendiri, sertifikat dengan ketidakcocokan nama host, dan sertifikat dengan root yang tidak tepercaya. Kode kegagalan 4xx atau 5xx akan ditampilkan. Jika tidak disetel, atau disetel ke false, hasil koneksi ke backend target dengan sertifikat bermasalah bergantung pada setelan <IgnoreValidationErrors> (lihat di bawah). Respons berhasil (2xx) dapat terjadi dalam kondisi tertentu, jika <IgnoreValidationErrors> disetel ke true. Anda dapat mengganti kolom Enforce di tingkat lingkungan dengan flag fitur SSLInfo.Enforce. Lihat Menentukan penerapan SSL tingkat lingkungan.	false	Tidak
TrustStore	Keystore yang berisi sertifikat server root tepercaya. Apigee akan memperlakukan peer jarak jauh sebagai tepercaya jika rantai sertifikat yang dikirimkan berakhir dengan sertifikat yang ada di keystore ini.	T/A	Tidak
ClientAuthEnabled	Jika disetel ke true, mengaktifkan TLS dua arah (juga dikenal sebagai TLS bersama atau mTLS) antara Apigee dan peer jarak jauh - baik klien API, atau backend target. Untuk mengaktifkan TLS dua arah, Anda biasanya harus menyiapkan truststore dan keystore di Apigee.	false	Tidak
KeyStore	Keystore yang berisi kunci pribadi yang digunakan untuk autentikasi klien keluar	T/A	Ya (jika ClientAuthEnabled benar)
KeyAlias	Alias kunci dari kunci pribadi yang digunakan untuk autentikasi klien keluar	T/A	Ya (jika ClientAuthEnabled benar)
IgnoreValidationErrors	Menunjukkan apakah error validasi diabaikan. Jika sistem backend menggunakan SNI dan menampilkan sertifikat dengan Nama Pembeda (DN) subjek yang tidak cocok dengan nama host, tidak ada cara untuk mengabaikan error dan koneksi akan gagal. Catatan: Jika <Enforce> ditetapkan ke true, nilai <IgnoreValidationErrors> akan diabaikan.	false	Tidak
Ciphers	Cipher yang didukung untuk TLS/SSL keluar. Jika tidak ada sandi yang ditentukan, semua sandi yang tersedia untuk JVM akan diizinkan. Untuk membatasi sandi, tambahkan elemen berikut yang mencantumkan sandi yang didukung: <Ciphers> <Cipher>TLS_RSA_WITH_3DES_EDE_CBC_SHA</Cipher> <Cipher>TLS_RSA_WITH_DES_CBC_SHA</Cipher> </Ciphers>	T/A	Tidak
Protocols	Protokol yang didukung untuk TLS/SSL keluar. Jika tidak ada protokol yang ditentukan, semua protokol yang tersedia untuk JVM akan diizinkan. Untuk membatasi protokol, tentukan protokol secara eksplisit. Misalnya, untuk hanya mengizinkan TLS v1.2 atau TLS v1.3: <Protocols> <Protocol>TLSv1.2</Protocol> <Protocol>TLSv1.3</Protocol> </Protocols> Catatan: TLS 1.0 tidak didukung untuk Apigee Hybrid untuk koneksi ke hilir.	T/A	Tidak
CommonName	Apigee memeriksa nilai di sini terhadap CN (Nama Umum) atau SAN (Nama Alternatif Subjek) pada sertifikat peer jarak jauh.	T/A	Tidak

Menentukan penerapan SSL tingkat lingkungan

Jika SSLInfo.Enforce ditetapkan ke true atau false, nilai yang ditentukan akan menggantikan opsi penerapan terperinci yang ditentukan dalam blok <SSLInfo> di konfigurasi TargetEndpoint atau TargetServer.

Jika SSLInfo.Enforce tidak ditetapkan, penerapan SSL ditentukan oleh nilai apa pun yang ditentukan menggunakan elemen <Enforce> dalam setiap blok <SSLInfo>. Untuk mengetahui informasi selengkapnya, lihat Konfigurasi TargetEndpoint TLS/SSL.

Dalam contoh berikut, SSLInfo.Enforce disetel ke true. Dalam output yang dihasilkan, Anda dapat melihat bahwa SSL diterapkan di lingkungan yang ditentukan.

Catatan Panggilan API dalam contoh tidak mempertahankan setelan flag fitur yang ditentukan sebelumnya. Dalam panggilan ini, Anda harus menentukan ulang setelan yang ingin dipertahankan.

VALUE=true
curl -Ss -v -X PUT \
    "https://apigee.googleapis.com/v1/organizations/MYORG/environments/MYENV" \
    -H "Content-Type: application/json" \
    -H "Authorization: Bearer TOKEN" \
    -d '{
        "name": "MYENV",
        "properties": {
            "property": [{
                "name": "features.SSLInfo.Enforce",
                "value": "'"$VALUE"'"
            }]
        }
    }'
  

Output:

{
  ...
  "properties": {
    "property": [
      {
        "name": "features.SSLInfo.Enforce",
        "value": "true"
      }
    ]
  },
  ...
}

Contoh endpoint target dengan autentikasi klien keluar yang diaktifkan

<TargetEndpoint name="default">
  <HttpTargetConnection>
        <URL>https://myservice.com</URL>
    <SSLInfo>
      <Enabled>true</Enabled>
      <Enforce>true</Enforce>
      <ClientAuthEnabled>true</ClientAuthEnabled>
      <KeyStore>myKeystore</KeyStore>
      <KeyAlias>myKey</KeyAlias>
      <TrustStore>myTruststore</TrustStore>
    </SSLInfo>
  </HttpTargetConnection>
</TargetEndpoint>

Untuk mengetahui petunjuk mendetail, lihat Opsi untuk mengonfigurasi TLS.

Menggunakan variabel alur untuk menetapkan nilai TLS/SSL secara dinamis

Anda juga dapat menetapkan detail TLS/SSL secara dinamis untuk mendukung persyaratan runtime yang fleksibel. Misalnya, jika proxy Anda terhubung ke dua target yang berpotensi berbeda (target pengujian dan target produksi), Anda dapat membuat proxy API mendeteksi secara terprogram lingkungan yang dipanggil dan menetapkan referensi secara dinamis ke keystore dan truststore yang sesuai. Artikel Komunitas Apigee Dynamic SSLInfo for TargetEndpoint using variable reference menjelaskan skenario ini secara lebih mendetail dan memberikan contoh proxy API yang dapat di-deploy.

Dalam contoh berikut tentang cara tag <SSLInfo> ditetapkan dalam konfigurasi TargetEndpoint, nilai dapat diberikan saat runtime, misalnya, oleh Java Callout, kebijakan JavaScript, atau kebijakan AssignMessage. Gunakan variabel pesan mana pun yang berisi nilai yang ingin Anda tetapkan.

Variabel hanya diizinkan dalam elemen berikut.

Catatan: Elemen ini mendukung fitur penggantian string dinamis yang disebut template pesan.

<SSLInfo>
    <Enabled>{myvars.ssl.enabled}</Enabled>
    <ClientAuthEnabled>{myvars.ssl.client.auth.enabled}</ClientAuthEnabled>
    <KeyStore>{myvars.ssl.keystore}</KeyStore>
    <KeyAlias>{myvars.ssl.keyAlias}</KeyAlias>
    <TrustStore>{myvars.ssl.trustStore}</TrustStore>
</SSLInfo>

Catatan: Penggantian variabel nilai TLS/SSL hanya dapat digunakan untuk endpoint target. Setiap upaya untuk menggunakan variabel dalam konteks lain, seperti logging pesan, akan menyebabkan kegagalan validasi.

Menggunakan referensi untuk menyetel nilai TLS/SSL secara dinamis

Saat mengonfigurasi endpoint target yang menggunakan HTTPS, Anda harus mempertimbangkan kasus saat masa berlaku sertifikat TLS/SSL berakhir, atau perubahan pada konfigurasi sistem mengharuskan Anda memperbarui sertifikat.

Untuk mengetahui informasi selengkapnya, lihat Menangani sertifikat yang telah habis masa berlakunya.

Namun, Anda dapat secara opsional mengonfigurasi endpoint target untuk menggunakan referensi ke keystore atau truststore. Keuntungan menggunakan referensi adalah Anda dapat mengupdate referensi untuk mengarah ke keystore atau truststore yang berbeda guna mengupdate sertifikat TLS/SSL tanpa harus memulai ulang Pemroses Pesan.

Catatan: Anda hanya dapat menggunakan referensi ke keystore dan truststore; Anda tidak dapat menggunakan referensi ke alias. Saat Anda mengubah referensi ke keystore, pastikan nama alias sertifikat sama dengan yang ada di keystore lama.

Misalnya, di bawah ini adalah endpoint target yang menggunakan referensi ke keystore:

<SSLInfo>
  <Enabled>true</Enabled>
  <ClientAuthEnabled>false</ClientAuthEnabled>
  <KeyStore>ref://keystoreref</KeyStore>
  <KeyAlias>myKeyAlias</KeyAlias>
</SSLInfo>

Gunakan panggilan API POST berikut untuk membuat referensi bernama keystoreref:

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/references" \
  -X POST \
  -H "Authorization: Bearer $TOKEN" \
  -d '<ResourceReference name="keystoreref">
    <Refers>myTestKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
</ResourceReference>'

Dengan $TOKEN ditetapkan ke token akses OAuth 2.0 Anda, seperti yang dijelaskan dalam Mendapatkan token akses OAuth 2.0. Untuk mengetahui informasi tentang opsi curl yang digunakan dalam contoh ini, lihat Menggunakan curl. Untuk mengetahui deskripsi variabel lingkungan yang dapat Anda gunakan, lihat Menetapkan variabel lingkungan untuk permintaan API Apigee.

Referensi menentukan nama keystore dan jenisnya.

Gunakan panggilan GET API berikut untuk melihat referensi:

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/references/keystoreref" \
  -H "Authorization: Bearer $TOKEN"

Dengan $TOKEN ditetapkan ke token akses OAuth 2.0 Anda, seperti yang dijelaskan dalam Mendapatkan token akses OAuth 2.0. Untuk mengetahui informasi tentang opsi curl yang digunakan dalam contoh ini, lihat Menggunakan curl. Untuk mengetahui deskripsi variabel lingkungan yang dapat Anda gunakan, lihat Menetapkan variabel lingkungan untuk permintaan API Apigee.

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/references/keystoreref" \
  -H "Authorization: Bearer $TOKEN"

Dengan $TOKEN ditetapkan ke token akses OAuth 2.0 Anda, seperti yang dijelaskan dalam Mendapatkan token akses OAuth 2.0. Untuk mengetahui informasi tentang opsi curl yang digunakan dalam contoh ini, lihat Menggunakan curl. Untuk mengetahui deskripsi variabel lingkungan yang dapat Anda gunakan, lihat Menetapkan variabel lingkungan untuk permintaan API Apigee.

Untuk mengubah referensi agar mengarah ke keystore lain di lain waktu, pastikan alias memiliki nama yang sama, gunakan panggilan PUT berikut:

curl "https://apigee.googleapis.com/v1/organizations/{org}/environments/{env}/references/keystoreref" \
  -X PUT \
  -H "Authorization: Bearer $TOKEN" \
  -d '<ResourceReference name="keystoreref">
    <Refers>myNewKeystore</Refers>
    <ResourceType>KeyStore</ResourceType>
  </ResourceReference>'

Dengan $TOKEN ditetapkan ke token akses OAuth 2.0 Anda, seperti yang dijelaskan dalam Mendapatkan token akses OAuth 2.0. Untuk mengetahui informasi tentang opsi curl yang digunakan dalam contoh ini, lihat Menggunakan curl. Untuk mengetahui deskripsi variabel lingkungan yang dapat Anda gunakan, lihat Menetapkan variabel lingkungan untuk permintaan API Apigee.

TargetEndpoint dengan load balancing target

Endpoint target mendukung load balancing di beberapa server target bernama menggunakan tiga algoritma load balancing.

Untuk mendapatkan petunjuk mendetail, lihat Load balancing di seluruh server backend.

IntegrationEndpoint

IntegrationEndpoint adalah endpoint target yang secara khusus menjalankan integrasi Apigee. Jika Anda telah mengonfigurasi IntegrationEndpoint, Apigee akan mengirim objek request ke Platform Integrasi Apigee untuk dieksekusi. Untuk menjalankan integrasi, selain mengonfigurasi IntegrationEndpoint, Anda juga harus menambahkan kebijakan SetIntegrationRequest dalam alur proxy.

Anda dapat mengonfigurasi integrasi untuk dieksekusi secara sinkron atau asinkron dengan menyetel elemen <AsyncExecution> dalam konfigurasi IntegrationEndpoint. Untuk mengetahui informasi selengkapnya, lihat Eksekusi sinkron vs. asinkron. Setelah menjalankan integrasi, Apigee menyimpan respons dalam pesan respons.

Catatan: Anda memerlukan token autentikasi untuk menjalankan IntegrationEndpoint. Namun, tidak ada elemen <Authentication> eksplisit dalam definisi IntegrationEndpoint. Apigee menambahkan token autentikasi ke permintaan di balik layar. Agar IntegrationEndpoint berhasil melakukan autentikasi, Anda harus men-deploy proxy API dengan akun layanan yang memiliki peran IAM yang diperlukan untuk menjalankan integrasi. Untuk mengetahui informasi tentang peran yang diperlukan, lihat Peran IAM untuk integrasi. Untuk mengetahui detail selengkapnya tentang men-deploy proxy API, lihat Men-deploy di Apigee.

Mengonfigurasi IntegrationEndpoint

Untuk mengonfigurasi endpoint integrasi sebagai endpoint target, tambahkan elemen IntegrationEndpoint ke konfigurasi ProxyEndpoint Anda. Berikut adalah contoh konfigurasi ProxyEndpoint:

<ProxyEndpoint name="default">
    <Description/>
    <FaultRules/>
    <PreFlow name="PreFlow">
        <Request>
            <Step>
                <Name>my-set-integration-request-policy</Name>
            </Step>
        </Request>
    </PreFlow>
    <Flows/>
    <PostFlow name="PostFlow"/>
    <HTTPProxyConnection>
        <BasePath>/integration-endpoint-test</BasePath>
        <Properties/>
    </HTTPProxyConnection>
    <RouteRule name="default">
        <IntegrationEndpoint>my-int-endpoint</IntegrationEndpoint>
    </RouteRule>
</ProxyEndpoint>

Dalam konfigurasi ProxyEndpoint contoh, Apigee melakukan tugas berikut:

1. Di PreFlow, jalankan kebijakan bernama my-set-integration-request-policy, yang menetapkan objek permintaan integrasi dan variabel alur integrasi.
2. Menggunakan my-int-endpoint sebagai endpoint target, seperti yang ditentukan dalam RouteRule.
3. Membaca objek permintaan integrasi yang dibuat oleh my-set-integration-request-policy.
4. Mengirim permintaan ke Integration Platform Apigee menggunakan objek permintaan dan variabel alur yang ditetapkan oleh kebijakan SetIntegrationRequest.
5. Menyimpan respons integrasi dalam pesan respons.

File XML yang berisi deklarasi <IntegrationEndpoint> akan tersedia di direktori APIGEE_BUNDLE_DIRECTORY/apiproxy/integration-endpoints/. Jika Anda membuat proxy API menggunakan opsi Develop > API Proxies > CREATE NEW > Integration target, Apigee akan menyimpan deklarasi dalam file /apiproxy/integration-endpoints/default.xml. Jika Anda membuat XML endpoint integrasi dari UI, Anda dapat memberikan nama kustom untuk file XML.

Contoh berikut menunjukkan deklarasi elemen <IntegrationEndpoint> dalam file XML:

<IntegrationEndpoint name="my-int-endpoint">
    <AsyncExecution>false</AsyncExecution>
</IntegrationEndpoint>

Elemen konfigurasi IntegrationEndpoint

Nama	Deskripsi	Default	Wajib?
IntegrationEndpoint
name	Nama IntegrationEndpoint. Karakter yang dapat Anda gunakan dalam nama dibatasi menjadi: A-Za-z0-9._\-$ %	T/A	Ya
AsyncExecution	Nilai Boolean yang menentukan apakah integrasi harus berjalan dalam mode sinkron atau asinkron. Untuk mengetahui informasi selengkapnya, lihat Eksekusi sinkron vs. asinkron.	false	Tidak

Eksekusi Sinkron vs. Asinkron

Anda dapat mengonfigurasi integrasi untuk berjalan dalam mode sinkron atau asinkron. Untuk memahami perbedaan antara mode eksekusi sinkron dan asinkron, lihat <AsyncExecution>.

Gunakan elemen <AsyncExecution> dalam </IntegrationEndpoint> untuk menentukan eksekusi sinkron atau asinkron. Jika Anda menetapkan <AsyncExecution> ke true, integrasi akan berjalan secara asinkron. Jika Anda menyetelnya ke false, integrasi akan berjalan secara sinkron.

Contoh berikut menetapkan AsyncExecution ke true:

<IntegrationEndpoint name="my-int-endpoint">
    <AsyncExecution>true</AsyncExecution>
</IntegrationEndpoint>

Kebijakan

Direktori /policies dalam proxy API berisi semua kebijakan yang tersedia untuk dilampirkan ke Alur dalam proxy API.

Elemen konfigurasi kebijakan

Nama	Deskripsi	Default	Wajib?
Policy
name	Nama internal kebijakan. Karakter yang dapat Anda gunakan dalam nama dibatasi ke: A-Za-z0-9._\-$ %. Namun, UI Apigee menerapkan batasan tambahan, seperti menghapus karakter yang bukan alfanumerik secara otomatis. Secara opsional, gunakan elemen <DisplayName> untuk memberi label pada kebijakan di editor proxy UI Apigee dengan nama bahasa alami yang berbeda.	T/A	Ya
enabled	Tetapkan ke true untuk menerapkan kebijakan. Setel ke false untuk menonaktifkan kebijakan. Kebijakan tidak akan diterapkan meskipun tetap terlampir pada alur.	true	Tidak
continueOnError	Disetel ke false untuk menampilkan error saat kebijakan gagal. Hal ini adalah perilaku yang diharapkan untuk sebagian besar kebijakan. Setel ke true agar eksekusi alur berlanjut meskipun kebijakan gagal.	false	Tidak
async	Catatan: Atribut ini tidak membuat kebijakan dijalankan secara asinkron. Dalam sebagian besar kasus, biarkan nilai defaultnya false. Jika disetel ke true, eksekusi kebijakan akan dialihkan ke thread lain, sehingga thread utama dapat menangani permintaan tambahan. Setelah pemrosesan offline selesai, thread utama akan kembali dan menyelesaikan penanganan alur pesan. Dalam beberapa kasus, menyetel asinkron ke true akan meningkatkan performa proxy API. Namun, penggunaan async yang berlebihan dapat menurunkan performa karena terlalu banyak pengalihan thread. Untuk menggunakan perilaku asinkron di proxy API, lihat model objek JavaScript.	false	Tidak

Lampiran kebijakan

Gambar berikut menunjukkan urutan eksekusi alur proxy API:

Seperti yang ditunjukkan di atas:

Kebijakan dilampirkan sebagai langkah pemrosesan ke Alur. Nama kebijakan digunakan untuk mereferensikan kebijakan yang akan diterapkan sebagai Langkah pemrosesan. Format lampiran kebijakan adalah sebagai berikut:

<Step><Name>MyPolicy</Name></Step>

Kebijakan diterapkan sesuai urutan penempelannya ke Alur. Contoh:

<Step><Name>FirstPolicy</Name></Step>
<Step><Name>SecondPolicy</Name></Step>

Elemen konfigurasi lampiran kebijakan

Nama	Deskripsi	Default	Wajib?
Step
Name	Nama kebijakan yang akan dieksekusi oleh definisi Langkah ini.	T/A	Ya
Condition	Pernyataan bersyarat yang menentukan apakah kebijakan diterapkan atau tidak. Jika kebijakan memiliki kondisi terkait, maka kebijakan hanya dijalankan jika pernyataan bersyarat bernilai benar (true).	T/A	Tidak

Alur

ProxyEndpoint dan TargetEndpoint menentukan pipeline untuk pemrosesan pesan permintaan dan respons. Pipeline pemrosesan terdiri dari alur permintaan dan alur respons. Setiap alur permintaan dan alur respons dibagi lagi menjadi PreFlow, satu atau beberapa alur bersyarat atau bernama opsional, dan PostFlow.

• PreFlow: Selalu dieksekusi. Dieksekusi sebelum Alur bersyarat.
• PostFlow: Selalu dieksekusi. Dieksekusi setelah Alur bersyarat.

Selain itu, Anda dapat menambahkan PostClientFlow ke endpoint proxy, yang dieksekusi setelah respons dikembalikan ke aplikasi klien yang meminta. Hanya kebijakan MessageLogging yang dapat dilampirkan ke alur ini. PostClientFlow mengurangi latensi proxy API dan menyediakan informasi untuk pencatatan yang tidak dihitung hingga setelah respons dikembalikan ke klien, seperti client.sent.start.timestamp dan client.sent.end.timestamp.Alur ini digunakan terutama untuk mengukur interval waktu antara stempel waktu mulai dan akhir untuk pesan respons.

Berikut adalah contoh PostClientFlow dengan kebijakan logging pesan yang dilampirkan.

...
  <PostFlow name="PostFlow">
      <Request/>
      <Response/>
  </PostFlow>
  <PostClientFlow>
      <Request/>
      <Response>
          <Step>
              <Name>Message-Logging-1</Name>
          </Step>
      </Response>
  </PostClientFlow>
  ...

Pipeline pemrosesan proxy API menjalankan Alur dalam urutan berikut:

Minta Pipeline:

1. Proxy Request PreFlow
2. Alur Bersyarat Permintaan Proxy (Opsional)
3. Proxy Request PostFlow
4. PreFlow Permintaan Target
5. Alur Bersyarat Permintaan Target (Opsional)
6. Target Request PostFlow

Pipeline Respons:

1. Target Response PreFlow
2. Alur Bersyarat Respons Target (Opsional)
3. Target Response PostFlow
4. Proxy Response PreFlow
5. Alur Bersyarat Respons Proxy (Opsional)
6. Proxy Response PostFlow
7. Respons PostClientFlow (Opsional)

Hanya Flow dengan lampiran kebijakan yang perlu dikonfigurasi dalam konfigurasi ProxyEndpoint atau TargetEndpoint. PreFlow dan PostFlow hanya perlu ditentukan dalam konfigurasi ProxyEndpoint atau TargetEndpoint jika kebijakan perlu diterapkan selama pemrosesan PreFlow atau PostFlow.

Berbeda dengan alur bersyarat, urutan elemen PreFlow dan PostFlow tidak penting--proxy API akan selalu mengeksekusi setiap elemen pada titik yang sesuai dalam pipeline, terlepas dari tempat kemunculannya dalam konfigurasi Endpoint.

Alur bersyarat

Endpoint proxy dan endpoint target mendukung jumlah alur bersyarat yang tidak terbatas (juga dikenal sebagai alur bernama).

Proxy API menguji kondisi yang ditentukan dalam alur bersyarat dan, jika kondisi terpenuhi, langkah-langkah pemrosesan dalam alur bersyarat akan dieksekusi oleh proxy API. Jika kondisi tidak terpenuhi, langkah-langkah pemrosesan dalam alur bersyarat akan dilewati. Alur bersyarat dievaluasi dalam urutan yang ditentukan di proxy API dan alur pertama yang kondisinya terpenuhi akan dieksekusi.

Dengan menentukan alur bersyarat, Anda mendapatkan kemampuan untuk menerapkan langkah-langkah pemrosesan di proxy API berdasarkan:

• URI Permintaan
• Kata kerja HTTP (GET/PUT/POST/DELETE)
• Nilai parameter kueri, header, dan parameter formulir
• Banyak jenis kondisi lainnya

Misalnya, alur kondisional berikut menentukan bahwa alur tersebut hanya dijalankan saat jalur resource permintaan adalah /accesstoken. Setiap permintaan masuk dengan jalur /accesstoken menyebabkan alur ini dieksekusi, beserta kebijakan apa pun yang dilampirkan ke alur. Jika jalur permintaan tidak menyertakan sufiks /accesstoken, maka alur tidak akan dieksekusi (meskipun alur bersyarat lain mungkin dieksekusi).

<Flows>
  <Flow name="TokenEndpoint">
    <Condition>proxy.pathsuffix MatchesPath "/accesstoken"</Condition>
    <Request>
      <Step>
        <Name>GenerateAccessToken</Name>
      </Step>
    </Request> 
  </Flow>
</Flows>   

Elemen konfigurasi alur

Nama	Deskripsi	Default	Wajib?
Flow	Pipeline pemrosesan permintaan atau respons yang ditentukan oleh endpoint proxy atau endpoint target
Name	Nama unik Flow.	T/A	Ya
Condition	Pernyataan bersyarat yang mengevaluasi satu atau beberapa variabel agar bernilai benar atau salah. Semua Flow selain jenis PreFlow dan PostFlow yang telah ditentukan sebelumnya harus menentukan kondisi untuk eksekusinya. Namun, jika Anda menyertakan satu alur tanpa kondisi di akhir urutan alur, alur tersebut akan bertindak sebagai pernyataan "Else" di akhir urutan alur.	T/A	Ya
Request	Pipeline yang terkait dengan pemrosesan pesan Permintaan	T/A	Tidak
Response	Pipeline yang terkait dengan pemrosesan pesan Respons	T/A	Tidak

Pemrosesan langkah

Pengurutan berurutan dari Flow bersyarat diterapkan oleh Apigee. Alur Bersyarat dieksekusi dari atas ke bawah. Alur bersyarat pertama yang kondisinya bernilai true akan dieksekusi, dan hanya satu Alur bersyarat yang dieksekusi.

Misalnya, dalam konfigurasi Flow berikut, setiap permintaan masuk yang tidak menyertakan akhiran jalur /first atau /second akan menyebabkan ThirdFlow dieksekusi, yang menerapkan kebijakan yang disebut Return404.

<Flows>
  <Flow name="FirstFlow">
    <Condition>proxy.pathsuffix MatchesPath "/first"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="SecondFlow">
    <Condition>proxy.pathsuffix MatchesPath "/second"</Condition>
    <Request>
      <Step><Name>FirstPolicy</Name></Step>
      <Step><Name>SecondPolicy</Name></Step>
    </Request>
  </Flow>
  <Flow name="ThirdFlow">
    <Request>
      <Step><Name>Return404</Name></Step>
    </Request>
  </Flow>
</Flows>

Referensi

"Resource" (file resource untuk digunakan dalam proxy API) adalah skrip, kode, dan transformasi XSL yang dapat dilampirkan ke Alur menggunakan kebijakan. Ini muncul di bagian Scripts pada editor proxy API di UI Apigee.

Lihat Mengelola resource untuk jenis resource yang didukung.

Resource dapat disimpan di proxy API, lingkungan, atau organisasi. Dalam setiap kasus, resource dirujuk berdasarkan nama dalam Kebijakan. Apigee menyelesaikan nama dengan berpindah dari proxy API, ke lingkungan, ke tingkat organisasi.

Resource yang disimpan di tingkat organisasi dapat dirujuk oleh Kebijakan di lingkungan mana pun. Resource yang disimpan di tingkat lingkungan dapat dirujuk oleh Kebijakan di lingkungan tersebut. Resource yang disimpan di level proxy API hanya dapat dirujuk oleh Kebijakan di proxy API tersebut.