Herzlich willkommen auf dem Blog der exensio GmbH

exensio ist ein unabhängiges Software-Unternehmen von erfahrenen IT Beratern und Architekten. Zu unseren Kunden zählen namhafte deutsche Großunternehmen.

exensio verbessert das Kommunikations- und Informationsmanagement von Unternehmen. Auf Basis sinnvoller und zweckmäßiger Technologien erarbeiten wir flexible und übergreifende Lösungen für webbasierte Informationssysteme. Abhängig von den Kundenanforderungen realisieren wir Web Applikationen sowie Lösungen auf Basis von Web Content Management- und Portalsystemen. Integrativ, wirtschaftlich und anwenderfreundlich!

Hier gelangen Sie zur exensio GmbH.

Donnerstag, 25. August 2011

Das Such-Interface in der exensio Enterprise 2.0 Plattform

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.

  1. 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].

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

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

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

  5. 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.

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

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

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

  9. 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

Samstag, 20. August 2011

ETL-Prozesse mit Pentaho Kettle umsetzen

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


Freitag, 19. August 2011

Building a Portal with Grails-Framework

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

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

Montag, 8. August 2011

Grails Entwicklung mit IntelliJ

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