التكاملات تفشل عند الأطراف

كل عرض توضيحي لتكامل يعمل. يتبادل نظامان طلبًا واستجابة، فتظهر البيانات في المكان الصحيح، وينتقل الجميع إلى المتطلب التالي.

ثم يلتقي التكامل ببيئة الإنتاج، فتأتي المشكلات من الأطراف: طابع زمني بلا منطقة زمنية، وإعادة محاولة تُنشئ نسخة مكررة، ورمز صلاحية ينتهي أثناء دفعة طويلة.

بعد عدد كافٍ من عمليات التنفيذ يصبح النمط متوقعًا. نادرًا ما يكون وسط التكامل هو الجزء الصعب. الأطراف هي الصعبة.

الوقت ليس تفصيلًا#

حصة مفاجئة من عيوب التكامل تتعلق بالوقت. ليس لأن الوقت معقّد من حيث المبدأ، بل لأن نظامين يختلفان عادة حوله.

من الاختلافات الشائعة:

• طابع زمني بلا إزاحة، يفسّره كل نظام بطريقة مختلفة.
• توقيت محلي في قاعدة بيانات، وUTC في الـ API، وطبقة عرض تفترض شيئًا ثالثًا.
• «يوم عمل» يعرّفه فريق واحد ويفترضه الجميع.
• تحولات التوقيت الصيفي التي تُنشئ ساعة غير موجودة أو تتكرر مرتين.

الحل ليس بارعًا. اختر تمثيلًا واحدًا، واكتبه، وحوّل عند حدود كل نظام لا في وسط سير العمل. ثم اختبر التواريخ الحرجة صراحةً: حدّ التوقيت الصيفي، وآخر يوم في الشهر، ونهاية فترة الفوترة.

إعادة المحاولة تحتاج إلى عقد#

تُوصف إعادة المحاولة عادةً بأنها ميزة متانة. وفي الممارسة، إعادة المحاولة طلب جديد قد يُنشئ أثرًا جانبيًا ثانيًا.

إذا كان التكامل يُنشئ فاتورة أو يرسل بريدًا إلكترونيًا أو يفتح تذكرة، فإن إعادة المحاولة عند انتهاء المهلة قد تكرر ذلك الإجراء. ربما عالج النظام الطلب وفشل قبل أن يستجيب. ولا يستطيع العميل التمييز بين «لم يُعالج» و«عولج وضاعت الاستجابة».

الإجابات العملية ليست مبهرة:

• امنح كل طلب مفتاح تكرارية يولّده المستدعي.
• اجعل المتلقي يعيد النتيجة الموجودة عند تكرار المفتاح.
• افصل في العميل بين إعادات محاولة «القراءة» وإعادات محاولة «الكتابة».
• سجّل معرّف الطلب على الطرفين كي يتيسّر تتبّع الفشل بدل تخمينه.

إذا لم يستطع النظام المتلقي دعم التكرارية، فستكون إعادة المحاولة يدوية أو محدودة صراحةً. والتظاهر بغير ذلك ينقل التكرار إلى مكان أقل ظهورًا فقط.

الهوية طرف بحد ذاتها#

المصادقة هي حيث تكتسب التكاملات اقترانًا مفاجئًا.

قد يتصرف حساب خدمة يعمل في بيئة اختبار بشكل مختلف في الإنتاج. وقد تنتهي صلاحية شهادة في تاريخ لم يكتبه أحد. وقد تتضمن رسالة SAML سمات لم تكن مطلوبة حتى استخدمها عميل جديد. وقد يكون لـ JWT هامش تفاوت في الساعة مقبول لنظام وقاتل لآخر.

أحتفظ بقائمة بسيطة لكل تكامل يشمل الهوية: مَن يصادق، وما الاعتماد المستخدم، ومتى تنتهي صلاحيته، ومَن يملك تدويره، وما يحدث عند فشله. هذه القائمة التقطت مشكلات أكثر من معظم وثائق الهندسة.

اكتب قائمة الأعطال أولًا#

العادة التي أفادتني أكثر عادة غير مبهرة. قبل بناء تكامل، أكتب قائمة بالطرق التي قد يفشل بها:

• النظام الآخر غير متاح.
• النظام الآخر بطيء لكنه سليم.
• الاستجابة صحيحة لكن البيانات خاطئة.
• الطلب ينجح مرتين.
• انتهاء صلاحية الاعتماد.
• الحجم أكبر عشر مرات من العينة.
• الملف فارغ أو مقطوع أو بترميز مختلف عمّا تزعمه المواصفات.

ثم أقرر صراحةً ما يفعله النظام في كل حالة. ليس لأن كل حالة تحتاج معالجة — بعضها يمكن قبوله — بل لأن عطلًا لم يُفحص يصبح حادثة إنتاج لها جمهور.

الخلاصة#

يُوصف عمل التكامل غالبًا بأنه سباكة. هذا بخسٌ له. المهارة الحقيقية هي فهم نظامين جيدًا بما يكفي لمعرفة أين تختلف افتراضاتهما، ثم تصميم حدّ يكون فيه الخلاف ظاهرًا ومضبوطًا.

العرض التوضيحي هو الجزء السهل. الأطراف هي العمل.