Error Event pada API Call

Secara bawaan, API Call yang gagal menghentikan process instance dan memunculkan incident: prosesnya berhenti di tempat, menunggu diperiksa orang. Itu benar untuk kerusakan, tetapi tidak selalu benar untuk bisnis — ada kegagalan yang memang punya rencana cadangan.

Contohnya: pengecekan ke OJK mengembalikan kode error, dan prosesnya harus melanjut ke penyedia lain, misalnya Pefindo. Dengan Error Boundary Event, kegagalan seperti itu menjadi cabang, bukan penghentian.

Prasyarat: API Call harus menjadi perilaku Service Task

Ini bagian yang paling mudah terlewat.

API Call yang dipasang lewat panel API Request dijalankan sebagai execution listener. Error yang dilempar dari execution listener tidak ditangkap Error Boundary Event — itu sifat Camunda, bukan keterbatasan AlurKerja. Supaya bisa ditangkap, panggilannya harus menjadi perilaku Service Task-nya sendiri.

Langkah

1. Pasang API Call pada Service Task

Pilih Service Task di kanvas, lalu pada panel kanan bagian Implementation pilih Expression dan isi:

${apiContext.getInstance("<tenant-id>", "<nama konfigurasi API>").setExecution(execution).putAllProcessVariables().executeAndExtractOrFail("<variabel hasil>", "<json path>")}

Bedanya dengan API Call biasa hanya pada nama method terakhirnya: executeAndExtractOrFail, bukan executeAndExtract. Method inilah yang mengubah kegagalan HTTP menjadi BPMN error.

2. Tempelkan Error Boundary Event

Tarik Boundary Event ke tepi Service Task tadi, lalu ubah jenisnya menjadi Error Boundary Event.

3. Tentukan Error Code-nya

Pada panel kanan, buat sebuah Error dan isi Code-nya dengan kode status HTTP yang ingin ditangkap — 404, 422, 500, dan seterusnya. Kode status dipakai apa adanya supaya yang ditulis di modeler sama persis dengan yang dibalas API, tanpa kamus perantara.

Kalau prosesnya perlu kode sendiri, tambahkan argumen ketiga:

...executeAndExtractOrFail("hasil", "$.data", "OJK_DITOLAK")

lalu isi Code dengan OJK_DITOLAK.

4. Sambungkan ke cabang penggantinya

Tarik sequence flow dari boundary event ke aktivitas berikutnya — misalnya Service Task Pefindo.

Variabel yang tersedia di cabang error

Sebelum error dilempar, tiga variabel diisi supaya cabang penggantinya tahu kenapa ia dijalankan:

Ketiganya bisa langsung dipakai di form, kondisi gateway, maupun API Call berikutnya.

Yang TIDAK menjadi error event

Hanya kegagalan HTTP — status 400 ke atas — yang menjadi BPMN error.

Koneksi yang putus, alamat yang salah, atau response yang tidak bisa dibaca tetap menjadi incident seperti sebelumnya. Itu disengaja: keduanya adalah kerusakan, bukan keputusan bisnis, dan menyembunyikannya di balik cabang pengganti membuat proses berjalan terus seolah tidak terjadi apa-apa.

Kalau boundary event-nya tidak cocok

Error yang tidak tertangkap oleh boundary event mana pun tetap menghentikan prosesnya dan memunculkan incident — sama seperti sebelum fitur ini ada. Jadi salah menulis Code tidak membuat kegagalan hilang diam-diam; ia tetap terlihat.

Validasi saat deploy

Untuk integrasi yang memakai saklar Route To Error Boundary Event, engine memeriksa diagram saat deploy. Deploy ditolak, dan modal deploy di Studio menampilkan pesannya, bila:

Pesan selalu menyebut nama task dan integrasi yang bermasalah. Aturan ini berlaku untuk deploy dari Studio, unggah berkas, maupun API. Diagram yang sudah ter-deploy sebelumnya tetap berjalan seperti biasa.

Tanpa pemeriksaan ini, integrasi yang gagal pada konfigurasi di atas bisa mengakhiri proses tanpa error dan tanpa jejak.