تحديد التكلفة في اليوم

تستخدم "أداة مزامنة دليل Google Cloud" مفتاح المستخدم لتحديد مشترك عند التواصل مع "هيئة حماية البيانات". يمكن للتطبيقات التي يمكنها الوصول إلى MSISDN الخاص بالمستخدم أن تستخدم هذا المفتاح باعتباره user_key. من ناحية أخرى، تحتاج التطبيقات التي لا يمكنها الوصول إلى MSISDN إلى إنشاء معرّف خطة مشغّل شبكة الجوّال (CPID) بدون التعرُّف على MSISDN. في ما يلي وصف للآلة التي تحدد معرّف CPID.

مسار مكالمة CPID

الشكل 2: مسار الاتصال لإنشاء معرِّف CPID.

  1. يستخدم تطبيق Google في UE واجهة برمجة تطبيقات داخلية من Google لاسترداد عنوان URL لنقطة نهاية CPID من GTAF. يتم تحديد المشغّل باستخدام عنوان IP العلني للعميل، ورقم تعريف MNC ومركز عملائي لشريحة SIM النشطة. في حال MVNO، ستستخدم Google SPN وGID1 لتحديد MVNO.
  2. يُصدِر البرنامج طلب HTTP GET إلى نقطة نهاية CPID. قد يتيح عامل التشغيل إرسال الطلب عبر HTTPS.
  3. قد يستخدم عامل التشغيل MAY وظيفة "فحص الحزمة الداخلية" لتحديد طلب وإدخال رقم هاتف المستخدم في الطلب كرأس HTTP.
  4. تتلقّى نقطة نهاية CPID الطلب ويتم إنشاء معرّف CPID وعرض CPID مع UE مع مدة بقاء (TTL) تشير إلى المدة التي يمكن أن يستخدمها UE خلالها.

قد يستخدم المُشغِّل أيضًا عناوين IP بدلاً من أسماء النطاقات في عنوان URL لنقطة نهاية CPID، إذا كان ذلك ممكنًا. قد تكون عناوين IP في نطاق العنوان الخاص، ولكن يجب أن يتمكن عملاء Google من الوصول إليها داخل شبكة عوامل التشغيل.

يقدّم عامل التشغيل "SHALL" المعلومات التالية إلى Google كجزء من عملية الإعداد:

  1. معرّف CPID_URL الذي ستتواصل معه التطبيقات للحصول على معرّفات CPID. من المستحسن إدخال عنوان CPID_URL إلزامي، ولكن يمكن لعامل التشغيل توفير عناوين URL متعددة لزيادة مدى توفّر الميزة.
  2. قائمة بادئات عناوين IP التي يملكها مشغِّل شبكة الجوّال ورمز بلد الجوّال (مركز عملائي) ورموز شبكة الجوّال (MNC) التي يريد المشغِّل ربطها بعناوين CPID_URLs المقدَّمة. إذا كان عامل التشغيل يستخدم SPN أو GID1 للتمييز بين MVNOs في شبكته، يجب أن يقدّم عامل التشغيل هذه المعلومات أيضًا. ستستخدم Google هذه المعلومات لمطابقة العملاء مع نقاط نهاية CPID المقابلة، كما هو موضّح في الخطوة 1 من الشكل 2.

تنسيق الطلب هو: GET CPID_URL لأسباب قديمة، يجب أن تتمكّن نقطة نهاية CPID من دعم طلب، مثل ما يلي:

GET CPID_URL?app={app_id}

يمكن أن تتجاهل نقطة نهاية CPID معلَمة عنوان URL التي تتضمّن {app_id} عند إنشاء CPID. ولكن يجب أن يتمكّن من معالجة طلب يحتوي على المَعلمة.

قد يتضمّن الطلب المُرسَل إلى نقطة نهاية CPID عنوان Accept-Language. في حال تضمين العنوان، حينئذٍ يمكن للمستخدمين قراءة السلاسل في التحديثات التي ترسلها "هيئة حماية البيانات" باستخدام واجهة برمجة التطبيقات لمشاركة خطة بيانات الجوّال، ويجب استخدام الإعدادات المقدَّمة في طلب CPID.

في كل مرة يُصدر فيها العميل طلب GET CPID_URL، يجب أن يتلقى معرِّف CPID جديدًا. في حال نجاح إنشاء معرِّف CPID، يجب أن تعرض نقطة نهاية CPID استجابة 200 OK. يجب أن يحتوي نص الاستجابة على مثال CPIDResponse.

{
    "cpid": "<CPID_string>",
    "ttlSeconds": 2592000
}

يجب أن يكون معرّف CPID المعروض صالحًا لمدة ttlSeconds ثوانٍ حتى إذا طلب أحد المشتركين معرّفات CPID أخرى بعد ذلك. تنصح Google باستخدام قيمة مدة البقاء (TTL) تبلغ 30 يومًا وليس أقل من 14 يومًا للحصول على أفضل تجربة للمستخدم. ستعمل ترميز GTAF على ترميز CPID وفقًا لمعيار RFC2396 في الاستدعاءات اللاحقة لهيئة حماية البيانات.

معرِّف CPID

في ما يلي الطريقة المُقترَحة لنقطة نهاية CPID لإنشاء معرِّف CPID:

CPID_string = Base64(AES(MSISDN + TimeStamp + language, secret))

تعمل نقطة نهاية CPID على ربط MSISDN واللغة التي يرسلها العميل في عنوان قبول اللغة والطابع الزمني العالي الدقة وتشفيرها عبر AES باستخدام مفتاح secret. يجب أن يتطابق الطابع الزمني مع الوقت الذي تنتهي فيه صلاحية معرّف CPID. الناتج المشفر هو Base64. بالإضافة إلى ذلك، عند استخدام معرّف CPID في عنوان URL، يجب أن يكون بترميز عنوان URL للتعامل مع الأحرف الخاصة (/+=) المستخدمة في Base64. وعلى وجه الخصوص، عندما توجّه "هيئة حماية البيانات" (DAF) "هيئة حماية البيانات" أو عندما تطلب "هيئة حماية البيانات" واجهة برمجة التطبيقات لمشاركة خطة بيانات الجوّال، يجب أن يكون معرّف CPID بترميز عنوان URL.

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

وحدة تخزين CPID

إنّ رقم CPID الذي تم إنشاؤه باستخدام الآلية الموضّحة أعلاه ليس من الضروري تخزينه في قاعدة بيانات. يمكن اشتقاق المعلومات ذات الصلة للتعامل مع المكالمات الواردة إلى "هيئة حماية البيانات" من "رقم تعريف التكلفة في اليوم".

  1. عندما تتلقّى "هيئة حماية البيانات" مكالمة من "GTAF" لحالة الخطة أو العروض، يمكن استنتاج ذلك من خلال فك تشفير رقم CPID واستخراج رقم MSISDN.
  2. يمكن استنتاج وقت انتهاء صلاحية معرّف CPID من خلال فك تشفير CPID ثم تجاوز الطابع الزمني لانتهاء الصلاحية.

متطلبات مدى التوفّر والسعة

إذا لم يتمكّن العملاء من استرداد قيمة CPID، لن يتمكّنوا من الوصول إلى أي معلومات من واجهة برمجة التطبيقات لخطة بيانات الجوّال. لهذا السبب، يجب أن يتّخذ عامل التشغيل "الإجراءات" اللازمة لضمان توفّر نقطة نهاية CPID. وتشمل هذه التدابير توفُّر مثيلات متعددة من نقاط نهاية CPID ووظائف DPI، فضلاً عن تكرار البيانات في كل من الموقع الجغرافي والشبكة والشبكة للدالتَين معًا وضمان أن تكون موارد النظام والسعة كافية. بالإضافة إلى ذلك، يجب أن تتوفّر لدى نقطة نهاية CPID بالإضافة إلى دالة DPI التي تُدخِل العنوان سعة كافية للتعامل مع حمل كل برامج Google التي تطلب أرقام CPID. يمكن أن تستخدم نقطة نهاية CPID قيمًا أكبر في الحقل ttlSeconds لتقليل وتيرة إنشاء معرّفات CPID.

حالات الخطأ

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

{
    "errorMessage": "<error message>",
    "cause": "USER_ROAMING"
}

يجب أن تعرض نقطة نهاية CPID ما يلي بناءً على السيناريو:

  1. إذا تم تلقّي طلب CPID لمستخدم لا ينتمي إلى شبكة المشغّل (على سبيل المثال، مستخدم ينتمي إلى مشغّل آخر ولكنه تجوّل على الشبكة التي تقدّمها نقطة نهاية CPID هذه) أو لم يختَر مشاركة معلومات خطة البيانات مع Google، يجب أن تعرض نقطة نهاية CPID رمز حالة HTTP 403 مع USER_ROAMING أو USER_Opt_OUT أو INELIGIBLE_FOR_SERVICE.
  2. إذا تم تلقّي طلب CPID برقم هاتف غير صالح، يجب أن تعرض نقطة نهاية CPID HTTP 400 مع سبب خطأ INVALID_NUMBER.
  3. إذا كان الطلب إلى نقطة نهاية CPID غير صحيح بأي طريقة أخرى، يجب أن تعرض نقطة نهاية CPID HTTP 400 مع ظهور ERROR_CAUSE_UNSPECIFIED باعتباره السبب.
  4. أما بالنسبة إلى الأسباب الأخرى المتعلقة بالأخطاء، فيتم قبول أي رمز خطأ HTTP متوافق. وعلى وجه الخصوص، يُعد HTTP 500 سببًا مناسبًا لأي خطأ داخلي في نقطة نهاية CPID.