لأتمتة عملياتها ، يستخدم العمل غالبًا Bitrix24. في هذه المقالة ، نتحدث عن بعض المشاكل المحتملة عند تغيير العمليات التجارية وكيفية حلها.

Bitrix24 هو واحد من أنظمة CRM الشائعة. يتضمن مصممًا مرئيًا (مصممًا) لبناء المخططات الخاصة بعمليات الأعمال. من المهم أن تتذكر أنه عند تحرير هذه العمليات ، تكون الصعوبات ممكنة - خاصةً في المشروعات الكبيرة القائمة ، حيث يتم فحص أي تغييرات أولاً على الخوادم المحلية واختبارها. في مثل هذه الحالات ، عند النقل إلى الإنتاج ، نستخدم آلية ترحيل العمليات التجارية (المشار إليها فيما يلي - BP).
يمكن للشركات الصغيرة ، كقاعدة عامة ، الاستغناء عن الهجرة وببساطة تعليق عملية تجارية معينة لمدة 2-3 أيام. عادةً لا تستطيع الشركات الكبيرة تحمل تكاليفها ، لذلك تستخدم خوادم الاختبار والنشر.
Bitrix24 حول كيفية عمل قالب عملية الأعمالالعمل مع الهجرة له خصائصه الخاصة. على وجه الخصوص ، الأمر معقد بسبب العدد الكبير من الكائنات المعنية والمعرف. بالإضافة إلى ذلك ، لا ينص Bitrix24 أيضًا على ترحيل العمليات التجارية على هذا النحو - غالبًا ما يتم حل هذه المشكلة من خلال الاستيراد والتصدير ، وقد يكون هناك العديد من التناقضات. دعونا نفكر في ما هي المشاكل الممكنة في نفس الوقت من وجهة نظر التنمية.
مشكلة في العثور على قالب عملية الأعمال
عند إنشاء عملية أعمال ، يمكنك فقط تعيين اسم للقالب ، وليس رمزًا فريدًا. في هذه الحالة ، عند تحديث عملية الأعمال ، يجب الحصول عليها من قاعدة البيانات بالاسم. تتغير الأسماء في بعض الأحيان لأن النظام يستخدمها لعرضها في قائمة العمليات عند بدء التشغيل. وفقًا لذلك ، قد تكون هناك مواقف عندما يكون من المستحيل العثور على قالب أثناء الترقية. وبشكل عام ، البحث بالاسم ليس فكرة جيدة.
الحل:يتم تخزين كل قوالب العمليات التجارية التي تم تكوينها في النظام في جدول b_bp_workflow_template. بعد فتح الجدول ، من بين الحقول التي نراها SYSTEM_CODE: يوجد حقل للرمز ، إنه ببساطة لا يُخرج إلى الواجهة. يمكننا ضبط الشفرة بأنفسنا باستخدام معرف القالب - يمكن رؤيته في عنوان url في صفحة تحرير العملية:

نحن بحاجة إلى إنشاء وظيفة من أجل الحصول على معرف القالب والكود ، وإجراء فحص للازدواجية واكتمال الحقل لتغيير القالب ، وكذلك تعيين الرمز الخاص به.
use Bitrix\Main\Loader; Loader::includeModule("bizproc"); $BPloader = CBPWorkflowTemplateLoader::GetLoader();
المضي قدما. على سبيل المثال ، قم بإنشاء عملية أعمال اختبار في القوائم:

لنقل عملية تم تطويرها محليًا إلى خادم اختبار (ثم إلى الإنتاج) ، نستخدم آلية الترحيل.
Bitrix24 يسمح لك بتصدير عملية تجارية. سوف نستخدم هذه الفرصة.

نظام النقل على النحو التالي:
- تصدير عملية تجارية
- نكتب الهجرة ، إرفاق الملف
- في الموقف الجديد ، نقوم بعمل نسخة احتياطية للعملية القديمة
- تطبيق الهجرة
بعد ذلك ، فكر في كيفية حدوث هذه العملية.
إنشاء الهجرة
سنستخدم وحدة الترحيل من السوق:
https://marketplace.1c-bitrix.ru/solutions/ws.migrations/ .
توجد ملفات الترحيل في مشروعنا على
/ migrations / سيناريوهات محلية

افتح صفحة قالب العملية وتصدير. داخل دليل الترحيل ، قم بإنشاء دليل الملفات ووضع الملف المصدر هناك. اتضح مثل هذا:
محلي / migrations / سيناريوهات / files / bp-94.bptقم بإنشاء سيناريو ترحيل:
class ws_m_1565783124_approve_task extends \WS\Migrations\ScriptScenario {
حدد معلمات قالب عملية الأعمال:
class ws_m_1565783124_approve_task extends \WS\Migrations\ScriptScenario { private $arBPFields = [ 'DOCUMENT_TYPE' => [ 'lists', 'BizprocDocument', 'iblock_' ], 'AUTO_EXECUTE' => 0, 'NAME' => ' ', 'CODE' => 'TEST', ];
ننفذ وظيفة الاستيراد للعملية التجارية:
private function importBP($path) { CModule::IncludeModule('bizproc'); CModule::IncludeModule('iblock');
هنا ، نحدد أولاً معرّف كتلة المعلومات التي نطبق العملية من أجلها ، ونحصل على معرف قالب العملية بالشفرة المحددة.
إذا تم العثور على القالب ، نقوم بتحديثه. إذا لم يتم العثور - إضافة.
تقوم الدالة بإرجاع معرف العملية التي تم إنشاؤها أو المحدثة ، ولماذا كانت هناك حاجة إليها - سنقول المزيد.
نحدد وظيفة الالتزام التي ستضيف / تُحدث عملية أعمالنا:
public function commit() { $pathBPElement = __DIR__ . '/files/bp-94-approve-task.bpt'; $id = $this->importBP($pathBPElement); }
لذلك ، في هذه الخطوة ، نحن قادرون بالفعل على إنشاء وتحديث عملية تجارية محددة من خلال وحدة الترحيل.
مشكلة في تحديث قالب البيانات
دعنا نعود إلى عملية أعمالنا وإضافة إجراء هناك - إشعار المستخدم.

كمرسل نختار المؤلف. سوف المستلمين:
- مجموعة مستخدمي الموارد البشرية
- العضو سفيتلانا كوزنتسوفا
الآن دعونا نرى كيف يتم تسجيل عملية الأعمال في قاعدة البيانات. للقيام بذلك ، نحصل على وطباعة القالب في وحدة تحكم PHP في لوحة المسؤول:

$arFieldsTemplate = \CBPWorkflowTemplateLoader::GetList([], ['ID' => 94])->GetNext(); echo '<pre>'; var_dump($arFieldsTemplate);
في مجموعة معلمات العملية ، نرى هذه الأحداث:

نحن ننظر إلى السطر group_g15. هنا 15 هو معرف مجموعة الموارد البشرية.
نحن ننظر إلى السطر user_579. هنا 579 هو معرف المستخدم.
هذا يعني أنه إذا قمنا باستيراد العملية في موقع آخر ، فستكون لدينا تناقضات مستمرة.
وهكذا نحتاج إلى إجراء بديل بعد ترحيل هذه المعرّفات إلى تلك ذات الصلة بالموقع الذي نستورد فيه العملية.
يتم تحديد المجموعات عن طريق الرمز الرمزي ، المستخدمين عن طريق تسجيل الدخول.
بادئ ذي بدء ، على الموقع حيث تم إنشاء العملية ، نحصل على رمز المجموعة وتسجيل دخول المستخدم. في حالة عدم وجود مجموعة رموز رمزية ، من الأفضل كتابة الترحيل وتثبيته أولاً.
في مثالنا:
- رمز المجموعة - HR
- تسجيل دخول المستخدم - svetlana.kuznetsova
بعد ذلك ، نكتب في وظائف الترحيل التي ، من خلال الرمز وتسجيل الدخول ، ستمنحنا معرف المجموعة والمستخدم:
- getUserId ($ login)
- getGroupId ($ code) ؛
أخيرًا ، قم بتحديث القيم المناسبة في القالب:
public function commit() {
استيراد عملية تجارية:
$pathBPElement = __DIR__ . '/files/bp-94-approve-task.bpt'; $id = $this->importBP($pathBPElement);
نحصل على بيانات القالب:
$arFieldsTemplate = \CBPWorkflowTemplateLoader::GetList([], ['ID' => $id])->GetNext(); $template = $arFieldsTemplate["TEMPLATE"];
استبدال معرف المستخدم داخل عملية الأعمال:
$template[0]['Children'][0]['Properties']["MessageUserTo"][0] = 'group_g' . $this->getGroupId('HR'); $template[0]['Children'][0]['Properties']["MessageUserTo"][1] = 'user_' . $this->getUserId('svetlana.kuznetsova'); $arNewFields = [ “TEMPLATE” => $template, “VARIABLES” => $arFieldsTemplate["VARIABLES"] ]; $arNewFields["MODIFIER_USER"] = new \CBPWorkflowTemplateUser(CBPWorkflowTemplateUser::CurrentUser); \CBPWorkflowTemplateLoader::Update($id, $arNewFields); }
هنا ، عند بدء الترحيل ، نقوم بتحميل الملف وإنشاء / تحديث العملية باستخدام وظيفة importBP. بعد ذلك ، نحصل على بنية قالب العملية التجارية في صفيف ، ونستبدل المعرف ونحدّث القالب.
لتلخيص
في هذه المقالة ، تطرقنا إلى حالات قليلة فقط قد تحدث فيها حالات عدم تناسق أثناء النقل بين المواقع ، وقد أشرنا إلى ما يجب البحث عنه. بشكل عام ، في ممارستنا ، صادفنا روابط معرف الهوية التالية:
- user_ (ملزم للمستخدم)
- group_ (ملزم لمجموعة المستخدمين)
- iblock_ (رابط إلغاء الحظر)
- SequentialWorkflowActivity (بدء عملية تجارية من قالب)
- PROPERTY_ (الربط إلى حقل مستند برمز حرف غير محدد)
إذا تم كل شيء بشكل صحيح ، فإن عملية نقل الأعمال التي تم تصحيحها إلى إنتاج سريعة وسلسة.
نأمل أن تكون تجربتنا مفيدة لك!
عرض المثال الكامل <?php class ws_m_1565783124_approve_task extends \WS\Migrations\ScriptScenario { private $arBPFields = [ 'DOCUMENT_TYPE' => [ 'lists', 'BizprocDocument', 'iblock_' ], 'AUTO_EXECUTE' => 0, 'NAME' => ' ', 'CODE' => 'TEST', ]; private $codeIBlock = 'APPROVE_TASK'; public static function name() { return 'approve task process'; } public static function description() { return 'process to approve task and set task deadline +14 days after approving'; } public function version() { return ['13ebf9abe69204014459b80a7036b7a0', '']; } private function getIblockId() { $result = CIBlock::GetList( [], [ 'TYPE' => 'bitrix_processes', '=CODE' => $this->codeIBlock ], false, ['nTopCount' => 1] ); if ($arIBlock = $result->Fetch()) { return $arIBlock['ID']; } return 0; } private function importBP($path) { CModule::IncludeModule('bizproc'); CModule::IncludeModule('iblock');