Cara Membaca Message Flow
Message Flow adalah satu-satunya elemen BPMN yang boleh menyeberangi batas Pool. Fungsinya menjawab satu pertanyaan spesifik: siapa mengirim apa kepada siapa?
Template Reading Grammar
[Message Flow] → "{pool_A} mengirimkan {message} kepada {pool_B}"
Diterapkan ke diagram di atas:
"Supplier mengirimkan Invoice Pengiriman kepada Gudang. Gudang mengirimkan Konfirmasi Barang Diterima kepada Supplier."
Tiga Hal yang Wajib Diperiksa Saat Membaca Message Flow
1. Arah panah. Message Flow punya arah — dari pengirim ke penerima. Membaca arah yang terbalik akan membalik seluruh logika siapa yang menunggu siapa.
2. Elemen di kedua ujungnya. Ujung pengirim biasanya berupa Throwing Intermediate Event, End Event, atau Send Task. Ujung penerima biasanya berupa Start Event (Message), Catching Intermediate Event, atau Receive Task. Kalau salah satu ujung "tidak masuk akal" menerima/mengirim pesan (misalnya menempel ke Task biasa tanpa ikon amplop), periksa lagi — ini indikasi diagram kurang presisi.
3. Isi pesan yang jelas. Label Message Flow seharusnya menyebutkan apa yang dikirim — bukan sekadar "Kirim" atau "Data". Bandingkan "Invoice Pengiriman" (jelas) dengan "Info" (ambigu, tidak bisa diverifikasi kebenarannya oleh pembaca).
Message Flow vs Data Object
Jangan tertukar antara Message Flow (komunikasi antar Pool, garis putus-putus dengan panah kosong) dan Association ke Data Object (garis titik-titik tanpa panah solid, menghubungkan Task dengan dokumen/data yang dipakainya). Keduanya sama-sama "putus-putus" secara visual tapi maknanya berbeda total — Message Flow adalah komunikasi antar pihak, Data Object Association adalah input/output sebuah Task.
Pola Umum: Request-Response
Sebagian besar Message Flow muncul berpasangan mengikuti pola permintaan-balasan (request-response): satu pesan pergi, satu pesan kembali. Diagram di atas adalah contohnya — Invoice Pengiriman (pergi) dan Konfirmasi Barang Diterima (kembali).
Saat membaca, biasakan mencari pasangannya: "pesan ini pergi — mana balasannya?" Pesan yang pergi tanpa balasan sah-sah saja (notifikasi satu arah memang ada), tapi kalau proses pengirim menunggu sesuatu setelah mengirim (ada catching event setelah throwing), balasan itu wajib tergambar. Menunggu balasan yang tidak pernah digambarkan siapa pengirimnya adalah proses yang menggantung selamanya.
Analogi Sehari-hari: Surat-menyurat Resmi
Untuk pembaca non-teknis: Message Flow adalah surat resmi antar kantor. Tiga hal yang selalu jelas pada surat resmi juga wajib jelas pada Message Flow: pengirimnya siapa (pangkal panah), penerimanya siapa (ujung panah), dan perihalnya apa (label). Surat tanpa perihal akan diteruskan ke bagian yang salah — Message Flow tanpa label bernasib sama saat diagram diterjemahkan jadi sistem.
Coba Sendiri
Diagram dua Pool: "Toko" dan "Kurir". Dari task "Serahkan Paket" di Pool Toko ada Message Flow berlabel "Paket" ke Pool Kurir. Dari Pool Kurir ada Message Flow berlabel "Status Pengiriman" kembali ke sebuah Catching Message Event di Pool Toko, yang diikuti task "Update Status di Aplikasi". Terjemahkan seluruh interaksi ini dengan Reading Grammar.
Lihat Jawaban
"Toko mengirimkan Paket kepada Kurir. Kurir mengirimkan Status Pengiriman kepada Toko. Toko menunggu Status Pengiriman sebelum melanjutkan, lalu Toko melakukan Update Status di Aplikasi."
Perhatikan dua level yang bekerja bersama: Message Flow diterjemahkan dengan template "{pool_A} mengirimkan {message} kepada {pool_B}", dan Catching Event di ujung penerima diterjemahkan dengan template menunggu — keduanya saling melengkapi membentuk narasi yang utuh.
Pertanyaan Umum
Bolehkah satu Message Flow menuju dua penerima? Tidak — satu Message Flow selalu satu pengirim, satu penerima. Untuk siaran ke banyak penerima sekaligus, gunakan Signal Event (lihat Timer, Signal, Escalation).
Message Flow menempel ke elemen apa saja? Di sisi pengirim: Send Task, Throwing Message Event, atau tepi Pool. Di sisi penerima: Receive Task, Catching Message Event, Message Start Event, atau tepi Pool (untuk black box).
Apakah urutan beberapa Message Flow bisa dibaca dari posisinya? Tidak otomatis — urutan ditentukan oleh Sequence Flow di dalam masing-masing Pool, bukan posisi visual panah pesannya. Selalu telusuri proses internal untuk tahu pesan mana yang terjadi lebih dulu.
Lanjut ke Cara Membaca Exception dan Error Handling, atau pelajari dasar notasinya di Flow: Sequence Flow, Message Flow, dan Association.
Artikel Terkait
Sudah memahami konsep BPMN?
Wujudkan diagram Anda menjadi workflow automation nyata tanpa coding - dengan AlurKerja, platform BPM buatan Indonesia.