الانتقال إلى المحتوى
Englishتواصل معنا
الهندسة · دقيقتان للقراءة

ما الذي تعلّمناه من ربط أكثر من 30 شركة شحن

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

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

ترتبط منصاتنا للطرود والخدمات اللوجستية بأكثر من 30 شركة شحن ومشغّل بريد: حجز الشحنات وإلغاؤها والاستعلام عن الأسعار وتتبّعها، ولكلٍّ منها واجهة برمجة مختلفة. بعضها يعمل عبر REST، وبعضها عبر SOAP، وبعضها ما زال يتبادل الملفات وفق جدول زمني. ولم يصبح الكتالوج سهل الصيانة إلا عندما توقفنا عن التعامل مع كل تكامل كمشروع مستقل، وبدأنا نتعامل مع الكتالوج كمنتج.

وهذا ما تغيّر.

1. صمّم نموذج الشحنة مرة واحدة، واربطه مرات كثيرة

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

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

2. افترض أن كل استدعاء سيُعاد

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

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

3. التتبّع تدفّق مستمر، لا طلب منفرد

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

CREATED → PICKED_UP → IN_TRANSIT → OUT_FOR_DELIVERY → DELIVERED
↘ EXCEPTION → RETURNED

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

4. ضع البنية التحتية في طبقة وسيطة

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

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

5. اجعل الأعطال مرئية لفرق العمليات، لا للمهندسين فقط

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

ما الذي أتاحه ذلك

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

إذا كنت تدير عمليات شحن أو بريد أو تنفيذ طلبات، وأصبحت التكاملات هي ما يبطئك، يسعدنا أن نتبادل الخبرات معك.

  • الخدمات اللوجستية
  • التكاملات
  • واجهات البرمجة
  • البنية المعمارية
  • Bitween

لنبنِ معًا ما هو قادم.

أخبرنا بما تعمل عليه. يقرأ أحد مهندسينا كل رسالة ويرد خلال يوم عمل واحد.

عمّان، الأردنشارع الأميرة ثروت الحسن، عمّان، الأردن
دبي، الإمارات العربية المتحدةحي دبي للتصميم، دبي، الإمارات العربية المتحدة