Anda sedang melihat dokumentasi Apigee Edge.
Buka
Dokumentasi Apigee X. info
Topik ini menjelaskan struktur kesalahan kebijakan dan jenis variabel alur yang disetel saat terjadi error kebijakan. Informasi ini sangat penting jika Anda mendesain dan menerapkan penanganan kesalahan untuk {i>proxy<i} Anda.
Topik ini mengasumsikan Anda memiliki pemahaman umum tentang cara kerja penanganan kesalahan di Edge, dan Anda tahu apa itu aturan kesalahan. Jika Anda memerlukan peninjauan, lihat Menangani kesalahan. Informasi di sini akan juga membantu Anda membuka dan menggunakan Referensi error kebijakan.
Tentang respons error kebijakan default
Saat kebijakan menampilkan error, Edge akan langsung memasuki alur error dan menghasilkan error untuk membuat pesan email baru. Pesan yang dihasilkan sistem ini adalah objek JSON yang menyertakan dua bit informasi: errorcode dan faultstring.
Contoh:
{ "fault":{ "detail":{ "errorcode":"steps.extractvariables.SourceMessageNotAvailable" }, "faultstring":"foo message is not available for ExtractVariable: ParseJsonResponse" } }
Mari kita dekonstruksi pesan {i>error<i} ini secara cepat:
errorcode terdiri dari awalan dan error
name, sebagai berikut: [prefix].[error_name]
. Dalam contoh di atas
"steps.extractvariables
" adalah awalan dan SourceMessageNotAvailable
adalah
nama error. Awalan memberi tahu Anda jenis kebijakan yang menyebabkan error. Dalam contoh di atas
misalnya, Anda dapat mengetahui bahwa kebijakan {i>
Extract Variables<i} menghasilkan {i>error<i} dan nama {i>error<i} adalah
SourceMessageNotAvailable
.
Faultstring berisi deskripsi error. String fault
biasanya mencakup petunjuk untuk membantu Anda menemukan masalah khusus yang menyebabkan kesalahan, seperti
nama kebijakan, nama variabel yang belum terselesaikan, atau apa pun yang menyebabkan error. Sebagai
contoh, dalam pesan error di atas, "foo
" kebetulan adalah nama objek yang belum
variabel pesan yang dirujuk dalam kebijakan dan "ParseJsonResponse
" adalah nama dari
yang memicu error.
Variabel khusus untuk error kebijakan
Saat error kebijakan dipicu, variabel alur khusus error tertentu akan diisi. Ini variabel sangat berguna dalam penanganan fault. Seperti yang telah dijelaskan dalam topik Menangani kesalahan, menjebak error kebijakan yang dihasilkan sistem dan melakukan tindakan selanjutnya seperti membuat respons error kustom. Misalnya, untuk alasan keamanan, Anda mungkin ingin mencegah klien melihat kesalahan aktual dan kode status yang dikembalikan Edge.
fault.name
variabel
Saat kebijakan menampilkan error, kebijakan akan menetapkan variabel alur fault.name
ke
error_name
dari kode error (seperti yang dijelaskan di bagian sebelumnya). Sangat
untuk mengevaluasi variabel ini untuk mengeksekusi
aturan fault secara bersyarat.
Berikut adalah contoh aturan kesalahan 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, fault.name
variabel selalu diatur ke nama {i>error<i}.
Variabel [prefix].[policy_name].failed
Selain fault.name
, variabel lain yang biasanya diperiksa oleh developer adalah
[prefix].[policy_name].failed
, yang disetel ke benar (true) atau salah (salah) saat
kebijakan dijalankan. Dalam aturan kesalahan, sebaiknya periksa kapan error tersebut true --
yaitu, untuk memeriksa
apakah terjadi kesalahan. Berikut cara membuat kondisional yang memeriksa
[prefix].[policy_name].failed
. Untuk memeriksa variabel
ini dengan benar, Anda harus
mengetahui dua hal:
- Nama kebijakan yang Anda periksa. Ini adalah nilai dari nama, bukan nama tampilan. Atribut ini selalu disertakan dalam kebijakan XML definisi.
- Awalan yang dikhususkan untuk jenis kebijakan yang Anda periksa. (Kita akan jelaskan cara menemukan awalan tersebut di bawah.)
Sebagai ilustrasi, berikut ini
contoh aturan kesalahan lainnya. Perhatikan dalam kondisi {i>outer<i}, bagaimana
Nama variabel [prefix].[policy_name].failed
dibuat. Dalam hal ini awalannya adalah
extractvariables
dan nama kebijakannya adalah ParseJsonResponse
. Di sini
kejadian, aturan kesalahan hanya akan
dieksekusi jika variabel ini bernilai benar. Dan, inilah tipnya: karena kesalahan
aturan dapat berisi beberapa langkah, pola ini adalah cara yang baik untuk mengatur aturan kesalahan ke
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 dari
{i>proxy<i}. Anda bisa mendapatkan informasi yang berguna dari variabel error, seperti pesan error, status
kode, frasa alasan, dan sebagainya. Pola pemformatan untuk variabel error adalah:
error.[error_component] = [value]
Contoh:
error.message
= "request message is not available for ExtractVariable:
ParseJsonResponse
inci
dan
error.status.code = "500"
Variabel message
juga tersedia dalam alur error dan dapat digunakan untuk
tujuan yang serupa dengan variabel error
. Variabel pesan ini khusus
karena dapat
bersifat kontekstual. Dalam alur permintaan, perilakunya seperti variabel permintaan, dan dalam alur respons,
dapat digunakan untuk mendapatkan/menetapkan nilai respons. Jika Anda ingin mengetahui lebih lanjut, lihat Menggunakan
untuk variabel pesan.
Lihat Referensi variabel
untuk informasi tentang semua variabel Edge, termasuk error
dan
message
.