Perjalanan order dapat melewati kanal penjualan, inventory, pembayaran, warehouse, carrier, billing, dan layanan pelanggan. Menyambungkan endpoint satu per satu belum menghasilkan proses yang andal. Workflow perlu bahasa state bersama, authority yang jelas, idempotensi, serta cara memulihkan atau merekonsiliasi langkah yang tidak dapat di-rollback.
Sertakan pula jalur pembatalan, perubahan alamat, split shipment, partial fulfillment, backorder, retur, dan koreksi. Alur ini tidak harus dibangun dalam rilis pertama, tetapi state machine tidak boleh membuatnya mustahil. Catat siapa yang boleh memulai transisi dan apakah efek sebelumnya masih dapat dikompensasi. Happy path tanpa exception catalog biasanya hanya memindahkan kompleksitas ke operator.
Bangun bahasa state yang disepakati
Istilah confirmed dapat berarti pembayaran disetujui di kanal, stok dipesan di inventory, atau order diterima warehouse. Gunakan state spesifik seperti payment_authorized, inventory_reserved, warehouse_accepted, dan shipment_dispatched. Setiap state memiliki owner, event pemicu, prasyarat, dan transisi yang diizinkan.
Jangan memaksa semua sistem menyimpan satu status global. Simpan correlation ID order dan peta status per sistem pada orchestration state atau tabel integrasi. Status komposit untuk pengguna dapat dihitung dari state yang diketahui, dengan penanda pending atau attention_required ketika bukti belum lengkap.
Tentukan authority pada setiap boundary
| Keputusan | Contoh otoritas | Bukti integrasi |
|---|---|---|
| Order diterima | Order management | Order ID dan versi |
| Pembayaran sah | Payment provider/system | Authorization reference |
| Stok tersedia | Inventory | Reservation ID dan expiry |
| Pekerjaan gudang | WMS | Fulfillment reference |
| Pengiriman | Carrier/TMS | Shipment/tracking event |
| Invoice | Billing/ERP | Invoice ID dan posting status |
Ini contoh pembagian, bukan aturan universal. Binding API, schema, status, dan peran manusia harus mengikuti implementasi aktual. Workflow mengorkestrasi keputusan yang diberikan sistem berwenang; ia tidak seharusnya mengklaim stok, pembayaran, atau pengiriman sukses hanya karena request diterima.
Rancang happy path beserta kontraknya
- Terima order.
Validasi contract nested, identity, currency, items, alamat, dan consent yang diperlukan.
- Reservasi.
Panggil layanan inventory dengan idempotency key dan simpan reservation reference.
- Otorisasi pembayaran.
Gunakan API resmi; jangan mencatat data pembayaran sensitif di workflow.
- Buat fulfillment.
Kirim order terverifikasi ke WMS dan simpan ID eksternalnya.
- Perbarui status.
Terima event lanjutan, tolak versi lama, dan proyeksikan status untuk consumer.
Urutan inventory dan payment bergantung kebijakan bisnis: reservasi dulu berisiko stok tertahan, pembayaran dulu berisiko perlu void/refund. Dokumentasikan expiry, timeout, serta pihak yang menyetujui urutan. Tidak ada sequence universal yang benar untuk semua bisnis.
Kompensasi bukan rollback sempurna
Database yang sama dapat memakai transaksi atomic. Sistem berbeda tidak berbagi transaksi itu. Saga menjalankan langkah dan kompensasi, misalnya melepas reservasi ketika pembayaran gagal. Namun void pembayaran, pembatalan gudang, atau pembatalan carrier memiliki aturan serta kemungkinan gagal sendiri. Catat compensation status dan route status yang memerlukan pemulihan manual ke operator.
- Gunakan idempotency key stabil untuk setiap aksi yang mungkin di-retry.
- Bedakan timeout dari penolakan; timeout dapat berarti tujuan sudah memproses.
- Simpan external reference sebelum melanjutkan bila diperlukan kompensasi.
- Jangan retry error validasi atau keputusan bisnis sebagai error sementara.
- Siapkan rekonsiliasi periodik untuk state yang tertinggal.
Pantau perjalanan bisnis, bukan hanya service
Dashboard teknis perlu dilengkapi ukuran bisnis: umur order pada setiap state, reservation hampir kedaluwarsa, order dibayar belum diterima WMS, shipment tanpa update, dan compensation tertunda. Correlation ID harus mengikuti order melalui seluruh workflow tanpa membawa secret atau data pribadi yang tidak perlu.
Tentukan SLA per transisi, bukan hanya endpoint. Alert warehouse_accepted terlambat harus menuju owner yang dapat bertindak. Postmortem membandingkan state aktual dengan intended state dan memperbarui runbook, test, serta boundary—bukan sekadar menambah retry.
Menyusun blueprint dengan platform integrasi visual
Command meminta sistem melakukan aksi dan dapat ditolak; event menyatakan sesuatu yang sudah terjadi. Mencampurkannya membuat retry serta ownership kabur. Beri nama node, payload, dan status sesuai peran tersebut. Untuk setiap command, simpan hasil otoritatif dari tujuan. Untuk setiap event, verifikasi source, versi, dan duplicate sebelum mengubah proyeksi. Pemisahan ini mempermudah recovery ketika respons dan event konfirmasi tiba pada waktu berbeda.
Platform integrasi visual menyediakan pemicu, kontrak nested, mapping, kondisi/cabang, Panggil API, penulisan database, variabel, deduplikasi, delay, Respons, dan Tangkap Error. Agent menghubungkan sistem privat. Untuk beberapa database, orkestrasi transaksi lintas penyimpanan menjalankan Saga dan kompensasi; aksi eksternal tetap at-least-once serta tidak atomic dengan database.
Bangun per transisi, uji timeout setelah tujuan memproses, duplicate event, response di luar urutan, kompensasi gagal, dan recovery manual di Sandbox. Lihat source of truth CRM–billing serta invoice header–item. Soft-selling yang paling jujur adalah ini: platform integrasi visual membuat orkestrasi terlihat dan dapat diuji, tetapi kewenangan serta aturan fulfillment tetap milik sistem dan tim domain.
Pembahasan ini menjelaskan pola industri umum, bukan implementasi produk tertentu. Jika tim sedang membandingkan pilihan, NitroNet dapat dimasukkan sebagai salah satu opsi evaluasi dan tetap perlu diuji dengan kebutuhan, risiko, serta kesiapan operasi organisasi.