exensio it blog

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-Fragmentzeigt 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

Grails Quick-Start

noreply@blogger.com (Peter Soth) — Fri, 08 Jul 2011 09:51:00 +0000

Ich bekomme des öfteren die Frage gestellt, wie man sich am besten in das Thema Grails einarbeitet. Aus diesem Grund möchte ich hier kurz zwei Empfehlungen geben, die sich sehr gut für einen Einstieg in das Grails-Framework [1] eignen.

"Getting started with Grails" - der Klassiker von Jason Rudolph liegt in der zweiten Version vor. Dieses Buch gibt es als PDF (Login bei InfoQ ist nötig) und kann von folgendem Link heruntergeladen werden.

Folgende YouTube Videos können ebenfalls empfohlen werden:

Getting Started with Grails - Teil 1

Getting Started with Grails - Teil 2

Getting Started with Grails - Teil 3

[1] Homepage Grails Framework

Links

Facebook und die Problematik mit der Sicherheit für Unternehmen

noreply@blogger.com (Peter Soth) — Tue, 05 Jul 2011 07:17:00 +0000

Im Oktober letzten Jahres meldete die Wirtschaftswoche, dass Porsche den Zugang zu Facebook gesperrt hat. Als Grund wurde Angst vor Wirtschaftsspionage angegeben. Auf Veranstaltungen zum Thema Social Media wird dieses Vorgehen immer als Negativbeispiel angeführt. Und meistens höre ich Sätze, wie „Porsche hat Social Media nicht verstanden“ oder „Dann greifen halt die Mitarbeiter mit Ihrem Smartphone auf Facebook zu“. Mit diesem Blog möchte ich die Informationen zusammenfassen, die ich bei meiner Internetrecherche zu diesem Thema gefunden habe.

Was macht Soziale Netzwerke in Bezug auf Cyberattacken so gefährlich?
Symantec [2] warnt im Internet Security Thread Report aus dem Jahre 2010 vor Problemen, die für Unternehmen dadurch entstehen, dass Mitarbeiter gerne ihren Arbeitgeber oder ihre Rolle innerhalb des Unternehmens in sozialen Netzwerken preisgeben. Neben Symantec warnt auch das BSI [3] (Bundesamt für Sicherheit in der Informationstechnik) davor Angaben über den Arbeitgeber in sozialen Netzwerken zu veröffentlichen. Aber warum ist dies so gefährlich? In diesem Artikel der VDI Nachrichten [4] ist dies - meiner Meinung nach - sehr schön dargestellt.

Was macht Facebook besonders riskant?
Zunächst einmal ist es die Größe von Facebook. Wie bei Windows ist es auch hier viel wahrscheinlicher, einem Angriff ausgesetzt zu sein. So sehen die Security-Experten von Sophos [5] vor allem folgende Verbesserungsmöglichkeiten bei Facebook:

Kein Informations-Sharing ohne Zustimmung.
Prüfung von App-Entwicklern. Durch die vielen Apps [6] unterscheidet sich Facebook von den anderen sozialen Netzwerken. Aber leider sind sie auch ein Sicherheitsrisiko.
Verschlüsselung als Regelfall. Die vor kurzen eingeführte HTTPS Option sollte der Regelfall sein.

Fazit
Ich möchte hier nicht gegen soziale Netzwerke wettern. Ich selbst benutze sehr gerne Xing. Aber auf der anderen Seite sollte man auch nicht die Gefahren unterschätzen. So kann ich Porsche durchaus verstehen, wenn dort Facebook gesperrt wurde. Benutzt ein Mitarbeiter sein Smart-Phone für den Zugriff auf Facebook können zumindest keine Schadprogramme in das Firmennetzwerk gelangen. Für Firmen, die nicht so restriktiv sein möchten, gäbe es noch die Möglichkeit die BitBox [7] zu benutzen. In diesem Fall läuft der FireFox-Browser in einer virtuellen Maschine, die auf einem abgespeckten Linux-Kernel basiert. Die BitBox wurde von der Sirrix AG in Zusammenarbeit mit dem BSI (Bundesamt für Sicherheit in der Informationstechnik) entwickelt, um ein sicheres Surfen zu ermöglichen.

[1] http://www.wiwo.de/unternehmen-maerkte/porsche-sperrt-facebook-443688/
[2] http://www.zdnet.de/news/41551384/symantec-soziale-netzwerke-heizen-cyberattacken-an.htm
[3] https://www.bsi-fuer-buerger.de/BSIFB/DE/SicherheitImNetz/KommunikationUeberInternet/SozialeNetzwerke/Schutzmassnahmen/schutzmassnahmen_node.html
[4] http://www.vdi-nachrichten.com/artikel/Unfreiwillige-Spione-im-eigenen-Haus/52543/4
[5] http://business.chip.de/news/Facebook-Security-Experten-fordern-mehr-Schutz_48514422.html
[6] http://www.zdnet.de/news/41541354/neuer-facebook-wurm-verbreitet-sich-ueber-schaedliche-apps.htm
[7] http://www.sirrix.de/content/pages/BitBox

Unsere Enterprise 2.0 Plattform - basierend auf dem Grails-Framework

noreply@blogger.com (Peter Soth) — Mon, 30 May 2011 07:49:00 +0000

Mit diesem Blogeintrag will ich über die Entwicklung unserer Enterprise 2.0 Plattform berichten. Es werden weitere Beiträge, die Teilaspekte der Plattform beleuchten, folgen. Die Entwicklung unserer Enterprise 2.0 Plattform basiert auf dem Framework Grails [1], das wir seit dessen Veröffentlichung sehr erfolgreich in diversen Web-Projekten einsetzen.

Warum eine weitere Enterprise 2.0 Plattform?
Schaut man sich den Markt für Enterprise 2.0 Lösungen an, so kann der Markt folgendermaßen klassifiziert werden:

Spezialisierte Anbieter – hierzu zählen beispielsweise ThoughtFarmer, SocialText, Confluence oder XWiki (Open-Source). Diese Lösungen waren meistens ursprünglich Wikis und wurden im Laufe der Zeit um weitere Funktionalitäten erweitern. Ein guter Überblick findet sich hier [2].
Content Management Systeme – wurden in den letzten Jahren um Enterprise 2.0 Funktionalitäten erweitert. Zu den kommerziellen Anbietern zählen beispielsweise OpenText oder Day CQ. Im Open-Source-Bereich finden sich hier beispielsweise TYPO3 oder Drupal.
Portal Anbieter – hierzu zählen alle großen, wie IBM (WebSphere / Lotus Connections / Lotus Quickr), Microsoft (Sharepoint) oder Oracle (WebCenter) aber auch Liferay aus dem Bereich Open-Source.

Unsere Enterprise 2.0 Plattform wird sich von der Idee auch im Portal-Segment wiederfinden. Im Vergleich zu den „großen“ Systemen soll unsere Lösung vor allem durch einen modularen Aufbau bestechen. Des Weiteren wird eine einfache Anpass- und Erweiterbarkeit durch das Grails-Framework erreicht. Es müssen nur die Teile benutzt werden, die vom Kunden in unterschiedlichen Projekten gefordert werden. So kann dies bei einem Wiki beginnen und bei einer komplexen Portal-Lösung enden.

Ein Portal hat hier (meine persönliche Meinung) den großen Vorteil, dass es einen ganzheitlichen Ansatz verfolgt. Das Portal ist hier mit einem Cockpit vergleichbar. Der Benutzer muss nicht zwischen verschiedenen Applikationen (bestehendes Portal und neu eingeführte Enterprise 2.0 Lösung) umschalten.

Als Beispiel möchte ich ein Außendienst-Portal heranziehen. Mit diesem erhalten die Außendienst-Mitarbeiter aktuelle Informationen in Form von Dokumenten oder die aktuellen Verkaufszahlen aus SAP. Dieses kann mit einem Microblog angereichert werden. Mit diesem können die Außendienst-Mitarbeiter - in Echtzeit - Informationen (beispielsweise über das Verhalten des Wettbewerbers) austauschen. Der Innendienst kann sich auch auf diesen Informationskanal („Flurfunk“) aufschalten und erhält tagesaktuelle Informationen über das Marktgeschehen.

Funktionalitäten unserer Enterprise 2.0 Plattform

In diesem Abschnitt möchte ich die Funktionalitäten beschreiben, die aktuell geplant sind. Weitere Funktionalitäten, wie Activity Stream oder Unterstützung von mobilen Endgeräten werden in Zukunft noch aufgenommen werden.

Content Management – hier haben wir uns entschieden, ein kleines CMS System selbst zu entwickeln. Weceem, ein CMS basierend auf dem Grails-Framework, war nicht mit unserem Portal-Gedanken zu verbinden. Wir sehen hier vor allem die Anforderung, dass Content in Form von Portlets dargestellt wird. Hier werden auch Informationen, wie Bilder oder Filme gespeichert.
Wiki – dieses Modul wird es einem Team ermöglichen Informationen zu dokumentieren. Im Unterschied zum CMS gibt es hier beispielsweise keinen Workflow.
(Micro)Blog – dieses Modul ermöglicht das Erstellen von Blogs. Mit Microblogs können Kollegen in Echtzeit Kurzinformationen austauschen (Twitter unternehmensintern).
Dokumenten Management – hier sind wir noch auf der Suche nach einem geeigneten Open-Source-System, das sich einfach integrieren lässt.
Tag-Management – ist die zentrale Komponente. Alle Informationen sollen mit Tags versehen werden können. Mit diesen Tags ist es dann auch möglich, eine Faceted-Search zur Navigation aufzubauen. Die integrierte Suche kann mit Hilfe der Tags bessere Ergebnisse liefern.
Kommentieren und Bewerten – dies ist auch eine zentrale Komponente. Es soll möglich sein, Content, Dokumente, Wiki- und Blog-Einträge kommentieren und bewerten zu können.
Suche – hier benutzen wir Apache Lucene bzw. Apache Solr.
Portlets – alle Module können in Form von Portlets integriert werden. Des Weiteren können Portlets auch Informationen aus Back-End-Systemen - wie SAP - darstellen.
Kollektive Intelligenz – dieses Modul soll Empfehlungen geben. Zum Beispiel, könnte ein Benutzer Informationen erhalten, dass sein Kollege Dokumente gelesen hat, die mit denselben Tags verknüpft sind, die auch für sie oder ihn von Interesse sein könnten.

Aktueller Stand

Die Implementierung der CMS-Funktionalitäten, des Blogs und die Applikations-Integration mittels Portlets ist abgeschlossen. Gegenwärtig arbeiten wir am Wiki, dem Tag Modul und der Suche. Die Abbildung rechts oben liefert einen ersten Eindruck über den aktuellen Stand der Implementierung.

Aufruf zur Mitarbeit

Wir suchen Mitstreiter, die an diesem Projekt mitarbeiten wollen. Voraussetzung wären Kenntnisse des Grails-Frameworks und eine Affinität für das Thema Enterprise 2.0.

Links

[1] Homepage Grails Framework
[2] Wikimatrix

Enterprise 2.0 – Rating und die wichtige Involvierung des Betriebsrates

noreply@blogger.com (Peter Soth) — Mon, 18 Apr 2011 12:42:00 +0000

Das bewerten und kommentieren von Content ist ein wesentlicher Baustein im Enterprise 2.0. In einem Enterprise 2.0 Projekt wollten wir ein 1-5 Star Rating einführen. Dies wurde jedoch durch den Betriebsrat untersagt, da vermieden werden sollte, dass Mitarbeiter eine schlechte Bewertung für den von Ihnen eingestellten Content erhalten können. Es wurde vielmehr ein 1-3 Star Rating (von „Good“ bis „Excellent“ - siehe links im Bild unten) entwickelt und vom Betriebsrat abgesegnet. Wir haben mit diesem Rating Verfahren sehr positive Erfahrungen gemacht.

Rating 1-3 Stars versus 1-5 Stars (Amazon)

In meiner Social Media Arbeitsgruppe haben wir letzten Freitag hierüber gesprochen. Als Nachteil eines nur positiven Ratings wurde aufgeführt, dass es nicht möglich ist, zu unterscheiden welcher Content wirklich gut und welcher schlecht ist. Der Arbeitskollege erwähnte jedoch auch, dass in seiner Firma ein Rating wieder abgeschafft wurde, da sich ein Spezialist darüber echauffiert hatte, dass sein Content nur mit 2 Sternen bewertet wurde.

Ich habe hierzu im Internet recherchiert und bin auf folgenden interessanten YouTube-Blog-Eintrag [1] gestoßen. In diesem wird die Auswertung von allen auf YouTube getätigten Bewertungen beschrieben und in der Grafik unten visualisiert. Das interessante hierbei ist, dass es eigentlich nur 1-Star und 5-Star-Ratings gibt. In diesem Blog gibt es noch jede Menge interessante Kommentare, wie ein Rating verbessert werden kann. Das Ergebnis der Auswertung hat dazu geführt, dass es bei YouTube nur noch eine binäre Bewertung („Mag ich“ bzw. „Mag ich nicht“ analog zu Facebook mit „Gefällt mir“) gibt.

Ergebnis der Analyse aller Ratings bei YouTube (1-5 Stars)

Fazit
Wie eingangs beschrieben ist das bewerten und kommentieren von Content sehr wichtig im Enterprise 2.0 Kontext. Der Betriebsrat sollte von Projektbeginn an involviert werden, da dieser hier ein gewichtiges Wort mitzusprechen hat. Wir haben sehr gute Erfahrungen mit dem 1-3 Star-Rating gemacht und dieses ist auf jeden Fall keinem Rating vorzuziehen. Den von YouTube gewählten Ansatz finde ich auch sehr interessant und besser als ein 1-3 Star-Rating. Mich würde interessieren, ob diese Art der Bewertung auch von einem Betriebsrat abgelehnt würde. Meiner Meinung nach eher nicht, da es keine harte „Notenskala“ gibt, sondern eine weichere Bewertung. Des Weiteren sollte die Bewertung auch kommentiert werden, um Rückschlüsse auf die Bewertung zu ermöglichen.

Links
[1] YouTube Blog - Five Stars Dominate Ratings

Enterprise 2.0 und das Problem mit der Partizipation

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

Eine Enterprise 2.0 Lösung ist meist schnell innerhalb eines Unternehmens eingeführt. Jedoch fehlt es meistens an einer Strategie, die Nachhaltigkeit von Enterprise 2.0 innerhalb eines Unternehmens zu verankern. Die Nachhaltigkeit kann sich jedoch nur einstellen, wenn die Enterprise 2.0 Community durch interessante Beiträge lebt.
Jakob Nielsen (Nielsen Norman Group) hat in seinem Blog-Beitrag (90-9-1 Rule for Social Design) im Jahre 2006 auf das ungleichmäßige Verhältnis von Content-Lesern und Content-Editoren im Internet hingewiesen. Seine in diesem Blog erwähnte 90-9-1-Regel besagt folgendes:

90% - lesen und suchen, liefern jedoch keinen Content
9% - steuern gelegentlich Content bei
1% - steuern regelmäßig Content bei

Quelle: Jakob Nielsen

Jakob Nielsen weist in seinem Blog-Beitrag (Social Networking on Intranets) aus dem Jahre 2009 darauf hin, dass es auch im Intranet ein Ungleichgewicht zwischen Mitarbeitern gibt, die viel beisteuern und solchen, die nur lesen. Es kommt seiner Meinung nach darauf an, dass das Verhältnis von Editoren und Lesern innerhalb der Community stimmt. Auch sind die reinen Leser nicht unterzubewerten, da auch sie von der Community profitieren. Das Verhältnis von Lesern und Editoren kann von Unternehmen zu Unternehmen variieren. Andrew McAfee beschreibt in seinem Blog-Beitrag (Enterprise 2.0 the Indian Way – 7. April 2011) einen Besuch beim indischen IT Dienstleister Tata Consultancy Services. Hier war der Anteil der Editoren sehr viel höher, bedingt durch einen sehr hohen Anteil von jungen Mitarbeitern (Digital Natives), die schon mit Social Media aufgewachsen sind.

Wie kann die Partizipation erhöht werden?

Jakob Nielsen hat in seinem Blog folgende Punkte hierzu aufgeführt:

Die Veröffentlichung von Content muss sehr einfach sein, damit nicht nur technisch Versierte mitmachen können.
Partizipation als Nebeneffekt. Vergleichbar mit Amazon‘s Empfehlungen oder Most Viewed Topics (Tag Cloud).
Teilnehmer sollen belohnt werden. Dies kann monetär (Incentives) oder auch mittels Anerkennung („Gold Stars“ auf Profil) realisiert werden. Andrew McAfee beschreibt in seinem Blog-Beitrag, dass bei TCS die Editoren vor allem durch Ihre Reputation innerhalb der Community motiviert wurden Inhalte beizusteuern. In Deutschland ist es ratsam sehr früh den Betriebsrat einzubinden.
Editoren mit qualitativ hochwertigen Informationen müssen promotet werden, damit Ihre Beiträge nicht in der Masse der 1% Überaktiven untergehen.

Folgende Vorschläge wurden innerhalb eines OpenSpace Workshops (moderiert durch Dr. Willms Buhse) auf der Social CRM Veranstaltung der Computerwoche in Karlsruhe erarbeitet:

Geduld - ein Klima (Unternehmenskultur), in dem die Mitarbeiter im doppelten Sinne Zeit bekommen
- in dem die Umstellung nicht bis gestern erwartet wird
- in dem der Zeitaufwand für die Einarbeitung in die neuen Strukturen und Werkzeuge berücksichtigt und/oder honoriert wird
Benutzerfreundlichkeit
Konkrete Ziele vereinbaren und dabei das mittlere Management einbeziehen
Menschen, die den Umgang mit den neuen Technologien und ihren Möglichkeiten begleiten (Moderatoren)

Fazit

Partizipation ist ein wichtiger Aspekt bei der Einführung von Enterprise 2.0 innerhalb eines Unternehmens. Meines Erachtens ist die kontinuierliche Moderation nach dem Go-Live sehr wichtig, damit die Begeisterung nach einer anfänglichen Euphorie nicht verloren geht. Ich höre des Öfteren auch noch eine weitere Möglichkeit, um die Partizipation zu steigern. Hierbei wird erwähnt, die Teilnahme innerhalb der Enterprise 2.0 Community in die Ziele des Mitarbeiters aufzunehmen. Dies würde ich jedoch nur als letzte Maßnahme in Betracht ziehen (falls obige Punkte nicht greifen), da eine freiwillige Teilnahme besser ist, als eine erzwungene.

Ist der ROI von Enterprise 2.0 berechenbar?

noreply@blogger.com (Peter Soth) — Mon, 07 Mar 2011 09:36:00 +0000

Die Berechnung eines ROI für Enterprise 2.0 gilt gemeinhin als nicht trivial. Auf dem Blog des Harvard Professors Andrew McAfee [1] (Schöpfer des Begriffs Enterprise 2.0) bin ich auf einen interessanten Eintrag gestoßen. Dieser basiert auf einem Report [2] [3] der Unternehmensberatung Deloitte mit dem Titel “Social Software for Business Performance”. Hierin werden bei zwei Firmen messbare Verbesserungen durch den Einsatz von Wikis – im Kontext von Enterprise 2.0 – aufgezeigt.

Die Abbildung unten zeigt, wie durch den Aufbau eines Wikis bei der der Firma Alcoa (Hersteller von Befestigungssystemen) die monatlichen Compliance Stunden reduziert werden konnten.

Quelle: Deloitte

Die Abbildung unten zeigt wie ein Wiki bei der Firma OSIsoft die Problemlösung im Customer Support um 22% verbesserte.

Quelle: Deloitte

Fazit

Der kritische Leser wird nun anmerken, dass es in diesem Fall einfach ist, einen Mehrwert auszurechnen. Ich gehe hier d’accord – nicht für jeden Fall kann so einfach ein ROI für den Einsatz von Enterprise 2.0 berechnet werden. Jedoch fand ich es sehr interessant einmal harte Zahlen zu sehen und vielleicht gibt der Report von Deloitte dem einen oder anderen eine Idee, wie sich in seinem speziellen Fall ein ROI berechnen lässt.

[1] Blog von Andrew McAfee
[2] Social Software Seite von Deloitte
[3] Report über Social Software (Deloitte)