Anda sedang melihat dokumentasi Apigee Edge.
Buka
dokumentasi Apigee X. info
Setiap model pemrograman aplikasi memiliki cara untuk mengontrol alur pemrosesan. Dalam proxy API, hal tersebut dilakukan dengan flow. Ke alur, Anda menambahkan logika, pernyataan kondisi, penanganan error, dan sebagainya. Anda menggunakan alur untuk mengontrol apa yang terjadi, dan kapan.
Flow adalah tahapan berurutan di sepanjang jalur pemrosesan permintaan API. Saat menambahkan logika proxy, misalnya untuk memverifikasi kunci API, Anda menambahkan logika sebagai langkah dalam urutan yang ditentukan oleh alur. Saat menentukan kondisi untuk menentukan apakah dan kapan logika dieksekusi, Anda menambahkan kondisi ke flow.
Contoh konfigurasi alur berikut menentukan alur tempat kebijakan VerifyAPIKey
dijalankan jika jalur permintaan masuk diakhiri dengan / dan kata kerja HTTP
permintaan adalah GET.
<Flow name="Get Food Carts">
<Description>Get Food Carts</Description>
<Request>
<Step>
<Name>Verify-API-Key</Name>
</Step>
</Request>
<Condition>(proxy.pathsuffix MatchesPath "/") and (request.verb = "GET")</Condition>
</Flow>
Nilai Verify-API-Key dalam elemen <Name> alur berfungsi untuk menyertakan kebijakan yang dikonfigurasi di tempat lain dalam proxy dengan XML seperti berikut:
<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<VerifyAPIKey async="false" continueOnError="false" enabled="true" name="Verify-API-Key">
<DisplayName>Verify API Key</DisplayName>
<Properties/>
<APIKey ref="request.header.x-api-key"/>
</VerifyAPIKey>
Mendesain urutan eksekusi flow
Anda menyusun alur sehingga logika dapat dijalankan dalam urutan yang benar di sepanjang jalur pemrosesan.
Saat menentukan tempat untuk menambahkan logika, pertama-tama Anda harus memilih apakah akan menambahkannya ke endpoint proxy atau endpoint target. Proxy API membagi kodenya antara kode yang berinteraksi dengan klien proxy (endpoint proxy) dan kode opsional yang berinteraksi dengan target backend proxy, jika ada (endpoint target).
Kedua endpoint berisi flow, seperti yang dijelaskan di sini:
| Jenis endpoint | Deskripsi | Flow didukung |
|---|---|---|
| ProxyEndpoint | Berisi alur proxy API yang paling dekat dengan klien. Memberikan tempat bagi logika untuk bertindak terlebih dahulu pada permintaan dari klien, lalu terakhir pada respons ke klien. | {i>PreFlow<i}, alur bersyarat, {i>PostFlow<i}, {i>PostClientFlow<i} |
| TargetEndpoint | Berisi alur proxy API yang paling dekat dengan resource backend. Menyediakan tempat untuk logika guna menyiapkan permintaan, lalu menangani respons dari resource backend. | Aliran Awal, alur bersyarat, PostFlow |
Anda mengonfigurasi alur dengan XML yang menentukan apa yang harus terjadi dan dalam urutan apa. Ilustrasi berikut menunjukkan cara urutan alur secara berurutan dalam endpoint proxy dan endpoint target:
Endpoint proxy dan endpoint target masing-masing berisi alur yang dapat Anda atur dalam urutan berikut:
| Posisi | Jenis alur | Deskripsi |
|---|---|---|
| 1 | PreFlow |
Berguna saat Anda perlu memastikan bahwa kode tertentu dijalankan sebelum hal lain terjadi. Jika berada di endpoint target, PreFlow akan dijalankan setelah PostFlow endpoint proxy. |
| 2 | Alur Bersyarat |
Tempat untuk logika kondisional. Dijalankan setelah PreFlow dan sebelum PostFlow.
Hanya satu flow kondisional yang dijalankan per segmen--flow pertama yang kondisinya bernilai
true. Artinya, Anda dapat menjalankan satu flow kondisional sebagai bagian dari
setiap alur bersyarat:
|
| 3 | PostFlow |
Tempat yang tepat untuk mencatat data, mengirim notifikasi bahwa terjadi sesuatu saat memproses permintaan, dan sebagainya. Dieksekusi setelah flow bersyarat dan PreFlow. Jika PostFlow berada di endpoint proxy, dan ada endpoint target, PostFlow endpoint proxy akan dijalankan sebelum PreFlow endpoint target. |
| 4 | PostClientFlow (khusus alur proxy) | Alur untuk mencatat pesan ke dalam log setelah respons ditampilkan ke klien. |
Menjalankan kode terlebih dahulu dengan PreFlow
PreFlow berguna saat Anda perlu memastikan bahwa kode tertentu dieksekusi sebelum hal lain terjadi.
Di endpoint proxy, PreFlow adalah tempat yang tepat untuk kode yang mengautentikasi klien dan membatasi traffic dari klien. Di endpoint target, tempatnya mulai mempersiapkan pengiriman permintaan ke target backend, PreFlow merupakan langkah pertama yang tepat untuk mempersiapkan pengiriman permintaan.
Misalnya, Anda biasanya tidak ingin melayani klien yang telah melebihi kuotanya. Untuk mendukung persyaratan ini, tempatkan kebijakan keamanan dan kuota dalam segmen PreFlow. Dengan demikian, Anda tidak perlu mengkhawatirkan kondisi yang gagal dievaluasi dalam alur kondisional berikutnya. Kebijakan dalam alur ini akan selalu dijalankan sebelum pemrosesan lainnya dilakukan.
Dalam contoh berikut, kebijakan SpikeArrest dan Quota dieksekusi sebelum pemrosesan diteruskan ke alur bersyarat.
<PreFlow name="MyPreFlow">
<Request>
<Step>
<Name>Spike-Arrest</Name>
</Step>
<Step>
<Name>Quota</Name>
</Step>
</Request>
<Response/>
</PreFlow>
Meminta kode dieksekusi secara bersyarat dengan alur bersyarat
Antara PreFlow dan PostFlow, Anda dapat memiliki alur yang dieksekusi secara kondisional. Hal ini memberi Anda kesempatan untuk mengonfigurasi beberapa urutan logika, tetapi hanya memiliki satu eksekusi berdasarkan status proxy Anda. Alur kondisional bersifat opsional jika Anda dapat menjalankan semua logika di PreFlow atau PostFlow dan tidak ada kondisi yang diperlukan (dengan kata lain, hanya satu jalur melalui endpoint yang didukung).
Setiap alur menetapkan kondisi yang menguji nilai status yang berbeda-beda. Hal ini secara efektif mencabangkan eksekusi berdasarkan kondisi. Misalnya, Anda mungkin ingin mengonversi XML ke JSON hanya saat aplikasi yang meminta berjalan di perangkat seluler.
Di sini, batasan kuota hanya diterapkan jika permintaan adalah permintaan GET dengan
pola URI /issue/** (/issue/ dengan apa pun dalam URI setelah garis miring
depan terakhir).
<Flow name="MyFlow">
<Description/>
<Request>
<Step>
<Name>Quota</Name>
</Step>
</Request>
<Response/>
<Condition>(proxy.pathsuffix MatchesPath "/issue/**") and (request.verb = "GET")</Condition>
</Flow>
Anda menggunakan variabel alur untuk menentukan kondisi. Untuk mengetahui informasi selengkapnya tentang penggunaan variabel dalam kondisi, lihat Kondisi dengan variabel alur.
Untuk contoh penggunaan pencocokan pola dalam kondisi, lihat Pencocokan pola.
Membuat kode dieksekusi setelah logika inti dengan PostFlow
PostFlow adalah tempat yang tepat untuk melakukan tindakan setelah logika inti endpoint, dan sebelum pemrosesan endpoint selesai. PostFlow dijalankan setelah flow bersyarat dan PreFlow.
PostFlow adalah alat yang baik untuk membuat log beberapa data, mengirim notifikasi bahwa sesuatu terjadi, mengubah format pesan respons, dan sebagainya.
Dalam contoh berikut, kebijakan AssignMessage yang disebut SetResponseHeaders menetapkan header pesan respons sebelum Apigee Edge mengirim respons kembali ke klien.
<PostFlow>
<Response>
<Step>
<Name>SetResponseHeaders</Name>
</Step>
</Response>
</PostFlow>
Membuat kode dieksekusi setelah klien menerima respons proxy Anda dengan PostClientFlow
PostClientFlow dapat mencakup kebijakan berikut:
* Kebijakan FlowCallout hanya dapat memanggil alur bersama yang memenuhi kriteria untuk berada di PostClientFlow (yaitu, hanya berisi kebijakan yang kompatibel).
Jika Anda menyertakannya, PostClientFlow akan menjadi alur terakhir yang akan dieksekusi, yang dieksekusi setelah respons dikirim ke klien.
PostClientFlow bagus untuk logging akhir. Selain itu, Anda dapat mencatat stempel waktu awal dan akhir untuk pesan respons.
Berikut adalah contoh PostClientFlow dengan kebijakan MessageLogging yang dilampirkan.
...
<PostFlow name="PostFlow">
<Request/>
<Response/>
</PostFlow>
<PostClientFlow>
<Request/>
<Response>
<Step>
<Name>Message-Logging-1</Name>
</Step>
</Response>
</PostClientFlow>
...
Video: Tonton video singkat ini yang menunjukkan cara membuat PostClientFlow menggunakan kebijakan MessageLogging dari seri Video Empat Menit untuk Developer (4MV4D).
Untuk informasi selengkapnya, lihat:
Menambahkan logika ke alur
Saat menambahkan logika ke proxy, Anda melakukannya dengan menambahkan kebijakan ke alur proxy. Sama seperti alur yang dijalankan dalam urutan (PreFlow lalu Flow kemudian PostFlow, seperti yang dijelaskan dalam topik ini), konten alur dieksekusi secara berurutan.
Contoh konfigurasi alur berikut merujuk pada tiga kebijakan (dikonfigurasi di tempat lain dalam
file XML-nya sendiri). Kebijakan yang dirujuk oleh Verify-API-Key dieksekusi sebelum
kebijakan yang dirujuk oleh Remove-API-Key; keduanya diikuti oleh kebijakan yang direpresentasikan oleh
Quota.
<Flow name="Get Food Cart Menus">
<Description>Get Food Cart Menus</Description>
<Request>
<Step>
<Name>Verify-API-Key</Name>
</Step>
<Step>
<Name>Remove-API-Key</Name>
</Step>
<Step>
<Name>Quota</Name>
</Step>
</Request>
<Condition>(proxy.pathsuffix MatchesPath "/") and (request.verb = "GET")</Condition>
</Flow>
Konsol Apigee Edge menampilkan urutan kebijakan ini sebagai deretan ikon yang setiap ikonnya merepresentasikan kebijakan tersebut.
Men-debug flow
Alat Apigee Edge Trace menyediakan cara grafis untuk melihat cara logika dalam proxy API dieksekusi mengikuti permintaan. Alat ini mengilustrasikan pemrosesan antara permintaan dan respons. Diagram ini tidak secara khusus mengilustrasikan pemisahan antara PreFlow, alur kondisional, dan PostFlow.
Untuk mengetahui informasi selengkapnya tentang pelacakan proxy, lihat Menggunakan alat Trace.
Menangani error dalam alur
Anda dapat melaporkan error dari berbagai tempat di proxy API, termasuk dari alur.
Contoh berikut adalah stanza respons dari PreFlow di endpoint target -- dengan kata lain, ini adalah kode yang langsung dieksekusi setelah menerima respons dari target backend. Dalam contoh, fault akan dimunculkan jika respons dari target bukan 200 (berhasil).
<PreFlow name="PreFlow">
<Response>
<Step>
<Name>RaiseFault</Name>
<Condition>(response.status.code GreaterThan "200")</Condition>
</Step>
</Response>
</PreFlow>
Untuk informasi selengkapnya tentang penanganan error, lihat Menangani kesalahan.