إعادة محاولة Webhooks و Idempotency لقرارات المخاطر
كيف تستقبل Webhooks المخاطر من نيزا بأمان، وتعيد محاولة التسليم الفاشل، وتتجنب تكرار تحديثات الحالات في سير عمل الاحتيال و AML.
تسليم Webhooks هو المكان الذي تتحول فيه قرارات الاحتيال إلى عمل تشغيلي. يجب أن يقبل التكامل النظيف كل إشعار بسرعة، ويتحقق منه، ويضعه في الطابور، ويجعل كل تحديث لاحق idempotent حتى لا تنشئ إعادة المحاولة حالات مكررة أو حالات عميل متعارضة.
الاستقبال بسرعة
تعامل مع endpoint الخاص بالـ webhook كطبقة استقبال خفيفة. تحقق من التوقيع، واحفظ payload الحدث، وأعد استجابة نجاح بعد وضع الرسالة في الطابور بأمان. إنشاء الحالات الطويل، وإشعار العميل، والتوجيه الداخلي يجب أن يحدث خارج طلب HTTP.
POST /webhooks/naiza/riskاجعل التحديثات Idempotent
استخدم معرف حدث نيزا مع معرف الحالة الداخلي كمفتاح ثابت للعمل اللاحق. إذا تم تسليم نفس webhook مرتين، يجب أن تحدّث المحاولة الثانية سجل الحالة الموجود بدل إنشاء سجل جديد.
- احفظ معرف تسليم webhook ومعرف حدث القرار.
- نفّذ upsert للحالة باستخدام معرف الحدث قبل إضافة التعليقات أو المهام.
- سجّل آخر قرار مطبق حتى لا تعيد رسائل
REVIEWأوBLOCKالمتكررة فتح عمل مغلق. - اجعل تغييرات الحالة الظاهرة للعميل خلف انتقال واحد واضح داخل منتجك.
أعد المحاولة بسياق
إعادة المحاولة مفيدة فقط عندما يستطيع فريق العمليات فهم ما فشل. سجّل كود الاستجابة، والوجهة، ومعرف الحدث، ووقت إعادة المحاولة التالي. عند تكرار الفشل، أرسل تنبيهًا واحدًا للفريق المالك مع معرفات الأحداث المتأثرة.
أغلق الحلقة
عند انتهاء التحقيق، أرسل الملاحظات إلى نيزا مع التصنيف النهائي ومرجع الحالة لديك. هذا يصنع مسار تدقيق أفضل ويساعد على ضبط القواعد لاحقًا.
اضبط شرح webhooks قبل ربط تنبيهات الإنتاج.