👂🏾 👩🏾‍🤝‍👨🏻 👩🏿‍🔬 كيفية ترحيل عملية كبيرة من IBM BPM إلى Camunda وعدم إيقاف تطوير الميزات 💹 🌂 💖

مرحبًا ، اسمي دينيس ، أعمل في Tinkoff وأعمل أنظمة BPM. في هذه المقالة ، سأخبرك بكيفية الترحيل من تراث الأنظمة إلى IBM BPM إلى محرك معالجة Camunda مفتوح المصدر باستخدام مثال عملية كبيرة. وفي النهاية سوف أدعوكم إلى الاجتماع الرابع حول Camunda ، الذي سيعقد في 27 فبراير في Tinkoff ، في موسكو (مترو Vodny Stadion) في المساء.

أنظمة BPMS و BPMN كطريقة لبرمجتها

إن فكرة أنه من خلال البرمجة يمكن بيعها بشكل جيد ، فإن السوق ينمو من سنة إلى أخرى. بعض الشركات تحصل على نتائج رائعة حقًا .
للقيام بمشاريع جيدة والبيع بنجاح ، يجب أن تكون أنظمة BPMS ، بالإضافة إلى "تناول" ملفات BPMN ، قادرة أيضًا على:

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

استخدمنا IBM BPM BPMS في Tinkoff ، مما ساعدنا على التطور نظرًا لتعقيدها وتغطيتها المقبولة لهذه الميزات. لكننا قررنا رفضه.

أسباب التخلي عن IBM BPM

لقد أدركنا أنه من الوظائف الرائعة لنظام BPMS نستخدم فقط:

تفسير ملفات BPMN
الوقوع في التعليمات البرمجية

تم نقل أشياء أخرى إلى أنظمة أخرى ، على سبيل المثال:

, — , , . , BPMS. , — CRM Siebel.
Siebel CRM-. Siebel , — - UI.
تم نقل تخزين البيانات في مكان ما إلى Siebel - في الحالات التي يحتاج فيها العديد من المستهلكين إلى عمليات CRUD على البيانات ، وفي مكان ما - في تطبيقات منفصلة. يسمح لك IBM BPM بمحاكاة البيانات بأسلوب علائقي ، ويقوم بإنشاء لوحات للنموذج. لكنها تخزنها كلها في قاعدة بيانات واحدة لجميع العمليات ، مما يخلق اتصالًا إضافيًا وتحميلًا على قاعدة البيانات.
بالنسبة لقواعد العمل ، نستخدم تقليديًا IBM ODM ، والآن بدأنا في استخدام إطار عمل Kotlin الخاص بنا.
عادة ، في أسلوب التطوير ، لم نتعلم كيفية اختبار التطبيقات على IBM BPM.

كانت هناك أسئلة عامة لم نحبها:

لقد تحولنا إلى Kotlin و Spring ، وهو أمر صعب في IBM BPM.
عدد قليل جدًا من المتخصصين أو الراغبين في العمل مع هذا المنتج.
صعوبات التطوير المشترك للمخططات / التعليمات البرمجية ، وهي في الأساس طريقة احتكار للتنمية.
4 3 ( ~40 ), .

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

على سبيل المثال ، كان هناك رمز إرسال SMS تم استخدامه من قبل منتجين - خدمات التسوية النقدية والمحاسبة الخارجية. في السابق ، كان النص مشفرًا على مستوى المكونات ، ولكن الآن أرادت عملية "الاستعانة بمصادر خارجية للمحاسبة" نقل نص رسالة SMS من العملية. لكن عملية CSC لم ترغب في ذلك ، ولكن يجب إجراء التغييرات في كل مكان.

أو يمكن للحشرات العادية أن تضع القاعدة بأكملها بحيث لا تعمل العديد من المنتجات ، على الرغم من أنها ليست مسؤولة.

كتب زميلي نيكولاي في منشور سابق لماذا اختاروا كاموندا .

ما هي العملية الكبيرة

قررنا نقل العملية الكبيرة من IBM (ولكن في البداية ، قمنا بالتدريب على عملية صغيرة):

أكثر من 100 ألف حالة شهريًا.
أكثر من 70 ساحة
أكثر من 30 عملية دمج مع أنظمة أخرى
تراكم سريع النمو

هذه هي عملية فتح حساب جاري في Tinkoff Business. لم يكن من الممكن نقل مثل هذه العملية في نهج واحد ، وستكون هناك حاجة إلى فترة توقف لمدة 3-4 أشهر في التطوير ، وهي ليست مناسبة جدًا لوتيرة تطوير الأعمال.
قررنا الانتقال إلى القطع وإعادة بناء كل ما يأتي في متناول اليد. ولحل مشكلة الجيران الصاخبين ، قدمنا طلبًا منفصلاً ، والذي كان مسؤولًا فقط عن طلبات خدمات التسوية النقدية.

في المستوى الأعلى ، تبدو العملية كما يلي:

قواعد الانتقال

رقم 1: توقف الحفر

قررنا التوقف عن عمل ميزات جديدة في التطبيق القديم. عندما ظهرت المهمة في الأعمال المتأخرة ، حاولنا تحديد المربع \ المكون \ الخدمة الذي يتعلق به وإعادة كتابة هذا الشيء من الصفر في Camunda. في بعض الأحيان بتكلفة كانت 1.2x (x - إذا كانوا يفعلون في IBM) ، وأحيانًا - 3x أو 5x.

# 2: Camunda لا يعرف أي شيء عن IBM

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

بيانات الأعمال المخزنة في Siebel
واجهات برمجة تطبيقات جاهزة من Camuda تساعدك على فهم كيف وكيف انتهت العملية.

ونتيجة لذلك ، قمنا بإجراء عملية في IBM تبدأ وتتلقى النتيجة من Camunda:

رقم 3: "المهام اليدوية" الطويلة وعمليات اللصق

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

رقم 4: تبديل الميزة في الشوكة

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

ترحيل الأمثلة من IBM إلى Camunda

في النهاية ، كانت العملية في IBM تتكون فقط من مكالمات إلى Camunda ، وتم جمع 3 مستويات من العمليات في Camunda. لم تتغير عمليات الأعمال نفسها كثيرًا ، لذلك تمكنا من نقل المثيلات القديمة من IBM إلى Camunda إلى نقاط الانتظار نفسها. وأغلق IBM.

ماذا تفعل إذا كان لديك موقف مماثل

إذا كنت تريد الانتقال إلى Camunda مع إرث BPMS ، فعندئذٍ:

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

ساعدنا هذا النهج على تقليل عدد الحوادث بمقدار 14 مرة ، ووقت الانحدار 4 مرات ، مما جعل من الممكن إطلاقه يوميًا وخفض تكلفة الاختبار اليدوي 4 مرات. يعمل الآن 5 أشخاص في المشروع ويقومون بنفس القدر من العمل الذي يعمل به 9 أشخاص مع IBM. آمل أن تكون نتائجك ليست أسوأ.

دعوة للتخطيط رقم 4 من كاموندا

27 فبراير 2020 (الخميس) الساعة 19:30 في موسكو ، Golovinskoye Shosse 5A ، مركز Vodny للأعمال التجارية ، سنعقد اجتماعًا آخر حول Camunda. يمكنك التسجيل والقراءة عن مكبرات الصوت على الرابط . تأتي!

كيفية ترحيل عملية كبيرة من IBM BPM إلى Camunda وعدم إيقاف تطوير الميزات