لديك نموذج يستقبل طلبات العملاء، وتريد نقل كل طلب إلى نظام إدارة العمل وإرسال رسالة تأكيد. يبدو المسار بسيطًا: استقبال، ثم إنشاء، ثم إرسال. لكن ماذا يحدث إذا انقطع الاتصال بعد إنشاء السجل وقبل وصول الرد؟ إعادة المحاولة دون ضوابط قد تنشئ طلبًا آخر.
ارسم العملية قبل ربط الأدوات
ابدأ بتحديد الحدث الذي يشغّل العملية، والبيانات المطلوبة، والجهة التي تستقبلها، والنتيجة التي تعد نجاحًا. عيّن أيضًا مسؤولًا يستطيع معالجة الحالات التي لا تكتمل آليًا.
في مثالنا التوضيحي، يمكن أن يمر الطلب بحالات «مستلم»، و«قيد المعالجة»، و«مكتمل»، و«يحتاج مراجعة». الأسماء ليست معيارًا إلزاميًا؛ فائدتها أن تجعل الحالة مفهومة للفريق، بدل أن تختبئ داخل سجل تقني لا يراجعه أحد.
امنح العملية معرّفًا واضحًا
استخدم معرّفًا للطلب يتتبع الرحلة بين الأنظمة، ومعرّفًا لمحاولة التنفيذ عند الحاجة. وجود سجل للخطأ يساعد على معرفة المرحلة التي توقفت، لكن تجنب تسجيل أسرار الدخول أو نسخ جميع بيانات العميل بلا ضرورة.
مثال سجل مختصر: رقم العملية، المرحلة، وقت المحاولة، ونوع الخطأ. صمّم ما يستطيع فريق الدعم رؤيته بما يتناسب مع حاجته وصلاحياته.
تعامل مع التكرار باعتباره احتمالًا طبيعيًا
توثّق Stripe مفهوم مفاتيح منع تكرار الأثر في واجهتها البرمجية: يتيح المفتاح التعرف على إعادة محاولة العملية وفق قواعد الخدمة. الاستفادة العامة من الفكرة هي أن تكرار الطلب لا ينبغي أن يعني تلقائيًا تكرار النتيجة.
لكن دعم هذا السلوك وتفاصيله يختلفان بين الخدمات. إذا كان النظام المستقبل يدعم مفتاحًا لهذا الغرض، فالتزم بتوثيقه. وإن لم يدعمه، فستحتاج إلى تصميم يحفظ حالة العملية ويمنع التعارض، وقد يتطلب ذلك قيدًا فريدًا أو معالجة متزامنة صحيحة. مجرد البحث عن السجل قبل إنشائه لا يكفي دائمًا إذا وصلت محاولتان معًا.
أعد المحاولة عندما تكون مفيدة
خطأ اتصال مؤقت يختلف عن بيانات ناقصة لن تصبح صحيحة بتكرار الإرسال. ضع سياسة محدودة للمحاولات، واحترم تعليمات الخدمة وحدودها. وعندما تكون النتيجة غامضة، مثل احتمال اكتمال الإنشاء دون وصول الرد، تحقق من الحالة أو أرسلها للمراجعة قبل تنفيذ أثر جديد.
اختبر ثلاثة سيناريوهات قبل الإطلاق
- طلب صحيح يصل مرة واحدة ويكتمل.
- الطلب نفسه يصل مرتين: ما النتيجة الفعلية؟
- تتعطل خدمة في منتصف الرحلة: هل يستطيع المسؤول معرفة ما حدث واستكماله بأمان؟
ابدأ بأتمتة محدودة، وراقب الحالات التي تحتاج تدخلًا يدويًا. مقياس النجاح لا يقتصر على عدد مرات التشغيل؛ يشمل أيضًا دقة النتيجة ووضوح الأخطاء والقدرة على الاسترداد. بهذه الأسئلة تتحول سلسلة الخطوات إلى عملية يمكن الاعتماد عليها.
مرجع للتوسع
توثيق Stripe: الطلبات التي تمنع تكرار الأثر — مثال تطبيقي خاص بخدمة بعينها، وتفاصيله لا تنطبق تلقائيًا على بقية الأنظمة.