نقل أتمتة Zapier أو Make إلى مضيف ترميز جغرافي جديد
تحتاج عمليات الأتمتة دون شيفرة المبنية على خطوة ترميز جغرافي إلى نهج ترحيل مختلف عن الشيفرة المخصصة. إليك كيفية التعامل مع هذا التحويل.
مطابقة رموز الأخطاء بين المزوّدين قبل التبديل
تحظى الاستجابات الناجحة بمعظم الاهتمام في عملية الترحيل، لأنها ما يعرضه العرض التوضيحي وما تتحقق منه الجولة الأولى من الاختبار عادةً. أما استجابات الأخطاء فتحظى باهتمام أقل بكثير، وهذا عكس ما ينبغي تمامًا، لأن شيفرة معالجة الأخطاء غالبًا ما تكون أول ما ينكسر وأوضحه في بيئة الإنتاج عندما يتغير المزود تحت التطبيق.
لكل مزود للترميز الجغرافي وبيانات المواقع أعرافه الخاصة في الإشارة إلى الإخفاق: فبعضهم يستخدم رموز حالة HTTP حصرًا، وبعضهم يضمّن حقل حالة داخل استجابة JSON تحمل الحالة 200 في ما عدا ذلك، وبعضهم يميز بين "لم يُعثر على نتائج" و"طلب غير صالح" برموز مختلفة، وبعضهم يدمج الاثنين في خطأ عام. ومنطق إعادة المحاولة في التطبيق، ورسائل الخطأ التي يراها المستخدم، وتنبيهات المراقبة، تُبنى كلها عادةً حول أعراف الأخطاء لدى مزود محدد واحد، أحيانًا دون أن يوثق أحد هذا الاعتماد صراحةً.
قبل تبديل المزود، من المفيد بناء جدول ربط صريح بين استجابات الأخطاء لدى المزود القديم واستجاباتها لدى المزود الجديد، يغطي على الأقل:
- عدم العثور على نتائج لاستعلام صالح لكن بلا مطابقة، تمييزًا له عن الطلب المشوّه أو غير الصالح
- تجاوز حد معدل الطلبات، وما إذا كانت الاستجابة تتضمن أي معلومات عن موعد إعادة المحاولة
- إخفاقات المصادقة، بما فيها بيانات الاعتماد المنتهية أو المفقودة أو المشوّهة
- أخطاء الخادم من جهة المزود، تمييزًا لها عن أخطاء الطلب من جهة العميل
- أي قيم حالة خاصة بالمزود تتحقق منها شيفرتك صراحةً بالاسم أو الرقم
توثّق My Geocode استجابات الأخطاء وأعراف الحالة لديها في /docs/errors/، وتحمل كل استجابة أيضًا ترويسات الحصة، X-Quota-Limit وX-Quota-Used وX-Quota-Free-Remaining وX-Quota-Network-Used وX-Credits-Remaining وX-Key-IPs-Used وX-Key-IPs-Limit وX-Quota-Reset، وهي تغطي فئة من المعلومات، حالة الحصة والمعدل، يدفنها بعض المزودين داخل أجسام استجابات الأخطاء بدلًا من كشفها مباشرة في الترويسات. والتحقق مما إذا كان منطق إعادة المحاولة الحالي لديك يقرأ معلومات الحصة من جسم الاستجابة أم من ترويسة بند محدد جيد لإضافته إلى قائمة التحقق الخاصة بالترحيل، لأن معلومات الحصة المستندة إلى الترويسات أسهل قراءة عمومًا دون المساس بمسار تحليل الاستجابة المستخدم للبيانات الفعلية.
من الطرق العملية لبناء جدول الربط إطلاق كل حالة خطأ عمدًا لدى المزود القديم والجديد كليهما في بيئة اختبار، بدلًا من الاعتماد على التوثيق وحده، لأن التوثيق والسلوك الفعلي لا يتطابقان دائمًا تمامًا، لدى أي مزود. أرسل طلبًا مشوّهًا، واستنفد حصة اختبار صغيرة عمدًا، وأرسل مفتاحًا غير صالح، ثم سجّل بالضبط ما يعيده كل مزود في كل حالة.
نادرًا ما يظهر هذا النوع من عمل ربط الأخطاء في خطة مشروع الترحيل لأنه لا ينتج ميزة مرئية، لكنه مسؤول بشكل غير متناسب عن الطريقة التي يُتذكر بها الترحيل بعد ذلك. فالترحيل الذي يغيّر الاستجابات الناجحة بشكل نظيف لكنه يترك معالجة الأخطاء معطلة يولّد عادةً تذاكر دعم أكثر بكثير، في الأسابيع الأولى بعد التحويل، من ترحيل لم يُصب المسار السعيد إلا جزئيًا.