Use case

استبدال backend من نوع legacy دون إيقاف كل من يعتمد عليه

عقد مستقر أمام مجال legacy واحد يتيح ترقية الـ backend أو استبداله وفق جدوله الخاص، دون اختبار منسّق مع كل مستهلك.

النسخة التنفيذية

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

المشكلة

لا يمكن تغيير الـ backend من نوع legacy دون كل من يعتمد عليه. يصل المستهلكون إلى المجال نفسه عبر واجهات API مملوكة للموردين، وحِزم SDK من الموردين، والوصول المباشر إلى قاعدة البيانات، والملفات أو الطوابير الخاصة، لذا تحتاج كل ترقية للـ backend إلى اختبار منسّق معهم جميعًا، ويضيف كل مستهلك جديد اعتمادًا آخر على دورة إصدارات الـ legacy.

ما الذي يتغيّر

  1. تحديد مجال واحد — كتالوج المنتجات، أو العميل، أو مخزون الخدمات، أو الـ billing — بدلًا من كشف تطبيق الـ legacy بأكمله.
  2. نشر عقد مستقر متوافق مع TM Forum Open API.
  3. مواءمة نظام الـ legacy خلفه عبر mappings قابلة لإعادة الاستخدام، مع BPMN للعمليات متعددة الخطوات.
  4. تشغيل الواجهة بوصفها منتجًا له مالك وإصدارات وأمن وخطة إيقاف.

ما الذي تحصلون عليه

  • تسير ترقية الـ backend واستبداله وفق جدولهما الخاص.
  • يعتمد المستهلكون على العقد، لا على نظام الـ legacy، ويتكامل كل مستهلك جديد مرة واحدة.
  • يُقاس التقدم: زمن التكامل، ونسبة إعادة الاستخدام، والاعتماديات التي أُوقفت.
Architect edition — استبدال backend من نوع legacy خلف عقد مستقر

المشكلة

منصات BSS و OSS متراكمة ذات واجهات مملوكة لمورديها، وبيانات مكررة، ومنطق عمليات مضمّن فيها. والتغيير في منصة واحدة ينتشر عبر القنوات والبرمجيات الوسيطة والأنظمة اللاحقة.

الحل القائم على MEF.DEV

  1. حدود المجالات. مجالات العميل والمنتج والطلب والخدمة والمورد والاستخدام والـ billing، باستخدام مصطلحات SID (Shared Information/Data) و eTOM حيثما ينطبق ذلك.
  2. عقود Open API ذات إصدارات. يُتاح كل مجال عبر واجهة متوافقة مع TM Forum؛ ويرتبط المستهلكون بالعقد المستهدف، لا ببنية الـ legacy.
  3. خدمات الواجهة (façade) والمحوّلات تترجم الموارد والعمليات والأحداث والإشعارات القياسية إلى الواجهات وهياكل البيانات المملوكة للموردين.
  4. عمليات عابرة للأنظمة منقولة إلى الخارج. ينتقل التنسيق إلى مسارات عمل BPMN تدير الحالة والمؤقتات وإعادة المحاولة والتعويض وتوجيه الاستثناءات.
  5. الاستبدال التدريجي. تُدخَل مكوّنات جديدة متوافقة مع ODA خلف العقد نفسه، مجالًا واحدًا أو وظيفة أعمال واحدة في كل مرة.
  6. دورة حياة مشتركة. التسجيل والمراجعة والإصدارات والنشر والتراجع والمراقبة والتدقيق للخدمات الجديدة؛ ويبقى الـ legacy على بنيته التحتية.

النتيجة

تتعايش أنظمة الـ legacy ومكوّنات ODA الجديدة خلف عقود مشتركة. ويصبح التحديث سلسلة من التغييرات في مجالات الأعمال بنتائج قابلة للقياس.

نموذج المكوّنات وأنماط النشر ومستويات التفويض متاحة على platform.mef.dev.

العمق التقني على platform.mef.dev ←

ثابت لكل القرّاء

TM Forum ODA · Open API

TM Forum ODA و Open APIs

يتيح MEF.DEV واجهات TM Forum Open APIs، ويلتزم بمبادئ ODA، وله قيد في TM Forum ODA Component Directory.

BSL 1.1

الترخيص

Business Source License 1.1: مجاني للاستخدام الإنتاجي الداخلي؛ و Enterprise Modules بمفتاح ترخيص؛ وكل إصدار يتحول إلى Apache 2.0 بعد أربع سنوات.

الاتحاد الأوروبي · on-premises · السحابة

الأمن والبيانات والولاية القضائية

شركة في الاتحاد الأوروبي؛ نشر في بنيتكم التحتية، وتسجيل دخول عبر SSO قياسي؛ تطوير وتسليم ودعم وفق نظام جودة ISO 9001:2015.

ISO 9001:2015

تطوير وأمن معتمدان

يُطوَّر WideCoup Convergent BSS و MEF.DEV ويُسلَّمان ويُدعَمان وفق نظام إدارة جودة ISO 9001:2015؛ واجتاز MEF.DEV تدقيقًا أمنيًا مستقلًا واختبار اختراق.

الشهادات والتدقيق ←

طلب وثيقة

 

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

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