Halaman ini berlaku untuk Apigee dan Apigee hybrid.
Lihat dokumentasi Apigee Edge.
Topik ini menjelaskan struktur error kebijakan dan jenis variabel alur yang ditetapkan saat error kebijakan terjadi. Informasi ini penting jika Anda mendesain dan menerapkan penanganan error untuk proxy.
Topik ini mengasumsikan bahwa Anda memiliki pemahaman umum tentang cara kerja penanganan error di Apigee, dan bahwa Anda mengetahui apa itu aturan error. Jika Anda memerlukan peninjauan, lihat Menangani error. Informasi di sini juga akan membantu Anda menavigasi dan menggunakan Referensi error kebijakan.
Tentang respons error kebijakan default
Saat kebijakan menampilkan error, Apigee akan langsung memasuki alur error dan menghasilkan pesan error. Pesan yang dibuat sistem ini adalah objek JSON yang menyertakan dua bit informasi: errorcode
dan faultstring
.
Contoh:
{ "fault":{ "detail":{ "errorcode":"steps.extractvariables.SourceMessageNotAvailable" }, "faultstring":"mymessage message is not available for ExtractVariable: ParseJsonResponse" } }
Mari kita dekonstruksi pesan error ini dengan cepat:
errorcode
terdiri dari prefix
dan error
name
, sebagai berikut: [prefix].[error_name]
. Pada contoh di atas,
"steps.extractvariables
adalah awalan dan SourceMessageNotAvailable
adalah
nama error. Awalan ini memberi tahu Anda jenis kebijakan yang menghasilkan error. Pada contoh
di atas, Anda dapat mengetahui bahwa kebijakan ExtractVariables menghasilkan error dan nama errornya adalah
SourceMessageNotAvailable
.
faultstring
berisi deskripsi error. String error
biasanya menyertakan petunjuk untuk membantu Anda menemukan masalah spesifik yang menyebabkan error, seperti
nama kebijakan, nama variabel yang belum terselesaikan, atau apa pun yang berkontribusi pada error. Misalnya, dalam pesan error di atas, mymessage
adalah nama variabel pesan
yang belum terselesaikan yang dirujuk dalam kebijakan dan ParseJsonResponse
adalah nama
kebijakan yang memicu error.
Variabel khusus untuk error kebijakan
Saat error kebijakan dipicu, variabel alur khusus error tertentu akan diisi. Variabel ini sangat berguna dalam penanganan error. Seperti yang dijelaskan dalam Menangani error, praktik umum adalah menangkap error kebijakan yang dihasilkan sistem dan melakukan tindakan berikutnya seperti membuat respons error kustom. Misalnya, karena alasan keamanan, Anda mungkin ingin mencegah klien melihat error dan kode status sebenarnya yang ditampilkan Apigee.
Variabel fault.name
Saat kebijakan menampilkan error, kebijakan akan menetapkan variabel alur fault.name
ke bagian error_name
dari errorcode (seperti yang dijelaskan di bagian sebelumnya). Sangat umum untuk mengevaluasi variabel ini guna mengeksekusi aturan error secara kondisional.
Berikut adalah contoh aturan error yang menguji nilai fault.name
:
<faultrule name="VariableOfNonMsgType"></faultrule><FaultRule name="Source Message Not Available Fault"> <Step> <Name>AM-CustomErrorMessage</Name> <Condition>(fault.name Matches "SourceMessageNotAvailable") </Condition> </Step> </FaultRule>
Hal yang perlu diingat adalah saat kebijakan memicu error, variabel fault.name
selalu ditetapkan ke nama error.
Variabel
[prefix].[policy_name].failed
Selain fault.name
, variabel lain yang biasa diperiksa developer adalah
tanda [prefix].[policy_name].failed
, yang disetel ke benar atau salah saat
kebijakan dieksekusi. Dalam aturan error, Anda perlu memeriksa kapan aturan tersebut benar —
yaitu, untuk memeriksa apakah error terjadi. Berikut cara membuat kondisional yang memeriksa
tanda [prefix].[policy_name].failed
. Untuk memeriksa variabel ini dengan benar, Anda perlu mengetahui dua hal:
- Nama kebijakan yang Anda periksa. Ini adalah nilai atribut nama kebijakan, bukan nama tampilan. Atribut ini selalu disertakan dalam XML definisi kebijakan.
- Awalan yang khusus untuk jenis kebijakan yang Anda periksa. (Kami akan menjelaskan cara menemukan awalan di bawah.)
Untuk mengilustrasikannya, berikut adalah contoh aturan error lainnya. Perhatikan dalam kondisi luar bagaimana
nama variabel [prefix].[policy_name].failed
terbentuk. Dalam hal ini, awalan adalah
extractvariables
dan nama kebijakan adalah ParseJsonResponse
. Dalam hal ini, aturan error hanya akan dieksekusi jika variabel ini bernilai benar. Selain itu, berikut adalah tipsnya: karena aturan
error dapat berisi beberapa langkah, pola ini adalah cara yang bagus untuk mengatur aturan error ke dalam
blok.
<faultrule name="VariableOfNonMsgType"></faultrule><FaultRule name="Extract Variable Faults"> <Step> <Name>AM-CustomErrorMessage</Name> <Condition>(fault.name Matches "SourceMessageNotAvailable") </Condition> </Step> <Condition>(extractvariables.ParseJsonResponse.failed = true) </Condition> </FaultRule>
Tentang variabel error
dan message
Variabel error
hanya tersedia dalam alur error proxy. Anda bisa mendapatkan informasi yang berguna dari variabel error
, seperti pesan error, kode status, frasa alasan, dan sebagainya. Pola pemformatan untuk variabel error adalah sebagai berikut:
error.ERROR_COMPONENT = VALUE
Contoh:
error.message = "request message is not available for ExtractVariable: ParseJsonResponse"
dan
error.status.code = "500"
Variabel message
juga tersedia dalam alur error dan dapat digunakan untuk tujuan yang serupa dengan variabel error
. Variabel pesan bersifat khusus karena bersifat kontekstual. Dalam alur permintaan, variabel ini berperilaku seperti variabel permintaan, dan dalam alur respons, variabel ini dapat digunakan untuk mendapatkan/menetapkan nilai respons.
Lihat Referensi variabel alur
untuk mengetahui informasi tentang semua variabel Apigee, termasuk error
dan
message
.