ارتباط جلسة الوكيل: طلب واحد أم سير عمل كامل؟

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

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

ملفات تعريف الارتباط وارتباط الوكيل حالتان مختلفتان

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

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

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

خطّط للحالة غير المريحة

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

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