Lewati ke konten utama

Complex Gateway

Complex Gateway adalah gateway untuk kondisi percabangan atau penggabungan yang tidak bisa diekspresikan oleh jenis gateway manapun. Ia memberikan kebebasan penuh untuk mendefinisikan logika custom — baik untuk split maupun join.

Simbol: Belah ketupat dengan tanda * (asterisk/bintang) di tengah
Dibaca sebagai: "Berdasarkan logika kompleks yang didefinisikan secara khusus..."

:::caution Gunakan dengan Sangat Hati-Hati Complex Gateway adalah "escape hatch" dari standar BPMN — digunakan hanya ketika tidak ada gateway lain yang mampu merepresentasikan logika yang dibutuhkan. Jika Anda sering menggunakannya, kemungkinan besar ada cara yang lebih baik untuk memodelkan proses tersebut. :::

Mengapa Complex Gateway Ada?​

BPMN 2.0 dirancang untuk menjadi standar yang komprehensif, mencakup berbagai skenario proses. Namun kenyataannya, ada skenario bisnis yang logika percabangannya sangat spesifik dan tidak masuk ke dalam pola XOR, OR, atau AND.

Complex Gateway hadir sebagai solusi terakhir untuk skenario seperti:

  • "Lanjutkan jika minimal 3 dari 5 persetujuan diterima"
  • "Aktifkan jalur A dan B jika kondisi X, tapi hanya jalur C jika kondisi Y"
  • "Gabungkan ketika salah satu dari dua grup jalur selesai semua"

Cara Kerja​

Complex Gateway mendefinisikan activation condition — ekspresi yang menentukan jalur mana yang aktif (untuk split) atau kapan melanjutkan (untuk join).

Complex Split​

Logika custom yang menentukan jalur keluar mana yang diaktifkan:

Skenario: Proses Voting Komite (5 anggota)
Kondisi split: 
  → "Mayoritas setuju" (≥3 votes): aktifkan jalur Persetujuan
  → "Suara berimbang" (2-2 atau 2-3): aktifkan jalur Mediasi
  → "Mayoritas menolak" (≥3 votes): aktifkan jalur Penolakan

◈* "Hasil Voting?"
  ├─→ "≥ 3 Setuju"     → [Proses Persetujuan]
  ├─→ "Berimbang"       → [Mediasi]
  └─→ "≥ 3 Menolak"    → [Proses Penolakan]

Ini bisa dimodelkan dengan Exclusive Gateway juga, jadi Complex Gateway tidak wajib di sini. Namun ada skenario yang lebih kompleks:

Kondisi split yang benar-benar complex:
  → Jika cabang >= 3 AND nilai < 100jt: aktifkan jalur A
  → Jika cabang >= 5 OR nilai >= 100jt: aktifkan jalur A DAN B
  → Sisanya: aktifkan jalur C saja

Kombinasi AND-OR dengan jalur yang berbeda ini sulit direpresentasikan dengan gateway standar.

Complex Join​

Logika custom yang menentukan kapan melanjutkan:

Skenario: Proses Pengambilan Keputusan Multi-Departemen
Kondisi join: "Lanjutkan jika minimal 3 dari 5 departemen sudah merespons"

[Dept. Keuangan]    ──┐
[Dept. Hukum]       ──┤
[Dept. Operasional] ──┤◈* → [Eksekusi Keputusan]
[Dept. IT]          ──┤     (tidak menunggu semua 5, cukup 3)
[Dept. HR]          ──┘

Tidak ada gateway standar yang mendukung logika "n dari m" ini:

  • Parallel Join → menunggu semua 5
  • Exclusive Join → melanjutkan setelah 1
  • Inclusive Join → bisa dikonfigurasi, tapi tidak untuk "n dari m" yang dinamis

Kapan Mempertimbangkan Complex Gateway​

Sebelum menggunakan Complex Gateway, selalu tanyakan dulu: bisakah skenario ini dimodelkan dengan kombinasi gateway standar?

Coba Alternatif Ini Dulu​

Alternatif 1: Kombinasi Gateway

Logika: "Setidaknya 2 dari 3 kondisi harus terpenuhi"

Alih-alih Complex Gateway, gunakan:
◎ Inclusive Split → [Jalur A], [Jalur B], [Jalur C]
[Jalur A] ──┐
[Jalur B] ──┤◎ Inclusive Join → [Business Rule Task: Cek Apakah ≥2 Jalur Selesai] → ◇ Gateway
[Jalur C] ──┘

Alternatif 2: Business Rule Task sebelum Gateway

[Business Rule Task: Evaluasi Kompleks] → variabel: jalurAktif
    ↓
◇X Exclusive Gateway berdasarkan nilai jalurAktif
  → "A"    → [Jalur A]
  → "B"    → [Jalur B]
  → "A+B"  → ◇+ Parallel Split → [Jalur A], [Jalur B]

Dengan Business Rule Task, logika kompleks dikelola di DMN — lebih mudah diubah dan dipahami.

Alternatif 3: Script Task + Exclusive Gateway

[Script Task: Hitung Jumlah Persetujuan] → jumlahSetuju
    ↓
◇X "Mayoritas tercapai?"
  → "Ya (≥3)"  → [Lanjutkan]
  → "Tidak"    → [Proses Penolakan]

Baru Gunakan Complex Gateway Jika:​

  • Semua alternatif di atas sudah dicoba dan tidak berhasil
  • Logika benar-benar tidak bisa disederhanakan
  • Tim memiliki konvensi dan dokumentasi yang jelas tentang logika Complex Gateway tersebut

Aturan Penamaan Complex Gateway​

Karena Complex Gateway memiliki logika custom, label yang sangat deskriptif adalah wajib:

AspekRekomendasi
Label gatewayJelaskan logika keputusan secara ringkas
Sequence flow keluarLabel kondisi yang jelas
Dokumentasi tambahanWajib — gunakan Text Annotation untuk menjelaskan logika lengkap

Contoh penamaan yang baik:

◈* "≥3 dari 5 persetujuan"
     Text Annotation: "Lanjutkan jika minimal 3 anggota komite 
                       menyetujui dalam 5 hari kerja. 
                       Jika tidak tercapai → eskalasi ke Direktur."
  ├─→ "Kuorum tercapai"  → [Eksekusi Keputusan]
  └─→ "Kuorum tidak tercapai" → [Eskalasi ke Direktur]

Dukungan Tool dan BPMS​

Perlu diketahui bahwa tidak semua BPMS mendukung Complex Gateway secara penuh:

BPMSDukungan Complex Gateway
Camunda 7/8⚠️ Terbatas — tidak ada implementasi native untuk activation condition
Flowable⚠️ Terbatas
IBM BPM✅ Didukung
ARIS✅ Didukung (untuk pemodelan)

Implikasi: Jika diagram BPMN Anda akan dieksekusi di Camunda atau Flowable, hindari Complex Gateway karena mungkin tidak bisa dieksekusi secara langsung. Gunakan kombinasi gateway standar + Business Rule Task/Script Task sebagai gantinya.

Ringkasan: Urutan Prioritas Pemilihan Gateway​

Sebelum memilih Complex Gateway, coba dari yang paling sederhana:

1. Apakah tepat satu jalur aktif?
   → Exclusive Gateway ✅

2. Apakah semua jalur selalu aktif tanpa kondisi?
   → Parallel Gateway ✅

3. Apakah satu atau lebih jalur aktif berdasarkan kondisi?
   → Inclusive Gateway ✅

4. Apakah keputusan berdasarkan event yang akan terjadi?
   → Event-Based Gateway ✅

5. Tidak ada yang cocok dari atas?
   → Pertimbangkan kombinasi gateway + Business Rule Task
   → Jika masih tidak bisa → Complex Gateway (sebagai pilihan terakhir)

Selanjutnya: Aturan Penamaan dan Flow Gateway →

Diperbaharui pada