2

OFBiz Entity Engine – der Entity ECA Handler

Geschrieben am 07.10.2011 in Technik von Sebastian Leitner

Entity Event Condition Actions werden bei definierten CRUD Operationen (create/read/update/delete) auf eine Datenbanktabelle aufgerufen und führen einen bestimmten Service aus. Zum Beispiel kann auf die Tabelle „Product“ bei einer Operation „create“ automatisch ein Service ausgeführt werden. Dies kann genutzt werden um z.B. zu jedem hinzugefügten Produkt automatisch Keywords erstellen zu lassen, ohne, dass der Entwickler sich darum kümmern muss.

 <eca entity="Product" operation="store" event="return"> <condition field-name="autoCreateKeywords" operator="not-equals" value="N"/> <action service="indexProductKeywords" mode="sync"/> </eca>

Definiert werden die Actions in der jeweiligen eecas.xml Datei, wie das obige Code-Beispiel zeigt.

Initialisierung der ECA Handler

Aber wann und wie wird der Entity ECA Handler eigentlich initialisiert und was geschieht während der Initialisierung? Die Entity ECA wird in der Delegator Factory, nach laden des Delegators, initialisiert. Die default Implementierung findet sich in der Delegator (GenericDelegator) Klasse. Um sicherzustellen, dass die Initialisierung nicht von verschiedenen Threads parallel durchgeführt wird ist die Methode synchronisiert. Gesteuert werden die Entity ECAs über die entityengine.xml im Abschnitt delegator, hier können die ECAs prinzipell aus und an geschaltet sowie die Implementierungsklasse (Default: org.ofbiz.entityext.eca.DelegatorEcaHandler) definiert werden. Optionen:

entity-eca-enabled="true" entity-eca-handler-class-name="org.ofbiz.entityext.eca.DelegatorEcaHandler" entity-eca-reader

Nach laden der Handler Klasse wird dem neuen Objekt der aktuelle Delegator zugewiesen, dabei wird neben dem Delegator der Delegatorname und der EntityEcaReaderName gesetzt, welcher im DelegatorInfo Objekt hinterlegt ist. Anhand des Delegators wird der Dispatch Context ermittelt. Der Dispatcher wird für das spätere Ausführen der Services benötigt. Abschließend wird der EntityEcaCache mit den ECA Regeln befüllt. Somit ist der EntityEcaHandler im Delegator bekannt. Bei jeder CRUD-Operation kann jetzt mit Hilfe des EntityEcaRuleRunners geprüft werden, ob für die genutzte Tabelle eine Regel hinterlegt ist. Entity ECA Regeln werden im Objekt EntityEcaRule gespeichert. Dieses Objekt verfügt über eine eval-Methode, welche die eigentliche EntityEcaAction ausführt. Jede EcaAction kann sowohl synchron als auch asynchron ausgeführt werden.

Einsatz-Beispiele für solche Datenbank-Trigger

ECAs sind also Trigger, die auf Änderungen in der Datenbank reagieren. Allerdings sind sie innerhalb der Applikation implementiert, d. h. sie agieren nicht direkt mit der Datenbank. So bleibt die Unabhängigkeit von bestimmten Datenbank-Systemen gewahrt, ohne aber auf diese immens hilfreiche Funktionalität verzichten zu müssen. Am Beispiel eines Online-Shops wären z. B. folgende Ansätze sehr einfach über ECAs zu realisieren:

  • E-Mail bei Kunden-Registrierung oder Bestellungseingang
  • Export von Kundendaten oder Bestellungen unmittelbar nach der Änderung
  • Export von Produktdaten an Preissuchmaschinen unmittelbar nach der Änderung, z. B. Preis, Stammdaten oder auch Lagerbestand
Dieser Artikel gefällt Ihnen? Sagen Sie's Ihren Freunden:

2 Antworten bisher.

  1. Asghar Rahmani sagt:

    Bonn, 18.10.2011

    Hallo Sascha,

    seit einer Woche wollte ich dich bezüglich deiner wertvollen Artikelserien anschreiben, jetzt komme ich endlich dazu.

    Vor 4 Wochen bin ich auf Apache OFBiz gestoßen, als ich eine Alternative zum Magento (ein PHP – basiertes
    e-Commerce Software System) suchte. Seit dem bin ich hauptsächlich mit OFBiz beschäftigt.
    So habe ich die Seite „Deutschsprachige OFBiz Community“ gefunden. Die Seite ist gut.

    Über OFBiz gibt es viel zu sagen. So ein elegantes Stück sieht man selten.
    Ich habe mich entschieden, ein aktives Mitglied der OFB Community zu werden.

    *

    Bis jetzt habe ich deine Artikel („Delegator“ und „Entity ECA-Handler“) und Mirkos Artikel „Eigenes Modul in OFBiz entwickeln“ gelesen und bearbeitet.
    Gespannt warte ich auf den Artikel zum sub-Thema „Distributed Cache Clear“ oder besser gesagt, generell „Caching in OFBiz“. Wann wird es er veröffentlicht?

    Ich denke, dass man ohne ein solides Verständnis über fundamentale OFBiz Module, wo auch „Entity Engine“ dazugehört, kein guter OFBiz Entwickler sein kann.

    *

    Das Thema „Integration vom Jackrabbbit in OFBiz“ ist für mich interessant und z.Z. Versuche ich mir in diesem OFBiz-Branch einen Durchblick zu verschaffen, mit der Hoffnung bald effektiv mitwirken zu können.
    (Z.B. Sample entwickeln, technische Artikel schreiben oder Dokumentation – wie JavaDoc für das API dieser Integration – erstellen.)

    Jackrabbit ist auch in „Liferay Portal Server“ integriert und „Java Standard für Portlet Technologie“, JSR 168 (V1) und JSR 286 (V2) ist eines meiner Lieblingsthemen, womit ich vertraut bin.

    Natürlich, setze ich mich auch mit Jackrabitt auseinander. (Dort stehe ich am Anfang)

    Apache Software Foundation“ ist mir als ein Organisation ziemlich neu und brauche Zeit, um mich dort zu recht zu finden.

    Ich habe auch ein paar technische Fragen, die ich der OFBiz User Mailinglist zu sende.

    Ich würde mich sehr freuen, von dir zu hören.
    Noch mal herzlichen Dank für die tollen Artikel.

    Asghar Rahmani

    • Hallo Asghar,

      danke für dein Interesse.
      Der Artikel über Caching in OFBiz ist in Arbeit ich hoffe,
      dass ich schnellstmöglich dazu kommen ihn fertig zu stellen.
      Wie du schon sagst, ist es ein sehr komplexes Thema. Zudem sind
      wir aktuell dabei das komplette Distributed Caching zu refactorn.

      Hilfe am Jackrabbit Branch ist immer willkommen, gerne auch nur
      Architektur Reviews oder Diskussion über Content Organisation.

      Viele Grüße
      Sascha