البنية المعمارية

    Headless Telematics: نواة جاهزة، وواجهتك أنت

    Headless Telematics نهج معماري تُتاح فيه وظائف النظام الخلفي التليماتي عبر واجهات API موثقة، وتبقى واجهة المزوّد اختيارية: يبني الفريق واجهته الخاصة فوق نواة جاهزة. واجهة ويب أو تطبيق جوال، سيناريو داخل إجراء العمل، أو تكامل مع نظام العمليات — الخيار لك، والنظام الخلفي يبقى نفسه.

    اطّلع على الوثائق انتقل إلى Composable Telematics
    واجهة API موثقةIoT Query — وصول للقراءةالواجهة تحت سيطرتك
    الطلب · SQL
    SELECT device_id, device_time, lat, lng
    FROM raw_telematics_data.tracking_data_core
    WHERE device_id = 104
    ORDER BY device_time DESC
    LIMIT 1;
    الرد · صف النتيجة
    { "device_id": 104,
    "device_time": "2026-07-21T14:02:11Z",
    "lat": 43.238, "lng": 76.889 }
    200 · raw_telematics_data · وصول للقراءة
    التعريف

    ما هي Headless Telematics

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

    • ابنِ بوابة، أو تطبيق جوال، أو سيناريو مدمجاً في إجراء العمل، أو تكاملاً مع نظام العمليات — خيار الواجهة لا يقتصر على شكل واحد.
    • فريقك مسؤول عن تجربة المستخدم، وإمكانية الوصول، وأمن التطبيق، والدعم، وإصدارات الواجهة التي يبنيها.
    • واجهة API الموثقة هي أساس البنية: عقد واحد يخدم الويب والجوال والسيناريو المدمج، ومستقبلاً الوكيل الذكي عبر MCP. Navixy MCP
    مسار التليماتية

    Headless — درجة بين white label وComposable Telematics

    تسلك التليماتية مساراً من الواجهة الجاهزة عبر بنية headless إلى منصة composable — ثم إلى بنية تحتية agent-ready يستخدم فيها البيانات والمنطق ليس البشر وحدهم بل الوكلاء الأذكياء أيضاً. وHeadless هي الدرجة التي يكون فيها النظام الخلفي مفتوحاً عبر API، وتصبح الواجهة ميدانك للتمايز.

    • white label وHeadless درجتان متجاورتان متكافئتان: اختر الواجهة الجاهزة حيث يؤتي ذلك ثماره، والواجهة الخاصة حيث تصبح الواجهة ميزتك.
    • تمنحك Headless بالفعل واجهة خاصة على نظام خلفي موثق — ويمكن اتخاذ خطوة نحو Composable Telematics على حدة، عند الحاجة إلى استقلال البيانات والمنطق. Composable Telematics
    كيف يعمل ذلك

    طبقة التطبيق تصل واجهتك بالنظام الخلفي التليماتي

    يضمنه النظام الخلفي التليماتي

    واجهة API موثقة ومخطط بيانات مستقر — مثل جدول raw_telematics_data.tracking_data_core في IoT Query.

    مخطط البيانات
    تتولاه واجهتك

    تستدعي طبقة التطبيق العمليات وتأخذ الحقول اللازمة فقط؛ ولا يتصل المتصفح بالنظام الخلفي مباشرةً.

    يضمنه النظام الخلفي التليماتي

    وصول للقراءة إلى بيانات التتبّع عبر اتصال IoT Query المتوافق مع PostgreSQL.

    إعداد الاتصال
    تتولاه واجهتك

    تحديد هوية المستخدمين وحفظ الأسرار وحدود الاستعلامات — من جانب حلّك.

    يضمنه النظام الخلفي التليماتي

    بيانات اعتماد اتصال لكل مثيل — عزل المستأجرين على مستوى النظام الخلفي.

    تتولاه واجهتك

    يُنسّق الفريق مع Navixy ربط المستخدم بالمستأجر وتدوير المفاتيح قبل الإطلاق.

    يضمنه النظام الخلفي التليماتي

    المنطق التشغيلي في IoT Logic: استقبال البيانات والتحويلات والإجراءات والتوجيه.

    عمليات المنطق
    تتولاه واجهتك

    الواجهة وإمكانية الوصول ومعالجة الأخطاء ودعم المستخدمين — نطاق مسؤوليتك.

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

    • تتحقق طبقة التطبيق من صلاحيات الوصول، وتراعي سياق المستأجر، وتخزّن استعلامات النظام الخلفي مؤقتاً.
    • السجلات ومعرّفات الطلبات وفحوص الإصدارات تربط الطبقات — فيمكن تشخيص العطل في دقائق.

    ثلاث عمليات تُحدِّد بنية Headless لديك

    تُتحقق كل منها على حدة: قراءة بيانات التتبّع، وتحديد هوية المستأجر، ودورة حياة الإصدارات.

    SQL على بيانات حيّة

    إعداد الاتصالمخطط البيانات
    01SELECT *
    02FROM raw_telematics_data.tracking_data_core
    03LIMIT 10;
    raw_business_dataraw_telematics_data
    tracking_data_core

    وصول موثق متوافق مع PostgreSQL إلى جدول raw_telematics_data.tracking_data_core — تقرأ الحقول اللازمة مباشرةً.

    المنطق التطبيقي — استقبال البيانات وتحويلات JEXL والتوجيه — هو IoT Logic في طبقة التطبيق، لا عقد النظام الخلفي. عمليات المنطق

      اطّلع على الوثائق
      إعادة توزيع المسؤولية

      تحصل على واجهتك — وعلى مسؤوليتها

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

      • يصمم فريقك التفاعل، ويتولى إمكانية الوصول وأمن الواجهة الأمامية والإصدارات ودعم العملاء.
      • يحدد مالكو النظام الخلفي والتطبيق المصادقة والتفويض وحدود معدلات الطلبات وإدارة الإصدارات وترتيب التصعيد قبل الإطلاق.
      • يُختبَر سيناريو مستخدم واحد كاملاً — رفض الوصول، والبيانات المتقادمة، والإخفاق الجزئي، وتغيير API لدى المزوّد: هكذا تُتحقق حدود المسؤولية، لا مجرد استعلام ناجح واحد.
      • يبقى white label خياراً سريعاً واقتصادياً إذا لم تُنشئ الواجهة الخاصة قيمة ملموسة للعميل. White-label
      حدود النظام الخلفي
      فريقك مسؤول عن
      • مصادقة مستخدمي البوابة والجلسات
      • عرض البيانات وإمكانية الوصول ومعالجة الأخطاء
      المنصة توفّر
      • واجهة API موثقة للنظام الخلفي التليماتي
      • بيانات اعتماد اتصال لكل مثيل
      تحقُّق عبر سيناريو واحد

      اجتَز سيناريو واحداً — من الاتصال إلى الدعم

      هكذا تتضح حدود المسؤولية عملياً، قبل أول سطر من الواجهة.

      1. 01تحديد هوية المستخدم
      2. 02الاتصال وفق الوثائق
      3. 03استعلام على جدول البيانات
      4. 04العرض والدعم
      5. 05المراقبة والتغييرات
      اطّلع على الوثائق
      أسئلة حول البنية

      أسئلة حول Headless Telematics

      ما هي Headless Telematics؟
      هي نهج معماري يُفتح فيه النظام الخلفي عبر واجهات API موثقة، وتبقى واجهة المزوّد اختيارية. وظائف النظام الخلفي التليماتي متاحة عبر واجهات API موثقة، ويبني الفريق واجهته الخاصة فوق نواة جاهزة. أما جهاز التتبّع أو الكاميرا أو وحدة TCU أو المركبة بلا شاشة فموضوع عتادي منفصل لا صلة له بهذا المصطلح.
      هل يعني ذلك أن كل وظيفة في النظام الخلفي متاحة عبر API؟
      ليس تلقائياً. تختلف تركيبة العمليات والصلاحيات المتاحة بحسب سطح المنتج — تحقّق منها في الوثائق الحالية لكل سيناريو قبل تصميم الواجهة.
      من المسؤول عن الأمن في نموذج Headless Telematics؟
      المسؤولية مقسومة عند حدود النظام الخلفي. تتولى Navixy حماية النظام الخلفي التليماتي ضمن الحدود المتفَق عليها؛ ويتولى فريقك واجهته الخاصة والجلسات والتكاملات والعمليات التشغيلية المحيطة بها.
      متى يُفضَّل اختيار white label بدلاً من Headless؟
      عندما لا تُنشئ الواجهة الخاصة قيمة ملموسة للعملاء. تنطلق الواجهة الجاهزة بعلامتك دون تطوير واجهة أمامية. white label وHeadless درجتان متكافئتان: اختر بحسب الموضع الذي يكون فيه اختلاف الواجهة مهماً فعلاً للسوق. White-label
      هل ينبغي أن يتصل المتصفح بواجهة API التليماتية مباشرةً؟
      الأوثق عادةً عبر طبقة تطبيق يديرها فريقك. تُوحّد طبقة التطبيق التفويض وسياق المستأجر والأسرار وحدود الاستعلامات ومعالجة تغييرات المزوّد — مرة واحدة، لا في كل تطبيق عميل على حدة.
      كيف تتحقق من بنية headless قبل الإطلاق؟
      اجتَز سيناريو مستخدم حقيقياً واحداً كاملاً. في سيناريو قراءة آخر الإحداثيات، تحقّق لا من الاستعلام الناجح فحسب، بل أيضاً من رفض الوصول، والبيانات المتقادمة أو الغائبة، ومهل الانتظار، والإخفاق الجزئي، وتغيير المخطط، ومسار التصعيد إلى الدعم. إعداد الاتصالمخطط البيانات
      هل يمكن إبقاء الواجهة الجاهزة خياراً بديلاً إلى جانب حل headless؟
      نعم، إذا سمح بذلك المنتج والشروط التجارية. تجعل Headless Telematics واجهة المزوّد خياراً لا شرطاً إلزامياً — أما توافق سيناريوهات جاهزة وخاصة محددة مع نموذج نشرك فراجِعه مع Navixy على حدة. White-label
      متى تبدأ Headless Telematics بتحقيق عائدها؟
      عندما يبرّر إجراء عمل مهم للعميل تطوير واجهة خاصة. تعتمد المدة على جاهزية الواجهات، وتصميم الهوية والمستأجرين، وتطوير التطبيق، واختبارات التكامل، والمراجعة الأمنية، وقابلية الرصد، وحجم الترحيل — ولا توجد مدة واحدة تنطبق على كل السيناريوهات.
      هل يمكن لوكيل ذكاء اصطناعي أو أداة مطوّر العمل مع نظام headless الخلفي؟
      نعم، عبر الوصول الموثق نفسه المستخدم في أي تكامل عادي. تنشر Navixy واجهة MCP لحسابات المستخدمين وحسابات Admin Panel، إضافةً إلى MCP عام للوثائق. ويمرّ الوكيل بالمصادقة نفسها ويعمل ضمن حدود الوصول نفسها التي يعمل فيها أي تطبيق. Navixy MCP

      ابنِ واجهتك على النظام الخلفي الموثق من Navixy

      ابدأ بسيناريو مستخدم واحد: حدّد عمليات النظام الخلفي اللازمة، ومناطق المسؤولية، ودورة الحياة — قبل أن يكتب الفريق أول سطر من الواجهة.

      اطّلع على الوثائق انتقل إلى Composable Telematics

      تفتح Headless Telematics النظام الخلفي عبر API — تحقّق من تركيبة العمليات لسيناريوك في الوثائق.