نمط قاطع الدائرة لواجهات برمجة التطبيقات الخارجية في سير العمل المرئي

لماذا انقطاعات واجهات الطرف الثالث تكسر أكثر من ميزة واحدة

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

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

البطء والتوقف يؤثران بشكل مختلف.

عندما تكون واجهة API بطيئة، لا يزال سير العمل يحاول النجاح، لكن كل خطوة تنتظر. يرى المستخدمون شاشات تدور، ويحصل فريق الدعم على تذاكر "عالقة"، وتتكدس المهام الخلفية. البطء خداع لأنه قد يبدو أن نظامك نفسه يفشل.

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

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

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

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

قاطع الدائرة ببساطة

قاطع الدائرة هو مفتاح أمان لاستدعاءات API. عندما يبدأ مزود طرف ثالث بالفشل، يمنع القاطع سير العمل من ضربه مرارًا وتكرارًا. بدلًا من تحويل انقطاع واحد إلى شاشات بطيئة، مهلات انتهاء، ووظائف عالقة، تتحكم في مساحة الضرر.

لقاطع الدائرة ثلاث نتائج بسيطة:

• السماح بالاستدعاء عندما يبدو البائع صحيًا.
• حظر الاستدعاء عندما تكون الأخطاء مرتفعة، وأخذ مسار بديل فورًا.
• محاولة اختبار محدودة بعد وقفة قصيرة للتحقق مما إذا عاد البائع.

إذا فضلت التسميات، فهي "مغلق" و"مفتوح" و"نصف مفتوح". الأسماء ليست النقطة الأساسية. الاتساق هو المطلوب. عندما يمرض البائع، يجب أن يتصرف سير العمل بنفس الطريقة في كل مرة.

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

اختر استدعاءات API التي يجب ألا توقف العمل

قواطع الدائرة تعمل أفضل عندما تكون انتقائيًا. ليس كل استدعاء بائع يستحق حماية خاصة. ابدأ بالخطوات التي، إذا حُجبت، توقف المال أو الطلبات أو وصول العملاء.

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

الاستدعاءات النموذجية "التي لا يجب أن تعيق العمل الأساسي" تشمل المدفوعات، الشحن والتنفيذ، تسجيل الدخول/SSO/MFA، رسائل OTP والتأكيد، وفحوصات الامتثال المرتبطة بالموافقة.

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

ابدأ صغيرًا لتجنب توسع النطاق. احمِ 1–3 سير عمل أولًا، ثم وسع.

حدد ماذا يعني "البديل الآمن" قبل البناء. البدائل الجيدة محددة وقابلة للاختبار:

• المدفوعات: احفظ الطلب كـ "دفع معلق" حتى لا يفقد السلة.
• الشحن: استخدم سعرًا مخزنًا مؤقتًا، أو سعرًا ثابتًا، أو أكد الطلب وأجل شراء الملصق.
• الهوية: اسمح بتسجيل الدخول بكلمة المرور عندما يكون SSO معطلاً، أو التحويل إلى التحقق عبر البريد الإلكتروني.
• الرسائل: ضع SMS في قائمة انتظار للإرسال لاحقًا ووفّر مسارًا بديلًا إن أمكن.

في Business Process Editor الخاص بـ AppMaster، يتحول هذا عادةً إلى فرع واضح: تستمر العملية الأساسية بينما يأخذ خطوة الاعتماد على البائع بديلًا محكومًا.

الحالات والعتبات والمؤقتات التي يمكن تفسيرها

قاطع الدائرة هو مفتاح أمان. معظم الوقت يترك الاستدعاءات تمر. عندما يبدأ البائع بالفشل، ينقلب لحماية سير العمل من إضاعة الوقت وتكدس الأخطاء.

الحالات الثلاث

مغلق هو الوضع الطبيعي. تستدعي الواجهة وتتابع.

إذا تجاوزت الأخطاء حدًا، ينتقل القاطع إلى مفتوح. تتوقف عن استدعاء البائع لفترة قصيرة وتتجه فورًا إلى بديل (قيمة مخزنة مؤقتًا، عمل في قائمة الانتظار، مسار بديل).

بعد فترة تبريد، ينتقل القاطع إلى نصف مفتوح. تسمح بعدد قليل من محاولات الاختبار. إذا نجحت، تعود إلى المغلق. إذا فشلت، تعود إلى المفتوح.

ما الذي يجب قياسه

استخدم إشارات تتطابق مع طريقة فشل البائع:

• مهلات انتهاء
• أخطاء HTTP 5xx
• ارتفاع الكمون (بطيء جدًا بحيث لا يكون مفيدًا)
• أخطاء اتصال/DNS
• حدود المعدل 429

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

عتبات البداية والمؤقتان الرئيسيان

ابدأ بأرقام سهلة الشرح، ثم ضبّطها على أساس الحركة الحقيقية. أمثلة:

• افتح القاطع إذا فشل 5–10 استدعاءات خلال 30–60 ثانية.
• أو افتح إذا فشل 20%–40% من الاستدعاءات في نافذة متحركة.
• اعتبر الكمون فشلًا عندما يتجاوز ما يمكن لعمليتك تحمله (غالبًا 2–5 ثوانٍ).

ثم اضبط مؤقتين:

• زمن التهدئة (حالة Open): غالبًا 30 ثانية إلى 5 دقائق.
• نافذة اختبار Half-open: اسمح بـ 1–5 محاولات اختبار، أو نافذة زمنية قصيرة مثل 10–30 ثانية.

الهدف واضح: الفشل السريع عندما يكون البائع غير صحي، والتعافي التلقائي عندما يعود.

خطوة بخطوة: بناء قاطع الدائرة في سير عمل مرئي

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

1) ضع استدعاء البائع خلف كتلة قابلة لإعادة الاستخدام

أنشئ عملية فرعية واحدة (كتلة سير عمل قابلة لإعادة الاستخدام) تستخدمها كل العمليات عند الحاجة لذلك البائع. في AppMaster، يتوافق هذا طبيعيًا مع Business Process يمكنك استدعاؤه من نقاط نهاية أو أتمتة. اجعله ضيقًا: مداخل، طلب البائع، وناتج نجاح/فشل واضح.

2) تتبع الإخفاقات بالزمن، ليس بالعد فقط

سجل كل نتيجة مع طابع زمني. احفظ أشياء مثل آخر نجاح، آخر فشل، الأخطاء ضمن نافذة، الحالة الحالية، وموعد انتهاء التهدئة.

خزن هذه الحقول في جدول حتى يصمد القاطع عبر إعادة التشغيل ويظل متناسقًا عبر مثيلات متعددة. PostgreSQL عبر Data Designer يناسب هذا جيدًا.

3) عرّف تغييرات الحالة التي ستتبعها في كل مرة

حافظ على القواعد بسيطة. مثال: إذا حدثت 5 حالات فشل خلال دقيقتين، انتقل إلى Open. أثناء Open، تخطى استدعاء البائع حتى تنقضي فترة التهدئة. بعد التهدئة، اذهب إلى Half-open واسمح بمحاولة مسيطرة واحدة. إذا نجحت، أغلق القاطع. إذا فشلت، أعد فتحه.

4) فرق سير العمل: مسار البائع مقابل المسار البديل

قبل طلب البائع، تحقق من الحالة المخزنة:

• مغلق: استدعِ البائع ثم حدّث النجاح أو الفشل.
• مفتوح: تخطى الاستدعاء ونفّذ المسار البديل.
• نصف مفتوح: اسمح بمحاولة محدودة، ثم قرر الإغلاق أو إعادة الفتح.

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

5) اجعلها مشتركة عبر سير العمل

إذا كان لديك عدة سير عمل وخوادم، يجب أن يقرأوا ويكتبوا نفس حالة القاطع. وإلا قد يستمر مثيل واحد بضرب البائع بينما قرر آخر التوقف.

مسارات بديلة تحافظ على سير العمل

قاطع الدائرة لا يفيد إلا إذا قررت ماذا يحدث عندما يُحظر الاستدعاء. البديل الجيد يبقي المستخدم يتحرك، يحمي بياناتك، ويجعل التنظيف لاحقًا متوقعًا.

اختر بديلًا يناسب المهمة. إذا كان مزود أسعار الشحن متوقفًا، قد لا تحتاج سعرًا دقيقًا لقبول الطلب. في سير عمل مرئي، وجه خطوة API الفاشلة إلى فرع بديل ينتج نتيجة قابلة للاستخدام.

عمليًا، تبدو البدائل عادةً كأحد الآتي:

• استخدم آخر قيمة معروفة مخزنة مؤقتًا (بنافذة صلاحية واضحة).
• استخدم تقديرًا آمنًا ثابتًا مع وسم واضح.
• وجه للمراجعة اليدوية.
• ضع العمل في قائمة انتظار لإعادة المحاولة لاحقًا (وظيفة غير متزامنة).

تجربة المستخدم مهمة بقدر المنطق. لا تعرض خطأ غامضًا. اشرح ما حدث وماذا يمكن للمستخدم فعله التالي: "لم نستطع تأكيد السعر الآن. يمكنك إتمام الطلب بتكلفة شحن تقديرية، أو حفظه للمراجعة."

أيضًا خطط لفترات انقطاع قصيرة وطويلة. انقطاع قصير (دقائق) يعني غالبًا "استمر، أعد المحاولة بالخلفية". انقطاع أطول (ساعات) قد يتطلب سلوكًا أكثر تشددًا مثل مزيد من المراجعات اليدوية أو الموافقات.

وأخيرًا، تتبع كل بديل لتسهيل التسوية لاحقًا. على الأقل، سجّل نوع البديل، تفاصيل الطلب الأصلي، ما أعدته للمستخدم (وهل كان تقديرًا)، وحالة للمتابعة.

قواعد الحظر المؤقت والمحاولات الأذكى

إعادة المحاولات غير المضبوطة تحول مشاكل صغيرة للبائع إلى انقطاعات حقيقية. عندما تعيد العديد من العمليات المحاولة في نفس الوقت، تخلق ذروة (مشكلة "القطيع الرعدي"). يبطأ البائع، تنمو الطوابير، وتُستهلك حدود المعدل.

يجب أن تكون الإعادات متوقعة ومحدودة، ويجب أن تحترم حالة القاطع. سياسة عملية هي:

• اجعل الحد الأقصى للمحاولات منخفضًا (غالبًا 2–3).
• استخدم تراجعًا أسيًا (مثل 2s، 8s، 30s).
• أضف تاضاربًا زمنيًا (jitter) حتى لا تتزامن المحاولات.
• قلّص إجمالي زمن المحاولات (على سبيل المثال 60–90 ثانية).
• إذا كان القاطع مفتوحًا، لا تعيد المحاولة؛ اذهب مباشرةً إلى البديل.

الحظر المؤقت مرتبط لكنه متميز. يستخدم عندما تشير الاستجابة إلى أن "هذا لن يعمل الآن." قواعد شائعة:

• 429 حد المعدل: احظر لفترة Retry-After أو نافذة آمنة ثابتة.
• 401/403 فشل مصادقة: احظر حتى تُجدد الاعتمادات، ثم اختبر مرة واحدة.
• 5xx متكرر: احظر لفترة قصيرة، ثم اسمح باختبار صغير.

أثناء الحظر، قرر ماذا يحدث للعمل الجاري: ضعه في قائمة انتظار، أعد توجيهه، أو انحدر بلطف (مثال: اقبل الطلب لكن أرجئ "إرسال SMS").

تنبيهات تخبرك ماذا تفعل

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

المشغلات الافتراضية الجيدة:

• نبه عند فتح القاطع.
• نبه إذا بقي مفتوحًا بعد حد زمني.
• نبه عند ارتفاع حاد في الأخطاء حتى قبل الفتح.

اجعل التنبيهات قابلة للفعل. ضمّن البائع والنقطة النهائية، الحالة الحالية ومتى تغيرت، ما سيشعر به المستخدم، ماذا يفعل سير العمل الآن (يُحظر، يعيد، يستخدم بديل)، وخطوة مقترحة واحدة.

وجّه التنبيهات حسب الشدة. API غير حرجة يمكن أن تذهب إلى البريد الإلكتروني. المدفوعات أو تسجيل الدخول أو تقديم الطلبات عادة تستحق صفحة تحذير. في AppMaster هذا يتوافق بوضوح مع فروع ترسل بريدًا أو Telegram أو SMS اعتمادًا على علامة الشدة.

تتبّع مجموعة صغيرة من المقاييس لتعرف ما إذا كنت تتعافى: الاستدعاءات المحجوبة واستخدام البدائل لكل بائع غالبًا ما تكون كافية.

مثال سيناريو: انقطاع بائع دون إيقاف الطلبات

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

في يوم عادي، يُنشأ الطلب، ثم يطلب سير العمل الأسعار الحية، ويحفظ الطلب مع الناقل والسعر المختار.

عندما يبدأ البائع بالفشل، تنتهي مهلات الاتصال أو تعود أخطاء 5xx. عند بلوغ عتبتك (مثلاً 5 فشل في دقيقتين)، يُفتح القاطع.

أثناء Open، يتوقف سير العمل عن استدعاء موفر الشحن لفترة قصيرة (مثلاً 10 دقائق). هذا يمنع بائعًا فاشلًا من سحب صفحة الخروج لكل المستخدمين.

بدلاً من حظر الخروج، يمكن للمسار البديل أن:

• يطبّق رسومًا ثابتة (أو تقديرًا آمنًا).
• ينشئ الطلب على أي حال.
• يعلّمه كـ “Shipping rate pending” لإعادة الحساب لاحقًا.
• يحفظ تفاصيل خطأ البائع للمتابعة.

في AppMaster، هذا فرع واضح في Business Process Editor، مدعومًا بحقول Data Designer مثل shipping_rate_status وshipping_rate_source.

فحوصات سريعة قبل الإطلاق

يجب أن يتصرف قاطع الدائرة بنفس الطريقة تحت الضغط كما يفعل في العرض التوضيحي. قبل الإصدار، تأكد من الأساسيات:

• العتبات وفترات التهدئة موثقة وسهلة التعديل.
• حالة Open تمنع الاستدعاءات فورًا (دون الانتظار لمهلات البائع).
• سلوك المسارات البديلة آمن للأموال ووعود العملاء.
• تجارب Half-open محدودة لعدد قليل من الاستدعاءات.
• السجلات تبيّن التوقيت والتأثير بوضوح.

اقضِ وقتًا إضافيًا على سلامة المسارات البديلة. بديل "يحافظ على تقدم العمل" يمكن أن يخلق أيضًا مخاطر مالية. إذا كان مزود الدفع متوقفًا، فإن وسم الطلب كـ مدفوع قد يكون خطيرًا. نهج أكثر أمانًا هو "دفع معلق" مع رسالة واضحة للعميل.

اختبر الاسترداد عمدًا. فرض الفشل، شاهد القاطع يفتح، انتظر فترة التهدئة، وتأكد أن Half-open يرسل فقط اختبارًا صغيرًا. إذا نجح، يجب أن يُغلق بسرعة. إذا فشل، يجب أن يُعاد فتحه دون غمر البائع.

يجب أن تجيب سجلاتك خلال أقل من دقيقة: من تأثر، متى بدأ، أي خطوة في سير العمل دفعت القاطع، وما المسار البديل المستخدم.

الخطوات القادمة: تنفيذ النمط في AppMaster

اختر تكاملًا واحدًا يمكن أن يؤذي العمليات اليومية إذا فشل (المدفوعات، بطاقات الشحن، SMS، مزامنة CRM). ابنِ القاطع من البداية للنهاية لذلك الاستدعاء المفرد أولًا. عندما يثق الفريق بالسلوك، كرر القالب لنفس البائع أو لبائع آخر.

في AppMaster، نمذجة حالة القاطع في PostgreSQL باستخدام Data Designer. اجعلها بسيطة: سجل واحد لكل بائع (أو نقطة نهاية) مع حقول مثل state، failure_count، last_failure_at، open_until، وlast_error القصير.

ثم طبّق المنطق في Business Process Editor بفروع واضحة وقابلة للقراءة. الوضوح أفضل من الذكاء.

ترتيب بناء عملي:

1. تحقق من حالة القاطع واحجب الاستدعاءات عندما يكون open_until في المستقبل.
2. استدعِ API البائع والتقط مخرجات النجاح والخطأ.
3. عند النجاح، أعد تعيين العداد وأغلق القاطع.
4. عند الفشل، زد العداد وافتح القاطع عند بلوغ العتبات.
5. وجّه المسارات المواجهة للمستخدم إلى بديل (قيد الانتظار، استخدم بيانات مخزنة مؤقتًا، أو اسمح بالمعالجة اليدوية).

وثّق قرار البديل بلغة بسيطة حتى يعرف الدعم والعمليات ما يراه المستخدم.

عندما يفتح القاطع، أبلغ مالكًا باستخدام وحدات المراسلة في AppMaster (بريد، SMS، Telegram). تضمّن ما يهم: البائع، النقطة النهائية، الحالة، والإجراء الموصى به الأول.

إذا كنت تبني هذه العمليات في AppMaster، appmaster.io مكان عملي للبدء لأن نفس Business Process المرئي يمكن أن يغذّي نقاط النهاية والمهام الخلفية والتنبيهات مع حالة قاطع مشتركة واحدة.