Skip to main content
استخدم مصدر الدفع المخصص (Custom Push Source) عندما يرسل نظام ما السجلات إلى Living Security بدلًا من أن يستعلم عنها موصّل من كتالوج. يمكن للمُرسِل إرسال مصفوفات JSON أو ملفات CSV إلى نقطة نهاية HTTPS إقليمية.

قبل البدء

تحتاج إلى ما يلي:
  • صلاحية إدارة التكاملات ومفاتيح الوصول في Living Security
  • مُرسِل من جهة الخادم قادر على إجراء طلبات HTTPS POST
  • منطقة Living Security الخاصة بمؤسستك
  • اسم مصدر ثابت واسم تدفق واحد على الأقل
اسما المصدر والتدفق هما مفتاحا توجيه دائمان. يجب أن يتكوّن اسم المصدر من 1–64 حرفًا من الأحرف الإنجليزية الصغيرة أو الأرقام أو الواصلات. يُسمح أيضًا بالشرطات السفلية في أسماء التدفقات. ويجب أن يبدأ كلاهما بحرف أو رقم.
تعامل مع مفتاح وصول API بوصفه سرًّا. لا تضعه في شيفرة المتصفح، ولا تودعه في نظام التحكم بالمصدر، ولا ترسله في تذكرة دعم.

1. تسجيل المصدر والتدفقات

1

فتح مصدر الدفع المخصص

انتقل إلى الإعدادات ← التكاملات ← كتالوج، وابحث عن Custom Push Source، ثم حدّد إضافة.
2

تسمية المصدر

أدخل مفتاح توجيه المصدر ووصفًا اختياريًا. على سبيل المثال، استخدم custom-phishing-sim بدلًا من اسم عرض يحتوي على مسافات.
3

إضافة التدفقات

أضف كل تدفق سيستخدمه المُرسِل. يجب أن يكون زوج المصدر والتدفق موجودًا قبل أول عملية دفع؛ إذ يؤدي زوج غير معروف إلى إرجاع 404 Not Found.
4

حفظ المصدر

بعد الإنشاء، افتح المصدر ضمن الإعدادات ← التكاملات ← متصل. يعرض عرض Push via API نمط نقطة النهاية وعمليات التشغيل الأخيرة.

2. إنشاء مفتاح دفع واستيعاب

انتقل إلى الإعدادات ← Access Keys، وحدّد Create Access Key، ثم اختر النطاق Push Ingest. انسخ القيمة المُنشأة فورًا؛ إذ تُعرض مرة واحدة فقط. يرتبط المفتاح بمؤسسة واحدة في Living Security. لا يحتاج طلب الدفع إلى ترويسة للمؤسسة. راجع مفاتيح وصول API للاطلاع على التدوير والإلغاء.

3. اختيار نقطة النهاية الإقليمية

استخدم اسم المضيف الخاص بمؤسسة Living Security: أضف /push-ingest/{integrationKey}/{streamName}. المسار حساس لحالة الأحرف ويجب أن يطابق المصدر والتدفق المسجلين تمامًا.
string
مطلوب
اسم المصدر المسجل. استخدم 1–64 حرفًا من الأحرف الإنجليزية الصغيرة أو الأرقام أو الواصلات، على أن يبدأ بحرف أو رقم.
string
مطلوب
اسم التدفق المسجل. تنطبق القواعد نفسها، ويُسمح أيضًا بالشرطات السفلية.
string
مطلوب
أرسل مفتاح وصول الدفع والاستيعاب على الصورة Bearer <access-key>.
string
استخدم application/json لصيغة JSON أو text/csv لصيغة CSV. يمكن للخادم أيضًا اكتشاف مصفوفة JSON عند حذف هذه الترويسة.
string
معرّف UUID اختياري للمؤسسة. يحدد مفتاح الوصول المؤسسة بالفعل. إذا أرسلت هذه الترويسة، فيجب أن تطابق مؤسسة المفتاح؛ ولا يمكنها اختيار مؤسسة أخرى.

نص الطلب

أرسل مصفوفة JSON من المستوى الأعلى غير فارغة من الكائنات، أو بايتات ملف CSV مع صف رأس. لا يوجد حقل JSON مُغلِّف مُسمّى. يمكن أن تحتوي كل دفعة على ما يصل إلى 10,000 سجل و10 MB.

4. إرسال دفعة JSON

أرسل مصفوفة JSON غير فارغة عناصرها كائنات. Content-Type: application/json موصى به وتشترطه كثير من المنتجات المُرسِلة، مع أن Living Security يمكنها اكتشاف نص الطلب من نوع مصفوفة بدونه.
يُرجع الطلب الناجح 202 Accepted. تعرض علامة تبويب الخطأ 400 Bad Request عندما يكون نص JSON غير صالح:
يعني القبول أن الدفعة خُزّنت للمعالجة غير المتزامنة. ولا يعني أن كل سجل قد فُسِّر بالفعل إلى نشاط. بالنسبة إلى مثال 400، صحّح JSON أو أرسل CSV باستخدام Content-Type: text/csv، ثم أعد المحاولة.
string
مطلوب
معرّف التشغيل لهذه الدفعة المقبولة. احتفظ به للتحقق من حالة المعالجة.
number
مطلوب
عدد السجلات المقبولة والمخزّنة.
string
مطلوب
اسم المصدر المستخدم في عملية الدفع هذه.
string
مطلوب
اسم التدفق المستخدم في عملية الدفع هذه.

إرسال CSV بدلًا من ذلك

اضبط Content-Type: text/csv وأرسل بايتات الملف، كما هو موضح في مثال الطلب CSV file أعلاه. يوفّر الصف الأول أسماء الحقول. يتحول النص المنطقي إلى قيمة منطقية، ويتحول النص الرقمي العادي إلى رقم. أما القيم ذات الأصفار البادئة، والأعداد الصحيحة الكبيرة غير الآمنة، والتواريخ، وسائر النصوص فتبقى سلاسل نصية. تؤدي الخلايا الفارغة إلى حذف الحقل المقابل. وتُرفض الصفوف المشوهة وعلامات الاقتباس غير المتوازنة وملفات UTF-16.

حدود الطلبات وإعادة المحاولة

قسّم عمليات التصدير الأكبر إلى دفعات تستوفي كلا الحدين. انتظر كل استجابة واحتفظ بقيمة runId المُرجعة في سجلات المُرسِل. يُرجع حد المؤسسة المصادَق عليها المعتاد 503 وليس 429، ولذلك تتعامل المُرسِلات عبر Webhook معه على أنه قابل لإعادة المحاولة. يُرجَع 503 قبل تخزين الدفعة؛ ولا تؤدي إعادة إرسال الدفعة نفسها بعد الفاصل الزمني المذكور إلى تكرار تشغيل مقبول.

التحقق من تدفق البيانات

افتح Custom Push Source وراجع Push History. تأكد من التدفق وعدد السجلات ونسبة المفتاح وحالة المعالجة. يمكن بعد ذلك أن تتحول البيانات التي لها مفسّر مُصان إلى أشخاص ونشاط موحَّد. أما البيانات التي ليس لها مفسّر فتبقى مخزّنة لكنها لا تنتج نشاطًا.
استخدم أسماء الحقول الدقيقة وبنية الحمولة من الدليل الخاص بالمزوّد عند وجوده. يثبت 202 الناجح أن التسليم قد تم، لا أن مخططًا عشوائيًا يُطابَق مع نشاط Living Security.

قائمة التحقق لاستكشاف الأخطاء وإصلاحها

  • انسخ نقطة النهاية من المصدر الصحيح واستبدل عنصر التدفق النائب.
  • أرسل مفتاح الوصول على الصورة Authorization: Bearer …؛ فـ x-api-key غير مقبول.
  • تأكد من أن النص مصفوفة JSON من المستوى الأعلى، وليس كائنًا واحدًا أو غلافًا حول السجلات.
  • تأكد من هجاء المصدر والتدفق، بما في ذلك الواصلات والشرطات السفلية وحالة الأحرف.
  • راجع Push History قبل إعادة إرسال دفعة فُقدت استجابتها.
  • عند التواصل مع دعم Living Security، أرفق المؤسسة والمصدر والتدفق ووقت الطلب وrunId عند توفره وحالة الاستجابة. لا ترفق مفتاح الوصول أو حمولة الأحداث.

ذو صلة

Zscaler ZIA Cloud NSS

قم بإعداد خلاصة سجلات ويب مدعومة من Zscaler باستخدام المصدر والتدفق والترويسات وبنية JSON المحددة بدقة.

مفاتيح وصول API

أنشئ بيانات الاعتماد محددة النطاق وأدِرها وألغِها.

مصادر بيانات الإشارات

تعرّف كيف يدعم النشاط المُفسَّر للتكاملات الإشارات.