JAX 2013 Enterprise Java Batch mit Spring

Der Name ist dabei Programm. Software Craftsmanship ist unsere Leidenschaft bei codecentric und im Softwerker schreiben unsere Experten über Themen rund um Agile Softwareentwicklung, Continuous Delivery und moderne Technologien.

In dieser Ausgabe haben wir folgende Artikel für Euch aufbereitet:

• Software Craftsmanship ohne Craftsmanship? (Uwe Friedrichsen)
• Die DevOps-Bewegung (Patrick Peschlow)
• Der Big Data Developer (Pavlo Baron)
• Spring komplett ohne XML – geht das? (Tobias Flohre)
• Das Problem mit der Architekturqualität (Uwe Friedrichsen)
• Erfolgreiche Festpreisprojekte durch flexiblen Inhalt (Mirko Novakovic)
• Continuous Delivery in der Praxis (Marcel Birkner)

Momentan gibt es die Ausgabe kostenlos nur in gedruckter Form, weil wir ein hochwertiges Magazin Format für den “Softwerker” gewählt haben. Registriert Euch einfach kostenlos auf http://www.codecentric.de/softwerker/ und wir schicken Euch jede Ausgabe zu.

Bin gespannt auf Euer Feedback und Vorschläge für die nächsten Ausgaben.

Anlass für meine Überlegungen war ein Meeting, das im Kontext von mehreren zusammenarbeitenden Teams (Scrum of Scrum) stattfand. Ziel des Meetings war es, die Ergebnisse der einzelnen Teamretrospektiven abzugleichen und teamübergreifende Maßnahmen abzustimmen. Die Teams hatten in ihren Retrospektiven die anzusprechenden Maßnahmen identifiziert und ein Mitglied in das Abstimmungsmeeting delegiert. Die Delegierten haben sich in einer Ecke des offenen Arbeitsbereichs getroffen, und dort auf mehreren beweglichen Sofas  Platz genommen.

Als unbeteiligter Beobachter (Chicken) habe ich dieses Abstimmungsmeeting als träge und ineffizient empfunden. Die Teilnehmer haben dem Sprechenden nur mit halbem Ohr zugehört, die Sprechenden schweiften ab und der Moderator konnte die geplante Struktur des Meetings nicht halten. Als Ergebnis wurde die Timebox überschritten, ohne das am Ende das geplante Ziel erreicht wurde. Ich glaube, dass die gewählte Form und der Ort des Meetings erheblich dazu beigetragen haben.

Besprechnungsraum, Offene Teamfläche oder gar Arbeitsplatz

Die meist genutzten Orte für Meetings sind Besprechungsräume. Dabei handelt es sich um dediziert vorgesehene, abgeschlossene Räume, meist mit für Besprechungen hilfreicher Ausstattung wie feste Beamer, Whiteboards oder Flipcharts.

Den größten Vorteil dieser Räume stellt die gute Abschirmung gegen Störungen von außen dar. Die Teilnehmer können ihre Aufmerksamkeit vollständig auf das Thema und das Meeting richten. Für Außenstehende findet so ein Meeting im stillen Kämmerlein statt. Weitere Nachteile sind eher „logistischer“ Natur. Solche Räume sind meist nicht in ausreichendem Maße vorhanden und müssen im Voraus reserviert werden. Spontane Meetings sind oft nicht möglich. Auch liegt ein verfügbarer Raum nicht immer in der Nähe der normalen Arbeitsplätze der Teilnehmer, so dass eine längere „Anreise“-Zeit benötigt wird.

Alternativen zu dedizierten Besprechungsräumen stellen ruhigere Bereiche auf offenen Flächen dar. Dabei kann es sich z. B. um einen extra dafür vorgesehenen Bereich einer Teamarbeitsfläche, die größere Kaffeeküche oder eine Ecke in der Kantine (außerhalb der Mittagzeit) handeln. Die logistische Ausstattung variiert, je nach Ort, meist sehr stark.

Ein solcher Ort erhöht die Transparenz für Außenstehende, da jeder, der vorbei kommt, zumindest sieht, dass ein Meeting stattfindet und wer daran teilnimmt. Auch eine spontane Teilnahme ist durch Dazugesellen, Zuhören und sogar Mitreden möglich. Vorzeitiges Verlassen und späteres Hinzustoßen kann ohne größere Störung erfolgen. Dies ist aber auch einer der gravierenden Nachteile. Teilnehmer werden sehr einfach von außen gestört und abgelenkt und verlieren so den Fokus auf das Meeting.

Ein sehr spezieller Ort ist der Arbeitsplatz eines oder mehrerer Teilnehmer. Logistisch hat es für die Teilnehmer durch den kurzen Weg einen Vorteil. Für die Teilnehmer ist es aber viel schwerer, sich auf das Meeting zu fokussieren, da der eigene Arbeitsplatz eine Quelle vieler Ablenkungen darstellt (Telefon, Emails, Instant-Messenger).

Meetingformate

Das Format des Meetings ist im Vergleich zum Ort mit viel weniger Restriktionen wählbar.

Die oben beschrieben Situation, bei der die Teilnehmer im Kreis auf Sofas sitzen, halte ich für ein extremeres Beispiel. Das Format erzeugt eine entspannte und lockere Atmosphäre. Was aber auch schnell zu einer trägen Beteiligung am Meeting führt. So muss ein Teilnehmer, der aktiv das Flipchart nutzen möchte, aus den tiefen Sofas aufstehen. Da ein Moderator meist steht, wird auf der “Ebene” der Sitzenden leicht eine Nebendiskussion begonnen. Aufgrund des bequemen Sitzens dauern die Diskussionen länger.

Das absolute Gegenteil stellen dazu Stand-Up Meetings dar, in die Teilnehmer das Meeting im Kreis stehend durchführen. Dieses Format fördert meist Aufmerksamkeit für den aktuell Sprechenden und das Meeting insgesamt, da sich die Teilnehmer auf natürlich Weise dem Sprechenden zuwenden. Die Moderation erfolgt auf gleicher Augenhöhe und Diskussionen werden selten in die Länge gezogen. Auch eine aktive Beteiligung, zum Beispiel an einem Whiteboard, erfolgt mit einer sehr niedrigen Hemmschwelle durch einen einfachen Schritt in Richtung des Boards.

Fazit

Ort und Format des Meetings haben Einfluss auf Ablauf und Wirkung eines Meetings. Dessen sollte ich mir als Organisator/Moderator bewusst sein und es mir, falls möglich, für die jeweilige Situation zu nutze machen oder, falls nicht die optimale Wahl verfügbar ist, die negativen Einflüsse durch anderen Mittel kompensieren.

Eine kurze Bemerkung zu Beginn: Dieser Blog-Artikel ist kein umfassender Überblick über JMeter, seine Möglichkeiten und Beschränkungen, sondern stattdessen ein sehr persönlicher Blick auf dieses Werkzeug. Man könnte auch sagen: eine längst überfällige Abrechnung.

Nach einigen Jahren, in denen ich im Wesentlichen in den Bereichen Performance-Optimierung und –Monitoring beschäftigt war, arbeitete ich im letzten Projekt wieder mit JMeter. Während ich früher hauptsächlich den HTTP-Sampler von JMeter benutzt habe, war diesmal der JUnit-Sampler das wichtigste Interface zur Last-Erzeugung.

Mit JMeter Lasttests zu schreiben und durchzuführen ist eigentlich ganz einfach. Im bereits erwähnten Projekt sollten die reichlich vorhandenen funktionalen JUnit-Tests zur Lasterzeugung genutzt werden. Dazu müssen diese Tests lediglich JMeter in Form einer jar-Datei zur Verfügung gestellt werden. Im JUnit-Sampler von JMeter werden anschließend die gewünschte Test-Klasse und die darin enthaltene, auszuführende Test-Methode ausgewählt. Als Klammer um einen oder mehrere JUnit-Sampler fungiert bei JMeter eine sog. Thread-Gruppe, in der die Last (die Anzahl der parallelen Threads) eingestellt wird und die Dauer des Tests. Im Großen und Ganzen war’s das, der Lasttest (oder „Testplan“ im JMeter-Jargon) ist definiert. Man muss nur noch auf den Start-Knopf drücken und der Test wird ausgeführt. Wer weitere Details wünscht, findet diese im in leicht verständlicher Form. Man würde sich etwas mehr explizite Beispiele wünschen, insb. zum Thema Regex, aber insgesamt gesehen handelt es sich um eine exzellente Doku.

Irgendwie ist es mir gelungen, das Gefühl zu verdrängen, das sich bei der Arbeit mit JMeter typischerweise einstellt. Allerdings hat JMeter dieses Gefühl sehr, sehr schnell wieder zurückgebracht. Ich hatte vergessen, dass JMeter – wie jeder von seiner Tagesform abhängige andere Mensch auch – sich richtig launisch aufführen kann, manchmal sogar zickig.

Beispiele gefällig?

• Die Fehlermeldungen des JUnit-Samplers sind recht aussagekräftig – normalerweise. Aber man hüte sich vor auch nur den geringsten Abweichungen zu dem, was JMeter von den Konstruktoren der JUnit-Test-Klasse erwartet. Man kriegt ein knappes „failed to create an instance of the class” an den Kopf geworfen und wird ansonsten von JMeter in seinem Elend alleine gelassen. Auch Google hilft einem in diesem Fall nicht weiter. Vielleicht helfen ja unsere Erfahrungen: JMeter scheint sowohl den Standard-Konstruktor als auch den Konstruktor mit einem einzelnen String-Parameter zu erwarten. Und falls in den Konstruktoren bereits irgendwelche Libraries zum Einsatz kommen (z.B. log4j), benötigt JMeter auch diese.
• Völlig rätselhaft war mir das Verhalten des „Regular Expression Extractor“-Controllers, mit dem man Variablen mittels Regex aus dem Ergebnis des letzten Samplers definieren kann. Der Inhalt dieser Variablen war flüchtig wie eine Seifenblase. Im direkt folgenden Sampler konnte man ihn noch verwenden, danach war er wie vom Winde verweht. Es ist mir nicht gelungen, den Variableninhalt in andere Variablen oder Strukturen zu transferieren und auch kein anderer der vielen denkbaren Workarounds funktionierte.
• Besondere Spannung kommt auf, wenn ein JMeter-Testplan mehrere JUnit-Sampler enthält. Manchmal ändert JMeter die Test-Klassen und Test-Methoden aller Sampler auf die entsprechende Klasse und Methode des aktuellen Samplers ab. Bisher habe ich den Auslöser für diesen Bug noch nicht gefunden.

Nette Features wie diese helfen dabei, die Aufmerksamkeit bei der Arbeit mit JMeter hoch zu halten. Anders ausgedrückt: Ich entwickelte eine handfeste Paranoia gegenüber JMeter, da ich nie sicher war, dass es wirklich das tut, was es soll. Außerdem hat dieses Verhalten den Effekt, den Fehler immer zuerst bei JMeter zu suchen, sobald irgendwo etwas schief geht.

Einige andere Dinge sind lediglich unpraktisch, z.B. die Verzeichnis-Pfade. JMeter liest und schreibt viele Dateien: Testpläne, Testparameter, Ergebnis-Dateien. Die Default-Verzeichnisse für diese Dateien sind aber unterschiedlich: Manchmal ist es das Verzeichnis, in dem der Testplan liegt; ein anderes Mal das JMeter-bin-Verzeichnis. Eine Logik habe ich dabei noch nicht entdeckt.

Führt man Tests über die JMeter-GUI durch und nicht über die Kommandozeile oder ein Skript, so spürt man schnell das dringende Verlangen, nach jedem Testlauf die GUI durchzustarten. Oftmals kann man nur dadurch sicherstellen, dass nicht irgendwelche Artefakte des letzten Tests noch in JMeter aktiv sind. Außerdem ist dies notwendig, um eine frische JVM zu kreieren, wenn – wie z.B. in einem typischen JUnit-Test-Szenario – alles in einer einzelnen JMeter-JVM läuft: JMeter, die JUnit-Test-Klassen und manchmal sogar auch noch das zu testende Java-System selbst.

So weit, so schlecht. JMeter ist also ein Dreckstool. Warum liebe ich es dennoch? Nun – JMeter hat praktisch keine Abhängigkeiten, ist schnell installiert, Open Source und kostenlos. Und zu all dem bietet es eine erstaunliche Flexibilität. Am häufigsten findet wahrscheinlich der HTTP-Sampler Verwendung, da er die ideale Schnittstelle ist, um Web-Anwendungen aus Anwendersicht zu testen. Andere Sampler, wie z.B. der hier beschriebene JUnit-Sampler, setzen auf einer tieferen, technischen Ebene an. Zur Zeit bietet JMeter ca. 20 verschiedene Sampler, die auf vielen unterschiedlichen Protokollen operieren.

Eine weitere nützliche Zugabe ist das sogenannte Performance-Plugin für Jenkins, das de facto ein JMeter-Plugin ist. Bei codecentric möchten wir so viel automatisieren wie nur irgend möglich und mit dem Performance-Plugin gelingt dies sogar mit JMeter-Performance-Tests.

Und wem das noch nicht reicht, der kann direkt den JMeter-Testplan hacken (der nur eine XML-Datei ist) – aber auch dabei muss man sich vor den Launen JMeters hüten, da nicht alle Modifikationen funktionieren, die logisch betrachtet möglich sein sollten – oder auch seinen eigenen Zusatz-Code schreiben.

JMeter erinnert mich an den Spruch eines alten Freundes, der mir über sein erstes Auto – einen kleinen Franzosen – Folgendes erzählt hat: „Ich wollte immer ein Auto mit Charakter. Und dieses Auto hat einen Charakter: Einen miesen zwar, aber es hat Charakter.“ Er liebte sein Auto.

Insgesamt gesehen: Werde ich JMeter wieder benutzen? Ganz gewiss. JMeter hilft einem, den Job zu erledigen, trainiert die Stressresistenz und nicht zu vergessen: Man lernt Demut.

In diesem Artikel in der Reihe der KTM-Blogs möchte ich die verschiedenen Möglichkeiten erläutern, die KTM zur Klassifizierung von Dokumenten bietet.

Die bisher erschienenen  KTM-Artikel über Formatlokatoren finden Sie hier:

Kofax Transformation Modules – Formatlokatoren und dynamische reguläre Ausdrücke – Teil 1
Kofax Transformation Modules – Formatlokatoren und dynamische reguläre Ausdrücke – Teil 2

Bevor Daten aus einem Dokument extrahiert werden können, muss ein System zunächst wissen, um welche Art Dokument es sich handelt. Aus einer Rechnung müssen beispielsweise andere Daten extrahiert werden, als aus einem Versicherungsvertrag. Bei der Rechnung will man typischerweise die Rechnungsnummer, das Rechnungsdatum, den Lieferanten und die Beträge extrahieren, wohingegen bei dem Versicherungsdokument die Werte Versicherungsnummer und Versicherungssparte von Interesse sind.

Vor der eigentlichen Extraktion muss also zunächst bestimmt werden, welche Art von Dokument vorliegt. Dies wird bei KTM durch die vor der Extraktion stattfindende Klassifikation durchgeführt. Sobald ein Dokument klassifiziert wurde, können dann die passenden Metadaten extrahiert werden.

Die Klassifikation eines Dokuments kann durch KTM mit verschiedenen Methoden durchgeführt werden, die sich in der Komplexität und im Aufwand für die Dokumentenvorbereitung unterscheiden:

1. Layoutklassifikation

Bei dieser Klassifikationsart versucht das System die Art des Dokuments anhand des grafischen Aufbaus zu bestimmen. Dieses Vorgehen ist die schnellste Art der Klassifizierung, da hierzu keinerlei OCR-Erkennung notwendig ist, da zur Klassifikation ja nicht der Dokumenteninhalt herangezogen wird. Allerdings ist diese Art der Klassifikation nur in Dokumentenbereichen nutzbar, in denen sich die Belege optisch klar voneinander trennen lassen. Beispiel wären bestimmte Antragsarten, die sich durch ihr Design (Aufbau, Firmenlogo, …) abgrenzen lassen. Ungeeignet sind hier beispielsweise zum Teil Formulare im Finanzdienstleistungs- oder Versicherungsbereich, da diese sich optisch häufig sehr ähneln.

Natürlich muss man KTM die Layoutklassifikation für die Dokumentenarten eines Kunden antrainieren. KTM hält den manuellen Aufwand hierzu aber sehr gering. Im Vorfeld müssen für die in Frage kommenden Dokumentarten jeweils einige Beispieldokumente zusammengetragen werden. Anschließend zeigt man KTM noch, welche Beispiele für welche Dokumentenklasse stehen. KTM lernt dann selbstständig die kennzeichnenden Strukturen der Layouts der einzelnen Dokumentarten. Das Antrainieren der Beispieldokumente kann einfach über die grafische Oberfläche des KTM Project Builders durchgeführt werden.

2. Inhaltsklassifikation

Die (automatische) Inhaltsklassifikation ähnelt vom Vorgehen her der Layoutklassifikation, mit dem Unterschied, dass hier nicht die optische Struktur, sondern der tatsächliche Dokumenteninhalt zur Klassifizierung herangezogen wird. Dazu muss natürlich vorher ein OCR-Lesen der Dokumente erfolgen.

Das charmante daran ist, dass der Entwickler keinerlei Vorgaben zur Bedeutung des Inhalts machen muss. Ähnlich wie bei der Layoutklassifikation muss auch hier für jede Dokumentart ein Stapel an Beispieldokumenten zusammengetragen werden. Nach erfolgter OCR-Lesung der Beispieldokumente zeigt man KTM auch hier wieder, welcher Beispielstapel für welche Dokumentart steht. Anschließend lernt KTM dann selbstständig welche Worte, Phrasen oder Wortkombinationen charakteristisch für eine Dokumentart sind. Das Antrainieren der Beispieldokumente geschieht auch hier einfach über die grafische Oberfläche des KTM Project Builders.

3. Instruktionsklassifikation

Bei der Layout- und Inhaltsklassifikation müssen dem KTM-System ‘nur’ genug Beispielbelege zur Verfügung gestellt werden. Die eigentliche Arbeit des Lernens und Bewertens wird dann von KTM durchgeführt. Bei der Instruktionsklassifikation muss hingegen der Entwickler die Dokumente inhaltlich kennen und bewerten können. Je Dokumentart kann der Entwickler manuell Worte, Phrasen und Wortkombinationen hinterlegen, die eine Dokumentart kennzeichnen. Hier ist also fachspezifisches Wissen über das Beleggut notwendig.

Die Instruktionsklassifikation wird häufig bei Beleggut eingesetzt, das zum großen Teil aus Korrespondenz besteht. Kommen beispielsweise die Worte ‘Mahngebühr’ und ‘Mahnung’ beide auf einem Dokument vor, kann man das Dokument darüber in die Dokumentart ‘Mahnverfahren’ klassifizieren.

Damit die Instruktionsklassifikation genutzt werden kann, muss vorher eine OCR-Lesung des Belegguts erfolgt sein. Die Eingabe der Instruktionen (Worte, Phrasen, Wortkombinationen) erfolgt über die grafische Oberfläche des KTM Project Builders.

4. Skript-Klassifikation

4.1 Barcode

In manchen Anwendungsfällen kann ein auf den Dokumenten aufgebrachter Barcode ausreichend für die Klassifizierung des Dokuments sein. KTM bietet auch diese Möglichkeit, man muss dazu aber die KTM-eigene Skriptsprache benutzen.

Ausgangspunkt ist ein auf Projektebene definierter Barcode-Lokator (BCode), der die Dokumentenbarcodes erkennt. Ein Stückchen Skript auf der Projektebene hilft das Dokument auf die gewünschte Dokumentart zu klassifizieren:

' Class script: Project
Private Sub Document_BeforeClassifyXDoc(pXDoc As CASCADELib.CscXDocument, bSkip As Boolean)
  If pXDoc.Locators.ItemByName("BCode").Alternatives.Count>0 Then
     If pXDoc.Locators.ItemByName("BCode").Alternatives(0).Confidence > 0.95 Then
       pXDoc.Reclassify "Barcodeantrag"
       Exit Sub 'möglichst nur ein reclassify
     End If
  End If
End Sub

Das Skript wird im Event Document_BeforeClassifyXDoc aufgerufen, welches vor allen anderen Klassifizierungsmechanismen von KTM ausgeführt wird.

Zunächst wird überprüft, ob der Barcode-Lokator überhaupt etwas gefunden hat, und ob die Konfidenz über 95% lag. Falls ja erfolgt über den reclassify-Befehl die Klassifizierung auf die Dokumentart ‘Barcodeantrag’. Nach erfolgter Klassifizierung wird die Routine verlassen, damit keine weitere Klassifizierung durch ein folgendes Stück Skript erfolgen kann. Ein mehrfaches reclassify ist zwar inzwischen mit KTM möglich, sollte aber nur mit Vorsicht eingesetzt werden, da man damit leicht Endlosschleifen hervorrufen kann.

4.2 Formatlokatoren, Erweiterte Zonenlokatoren und der ganze Rest…

Das in 4.1 anhand eines Barcodelokators beschriebene Prinzip der Skriptklassifizierung kann natürlich auch mit beliebigen anderen Lokatoren durchgeführt werden. Wichtig ist, dass der entsprechenden Lokator auf Projektebene definiert wird, da er sonst im Event Document_BeforeClassifyXDoc nicht ausgewertet werden kann, und er muss natürlich die Dokumentart eindeutig kennzeichnen. Der primäre Zweck dieser ‘Projektlokatoren’ ist also nicht die Datenextraktion sondern sie dienen als Hilfsmittel zur Klassifikation.

Mit einem auf Projektebene definierten Formatlokator kann man beispielsweise den Typ eines Versicherungsantrags feststellen und dann das Dokument entsprechend klassifizieren. Das folgende Bild zeigt  einen Ausschnitt eines Haftpflichtversicherungsantrags:

Mit einem Formatlokator (Antrag_Haft), der beispielsweise das Wort Haftpflichtversicherung oberhalb des Wortes Antrag in einer Region in der linken oberen Ecke des Dokuments sucht, kann der Antragstyp eindeutig bestimt werden.

Das passende Stück Skript sieht dann so aus (enstprechend dem Barcodebeispiel):

' Class script: Project
Private Sub Document_BeforeClassifyXDoc(pXDoc As CASCADELib.CscXDocument, bSkip As Boolean)
  If pXDoc.Locators.ItemByName("Antrag_Haft").Alternatives.Count>0 Then
     If pXDoc.Locators.ItemByName("Antrag_Haft").Alternatives(0).Confidence > 0.95 Then
       pXDoc.Reclassify "Antrag_Haftpflicht"
       Exit Sub 'möglichst nur ein reclassify
     End If
  End If
End Sub

Nutzt man einen ‘Erweiterten Zonenlokator’ (Antrag_Haft_EZL) für die Klassifizierung muss man das Skript nur leicht an die Unterfelder des Zonenlokators anpassen:

' Class script: Project
Private Sub Document_BeforeClassifyXDoc(pXDoc As CASCADELib.CscXDocument, bSkip As Boolean)
  If pXDoc.Locators.ItemByName("Antrag_Haft_EZL").Alternatives.Count>0 Then
     If pXDoc.Locators.ItemByName("Antrag_Haft_EZL").Alternatives(0).SubFields.ItemByName("UF_Zone0").Confidence > 0.95 Then
       pXDoc.Reclassify "Antrag_Haftpflicht"
       Exit Sub 'möglichst nur ein reclassify
     End If
  End If
End Sub

Hat man das Prinzip der Skriptklassifizierung einmal verstanden, sind der Fantasie eigentlich keine Grenzen gesetzt. So könnte man beispielsweise über einen Datenbanklokator den Absender der Eingangsdokumente bestimmen (falls eine entsprechende Stammdatendatei vorliegt) und die Dokumente dann in vordefinierte Gruppen klassifizieren.

Oft haben Formulare eine eindeutige Formularnummer um 90° gedreht in der unteren linken Ecke aufgedruckt. Mit einem ‘Erweiterten Zonenlokator’ kann diese um 90° gedrehte Nummer ausgelesen und zur Dokumentenklassifikation genutzt werden.

Ich hoffe Ihnen durch diesen Artikel einige Anregungen für die Arbeit mit Kofax Transformation Modules gegeben zu haben und wünsche viel Spaß beim Experimentieren

Noch ein Hinweis für die Entwickler unter den Lesern: mein Kollege Frank Engelen aus dem codecentric Unternehmensbereich Agile Software Factory hat aktuell einen sehr interessanten Artikel über Daten- / Dokumentklassifizierung unter Nutzung des Tools ‘RapidMiner’ verfasst. Mit ‘etwas’ Java KnowHow können Sie Ihre eigenen Klassifizierungsmechanismen entwickeln!

Hier der Link zum Artikel: Taking a look at Java-based Machine Learning by Classification