Yang perlu Anda ketahui tentang error kebijakan

Halaman ini berlaku untuk Apigee dan Apigee hybrid.

Lihat Dokumentasi Apigee Edge.

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 dalam Apigee, dan Anda tahu apa itu aturan kesalahan. Jika Anda memerlukan peninjauan, lihat Menangani kesalahan. Tujuan informasi di sini akan juga membantu Anda membuka dan menggunakan Referensi error kebijakan.

Tentang respons error kebijakan default

Saat kebijakan menampilkan error, Apigee 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":"mymessage message is not available for ExtractVariable: ParseJsonResponse"
   }
}

Mari kita dekonstruksi pesan {i>error<i} ini secara cepat:

errorcode terdiri dari prefix dan error name, sebagai berikut: [prefix].[error_name]. Dalam contoh di atas "steps.extractvariables adalah awalan dan SourceMessageNotAvailable adalah awalan nama error. Awalan memberi tahu Anda jenis kebijakan yang menyebabkan error. Dalam contoh di atas misalnya, Anda dapat mengetahui bahwa kebijakan ExtractVariables menghasilkan error dan nama error-nya 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, mymessage kebetulan adalah nama objek yang belum terselesaikan variabel pesan yang dirujuk dalam kebijakan dan ParseJsonResponse adalah nama 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 dijelaskan dalam Menangani kesalahan, yang merupakan praktik yang umum 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 error dan kode status sebenarnya yang ditampilkan Apigee.

Variabel fault.name

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}.

Tujuan 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 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 ini khusus karena dapat bersifat kontekstual. Dalam alur permintaan, perilakunya seperti variabel permintaan, dan dalam alur respons, dapat digunakan untuk mendapatkan/menetapkan nilai respons.

Lihat Referensi variabel flow untuk mendapatkan informasi tentang semua variabel Apigee, termasuk error dan message.