تكامل بيانات الاتصالات عن بُعد باستخدام HTTP Push في IoT Logic

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

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

ما المقصود بإثراء البيانات باستخدام HTTP Push؟

يتيح إثراء البيانات باستخدام HTTP Push لنظام خارجي إرسال البيانات مباشرة إلى Navixy IoT Logic، وهي بيئة low-code لمعالجة وتحويل بيانات الاتصالات عن بُعد الواردة من أجهزة IoT وأنظمة OEM.

يرسل النظام الخارجي طلب HTTP يحتوي على بياناته. ويعمل تعيين مُعد مسبقًا على ربط البيانات الواردة بجهاز التتبع المقابل وإتاحة السمات للمعالجة في IoT Logic.

تصل بيانات القياس عن بُعد من جهاز التتبع والبيانات الخارجية بشكل مستقل.

لنفترض أن جهاز التتبع يرسل:

hardware_mileage = 197450

بينما يرسل نظام إدارة صيانة الأسطول المسافة المسجلة عند آخر صيانة:

{
  "vehicle_ref": "VEH-318",
  "odometer_at_service": 182300
}

أصبحت القيمتان الآن متاحتين في IoT Logic. ويمكن للتدفق حساب أن المركبة قطعت 15,150 كيلومترًا منذ الصيانة المسجلة واستخدام النتيجة في المعالجة اللاحقة.

لا يتحول نظام الصيانة إلى مصدر آخر لبيانات القياس عن بُعد. فهو يوفر المعلومات التي يمتلكها، بينما يواصل جهاز التتبع إرسال بيانات المركبة بشكل مستقل.

ما الذي تضيفه البيانات الخارجية إلى تدفق بيانات الاتصالات عن بُعد؟

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

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

إنشاء شروط باستخدام مصدرين للبيانات

تحتاج بعض القواعد التشغيلية إلى بيانات القياس عن بُعد ومعلومات موجودة في أنظمة أخرى في الوقت نفسه.

لنفترض أن جهاز التتبع أبلغ عن دخول مركبة مبردة إلى السياج الجغرافي لمستودع، بينما يوفر نظام خارجي القيمة التالية:

inspection_required = true

يمكن لـ IoT Logic تقييم المعلومتين واستخدام النتيجة لتشغيل الخطوة التالية في سير العمل.

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

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

تشغيل إجراء في نظام الاتصالات عن بُعد من نظام آخر

يمكن للبيانات الخارجية أيضًا بدء سير عمل في الاتجاه الآخر.

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

immobilization_requested = true

يمكن للطلب الدخول إلى IoT Logic عبر HTTP Push. ويمكن للتدفق تقييم أي شروط إضافية، وعندما تسمح إعدادات التدفق وإمكانات جهاز التتبع بذلك، بدء الإجراء المقابل على الجهاز.

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

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

ربط المعرّفات الخارجية بأجهزة التتبع

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

VEH-318
VEH-319
VEH-320

عند إعداد إثراء البيانات باستخدام HTTP Push، يمكن استخدام معلمة مناسبة من البيانات الواردة كمفتاح أساسي لربط هذه القيم بأجهزة التتبع:

VEH-318 → جهاز التتبع 12345
VEH-319 → جهاز التتبع 12346
VEH-320 → جهاز التتبع 12347

وبالتالي، يمكن لنظام الصيانة الاستمرار في إرسال payload يستند إلى المعرّف الخاص به:

{
  "vehicle_ref": "VEH-318",
  "maintenance_due": false,
  "work_order": "WO-98311",
  "odometer_at_service": 182300
}

يستخدم IoT Logic التعيين المُعد للحقل vehicle_ref لربط البيانات الواردة بجهاز التتبع المقابل. وبذلك تبقى عملية ترجمة المعرّفات عند حدود التكامل، بدلًا من مطالبة التطبيق المصدر باعتماد معرّفات أجهزة التتبع أو أي معرّف آخر خاص بـ Navixy.

من البنية التحتية للتكامل إلى منطق الأعمال

قبل إثراء البيانات باستخدام HTTP Push، لم يكن من الممكن إدخال بيانات الأعمال الخارجية مباشرة إلى IoT Logic بهذه الطريقة. وكان ذلك قد يتطلب مكوّن تكامل بين التطبيق الخارجي ومعالجة بيانات الاتصالات عن بُعد.

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

ينقل HTTP Push هذا الجزء من التكامل إلى IoT Logic. يرسل النظام الخارجي البيانات، وتربط التعيينات المُعدة هذه البيانات بأجهزة التتبع، بينما يحدد التدفق ما يحدث بعد ذلك.

في الحلول التي يكون فيها الغرض الأساسي من المكوّن المخصص هو استقبال البيانات الخارجية وربطها بمعالجة بيانات الاتصالات عن بُعد، يمكن لـ HTTP Push إزالة مكوّن كامل من البنية التحتية. وبالنسبة إلى مزود خدمات الاتصالات عن بُعد (TSP) أو المُكامل الذي ينشر حلولًا مماثلة لعدة عملاء، يعني ذلك أيضًا خدمة أقل يجب نشرها وصيانتها في كل عملية تنفيذ.

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

HTTP Push وآليات التكامل الأخرى في Navixy

يؤدي كل من HTTP Push وNavixy Generic Protocol وواجهة Navixy API أدوارًا مختلفة.

الآلية	الدور
إثراء البيانات باستخدام HTTP Push	إدخال السمات الخارجية إلى IoT Logic وربطها بجهاز تتبع موجود لمعالجتها إلى جانب بيانات القياس عن بُعد الخاصة به
Navixy Generic Protocol	ربط مصدر يعمل كمصدر مستقل لبيانات الاتصالات عن بُعد ويوفر بيانات القياس عن بُعد الخاصة به
Navixy API	إنشاء كيانات Navixy وإعداداتها المدعومة وقراءتها وتحديثها وحذفها

ويُعد الفرق بين HTTP Push وNGP مهمًا بشكل خاص.

مع NGP، يكون النظام المتصل هو مصدر بيانات القياس عن بُعد. أما مع HTTP Push، فتصل بيانات القياس عن بُعد من جهاز التتبع بشكل مستقل بالفعل، بينما يضيف نظام آخر معلومات إضافية مرتبطة بجهاز التتبع هذا.

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

تؤدي Navixy API وظيفة مختلفة. فهي توفر عمليات CRUD برمجية للكيانات والإعدادات المدعومة في المنصة، وليست مدخلًا بديلًا لمعالجة بيانات خارجية عشوائية داخل تدفق IoT Logic.

قد تظل برمجة تكامل مخصص ضرورية في حالات استثنائية لا تستطيع فيها آليات المنصة المتاحة تلبية متطلبات التكامل. ولكن لا ينبغي أن تكون ضرورية لمجرد أن نظامًا تابعًا لجهة خارجية يمتلك بيانات يجب استخدامها في معالجة IoT Logic.

الإعداد لا يزال يتطلب عملًا هندسيًا

لا يؤدي نقل طبقة النقل والتعيين إلى الإعداد إلى إلغاء عقد التكامل.

لنأخذ التعيين التالي:

VEH-318 → جهاز التتبع 12345

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

تحتاج أسماء السمات وأنواعها إلى القدر نفسه من الانضباط. فأسماء مثل:

maintenance_due
maintenance_work_order
odometer_at_service

أسهل في الصيانة من الحقول العامة مثل status أو id أو value. وإذا كان التدفق يتوقع:

{
  "maintenance_due": true
}

فإن تغيير القيمة إلى "yes" يغيّر العقد الذي تعتمد عليه آلية المعالجة التي تستهلك هذه البيانات.

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

أثناء التشغيل الأولي، يمكن أن يساعد Data Stream Analyzer في التحقق من وصول المعرّف والتعيين والسمات والمعالجة اللاحقة المتوقعة إلى التدفق بصورة صحيحة.

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

إعداد إثراء البيانات باستخدام HTTP Push

يتم إعداد إثراء البيانات باستخدام HTTP Push في عقدة Data Source داخل IoT Logic.

حدد أجهزة التتبع التي يجب أن تستقبل البيانات الخارجية، ثم اضبط HTTP Push كمصدر بيانات برمجي. بعد حفظ التدفق، يوفر IoT Logic عنوان URL الخاص بـ HTTP Push الذي سيستخدمه التطبيق الخارجي. وتتم مصادقة الطلبات باستخدام مفتاح API.

بعد ذلك، اختر المعلمة الواردة التي ستُستخدم كمفتاح أساسي، ثم قم بإعداد تعييناتها مع أجهزة التتبع المقابلة:

VEH-318 → جهاز التتبع 12345
VEH-319 → جهاز التتبع 12346
VEH-320 → جهاز التتبع 12347

يمكن للتطبيق الخارجي بعد ذلك إرسال:

{
  "vehicle_ref": "VEH-318",
  "maintenance_due": false,
  "work_order": "WO-98311",
  "odometer_at_service": 182300
}

يحدد IoT Logic جهاز التتبع المرتبط بـ VEH-318 من خلال التعيين المُعد، ويجعل السمات المرسلة متاحة للمعالجة إلى جانب البيانات التي تصل بشكل مستقل من جهاز التتبع.

للاطلاع على حقول الإعداد الدقيقة ومتطلبات HTTP Push الحالية، راجع وثائق إثراء البيانات باستخدام HTTP Push.

السياق الخارجي يصبح جزءًا من منطق الاتصالات عن بُعد

يوفر HTTP Push لبيانات الأعمال الخارجية مدخلًا مباشرًا إلى IoT Logic. ويمكن لهذه البيانات أن تدخل في شروط إلى جانب بيانات القياس عن بُعد من جهاز التتبع، أو أن تبدأ مهام سير عمل تستمر من جانب نظام الاتصالات عن بُعد.

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

هل لديك سيناريو يجمع بين البيانات الخارجية وبيانات القياس عن بُعد؟ تواصل مع فريقنا لمناقشة كيفية تنفيذه باستخدام IoT Logic.