exensio it blog

Grails-Applikation mit Fail2ban schützen

noreply@blogger.com (Manuel Breitfeld) — Mon, 07 May 2012 09:14:00 +0000

Fail2ban [1] ist ein Tool, welches Log-Files nach bestimmten Mustern scannt und abhängig von den definierten Filtern IPs für eine gewisse Zeit sperrt. Ein typisches Anwendungsszenario für Fail2ban ist beispielsweise das Absichern des SSH-Servers: Hat die gleiche IP innerhalb von 10 Minuten eine gewisse Anzahl an fehlgeschlagenen Logins überschritten, wird sie für eine bestimmte Zeit gesperrt. Damit erhält man nicht nur mehr Sicherheit - auch die Log-Files werden übersichtlicher, da sie nicht mit tausenden von fehlgeschlagenen Logins überfüllt werden.

Die eigene Grails-Applikation mit Fail2Ban schützen

Im Folgenden möchte ich zeigen, wie einfach und schnell die eigene Grails-Applikation mit Fail2Ban geschützt werden kann. Wir verwenden das SpringSecurity Plugin [2] und wollen eine IP dann sperren, wenn von ihr 5 fehlgeschlagene Logins binnen einer Minute ausgingen.

SpringSecurity AuthenticationFailureEvent

In Config.groovy definieren wir den Aufruf zu unserem Logger: LoginUtils.logFailedLogin()

grails.plugins.springsecurity.useSecurityEventListener = true
grails {
    plugins {
        springsecurity {
            onAbstractAuthenticationFailureEvent  = { e, appCtx ->
                LoginUtils.logFailedLogin()
                return true
            }
        }
    }
}

Wie geloggt werden soll, definieren wir ebenfalls in der Config.groovy:

log4j = {
    appenders {
        rollingFile name: "failedLoginsFile", maxFileSize: "7MB", 'append': true, file: "/var/log/exensio-demoapp/failedlogins.log",  layout: pattern(conversionPattern: '%d{yyyy-MM-dd HH:mm:ss,SSS} %p %c{2} %m%n')
    }

    warn failedLoginsFile: 'com.exensio.utils.LoginUtils'
}

Der Logger sieht dabei wie folgt aus:

class LoginUtils {
    private static final log = LogFactory.getLog(this)

    def static logFailedLogin() {
        GrailsWebRequest request = RequestContextHolder.currentRequestAttributes()
        def ip = getRemoteAddress(request)
        log.warn("Failed login attempt for IP: ${ip}")
    }

    private static getRemoteAddress(GrailsWebRequest request)  {
        def retVal = request.getRequest().getRemoteAddr()
        // If you're application is behind a proxy, you may have to call
        // a: request.getRequest().getHeader("X-Forwarded-For")
        // b: request.getRequest().getHeader("Client-IP")
        return retVal
    }
}

Fail2Ban-Installation

Unter Debian/Ubuntu kann Fail2Ban einfach über das Paketmanagement installiert werden. Das geht beispielsweise so:


sudo aptitude install fail2ban

Fail2Ban-Konfiguration

Das Kernstück der Fail2Ban-Konfiguration steckt in der Datei jail.conf. In ihr werden die unterschiedlichen Dienste, sprich Log-Files, definiert, die zu überwachen sind. In unserem Fall sieht der Abschnitt wie folgt aus:

[exensio-demoapp]
enabled = true
port = 8080
filter = exensio-demoapp
logpath  = /var/log/exensio-demoapp/failedlogins.log
maxretry = 5
bantime = 600
findtime = 60

Die Konfigurationen im Einzelnen:

enabled: Gibt an, ob der Filter überhaupt genutzt werden soll
port: Gibt an, für welchen Port die IP gesperrt werden soll. In unserem Fall läuft die Grails-Applikation auf 8080.
filter: Gibt den Namen des Filters an, siehe nächster Abschnitt
logpath: Der Pfad zur Log-Datei
maxretry: Die Anzahl an fehlgeschlagenen Logins
bantime: Die Zeit in Sekunden, für die eine IP gesperrt werden soll
findtime: Die Zeit in Sekunden, in der die fehlgeschlagenen Logins erfolgen müssen. In unserem Fall müssen 5 Fehl-Logins innerhalb von 60 Sekunden vorkommen.

Dabei gibt das in eckigen Klammern geschriebene [exensio-demoapp] an, um welchen Filter es sich handelt. Ein Filter definiert, wie das Muster eines fehlgeschlagenen Logins aussieht. Nach unserem Beispiel in der Methode logFailedLogin() aus der Grails-Applikation lautet der Pseudo Reguläre Ausdruck:

[Definition]
failregex = Failed login attempt for IP: 
ignoreregex =

Die Datei kopieren wir in das filter.d-Verzeichnis von fail2ban, zum Beispiel unter dem Namen exensio-demoapp.conf.

Fail2Ban-Log überprüfen

Das Fail2Ban-Log-File unter /var/log/fail2ban.log registriert alle gebannten IPs und den Zeitpunkt, an welchem sie wieder freigeschalten wurden.


2012-05-07 08:28:35,427 fail2ban.jail   : INFO   Creating new jail 'exensio-demoapp'
2012-05-07 08:28:35,427 fail2ban.jail   : INFO   Jail 'exensio-demoapp' uses poller
2012-05-07 08:28:35,438 fail2ban.filter : INFO   Added logfile = /var/log/exensio-demoapp/failedlogins.log
2012-05-07 08:28:35,439 fail2ban.filter : INFO   Set maxRetry = 5
2012-05-07 08:28:35,440 fail2ban.filter : INFO   Set findtime = 60
2012-05-07 08:28:35,440 fail2ban.actions: INFO   Set banTime = 600
2012-05-07 08:28:35,446 fail2ban.jail   : INFO   Jail 'exensio-demoapp' started
2012-05-07 08:28:45,458 fail2ban.actions: WARNING [exensio-demoapp] Ban 192.168.11.30
2012-05-07 08:38:45,466 fail2ban.actions: WARNING [exensio-demoapp] Unban 192.168.11.30

Fazit

Fail2Ban ist ein einfaches Tool, um Dienste zusätzlich zu schützen und Log-Files übersichtlich zu halten. Es kann in seiner Standard-Konfiguration verwendet werden, um populäre Applikationen wie SSH, Apache, Tomcat, Courier-Imap oder zum Beispiel FTP-Server wie ProFTP oder PureFTP zu sichern. Wie in diesem Beitrag gezeigt wurde, lässt sich darüber hinaus mit wenig Aufwand auch die eigene Grails-Applikation absichern.
Bei der Konfiguration ist jedoch zu beachten, dass eine IP in großen Unternehmen für viele Mitarbeiter gleich ist und so die Anzahl von 'maxRetry' nicht zu klein gewählt werden sollte. Ansonsten wird das ganze Unternehmen für einige Zeit ausgesperrt.

Links

[1] Fail2Ban Dokumentation
[2] Grails Spring Security Core Plugin

Teil 3 - Grails in Produktion – mit Apache, Tomcat und MySQL

noreply@blogger.com (Peter Soth) — Tue, 01 May 2012 11:36:00 +0000

In diesem Teil meiner Blog-Serie zum Thema Grails in Produktion möchte ich auf die Konfigurationsmöglichkeiten eines Tomcat-Clusters eingehen (hier der Link zu Teil 2 und Teil 1). Dieser Teil meiner Blog-Serie mag für manche vielleicht der interessanteste sein. Ich werde auch ab und zu einen Vergleich zum Oracle WebLogic Server herstellen, da ich selbst einmal als Systemberater für BEA (bevor BEA von Oracle gekauft wurde) tätig war. Bei einem Cluster stellt sich gleich folgende Frage:

In-Memory-Session-Replication oder „nur” Load-Balancing der HTTP-Requests?
Zunächst einmal möchte ich die Unterschiede beschreiben. Der Vorteil bei In-Memory-Session-Replication liegt darin, dass sich ein User – falls ein Tomcat abstürzt – sich nicht erneut einloggen muss, da die Informationen der HTTP-Session bereits auf den Backup-Server repliziert wurden. Beim einfachen Load-Balancing wird nur die Last (Anmerkung: auch beim In-Memory-Session-Replication wird die Last auf die Tomcat-Server eines Clusters verteilt) auf die unterschiedlichen Tomcat-Server eines Clusters verteilt.

Bei der In-Memory-Session-Replication wird von einem Tomcat-Server die Daten des HTTP-Session-Objekts vom Primär- zum Backup-Server über das Netzwerk repliziert (Anmerkung: es gibt auch noch die Möglichkeit, eine Datenbank zur Replikation zu benutzen, dieser Weg ist jedoch nicht sehr performant). Tomcat unterstützt erst seit Version 5 die Replikation von Primär- zu Backup-Server (dies haben sich die Tomcat Entwickler vom WebLogic Server abgeschaut). Davor replizierte ein Tomcat-Server seine HTTP-Sessions zu allen Tomcats innerhalb eines Clusters. Dies hatte enorme Auswirkungen auf die Netzwerklast und somit auf die Gesamtperformanz des Tomcat-Clusters. Um es gleich vorweg zu nehmen, ist In-Memory-Session-Replication die komplexere Systemkonstellation. Es gibt noch einen einfacheren Weg, in dem „nur“ die HTTP-Requests zwischen den Tomcat-Servern eines Clusters verteilt werden (Load-Balancing).

Was nimmt man nun am besten für eine Grails-Web-Applikation?
Wir von exensio benutzen eigentlich nur das einfache Load-Balancing, da für die In-Memory-Session-Replication bereits bei der Entwicklung einiges beachtet werden muss. Die meisten unserer Kunden sind nicht gewillt, diesen Mehrpreis zu zahlen, nur damit der User einen transparenten Fail-Over erhält, sprich sich nicht erneut einloggen muss. Folgendes muss beachtet werden:

Alle Objekte, die in der HTTP-Session gespeichert werden müssen serialisierbar (von java.io.Serializable erben) sein. Dies ist per se kein Problem, jedoch habe ich es schon öfters in Projekten erlebt, dass dann doch die eine oder andere Hashmap ein nicht serialisierbares Objekt enthält.
Die HTTP-Session darf nicht größer als 50-70 KByte sein. Hier auch wieder, eigentlich kein Problem, aber auch hier habe ich schon einiges erlebt. Es war dann doch eine Hashmap im HTTP-Session-Objekt, die beispielsweise die Ergebnisse einer Datenbankabfrage enthielt.
Wie gewährleisten wir die Idempotenz, wenn unser Service auf dem Backup-Server erneut aufgerufen wird. Einfaches Beispiel, wir haben in einem Grails-Controller eine Action die zweimal eine save() Methode nacheinander auf unterschiedliche Grails-Domian-Klassen ausführt. Würde es nun zwischen diesen beiden save() Aufrufen zu einem Absturz eines Tomcat-Servers kommen, so würde die Grails-Controller-Action dann erneut auf dem Tomcat-Backup-Server ausgeführt werden. In diesem Fall würde die erste save() Methode erneut ausgeführt werden. Aus unserer Erfahrung heraus ist es gar nicht so einfach, Grails-Actions oder Grails-Services idempotent zu schreiben.

Aus den oben aufgeführten Gründen setzen wir unsere Tomcat-Cluster immer nur mit einfachem Load-Balancing auf. Aus meiner Zeit bei BEA weiß ich noch, dass die meisten Kunden (nachdem das Geld nach der Euphorie des Jahrtausendwechsels wieder knapper wurde) auch nur das Load-Balancing benutzt haben. Mich würde hier natürlich interessieren, wie die Meinung anderer zum Thema Grails im Tomcat-Cluster aussieht.

Installation des Tomcat-Clusters
Hier gibt es verschiedene Möglichkeiten. Da bei unseren Kundenprojekten das Hosting meistens durch einen professionellen Hosting-Provider, mit dem der Kunde bereits zusammenarbeitet, übernommen wird, müssen wir uns nicht um die Installation kümmern. Es ist hier jedoch wichtig darauf hinzuweisen, dass jeder Tomcat in einem eigenen Java-Prozess laufen soll und nicht als virtueller Server (verwaltet über die Tomcat-Management-Applikation host-manager). In diesem Fall teilen sich alle Tomcats (obwohl sie über einen eigenen Port etc. verfügen können) einen Java-Prozess. Eine fehlerhafte Grails-Web-Applikation würde dann den gesamten Tomcat herunterreißen. Wer sich um die Installation selber kümmern muss, dem können folgende URLs empfohlen werden [1][2][3].

Anmerkung: Die einfachste Form der Installation ist einen Tomcat für jeden Java-Prozess zu installieren. Der physikalische Server enthält dann zwei Tomcat-Verzeichnisse (z.B. srv1 und srv2). Die oben erwähnten Skripte hingegen teilen den Tomcat in einen generellen und serverabhängigen Bereich auf (z.B. common, srv1 und srv2). Der Teil, der in das common-Verzeichnis kommt, kann sich von Version zu Version des Tomcats unterscheiden. Deshalb ist bei diesen Skripten immer zu überprüfen, ob sie mit der benutzten Tomcat-Version funktionieren.

JVM Settings
Wir benutzen meistens nur leicht modifizierte Standardeinstellungen der JVM für unsere Grails-Applikationen. Die Erfahrung hat gezeigt, dass es nicht zwingend besser ist die JVM extrem zu tunen. Mit folgenden Einstellungen haben wir bisher ganz gute Erfahrungen gemacht:

JAVA_OPTS="-Djava.awt.headless=true -Dfile.encoding=UTF-8 -server -Xms1536m
-Xmx1536m -XX:NewSize=256m -XX:MaxNewSize=256m -XX:PermSize=256m -XX:MaxPermSize=256m -XX:+DisableExplicitGC -XX:+CMSClassUnloadingEnabled -XX:+UseConcMarkSweepGC"

Anmerkung: die beiden letzten Parameter dienen dazu, dass der PermGenSpace wieder freigegeben wird. Je nach Grails-Applikation mögen diese Parameter nicht nötig sein.

JDBC Connection Pool
Es ist sinnvoll, den JDBC Connection Pool des Tomcat-Servers zu benutzen. Dieser verfügt über bessere Pooling-Eigenschaften, als der standardmäßig in einer Grails-Applikation (Grails Commons DBCP Pool) benutzte. Des Weiteren kann sehr einfach eine neue Datenbank konfiguriert werden, ohne Code an der Grails Applikation ändern zu müssen. In der Grails Applikation muss folgendes in der DataSource.groovy eingefügt werden.

// environment specific settings
environments {
  ...
  grails_production {
        dataSource {
            jndiName        = "java:comp/env/jdbc/grails_application"
            dialect         = org.hibernate.dialect.MySQL5InnoDBDialect
            dbCreate        = 'update'
        }
    }
  ...
}

Unten habe ich eine unserer Standardkonfigurationen (zu ändern in conf/context.xml) eingefügt, mit der wir bisher gute Erfahrungen gemacht haben. Diese können sich natürlich von Projekt zu Projekt ändern.


WEB-INF/web.xml

Anmerkung: In unserer Konfiguration wird der Connection-Pool zeitbasiert wieder verringert. Diese zeit-gesteuerte Anpassung der Pool-Größe kann zu Problemen führen, wenn die Connection im Tomcat schon weg ist, aber in MySQL aufgrund des eingestellten Timeouts noch aktiv ist. In diesem Fall wird eine neue Session auf dem MySQL-Server angelegt und dies kann unter Umständen dazu führen, dass die auf dem MySQL-Server eingestellten Connections (MySQL Parameter max_connections) überschritten wird. Aus diesem Grund sollte die maximale Anzahl der Connections über einen Last-Test ermittelt werden und zum Go-Live etwas höher sein. Nach dem Go-Live kann man über das Monitoring [4] eine genauere Größe ermitteln.

Der MySQL JDBC Driver (beispielsweise mysql-connector-java-5.1.10-bin.jar) muss nach tomcat/lib kopiert werden.

Konfiguration der Tomcat-Ports
Wichtig hierbei ist, dass jeder Tomcat über eigene Ports verfügt, da wir ja 1..n Tomcats auf einem physikalischen Rechner haben. Folgende Werte müssen in der server.xml gesetzt werden:

AJP Connector Ports
Hierbei ist wichtig, dass auch das URIEncoding (Vorsicht: der Code-Formatter hat oben URIEncoding in Kleinbuchstaben gewandelt) gesetzt wird. Falls nicht werden deutsche Umlaute in einem Formular auf einer .gsp Seite nicht richtig übermittelt.
Server-Ports
HTTP Connector Ports (für Admin-Konsole)
Jeder Tomcat Server braucht ein jvmRoute Setting, dieses wird an die SessionID angehängt und muss mit denen in der worker.properties (Apache WS) übereinstimmen.

Deployment der Grails-Web-Applikation
Generell stoppen wir hierzu den Tomcat, löschen die Grails-Web-Applikation im webapps-Verzeichnis (z.B. Grails_App.war und das Verzeichnis Grails_App/) kopieren die neue Version der Grails-Web-Applikation in das webapps-Verzeichnis und starten dann wieder den Tomcat. Dies geht natürlich auch alles ohne den Restart, aber mit dem oben beschrieben Weg haben wir die besseren Erfahrungen gemacht.

Monitoring
Das Monitoring in einer Produktions-Umgebung wird meistens durch Nagios abgedeckt. Für die Last-Tests setzen wir hingegen sehr gerne PSI-Probe [5] ein. Für ein passendes Monitoring-Tool mussten wir eine Weile suchen, da wir hier vom Oracle WebLogic-Server sehr verwöhnt waren, wir denken jedoch, dass PSI-Probe vergleichbar ist. PSI-Probe basiert auf Lambda-Probe, jedoch ist Lambda-Probe veraltet. Mit PSI-Probe kann man sehr viele interessante Werte, wie Anzahl HTTP-Session, JDBC-Sessions, Java-Heap, Java-PermGenSpace etc. analysieren. Unten habe ich noch ein paar Screen-Shots von PSI-Probe angehängt.

Links
[1] Clustering Grails - Burt Beckwith - http://burtbeckwith.com/blog/?p=244
[2] Basic Apache Tomcat clustering for Grails applications - Peter Ledbrook
[3] Tomcat Cluster Scripts - https://github.com/acreeger/grails-tomcat-cluster-scripts
[4] Nagios - http://www.nagios.org
[5] PSI-Probe - http://code.google.com/p/psi-probe

exensio GmbH ist Silber Sponsor des BarCamp 2012 in Karlsruhe

noreply@blogger.com (Peter Soth) — Fri, 27 Apr 2012 13:38:00 +0000

Seit heute ist es offiziell, wir unterstützen das diesjährige BarCamp [1], das am 14. und 15. Juli 2012 hier in Karlsruhe stattfindet. Ein Barcamp wird auch häufig als Unkonferenz bezeichnet, da es – im Vergleich zu einer gewöhnlichen Konferenz - kein vorgefertigtes Programm gibt. Die Inhalte und der Ablauf werden erst bei Konferenzbeginn von den Teilnehmern selbst erstellt. Weitere Infos finden sich in Wikipedia[2].

Aber warum unterstützt exensio das Barcamp?
Zum einen erhalten wir hierdurch natürlich etwas Sichtbarkeit in der Öffentlichkeit, was uns bei der Suche nach neuen Mitarbeitern oder vielleicht auch Kunden helfen kann. Wir finden jedoch ehrlich gesagt die Idee eines Barcamps sehr interessant. Hierdurch ist eine neue Form des Gedankenaustauschs möglich.
Bei den Anbietern von Konferenzen zu IT-Themen ist eine gewisse Monopolisierung unübersehbar. So leiern immer die gleichen Präsentatoren (von den großen Anbietern bzw. Softwarehäusern) mantraartig Ihre Folien herunter und das bei hohen Preisen. Bei einem Barcamp hingegen entscheidet die Gruppe, welche Themen für sie interessant sind.

Fazit
Wir freuen uns schon auf das Barcamp 2012 hier in Karlsruhe. Und natürlich ein dickes Lob an das Orga-Team, das solch ein Event - mit viel Einsatz - erst ermöglicht.

[1] http://www.barcamp-karlsruhe.de
[2] http://de.wikipedia.org/wiki/Barcamp

Erfahrungen bei der Migration von Grails 1.3.x nach 2.0.x

noreply@blogger.com (Tobias Kraft) — Mon, 09 Apr 2012 10:18:00 +0000

Nachdem für das Grails-Framework die Version 2.0 im Dezember 2011 freigegeben wurde, stellt sich für bestehende Projekte, die auf älteren Grails-Versionen realisiert bzw. begonnen wurden, die Frage nach der Migration. Die Analyse, ob sich eine Migration lohnt muss für jedes Projekt individuell durchgeführt werden, da ein entsprechender Aufwand dahinter steckt. Klar ist aber auch, dass Projekte, die noch länger laufen und weiterentwickelt werden an einer Migration kaum vorbeikommen.

Warum sollte man migrieren?

Wie im User Guide [1] beschrieben gibt es mit Grails 2.0 zahlreiche Neuerungen, die entsprechende Mehrwerte bieten. Außerdem ist davon auszugehen, dass neue Plugins sowie die Weiterentwicklungen bestehender Plugins auf die Version 2.x setzen. Damit würden diese nicht zur Verfügung stehen, bzw. müssten selbst auf Tauglichkeit für ältere Version angepasst und getestet werden.

Was ist zu beachten bei der Migration?

Auf unserem Blogeintrag Grails 2.0 Upgrade Guide sind die entsprechenden Seiten zusammengefasst, mit denen man auf jeden Fall vor Beginn der Migration auseinandersetzen sollte. Darüber hinaus sind die Informationen über Änderungen, die potentiell zu Problemen nach der Migration führen, im Grails User Guide [2] hilfreich.

Neben dem geplanten Bug-Fix Release 2.0.1 gab es in den letzten Tagen zwei weitere Bug-Fix-Releases, so dass zwischenzeitlich die aktuellste Version 2.0.3 ist [3]. Mit dem Release 2.0.2 wurde eine erhebliche Security-Lücke im Bereich des Data-Binding behoben [4]. Leider schlichen sich auch ein paar gravierende Probleme mit Domain-Klassen und Entwicklungsumgebungen ein, so dass kurze Zeit später die Version 2.0.3 herausgebracht wurde.

Wenn eine Migration ansteht sollte man deshalb unbedingt auf die momentan aktuellste Grails-Version 2.0.3 migrieren.

Fallen und Probleme bei der Migration

Nachfolgend werden Hinweise gegeben und auf Probleme eingegangen, die im Rahmen von Migrationen bei exensio aufgetreten sind. Es wird nur auf ausgewählte Fälle eingegangen, da es viele Hinweise schon im Upgrade-Guide gibt.

DataSource.groovy
Wurde bisher für Entwicklung oder Tests die mitgelieferte HSQL Datenbank verwendet, dann sollte nach Möglichkeit durch Anpassung der Settings in der Datei DataSource.groovy auf die H2 Datenbank gewechselt werden. Mit H2 kann die DB-Konsole direkt aus der Grails-Webapplikation aufrufen werden.

executeQuery Methode
Schon in älteren Grails-Versionen wurde angekündigt, dass zukünftig in Domain-Klassen für die executeQuery-Methode die Parameter nicht mehr als String übergeben werden können. Mit der Version 2.0 änderte sich die Methoden-Signatur endgültig.

def rev = Template.executeQuery('from Template t where t.ui = ? and t.revision = (select max(tMax.revision) from Template tMax where tMax.ui = ? ) ', ui, ui)

Die Migration erfolgt hier einfach, in dem die Parameter wie nachfolgend aufgezeigt als Liste übergeben werden:

def rev = Template.executeQuery('from Template t where t.ui = ? and t.revision = (select max(tMax.revision) from Template tMax where tMax.ui = ? ) ', [ui, ui])

groovyPagesTemplateEngine
In Services wird die Variable groovyPagesTemplateEngine über Spring injiziert und kann für das Erzeugen von Page-Templates verwendet werden. Aus den Templates können wiederum entsprechende GSP-Seiten erzeugt werden. Bei einem migriertem Projekt wird von diesem Mechanismus intensiv Gebrauch gemacht und die entsprechenden Service-Methoden werden von Controllern und Taglibs aufgerufen. Nach der Migration startete allerdings der Server aufgrund von Initialisierungs-Problemen der Variable groovyPagesTemplateEngine durch Spring nicht mehr.

Lösung war hier die Variable groovyPagesTemplateEngine nicht mehr in den Services zu deklarieren. Stattdessen wird, wie nachfolgend dargestellt, die TemplateEngine in einer Helper-Klasse erzeugt und kann von den Services abgefragt werden.

public synchronized static GroovyPagesTemplateEngine getEngine() {
  if (engine == null) {
    engine = getApplicationContext().getBean(GroovyPagesTemplateEngine.BEAN_ID)
  }
  return engine
}

Transiente Attribute in Domain-Klassen
Bedingt durch die Behebung der Sicherheitslücke in Grails 2.0.2 fließen transiente, statische oder dynamisch getypte Variablen in Domain-Klassen standardmäßig nicht mehr in das Data-Binding ein. Um dennoch ein Data-Binding zu erreichen steht, wie unten beispielhaft skizziert, das Attribut bindable zur Verfügung.

def attachment
static transients = ['attachment']
static constraints = {
  attachment bindable: true // Required since Grails 2 for tranisent attributes
}

afterInterceptor
Über den afterInterceptor [5] kann in Controller-Actions nach deren Aufruf eingegriffen werden. Bei einer bestehenden exensio-Applikation wurde bisher im afterInterceptor unter bestimmten Bedingungen ein Redirect durchgeführt.

def runAfterAction (model, modelAndView) {
  // Redirect
  if(model.redirectParams) {
    redirect( model.redirectParams )
  }
}

Nach Durchführung der Migration funktionierte der Redirect nicht mehr, bzw. führte nicht auf die gewünschten Controller. Das Problem konnte nur gelöst werden, in dem der Redirect aus dem afterInterceptor entfernt wurde und direkt am Ende der betroffenen Actions eingefügt wurde.

Abstrakte Domain-Klassen
Eine wesentliche Änderung mit Grails 2.0 ist der Umgang mit Vererbung innerhalb von Domain-Klassen. Eine abstrakte Vater-Klasse resultiert ab Grails 2.0 in einer eigenen Datenbank-Tabelle. Damit würde sich für eine migrierte Applikation das Datenbankschema ändern, was in der Regel unerwünscht ist. Außerdem machen für neu erstellte Grails 2.0 Anwendungen zentrale Vaterklassen durchaus Sinn, die nicht in einer separaten Tabelle resultieren. In diesen Klassen können bspw. Attribute wie der Version-Count, das Erstellungs- oder Änderungsdatum modelliert werden. Diese Attribute sollen direkt als Spalten in der Datenbank-Tabelle der eigentlichen Domain-Klasse resultieren, um zusätzliche JOINS zu vermeiden.

Dies kann einfach erreichr werden durch Ablage der abstrakten Domain-Klassen im src-Verzeichnis anstatt im Domain-Klassen-Verzeichnis.

Generieren von Links
In bestimmten Fällen ist es notwendig in Services Links zu generieren. Dies war bisher ziemlich umständlich, da die TagLibrary entsprechend im Service verfügbar gemacht werden musste, um dann den entsprechenden Aufruf für die Generierung durchführen zu können:

def href = g.createLink(controller:'content', action:'show', id:c.id)

Ab Grails 2.0 geht dies eleganter über die Variable LinkGenerator, die über Spring direkt injiziert wird.

def href = grailsLinkGenerator.link(controller:'content', action:'show', id:c.id)

Fazit

Die Migration ist bei größeren Projekten kein Selbstläufer und muss entsprechend eingeplant werden. Es gibt viele Hilfestellungen, man muss aber auch damit rechnen auf Probleme stoßen zu denen man im ersten Moment keine direkte Hilfe im Netz findet.
Nichtsdestotrotz macht die Version 2.0.3 jetzt einen stabilen Eindruck auf die man migrieren kann. Für den 30. April ist bereits Grails 2.1 angekündigt. Laut Jira sind für dieses Release aktuell ca. 100 Erweiterungen und Bugfixes vorgesehen. Dies zeigt, dass die Weiterentwicklung stetig voran schreitet und spätestens dann sollte man sich mit dem Thema der Migration befassen.

[1] Neuerungen in Grails 2.0
[2] Upgrading from previous versions of Grails
[3] Grails 2.0.3 Release Ankündigung
[4] Secure data binding with Grails
[5] afterInterceptor

Impressionen von der SMX München 2012

noreply@blogger.com (Manuel Breitfeld) — Mon, 02 Apr 2012 05:16:00 +0000

Vergangene Woche habe ich am 27. und 28. März an der SMX - der Search Marketing Expo - 2012 in München teilgenommen. In diesem Blogbeitrag schildere ich meine Erfahrungen zur Konferenz im Allgemeinen und einige Erkenntnisse aus den einzelnen Vorträgen.
Insgesamt wurden parallel in vier großen Räumen Vorträge zu unterschiedlichen Themengebieten rund um SEO und SEA gehalten. Die Keynotes von Rand Fishkin, Will Critchlow und Prof. Wolfgang Henseler fanden einzeln im großen Ballsaal statt.

Viral-Marketing-Perfektion und SEO-Katastrophe

Ein spannendes Beispiel zu tollem viralem Marketing und gleichzeitig nur mäßigem SEO nannte Rand in seiner Keynote. Dollarshaveclub verkauft Rasierer und hat mit seinem Video auf Youtube fast 4 Millionen Views. Durch die losgetretene Welle kommt die Firma den ersten Bestellungen schon nicht mehr hinter her.
Jedoch - sucht man nach typischen Keywords zum Thema "Rasierer, Rasierer monatlich, Rasierer im Abo, Rasierer für einen Dollar" befindet sich die Webseite nie unter den Top 10 in Google. (Aufgrund der Keynote und der Tatsache, dass das mittlerweile von vielen als Beispiel herangezogen wird, befindet sich die Firma tatsächlich doch indirekt unter den Top 10 - nämlich bei Blogs und Foren, die genau darüber berichten.)

KML Sitemap für Local Searches

Mithilfe einer KML Sitemap erleichtert man Google das Auffinden des eigenen Unternehmens auf der Landkarte und ermöglicht so, dass bei der Suche nach dem Unternehmen auch gleich der passende Kartenausschnitt aus Google Maps angezeigt wird. Das ist zum einen hilfreich für den Nutzer, zum anderen wirkt dadurch der Suchtreffer in Google sofort "größer" und sticht eher ins Auge des Suchenden. Mehr dazu findet man bei Martijn Beijk und seinem Tutorial KML and sitemaps for SEO – The definitive guide [1].

Social Networks und Suche

In allen Vorträgen, in denen es um die soziale Komponente der heutigen Suchmaschinen ging, wurde betont, wie wichtig es ist, neue Beiträge auf Google+ zu teilen und/oder +1en. Zusätzlich helfen Twitter, Facebook, you name it... Interessant ist, dass eine auf Google+ geteilte URL sofort in den Google Index aufgenommen wird - diese Chance eines schnellen Indizierens sollte man sich also nicht entgehen lassen.

Google+ Ripples [2] ist eine geniale Visualisierung von Google+ Shares - jeder Content in Google+ kann über Ripples gewissermaßen nachverfolgt werden: Ripples zeigt an, welche Circles den Content weitergeteilt haben, wer aus den Circles den größten Einfluss auf die Weiterverteilung hatte, usw. Genial! Einfach mal selbst bei einem beliebigen Beitrag ausprobieren. Auf seomoz wird Ripples im Detail vorgestellt [3].

Ein weiterer kleiner Tipp: Sind Ihnen die Personenbilder bei Top-Suchergebnissen in Google aufgefallen? Allein dadurch wird ein Link interessanter. Der Clue - das ist auch einfach für den eigenen Content zu erreichen. Das Stichwort heißt rel=author und Scott Hanselmann zeigt die Funktionsweise schön an einem Beispiel [4].

Large Scale Linkbuilding

Die SEO-Gemeinde beschäftigt auch im Jahre 2012 noch die Frage, wie eine Webseite am meisten Links von wichtigen Domains bekommt. Interessante Vorschläge beinhalteten unter anderem:

Ausschreibung eines Stipendiums: Die Kosten sind berechenbar und eine Fülle an neuer Links ist gewiss. Dabei kommen die Links nicht "nur" von kleineren privaten Seiten - mit etwas Nachdruck bringt man auch die eher langsamer tickenden Universitäten dazu, auf das neue Stipendium zu verlinken. Mit geschicktem Marketing lassen sich natürlich noch weitere Kanäle bedienen.

Sponsoring von kleineren "Goodies": Mit dem Sponsoring von Stickern, Kugelschreibern, Blocks, USB-Sticks oder Schlüsselbändern für eine lokale Konferenz oder beispielsweise einem Barcamp sind die Kosten im moderaten Bereich - das Firmen-Logo und der Link zur Firmen-Website sind mindestens auf der Konferenz jedoch präsent.

OpenGraph für Facebook

Damit die eigene Webseite auch in Facebook Shares gut aussieht, sollte man sich mit OpenGraph [5] beschäftigen. Damit lässt sich steuern, welches Bild, welcher Titel und welche sonstigen Meta-Informationen in Facebook angezeigt werden, wenn Content der eigenen Webseite geshared wird. Auf BlueGlass gibt es dazu die perfekte Anleitung [6].
Weitere interessante Möglichkeiten der Facebook APIs sind unter anderem auch, dass man die Interaktion eines Nutzers auf der eigenen Unternehmenswebseite auf dessen News Stream in Facebook pushen kann. Als Beispiel seien hier Zeitungen, allen voran der Guardian, genannt: Habe ich in Facebook erlaubt, dass der Guardian, die von mir gelesenen Artikel auf meiner Facebook-Seite publizieren darf, wird dies fortan mit allen Artikeln gemacht - stets mit Link zurück zum Artikel. Das klingt auf den ersten Blick vielleicht etwas schräg, es sollte aber schnell klar werden, dass der Guardian damit ungemein viele potentielle neue Leser erhält. Nämlich mindestens jeden meiner Freunde. Und sobald einer meiner Freunde das gleiche macht, spannt sich der Netzwerk-Graph weiter,...
Das Beispiel macht natürlich in dieser Weise nur für Zeitungen Sinn. Andere Szenarien wären das Anschauen eines Videos, einer Präsentation oder ähnliches. Ganz nach dem Motto: Max Mustermann schaut gerade das Video "Grails in Produktion - Teil 1" auf exensio.de

SMX After Dark

Der erste Tag der SMX schloss mit dem Beginn der SMX After Dark auf der Praterinsel ab. Die Party war riesig und das folgende Bild zeigt eine der vielen Tanzflächen ganz zu Beginn der Veranstaltung - später waren sie alle voll, die Tanzflächen. ;-)

Da gleichzeitig zur SMX auch die E-Commerce Messe Internet World in München stattfand, waren viele Internet-affine Leute auf die After-Party gegangen, die sich nett bei dem ein oder anderen Drink und dem köstlichen Essen austauschen konnten.

Fazit

Für mich persönlich war die SMX 2012 interessant und hatte viel an Informationen zu bieten, was ich so in der Form noch nicht kannte. Der Fokus liegt stark auf SEO und SEA und somit dreht sich im Prinzip alles um Google und/oder Bing. Die meisten Besucher kommen daher auch aus den Bereichen des Online Marketings oder ganz speziell der SEO-Abteilung.
Schade war, dass das ganze Thema Enterprise Search in keiner Session erwähnt wurde.

Weitere Berichte zur SMX 2012 in München

SMX München 2012 Recap: 121WATT: SMX München 2012 Recap
SMX Recap 2012: Mindshape: SMX Recap 2012
Recap & Faszinationspunkte: Jan Kutschera: SMX München Recap 2012 Seonauten: SMX 2012 – Recap & Faszinationspunkte
Lustiges Gezwitscher: Tweetgeflüster von der SMX München 2012
Recap mit Video-Tipps: SMX – Recap inkl. Video-Tipps von Rand Fishkin
Auch in 2012 toll: SMX München: Auch 2012 toll!

[1] KML and sitemaps for SEO – The definitive guide
[2] Google: About Google+ Ripples
[3] Using Google+ Ripples to Connect with Influencers
[4] Embrace Authorship - The importance of rel=me and rel=author on your content's SEO and Google
[5] OpenGraph
[6] Unraveling Facebook Open Graph – Part 1

Teil 2 - Grails in Produktion – mit Apache, Tomcat und MySQL

noreply@blogger.com (Peter Soth) — Sun, 04 Mar 2012 15:31:00 +0000

Im zweiten Teil meiner Blog-Serie (hier geht es zu Teil 1 bzw. Teil 3) möchte ich auf die Konfiguration des Apache Moduls mod_jk innerhalb des Apache Web-Servers eingehen. Hierzu muss die Datei httpd.conf angepasst und eine Datei worker.properties erstellt (die Konfiguration der Ports beschreibe ich dann im Tomcat-Teil meiner Blog-Serie) werden. Des Weiteren werden ich noch kurz die JKStatus Konsole vorstellen.

Einstellungen in der Datei httpd.conf:
Im Listing unten sieht man die Standard-Einstellungen, diese können und sollten dann in jedem Projekt modifiziert bzw. erweitert werden. Folgendes ist anzumerken :

Bis Zeile 9 - stehen die globalen Einstellungen, wie Lokation des Logfiles, der worker.properties, etc.
Ab Zeile 43 - stehen dann die Einstellungen innerhalb des Virtual-Host Abschnitts. In einer Produktions-Umgebung sollte man dann noch entscheiden, ob die JKStatus-Konsole benutzt werden soll (Zeile 50).

LoadModule jk_module /usr/lib/apache2/modules/mod_jk.so
LoadModule rewrite_module /usr/lib/apache2/modules/mod_rewrite.so
JkWorkersFile /etc/apache2/worker.properties 
# Where to put jk logs 
JkLogFile /var/log/apache2/mod_jk.log 
# Set the jk log level [debug/error/info] 
JkLogLevel info 
# Select the log format 
JkLogStampFormat "[%a %b %d %H:%M:%S %Y] " 



 ServerAdmin webmaster@localhost

 DocumentRoot /var/www
 
  Options FollowSymLinks
  AllowOverride None
 
 
  Options Indexes FollowSymLinks MultiViews
  AllowOverride None
  Order allow,deny
  allow from all
 

 ErrorLog /var/log/apache2/error.log

 # Possible values include: debug, info, notice, warn, error, crit,
 # alert, emerg.
 LogLevel warn

 CustomLog /var/log/apache2/access.log combined

    Alias /doc/ "/usr/share/doc/"
    
        Options Indexes MultiViews FollowSymLinks
        AllowOverride None
        Order deny,allow
        Deny from all
        Allow from 127.0.0.0/255.0.0.0 ::1/128
    
 # JkOptions indicate to send SSL KEY SIZE, 
 JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories 
 # JkRequestLogFormat set the request format 
 JkRequestLogFormat "%w %V %T" 
 # Send all MyWebApp requests to Tomcat
 JkMount /MyWebApp/* loadbalancer
 # Send JKStatus Console
 JkMount /jkstatus/ status

 RewriteEngine On
 RewriteRule ^/$ /MyWebApp/ [PT,L]

Einstellungen in der Datei worker.properties (/etc/apache2):
Diese finden sich im Listing unten. Diese worker.properties führt ein Load-Balancing der Http-Requests auf 4 Tomcat-Server durch (mit einem Apache-WS davor). Sollen die 4 Tomcats die Requests von 2 Apache-WS-Servern erhalten, so bräuchte man 2 worker.properties. Ich würde dann jedoch weiterhin die Namen der Server global durchnummerieren, sprich svr1..svr4 und nicht svr1/svr2 für den ersten Apache-WS und erneut svr1/svr2 für den zweiten Apache-WS, da der Servername an die JSESSIONID angehängt wird und man somit einfacher herausfinden kann, an welchen Server der HttpRequest ging, um dann beispielsweise schneller das zugehörige Logfile zu finden. Zeile 29 ist noch erwähnenswert: Das Modul mod_jk geht standardmäßig von max. 3 Servern aus, auf die die Last verteilt werden soll. Aus diesem Grund ist hier der Wert auf 4 angepasst worden.

worker.list=svr1,svr2,svr3,svr4,loadbalancer,status
worker.svr1.type=ajp13
worker.svr1.host=xx.xx.xx.xx
worker.svr1.port=9008
worker.svr1.lbfactor=1
worker.svr1.socket_keepalive=1
worker.svr1.socket_timeout=300
worker.svr2.type=ajp13
worker.svr2.host=xx.xx.xx.xx
worker.svr2.port=9009
worker.svr2.lbfactor=1
worker.svr2.socket_keepalive=1
worker.svr2.socket_timeout=300
worker.svr3.type=ajp13
worker.svr3.host=xx.xx.xx.xx
worker.svr3.port=9008
worker.svr3.lbfactor=1
worker.svr3.socket_keepalive=1
worker.svr3.socket_timeout=300
worker.svr4.type=ajp13
worker.svr4.host=xx.xx.xx.xx
worker.svr4.port=9009
worker.svr4.lbfactor=1
worker.svr4.socket_keepalive=1
worker.svr4.socket_timeout=300
worker.loadbalancer.type=lb
worker.loadbalancer.sticky_session=1
# Adjust to the number of workers (4 in our case)
worker.retries=4
worker.loadbalancer.balance_workers=svr1,svr2,svr3,svr4
worker.status.type=status

JKStatus-Konsole:

Diese ist im Bild rechts zu sehen. Meines Erachtens ist diese Konsole während der Lasttests ein sehr nützliches Hilfsmittel. In Produktion sollte dann jedoch eher Nagios benutzt werden. Man sieht in der Konsole beispielsweise sehr schön, ob sich die Last gleichmäßig auf alle Tomcat-Server verteilt. Auch bekommt man sehr schnell mit, wenn ein Tomcat Probleme hat. Hierbei sind folgende Angaben (rote Umrandung im Bild rechts) von besonderem Interesse:

Busy (Current number of busy connections)
Max (Maximum number of busy connections).

Bei hohen Werten hat der Tomcat Probleme, meistens hängen dann Tomcat-Threads, beispielsweise verursacht durch eine überlastete Datenbank.

Teil 1 - Grails in Produktion – mit Apache, Tomcat und MySQL

noreply@blogger.com (Peter Soth) — Mon, 13 Feb 2012 08:19:00 +0000

Mit diesem Blog-Post möchte ich die Schritte, die nötig sind, um eine Grails Applikation produktiv zu stellen, beschreiben. Dieses Thema werde ich in aufeinanderfolgende Blog-Posts aufteilen. Die Aufteilung sieht folgendermaßen aus:

Teil 1 – Allgemeines zur Systemarchitektur und Ergänzungen in Grails
Teil 2 – Apache Web Server
Teil 3 – Tomcat
Teil 4 – MySQL
Teil 5 – Load Tests

Systemarchitektur
Das Bild rechts beschreibt die gewählte Systemarchitektur. Diese besteht aus folgenden Komponenten:

Load-Balancer – dieser kann sowohl auf Soft-, wie auch auf Hardware basieren. Meistens wird hier Hardware favorisiert. Wichtig ist, dass der Load-Balancer „Sticky Sessions“ unterstützt, sprich einen User-Request immer wieder an den ursprünglichen Apache WS weiterleitet.
Apache Web Server – hier benutzen wir mod_jk zur Kommunikation zwischen Apache WS und Tomcat. Gründe hierfür sind: sehr ausgereift und wir benutzen meistens keine SSL Verschlüsselung zwischen Apache WS und Tomcat. Falls SSL notwendig ist, sollte eher mod_proxy_http benutzt werden [1].
Tomcat – hier ist wichtig zu erwähnen, dass wir nur ein Load-Balancing für die Requests durchführen, also kein Cluster mit Session Replication. Dies reicht in den meisten Fällen vollkommen aus. Nachteilig hierbei ist, dass ein User sich erneut anmelden muss, falls eine Tomcat-Instanz abstürzt. Als Nachteile für ein Cluster können folgende Punkte aufgeführt werden:
- Performanz – jede Session wird auf einen Backup-Server (in-memory) über das Netzwerk repliziert. Bei sehr vielen Sessions (und vielen Tomcat-Instanzen im Cluster) kann dies eine sehr hohe Netzwerklast verursachen. Die Sessions können auch in einer Datenbank persistiert werden. Dies ist jedoch nicht performanter.
- Bei der Entwicklung muss beispielsweise beachtet werden, dass alle Objekte in der HTTP-Session serialisierbar sind. Auch darf die http-Session nicht zu groß sein (max. 50 – 70 KByte). Des Weiteren darf beispielsweise keine Hibernate-Session in einem HTTP-Objekt gespeichert werden. Obwohl wir wissen, dass dies Anfängerfehler sind, treten diese Fälle trotzdem sehr oft auf. Insbesondere in hektischen Projektphasen. Dies bedeutet schließlich, dass ein Cluster höhere Aufwände verursacht.
MySQL – wir verwenden auch sehr gerne PostgreSQL. Jedoch ist MySQL bei den Hosting Providern unserer Kunden öfters vertreten. Deshalb wird hier auf MySQL eingegangen. Wichtig ist hier, sich über einen Fail-Over-Szenario im klaren zu sein. Es gibt mehrere Möglichkeiten, beispielsweise Linux-Cluster, VM-Ware-Cluster, Sequoia, etc. Die Hosting-Provider unserer Kunden setzen hier meistens ein Linux-Cluster ein.

Ergänzungen in Grails
Folgende Ergänzungen sollten meines Erachtens in Grails hinzugefügt werden:

GSP-Seite mit folgenden Informationen:
- Information über die für den Build des WAR-Files benutzte Revision-Nummer des Sourcecode-Systems (Subversion in meinem Fall).
- Ausgabe von allen Cookies. Hier ist insbesondere die JSESSIONID von Interesse, da mod_jk den in der workers.properties gewählten Servernamen an die JSESSIONID anhängt.
Konfiguration des Connection-Pools im Tomcat. Dieser wird dann als JNDI Connection-Pool in der Grails-Applikation benutzt. Dies hat den Vorteil, dass eine neue Datenbank mit anderen Settings, ohne ein erneutes Kompilieren der Grails-Applikation, benutzt werden kann.
Ausgabe der Logfiles in ${CATALINA_HOME}/logs. Nun könnte jemand auf die Idee kommen, dies über einen JNDI Eintrag steuern zu wollen, wie in meinem Blog [3] beschrieben. Hierbei ist jedoch das Problem, dass die Config.groovy vor der resources.groovy (die den Zugriff auf JNDI durchführt) aufgerufen wird.

Revision aus Subversion während Grails War-File Build ermitteln
Der Code unten basiert auf einem Code-Snippet von StackOverflow [2]. Ich habe diesen modifiziert (Zeile 32), so dass die Revision-Nummer angezeigt wird. Dieser Code muss der Datei _Events.groovy hinzugefügt werden.

import org.tmatesoft.svn.core.SVNException
import org.tmatesoft.svn.core.wc.SVNRevision
import org.tmatesoft.svn.core.wc.SVNInfo
import org.tmatesoft.svn.core.wc.SVNWCClient
import org.tmatesoft.svn.core.wc.SVNClientManager
import org.tmatesoft.svn.core.internal.io.fs.FSRepositoryFactory
import org.tmatesoft.svn.core.internal.io.svn.SVNRepositoryFactoryImpl
import org.tmatesoft.svn.core.internal.io.dav.DAVRepositoryFactory

// Create revision info in case of a WAR build
eventWarStart = { type ->

    println "******************* eventWarStart *****************"
    try {
        // initialise SVNKit
        DAVRepositoryFactory.setup();
        SVNRepositoryFactoryImpl.setup();
        FSRepositoryFactory.setup();

        SVNClientManager clientManager = SVNClientManager.newInstance();
        println "clientManager = " + clientManager.toString();
        SVNWCClient wcClient = clientManager.getWCClient();
        println "wcClient = " + wcClient.toString();

        // the svnkit equivalent of "svn info"
        File baseFile = new File(basedir);

        println "baseFile = " + baseFile.toString();
        SVNInfo svninfo = wcClient.doInfo(baseFile, SVNRevision.WORKING);
        println "svninfo = " + svninfo.toString();

        def version = svninfo.revision.number as String
        println "Setting Version to: ${version}"
        metadata.'app.version' = "${version}".toString()
        metadata.persist()

    }
    catch (SVNException ex) {
        //something went wrong
        println "**************** SVN exception **************"
        println ex.getMessage();
    }

} // End eventWarStart()

Während des Builds wird die Revisions-Nummer in der Datei application.properties (siehe unten Zeile 6) geändert.

#Grails Metadata file
#Sat Jan 21 16:17:44 CET 2012
app.grails.version=1.3.7
app.name=MyGrailsProject
app.servlet.version=2.4
app.version=455
plugins.aop-reloading-fix=0.1
plugins.batch-launcher=0.5.6
plugins.csv=0.3.1
plugins.fixtures=1.1
plugins.hibernate=1.3.7
plugins.jquery=1.7.1
plugins.jquery-ui=1.8.15
plugins.mail=1.0-SNAPSHOT
plugins.resources=1.0.2
plugins.spring-security-core=1.2.4
plugins.tomcat=1.3.7

In der BuildConfig.groovy muss dann noch überprüft werden, ob das War-File nicht die Revisionsnummer angehängt bekommen hat. Sonst hätte der Name des War-Files folgenden Aufbau : MyProject-455.war, mit dem Nachteil, dass sich jedes Mal die Url der Grails-Applikation ändern würde.

grails.project.class.dir = "target/classes"
grails.project.test.class.dir = "target/test-classes"
grails.project.test.reports.dir = "target/test-reports"
grails.project.war.file = "target/${appName}.war"
grails.project.dependency.resolution = {
...

Das Ganze kann in einer GSP-Seite (inkl. Ausgabe der Cookies) folgendermaßen dargestellt werden:

<%--
  Created by IntelliJ IDEA.
  User: Peter Soth
  Date: 11.01.12
  Time: 11:49
  To change this template use File | Settings | File Templates.
--%>
<html>
<head>
    <meta http-equiv="Content-Type" content="text/html; charset=UTF-8"/>
    <meta name="layout" content="main"/>
    <title>Info:</title>
</head>

<body>







The following revision has been used for the build of this WAR.

REV: ${grailsApplication.metadata.'app.version'}







Show all cookies


    NAME: ${cookie.name} VALUE: ${cookie.value}

</body>
</html>

Tomcat JDBC Connection-Pool mittels JNDI einbinden
Hierzu wird in DataSource.groovy folgendes eingetragen:

// environment specific settings
environments {
    production {
        dataSource {
            jndiName        = "java:comp/env/jdbc/production"
            dialect         = org.hibernate.dialect.MySQL5InnoDBDialect
            dbCreate        = 'update'
        }
    }
...

Im Blog-Post zum Tomcat zeige ich dann, wie dies im Tomcat konfiguriert wird.

Logging in CATALINA_HOME festlegen
Mit folgendem Code-Snippet werden die Logs-Files der Grails-Applikation in das Log-Verzeichnis des Tomcat-Servers geschrieben. Hierzu muss die Variable logDirectory in der log4j-Konfiguration in Config.groovy benutzt werden.

// request parameters to mask when logging exceptions
grails.exceptionresolver.params.exclude = ['password']

// set per-environment serverURL stem for creating absolute links
environments {
 ...
    production {
        grails.serverURL = "http://www.changeme.com"
        //tomcat based logging
        def catalinaHome = System.getenv('CATALINA_HOME')
        if (!catalinaHome) catalinaHome = '.'   // falls nicht gesetzt
        def String grailsLogDir = "${catalinaHome}/logs/"
        ...
    }
}

[1] Tomcat Expert Blog
[2] StackOverflow: SVN Revisionsnummer in Grails einbinden
[3] Grails : JNDI Werte im Embedded Tomcat setzen

Grails 2.0 Upgrade Guide

noreply@blogger.com (Peter Soth) — Mon, 06 Feb 2012 08:54:00 +0000

Auf Google+ [1] hat das Grails-Team die Grails Community über Ihre Erfahrungen bei der Migration auf Grails 2.0 befragt. Um es kurz zu machen: Bei kleinen Applikationen ist eine Migration sehr einfach, bei großen Applikationen gibt es jedoch Probleme. Vor allem bei der Migration von Tests gibt es Probleme. Laut Grails Team soll man auf Grails 2.0.1 [2] warten, sofern man die Tests auch migrieren möchte. Dies dürfte bei den meisten Projekten – wie auch bei uns - der Fall sein. Und hier geht es zum Upgrade Guide von Peter Ledbrook [3].

[1] https://plus.google.com/117411438136918964913/posts/axyCZk1P5L5
[2] https://plus.google.com/117411438136918964913/posts/TFw4YvNfQXX
[3] http://pledbrook.github.com/grails-howtos/en/upgradeToGrails2.html

Recruiting 2.0 – exensio auf Youtube - IT Berater (w/m) mit hohem *PZU-Faktor gesucht

noreply@blogger.com (Peter Soth) — Sun, 05 Feb 2012 17:05:00 +0000

Unter Recruiting 2.0 versteht man die Benutzung von Web 2.0 Diensten, wie Xing, Facebook, Twitter, Google+ und Youtube zur Mitarbeitergewinnung. Bisher sind wir bei exensio auch den klassischen Weg mit Anzeigen in Jobbörsen gegangen. Vor allem für kleinere Unternehmen hat dies jedoch den Nachteil, dass Stellen- ausschreibungen leider in der Masse untergehen.

Warum neue Kollegen über einen Youtube Kanal suchen?

Uns wurde schnell klar, dass wir einen anderen Weg versuchen mussten und als Software-Ingenieure auch professionelle Unterstützung hierfür benötigen würden. Mit dem Kommunikationsdesigner Michael Starzmann von gadget Strategie + Design [1][2] hatten wir endlich den Richtigen gefunden, der sich voll und ganz auf unserer Wellenlänge befindet. gadget zeichnet meiner Meinung nach vor allem durch tragfähige sowie angemessene Lösungen aus, denn wir hatten kein Budget für ein ganzes Filmteam etc. Weitere Infos finden sich auf dem gadget Blog [3]

Fazit
Um es gleich vorweg zu nehmen: Mit dem Hochladen eines Videos auf Youtube steigen nicht über Nacht die Zahl der Bewerbungen an. Unsere Intension war hierbei eine andere: Wir sehen das Youtube Video mehr als Möglichkeit, uns unseren potentiellen neuen Mitarbeitern in 30 Sekunden vorzustellen und vielleicht etwas mehr von der exensio „Idee“ rüberzubringen, als dies mit einer statischen Web-Seite oder einer PDF-Datei möglich ist. Das sehr positive Feedback, das wir bisher erhalten haben, zeigt uns, dass es der richtige Weg ist - wir würden es auf jeden Fall wieder machen. Des Weiteren ist zu erwähnen, dass das Video länger für uns arbeitet, als eine Anzeige auf einem Jobportal.

[1] http://www.gadget.de
[2] http://blog.gadget.de
[3] http://blog.gadget.de/?p=163

Vermeiden von ClassCastExceptions beim Reloading in Grails-Applikationen

noreply@blogger.com (Tobias Kraft) — Thu, 02 Feb 2012 17:48:00 +0000

Problem

Einer der Hauptvorteile von Grails gegenüber anderen Frameworks bzw. Sprachen ist die schnelle Entwicklung. Bei laufendem Server können Änderungen vorgenommen und diese sind ohne einen lang dauernden Publizierungsvorgang verfügbar.
Unter bestimmten Umständen funktioniert allerdings der Reload von Änderungen in Controllern oder Services nicht bei laufendem Server. Nimmt man eine Änderung vor und lädt anschließend über den Browser die Seite neu, dann resultiert dies in eine ClassCast-Exception, die nur durch einen Server-Neustart zu beheben ist. Das Problem tritt unseren Beobachtungen zufolge insbesondere im Zusammenhang mit dem Spring-Cache-Plugin auf, das Annotation verwendet. Auch bei anderen Annotationstypen ist das Problem schon aufgetaucht und bekannt [1]

Lösung

Ab der Grails-Version 2.0 ist dieses Problem behoben. Für andere Grails-Versionen lässt sich das Problem durch Installation des „AOP Reloading Fix“ Plugins [2] beheben. Dies funktioniert standardmäßig allerdings nur für die Umgebung (Environment) Development.
Wird eine eigene Umgebung für die Entwicklung eingerichtet, z.B. zum Umsetzen von Batches, dann werden die Erweiterungen des Plugins nicht angezogen. Durch Setzen der Variable grails.reload.enabled beim Starten der Anwendung kann dies umgangen werden und das Plugin wird angezogen. Die folgende Abbildung zeigt in IntelliJ den Befehl zum Starten der Umgebung devbatch. Zusätzlich werden die beiden Variablen grails.reload.enabled=true und grails.reload.location=. übergeben.

Links

[1] http://jira.grails.org/browse/GRAILS-6370
[2] AOP Reloading Fix Plugin

Grails : JNDI Werte im Embedded Tomcat setzen

noreply@blogger.com (Peter Soth) — Mon, 30 Jan 2012 18:39:00 +0000

JNDI eignet sich sehr gut, um einer Web-Applikation von außen (über den Tomcat) Parameter zur Verfügung zu stellen. Die JNDI Einstellungen werden in Tomcat in der context.xml vorgenommen. Entwickelt man in Grails (beispielsweise mit IntelliJ), so läuft der Tomcat jedoch im Embedded Mode. Dies bedeutet, dass keine context.xml vorhanden ist, die editierbar wäre. In den folgenden Code-Beispielen möchte ich zeigen, wie ein JNDI Wert ausgelesen und im Embedded Tomcat gesetzt werden kann. Dies ist beispielsweise zum Testen sehr nützlich.

So würde das Setzen eines JNDI Parameters in der Context.xml (auf dem Produktionsserver) aussehen:


  ...
  
  ...

In der Grails Test-Umgebung werden dann in der Datei _Events.groovy die JNDI Werte gesetzt. Hier muss beachtet werden, dass MyWebAppName durch den richtigen Namen der Web Applikation ersetzt wird. In dem Beispiel unten ist es nicht nötig, das Grails Tomcat Plugin zu modifizieren, wie es in den Grails Mailing-Listen diskutiert wurde:

eventConfigureTomcat = {tomcat ->
    println "### Start Tomcat configuration"

    try {
        def environment = tomcat.class.classLoader.loadClass('org.apache.catalina.deploy.ContextEnvironment').newInstance()
    
        environment.name = 'jnditest'
        environment.type = 'java.lang.String'
        environment.value = 'Grails JNDI Test String'
        environment.override = Boolean.TRUE
    
        def context = tomcat.host.findChild('/MyWebAppName')
        context.namingResources.addEnvironment environment
    }
    catch (Exception e)
    {
        e.printStackTrace()
    }
    println "### End Tomcat configuration"
}

Auslesen in der resources.groovy. So funktioniert es sowohl in der Test- als auch in der Produktions-Umgebung. In dem Beispiel unten wird jedoch überprüft, ob Grails im Entwicklungsmodus läuft:

import org.springframework.web.servlet.i18n.SessionLocaleResolver

// Place your Spring DSL code here
beans = {
    localeResolver(SessionLocaleResolver) {       
        Locale.setDefault(Locale.GERMAN)
    }
    
    if (grails.util.GrailsUtil.environment.equals('development')) {
        jnditest(org.springframework.jndi.JndiObjectFactoryBean) {
            jndiName = 'java:/comp/env/jnditest'
        }
    }
}

Links:
[1] http://tomcat.apache.org/tomcat-7.0-doc/config/context.html#Environment Entries

Langsame Netzwerk-Geschwindigkeit mittels Apache-Webserver simulieren

noreply@blogger.com (Manuel Breitfeld) — Thu, 12 Jan 2012 14:56:00 +0000

Einleitung

Im Bereich der Web-Entwicklung gibt es viele unterschiedliche Szenarien, die zu testen sind, bevor eine Änderung "live" gehen kann. Neben den typischen Kompatibilität-Tests auf Betriebssystem, Browser und Bildschirmauflösung ist auch die Netzwerk-Geschwindigkeit eine Komponente, der Beachtung geschenkt werden sollte.
Insbesondere wenn Ressourcen nachgeladen werden müssen, ist es wichtig zu testen, wie die Web-Applikation bei verschiedenen Übertragungsgeschwindigkeiten reagiert.

In einem aktuellen Projekt haben wir eine Flash/AS3-Applikation getestet, die JSON-Daten per asynchronem Request vom Server erhält und daraufhin externe Bilddateien in die Applikation nachlädt. In erster Linie musste also sichergestellt werden, dass die Applikation auch bei langsamer Übertragungsrate und gleichzeitig hoher Anzahl nachzuladender Bilder intuitiv zu bedienen bleibt (sprich: Einführung von Ladebalken, Deaktivierung von bestimmten Elementen, etc.).

Das Tool "Throttle"

Während es für den Apache Webserver mittlerweile auch Module gibt, die das "throttling" übernehmen können sollen, gibt es damit relativ schnell Kompatibilitätsprobleme zwischen den unterschiedlichen Webserver Versionen.
Als zuverlässig hat sich das kleine auf Pipe-Basis [1] operierende Tool Throttle [2] herausgestellt. Unter Linux erfolgt die Installation einfach mit dem gewohnten Dreisatz "./configure && make && make install".

Apache Webserver und Throttle

Pipe-Tools lassen sich auf einfache Weise in den Apache Webserver einbinden (Stichwort SetOutputFilter [3]). Im Folgenden ist die Beispiel-Konfiguration für ein Bandbreiten-Limit von 56K angegeben:


# 56KB/s filter definition
ExtFilterDefine ksec56 mode=output cmd="/usr/local/bin/throttle 57344" preservescontentlength 
# Use filter (e.g. in Location or VirtualHost directive)
SetOutputFilter ksec56

Der Filter kann beispielsweise innerhalb einer belieben Location- or VirtualHost-Anweisung verwendet werden.

Fazit

Mittels Throttle und dem Apache Webserver können auch verschiedene Übertragungsgeschwindigkeiten einfach in die Tests bei der Web-Entwicklung einbezogen werden. Mithilfe der Location- oder VirtualHost-Anweisung kann die Beschränkung nur für einzelne Verzeichnisse aktiviert werden - perfekt um langsame externe Server zu simulieren.

Links

[1] Pipe auf Wikipedia
[2] Website zu Throttle
[3] Dokumentation zu SetOutputFilter

exensio wünscht ein frohes Fest und ein erfolgreiches neues Jahr

noreply@blogger.com (Peter Soth) — Thu, 22 Dec 2011 16:50:00 +0000

Unsere besten Wünsche

für ein frohes Weihnachtsfest

und ein glückliches, erfolgreiches neues Jahr.

Auch in diesem Jahr verwenden wir den von

uns für Weihnachtsgeschenke vorgesehenen Betrag zu Gunsten einer Spende an die

Marc Soth Stiftung in der Trägerschaft der SOS Kinderdorf Stiftung.

Criteria List Queries bei Many-To-Many Beziehungen in Grails

noreply@blogger.com (Manuel Breitfeld) — Thu, 22 Dec 2011 13:52:00 +0000

Einleitung

In diesem Beitrag wird gezeigt, wie n:m Beziehungen in Grails (Stichwort 'hasMany') innerhalb einer Query abgefragt werden können.
Als Beispiel betrachten wir die Beziehung zwischen einer Person und eines Projekts. Eine Person kann in mehreren Projekten involviert sein. In einem Projekt arbeiten wiederum mehrere Personen. Die Modellierung in Domain-Klassen könnte wie folgt (vereinfacht) aussehen

class Person {
String firstname
String lastname
static hasMany = [projects:Project]
}

class Project {
String name
static hasMany = [persons:Person]
}

Datenbank-Abfragen

Im Folgenden sollen zwei Abfragen betrachtet werden:

Liefere alle Personen, deren Vorname "Max" oder "Moritz" ist.
Liefere alle Projekte, bei welchen Personen mit Vorname "Max" oder "Moritz" beteiligt sind.

Die erste Abfrage kann einfach mit dem dynamischen Finder findAllBy*InList [1] in Grails realisiert werden.

def firstnames = ["Max", "Moritz"]
def result = Person.findAllByFirstnameInList(firstnames)

Die zweite Abfrage kann nicht mehr über einen dynamischen Finder abgehandelt werden. Hierfür verwenden wir ein Criteria [2]. Criteria-Abfragen sind eine geschickte Möglichkeit, um komplexe Queries in Grails-Syntax relativ übersichtlich zu schreiben. Die zweite Abfrage lässt sich wie folgt realisieren:

def firstnames = ["Max", "Moritz"]
def c = Project.createCriteria()
def result = c.list() {
persons {
    inList("firstname", firstnames)
}
resultTransformer Criteria.DISTINCT_ROOT_ENTITY
}

Innerhalb der list-Closure des Criterias kann auf die einzelnen Attribute der Domain-Klasse zugegriffen werden - im Beispiel greifen wir auf die Assoziation "persons" zu. Mit der nächsten Closure wird sichergestellt, dass nur jene Personen zurückgeliefert werden, deren Vorname in der angegebenen Liste enthalten ist.

Sowohl der findAllBy-Finder als auch das list-Criteria akzeptieren die typischen Parameter wie max, offset, sort oder order, die vor allem bei Web-Applikationen für tabellarische Darstellungen unumgänglich sind.

Links

[1] findAllBy in der Grails-Dokumentation
[2] createCriteria in der Grails-Dokumentation

Datenbank-Migrationen mit Grails

noreply@blogger.com (Tobias Kraft) — Tue, 22 Nov 2011 21:32:00 +0000

Problemstellung
Wird für eine Applikation, die darunterliegende Datenbank ausgetauscht, dann sind im Idealfall keine Änderungen im Anwendungscode notwendig. Dies sollte zumindest gelten wenn die Applikation Standard-SQL einsetzt. Unabhängig davon müssen aber die Daten von der ursprünglichen Datenbank in die Zieldatenbank überspielt werden. Für eine Grails-Applikation standen wir genau vor dieser Herausforderung, wobei von einer MySQL-Datenbank auf eine PostgreSQL-Datenbank migriert wurde.

Hierfür gibt es nun mehrere Möglichkeiten. Relativ einfach erscheint das Durchführen eines Datenbank-Exports, anschließendes modifizieren der Daten und abschließendes Importieren in PostgreSQL. Leider hat bei keinem der verfügbaren Tools zur Modifizierung (siehe [1]) der Import funktioniert, d.h. die Daten konnten nicht korrekt für PostgreSQL modifiziert werden. Des Weiteren gibt es kommerzielle Tools wie bspw. easyfrom, die über eine entsprechende Oberfläche die Migration von der Quell- zur Zieldatenbank ermöglichen. Eine weitere Möglichkeit ist die Verwendung eines Grails-Plugins wie beispielsweise DB Stuff [2]. Mit dem Plugin können Daten aus einer DB in XML abgespeichert werden und von XML wiederum in eine Datenbank eingelesen werden.

In unserem Fall traten Probleme bezüglich der unterschiedlichen Datentypen zwischen MySql und PostgreSQL auf. Außerdem ist das Handling von DB-Relationen mit dieser Art von Plugins eher schwierig bzw. nicht möglich. Aufgrund der Historie hatten wir auch einige Spalten im Originalschema, für die es kein Mapping mehr in den Grails-Domain-Klassen gab. Sie waren also unbenutzt und sollten möglichst automatisiert entfernt werden.
Der Entschluss fiel schließlich zur Erstellung einer eigenen kleinen Migrationssuite.

Migrationsidee
Die Idee zur Durchführung ist relativ einfach. Über Grails Domain-Klassen werden die Daten aus der alten DB ausgelesen und anschließend werden die Inhalte der Domain-Objekte direkt in die neue Datenbank gespeichert.
Folgende Punkte sind hierbei zu beachten und müssen gelöst werden:

Zugriff auf zwei Datenbanken in einer Grails-Applikation
Transaktionen: Abhängig von der Datenmenge ist ein entsprechendes Transaktionshandling notwendig
Definition von fachlichen Schlüsseln, um Relationen in der Ziel-Datenbank wieder zu erstellen

Migrationsdurchführung
Für den Zugriff auf zwei Datenbanken wurde das Datasources Plugin [3] eingesetzt. Die Standard-Konfiguration für Datenbanken in der Datei DataSource.groovy zeigte auf die alte DB und war wie bisher mit allen bestehenden Domain-Klassen verknüpft.
Die bestehenden Domain-Klassen wurden alle in ein neues Package kopiert und über das Datasources Plugin mit der neuen DB verknüpft. Hierfür können, wie nachfolgend dargestellt, in der Konfigurations-Datei des Plugins die zu verknüpfenden Domain-Klassen angegeben werden. Des Weiteren kann auch angegeben werden welche Services per Default auf die konfigurierte Data-Quelle zugreifen.

datasources = {
 datasource(name: 'dsPostgresMigration') {
  domainClasses([com.exensio.timesheet.migrate.RenderReportLevel,...])
  readOnly(false)
  pooled(true)
  dialect(org.hibernate.dialect.PostgreSQLDialect)
  driverClassName('org.postgresql.Driver')
  url('jdbc:postgresql://192.168.11.211:5432/extime')
  username('...')
  password('...')
  dbCreate('update') 
  pooled(true)
  services(['migration'])
 }
}

Für die eigentliche Migration ist der MigrationService zuständig. Der Service enthält für jedes zu migrierende Domain-Klassen-Geflecht eine Methode. Im einfachsten Fall führt eine Methode die Migration für genau eine Domain-Klasse und damit Datenbanktabelle durch. Das nachfolgende Code-Fragment zeigt wie im ersten Schritt alle zu migrierenden Domain-Objekte ausgelesen werden. Anschließend wird über diese iteriert und bei jedem Schleifendurchlauf alle Attribute bis auf die technische ID vom alten Domain-Objekt in ein neu erstelltes Domain-Objekt kopiert und gespeichert.

def migrateRenderReportLevel() {
 def renderReportLevels = com.exensio.timesheet.RenderReportLevel.list()
 def domainClass = new DefaultGrailsDomainClass(RenderReportLevel.class)

 renderReportLevels.each {oldDomainObject ->
  def newDomainMap = [:]
  domainClass.persistentProperties.each { property ->
   newDomainMap[property.name] = oldDomainObject[property.name]
  }
  RenderReportLevel newDomainObject = new RenderReportLevel(newDomainMap)
  newDomainObject.save(flush: true)
  if (newDomainObject.hasErrors()) {
   handleErrors(newDomainObject)
  }
  else {
   log.info "${newDomainObject.class.simpleName} ${oldDomainObject.id} migrated"
  }
 }
}

Durch die Nutzung eines Service und die Aufspaltung in mehrere Methoden kann der Ablauf der Migration einfach in mehrere Transaktionen eingeteilt werden. Die Hauptschwierigkeit bei der Migration ist die Auflösung der Beziehungen. In vielen Fällen kann die Migration über mehrere Objekte in einer Methode direkt erfolgen. Allerdings gibt es auch Domain-Klassen, die von mehreren anderen referenziert werden. Hier ist darauf zu achten, dass die Migration nur einmal erfolgt und die Beziehungen anschließend über fachliche Schlüssel erstellt werden.
In unserem Fall gibt es die beiden Domain-Klassen User und Role, die in einer Methode migriert wurden. Die Klasse User wird auch von der Klasse Project referenziert, die wiederum in einer separaten Methode migriert wurde. Diese Migration-Methode sucht sich über den eindeutigen Login-Namen den entsprechenden User aus der Tabelle und setzt die Beziehung.

Employee existing = Employee.findByUsername(oldDomainObject.projectManager.username)
if (existing) {
 newDomainObject.projectManager = existing
}

Zusammenfassung
Das vorgestellte Verfahren für eine Datenbankmigration erfordert zwar etwas Programmierarbeit, ist aber dank Grails in kurzer Zeit umzusetzen. Es bietet sich insbesondere an wenn bei der Migration Sonderfälle zu beachten sind, wie bspw. das Entfernen nicht mehr benötigter Spalten.

Links
[1] Converting from other Databases to PostgreSQL
[2] DB Stuff Plugin
[3] Datasources Plugin

Verbesserung der Usability mittels Faceted Search

noreply@blogger.com (Peter Soth) — Sun, 20 Nov 2011 16:16:00 +0000

Die Idee der Faceted Search basiert auf der Facettenklassifikation [1][2]. Diese wurde 1933 von dem indischen Mathematiker und Bibliothekar S. R. Ranganathan [3] entwickelt, um die Bestände der Universitätsbibliothek von Madras zu katalogisieren. Bei der Facettenklassifikation werden Objekte des Wissensbereichs nicht in eine starre Baumstruktur eingegliedert, sondern durch mehrere voneinander unabhängige Gesichtspunkte definiert. In folgendem Blogeintrag möchte ich kurz beschreiben, wie User mittels Faceted Search schneller und präziser Informationen finden können und somit die Usability von (Web-) Applikationen gesteigert werden kann.

Anwendungsbeispiele
Die Faceted Search ist heute vor allem bei Online Shops anzutreffen. Als prominentestes Beispiel kann hier Amazon genannt werden. Die Faceted Search setzt sich jedoch auch immer mehr bei der Verwaltung und späteren Suche von Informationen, wie Dokumenten oder Emails durch. Als Beispiel kann hier Google Mail betrachtet werden. Im Vergleich zu Outlook werden Mails nicht hierarchisch abgelegt, sondern mit Label versehen. Label sind auch unter dem Begriff Tag bekannt. Eine Hierarchie lässt sich beispielsweise unter Benutzung von Pfadnamen realisieren, wie es auch bei Google Mail gemacht wird.

Vorteile
Beim Ablegen von Dokumenten trifft man oft auf die Problematik, dass ein Dokument eigentlich in mehreren Knoten einer Baumstruktur abgelegt werden soll. Dies ist bei einer starren Baumstruktur nicht möglich (Google Mail versus Outlook). Bei der Faceted Search werden die Dokumente mit Tags versehen (verschlagwortet) und können später in verschiedenen Knoten angezeigt (gefiltert)werden. Ein Nebeneffekt der Verschlagwortung ist, dass die Dokumente eindeutig klassifiziert werden. Dies hat den großen Vorteil – im Vergleich zu einer Volltextsuche, dass Informationen präziser und schneller gefunden werden können. Bei einer Volltextsuche wird für die Dokumente beim Indizieren ein Wortvektor ermittelt. In der Suchergebnismenge wird dann die Relevanz eines Suchbegriffs über den Wortvektor ermittelt. Das Problem hierbei ist, dass die Relevanz nur eine Annäherung darstellt. Der semantische Bezug zum eigentlichen Suchwort ist meist nicht gegeben. So erreicht beispielsweise Google erst unter Einbeziehung von Wikipedia bessere Suchergebnisse.

Voraussetzung für den Einsatz einer Faceted Search
Die wichtigste Voraussetzung für die Benutzung von Faceted Search ist die Erstellung einer Tag Taxonomie. Diese kann beispielweise aus der Menüstruktur abgeleitet werden. Wichtiger Tipp hier ist, nicht mehr als 4 Hierarchieebenen aus der Menüstruktur zu übernehmen. Die Tags werden dann später zur Verschlagwortung durch den Editor herangezogen.

Beispiel

Als Beispiel (siehe Wireframe rechts) möchte ich das Dokumenten-Center unserer Enterprise 2.0 Applikation heranziehen. Auf der linken Seite wird die Faceted Search angezeigt. In unserem Fall ist sie hierarchisch. Eine flache Struktur wäre auch denkbar. Durch das Markieren der Check-Boxen wird die Suchergebnismenge in der Mitte eingeschränkt, sprich die Dokumente werden gefiltert. Auf der rechten Seite sind technische Filter (oder Navigatoren) platziert, mit denen die Suchergebnismenge nochmals um Aspekte, wie Dokumententyp oder Zeitraum eingeschränkt werden können.

Fazit
In unseren Kundenprojekten haben wir die Erfahrung gemacht, dass Benutzer schneller und präziser die gewünschten Informationen mittels Facted Search - im Vergleich zur Volltextsuche - finden. Hierdurch kann die Usability von (Web-)Applikationen enorm gesteigert werden. Nicht verschweigen sollte man jedoch, dass es eine gewisse Zeit für den Benutzer bedarf, bis er sich von einer hierarchischen Menüstruktur gelöst hat.

Links
[1] http://de.wikipedia.org/wiki/Facettenklassifikation
[2] http://de.wikipedia.org/wiki/Colon-Klassifikation
[3] http://de.wikipedia.org/wiki/S._R._Ranganathan

Excel Prozesse und warum es sinnvoll ist, diese durch Grails Web Applikationen zu ersetzen

noreply@blogger.com (Peter Soth) — Sun, 30 Oct 2011 15:36:00 +0000

Excel gilt in Fachabteilungen als das Schweizer Taschenmesser um verschiedenste Prozesse abzubilden. So ist ein Prozess auf den ersten Blick schnell aufgesetzt und das ohne die Involvierung der IT-Abteilung, die den Fachabteilungen bekanntlich meistens zu langsam ist.

Als fiktiven Prozess können wir hier beispielsweise den Export eines Excel-Sheets aus dem SAP System heranziehen. Dieses Excel-Sheet wird dann per Mail oder Fileshare zwischen den unterschiedlichen Abteilungen (oder auch mit externen Dienstleistern) verteilt, die jeweils einen oder mehrere Prozessschritte in diesem Excel-Sheet abarbeiten. Zum Schluss soll dieses Excel Sheet wieder in das SAP System importiert werden.

Einige Leser werden sich nun fragen, wo hier das Problem liegt, da ja genauso in ihrem Unternehmen gearbeitet wird. Zunächst einmal funktioniert das Ganze natürlich auch per Excel-Sheet. Es wird jedoch leicht übersehen, dass diese Excel-Prozesse auf Dauer teurer sind, als wenn sie über eine Software-Lösung abgebildet werden.

Was ist an einem Excel-Prozess suboptimal?
Folgende Punkte können anhand unseres fiktiven Prozesses als nachteilig aufgeführt werden:

Alle im Prozess beteiligten Personen wissen nie, ob sie wirklich die aktuelle Version haben.
Mit MS Sharepoint ist es zwar möglich, ein Excel Sheet in einer Gruppe zu bearbeiten. Dies hat jedoch den Nachteil, dass keine Drittsysteme eingebunden werden können, mit der Folge, dass sich Falscheingaben – wie beispielsweise eine falsche Email-Adresse – einschleichen können. Diese Informationen sollten jedoch direkt aus den Drittsystemen, wie in diesem Fall aus dem Verzeichnisdienst (beispielsweise Active Directory) gezogen werden.
Sollen externe Dienstleister integriert werden, müsste Sharepoint über ein Extranet geöffnet werden. Viele Firmen scheuen sich jedoch momentan noch, aus Gründen der Sicherheit, Sharepoint nach außen zu öffnen.
Der abschließende Import in das SAP System ist sehr fehleranfällig, da es schon reicht, dass jemand im Excel-Sheet versehentlich eine Falschangabe (beispielweise Formatänderung der Zelle, etc.) gemacht hat.
Alle Prozessbeteiligten müssen über die gleiche Excel-Version verfügen. Dies ist dann vor allem problematisch, wenn externe Dienstleister integriert werden sollen.
Die Unterstützung von mobilen Endgeräten (iPad, iPhone oder Android) ist nicht möglich.

Was sind die Alternativen?
Der Königsweg wäre ganz klar, die Prozesse mittels einer unternehmensübergreifen BPM bzw. SOA Strategie abzudecken. Als größtes Problem ist hierbei jedoch aufzuführen, dass solch ein Projekt sehr langwierig ist und die Vorurteile des Fachbereichs gegenüber der IT (zu langsam) sicherlich bekräftigt.

Ein Mittelweg wäre den Excel Prozess mit einer Web Applikation abzubilden. Wir benutzen hier sehr gerne das Open-Source-Framework Grails, mit diesem Framework ist eine schnelle Entwicklung möglich.

Was wären die Vorteile - am Beispiel - unseres fiktiven Prozesses:

In der ersten Phase könnte der Export und Import des Excel-Sheets aus dem SAP System bestehen bleiben. Es ist natürlich auch möglich, auf das SAP System direkt mittels SAPJco oder Web-Services zuzugreifen. Dies hängt ganz von den Wünschen des Kunden ab.
Alle Prozessbeteiligten erhalten eine aktuelle Sicht auf Ihre Daten. Und nur auf ihre Daten. Wir haben in diesem Kontext schon Excel-Sheets mit 5000 und mehr Zeilen gesehen. Ich denke jeder kann sich vorstellen, dass es hier leicht zu Fehleingaben kommen kann.
Externe Dienstleister können über ein Extranet (z.B. XML-Schnittstelle) bedient werden. Da das Grails Framework auf der Java JVM aufbaut, kann hier der gesamte Java Security Stack benutzt werden.
Der abschließende Import in das SAP System könnte direkt über SAPJco oder einen Web-Service erfolgen. Falls der Import über Excel gewählt wird, kann auf jeden Fall sichergestellt werden, dass das zu importierend Excel-Sheet sauber ist.

Fazit
Auf vielen Veranstaltungen bekommen wir positives Feedback, wenn wir unseren Mittelweg der Excel-Prozess-Optimierung vorstellen. So ist vielen Unternehmen schnell ersichtlich, dass ein Excel-Prozess auf lange Sicht viel teurer kommt, als eine saubere Software-Lösung. Der Mittelweg über eine Grails Web Applikation ist somit – aus unserer Sicht – eine sehr gute Lösung für Firmen, die noch nicht bereit sind für den unternehmensübergreifenden BPM/SOA Ansatz.

Wir benutzen nun das CRM System Highrise von 37signals.com

noreply@blogger.com (Peter Soth) — Sat, 01 Oct 2011 16:31:00 +0000

Mit diesem Blogeintrag möchte ich kurz über die von uns gesammelten Erfahrungen, bei der Evaluierung unseres neuen CRM Systems, berichten. Bisher haben wir hierzu eine Kombination aus Outlook und Excel benutzt, mit den bei dieser Kombination typischen Problemen. Ein Anlass diesen Prozess zu optimieren bot sich letzte Woche, als wir von einer Veranstaltung zurück kamen. Wir hatten uns vorgenommen, eine kleine Evaluierung durchzuführen und falls wir nicht fündig werden, ein kleines CRM System - basierend auf dem Grails Framework - selbst zu schreiben. Unsere Projekt-Zeiterfassung haben wir bereits - nach einer erfolglosen Suche - mit dem Grails Framework implementiert [1]. Für uns waren folgende Kriterien besonders wichtig:

Source: 37signals.com

Die Anwendung sollte sehr einfach zu bedienen sein
Die Anwendung sollte keine lange Einarbeitungszeit erfordern
Die Anwendung sollte als Software as a Service (SaaS) verfügbar sein.
Einfacher Import von Kontakten, ohne ein Browser-Plugin installieren zu müssen

Welche Anbieter haben wir uns angeschaut?
Folgende Lösungen sind von uns evaluiert worden:

CAS PIA [2]
SageCRM.com [3]
Salesforce [4]

Schnell mussten wir feststellen, dass unsere Kriterien, wie beispielsweise Einfachheit, von keinem der Systeme erfüllt wurde. Zufällig erinnerten wir uns, dass auf der Homepage der Firma 37signals.com auch ein CRM System angeboten wird. Die Firma 37signals.com ist wohl den meisten als Anbieter der Projektmanagement-Lösung Basecamp bekannt. Aus Basecamp wurde später Ruby on Rails [5] extrahiert und Ruby on Rails ist wiederum der Initiator des Opensource-Projekts Grails[6]. Nun wussten wir, dass wir richtig waren :-).

Was gefällt uns an Highrise von 37signals.com besonders?

Das System sehr einfach und selbsterklärend aufgebaut
Die Lösung ist als SaaS verfügbar
Kontakte können einfach mittels Excel, CSV oder vCard importiert werden
Es können verschiedene Drittsystem (z.B. für den Mailversand) als Add-Ons angebunden werden
Wir können Kontakte mit Schlagworten („Tags“) versehen werden. Diese Vorgehensweise ist viel besser, als ein Kommentarfeld.
Emails können mit Outlook versendet werden. In der BCC Zeile gibt man eine Dropbox-Email-Adresse an. Die Mail wird dann automatisch zu dem Activity Stream des Kontakts hinzugefügt. Dies ist einfach nur genial!

Weitere Infos zu Highrise finden sich hier [7]

Fazit
Wir sind wirklich sehr begeistert von dieser Lösung. Die anderen Anbieter verfügen selbstredend über einen viel größeren Funktionsumfang. Diesen brauchen wir jedoch nicht. Highrise sollte man bei einer CRM-Evaluierung auf jeden Fall in Betracht ziehen.

Links
[1] Erfahrungsbericht: Ablösung einer Excel-basierten Zeiterfassung durch eine Grails Web-Applikation
[2] CAS PIA
[3] SageCRM.com
[4] Salesforce
[5] Homepage Ruby on Rails
[6] Homepage Grails Framework
[7] Highrise Tour

Social Media und das Thema Sicherheit

noreply@blogger.com (Peter Soth) — Fri, 30 Sep 2011 16:46:00 +0000

In den letzten Wochen habe ich wieder sehr viele Blog-Posts gelesen, in denen immer wieder mantraartig auf die mangelnde Bereitschaft deutscher Unternehmen, sich mit dem Thema Social Media zu beschäftigen, hingewiesen wird. Laut zahlreicher Studien (z.B. [1]) lehnen demzufolge knapp 86% aller deutschen Unternehmen Social Media aus Sicherheitsgründen ab.
Auf Veranstaltungen zum Thema Social Media wird von Agenturen meist nur aufgezeigt, wie wichtig es ist, dabei zu sein. Sicherheitsthemen werden gerne ausgeblendet, da dies dem neuen Geschäftsfeld nicht zuträglich ist.
Ich möchte hier nicht gegen Social Media wettern, aber ich finde es immer besser, wenn man sich der Gefahr bewusst ist. Nur dann kann adäquat reagiert werden. Des Weiteren ist es meines Erachtens sehr wichtig, die IT-Abteilung von Anfang an, bei den sicherheitsrelevanten Themen, zu involvieren. Ein Alleingang der Marketing- bzw. Personalabteilung ist nicht anzuraten. Aber wo lauern jetzt genau die Gefahren?

Ein kleiner Exkurs in die Welt der Virenscanner
Durch einen Virenscanner wird verhindert, dass sich Schädlinge (Malware) - wie Computerviren, Computerwürmer oder Trojanische Pferde - auf einem PC einnisten können. Hierzu arbeiten die Hersteller vor allem mit 2 Verfahren, den Virensignaturen und Heuristiken (Suche nach Merkmalen eines Computervirus). Leider sind Virenscanner nicht 100% zuverlässig. So können Virensignaturen erst vom Hersteller zum Download angeboten werden, wenn diesem der neue Virustyp bekannt ist (Problem der Zero-Day-Attacke [2]).

Was macht Facebook und Co nun so gefährlich?
Ein Angriff ohne Social Media benutzt beispielsweise Massenemails. Bei dieser Angriffsform wird darauf vertraut, dass ein gewisser Prozentsatz unwissentlich auf einen Link klickt. Mit Social Media Netzwerken, wie Facebook, Xing oder Google+ können Angreifer mit einer viel kleineren Anzahl von Mails auskommen und somit (theoretisch) fast punktgenau Malware auf den PC eines Mitarbeiters einschleusen.

Wie könnte so ein Angriffsszenario aussehen?
So kann beispielsweise über Xing der Vor- und Nachname von Mitarbeitern einer bestimmten Firma (und vielfach sogar die Abteilung) ermittelt werden. Dann ist es ein leichtes sich die Emailadressen zusammenzusetzen. Ohne Xing müssten die Emailadressen durchprobiert werden. Die Vornamen würden einer Vornamenliste (die es im Internet gibt) entnommen, die Nachnahmen würden permutiert werden. So wäre beispielsweise meine Email-Adresse sehr schnell ermittelt, da mein Nachname nur aus 4 Buchstaben besteht. Bei dieser Vorgehensweise müssen jedoch sehr viele Mails – auch viele mit falschen Mailadressen – an den Mailserver der anzugreifenden Firma versendet werden, deshalb wird solch ein Angriff mit einer hohen Wahrscheinlichkeit auffallen. Bei der Social Media Variante erreichen alle Mails ohne Verdacht die Empfänger. Virenscanner, die im Mailserver installiert sind, können keine Muster erkennen, da es Emails sind, die individuell für einen kleinen Kreis von Adressaten erstellt wurden. Klickt dann ein Mitarbeiter auf einen Link innerhalb der Mail, so wird der Schädling (Malware) heruntergeladen. Diese wird vom Virenscanner wahrscheinlich nicht erkannt, da es sich um einen ganz neuen und individuell für diesen Angriff entwickelten Virus handelt.
Facebook ist aufgrund seiner sehr hohen Anzahl von Mitgliedern besonders interessant für Angreifer, vergleichbar mit Windows in Bezug auf Linux. Aus diesem Grund ist es wohl wahrscheinlicher, sich über Facebook Malware einzuschleppen, als über Xing. Ein weiteres Sicherheitsproblem ergibt sich bei Facebook und Co. dadurch, dass ich von meinen Kontakten (Freunde und Bekannten) Nachrichten erhalte - und nicht von einer unbekannten Phishing-Mail-Adresse -, die ich für vertrauenswürdig halte. Die Wahrscheinlichkeit, dass ich auf einen Link, der mir von einem Freund über Facebook geschickt wurde, klicke, ist somit weitaus größer. Durch Social Media erhalten Angreifer somit erstmalig die Möglichkeit sehr gezielte Angriffe durchzuführen.

Fazit
Durch Social Media wird eine neue Qualität von Angriffen stattfinden. Jedes Unternehmen muss für sich den Nutzen und die Gefahren von Social Media abwägen. Folgende Punkte sind meines Erachtens beim Einstieg in diese Thematik zu beachten:

Mitarbeiter müssen für das Thema Sicherheit im Kontext von Social Media sensibilisiert werden. Wichtig wäre es auch, eine IT-Security-Strategie in den Social Media Guide mit aufzunehmen. Hier könnte dann auch verankert werden, dass es beispielsweise wichtig ist, ein sicheres Passwort bei Facebook und Co. zu verwenden.
Brauchen alle Mitarbeiter Zugriff auf Social Media? Dies ist eine wichtige Frage. Meistens benötigt nur die Marketing oder Corporate Communications Abteilung einen direkten Zugang. Die restlichen Mitarbeiter könnten sich auch über Ihr Smart-Phone - während der Mittagspause - bei Facebook oder Xing einwählen. Den Zugriff der Marketingabteilung könnte man beispielsweise über eine Bitbox [3] absichern.
Des Weiteren wäre die Benennung eines zentralen Ansprechpartners wichtig. Zum einen können sich Mitarbeiter mit Fragen an diese Person wenden und zum anderen kann diese Person dann das Krisenmanagement koordinieren. Social Media wird zukünftig ein weiteres Aufgabengebiet für den Chief Security Officer darstellen.

Links
[1] http://www.itespresso.de/2011/09/12/studie-deutsche-unternehmen-blocken-social-media-am-haufigsten/
[2] http://de.wikipedia.org/wiki/Zero-Day-Exploit#Zero-Day-Exploit
[3] http://www.sirrix.de/content/pages/BitBox

Weitere Infos zu diesem Thema
http://www.heise.de/newsticker/meldung/Klick-Diebstahl-auf-Facebook-breitet-sich-aus-1207165.html
http://exensio.blogspot.com/2011/07/facebook-und-die-problematik-mit-der.html

Das Such-Interface in der exensio Enterprise 2.0 Plattform

noreply@blogger.com (Manuel Breitfeld) — Thu, 25 Aug 2011 13:32:00 +0000

Im Artikel Fuzzy Search und "Meinten Sie?" in Apache Solr habe ich bereits erwähnt, dass wir in unserer Enterprise 2.0 Plattform auf Apache Solr als Suchmaschine setzen. In diesem Artikel gehe ich auf das User Interface unserer Suche innerhalb unseres Portals ein.

Prinzipien eines User Interfaces einer Suche

In jeder besseren Suche kann man nicht nur nach Begriffen suchen - man kann auch im Anschluss die zurückgelieferte Ergebnismenge mithilfe nützlicher Filter weiter einschränken. Bekannte Filteroptionen sind unter anderem das Datum oder der Dateityp.

Hilfreich sind solche Filter insbesondere dadurch, dass man die gesamte Ergebnismenge schrittweise (per Klick) verfeinern kann, um letztendlich aus einem großen "Topf" an Daten die relevanten Informationen zu erhalten.

Einsatz innerhalb des Enterprise 2.0 Portals

In unserem Portal ist die Suche eine zentrale Komponente, die in verschiedenen Portlets zur Filterung der Inhalte verwendet wird. Im Folgenden gehe ich auf das User Interface der "eigenständigen" Suche ein.

Eingabe von Suchbegriffen: Eingegeben werden kann alles, was Apache Solr unterstützt. Eine Übersicht über die Syntax und die boolschen Operatoren findet sich unter [1].

Auto-complete: Dabei werden die Auto-complete Vorschläge zur Laufzeit anhand der aktuell im Index vorhandenen Daten über Apache Solr ermittelt.

Administrations-Tools: Nützliche Funktionen rundum die Indizierung können von berechtigten Benutzern direkt über die Suchseite aufgerufen werden.

Sortierung: Die Sortierung nach Relevanz ist Standard und erfolgt über den von Apache Solr ermittelten Score. Alternativ wird eine Sortierung nach Datum angeboten.

Filter (Navigatoren/Facets): Die Filter lassen sich in unterschiedliche Kategorien einteilen. Sie können benutzt werden, um Dokumente nach Datum, Typ, Autor, Kategorie o.ä. zu filtern. In Screenshot 2 ist dargestellt, wie sich solche Filter sukzessive anwenden lassen um von einer großen Ergebnismenge auf ein paar gezielt herausgesuchte Ergebnisse zu kommen.

Meta-Informationen: Jeder Treffer enthält nützliche Meta-Informationen wie das Datum der letzten Aktualisierung oder - im Fall von Dokumenten - die Dateigröße.

Teaser und Highlighting: Zu jedem Treffer wird ein Teaser angezeigt, bei dem die gesuchten Begriffe hervorgehoben werden.

Blätterung: Die Blätterung erlaubt das schnelle Durchsuchen der Ergebnismenge.

Tag-Cloud: Die Tag-Cloud kann über beliebige Informationen gebildet werden. In diesem Fall werden die am häufigsten Begriffe, die im Kontext des aktuellen Suchbegriffs auftauchen, angezeigt (groß = häufig, klein = weniger häufig). Gleiches lässt sich auch problemlos auf strukturierte Daten wie Tags anwenden.

Screenshots der Suche

Suche nach exensio GmbH

Suche nach exensio GmbH mit anschließender Filterung auf Blog-Beiträge mit Tag "exensio" im Zeitraum ab 1. August 2011

[1] http://lucene.apache.org/java/3_3_0/queryparsersyntax.html
[2] http://wiki.apache.org/solr/SolrRelevancyCookbook

ETL-Prozesse mit Pentaho Kettle umsetzen

noreply@blogger.com (Tobias Kraft) — Sat, 20 Aug 2011 14:14:00 +0000

Ein wichtiger Aspekt beim Aufbau eines Data Warehouses ist der Befüllungs-Prozess, der über den sogenannten ETL-Vorgang [1] erfolgt. Hierbei werden Daten von verschiedenen Quell-Systemen extrahiert, anschließend ggfs. transformiert und im abschließenden Schritt in das Data Warehouse geladen.
Zur Unterstützung des ETL-Vorgangs stehen zahlreiche Tools aus dem kommerziellen und Open-Source Umfeld zur Verfügung. Generell bringen Data Warehouse Lösungen selbst schon ein entsprechendes Tool bzw. Toolunterstützung mit.
Alternativ kann man natürlich den gesamten ETL-Prozess auch „von Hand“ umsetzen. Dies ist aufgrund der Komplexität mit einem entsprechenden Aufwand verbunden. Deshalb wird i.d.R. auf ETL-Tools zurückgegriffen, die vor allen Dingen die folgenden Anforderungen erfüllen:

Integration von verschiedenen Quell-Systemen
Skalierbarkeit
Erweiterbarkeit für die Integration von weiteren Systemen
Unterstützung für Daten-Transformationen (z.B. Aggregation, Filterung, …)
ausführliche Test-, Debug- und Logging-Möglichkeiten

Ein ausgereiftes ETL-Tool, das unter anderem diese Anforderungen erfüllt ist Kettle. Kettle ist ein Open-Source Produkt und stammt von der Firma Pentaho [2], die auch die gleichnamige DWH- bzw. BI-Lösung anbietet.

Kettle in der Entwicklung
Dreh- und Angelpunkt ist in Kettle das Designer-Tool Spoon. Mit dessen Unterstützung werden die sogenannten Jobs und Transformationen definiert. Die Transformationen sind für das eigentliche ETL-Handling zuständig. Jobs sind dagegen für die Einhaltung der Reihenfolge sowie die Verwaltung (z.B. auch Fehlerhandling) verantwortlich und können mehrere Transformationen enthalten.

Die vorherige Abbildung zeigt eine Transformation in der Designer-Sicht von Spoon. Im ersten Schritt werden aus einem Verzeichnis CSV-Dateien eingelesen. Beim Einlesen kann über einen Regex-Ausdruck definiert werden welche Dateien eingelesen werden. Aus den CSV-Dateien werden die benötigten Werte extrahiert und bei Bedarf auch formatiert. Da die Daten in ein relationales Datenbankschema geladen werden sollen müssen zunächst entsprechende Fremdschlüssel über Lookups ermittelt werden. Nach der Ermittlung des nächsten freien Primärschlüssels für die Zieltabelle kann abschließend die Einfüge-Operation vorgenommen werden.

Der Aufbau der Transformation sowie die Definition der einzelnen Schritte wurden allesamt mit Spoon vorgenommen. Das vorgestellte Beispiel zeigt nur eine kleine Auswahl an möglichen Schritten, die durchgeführt werden können. Spoon bietet ein sehr große Palette an vordefinierten Elementen, die für Transformationen eingesetzt werden können (z.B. Ausführung von Pragrammcode zur Konvertierung oder FTP-Transfer zum Abholen von Dateien).

Das Testen und Debuggen der Transformation wird direkt in Spoon durchgeführt und ermöglicht so eine schnelle Verifikation.

Fazit
Würde man die vorgestellte Transformation komplett in Eigenarbeit umsetzen wäre ein wesentlich höherer Zeitaufwand notwendig und auch Erweiterungen bzw. Änderungen würden höher zu Buche schlagen. Kettle eignet sich, aufgrund seiner zahlreichen Funktionen, neben der Nutzung als ETL Tool auch zur Durchführung von Migrations-Projekten oder als Import-Werkzeug für Daten in OLTP-Datenbanken.

Kettle ist ein ausgereiftes und verbreitetes Werkzeug, was sich in der Statistik mit ca. 15.000 Downloads pro Monat bei Sourceforge [3] widerspiegelt.

[1] http://en.wikipedia.org/wiki/Extract,_transform,_load
[2] http://www.pentaho.com/
[3] http://sourceforge.net/projects/pentaho/files/Data%20Integration/stats/timeline

Building a Portal with Grails-Framework

noreply@blogger.com (Peter Soth) — Fri, 19 Aug 2011 16:12:00 +0000

In this blog post I will describe how we have implemented a web portal by using only the Grails Framework [1]. Our approach differs from the Grails Portlets Plugin in the fact, that in our case the portlets are running directly in a Grails application and not as a JSR 168 portlet in a Liferay portal.

Why do we need a Grails Portal?
exensio has a long experience in the development of portal solutions. So far we have used portal solutions from the major manufacturers like Oracle. On the other hand, we use the Grails framework for developing Web applications more and more. Thus the idea to combine both was close. Our solution offers the possibility to embed a Grails controller as a portlet within a Grails application. Below I've included screenshots showing this feature.

The Building Blocks of the Grails Portal
A portal consists mainly of the following building blocks:

Portal
Page contains one or more portlets. A Portal can contain one or more pages.
Portlet-Instance of a Portlet. Each Portlet can reside on the same or another page.
Portlet Preferences. Each portlet can have specific preferences. For instance, a path to the root node of content.

The wireframe below depicts these building blocks:

The Link Issue of the Grails Portal
The generation of links must be implemented in a portal different than in a Grails application. The problem in a portal is that a click on a link must be redirected to the portlet on which the click has been executed.
There are different ways to solve this problem. The easiest way is to use Ajax or Flash to implement the portlets. This was not our preferred solution. Our solution should be based on standard GSP pages. We solved the link problem by implementing a portal controller which gets the requests first. A link in our Grails Portal looks the following:

http://server:port/enterprise20/default/MicroBlog?po_67_portlet_action=save#po_67

The link contains all the necessary information like portal (since the portal can contain one or more portals), page, portlet instance and the action which should be executed in the instance of that portlet. The portal controller loops over all the portlets which reside on the executed page, renders each portlet and returns the whole portal page back to the browser.

Some Screenshots showing the Functionality

Grails Portal displaying two portlets

Adding new values to portlet on right hand side.

Error is shown at portlet level.

Page is shown after entering correct value.

Conclusion
As you can see it is possible to implement a portal based on the Grails framework. This portal acts like a portal from the major vendors but is much easier and faster to implement.

Links
[1] Homepage Grails Framework

exensio bekommt Nachwuchs ...

noreply@blogger.com (Peter Soth) — Tue, 09 Aug 2011 07:33:00 +0000

natürlich nicht exensio, sondern unser Kollege Xuetao ist Vater geworden. Hierzu wollen wir auf diesem Weg noch einmal recht herzlich gratulieren. Aufgrund des Fachkräftemangels in Deutschland wollen wir sogleich den Nachwuchs unseres Kollegen an die Firma binden. Hierzu kamen wir auf die geniale Idee, einen Strampler mit dem exensio Firmenlogo zu verschenken :-)

Grails Entwicklung mit IntelliJ

noreply@blogger.com (Peter Soth) — Mon, 08 Aug 2011 09:30:00 +0000

Ein guter Editor reicht dem Puristen für die Entwicklung von Grails Applikationen aus. Werden die Projekte größer stellt sich jedoch die Frage, welche Entwicklungsumgebung (IDE) benutzt werden soll. Aktuell gibt es zwei IDEs, die in der Grails-Entwicklergemeinde benutzt werden:

SpringSource Tool Suite (STS) [1]
STS basiert auf Eclipse, dies hat den Vorteil, dass das reichhaltige Angebot von Eclipse-Plugins benutzt werden kann. Dies hat jedoch auch den Nachteil, dass ein schlecht implementiertes Plugin das ganze Eclipse runterreißen kann.
IntelliJ IDEA [2]
Basiert nicht auf Eclipse. Im Settings-Dialog kann die Eclipse-Keymap eingestellt werden, um die tief verinnerlichten Eclipse-Short-Cuts weiterbenutzen zu können. Als Nachteil könnte bei IntelliJ vielleicht aufgeführt werden, dass Spring Insight (Profiling Aufsatz für den Tomcat) nicht "out of the box" integriert ist. Zudem ist die Ulimate Edition (nur diese unterstützt die Entwicklung von Grails Applikationen) kostenpflichtig.

Wir haben bei exensio bisher STS benutzt, haben in letzter Zeit jedoch vermehrt gehört, dass die Entwicklung mit IntelliJ schneller vonstattengeht. Um es kurz zu machen, IntelliJ scheint unserer Meinung nach wirklich eine gelungene IDE zu sein. Vor allem viele Kleinigkeiten finden wir sehr beachtenswert. Eine Liste mit allen Groovy und Grails Funktionalitäten finden sich hier [3][4]. Folgende Punkte haben uns bei IntelliJ beeindruckt:

Stabilität:
Bei STS war oft das deployte WAR irgendwie inkonsistent und es erschienen irgendwelche komischen Fehlermeldungen. Durch ein “grails clean” war die Applikation wieder deploybar, aber dieser Prozess war auf Dauer zu nervig.
Einfacherer Setup:
Bei Eclipse gibt es so viele Settings, sodass leicht etwas übersehen wird. Bei IntelliJ ist alles, was ein Grails-Entwickler benötigt, vorab konfiguriert.
Debugging:
Das Debugging von Closures ist bei IntelliJ "out of the box" möglich. Bei STS muss dies erst konfiguriert werden [5]. War bei uns in der STS 2.7.1 Version vorab gesetzt, das Debugging von Closures haben wir jedoch nicht hinbekommen. Des Weiteren ist es sehr mühsam, (wenn überhaupt möglich) die Variablen zu inspizieren.
Übersichtlichkeit:
Wir finden IntelliJ übersichtlicher. So hat man immer die Gruppe (Domain-Klasse, Controller, Views und Test) im Blick:
Oder es ist einfach möglich, per Klick von einer Action in einem Controller in die GSP-Seite zu springen:
Des Weiteren ist kann ein ER-Diagramm einer Domain-Klasse in Beziehung zu den anderen angezeigt werden. Hier ein Beispiel eines Star Schemas, das wir mit Grails GORM modelliert haben. Diese Funktionalität ist sehr nützlich, wenn das Datenmodell anfängt zu wachsen.

Fazit

Wir wollen hier keine Empfehlung geben, welche Groovy/Grails IDE nun die bessere ist, da die Wahl einer IDE für einen Entwickler einer Glaubensfrage gleicht ;-) . Jedoch fällt auf, dass IntelliJ sehr viele Kleinigkeiten anbietet, die in Summe die Grails-Entwicklung wirklich vereinfacht und beschleunigt. Es fällt auch auf, dass bei IntelliJ die Entwickler ermuntert werden, Verbesserungsvorschläge und Wünsche einzubringen, dies merkt man unweigerlich bei der täglichen Arbeit. Wer sich selber überzeugen möchte, kann sich eine Testlizenz herunterladen, die 30 Tage gültig ist.

Links
[1] http://www.springsource.com/developer/sts
[2] http://www.jetbrains.com/idea
[3] http://www.jetbrains.com/idea/features/groovy_grails.html
[4] http://blogs.jetbrains.com/idea/tag/grails/
[5] http://blog.springsource.com/2010/11/30/new-groovy-debug-support-in-sts-2-5-1/

Weitere nützliche Links zum Thema IntelliJ und Grails
[1] http://wiki.jetbrains.net/intellij/Creating_a_simple_Grails_application_with_IntelliJ_IDEA
[2] http://wiki.jetbrains.net/intellij/Managing_Grails_plugins
[3] http://www.grails.org/IDEA+Integration
[4] http://www.grails.org

Fuzzy Search und "Meinten Sie?" in Apache Solr

noreply@blogger.com (Manuel Breitfeld) — Fri, 29 Jul 2011 08:31:00 +0000

In unserer Enterprise 2.0 Plattform setzen wir die Volltextsuchmaschine Apache Solr, die auf Basis der Such-Bibliothek Lucene arbeitet, mit Begeisterung ein. Dieser Beitrag soll beschreiben, wie dem Benutzer mit einfachen Mitteln bei Tippfehlern geholfen werden kann.

Spellchecker Komponente
Mit der SpellCheckComponent [1] teilt Solr Vorschläge zu den vom Benutzer abgesandten Suchtermen mit. Als Grundlage dieser Vorschläge kann ein Feld aus dem Such-Index herangezogen werden.

Die Konfiguration der Komponente ist bereits in der standardmäßigen schema.xml enthalten. So gilt es nur noch das Vorschläge-Verzeichnis aufzubauen. Solr erledigt dies automatisch, wenn der Parameter spellcheck.build=true an die Anfrage angehängt wird. Ein Beispiel wäre:

http://localhost:8983/solr/spell?q=test%20cotent&spellcheck=true&spellcheck.collate=true&spellcheck.build=true

Das muss selbstverständlich nicht bei jeder Abfrage gemacht werden.

Die eigentliche Suchabfrage sieht genau gleich - nur ohne den Parameter - aus. Bemerkenswert ist der Parameter spellcheck.collate=true, der nicht nur das falsch geschriebene Wort, sondern auch gleich die komplett korrigierte Suchabfrage zurück liefert. So liefert die SpellCheck-Abfrage nach "test cotent" als Vorschlag "test content" zurück.

Fuzzy Search
Ein weiteres Mittel, das Apache Solr (genauer gesagt: Apache Lucene) bietet, ist die "Fuzzy Search". "Fuzzy Search" steht für Suche mit einer gewissen Unschärfe.
Durch Anhängen einer Tilde an den eigentlichen Suchterm wird angegeben, dass der Suchterm mit Unschärfe betrachtet werden soll. Dies korrigiert zum Beispiel automatisch Tippfehler, liefert aber auch ähnliche Suchtreffer, die möglicherweise passen könnten, als Ergebnis zurück.
Während bei uns die Suche nach "exnsio" keinerlei Treffer hat, findet die Fuzzy Search nach "exnsio~" alle Dokumente, in denen "exensio" auftaucht.

Verwendung in unserer Enterprise 2.0 Plattform
Sowohl die SpellCheck-Komponente als auch die "Fuzzy Search" bieten eine einfache Möglichkeit, um den Benutzer bei der Suche zu unterstützen und eventuelle Tippfehler (sogar automatisch) zu korrigieren.
In unserer Enterprise 2.0 Plattform verwenden wir beide Möglichkeiten: Wir bieten dem Benutzer Vorschläge wie "Meinten Sie? ..." à la Google und führen gleichzeitig bei wenig Treffern eine Fuzzy Search zum eingegeben Suchterm aus, um dem Benutzer sofort passende Ergebnisse anzeigen zu können.

[1] Ausführliche Beschreibung zur SpellCheck-Komponente: http://wiki.apache.org/solr/SpellCheckComponent