How To: Membuat Middleware Bridging untuk Sistem Legacy yang Andal

Integrasi ke sistem legacy jarang gagal karena kode aplikasi barunya jelek. Kegagalan lebih sering terjadi di lapisan tengah: SIMRS lama yang hanya menyediakan stored procedure 400 baris di SQL Server 2012, aplikasi penunjang dari vendor berbeda yang mengekspos SOAP tanpa dokumentasi, atau bridging BPJS VClaim yang menuntut format tanggal yyyy-MM-dd sementara database internal menyimpan dd/MM/yyyy. Middleware bridging bekerja tepat di titik itu sebagai penerjemah: menormalkan format data, mengatur timeout, mencatat jejak audit, tanpa memaksa rumah sakit mengganti sistem yang sudah berjalan dan dipakai 200+ staf setiap hari. Artikel ini membahas langkah konkret membangun middleware tersebut—dari pemetaan endpoint, pembuatan adapter layer, sampai penanganan kegagalan dengan idempotency key—dengan contoh kode Node.js yang bisa langsung dijalankan.

1. Petakan Titik Integrasi Sebelum Menulis Satu Baris Kode

Mulai dari inventarisasi, bukan dari framework. Buat spreadsheet dengan kolom: nama sistem, protokol, endpoint, metode autentikasi, format tanggal/angka, SLA yang dijanjikan vendor, dan kontak penanggung jawab. Pada satu proyek SIMRS di rumah sakit tipe C dengan 180 tempat tidur, inventarisasi awal menemukan 7 sistem terhubung dengan 23 endpoint, dan 4 di antaranya sama sekali tidak berdokumentasi—termasuk endpoint laboratorium yang hanya "diwariskan" lewat file WSDL lama.

Jangan percaya dokumentasi 100%. Uji setiap endpoint dengan Postman atau curl, simpan contoh response asli ke folder fixtures/, lalu jadikan itu bahan unit test. Pengalaman umum: field NAMA_PASIEN yang di dokumen disebut wajib ternyata bisa null pada pasien bayi baru lahir, dan TGL_LAHIR pada satu instalasi berisi string kosong, bukan tanggal default.

Setelah peta selesai, definisikan satu kontrak internal—model kanonik dalam JSON—yang menjadi "bahasa netral" seluruh middleware. Semua adapter wajib mengembalikan bentuk yang sama: { noRm, nama, tglLahir, nik }. Gunakan FHIR R4 (Patient, Encounter, Observation) sebagai referensi penamaan field, karena bila nanti rumah sakit perlu bridging SatuSehat, pemetaan ulang jauh lebih murah.

Satu aturan besi: middleware tidak boleh menulis langsung ke database legacy. Semua akses lewat API atau stored procedure yang disetujui vendor, atau paling jauh read-only view. Ini menjaga garansi dukungan vendor tetap berlaku dan mencegah insiden yang sulit dilacak saat audit.

2. Bangun Adapter Layer dengan Node.js 20, Fastify 4.28, dan Undici

Untuk middleware yang menangani 1.200–3.000 request per hari, Node.js 20 LTS dengan Fastify 4.28 sudah lebih dari cukup: throughput tinggi, ekosistem library matang, dan mudah di-deploy sebagai container. Untuk HTTP client gunakan undici 6.19 (bukan axios) karena mendukung AbortController native dan overhead-nya kecil; untuk validasi payload gunakan zod 3.23 agar kontrak internal benar-benar ditegakkan di runtime.

Terapkan pola adapter: satu file per sistem, satu fungsi per operasi domain. Fungsi adapter hanya bertanggung jawab memanggil endpoint legacy, menerjemahkan field, dan melempar error bertipe. Semua logika bisnis tetap di service layer, sehingga ketika vendor SIMRS mengganti endpoint, Anda hanya menyentuh satu file.

// adapters/simrs.adapter.js — Node.js 20, undici 6.19
import { request } from 'undici';

export async function getPasienByRm(noRm, { timeoutMs = 3000 } = {}) {
  const ctrl = new AbortController();
  const timer = setTimeout(() => ctrl.abort(), timeoutMs);
  try {
    const res = await request(`http://10.10.10.21:8081/api/pasien/${noRm}`, {
      signal: ctrl.signal,
      headers: { 'X-Api-Key': process.env.SIMRS_KEY }
    });
    if (res.statusCode === 404) return null;
    if (res.statusCode >= 500) throw new Error(`SIMRS_5XX_${res.statusCode}`);
    const raw = await res.body.json();
    return { noRm: raw.NO_RM, nama: raw.NAMA_PASIEN, tglLahir: raw.TGL_LAHIR, nik: raw.NIK };
  } finally { clearTimeout(timer); }
}

Setelah adapter berjalan, ukur sebelum menambah fitur. Pada implementasi nyata, endpoint pasien SIMRS merespons 6–9 detik pada jam sibuk (08.00–11.00) karena stored procedure melakukan join ke 5 tabel. Dengan menambahkan cache Redis 7.2 selama 300 detik khusus data master (poli, dokter, ICD-10), panggilan ke SIMRS turun 78% dan p95 endpoint internal turun dari 8.400 ms ke 420 ms.

3. Tangani Kegagalan: Retry, Idempotensi, dan Audit Trail

Asumsikan jaringan dan sistem legacy akan gagal. Terapkan retry dengan exponential backoff 200 ms, 400 ms, lalu 800 ms plus jitter, maksimal 3 percobaan, dan hanya untuk status 5xx, timeout, atau ECONNRESET. Jangan pernah me-retry error 400/422—payload yang salah tidak akan berubah hasilnya, dan pada kasus pendaftaran kunjungan retry seperti itu justru membuat data ganda.

Untuk semua operasi POST, wajibkan header Idempotency-Key berisi UUID v4, simpan di tabel PostgreSQL 16 dengan unique index dan TTL 24 jam. Tanpa ini, satu double-click pada form pendaftaran pernah menghasilkan dua nomor SEP di BPJS dan harus dibatalkan manual oleh petugas—insiden yang bisa dihindari dengan 20 baris kode.

Untuk sinkronisasi yang tidak butuh jawaban langsung (kirim laporan ke SatuSehat, update stok ke ERP), gunakan outbox pattern: tulis event ke tabel outbox dalam transaksi yang sama, lalu worker BullMQ 5.x memprosesnya secara async dengan retry sendiri. UI tidak perlu menunggu 9 detik; pengguna mendapat respons di bawah 300 ms.

Lengkapi dengan circuit breaker (opossum 8.x): bila 50% request gagal dalam window 10 detik, breaker terbuka selama 30 detik agar sistem legacy tidak makin tenggelam. Semua request dan error dicatat lewat pino sebagai structured log ke Loki dengan retensi 90 hari—ini penting karena rekam medis elektronik wajib punya jejak audit yang bisa ditelusuri.

Best Practices

1. Kontrak dulu, kode kemudian. Tulis skema JSON/zod dan contoh payload di repositori sebelum implementasi; semua adapter mengikuti skema itu, bukan sebaliknya.
2. Selalu set timeout eksplisit. Default tanpa timeout akan menggantung request sampai load balancer memutus koneksi dan menyisakan worker menggantung.
3. Idempotensi untuk setiap POST. Simpan idempotency key minimal 24 jam; ini pertahanan termurah terhadap data ganda di SIMRS maupun klaim BPJS.
4. Simpan kredensial di secret manager (Vault, AWS Secrets Manager, atau minimal environment variable terenkripsi), bukan di repositori atau file konfigurasi yang dibagikan lewat chat.
5. Sediakan mock server untuk pengujian. Rekam response asli menjadi fixture, sehingga pengujian bisa berjalan tanpa menyentuh sistem produksi rumah sakit.

FAQ

Apakah middleware bridging wajib dibuat dengan Node.js?

Tidak. Node.js 20 + Fastify cocok untuk tim yang terbiasa JavaScript dan butuh I/O concurrency tinggi. Jika tim Anda kuat di PHP, Laravel 11 dengan Guzzle dan Horizon juga sangat layak; kuncinya bukan bahasa, melainkan disiplin adapter, timeout, idempotensi, dan logging.

Bagaimana jika vendor SIMRS menolak memberikan akses API?

Ajukan permintaan tertulis dengan spesifikasi endpoint yang dibutuhkan, tawarkan opsi read-only view atau stored procedure yang disetujui vendor, dan siapkan opsi jangka panjang berupa RFP penggantian sistem. Middleware tidak dirancang untuk menembus batasan lisensi—itu risiko hukum dan operasional.

Berapa lama waktu pembuatan middleware seperti ini?

Untuk 5–10 endpoint dengan dua sistem legacy, tahap pemetaan 3–5 hari kerja dan implementasi 2–3 minggu, sudah termasuk pengujian dan observability. Bridging BPJS VClaim atau SatuSehat yang melibatkan validasi dan antrean klaim biasanya 4–6 minggu.

Apakah middleware akan memperlambat sistem?

Justru sebaliknya bila diukur. Lapisan tambahan memang menambah 5–20 ms, tetapi caching, parallel call, dan pemanggilan async ke layanan lambat memangkas waktu tunggu dari detik menjadi ratusan milidetik. Kuncinya adalah profiling sejak awal, bukan menebak.

Membangun middleware bridging yang andal bukan soal memilih framework paling baru, tetapi soal disiplin memetakan kontrak, mengukur latency, dan menangani kegagalan secara eksplisit. Dengan adapter layer yang tipis, timeout yang jelas, idempotensi pada setiap POST, serta circuit breaker dan audit trail yang rapi, sistem legacy tetap bisa dipertahankan sambil membuka jalan ke BPJS VClaim, SatuSehat FHIR, ERP, dan POS modern. Jika tim IT Anda sedang menyiapkan bridging untuk SIMRS, SIM Klinik, ERP, atau website dan membutuhkan pendampingan teknis, layanan konsultasi IT dan pengembangan aplikasi kami mencakup wilayah Yogyakarta, DIY, dan Magelang. Diskusikan arsitektur Anda lebih awal agar implementasi tidak menebak-nebak di produksi.

Artikel ini bagian dari edukasi Nugroho Setiawan, konsultan IT Jogja. Solusi terkait: SIMRS Integrator Bridging BPJS & SatuSehat. Butuh konsultasi gratis?