Bitrix24 und Site Management
Lokale Bitrix24-Module: Grenzen, Updates und Wartung
Welche Aufgaben ein lokales Modul übernimmt, wie Sie Geschäftslogik von der Oberfläche trennen und Änderungen für die Wartung vorbereiten.
Ein lokales Modul bündelt zusammengehörige Anwendungslogik. Der Pfad /local/modules/ allein macht die Lösung nicht unabhängig von der Plattformversion. Entscheidend ist, welche Aufgaben das Modul übernimmt, wovon es abhängt und welche Abläufe Sie nach Updates prüfen müssen.
Dieser Beitrag behandelt den Aufbau einer Lösung. Er ist kein fertiges Installationspaket und verspricht keine Kompatibilität mit sämtlichen Editionen von Site Management und Bitrix24.
Wann ein Modul sinnvoll ist
Ein Modul hilft, wenn eine Funktion eigene Einstellungen, Daten, Berechtigungen, Integrationsvorgänge oder mehrere Einstiegspunkte besitzt. Beispielsweise können die Oberfläche, ein Bitrix-Agent und eine Administrationsaktion dieselbe Prüfung benötigen.
Lässt sich die Aufgabe durch eine kleine Standardkonfiguration lösen, kann ein zusätzliches Modul unnötig sein. Maßgeblich sollte der Lebenszyklus der Funktion sein, nicht die Länge des ersten Codefragments.
Eine Operation – eine fachliche Verantwortung
Angenommen, eine Anfrage soll angenommen und an ein externes System übermittelt werden. Drei Teile lassen sich sinnvoll unterscheiden:
| Teil | Verantwortung |
|---|---|
| Einstiegspunkt | HTTP-Anfrage annehmen, Sitzung und Aktionsrecht prüfen, Antwort vorbereiten |
| Anwendungsoperation | Regeln der Anfrage prüfen und ihren Zustand konsistent ändern |
| Adapter zum externen System | Externe HTTP-Anfrage erstellen, Ergebnis auswerten und Fehlertyp bestimmen |
Dafür sind weder drei große Frameworks noch komplexe Hierarchien nötig. So können Sie die Oberfläche ändern, ohne den Datenaustausch neu zu schreiben. Außerdem lassen sich Fehler des Austauschs getrennt von einer HTML-Antwort behandeln.
Prüfen Sie Berechtigungen auf dem Server. Eine ausgeblendete Schaltfläche verhindert keine direkte HTTP-Anfrage. Klären Sie auch bei einer Hintergrundoperation, wer sie ausgelöst hat und in wessen Namen sie Daten verändern darf.
Erweiterungspunkte bewusst nutzen
Plattformereignisse erlauben eigene Logik an bestimmten Stellen einer Operation. Prüfen Sie vor der Registrierung eines Handlers die Ereignissignatur, die Bedingungen und die Fehlerfolgen. Verwenden Sie dafür genau die Modulversion, auf der die Lösung laufen soll.
Prüfen Sie bei langen Netzwerkoperationen, wann sie ausgeführt werden sollen. Werden sie während einer HTTP-Anfrage des Nutzers ausgeführt, kann ein externer Ausfall den gesamten Ablauf verzögern. Je nach Aufgabe gehört die Arbeit deshalb in eine Warteschlange.
Die D7-Dokumentation und EventManager helfen bei der Suche nach verfügbaren Mechanismen. Interne, undokumentierte Methoden erfordern höhere Aufmerksamkeit bei Änderungen: Ihre Existenz in einer Version verspricht keinen stabilen Schnittstellenvertrag.
Daten und Installation
Installation, Update und Deinstallation sind unterschiedliche Vorgänge. Ein Update darf nicht die Entfernung des Moduls und den Verlust vorhandener Daten voraussetzen. Für Administratoren muss nachvollziehbar sein, ob Daten bei der Deinstallation erhalten bleiben.
Setzen Sie Strukturänderungen als reproduzierbare Schritte um. Prüfen Sie eine Neuinstallation und ein Update von der vorherigen unterstützten Version. Wie umfangreich die Prüfung sein muss, hängt von der tatsächlichen Änderung ab.
Prüfen Sie auch bei ORM-Nutzung die Geschäftsregeln der jeweiligen Entität. Ein allgemeiner Speichervorgang führt nicht automatisch die Standardoperation des Produkts mit allen Ereignissen, Berechtigungsprüfungen und Nebenwirkungen aus.
Was betreuende Entwickler benötigen
- Modulzweck und Verantwortungsgrenzen.
- Unterstützte Umgebung und wesentliche Abhängigkeiten.
- Einstiegspunkte, Ereignisse, Hintergrundaufgaben und Einstellungen.
- Installation, Updates und Wiederherstellung des vorherigen Zustands.
- Beispiele öffentlicher Methoden und erwartete Fehler.
- Kurze Prüfabläufe nach Änderungen oder Plattformupdates.
Beschreiben Sie auch einen Fehlerfall: Woran erkennt man das Problem, wo steht der Diagnoseeintrag und wann darf die Aktion wiederholt werden? So können betreuende Entwickler handeln, ohne jedes Mal den Autor zu fragen.
Übergabereife prüfen
Bitten Sie einen anderen Entwickler, anhand der Dokumentation einen Hauptablauf auszuführen und das Verhalten im Fehlerfall zu erklären. Muss er dafür den Autor nach stillschweigenden Einstellungen fragen, ist die Übergabe noch nicht abgeschlossen.