Cara Membaca Event-Based Gateway

Event-Based Gateway adalah gateway BPMN yang menentukan jalur bukan berdasarkan kondisi data, melainkan berdasarkan kejadian (event) mana yang lebih dulu terjadi. Ini jenis gateway yang paling jarang muncul — tapi paling sering salah digambar ketika muncul.

Template Reading Grammar

[Event-Based Gateway] → "Proses menunggu salah satu dari kejadian berikut lebih dulu terjadi: {daftar event}, lalu lanjut sesuai yang terjadi"

Analoginya di pemrograman: Promise.race() di JavaScript atau select di Go — beberapa operasi asinkron berjalan bersamaan, dan yang pertama selesai itulah yang menentukan jalur berikutnya.

Diterapkan ke diagram di atas:

"Setelah Kirim Reminder, proses menunggu salah satu dari kejadian berikut lebih dulu terjadi: Balasan Diterima, atau 2 Hari Tanpa Balasan. Jika Balasan Diterima lebih dulu, lanjut ke Proses Konfirmasi. Jika 2 hari berlalu tanpa balasan, lanjut ke Eskalasi ke Sales."

Aturan yang Wajib Diperiksa Saat Membaca

1. Jalur keluar harus berupa Catching Event, bukan Task. Ini aturan paling sering dilanggar. Setiap jalur keluar dari Event-Based Gateway wajib berupa elemen yang menangkap kejadian — Message Catch Event, Timer Catch Event, atau Receive Task. Kalau ada User Task langsung setelah Event-Based Gateway, itu kesalahan: gateway ini cuma boleh menunggu, bukan mengeksekusi aktivitas.

2. Tidak ada kondisi pada flow keluar. Sama seperti Parallel Gateway, flow keluar dari Event-Based Gateway tidak dievaluasi berdasarkan kondisi data — jadi tidak boleh diberi label seperti "Jika X".

3. Label setiap jalur menggambarkan event yang dinantikan, bukan hasil keputusan. Bandingkan dengan Exclusive Gateway yang labelnya berupa "jawaban" — Event-Based Gateway labelnya berupa "kejadian yang ditunggu".

:::tip Kesalahan yang sering ditemukan Menaruh User Task langsung setelah Event-Based Gateway adalah kesalahan #6 dalam katalog 10 Kesalahan Umum BPMN. Kalau Anda menemukan pola ini saat membaca, tandai sebagai diagram yang perlu diperbaiki. :::

Analogi Sehari-hari: Menunggu di Ruang Tamu

Untuk pembaca non-teknis: bayangkan Anda menunggu kabar hasil wawancara kerja. Ada dua kemungkinan yang Anda tunggu bersamaan: telepon dari HRD (kabar datang), atau lewatnya tanggal 15 tanpa kabar (batas waktu yang mereka janjikan). Anda tidak memilih mana yang terjadi — Anda hanya menunggu, dan kejadian mana pun yang datang lebih dulu menentukan langkah Anda berikutnya: menerima tawaran, atau mulai melamar ke tempat lain.

Itulah Event-Based Gateway. Bandingkan dengan Exclusive Gateway, yang seperti memeriksa isi amplop yang sudah ada di tangan lalu memutuskan berdasarkan isinya — di Event-Based, amplopnya belum datang, dan keputusan dibuat oleh kejadian, bukan oleh Anda.

Perbedaan dengan Exclusive Gateway: Siapa yang Memutuskan

Aspek	Exclusive Gateway	Event-Based Gateway
Dasar keputusan	Kondisi data yang sudah tersedia	Kejadian yang belum terjadi
Kapan jalur ditentukan	Seketika saat token tiba	Saat salah satu event terpicu (bisa lama)
Yang mengevaluasi	Proses itu sendiri	Dunia luar (pesan masuk, waktu berlalu)
Elemen setelah gateway	Task apa pun	Wajib Catching Event / Receive Task

Salah memilih antara keduanya adalah kesalahan desain yang serius: memakai Exclusive untuk situasi menunggu berarti prosesnya akan mengevaluasi kondisi yang belum ada datanya.

Coba Sendiri

Sebuah proses pengadaan mengirim permintaan penawaran ke vendor, lalu menunggu di Event-Based Gateway dengan dua jalur: Message Catch Event "Penawaran Diterima" → "Evaluasi Penawaran", dan Timer Catch Event "7 Hari Berlalu" → "Hubungi Vendor Cadangan". Vendor mengirim penawaran di hari ke-9. Apa yang terjadi?

Lihat Jawaban

Proses sudah tidak lagi menunggu penawaran itu. Di hari ke-7, Timer Event terpicu lebih dulu — token mengambil jalur "Hubungi Vendor Cadangan", dan jalur "Penawaran Diterima" otomatis dibatalkan (semua "pendengar" lain berhenti begitu satu event menang).

Penawaran yang datang di hari ke-9 tidak akan diproses oleh instance proses ini. Kalau bisnis ingin penawaran terlambat tetap ditampung, itu harus dimodelkan eksplisit — misalnya proses terpisah, atau boundary event. Inilah nilai membaca Event-Based Gateway dengan presisi: pembaca langsung tahu nasib kejadian yang "kalah cepat".

Pertanyaan Umum

Berapa minimal jalur keluar Event-Based Gateway? Dua — sama seperti gateway lain. Dan salah satunya hampir selalu Timer, karena menunggu tanpa batas waktu adalah desain yang buruk.

Apakah jalur yang kalah bisa "menang" belakangan? Tidak. Begitu satu event terpicu, jalur lain dibatalkan permanen untuk instance proses itu. Ini beda dengan Inclusive Gateway yang bisa mengaktifkan beberapa jalur.

Kenapa tidak boleh ada Task langsung setelah gateway ini? Karena gateway ini bekerja dengan "mendengarkan" beberapa kemungkinan kejadian sekaligus — dan hanya elemen bertipe catching yang bisa mendengarkan. Task adalah pekerjaan aktif, bukan pendengar. Lihat kesalahan #6 di 10 Kesalahan Umum BPMN.

---

Lanjut ke Trace the Token, atau pelajari dasar notasinya di Event-Based Gateway.