0

Artikel-Serie: OFBiz Entity Engine – der Delegator

Geschrieben am 06.07.2011 in Technik von Sebastian Leitner

Hier startet die neue, technische Artikelserie zum Thema OFBiz Entity Engine. In den nächsten Wochen sollen nach und nach Artikel entstehen, welche die verschiedenen Facetten und Komponenten der Entity Engine erläutern. Die Artikel richten sich an Entwickler und diejenigen, die OFBiz von der technischen Seite kennen lernen möchten.

Der Delegator in der Übersicht – Part One

Jeder kennt ihn, jeder hat ihn schon das ein oder andere Mal genutzt. Der Delegator ist das zentrale Objekt der OFBiz Entity Engine, die dem Entwickler den Datenbankzugriff, die Cache-Verwaltung und Weiteres ermöglicht. Aber wo kommt der Delegator eigentlich her, wann wird er geladen, wie funktioniert er und welche Möglichkeiten bietet er uns wirklich?

Um eines vorwegzunehmen, dieses mächtige Objekt ist doch erstaunlich einfach und gut nachvollziehbar implementiert.

Startup des Delegators in OFBiz

Der Delegator wird innerhalb des Catalina Container Starts geladen (CatalinaContainer.java#init()). Welcher Delegator genutzt werden soll findet sich in der Catalina Container Definition der ofbiz-containers.xml. Der Standard Delegator hat den Namen „default„. Der dort definierte Delegator (Name) wird an die DelegatorFactory (getDelegator) übergeben. Die Factory führt einen Cache welcher schon initialisierte Delegator beinhaltet. Sollte der angeforderte Delegator im Cache gefunden werden, wird der EntityECA Handler sowie das Distributed Cache Clear geladen (dazu in einem späteren Artikel mehr). Ist dies nicht der Fall lädt die Factory über die getObjectFromFactory Methode der UtilObject Klasse eine Instanz des GenericDelegators. Dies ist über den Java Service Loader realisiert. Dieser lädt die konkrete Factory Implementierung (in diesem Fall eine Factory, die unseren GenericDelegator, welche die OFBiz Referenz Implementierung ist, erzeugt).

Das initialisierte Objekt wird anschließend in den Cache geschrieben und die oben genannten ECA Handler sowie das Distributed Cache Clear werden initialisiert.

Generic Delegator Konstruktor

Aber was geschieht eigentlich innerhalb des Generic Delegator (GD) Konstruktors? Der GD implementiert das Delegator Interface. Außerdem kann der Konstruktor nur von Factory Klassen des gleichen Packages aufgerufen werden (protected), um hier den Zugriff über eine zentrale Stelle zu führen.

Auf Basis des Delegator Namens wird über den Model Reader (dazu später mehr) das Entity Modell geladen. Anhand der ofbiz-component.xml#entity-resource wird ermittelt welche entitymodels geladen werden sollen. Ist dies erfolgreich, erscheint in der Konsole (Log Level INFO) wie viele Entities, ViewEntities, Fields geladen werden.

FINISHED LOADING ENTITIES - ALL FILES; #Entities=859 #ViewEntities=273
#Fields=9005 #Relationships=2950 #AutoRelationships=2175

Anschließen werden die Entity Gruppen über den Model Group Reader geladen, die Gruppen sind in der entityengine.xml unter der Delegator Sektion definiert. Es gibt verschiedene Gruppen für die „alltäglichen“, OLAP oder Teanant Daten, das Gruppen Model kann beliebig erweitert werden.

Auf Basis des Delegator Namens wird das Cache Objekt erstellt (die Funktionsweise des Caches bekommt einen eigenen Artikel). Außerdem wird bei jeder Initialisierung eines GDs das Tabellen Modell auf Korrektheit überprüft (z. B. Tabellen Name länger als 30 Zeichen, Tabellen Name ist ein reserviertes Wort, Feld Name ist nicht eindeutig, etc.).

Über die zuvor ermittelten Gruppen Namen lassen sich Helper laden. Diese definieren, welche Gruppe welche Datenbank respektive Treiber nutzt (z. B. die Gruppe org.ofbiz nutzt MySQL). Für jede Gruppe wird anschließend der Datenbankzugriff definiert (Server, User, Passwort, etc.). Die Informationen stammen aus der entityengine.xml, wie wir es in unserem Tutorial zur OFBiz Installation erklären. Das Überprüfen der Zugangsdaten übernimmt die Methode checkDataSource(GenericHelper.java). Sie liest alle Tabellen und Spalten Informationen des Datenbankschemas und gleicht diese mit den Definitionen der XML Dateien ab.

Abschließend wird noch das EntityCrypto Objekt initialisiert, dieses Objekt stellt zum späteren Zeitpunkt de- und encrypt Methoden zur Verfügung welche Entity Felder in HexStrings encrypten bzw. wieder in Objekte wandeln.

Damit ist die Initialisierung des GenericDelegators abgeschlossen.

Für Anregungen, Fragen und Kritik bin ich gerne offen und lade euch zu einer Diskussion der folgenden Thematiken ein.

Dieser Artikel gefällt Ihnen? Sagen Sie's Ihren Freunden:

Kommentare sind deaktiviert.