Event-Based Gateway
Event-Based Gateway adalah gateway yang unik karena jalur yang dipilih bukan berdasarkan data atau kondisi, melainkan berdasarkan event mana yang terjadi lebih dulu. Proses "bersabar" menunggu di gateway ini, dan jalur yang diambil ditentukan oleh kejadian pertama yang tiba.
Simbol: Belah ketupat dengan lingkaran ganda berisi bintang segi enam di tengah
Dibaca sebagai: "Tergantung mana yang terjadi lebih dulu..."
Nama lain: Event-Based Exclusive Gateway
Perbedaan Mendasar: Data vs. Event
Ini adalah konsep terpenting dalam memahami Event-Based Gateway:
| Aspek | Exclusive/Inclusive/Parallel | Event-Based Gateway |
|---|---|---|
| Basis keputusan | Data / variabel proses | Event yang terjadi |
| Kapan dievaluasi | Saat token tiba | Setelah menunggu event |
| Kondisi | Expression (if/then) | Tidak ada kondisi |
| Proses menunggu? | Tidak | Ya, sampai event terjadi |
Analogi perbedaannya:
-
Exclusive Gateway: "Lihat status pengiriman. Jika sudah sampai, lanjut ke penerimaan. Jika belum, lanjut ke pengingat."
→ Keputusan dibuat berdasarkan data yang sudah ada -
Event-Based Gateway: "Tunggu. Jika konfirmasi pengiriman tiba lebih dulu, lanjut ke penerimaan. Jika notifikasi penundaan tiba lebih dulu, lanjut ke penanganan penundaan."
→ Keputusan ditentukan oleh kejadian yang akan datang
Cara Kerja
Ketika token mencapai Event-Based Gateway:
- Proses berhenti dan menunggu
- Beberapa "pendengar event" diaktifkan secara bersamaan (satu per jalur)
- Event pertama yang terjadi mengaktifkan jalurnya dan menonaktifkan semua pendengar lain
- Hanya satu jalur yang akhirnya dieksekusi
◎ Timer "24 jam"
↗ → [Kirim Pengingat Pembayaran]
[Tunggu] ─── ◈ ──┤
↘ ✉ Receive "Konfirmasi Pembayaran"
→ [Proses Pesanan]
Jika pembayaran dikonfirmasi sebelum 24 jam → jalur kanan aktif.
Jika 24 jam berlalu tanpa konfirmasi → jalur timer aktif.
Elemen yang Valid Setelah Event-Based Gateway
Ini adalah aturan paling penting: Sequence Flow keluar dari Event-Based Gateway hanya boleh menuju elemen-elemen berikut:
| Elemen | Keterangan |
|---|---|
| Message Catching Event ◎✉ | Menunggu pesan dari peserta lain |
| Timer Catching Event ◎⏱ | Menunggu waktu/durasi tertentu |
| Signal Catching Event ◎△ | Menunggu sinyal disiarkan |
| Conditional Catching Event ◎☰ | Menunggu kondisi menjadi benar |
| Receive Task 📬 | Menunggu dan menerima pesan |
Tidak boleh menuju:
- Task biasa (User Task, Service Task, dll.)
- Gateway lain
- Data Object
Mengapa Demikian?
Event-Based Gateway bekerja dengan prinsip "race condition" — beberapa event diperlombakan, dan yang pertama menang. Jika ada Task biasa setelah gateway, Task tersebut tidak memiliki sifat "menunggu event" sehingga logika race condition tidak bermakna.
Aturan Penamaan Event-Based Gateway
Label Event-Based Gateway biasanya menggambarkan kondisi menunggu atau pertanyaan terhadap masa depan:
| Baik ✅ | Kurang Baik ❌ |
|---|---|
Menunggu respons... | Gateway |
Apa yang terjadi lebih dulu? | Event Gateway |
Respons vendor? | Tunggu |
| kosong (jika sudah jelas dari konteks) | Proses |
Label Sequence Flow Keluar
Label harus menggambarkan event yang ditunggu, bukan kondisi data:
◈ "Menunggu respons nasabah"
→ ◎⏱ "Dalam 3 hari kerja" → [Kirim Pengingat]
→ ◎✉ "Terima konfirmasi" → [Proses Persetujuan]
→ ◎✉ "Terima penolakan" → [Catat Penolakan]
Perhatikan bahwa label sequence flow menyebut "event" bukan "kondisi":
- ✅ "Terima konfirmasi" (menyebut event yang dinantikan)
- ❌ "Jika dikonfirmasi" (gaya kondisi data, tidak tepat untuk event-based)
Kapan Menggunakan Event-Based Gateway
Gunakan ketika:
✅ Proses harus menunggu dan tidak tahu apa yang akan terjadi — konfirmasi, penolakan, atau timeout
✅ Beberapa event berbeda bisa menentukan jalur proses, dan hanya yang pertama terjadi yang relevan
✅ Memodelkan pola request-response di mana respons bisa bermacam-macam
✅ Memodelkan timeout sebagai salah satu skenario alternatif
✅ Proses bergantung pada tindakan dari pihak eksternal yang tidak bisa dikontrol
Jangan gunakan ketika:
❌ Keputusan sudah bisa dibuat berdasarkan data yang sudah ada → Exclusive Gateway
❌ Semua kemungkinan harus diproses → Parallel Gateway
❌ Tidak ada waiting — keputusan instan → Exclusive Gateway
Pola Penggunaan yang Umum
Pola 1: Request–Response dengan Timeout
Pola paling klasik untuk Event-Based Gateway: mengirim permintaan, lalu menunggu respons atau batas waktu.
[Send Task: Kirim Penawaran ke Vendor]
↓
◈ "Respons vendor?"
├─→ ◎✉ "Terima Konfirmasi" → [Proses Purchase Order]
├─→ ◎✉ "Terima Penolakan" → [Cari Vendor Alternatif]
└─→ ◎⏱ "3 hari tanpa respons" → [Kirim Pengingat] → (kembali ke menunggu)
Pola 2: Pembayaran dengan Beberapa Skenario
[User Task: Pilih Metode Pembayaran]
↓
◈ "Status pembayaran?"
├─→ ◎✉ "Pembayaran Dikonfirmasi" → [Proses Pesanan]
├─→ ◎✉ "Pembayaran Ditolak" → [Notifikasi Gagal] → [End]
└─→ ◎⏱ "24 jam tanpa konfirmasi" → [Batalkan Pesanan] → [End]
Pola 3: Persetujuan dengan Eskalasi
[Send Task: Kirim ke Approver]
↓
◈ "Respons approver?"
├─→ ◎✉ "Disetujui" → [Proses Persetujuan]
├─→ ◎✉ "Ditolak" → [Kirim Notif Penolakan]
└─→ ◎⏱ "2 hari kerja" → [Eskalasi ke Atasan Approver]
Pola 4: Menunggu Salah Satu dari Banyak Sistem
[Service Task: Broadcast ke Semua Sistem]
↓
◈ "Sistem mana yang merespons pertama?"
├─→ ◎✉ "ACK dari Sistem A" → [Proses dengan Sistem A]
├─→ ◎✉ "ACK dari Sistem B" → [Proses dengan Sistem B]
└─→ ◎⏱ "30 detik" → [Fallback ke Sistem Default]
Event-Based Gateway vs. Exclusive Gateway: Kapan Beda?
Sering terjadi kebingungan kapan harus menggunakan salah satu dari keduanya. Gunakan panduan ini:
| Situasi | Gateway |
|---|---|
| Status pembayaran sudah ada di database, tinggal dicek | Exclusive |
| Menunggu notifikasi pembayaran dari sistem eksternal | Event-Based |
| Data persetujuan sudah tersimpan, tinggal dicek nilainya | Exclusive |
| Menunggu email persetujuan dari atasan | Event-Based |
Variabel statusKYC sudah ada nilainya | Exclusive |
| Menunggu hasil KYC dari sistem pihak ketiga yang asinkron | Event-Based |
Kunci pembedanya: Apakah informasi sudah tersedia sekarang (Exclusive), atau kita harus menunggu informasi tersebut datang dari luar (Event-Based)?
Instantiating Event-Based Gateway
Ada varian khusus Event-Based Gateway yang bisa memulai (instantiating) proses — berbeda dari Event-Based Gateway biasa yang ada di tengah proses.
Simbol: Sama, tapi dengan lingkaran tunggal (bukan ganda) di dalam belah ketupat
Cara kerjanya: Seperti beberapa Message Start Event sekaligus — proses dimulai oleh event pertama yang terjadi dari beberapa kemungkinan.
◈ (Instantiating)
├─→ ◎✉ "Terima Formulir Online" → [Proses via Online]
└─→ ◎✉ "Terima Formulir Fisik" → [Proses via Offline]
Kesalahan Umum
Menaruh Task Setelah Event-Based Gateway
❌ SALAH:
◈ → [User Task: Approve] ← Task tidak valid setelah Event-Based Gateway!
→ ◎⏱ Timer 1 hari
Solusi: Jika ingin ada task setelah event, taruh task sesudah event, bukan langsung setelah gateway.
✅ BENAR:
◈ → ◎✉ "Terima Persetujuan" → [User Task: Proses Persetujuan]
→ ◎⏱ Timer 1 hari → [Service Task: Eskalasi Otomatis]
Menggunakan Conditional Expression
Event-Based Gateway tidak memiliki condition expression pada jalurnya. Jangan tulis kondisi seperti ${status == 'APPROVE'} — kondisi ini tidak akan dievaluasi. Jalurnya ditentukan murni oleh event yang terjadi.
Selanjutnya: Complex Gateway →