Transaksi Ganda Bisa Berawal dari Integrasi yang Mengulang Permintaan

Transaksi Ganda Bisa Berawal dari Integrasi yang Mengulang Permintaan

Satu pesanan pelanggan masuk ke aplikasi penjualan, tetapi bagian gudang menerima dua instruksi pengiriman. Tim penjualan merasa hanya mengirim sekali. Setelah diperiksa, aplikasi ternyata mengulang permintaan karena tidak menerima konfirmasi dari sistem gudang.

Masalahnya, permintaan pertama sebenarnya sudah berhasil diproses. Ketika permintaan kedua datang, sistem menganggapnya sebagai pesanan baru.

Transaksi ganda seperti ini dapat muncul ketika integrasi menghadapi respons yang terlambat atau koneksi terputus. Jika aplikasi belum memiliki cara untuk mengenali pengiriman ulang, mekanisme yang seharusnya membantu pemulihan justru menambah pekerjaan koreksi.

Bagi perusahaan, persoalannya tidak berhenti pada dua catatan yang sama. Stok, tagihan, pengiriman, dan komunikasi kepada pelanggan dapat ikut terdampak.

Respons Tidak Diterima, Transaksi Belum Tentu Gagal

Dalam integrasi API, aplikasi mengirim permintaan kepada sistem lain, kemudian menunggu respons. Namun, pengiriman permintaan, pemrosesan transaksi, dan penerimaan respons merupakan tahapan yang berbeda.

Bayangkan aplikasi penjualan mengirim pesanan ke sistem gudang. Sistem gudang berhasil menyimpannya, tetapi koneksi terputus sebelum konfirmasi sampai. Aplikasi penjualan kemudian mengalami timeout, yaitu batas waktu menunggu respons telah terlewati.

Dari sisi aplikasi penjualan, hasilnya belum diketahui. Dari sisi gudang, pekerjaan sudah selesai.

AWS menjelaskan bahwa ketidakpastian semacam ini perlu diperhitungkan ketika aplikasi mengulang panggilan layanan. Mengirim ulang permintaan tanpa pengendalian dapat menciptakan hasil tambahan yang tidak dimaksudkan.

Karena itu, status “belum menerima respons” sebaiknya tidak langsung dianggap sebagai “transaksi gagal”. Perbedaan ini menentukan apakah aplikasi perlu memeriksa status, menunggu, atau mencoba kembali dengan identitas transaksi yang sama.

Pengulangan Permintaan Memerlukan Identitas yang Konsisten

Mengulang permintaan tetap berguna untuk menghadapi gangguan sementara. Perusahaan tentu tidak ingin setiap koneksi yang terputus harus ditangani secara manual.

Namun, sistem penerima perlu mengetahui bahwa permintaan berikutnya merupakan kelanjutan dari transaksi sebelumnya.

Prinsip ini dikenal sebagai idempotensi: permintaan yang sama dapat diterima berulang kali tanpa menggandakan dampak transaksinya. Salah satu pendekatannya adalah menggunakan identitas khusus yang tetap dipertahankan saat permintaan dikirim ulang.

Dalam contoh pesanan, sistem gudang dapat mengenali bahwa identitas tersebut sudah pernah diproses. Sistem kemudian memberikan informasi hasil sebelumnya tanpa membuat pesanan baru.

Pengenalan ini tidak cukup hanya dengan membandingkan isi pesanan. Pelanggan bisa saja membeli produk dan jumlah yang sama sebanyak dua kali secara sengaja. Kedua pembelian tersebut tetap merupakan transaksi yang sah.

Karena itu, aturan identitas transaksi perlu disepakati antara aplikasi pengirim dan penerima. Jika setiap percobaan ulang selalu mendapatkan identitas baru, sistem akan kesulitan membedakannya dari transaksi baru.

Dampaknya Meluas ke Pekerjaan Operasional

Pesanan ganda dapat membuat barang dicadangkan dua kali sehingga stok yang tersedia terlihat lebih sedikit. Jika proses terus berjalan, gudang mungkin menyiapkan dua pengiriman untuk satu pembelian.

Bagian keuangan kemudian perlu memeriksa apakah tagihan ikut terbentuk dua kali. Tim layanan pelanggan harus memastikan informasi yang diterima pelanggan sesuai dengan transaksi sebenarnya.

Pekerjaan koreksi tersebut menyita waktu yang semestinya digunakan untuk kegiatan utama. Tim juga perlu berhati-hati saat membatalkan catatan agar tidak menghapus transaksi yang sah atau meninggalkan ketidaksesuaian di aplikasi lain.

Persoalan seperti ini juga sering kami temukan ketika mendampingi proses pengembangan, integrasi, maupun modernisasi sistem pada perusahaan.

Pada sistem yang berkembang secara bertahap, aturan pengulangan terkadang berbeda di setiap integrasi. Aplikasi baru mungkin sudah mengenali transaksi berulang, sementara sistem lama masih memproses setiap permintaan sebagai pekerjaan baru. Perbedaan perilaku inilah yang perlu diperiksa sebelum integrasi diperluas.

Pencegahan Perlu Mengikuti Seluruh Alur Transaksi

Menonaktifkan tombol setelah pengguna menekan “Kirim” dapat membantu mencegah klik berulang. Namun, permintaan juga bisa dikirim kembali secara otomatis oleh komponen lain di belakang aplikasi.

Pemberitahuan antarsistem atau webhook, misalnya, dapat diterima lebih dari sekali. Dokumentasi Stripe secara khusus mengingatkan pengembang untuk menangani kejadian berulang agar tidak memprosesnya kembali tanpa pemeriksaan.

Artinya, pemeriksaan tidak cukup berhenti pada halaman yang digunakan karyawan. Perusahaan perlu mengikuti perjalanan transaksi hingga tindakan terakhir.

Pesanan mungkin hanya tercatat sekali, tetapi instruksi pengurangan stok atau pembuatan pengirimannya masih dapat berjalan berulang. Setiap tindakan yang mengubah catatan bisnis perlu memiliki pengendalian yang sesuai.

Penanganan status juga penting. Aplikasi sebaiknya menunjukkan apakah transaksi sedang diproses, sudah selesai, atau memerlukan pemeriksaan. Pesan kesalahan yang terlalu umum dapat membuat pengguna mencoba kembali tanpa mengetahui hasil sebelumnya.

Apa yang Perlu Dipertimbangkan Perusahaan?

Evaluasi dapat dimulai dari alur yang paling sering membutuhkan koreksi, seperti pesanan, perpindahan stok, atau pembuatan tagihan.

Pertama, periksa apakah identitas transaksi dapat ditelusuri dari aplikasi asal hingga sistem tujuan. Tim harus dapat menghubungkan beberapa percobaan pengiriman dengan satu transaksi bisnis.

Kedua, sepakati aturan pengulangan. Tentukan kapan sistem boleh mencoba kembali, berapa lama identitas transaksi perlu dikenali, dan kapan status harus diperiksa terlebih dahulu.

Ketiga, uji kondisi di luar alur normal. Misalnya, respons terlambat setelah transaksi tersimpan atau dua permintaan yang sama diterima hampir bersamaan. Pengujian perlu memastikan tindakan bisnis tidak dilakukan dua kali.

Keempat, siapkan rekonsiliasi untuk transaksi yang hasilnya belum jelas. Tim membutuhkan penanggung jawab dan prosedur pemeriksaan agar penyelesaian tidak bergantung pada tebakan.

Perbaikan tersebut dapat dilakukan bertahap. Pada sistem legacy, penambahan pengendalian mungkin membutuhkan penyesuaian integrasi dan pencatatan status. Biaya pengembangannya perlu dibandingkan dengan waktu koreksi, gangguan pengiriman, serta beban maintenance yang selama ini muncul.

Kesimpulan

Integrasi yang andal perlu menjaga ketepatan transaksi ketika komunikasi tidak berjalan sempurna. Permintaan yang diulang harus tetap dapat dikenali sebagai transaksi yang sama.

Dengan identitas yang konsisten, status yang jelas, dan pemeriksaan menyeluruh terhadap alur bisnis, perusahaan dapat mengurangi duplikasi serta pekerjaan manual untuk memperbaikinya.

Diskusikan Integrasi Sistem Anda bersama Rakit Sembada

Rakit Sembada membantu perusahaan mengevaluasi alur transaksi melalui layanan System & API Integration, pengembangan aplikasi custom, dan modernisasi sistem. Diskusikan kebutuhan Anda agar integrasi mendukung operasional dengan pencatatan yang lebih andal.