Um ihre Abläufe zu automatisieren, verwendet das Unternehmen häufig Bitrix24. In diesem Artikel sprechen wir über einige der möglichen Probleme bei der Änderung von Geschäftsprozessen und wie wir sie gelöst haben.

Bitrix24 ist eines der gängigen CRM-Systeme. Es enthält einen visuellen Designer (Designer) zum Erstellen von Geschäftsprozessdiagrammen. Es ist wichtig zu beachten, dass beim Bearbeiten dieser Prozesse Schwierigkeiten auftreten können - insbesondere bei großen vorhandenen Projekten, bei denen Änderungen zuerst auf den lokalen Servern und den Testservern überprüft werden. In solchen Fällen verwenden wir beim Übergang in die Produktion den Mechanismus zur Migration von Geschäftsprozessen (im Folgenden: BP).
Kleine Unternehmen können in der Regel auf Migration verzichten und einen bestimmten Geschäftsprozess einfach für 2-3 Tage aussetzen. Ein großes Unternehmen kann es sich normalerweise nicht leisten und verwendet daher Testserver und Bereitstellung.
Bitrix24 zur Funktionsweise einer GeschäftsprozessvorlageDie Arbeit mit Migration hat ihre eigenen Merkmale. Insbesondere wird es durch die große Anzahl der beteiligten Objekte und die ID kompliziert. Darüber hinaus sieht Bitrix24 auch keine Migration von Geschäftsprozessen als solche vor. Oft wird dieses Problem durch Import und Export gelöst, und es können verschiedene Inkonsistenzen auftreten. Betrachten wir, welche Probleme aus entwicklungspolitischer Sicht gleichzeitig möglich sind.
Problem beim Finden einer Geschäftsprozessvorlage
Beim Erstellen eines Geschäftsprozesses können Sie der Vorlage nur einen Namen zuweisen, keinen eindeutigen Code. In diesem Fall muss ein Geschäftsprozess beim Aktualisieren namentlich aus der Datenbank abgerufen werden. Namen ändern sich manchmal, weil das System sie verwendet, um sie beim Start in der Liste der Prozesse anzuzeigen. Dementsprechend kann es Situationen geben, in denen es während des Upgrades unmöglich ist, eine Vorlage zu finden. Und im Allgemeinen ist die Suche nach Namen keine so gute Idee.
Lösung:Alle im System erstellten Geschäftsprozessvorlagen werden in der Tabelle b_bp_workflow_template gespeichert. Nachdem wir die Tabelle geöffnet haben, sehen wir unter den Feldern SYSTEM_CODE: Es gibt ein Feld für den Code, es wird einfach nicht an die Schnittstelle ausgegeben. Wir können den Code selbst mithilfe der Vorlagen-ID festlegen - er ist in der URL auf der Seite zur Prozessbearbeitung zu sehen:

Wir müssen eine Funktion erstellen, um die ID der Vorlage und des Codes abzurufen, eine Überprüfung auf Duplizierung und die Vollständigkeit des Felds für die zu ändernde Vorlage durchzuführen und auch den Code festzulegen.
use Bitrix\Main\Loader; Loader::includeModule("bizproc"); $BPloader = CBPWorkflowTemplateLoader::GetLoader();
Mach weiter. Erstellen Sie beispielsweise einen Testgeschäftsprozess in den Listen:

Um einen lokal entwickelten Prozess auf einen Testserver (und dann auf die Produktion) zu übertragen, verwenden wir den Migrationsmechanismus.
Mit Bitrix24 können Sie einen Geschäftsprozess exportieren. Wir werden diese Gelegenheit nutzen.

Das Übertragungsschema ist wie folgt:
- Geschäftsprozess exportieren
- Wir schreiben die Migration, hängen die Datei an
- Am neuen Stand sichern wir den alten Prozess
- Migration anwenden
Als nächstes überlegen Sie, wie dieser Prozess abläuft.
Erstellen Sie eine Migration
Wir werden das Migrationsmodul vom Marktplatz verwenden:
https://marketplace.1c-bitrix.ru/solutions/ws.migrations/ .
Migrationsdateien in unserem Projekt befinden sich unter
local / migrations / Szenarios

Öffnen Sie die Prozessvorlagenseite und exportieren Sie. Erstellen Sie im Migrationsverzeichnis das Dateiverzeichnis und legen Sie die exportierte Datei dort ab. Es stellt sich so heraus:
lokal / migrationen / szenarien / dateien / bp-94.bptErstellen Sie ein Migrationsszenario:
class ws_m_1565783124_approve_task extends \WS\Migrations\ScriptScenario {
Definieren Sie die Parameter der Geschäftsprozessvorlage:
class ws_m_1565783124_approve_task extends \WS\Migrations\ScriptScenario { private $arBPFields = [ 'DOCUMENT_TYPE' => [ 'lists', 'BizprocDocument', 'iblock_' ], 'AUTO_EXECUTE' => 0, 'NAME' => ' ', 'CODE' => 'TEST', ];
Wir implementieren die Importfunktion des Geschäftsprozesses:
private function importBP($path) { CModule::IncludeModule('bizproc'); CModule::IncludeModule('iblock');
Hier bestimmen wir zuerst die ID des Informationsblocks, für den wir den Prozess anwenden, und erhalten die ID der Prozessvorlage mit dem angegebenen Code.
Wenn die Vorlage gefunden wird, aktualisieren wir sie. Wenn nicht gefunden - hinzufügen.
Die Funktion gibt die ID des erstellten oder aktualisierten Prozesses zurück, und für das, was benötigt wird, werden wir weiter erzählen.
Wir definieren eine Festschreibungsfunktion, die unseren Geschäftsprozess hinzufügt / aktualisiert:
public function commit() { $pathBPElement = __DIR__ . '/files/bp-94-approve-task.bpt'; $id = $this->importBP($pathBPElement); }
In diesem Schritt können wir also bereits einen bestimmten Geschäftsprozess über das Migrationsmodul erstellen und aktualisieren.
Problem beim Aktualisieren der Vorlagendaten
Kehren wir zu unserem Geschäftsprozess zurück und fügen dort eine Aktion hinzu - Benutzerbenachrichtigung.

Als Absender wählen wir den Autor. Die Empfänger werden:
- HR-Benutzergruppe
- Benutzer Svetlana Kuznetsova
Nun wollen wir sehen, wie der Geschäftsprozess in der Datenbank aufgezeichnet wird. Dazu erhalten und drucken wir die Vorlage in der PHP-Konsole im Admin-Bereich:

$arFieldsTemplate = \CBPWorkflowTemplateLoader::GetList([], ['ID' => 94])->GetNext(); echo '<pre>'; var_dump($arFieldsTemplate);
In der Reihe der Prozessparameter sehen wir folgende Vorkommen:

Wir schauen uns die Zeile group_g15 an. Hier ist 15 die HR-Gruppen-ID.
Wir schauen uns die Zeile user_579 an. Hier ist 579 die Benutzer-ID.
Dies bedeutet, dass beim Importieren des Prozesses an einem anderen Standort fortlaufende Inkonsistenzen auftreten.
T.O. Nach der Migration dieser IDs auf diejenigen, die für die Site relevant sind, auf die wir den Prozess importieren, müssen wir einen Ersatz vornehmen.
Gruppen werden durch symbolischen Code identifiziert, Benutzer durch Anmelden.
Zunächst erhalten wir auf der Site, auf der der Prozess erstellt wurde, den symbolischen Code der Gruppe und die Benutzeranmeldung. Für den Fall, dass Sie keine symbolischen Gruppencodes festgelegt haben, ist es besser, die Migration zu schreiben und sie zuerst zu installieren.
In unserem Beispiel:
- Gruppencode - HR
- Benutzer Login - svetlana.kuznetsova
Als nächstes schreiben wir in die Migrationsfunktionen, die uns durch Code und Login die ID der Gruppe und des Benutzers geben:
- getUserId ($ login)
- getGroupId ($ code);
Aktualisieren Sie abschließend die entsprechenden Werte in der Vorlage:
public function commit() {
Geschäftsprozess importieren:
$pathBPElement = __DIR__ . '/files/bp-94-approve-task.bpt'; $id = $this->importBP($pathBPElement);
Wir erhalten die Vorlagendaten:
$arFieldsTemplate = \CBPWorkflowTemplateLoader::GetList([], ['ID' => $id])->GetNext(); $template = $arFieldsTemplate["TEMPLATE"];
Ersetzen Sie die Benutzer-ID innerhalb des Geschäftsprozesses:
$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); }
Hier laden wir zu Beginn der Migration die Datei hoch und erstellen / aktualisieren den Prozess mit der Funktion importBP. Als Nächstes erhalten wir die Struktur der Geschäftsprozessvorlage in einem Array, ersetzen die ID und aktualisieren die Vorlage.
Zusammenfassend
In diesem Artikel haben wir nur einige Fälle angesprochen, in denen während der Übertragung zwischen Standorten Inkonsistenzen auftreten können, und wir haben angegeben, worauf zu achten ist. Im Allgemeinen sind wir in unserer Praxis auf folgende ID-Bindungen gestoßen:
- user_ (Bindung an Benutzer)
- group_ (Bindung an Benutzergruppe)
- iblock_ (Infoblock-Bindung)
- SequentialWorkflowActivity (Starten eines Geschäftsprozesses aus einer Vorlage)
- PROPERTY_ (Bindung an ein Dokumentfeld mit einem undefinierten Zeichencode)
Wenn alles richtig gemacht wurde, ist die Übertragung eines debuggten Geschäftsprozesses in die Produktion schnell und reibungslos.
Wir hoffen, dass unsere Erfahrung für Sie nützlich war!
Vollständiges Beispiel anzeigen <?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');