ابنِ نموذج بيانات يناسب أعمال التليماتكس لديك مع Business Data Repository

عادةً ما تبدأ منصة التليماتكس بمجموعة مألوفة من الكائنات: المركبات، والأجهزة، والسائقون، والسياجات الجغرافية.

لكن العمليات الفعلية لدى العملاء نادرًا ما تتوقف عند هذا الحد.

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

وهنا تحديدًا يبدأ نموذج البيانات الجامد في المنصة بالتحول إلى مشكلة.

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

الطرق الثلاث تعمل. لكن أيًّا منها لا يصمد مع الوقت.

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

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

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

وتمثّل GraphQL Repository API العقد الذي يقف خلف هذه المرونة. فهي تمنح المتكاملين طريقة متسقة لتعريف كيانات الأعمال المترابطة هذه والعمل معها دون انتظار تغييرات في مخطط بيانات المنصة. ومن المخطط توفير SDK بلغات Kotlin وTypeScript وPython لتسهيل استخدام النموذج نفسه من اللغات التي يعمل بها المتكاملون بالفعل، مع خادم MCP مخطط فوق الكيانات نفسها للعمل معها من Navixy ومن أدوات خارجية.

سياق مهم في البداية: لم تُطلق Business Data Repository API وSDK للعموم بعد. فالتوثيق الحالي هو توثيق معاينة، وقد تتغير البنى أو السلوكيات قبل الإصدار. لذا يُقرأ هذا النص باعتباره اتجاه النموذج وسبب أهميته، لا دليل نشر إنتاجي لليوم.

نموذج العمليات المترابطة

من المفيد التفكير في Business Data Repository API عبر هذا النموذج المكوّن من خمس طبقات:

1. النوع — عرّف شكل الكائن الذي تستخدمه أعمالك فعليًا.
2. الربط — اربط السجلات ببعضها كعلاقات، لا كنص حر.
3. التحقق — افرض جودة البيانات على مستوى نوع الحقل.
4. الكتالوج — وحّد المفردات المضبوطة مرة واحدة وأعد استخدامها في كل مكان.
5. التتبع — احتفظ بسجل التغييرات حتى لا يضيع السياق التشغيلي مع مرور الوقت.

الحقول المخصصة جزء من هذا، لكنها طبقة واحدة فقط.

ابدأ من كائنات الأعمال، لا من الإعدادات الافتراضية للمنصة وحدها

الحقول المخصصة مفيدة، لكنها تحل جزءًا فقط من المشكلة.

ففي بعض الأحيان لا تحتاج إلى سمة إضافية على المركبة، بل إلى نوع آخر من الكائنات في نموذجك التشغيلي.

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

صُمِّمت Business Data Repository API لتتيح لمساحة العمل تعريف أنواعها الخاصة ضمن عائلتين من الكائنات: أنواع الأصول وأنواع الكائنات الجغرافية. فكل ما ورد في القائمة أعلاه — المقطورة، والشحنة، وعقد الخدمة، ووحدة التأجير، وقطعة المعدات — يُنمذج كنوع أصل خاص بك، بسماته الخاصة؛ أما المناطق والمواقع ومناطق الخدمة فهي أنواع كائنات جغرافية.

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

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

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

وللاطلاع على كيفية نمذجة Navixy للأصول المصنّفة بالأنواع اليوم، راجع دليل العمل مع الأصول.

اربط السجلات بدل تخزين المعرّفات كنص عادي

إنشاء السجلات لا يكون مفيدًا إلا إذا أمكن ربطها ببعضها بشكل ذي معنى.

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

صُمِّمت Repository API حول علاقات مرجعية بين السجلات.

وهذا يغيّر ما يمكن للمتكاملين بناؤه:

• vehicle -> trailer
• equipment -> service contract
• shipment -> vehicle
• asset -> customer — يُمثَّل العميل كمدخل في كتالوج أو كنوع أصل تعرّفه بنفسك

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

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

أضف سمات تناسب وظيفة كل كائن

بمجرد وجود أنواع الكائنات، تصبح الحقول المخصصة أكثر قيمة بكثير.

إذ يمكن لكل نوع أن يحمل سماته الخاصة به بدل مشاركة سلة واحدة من «الحقول الإضافية» يستخدمها الجميع.

قد تحتاج المقطورة إلى رقم VIN وحدود الحمولة وتواريخ الفحص. وقد يحتاج عقد الخدمة إلى رقم العقد وتواريخ السريان والحالة. وقد تحتاج وحدة التأجير إلى حقول الاستخدام والتسليم.

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

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

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

وللاطلاع على أحدث التفاصيل مع تطور المعاينة، راجع تنفيذ الحقول المخصصة.

استخدم الكتالوجات للحفاظ على اتساق لغة الأعمال

كثير من سمات الأعمال تأتي من مفردات مضبوطة: الشركات المصنّعة، وفئات الخدمة، وأصناف البضائع، وهياكل الفروع، ومراكز التكلفة.

وبدون كتالوجات، ينتهي الأمر بالفرق عادةً إلى تشتت في طريقة الكتابة:

• Bosch
• BOSCH
• Bosch GmbH

تتضمن Business Data Repository API بنى كتالوج يعرّفها المستخدم، بحيث يمكن توحيد تلك القيم مرة واحدة وإعادة استخدامها عبر الكائنات المرتبطة.

ومع اتساع النمذجة الخاصة بكل عميل، يصبح هذا من أكبر مضاعِفات الجودة: تنظيف أقل، وتعارضات أقل، وأخطاء تكامل أقل من نوع «الشيء نفسه بثلاث طرق كتابة».

احتفظ بسياق التغيير، لا بالحالة الراهنة فقط

في سير العمل التشغيلي، غالبًا ما لا تكفي القيمة الحالية.

فالسؤال الشائع ليس «ما القيمة التي يحملها هذا الكائن الآن؟» بل «ما القيمة التي كان يحملها عندما وقع هذا الحدث؟»

تتضمن Business Data Repository API سياق تغيير موجّهًا نحو سجل الكيان وتدقيقه، حتى يتمكن المتكاملون من بناء واجهات يهم فيها التسلسل الزمني ومصدر البيانات، لا الحالة الأحدث فقط.

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

أدِر عمليات التليماتكس الشائعة بقدر أقل من شيفرة الربط

كثيرًا ما يقضي المتكاملون وقتًا في مهام تشغيلية متكررة تقع بين «عمليات CRUD البسيطة» ومحركات سير العمل الكاملة.

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

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

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

لماذا يناسب GraphQL هذا النموذج

تستخدم Business Data Repository API تقنية GraphQL، وهي مناسبة تمامًا لنمذجة البيانات المترابطة.

إذ يمكن للمتكاملين طلب الحقول والكائنات المرتبطة التي تحتاجها الواجهة بالضبط، بدل جمع حمولات كاملة من عدة نقاط نهاية ثابتة ثم تجميعها معًا لاحقًا.

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

الخلاصة الأوسع

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

يجري بناء Business Data Repository API لجعل سياق الأعمال هذا قابلًا للنمذجة: عرّف البنى التي تحتاجها، واربطها، وتحقق منها، وتتبّع كيف تتطور.

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

وإذا أردت متابعة تطور هذا النموذج قبل الإصدار، ابدأ من فهرس توثيق Business Data Repository API، وتابع التحديثات في أدلة المعاينة، بما في ذلك سلوك التصفية والفرز للحقول المخصصة في مرجع تصفية الحقول المخصصة.