Yang perlu Anda ketahui tentang error kebijakan

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.