MuleSoft - Penanganan Pengecualian Mule

Dalam kasus setiap proyek, fakta tentang pengecualian adalah bahwa mereka pasti akan terjadi. Itulah mengapa penting untuk menangkap, mengkategorikan, dan menangani pengecualian agar sistem / aplikasi tidak dibiarkan dalam keadaan tidak konsisten. Ada strategi pengecualian default yang diterapkan secara implisit ke semua aplikasi Mule. Rollback setiap transaksi yang tertunda secara otomatis adalah strategi pengecualian default.

Pengecualian di Mule

Sebelum mendalami penanganan luar biasa, kita harus memahami jenis pengecualian yang dapat terjadi bersama dengan tiga pertanyaan dasar yang harus dimiliki pengembang saat merancang penangan pengecualian.

Transportasi mana yang penting?

Pertanyaan ini memiliki relevansi yang cukup sebelum merancang penangan pengecualian karena semua transpor tidak mendukung transnasionalitas.

File atau HTTPtidak mendukung transaksi. Itu sebabnya, jika terjadi eksepsi dalam kasus ini, kita harus mengelolanya secara manual.

Databasesmendukung transaksi. Saat mendesain penangan pengecualian dalam kasus ini, kita harus ingat bahwa transaksi database dapat secara otomatis melakukan rollback (jika diperlukan).

Dalam kasus REST APIs, kita harus ingat bahwa mereka harus mengembalikan kode status HTTP yang benar. Misalnya, 404 untuk sumber daya tidak ditemukan.

Pola Pertukaran Pesan mana yang akan digunakan?

Saat merancang penangan pengecualian, kita harus memperhatikan pola pertukaran pesan. Bisa ada pola pesan sinkron (permintaan-balasan) atau asinkron (api-lupa).

Synchronous message pattern didasarkan pada format permintaan-balasan yang berarti pola ini akan mengharapkan tanggapan dan akan diblokir sampai tanggapan dikembalikan atau terjadi waktu habis.

Asynchronous message pattern didasarkan pada format fire-forget yang berarti pola ini mengasumsikan bahwa permintaan pada akhirnya akan diproses.

Jenis pengecualian apa itu?

Aturan yang sangat sederhana adalah Anda akan menangani pengecualian berdasarkan tipenya. Sangat penting untuk mengetahui apakah pengecualian disebabkan oleh masalah sistem / teknis atau masalah bisnis?

Pengecualian terjadi oleh system/technical issue (seperti pemadaman jaringan) harus secara otomatis ditangani oleh mekanisme coba lagi.

Di sisi lain, terjadi pengecualian by a business issue (seperti data tidak valid) tidak boleh diselesaikan dengan menerapkan mekanisme coba lagi karena tidak berguna untuk mencoba ulang tanpa memperbaiki penyebab yang mendasarinya.

Mengapa Mengkategorikan Pengecualian?

Seperti yang kita ketahui bahwa semua pengecualian tidak sama, sangat penting untuk mengkategorikan pengecualian tersebut. Pada tingkat tinggi, pengecualian dapat diklasifikasikan menjadi dua jenis berikut -

Pengecualian Bisnis

Alasan utama terjadinya pengecualian bisnis adalah data yang salah atau aliran proses yang salah. Pengecualian semacam ini biasanya tidak dapat ditarik kembali dan oleh karena itu tidak baik untuk mengonfigurasi filerollback. Bahkan melamarretrymekanisme tidak akan masuk akal karena tidak berguna untuk mencoba lagi tanpa memperbaiki penyebab yang mendasarinya. Untuk menangani pengecualian tersebut, pemrosesan harus segera dihentikan, dan pengecualian dikirim kembali sebagai respons atas antrean surat mati. Pemberitahuan juga harus dikirim ke operasi.

Pengecualian Non-bisnis

Alasan utama terjadinya pengecualian non-bisnis adalah masalah sistem atau masalah teknis. Jenis pengecualian ini bersifat retriable dan karenanya bagus untuk mengonfigurasi fileretry mekanisme untuk menyelesaikan pengecualian ini.

Strategi Penanganan Pengecualian

Mule memiliki lima strategi penanganan pengecualian berikut -

Strategi Pengecualian Default

Mule secara implisit menerapkan strategi ini pada aliran Mule. Ini dapat menangani semua pengecualian dalam aliran kami, tetapi juga dapat diganti dengan menambahkan strategi pengecualian tangkapan, Pilihan atau Rollback. Strategi pengecualian ini akan mengembalikan semua transaksi yang tertunda dan mencatat pengecualian juga. Karakteristik penting dari strategi pengecualian ini adalah bahwa ia juga akan mencatat pengecualian jika tidak ada transaksi.

Sebagai strategi default, Mule mengimplementasikan ini ketika terjadi kesalahan dalam aliran. Kami tidak dapat mengonfigurasi di AnyPoint studio.

Strategi Pengecualian Rollback

Misalkan jika tidak ada solusi yang mungkin untuk memperbaiki kesalahan lalu apa yang harus dilakukan? Solusinya adalah dengan menggunakan Strategi Pengecualian Rollback yang akan memutar kembali transaksi bersama dengan pengiriman pesan ke konektor masuk aliran induk untuk memproses ulang pesan. Strategi ini juga sangat berguna ketika kita ingin memproses ulang sebuah pesan.

Example

Strategi ini dapat diterapkan pada transaksi perbankan di mana dana disimpan di rekening giro / tabungan. Kita dapat mengonfigurasi strategi pengecualian rollback di sini karena jika terjadi kesalahan selama transaksi, strategi ini menggulung pesan kembali ke awal alur untuk mencoba pemrosesan kembali.

Strategi Pengecualian Tangkapan

Strategi ini menangkap semua pengecualian yang dilemparkan dalam aliran induknya. Ini menggantikan strategi pengecualian default Mule dengan memproses semua pengecualian yang dilemparkan oleh aliran induk. Kita dapat menggunakan strategi pengecualian tangkapan untuk menghindari penyebaran pengecualian ke konektor masuk dan aliran induk juga.

Strategi ini juga memastikan bahwa transaksi yang diproses oleh aliran tidak dibatalkan ketika terjadi pengecualian.

Example

Strategi ini dapat diterapkan pada sistem pemesanan penerbangan di mana kita memiliki alur untuk memproses pesan dari antrian. Pengaya pesan menambahkan properti pada pesan untuk penetapan kursi dan kemudian mengirim pesan ke antrean lain.

Sekarang jika ada kesalahan yang terjadi dalam aliran ini, maka pesan tersebut akan memunculkan pengecualian. Di sini, strategi pengecualian tangkap kami dapat menambahkan tajuk dengan pesan yang sesuai dan dapat mendorong pesan itu keluar dari alur ke antrean berikutnya.

Strategi Pengecualian Pilihan

Jika Anda ingin menangani pengecualian berdasarkan konten pesan, maka strategi pengecualian pilihan akan menjadi pilihan terbaik. Cara kerja strategi pengecualian ini adalah sebagai berikut -

Pertama, ini menangkap semua pengecualian yang dilemparkan dalam aliran induk.
Selanjutnya, ia memeriksa konten pesan dan jenis pengecualian.
Dan akhirnya, ini merutekan pesan ke strategi pengecualian yang sesuai.

Akan ada lebih dari satu strategi pengecualian seperti Catch atau Rollback, yang ditentukan dalam strategi pengecualian pilihan. Jika tidak ada strategi yang ditentukan di bawah strategi pengecualian ini, maka itu akan merutekan pesan ke strategi pengecualian default. Itu tidak pernah melakukan aktivitas commit atau rollback atau konsumsi apa pun.

Referensi Strategi Pengecualian

Ini mengacu pada strategi pengecualian umum yang ditentukan dalam file konfigurasi terpisah. Jika pesan melontarkan pengecualian, strategi pengecualian ini akan merujuk ke parameter penanganan kesalahan yang ditentukan dalam strategi global catch, rollback atau choice exception. Seperti strategi pengecualian pilihan, ia tidak pernah melakukan aktivitas commit atau rollback atau konsumsi apa pun juga.