Cara Membaca Inclusive Gateway (OR)

Inclusive Gateway (OR) adalah gateway BPMN yang mengizinkan satu atau lebih jalur aktif sekaligus, sesuai kondisi mana saja yang terpenuhi. Dari semua jenis gateway, inilah yang paling sering disalahpahami — bahkan oleh pembuat diagram berpengalaman. Penyebabnya: Inclusive terlihat seperti gabungan Exclusive dan Parallel, padahal punya aturan bacanya sendiri.

Template Reading Grammar

Split:

[Inclusive Gateway, split] → "Bergantung kondisi yang terpenuhi, dilakukan satu atau lebih dari: {daftar jalur}"

Join:

[Inclusive Gateway, join] → "Setelah semua jalur yang aktif selesai (bisa satu atau lebih), maka {next}"

Diagram di atas dibaca:

"Setelah Evaluasi Klaim, bergantung jenis kerusakan yang ditemukan, dilakukan satu atau lebih dari: Klaim Servis Mesin, Klaim Servis Body, atau Klaim Servis Interior. Setelah semua klaim yang diajukan selesai diproses, maka proses berlanjut."

Perbedaan Kunci dengan Exclusive dan Parallel

Aspek	Exclusive (XOR)	Inclusive (OR)	Parallel (AND)
Jalur yang bisa aktif	Tepat satu	Satu atau lebih	Semua
Kondisi pada flow keluar	Wajib	Wajib	Dilarang
Join menunggu	Jalur yang aktif saja (1)	Semua jalur yang aktif (jumlahnya dinamis)	Semua jalur (tetap)

Baris terakhir inilah sumber kesalahan paling umum. Join dari Inclusive Gateway tidak tahu di awal berapa banyak jalur yang akan aktif — bisa satu klaim, bisa tiga klaim sekaligus. Ia harus menunggu persis sejumlah jalur yang benar-benar berjalan, bukan menunggu semua jalur yang ada di diagram (itu perilaku Parallel) dan bukan pula berhenti begitu satu jalur masuk (itu perilaku Exclusive).

Kenapa Ini Bagian Tersulit

Saat men-trace token pada Inclusive Gateway, Anda tidak bisa menjawab dengan satu token saja — Anda perlu membayangkan beberapa token sekaligus, sejumlah kondisi yang terpenuhi, lalu memastikan join menunggu token-token itu dengan tepat.

Kesalahan paling sering: diagram memakai Inclusive Split tapi join-nya digambar sebagai Exclusive Join (berhenti begitu token pertama tiba). Kalau ini terjadi di sistem nyata, klaim kedua dan ketiga yang harusnya diproses akan hilang karena join sudah lanjut duluan saat klaim pertama masuk.

:::tip Kapan sebenarnya butuh Inclusive? Kalau setelah dicoba dibaca ternyata kondisi-kondisinya selalu saling lepas (tidak mungkin dua kondisi benar bersamaan), gateway itu sebenarnya Exclusive, bukan Inclusive — ganti jenisnya. Inclusive hanya dibutuhkan kalau kombinasi kondisi memang mungkin terjadi bersamaan. :::

Analogi Sehari-hari: Formulir dengan Centang Ganda

Untuk pembaca non-teknis, bayangkan formulir pendaftaran seminar dengan pertanyaan: "Fasilitas apa yang Anda butuhkan? (boleh pilih lebih dari satu)" — dengan pilihan: penjemputan bandara, penginapan, dan konsumsi khusus. Peserta bisa mencentang satu, dua, atau ketiganya, sesuai kebutuhannya.

Panitia lalu memproses hanya yang dicentang — dan acara baru dianggap siap untuk peserta itu setelah semua yang dicentang selesai diurus. Panitia tidak menunggu urusan penginapan untuk peserta yang tidak mencentang penginapan; tapi juga tidak boleh bilang "siap" kalau penjemputan yang dicentang belum diatur. Persis begitulah Inclusive Gateway bekerja: split mengaktifkan jalur sesuai kondisi yang terpenuhi, join menunggu tepat sejumlah jalur yang aktif.

Menelusuri Token Selangkah demi Selangkah

Pakai contoh klaim asuransi pada diagram di atas, misalkan kerusakan yang ditemukan adalah mesin dan body (dua dari tiga kondisi):

1. Token tiba di Inclusive Split "Jenis Kerusakan?"
2. Kondisi "Mesin" terpenuhi → token pertama berjalan ke "Klaim Servis Mesin"
3. Kondisi "Body" terpenuhi → token kedua berjalan ke "Klaim Servis Body"
4. Kondisi "Interior" tidak terpenuhi → jalur itu tidak menghasilkan token sama sekali
5. Inclusive Join tahu ada dua token aktif — ia menunggu keduanya, tidak kurang, tidak lebih
6. Klaim Servis Body selesai duluan → join belum meneruskan, masih menunggu satu lagi
7. Klaim Servis Mesin selesai → kedua token lengkap, join meneruskan satu token ke elemen berikutnya

Langkah 5 inilah keistimewaan (sekaligus kerumitan) Inclusive Join: jumlah yang ditunggu dinamis, ditentukan saat split terjadi — bukan angka tetap seperti Parallel Join.

Coba Sendiri

Sebuah proses promo e-commerce punya Inclusive Gateway "Voucher yang Berlaku?" dengan tiga jalur: "Gratis Ongkir", "Cashback", dan "Diskon Member". Seorang pembeli memenuhi syarat gratis ongkir dan diskon member, tapi tidak cashback. Jalur mana saja yang aktif, dan kapan proses boleh lanjut ke "Terbitkan Invoice"?

Lihat Jawaban

Dua jalur aktif: "Gratis Ongkir" dan "Diskon Member". Jalur "Cashback" tidak menghasilkan token. Proses boleh lanjut ke "Terbitkan Invoice" setelah kedua jalur yang aktif itu selesai diproses — Inclusive Join tidak menunggu jalur Cashback yang memang tidak pernah aktif.

Dibaca dengan Reading Grammar: "Bergantung voucher yang berlaku, dilakukan satu atau lebih dari: proses Gratis Ongkir, proses Cashback, atau proses Diskon Member. Setelah semua jalur yang aktif selesai, maka Terbitkan Invoice."

Pertanyaan Umum

Kapan harus pakai Inclusive, bukan beberapa Exclusive berturut-turut? Kalau kondisi-kondisinya independen dan pekerjaannya bisa berjalan bersamaan, Inclusive lebih tepat dan lebih ringkas. Rangkaian Exclusive berturut-turut memaksa pengecekan berurutan — pekerjaan kedua baru mulai setelah yang pertama selesai.

Apa yang terjadi kalau tidak ada satu pun kondisi Inclusive yang terpenuhi? Sama seperti Exclusive: proses macet, kecuali ada Default Flow. Inclusive Gateway yang kondisinya bisa semua-salah wajib punya Default Flow.

Kenapa banyak praktisi menghindari Inclusive Gateway? Karena perilaku join-nya yang dinamis sulit dipahami pembaca awam dan sulit diimplementasikan sebagian mesin BPMS lama. Sebagian pemodel memilih kombinasi Parallel + Exclusive yang lebih verbose tapi lebih eksplisit. Keduanya sah — yang penting pembaca bisa menerjemahkannya dengan bersih.

---

Lanjut ke Cara Membaca Event-Based Gateway, atau pelajari dasar notasinya di Inclusive Gateway.