In den Zeiten von Business Process Engines, ESBs und SOAs könnte man meinen, dass die gute alte Batchverarbeitung in Vergessenheit geraten ist. Doch gerade in Versicherungsunternehmen und Banken müssen große Datenmengen bewegt werden und da ist die Stapelverarbeitung weiterhin das Maß aller Dinge. Für einige Kunden haben wir bereits Batchprozesse auf Java-Basis implementiert und damit gute Erfahrungen gemacht. In vielen Projekten findet man heute aufwändige eigene Implementierungen. Dabei lohnt wie immer ein Blick auf eine Standardtechnologie.
Unser Partner springsource bietet neben den bereits sehr verbreiteten Komponenten, wie z.B. das springframework, Spring MVC oder Spring WebFlow auch ein auf Spring basierendes Open Source Batch Framework an. Leider finden sich im Netz viele veraltete Artikel aus den Anfangszeiten des Frameworks.
Technisch gesehen ist das Framework aber gut dokumentiert . Ich möchte an dieser Stelle nicht auf die einzelnen Details eingehen, sondern ein praxisorientiertes Beispiel vorstellen. Mit Hilfe von Spring Batch lässt sich mit wenig Aufwand und in kurzer Zeit eine funktionierende Lösung implementieren.
Beispiel aus der KFZ-Versicherung
Ein Kunde wechselt zu einem anderen Versicherungsunternehmen und nennt dabei dem neuen Versicherer seine aktuellen Schadenfreiheitsklassen. Um dies zu überprüfen wendet sich der neue Versicherer an den GDV (Gesamtverband der deutschden Versicherer). Der GDV bietet mit dem so genannte VWB-Verfahren die Möglichkeit SF-Klassen beim Vorversicherer zu verifizieren. Als Basis zur Kommunikation dienen hier Textdateien mit einem festen Satzaufbau.
Basiskonfiguration
Die Basiskonfiguration für die Verarbeitung von eingehenden VWB-Nachrichten sieht mit der Spring Batch Version 1.x so aus:
1<bean id="vwbIncomingJob" parent="simpleJob"> 2 <property name="name" value="vwbIncoming" /> 3 <property name="restartable" value="true" /> 4 <property name="steps"> 5 <list> 6 <bean parent="skipLimitStep"> 7 <property name="streams"> 8 <list> 9 <ref bean="fileItemReader" /> 10 </list> 11 </property> 12 <property name="itemReader" ref="itemReader" /> 13 <property name="itemWriter" ref="itemWriter" /> 14 <property name="skippableExceptionClasses" value="java.lang.Exception" /> 15 <property name="fatalExceptionClasses"> 16 <value> 17 org.springframework.beans.factory.BeanCreationNotAllowedException, 18 java.lang.IllegalStateException, 19 org.springframework.jndi.JndiLookupFailureException 20 </value> 21 </property> 22 <property name="skipLimit" value="${job.vwbIncoming.skipLimit}" /> 23 <property name="commitInterval" value="${job.vwbIncoming.commitInterval}" /> 24 <property name="listeners"> 25 <list> 26 <ref bean="inputFile"/> 27 <ref bean="logFileFail" /> 28 <ref bean="logFileComplete" /> 29 <ref bean="itemLoggerListener"/> 30 </list> 31 </property> 32 </bean> 33 <bean parent="taskletStep"> 34 <property name="tasklet" ref="mailTasklet" /> 35 </bean> 36 </list> 37 </property> 38</bean>
Ein Spring Batch Job besteht in den meisten Fällen aus 1-n Steps. Hier wird ein spezieller SkipLimitStep genutzt, wo sich genau konfigurieren lässt, welche Typen von Exceptions ggf. akzeptiert werden können oder welche den Job direkt abbrechen lassen. Dies ist in der Regel sehr hilfreich, da nicht immer alle Sätze korrekt interpretiert werden können und nicht jedesmal der Job neu gestartet werden soll.
Der Konfiguration ist auch zu entnehmen, dass die einzelnen Resources (Eingangsdatei, Logfiles) als Listener in den Step reingehangen werden. Sinn und Zweck ist auch hier die Nutzung einer Spring-Batch-Komponente, die für die saubere Erzeugung und Verarbeitung der Dateien zuständig ist. Zusätzlich lässt sich hier mit Hilfe von Platzhaltern auch der Name der Dateien variabel gestalten.
Beispiel:
1<bean id="inputFile" class="org.springframework.batch.core.resource.StepExecutionResourceProxy"> 2 <property name="filePattern" value="file:${jboss.server.data.dir}${job.vwbIncoming.incoming.path}//%file.name%"/> 3</bean>
Der Job gliedert sich in folgende Teilaufgaben:
1. ItemReader: Einlesen der GDV-Datei und Transformation von 1-n-Satzzeilen in ein XML-Dokument
Konfiguration:
1<bean id="itemReader" class="org.springframework.batch.item.file.FlatFileItemReader" > 2 <property name="comments"> 3 <list> 4 <value>#</value> 5 <value>**</value> 6 <value>KONTROLLE</value> 7 </list> 8 </property> 9 <property name="lineTokenizer" ref="flatFileTokenizer"/> 10 <property name="resource" ref="inputFile"/> 11 <property name="fieldSetMapper" ref="vwbDokumentFieldSetMapper"/> 12</bean> 13 14<bean id="flatFileTokenizer" class="org.springframework.batch.item.file.transform.PrefixMatchingCompositeLineTokenizer"> 15 <property name="tokenizers"> 16 <map> 17 <entry key="10" value-ref="recordType10" /> 18 <entry key="20" value-ref="recordType20" /> 19 <entry key="21" value-ref="recordType21" /> 20 [...] 21 </map> 22 </property> 23</bean> 24 25<bean id="recordType10" class="org.springframework.batch.item.file.transform.FixedLengthTokenizer"> 26 <property name="names" value="satzart, verbandsVorgangsnummer, datum, vuGstNrNachvers, vsnrBeimNachvers, anfragegrund, fahrzeugidentifizierungsNrBeimNachvers, [...]" /> 27 <property name="columns" value="1-2, 3-20, 7-14, 21-28, 29-48, 49-50, 51-67, [...]"/> 28</bean>
Dieser Vorgang kann fast ausschließlich über Konfiguration erzeugt werden. Der FlatFileItemReader erhält eine Referenz auf die Eingangsdatei und liefert die einzelnen Zeilen an einen LineTokenizer. Die Standard-Implementierung des PrefixMatchingCompositeLineTokenizer sorgt für die Transformation in FieldSets, vergleichbar mit einem Array bzw. einem Datenbank-ResultSet, wo sich die einzelnen Felder über die Feldposition ansprechen lassen. Der GDV liefert jeden Satz mit einer Satzart als Präfix, wodurch der LineTokenizer immer genau weiß, welche Felder er mappen muss. Für z.B. dynamische Satzlängen sind natürlich auch bereits fertige Klassen verfügbar.
Der FieldSetMapper ist hier die einzige Stelle, wo man selber Hand anlegen muss. Die Implementierung der Methode public Object mapLine(FieldSet fieldSet) erzeugt aus einem FieldSet das Zielobjekt. In diesem Beispiel wird mit Hilfe einer generischen Implementierung ein Java-Objekt erzeugt, welches später mit Hilfe von XStream in ein XML-Dokument transformiert wird.
2. ItemWriter: Verarbeitung und Persistierung der Items im Zielsystem
Aus der Sicht von Spring Batch passiert hier nicht viel und sollte auch nicht! Das Ziel sollte hier immer die Delegation an einen Business-Service sein, der die Verarbeitung vornimmt. Daraus ergibt sich nicht nur der Vorteil der besseren Testbarkeit, sondern ein Batch ist neben den verschiedenen Online-Komponenten nur ein Auslöser dieser Funktion. In einer ersten Ausbaustufe wird das Dokument lediglich an den Zielvertrag angehangen, welches im Nachgang natürlich eine manuelle Bearbeitung erfordert.
3. Tasklet: E-Mail-Versand der Logfiles
Wie bei jeder sauber implementierten Software-Komponente darf natürlich auch hier das Monitoring nicht fehlen. Denkbar sind hier verschiedene Herangehensweisen. Spring Batch bietet hier für fast jede Stelle im Job-Ablauf eine Listener-Schnittstelle an. Im VWB-Beispiel werden pro Item Logeinträge geschrieben, die Auskunft über den Erfolg/Misserfolg der Verarbeitung geben. Im letzten Arbeitsschritt versendet das MailTasklet die entsprechenden Logfiles an die verantwortlichen Personen.
1<bean id="vwbIncomingTasklet" class="com.codecentric.example.batch.tasklet.MailTasklet"> 2 <property name="mailTo"> 3 <list> 4 <value>${job.vwbIncoming.receiver1}</value> 5 <value>${job.vwbIncoming.receiver2}</value> 6 <value>${job.vwbIncoming.receiver3}</value> 7 </list> 8 </property> 9 <property name="mailSubject" value="${job.vwbIncoming.betreff}" /> 10 <property name="mailText" value="${job.vwbIncoming.body}" /> 11 <property name="mailFrom" value="${jobs.mailtemplate.sender}" /> 12 <property name="attachments"> 13 <map> 14 <entry key="vwbIncomingErfolgreich" value-ref="logFileComplete" /> 15 <entry key="vwbIncomingFehler" value-ref="logFileFail" /> 16 </map> 17 </property> 18</bean>
Testen
Und wie man es natürlich von Spring gewöhnt ist, wird auch bei Spring Batch sehr viel Wert auf einfache Testbarkeit der Komponenten gelegt. Die Job-Konfiguration lässt sich unter Berücksichtigung der notwendigen Abhängigkeiten mit den bekannten Bordmitteln von Spring testen. Hier ein Beispiel, welches die Grundlage für einen Test bilden kann:
1@ContextConfiguration(locations={"classpath:/jobs/vwbIncoming.xml"})
2public class VwbIncomingJobITest extends AbstractJUnit4SpringContextTests {
3
4 /** Der Job-Ausführer */
5 @Autowired
6 private JobLauncher jobLauncher;
7
8 /** Der zu testende Job */
9 @Autowired
10 @Qualifier("vwbIncomingJob")
11 private Job job;
12
13 /** Der Service für die Verarbeitung der eingehenden Dokumente */
14 private BusinessService businessServiceMock;
15
16 /** Die zu testende Eingabedatei */
17 private static final String INPUT_FILE = "src/test/resources/vwbIncoming/vwbTest.txt";
18
19 private JobParametersBuilder builder;
20
21 @Before
22 public void setUp() {
23 businessServiceMock= (BusinessService ) applicationContext.getBean("businessServiceMock");
24 builder = new JobParametersBuilder();
25 Resource inputFile = new FileSystemResource(INPUT_FILE);
26 builder.addString("file.name", inputFile.getFilename());
27 }
28
29 @Test
30 public void testLaunchVwbIncomingJob() throws Exception {
31 expect(businessServiceMock.verarbeiteVwbDokument(isA(VwbDokument.class))).andReturn(Boolean.TRUE);
32 replay(businessServiceMock);
33 JobExecution jobExecution = jobLauncher.run(job, builder.toJobParameters());
34 verify(businessServiceMock);
35 assertTrue(jobExecution.getStatus().equals(BatchStatus.COMPLETED));
36 }
37
38 [...]
39
40}
Ausblick
Das gezeigte Beispiel orientiert sich noch an der alten Version des Frameworks. Aktuell ist 2.1 als Release verfügbar und bietet neben nützlichen Neuerungen auch eine Vereinfachung der Konfiguration. Hierauf werd ich dann aber in einem meiner nächsten Blogeinträge eingehen und die Unterschiede anhand des Beispiels deutlich machen. Ein weiteres interessantes Thema in diesem Zusammenhang ist auch die Nutzung der Komponente Spring Integration, wo wir dann wieder in der ESB-Welt angekommen wären 😉 Für Feedback und weitere Themenvorschläge in Bezug auf Spring Batch bin ich natürlich immer dankbar 🙂
War dieser Beitrag hilfreich?
Weitere Beiträge
von Dennis Schulte
5.4.2015 Dein Job bei codecentric?
Jobs
Agile Developer und Consultant (w/d/m)
Alle Standorte
Weitere Artikel in diesem Themenbereich
Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.
Gemeinsam bessere Projekte umsetzen.
Wir helfen deinem Unternehmen.
Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.
Hilf uns, noch besser zu werden.
Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.
Blog-Autor*in
Dennis Schulte
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.
Du hast noch Fragen zu diesem Thema? Dann sprich mich einfach an.