SENAITE unter der Haube: Plone, Zope, ZODB und warum das zählt

Eine URL wie /senaite/clients/client-1/W26-0042 wird nicht über eine Routing-Tabelle aufgelöst. Jedes Segment ist ein echtes Python-Objekt in der Datenbank, und die URL ist ein Weg durch den Objektbaum. Dieses Verhalten hat nicht SENAITE erfunden. Es kommt von Zope, das seit 1998 so arbeitet.

Der Rest von SENAITE ist genauso gebaut: bewährte Teile aus langlebigen Open-Source-Projekten, darüber die Labordomäne. Wer die drei Schichten darunter kennt, liest die API leichter, plant Backups besser, dimensioniert Server sicherer und erweitert das System sauberer.

Zope: URLs sind Pfade durch Objekte

Zope ist einer der ältesten Python-Anwendungsserver und wird bis heute gepflegt. Seine prägende Idee ist das Publizieren von Objekten. Wo Flask oder Django URLs über deklarierte Routen auf Funktionen abbilden, sucht Zope jedes Pfadsegment als Kind des vorherigen Objekts.

Proben liegen direkt in ihrem Kunden, Analysen in ihrer Probe. Zope läuft den Pfad ab, prüft auf jedem Objekt unterwegs die Berechtigungen und übergibt das letzte Objekt einer Ansicht zur Darstellung.

Für ein LIMS zählen drei Folgen:

• Der Baum ist das Datenmodell. Zu welchem Kunden eine Probe gehört, ist kein Fremdschlüssel, sondern der Ort, an dem sie liegt, und was die Benutzer eines Kunden sehen dürfen, folgt aus diesem Ort.
• Sicherheit gilt pro Objekt. Berechtigungen werden am Objekt geprüft, auf das zugegriffen wird, und Rollen lassen sich lokal auf einem Ordner und allem darunter vergeben. Der Kundenzugang in SENAITE baut genau darauf auf.
• Komponenten statt Patches. Die Zope Component Architecture erlaubt einem Add-on, Adapter, Utilities und Event-Subscriber zu registrieren, die der Kern zur Laufzeit nachschlägt. Ein eigenes ID-Format, ein zusätzlicher Suchbegriff oder eine Reaktion auf den Probeneingang ist eine registrierte Komponente, keine geänderte Kerndatei. Das hält Kunden-Add-ons upgradefähig.

ZODB: eine Objektdatenbank

ZODB speichert Python-Objekte so, wie sie sind. Es gibt kein ORM, keine Tabellen und kein Schema in der Datenbank. Eine Probe mit ihren Verweisen und Analysen wird in der Form geschrieben, die sie im Speicher hat.

Daraus folgt:

• Jede Anfrage ist eine Transaktion. Schlägt eine Anfrage fehl, wird nichts von dem geschrieben, was sie geändert hat. Ändern zwei Anfragen gleichzeitig dasselbe Objekt, bekommt eine von ihnen einen Konflikt, und Zope wiederholt sie. Halbe Schreibvorgänge gibt es nicht.
• Historie bleibt bis zum Packen erhalten. ZODB hängt neue Versionen geänderter Objekte an, statt sie zu überschreiben, deshalb wächst die Datenbankdatei mit jeder Änderung. Packen entfernt alte Versionen. Der Audit-Trail von SENAITE ist davon nicht betroffen: Die Änderungshistorie einer Probe liegt an der Probe selbst, nicht in alten Datenbankversionen.
• Neue Felder brauchen keine Datenbankmigration. Ein Objekt ohne Wert für ein neu hinzugefügtes Feld liefert den Standardwert des Felds. Katalogindizes und berechnete Werte brauchen dennoch einen Upgrade-Schritt, deshalb bringen SENAITE-Versionen solche Schritte mit.

Der Preis ist das Fehlen von Ad-hoc-Abfragen. Es gibt kein SQL-JOIN; alles, wonach Sie filtern oder sortieren wollen, braucht einen Katalogindex. Wie das funktioniert und wo es hakt, steht im Beitrag zu den Katalogen.

Plone: Inhaltstypen, Workflows, Benutzer

Zope allein ist ein Baukasten. Plone ist das darauf aufbauende Content-Management-System und liefert die Teile, die ein LIMS beherrschbar machen.

• Inhaltstypen. Jede Art von Objekt, von der Probenart bis zum Arbeitsblatt, ist ein Inhaltstyp mit Schema, Formularen und Validierung. SENAITE nutzt zwei Generationen nebeneinander: das ältere Framework Archetypes und seinen Nachfolger Dexterity. Probenarten, Kontakte, Arbeitsblätter und die meisten Einrichtungstypen sind in SENAITE 2.x Dexterity-Typen. Proben, Analysen, Analysenleistungen und Kunden sind noch Archetypes und werden von Version zu Version migriert. Für Benutzer zeigt sich der Unterschied vor allem in den Formularen.
• Workflows. Jeder Typ hat einen Workflow mit benannten Zuständen, abgesicherten Übergängen und einer Berechtigungstabelle pro Zustand. Eine Probe durchläuft Zustände wie sample_due, sample_received, to_be_verified, verified und published, und in jedem Zustand legt der Workflow fest, wer welches Feld bearbeiten darf. Jeder Übergang wird mit Person und Zeitpunkt festgehalten.
• Benutzer, Gruppen und Rollen. Die Benutzerverwaltung von Plone, einschließlich der Anbindung an LDAP oder Active Directory, ist die Grundlage für SENAITE-Rollen wie LabClerk, Analyst, Verifier oder LabManager. Berechtigungen werden Rollen zugeordnet, nicht Personen, und die Prüfungen erfolgen im Framework statt verstreut im Anwendungscode. Ein Analytiker darf ein Ergebnis übermitteln, aber nicht verifizieren; ob die Person, die ein Ergebnis übermittelt hat, es auch verifizieren darf, ist eine Einstellung (Erlaube Selbstverifizierung der Ergebnisse), keine Codeänderung.

Was der Stack in der Praxis bedeutet

Für Administratoren: Ein Backup ist mehr als eine Datei. ZODB hält die Objekte in Data.fs und Binärdateien wie veröffentlichte Berichts-PDFs in einem eigenen Blob-Verzeichnis. Sichern Sie beides vom selben Zeitpunkt, und testen Sie die Wiederherstellung. Planen Sie das Packen ein; eine Datenbank, die nie gepackt wird, wächst nur.

Für Integratoren: Der Objektbaum erklärt die JSON-API. Jedes Objekt hat eine URL, die dem Baum folgt, und eine UID, die sich nie ändert, und Verweise zwischen Objekten sind UIDs. Speichern Sie auf Ihrer Seite die UID; IDs und Pfade sind für Menschen. Die Anfragen zeigt der Beitrag zur JSON-API.

Für Entwickler: Das Muster, um SENAITE zu erweitern, ist ein Marker-Interface für eine Fähigkeit, ein Adapter für Verhalten, ein Dexterity-Typ für neue Inhalte und Workflow-Definitionen mit Guards für neue Zustände. Unsere Kunden-Add-ons sind so gebaut, deshalb überstehen sie Kern-Upgrades ohne Patches.

Für IT und Einkauf: Nichts davon ist neue Technik. Zope wurde 1998 als Open Source veröffentlicht, ZODB und Plone werden seit mehr als zwei Jahrzehnten entwickelt, und alle drei werden von Open-Source-Stiftungen getragen. Für ein System, das ein Jahrzehnt laufen und dabei Audits bestehen muss, ist ein gut verstandener Stack ein Vorteil.

Weiterlesen

Die offizielle Dokumentation der drei Projekte:

• Zope
• ZODB
• Plone