Lewati ke konten utama

Inclusive Gateway (OR)

Inclusive Gateway adalah gateway yang memungkinkan satu atau lebih jalur untuk aktif secara bersamaan — bergantung pada kondisi yang dievaluasi. Ini adalah "saudara" dari Exclusive Gateway, namun lebih fleksibel: daripada "tepat satu", ia bekerja dengan prinsip "satu atau lebih".

Simbol: Belah ketupat dengan lingkaran di tengah
Dibaca sebagai: "Satu atau lebih dari..." / "Semua yang memenuhi syarat..."
Nama lain: OR Gateway, Inclusive OR Gateway

Cara Kerja​

Inclusive Split (Diverging / Percabangan)​

Engine mengevaluasi semua kondisi pada jalur keluar. Setiap jalur yang kondisinya true diaktifkan. Bisa jadi satu jalur aktif, bisa beberapa, bisa semua.

                    [Verifikasi Identitas]
                   ↗ (jika pelanggan baru)
[Cek Status] ─────◎─→ [Verifikasi Alamat]
                   ↘ (jika pinjaman > 100jt)
                    [Verifikasi Aset]
                      (selalu)

Untuk pelanggan lama dengan pinjaman kecil: hanya "Verifikasi Aset" aktif.
Untuk pelanggan baru dengan pinjaman besar: ketiga jalur aktif bersamaan.

Inclusive Join (Converging / Penggabungan)​

Ini adalah bagian yang paling penting dan sering disalahpahami:

Inclusive Join menunggu semua jalur yang aktif selesai — bukan semua jalur yang secara fisik masuk ke gateway.

Engine "mengingat" jalur mana saja yang diaktifkan oleh Inclusive Split yang berpasangan. Hanya jalur-jalur aktif itu yang ditunggu.

[Verifikasi Identitas] ──┐
[Verifikasi Alamat]   ──┤◎──→ [Lanjutkan Proses]
[Verifikasi Aset]     ──┘

Jika hanya "Verifikasi Identitas" dan "Verifikasi Aset" yang aktif, Join menunggu keduanya — tidak menunggu "Verifikasi Alamat" yang memang tidak diaktifkan.

Token Semantics: Mengapa Ini Penting​

Dalam BPMN, "token" adalah representasi dari satu thread eksekusi yang mengalir melalui proses. Memahami token membantu menjelaskan perilaku Inclusive Gateway:

Pada Inclusive Split:

  • Jika 2 dari 3 jalur aktif → 2 token dibuat dan mengalir di kedua jalur
  • Token mengalir secara paralel

Pada Inclusive Join:

  • Menunggu semua token yang "berasal dari split yang sama" untuk kembali
  • Ini membutuhkan engine untuk melacak "konteks" token — dari split mana ia berasal

Implikasi: Inclusive Join harus selalu dipasangkan dengan Inclusive Split yang jelas. Tanpa pasangan yang jelas, engine tidak bisa menentukan berapa token yang harus ditunggu.

Aturan Penamaan Inclusive Gateway​

Label Gateway (Split)​

Format yang direkomendasikan sama dengan Exclusive Gateway — berupa pertanyaan atau kondisi:

Baik ✅Kurang Baik ❌
Verifikasi apa yang diperlukan?OR Gateway
Notifikasi mana yang dikirim?Gateway 3
Layanan tambahan yang berlaku?Pilih layanan

Label Sequence Flow Keluar​

Setiap jalur keluar harus memiliki label kondisi yang jelas. Karena lebih dari satu bisa aktif, label kondisi harus bisa berdiri sendiri (tidak harus pilihan biner ya/tidak):

Gateway: "Jenis verifikasi yang diperlukan?"
  → "Pelanggan baru"           → [Verifikasi Identitas]    kondisi: ${pelangganBaru == true}
  → "Pinjaman > Rp 100 juta"   → [Verifikasi Aset]         kondisi: ${nilaiPinjaman > 100000000}
  → "Riwayat kredit bermasalah"→ [Verifikasi Referensi]    kondisi: ${adaCatatan == true}
  → "Standar" (default)        → [Verifikasi Dasar]

Kapan Menggunakan Inclusive Gateway​

Gunakan Inclusive Gateway ketika:

✅ Beberapa kondisi bisa true sekaligus dan setiap jalur harus dieksekusi
✅ Setiap kombinasi jalur mungkin terjadi (tidak diketahui berapa jalur yang aktif)
✅ Pekerjaan yang saling tidak bergantung, tapi kondisinya tidak mutually exclusive

Contoh skenario yang tepat:

  • Menentukan jenis verifikasi yang diperlukan berdasarkan profil risiko
  • Memilih saluran notifikasi (email + SMS + push notification, tergantung preferensi)
  • Menentukan dokumen yang harus disiapkan berdasarkan jenis permohonan

Jangan gunakan ketika:

❌ Hanya satu jalur yang bisa aktif → pakai Exclusive Gateway
❌ Semua jalur selalu aktif → pakai Parallel Gateway (lebih sederhana)
❌ Hanya ada satu kondisi yang menentukan satu jalur → pertimbangkan apakah gateway diperlukan sama sekali

Inclusive vs. Exclusive: Panduan Memilih​

PertanyaanJawabanGateway
Bisakah lebih dari satu kondisi bernilai true pada waktu yang sama?YaInclusive
Bisakah lebih dari satu kondisi bernilai true pada waktu yang sama?TidakExclusive
Apakah kondisi saling eksklusif secara bisnis?YaExclusive
Apakah kondisi saling eksklusif secara bisnis?TidakInclusive

Tes sederhana: Ambil dua kondisi mana pun dari jalur-jalur yang ada. Bisakah keduanya benar secara bersamaan? Jika ya → Inclusive Gateway.

Inclusive vs. Parallel: Kapan Lebih Tepat​

AspekInclusive GatewayParallel Gateway
Semua jalur selalu aktif?Tidak tentuSelalu
Ada kondisi pada jalur keluar?YaTidak
Jumlah jalur aktif bisa berbeda-beda?YaTidak (selalu semua)

Jika semua jalur selalu harus dieksekusi tanpa kondisi → gunakan Parallel Gateway.
Parallel Gateway lebih sederhana dan lebih mudah dipahami. Inclusive Gateway hanya ketika ada variasi.

Kesalahan Paling Umum​

Kesalahan 1: Tidak Memasangkan Split dan Join dengan Jenis yang Sama​

❌ SALAH:
◎ Inclusive Split → [Task A], [Task B], [Task C]
         ...
◇X Exclusive Join ← [Task A], [Task B], [Task C]

Exclusive Join tidak menunggu semua jalur aktif — ia akan memproses setiap token yang tiba, sehingga langkah berikutnya bisa dieksekusi 1, 2, atau 3 kali.

✅ BENAR:
◎ Inclusive Split → [Task A], [Task B], [Task C]
         ...
◎ Inclusive Join ← [Task A], [Task B], [Task C]

Kesalahan 2: Semua Kondisi Bisa Benar Sekaligus, Tapi Pakai Exclusive​

Ini menyebabkan hanya satu jalur yang dieksekusi padahal seharusnya lebih dari satu:

❌ SALAH: Exclusive Gateway
Gateway: "Kanal notifikasi?"
  → "Via Email"   (kondisi: ${prefEmail})
  → "Via SMS"     (kondisi: ${prefSMS})
  → "Via WA"      (kondisi: ${prefWA})

Jika pengguna ingin notifikasi via Email DAN SMS, hanya Email yang akan dikirim (kondisi pertama yang true).

✅ BENAR: Inclusive Gateway
◎ Gateway: "Kanal notifikasi yang diinginkan?"
  → "Via Email"   (kondisi: ${prefEmail})
  → "Via SMS"     (kondisi: ${prefSMS})
  → "Via WA"      (kondisi: ${prefWA})

Kesalahan 3: Inclusive Join Tanpa Inclusive Split yang Jelas​

❌ MASALAH:
[Task A] ──────────────────┐
                           ◎ Join
[Task B yang mungkin skip]─┘

Jika Task B bisa di-skip (karena suatu kondisi), engine mungkin tidak tahu apakah harus menunggu Task B atau tidak. Selalu pastikan ada Inclusive Split yang jelas sebagai pasangan.

Kesalahan 4: Tidak Ada Default Flow​

Jika semua kondisi bisa bernilai false sekaligus (misalnya tidak ada verifikasi yang diperlukan), proses akan dead end. Selalu beri jalur default.

Contoh Lengkap: Proses Onboarding Nasabah Premium​

[Start: Daftar sebagai Nasabah Premium]
    ↓
[Service Task: Tentukan Layanan yang Berlaku]
    ↓
◎ "Fasilitas tambahan yang diberikan?"
  ├─ "Nasabah baru di segmen ini" → [User Task: Setup Private Banker]
  ├─ "Saldo > Rp 1 Miliar"        → [Service Task: Aktivasi Wealth Management]
  ├─ "Usia > 55 tahun"            → [Service Task: Aktivasi Layanan Estate Planning]
  └─ "Standar" (default)          → [Service Task: Aktivasi Fitur Dasar]
    ↓ (semua jalur aktif mengarah ke sini)
◎ Inclusive Join
    ↓
[Send Task: Kirim Selamat Datang Nasabah Premium]
    ↓
[End]

Untuk nasabah baru berusia 60 tahun dengan saldo Rp 2 miliar: keempat jalur aktif semua.
Untuk nasabah pindahan berusia 40 tahun dengan saldo Rp 500 juta: hanya jalur default yang aktif.

Selanjutnya: Parallel Gateway →

Diperbaharui pada