Lokasi: Management → API & Integrations (grup Admin) → Webhooks untuk sisi OpexMX. Flow-nya sendiri dibangun dan dijalankan di OpexFlow.
Pekerjaan pemeliharaan menghasilkan dokumen SAP: suku cadang yang dikeluarkan untuk work order, serta tenaga kerja dan biaya yang dikonfirmasi saat order ditutup. Halaman ini menjelaskan jalur yang membawa posting tersebut dari OpexMX ke SAP agar setiap posting dikonfirmasi oleh SAP atau terlihat sebagai item terbuka.
Status halaman ini
Jalur ini diuji terhadap middleware SAP simulasi, bukan sistem SAP yang hidup. Nomor dokumen dalam uji bukan dokumen SAP yang nyata, dan email peringatan dikirim ke mailbox uji. Bukti terekam adalah studi kasus OpexFlow OpexMX to SAP: confirmed delivery for every posting.
Pemetaan field, jenis dokumen, dan antarmuka SAP (REST middleware, IDoc, atau BAPI) diatur per instalasi.
Komponen
| Komponen | Peran |
|---|---|
| OpexMX | Memunculkan event dan mengirimnya sebagai webhook bertanda tangan. Menerima kembali nomor dokumen SAP |
| OpexFlow | Memeriksa, membuang duplikat, memetakan, dan mengirim event, menyimpan catatan kedua sisi, dan menandai apa yang tidak sampai |
| Middleware SAP | Antarmuka di depan SAP yang menerima posting dan menjawab dengan nomor dokumen atau penolakan |
Flow
OpexMX mengirim webhook bertanda tangan untuk setiap event posting. Satu flow di OpexFlow berada di antara OpexMX dan middleware SAP dan menjalankan langkah berikut secara berurutan:
- Webhook bertanda tangan. Request membawa id event dan tanda tangan. Request yang gagal pemeriksaan tanda tangan ditolak dengan
401dan tidak pernah masuk ke flow. - Dedupe pada id event. Setiap id event diterima sekali. Pengiriman ulang id event yang sama dikenali dan dibuang, sehingga SAP tidak diposting dua kali.
- Map. Event dipetakan ke payload SAP. Dalam uji: goods issue (movement type 261) atau konfirmasi order PM.
- Ledger, sisi OpexMX. Event ditulis ke ledger di sisi OpexMX.
- POST ke middleware SAP. Payload dikirim dengan header
Idempotency-Key. - Ledger, sisi SAP. Jawaban SAP ditulis ke ledger di sisi SAP.
- Write-back. Nomor dokumen SAP dikembalikan ke OpexMX, yang menyimpannya pada transaksi.
- Reconcile. Node terjadwal membandingkan kedua ledger.
Apa yang dikirim OpexMX
Pengirim webhook OpexMX, sebagaimana diimplementasikan dalam kode produk:
- mengirim
POSTdengan body JSON yang berisi id event unik, jenis event, tenant, dan data record - menandatangani request. Header
X-Webhook-Signatureberisi timestamp dan HMAC-SHA256 dari timestamp dan body, dibuat dengan secret webhook.X-Webhook-Id,X-Webhook-Timestamp, danX-Webhook-Eventjuga dikirim - berlangganan per tenant berdasarkan jenis event, dengan wildcard seperti
work_order.* - timeout setelah 30 detik dan menulis setiap percobaan ke delivery log
- menampilkan kesehatan webhook dari 10 pengiriman terakhir: healthy pada keberhasilan 80% atau lebih, degraded pada 50% atau lebih, selain itu failing
Saat SAP menolak atau tidak tersedia
| Kasus | Yang terjadi |
|---|---|
| SAP menerima posting | Jawabannya 201. Nomor dokumen masuk ke ledger dan dikembalikan ke OpexMX |
| Event yang sama dikirim lagi | Dikenali dari id event-nya. Tidak ada posting kedua |
| Tanda tangan salah | Ditolak di pintu dengan 401. Tidak ada yang sampai ke SAP |
| SAP menolak posting (jawaban 4xx) | Record disimpan di Dead letters beserta payload asli dan pesan SAP. Email dikirim ke mailbox operasi. Seseorang dapat memperbaiki record lalu memutarnya ulang |
| SAP tidak tersedia (jawaban 5xx) | OpexFlow menjawab OpexMX dengan 503 agar pengiriman dapat di-retry. Tidak masuk ke Dead letters |
Kedua jenis kegagalan sengaja diperlakukan berbeda. Penolakan seperti cost center yang diblokir akan gagal lagi kecuali seseorang mengubah record, jadi record disimpan untuk ditangani orang. Gangguan bersifat sementara, jadi pengiriman di-retry.
Dead letter, perbaiki dan replay
Posting yang ditolak tidak hilang dan tidak menghalangi yang lain. Ia tersimpan di Dead letters bersama record persis seperti yang dikirim dan teks error SAP. Seseorang mengedit payload dan memutarnya ulang ke flow. Setiap tindakan tercatat atas nama login mereka.
Dalam uji, SAP menjawab 422 dengan pesan "KI235 cost center blocked". Record disimpan, dan email peringatan menyebutkan work order, plant, cost center, jumlah, dan error SAP.
Reconcile malam hari
Pada pukul 01:00 node reconcile membandingkan ledger OpexMX dengan ledger SAP berdasarkan id event. Selisih menjadi kasus pengecualian dengan status, penanggung jawab, dan riwayat. Ia ditangani, bukan sekadar dibaca: tugaskan, selidiki, lalu selesaikan sebagai cocok, koreksi diposting, atau dihapuskan.
Dalam run uji, OpexMX memiliki 5 event dan SAP memiliki 4. Empat cocok. Satu selisihnya adalah posting yang ditolak, sehingga dead letter dan reconcile sepakat.
Reconcile memberi pandangan kedua yang independen untuk setiap posting. Posting yang diterima middleware tetapi tidak pernah sampai ke SAP, atau yang tidak pernah keluar dari OpexMX, terlihat di sini meskipun tidak ada error yang muncul di sepanjang jalan.
Health dan SLA
Tampilan Health and SLA mendaftar setiap panggilan eksternal yang dibuat flow, dengan jumlah panggilan, error, retry, dan latensi. Pada jendela uji, panggilan ke SAP tercatat 7 panggilan, 3 error, dan 2 retry, sesuai dengan satu penolakan dan dua jawaban 503.
Cakupan dan hal yang masih terbuka
- Diuji terhadap middleware SAP simulasi. Tidak ada sistem SAP yang hidup dipakai.
- Dalam uji, retry setelah
503dilakukan oleh sisi pengirim. Pengirim webhook OpexMX dalam kode produk saat ini mencoba lagi setelah error jaringan atau timeout (default 3 percobaan, jeda 60 detik lalu 120 detik) dan mencatat respons tidak sukses sebagai pengiriman gagal tanpa mengirimnya lagi. Pastikan perilaku retry pengirim untuk versi OpexMX Anda sebelum mengandalkan pemulihan dari503. - Write-back nomor dokumen SAP menuju endpoint di sisi OpexMX. Dalam uji, endpoint itu berupa stand-in. Cara nomor disimpan pada transaksi diatur per instalasi.
- Email peringatan dikirim lewat SMTP ke mailbox operasi yang Anda konfigurasikan.
Sinkronisasi SAP native
OpexMX juga memiliki engine sinkronisasi bawaan untuk SAP ECC 6 (tipe integrasi sap_ecc6). Modelnya sama dengan sinkronisasi Epicor: run terjadwal, watermark per entitas dan arah, serta dead letter dengan replay. Cakupannya work order, aset, suku cadang (material), dan purchase order. Ini jalur yang berbeda dari jalur di halaman ini. Ia memindahkan data master dan transaksional sesuai jadwal, sedangkan flow di halaman ini membuktikan pengiriman posting satu per satu.