واجهات البرمجة أولًا مع الأنظمة القديمة: فكّ التشابك مسارًا بعد مسار

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

ضع واجهة أمام النظام الأساسي

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

صمّم العقد أولًا

• اكتب مواصفات الواجهة، عادةً بصيغة OpenAPI، قبل كتابة أي شيفرة؛
• اتفق عليها مع الفرق التي ستستخدمها؛
• أعطها رقم إصدار، ولا تُلغِ إصدارًا قائمًا دون إشعار مسبق؛
• انشرها في بوابة للمطورين مع أمثلة وبيئة اختبار.

اجعل إعادة المحاولة آمنة

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

الأمن ووضوح الرؤية

تتولى بوابة الواجهات المصادقة عبر OAuth 2.0 أو TLS المتبادل، وحدود الاستخدام، والسجلات في مكان واحد. وتتيح معرّفات الربط المرافقة لكل طلب لفرق الدعم تتبع طلب واحد عبر الأنظمة كلها. ومن دونها يتحول أي عطل في التكامل إلى اجتماع بين أربعة موردين.

شغّلها كما تشغّل منتجًا

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

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