GSB 7.0 Standardlösung

Springe direkt zu:

Zielgruppe Site AdminVersion: GSB10.0EventDispatcher

Der EventDispatcher ist ein Event-Listener und bietet so die Möglichkeit auf bestimmte Events zu reagieren und eine spezielle Verarbeitung anzustoßen.

Der EventDispatcher kann dabei mandantenspezifisch konfiguriert werden. So kann auf Mandantenebenene festgelegt werden auf welche Events der Dispatcher reagiert und welche Aktionen ausgeführt werden sollen.

Der Haupteinsatz des EventDispatchers ist die Verarbeitung von Publikationsevents und Generierung und Versand von Newsletter-Dokumenten.

Funktionsweise des EventDispatchers

Wann immer der EventDispatcher ein Event wahrnimmt, wird die Herkunft dieses Events geprüft und entsprechend das Event mandantenspezifisch überprüft.Dabei kann gegen bestimme Unterverzeichnisse, Dokumenttypen, Benutzergruppen und Namen der Autoren sowie eigens deklarierte Eigenschaften geprüft werden.Stimmt das Event überein, kann eine spezielle Klasse mit konfigurierten Parametern ausgeführt werden. Meist wird der EventDispatcher für den Newsletterversand verwendet, bei dem dann schlussendlich die zu versendenden Emails beispielsweise mit Adressen und Betreff ausgestattet werden.

Ordnerstruktur

Der EventDispatcher wird in den Ordner GSB/active/EventDispatcher installiert.

Im Folgenden werden die für den Betrieb des EventDispatcher zentralen Dateien aufgführt:

EventDispatcher/bin/eventdispatcher.sh

Das Shellskript zum Starten und Stoppen des EventDispatchers. Dieses überprüft auch, ob der EventDispatcher schon mit der in der in EventDispatcher/var/run/eventdispatcher.pid gespeicherten Process ID läuft. Ist dies der Fall wird ein erneuter Start verhindert, da zu einem Zeitpunkt nur eine EventDispatcher-Instanz laufen darf.

Gestartet wird der EventDispatcher mit <source lang="text">EventDispatcher/bin/eventdispatcher.sh start</source>

Gestoppt wird der EventDispatcher mit <source lang="text">EventDispatcher/bin/eventdispatcher.sh stop</source>

EventDispatcher/config

Dieser Ordner enthält alle für den EventDispatcher relevanten Konfigurationsdateien wie z.B.

  • eventdispatcher.properties
  • eventdispatcher-context.xml

EventDispatcher/var/timestamps/LastDispatcherEvent.timestamp

Diese Datei setzt die Startzeit des EventDispatchers. Dieser Zeitstempel wird beim Ausschalten des EventDispatchers gesetzt und ermöglicht die Wiederaufnahme der Event-Verarbeitung.Existiert die Datei nicht, startet der EventDispatcher mit der Bearbeitung von Ereignissen vom aktullen Zeitpunkt. In diesem Fall erkennt und behandelt der EventDispatcher nur Events die nach dem Start des EventDispatcher aufgetreten sind.

Konfiguration des EventDispatchers

Der EventDispatcher wird im Wesentlichen in der unten beschriebenen Spring-Property Datei konfiguriert.

eventdispatcher.properties

Diese Datei befindet sich im Ordner EventDispatcher/config/.

Die ersten Blöcke konfigurieren die Verbindung zum Repository.

Die Dispatcher-Basiskonfiguration enthält:

  • timeStampBaseDir: Verweist auf den Ordner, der die Timestamps der Mandanten enthält.
  • startupSleeTime: Gibt die Pause beim Starten in Milisekunden an.
  • stopSleepTime: Gibt die Pause beim Ausschalten in Milisekunden an.

Die Newsletterkonfiguration enthält:

  • newsletter.generatorurl: Enthält die URL zum HTML-Generator.
  • newsletter.smtpHost: Der Hostname des Mailservers.
  • newsletter.smtpUser: Der Loginname des Mailservers.
  • newsletter.password: Das Passwort zum obigen Login.

Weitere Dispatcher-Verbindungsoptionen sind:

  • checkConnection: Prüft die Verbindung wenn true.
  • checkConnectionSleepTime: Setzt die Pause bei nicht vorhandener Verbindung in Milisekunden.
  • maxReconnectTries: Gibt die maximale Anzahl der Verbindungsversuche an.
  • checkConnectionRate: Das Interval, in dem die Verbindung überprüft wird in Milisekunden.

Eine weitere Dispatcher-Konfigurationsmöglichkeit ist:

  • dbConfigured: Ist truewenn eine Datenbankanbindung konfiguriert ist.

eventdispatcher-context.xml

Diese Datei befindet sich im Ordner EventDispatcher/config/.

Hier wird der EventDispatcher initialisiert. Dabei werden die Dispatcher-Properties geladen:

<source lang="xml">

 <bean id="eventDispatcher" class="de.materna.cms.eventdispatcher.EventDispatcherImpl" scope="singleton">

   <property name="connection"><ref bean="connection"/></property>

   <property name="contentRepository"><ref bean="contentRepository"/></property>

   <property name="userRepository"><ref bean="userRepository"/></property>

   <property name="timeStampBaseDir" value="${dispatcher.timeStampBaseDir}" />

   <property name="startUpSleepTime" value="${dispatcher.startupSleeTime}"/>

   <property name="stopSleepTime" value="${dispatcher.stopSleepTime}"/>

   <property name="generatorUrl" value="${dispatcher.newsletter.generatorurl}"/>

   <property name="smtpHost" value="${dispatcher.newsletter.smtpHost}"/>

   <property name="smtpUser" value="${dispatcher.newsletter.smtpUser}"/>

   <property name="smtpPassword" value="${dispatcher.newsletter.password}"/>

   <property name="checkConnection" value="${dispatcher.checkConnection}"/>

   <property name="checkConnectionSleepTime" value="${dispatcher.checkConnectionSleepTime}"/>

   <property name="maxReconnectTries" value="${dispatcher.maxReconnectTries}"/>

   <property name="dbConfigured" value="${dispatcher.dbConfigured}"/>

 </bean>

 <task:scheduled-tasks scheduler="checkConnectionScheduler">

   <task:scheduled ref="eventDispatcher" method="checkConnection" fixed-delay="${dispatcher.checkConnectionRate}"/>

 </task:scheduled-tasks>

 <task:scheduler id="checkConnectionScheduler" pool-size="1"/>

</source>

Des Weiteren besteht die Möglichkeit hier Mandanten-spezifische Ressourcenimports durchzuführen.

Dies sind die Performer-Konfigurationen. <source lang="xml"><import resource="[MANDANT]-Performer.xml"/></source>

Mandanten Performer und Properties

Performer legen fest, welches Event welche Aktionen auslösen soll. Jeder Mandant erhält seine eigene [MANDANT]-Performer.xml und Property-Datei, beispielsweise [MANDANT]_newsletter.properties.Die unten gezeigten Ausschnitte enthalten Einträge in Großbuchstaben und in eckigen Klammern, die mit den gewünschten Mandanten und Inhalten und existierenden Pfaden zu füllen sind.

Properties

Die Properties legen beispielsweise die Emailadressen des Admins, des Versenders und der Rezipienten fest.Dazu finden sich hier die sogenannten Attribute-Type-Values, die auf Datenbank-IDs zu Formaten und Themen verweisen.Diese Einstellungen werden für jeden Mandant in einer eigenen [MANDANT]_newsletter.properties-Datei gespeichert.

Performer

Der Performer legt fest, bei welchem Ereignis was getan werden soll. Jeder Mandant bekommt eine eigene [MANDANT]-Performer.xml-Datei.

Property Import

Der Performer importiert die oben beschriebene Property-Datei:

<source lang="xml">

 <bean id="[MANDANT]EventDispatcherPPC" class="org.springframework.beans.factory.config.PropertyPlaceholderConfigurer">

   <property name="systemPropertiesModeName" value="SYSTEM_PROPERTIES_MODE_OVERRIDE"/>

   <property name="ignoreUnresolvablePlaceholders" value="true"/>

   <property name="locations">

     <list>

       <value>classpath:/[PFAD]/[MANDANT]_newsletter.properties</value>

     </list>

   </property>

 </bean>

</source>

Checks

Verschiedene Überprüfungen können eingestellt werden. Diese befinden sich in nach den Überprüfungen benannten -Elementen mit den Klassen und Unterlementen:

  • materna.cms.eventdispatcher.util.propertycheck.CL2PropertyCheckContainer Überprüft eine Klassifizierte Linkliste.
    • -Element mit Namen propertyName erhält die Bezeichnung der Klassifizierten Linkliste als Wert.
    • -Element mit Namen propertyInReferredDoc erhält die Bezeichnung der Property als Wert.
    • -Element mit Namen requiredPropertyValue erhält die Bezeichnung der gewünschten Property-Eigenschaft als Wert.
    • -Element mit Namen linkClassifierTitle erhält die Bezeichnung des Klassifizierers als Wert.
  • materna.cms.eventdispatcher.util.propertycheck.SimplePropertyCheckContainer Überprüft eine einzelne Property.
    • -Element mit Namen propertyName erhält die Bezeichnung der Property als Wert.
    • -Element mit Namen requiredPropertyValue erhält die Bezeichnung der gewünschten Property-Eigenschaft als Wert.

Performer Konfiguration

Der wichtigste Teil ist die Performer-Konfigurationen, die hier exemplarisch Stück für Stück durchgegangen wird. Die Performer-Konfigurationen befinden sich in -Elementen mit IDs ähnlich [MANDANT MANDANT]NewsletterPerformer. Es können mehrere Performerkonfigurationen vorhanden sein und die ID sollte bereits Schlüsse auf die vorgesehene Funktion zulassen.Diese Konfiguratinen können zum Versand verschiedener Newsletter in unterschiedlichen Voraussetzungen genutzt werden.

<source lang="xml">

 <bean id="[MANDANT]NewsletterPerformer"           class="de.materna.cms.eventdispatcher.newsletter.BaseNewsletterPerformerImpl"        scope="singleton">

   [...]

 </bean>

</source>

Event

Das Event wird mit dem -Element mit dem Namen eventsToHandle festgelegt:

<source lang="xml">

   <property name="eventsToHandle">

     <map>

       <entry key="PlacePublishedEvent" value="true"/>

     </map>

   </property>

</source>

Quellverzeichnisse des Events

Die Quellverzeichnisse der auslösenden Events werden (mit Regulären Ausdrücken) festgelegt. Hier werden Unterordner mit .* einbezogen.

<source lang="xml">

   <property name="includedDirectories" value="/[MANDANT]/.*"/>

</source>

Im Event einzubeziehende Dokumenttypen

Die einbezogenen Dokumenttypen (Newsletter, Basepage, Speech, Video usw.) werden hier kommasepariert aufgelistet.

<source lang="xml">

   <property name="includedDocTypes" value="[DOKUMENTENTYP]" />

</source>

Im Event einzubeziehende Benutzergruppen

Hier werden die Benutzergruppen aufgelistet, bei denen auf das Event reagiert werden soll, beispielsweise Administratoren und Site Manager.

<source lang="xml">

   <property name="groups" >

     <map>

       <entry key="[MANDANT]_Administration@[DOMAIN]" value="[MANDANT]_Administration@[DOMAIN]" />

       <entry key="[MANDANT]_Site_Manager@[DOMAIN]" value="[MANDANT]_Site_Manager@[DOMAIN]" />

     </map>

   </property>

</source>

Im Event einzubeziehende Benutzernamen

Es kann auch auf einen bestimmten Benutzer reagiert werden:

<source lang="xml">

   <property name="allowedUserNames">

     <set>

       <value>[BENUTZERNAME]</value>

     </set>

   </property>

</source>

Im Event zu kontrollierende Überprüfungen

Es werden die oben definierten Überprüfungen verwendet.

<source lang="xml">

   <property name="propertyChecks">

     <list>

       <ref bean="[ÜBERPRÜFUNG_ID]" />

     </list>

   </property>

</source>

Im Event zu überprüfendes Datum

Dieser Eintrag macht es erforderlich, dass das aktuelle Datum im Feld dateOfIssue eingetragen ist.

<source lang="xml">

   <property name="dateOfIssueCurrent" value="true"/>

</source>

Newsletter-Betreff

Der Betreff wird hier beispielsweise auf den Titel einer Pressemitteilung gesetzt und für den Dokumenttyp Newsletter obendrein ein Prefix eingefügt.

<source lang="xml">

   <property name="subjects">

     <map>

       <entry key="PressRelease" value="{title}"/>

<entry key="Newsletter" value="[MANDANT] Newsletter: {title}"/>

     </map>

   </property>

</source>

Admin-Emails

Die Konfiguration der Admin-Email. Die Elemente adminFrom und adminTo werden aus den oben beschriebenen und importierten Mandanten Properties ausgelesen.Wie im Quellcode kommentiert wird auch eine Status-Email versendet wenn der Wert sendSuccessMailauf true gesetzt wird.

<source lang="xml">

   <property name="adminFrom" value="${[MANDANT]_admin_email_from}"/>

   <property name="adminTo" value="${[MANDANT]_admin_email_to}"/>

   <property name="sendSuccessMail" value="true"/>

</source>

Newsletter Emails

In der Konfiguration der Newsletter-Emails werden ebenfalls Einträge aus den importierten Mandanten Properties ausgelesen.emailFromlegt die Emailadresse fest, die als Absender dienen wird. emailTo enthält die Emailadressen der Rezipienten. Anschließend werden die Views des zu versendenden Newsletters angegeben. In diesem Fall ist kein Textlayout definiert und nur eine HTML-Ausgabe angegeben.

<source lang="xml">

   <property name="emailFrom" value="${[MANDANT]_email_from}"/>

   <property name="emailTo" value="${[MANDANT]_email_to}"/>

   <property name="htmlTemplate" value="view=renderNewsletterHtml"/>

   <property name="plainTemplate" value=""/>

</source>

Mit erneuten Verweisen auf die importierten Mandanten Properties werden die Datenbank-IDs eingetragen und hier z.B. Themen angegeben. Diese werden im Header der Mail eingebunden und der versendenden Mail-Komponente (momentan Mailman) übergeben, damit diese die korrekten Rezipienten gemäß deren gewünschten Themen oder Formate zuordnen kann.

<source lang="xml">

   <property name="htmlAttribute" value="${BR_bundesrat_Format_html}" />

   <property name="plainAttribute" value="" />

   <property name="attributesCl2List" value="cl2Categories"/>

   <property name="attributesCl2ListClassifierTitle" value="EmailAboThemen"/>

   <property name="themePropertyForXMat" value="internalComments"/>

</source>

Konfiguration des MailDistributors

Der EventDispatcher kann, zusätzlich zum Direktversand von Emails, die Rest Schnittstelle des MailDistributors für den Versand der Newsletter ansteuern.

Dafür benötigt der EventDispatcher dedizierte Konfigurationen:

  • Endpunkt für die REST Schnittstelle
  • REST-basierte Konfiguration des Newsletters für den/die Mandanten

Endpunkt für die REST Schnittstelle (Basiskonfiguration für den Versand per REST)

Die Restschnittstelle wird in der Spring Konfiguration rest.xml des EventDispatchers konfiguriert:

<source lang="xml"> <?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

 <bean id="httpParams" class="org.apache.commons.httpclient.params.HttpConnectionManagerParams" scope="singleton">

   <property name="connectionTimeout" value="${dispatcher.restConnectionTimeout}"/>

   <property name="soTimeout" value="${dispatcher.restSocketTimeout}"/>

   <property name="defaultMaxConnectionsPerHost" value="1"/>

 </bean>

 <bean id="connManager" class="org.apache.commons.httpclient.SimpleHttpConnectionManager" scope="singleton">

   <property name="params" ref="httpParams"/>

 </bean>

 <bean id="httpClient" class="org.apache.commons.httpclient.HttpClient" scope="singleton">

   <constructor-arg ref="connManager"/>

 </bean>

 <bean id="newsletterPoster" class="de.materna.cms.eventdispatcher.rest.NewsletterPost" scope="singleton">

   <property name="newsletterRestEndpoint" value="${dispatcher.newsletterRESTEndpoint}"/>

   <property name="httpClient" ref="httpClient"/>

   <property name="maxRetries" value="${dispatcher.restCallMaxRetries}"/>

   <property name="waitMs" value="${dispatcher.restCallWaitMs}"/>

 </bean>

 <bean id="xmlGenerator" class="de.materna.cms.eventdispatcher.rest.XMLGeneratorImpl" scope="singleton" />

</beans>

</source>

Dabei sind folgende Konfigurationen über die build Properties des EventDispatchers anzugeben:

  • dispatcher.newsletterRESTEndpoint (build-Property: eventdispatcher_newsletterRESTEndpoint): Der Endpunkt zum Starten eines Newsletters im MailDistributor

Folgende Properties und deren entsprechende Build Propertties sind dabei optional und betreffen das Connection Handling zum REST Endpunkt, wie z.B. die Timeouts für den genutzten HTTPClient:

  • dispatcher.restConnectionTimeout (Connection Timeout des HTTPClients)
  • dispatcher.restSocketTimeout (Socket Timeout des HTTPClients)
  • dispatcher.restCallMaxRetries (Anzahl der Wiederholungen im Fehlerfall)
  • dispatcher.restCallWaitMs (Zeit in ms zwischen den Wiederholungen im Fehlerfall)

REST-basierte Konfiguration des Newsletters für den/die Mandanten

Die Mandanten müssen zur Verwendung des MailDistributor eine dafür vorgesehen dedizierte Konfiguration verwenden, die in einigen Punkten von der bekannten und oben beschriebenen Konfiguration abweicht.

Beispiel für eine REST basierte Newsletterkonfiguration für den Mandanten standardlsg (bzw. gsbsl):

<source lang="xml">

<?xml version="1.0" encoding="UTF-8"?> <beans xmlns="http://www.springframework.org/schema/beans" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans.xsd">

 <bean id="stdlsgRestConfig" class="de.materna.cms.eventdispatcher.rest.RESTConfigProperties">

   <property name="documentTypeAttributeName" value="doctype"/>

   <property name="formatAttributeName" value="format"/>

   <property name="htmlAttributeName" value="html"/>

   <property name="plainAttributeName" value="text"/>

   <property name="subjectAttributeName" value="subject"/>

   <property name="listName" value="testlist"/>

   <property name="newsletterPost" ref="newsletterPoster"/>

   <property name="xmlGenerator" ref="xmlGenerator"/>

 </bean>

 <bean id="standardlsgNewsletterPerformer"

       class="de.materna.cms.eventdispatcher.newsletter.RESTNewsletterPerformer"

       scope="singleton">

   <property name="eventsToHandle">

     <map>

       <entry key="VersionPublishedEvent" value="true"/>

     </map>

   </property>

   <property name="useVersionForChecks" value="true"/>

   <property name="includedDirectories" value="/standardlsg/SharedDocs/.*"/>

   <property name="includedDocTypes" value="Newsletter" />

   <property name="groups" >

     <map>

       <entry key="mandant_standardlsg" value="mandant_standardlsg" />

     </map>

   </property>

   <property name="subjects">

     <map>

       <entry key="Newsletter" value="[standardlsg] Newsletter: {title}"/>

     </map>

   </property>

   <property name="sendSuccessMail" value="false"/>

   <property name="htmlTemplate" value="view=renderNewsletterHtml"/>

   <property name="plainTemplate" value="view=renderNewsletterPlain"/>

   <property name="attributesCl2List" value="cl2Categories"/>

   <property name="attributesCl2ListClassifierTitle" value="Themen"/>

   <property name="themePropertyForXMat" value="title"/>

   <property name="restConfiguration" ref="stdlsgRestConfig"/>

   <property name="storeSendingDataToDB" value="false"/>

 </bean>

 <bean id="standardlsgPerformers"

       class="de.materna.cms.eventdispatcher.PerformerWrapperImpl"

       init-method="init"

       scope="singleton">

   <property name="performers">

     <list>

       <ref bean="standardlsgNewsletterPerformer"/>

     </list>

   </property>

   <property name="customer" value="standardlsg"/>

 </bean>

</beans>

</source>

Die Konfiguration unterscheidet sich von der herkömmlichen Newsletterkonfiguration darin, dass als Klasse für den Versand des Newsletters die Klasse: de.materna.cms.eventdispatcher.newsletter.RESTNewsletterPerformer verwendet wird, welche den REST basierte Versand zur Verfügung stellt.

Diese Klasse erweitert die herkömmlich verwendete Klasse BaseNewsletterPerformer um die REST Funktionalität. Daher benötigt diese Klasse, zusätzlich zu den aus den weiter oben schon beschriebenen Konfigurationen, eine dedizierte REST Konfiguration: Im obigen Beispiel ist dies die Springbean stdlsgRestConfig, welche dann wiederum in der Performer Bean standardlsgNewsletterPerformer verwendet wird.

Dort zu definieren sind im wesentlichen die folgenden Properties bzw. Referenzen auf andere Spring Konfigurationen:

  • documentTypeAttributeName - das im MailDistributor konfigurierte Attribut für den Dokumenttyp, z.B. doctype
  • formatAttributeName - das im MailDistributor konfigurierte Attribut für das Mailformat, z.B. format
  • htmlAttributeName - Attributwert für das HTML Format, z.B. html
  • plainAttributeName - Attributwert für das TEXT/PLAIN Format, z.B. text
  • subjectAttributeName - das im MailDistributor konfigurierte Attribut für bspw. ein Thema, z.B. subject
  • listName - der Name der Liste an die der Newsletter versendet wird, z.B. testlist
  • newsletterPost - Referenz auf bean newsletterPoster, Klasse die den Versand an die Schnittstelle ausführt
  • xmlGenerator - Referenz auf bean xmlGenerator, Klasse, die das zu versendende XML generiert

nach oben