Java Batch: Der neue Standard für‘s Stapeln

322 views

Published on

Vortrag Expertenkreis Java am 8.5.2014

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
322
On SlideShare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
8
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Java Batch: Der neue Standard für‘s Stapeln

  1. 1. Java Batch 1.0 – Der neue Standard für‘s Stapeln Java Expertenkreis, 08.05.2014 Gedoplan IT Training Klaus Bertelt, GEDOPLAN GmbH
  2. 2. Batch? Ein alter Hut! Warum ist das jetzt so besonders? Ich mach das schon ewig! Stimmt wohl, aber: Bis jetzt ohne Standard Irgendwie Ohne Unterstützung seitens des Servers Mit Java-Batch in der Java EE 7 wird das anders! 2
  3. 3. Was ist Java - Batch Neues Framework seit Java EE 7 Stark inspiriert von Spring (Zusammenarbeit) Bietet standardisierte und serverseitige Unterstützung Parallelisierbar Statusgesteuert Entscheidungsgesteuert Steuerung via XML oder Artefakten Menge von Interfaces, die mit der entsprechenden Funktionalität implementiert werden können EE oder standalone 3
  4. 4. Wann nutze ich (Java) – Batch? Batch –Kandidaten sind: immer wiederkehrende Prozesse zeit-, rechen-, oder speicherintensiv ohne menschliche Beteiligung klar definierbar (einzelne Schritte) Bsp: Tägliche Aktualisierung eines Artikelstamms 4
  5. 5. Batch – grundlegende Begriffe JobList: Oberstruktur im Batchprocessing. Besteht aus 1-n Jobs. Job: Bestandteil der Joblist. Kann mit anderen Jobs in Beziehung gesetzt werden. Ein Job besteht aus 1-n Steps Step: Bestandteil eines Jobs. Beinhaltet einzelne Arbeitsschritte, Chunk (Brocken, Batzen): die eigentlichen Arbeitstiere. Chunk und E.V.A. sind gute Freunde Task (Batchlet): Zuarbeiter, nicht zwangs- läufig laufzeitintensiv. 5
  6. 6. Batch - grundlegende Begriffe Flow: Abfolge von Steps, die als Einheit ausgeführt werden können. Split: Menge von Flows, die parallel ausgeführt werden können. Decision: Entscheider, z. Bsp. ob nächster Step ausgeführt wird, oder der Job terminiert wird. Partition: Möglichkeit, Batch-Mengen auf mehr als einem Thread laufen zu lassen. Checkpoint: Wird gesetzt, wenn die Ergebnisse eines Chunks übergeben wurden; Ermöglicht so das genau Ansteuern von Teilaufgaben Für mehr Infos: http://download.oracle.com/otndocs/jcp/batch-1_0-fr-spec/ 6
  7. 7. Batch - Struktur JobOperator: Manager des Jobs JobRepository: Enthält Infos über Jobs, die laufen oder gelaufen sind. 7 Quelle: JSR-352-1.0-Final- Release.pdf
  8. 8. Implementierung - Steuerdatei In Enterprise-Applications In Web-Applications 8 Naming: *jobID*.xml
  9. 9. Implementierung – So sieht sie aus: 9 <job id="adressJob" xmlns=http://xmlns.jcp.org/xml/ns/javaee” version="1.0"> <listeners> <listener ref="de.gedoplan.seminar.javabatch.batch.listener.MyJobListener"/> </listeners> <step id="buildingData" next="adressStep"> <batchlet ref="de.gedoplan.seminar.javabatch.batch.GenerateDataBatchlet" /> </step> <step id="adressStep"> <listeners> <listener ref="de.gedoplan.seminar.javabatch.batch.listener.MyStepListener"/> </listeners> <chunk item-count="10"> <reader ref="adressItemReader" /> <processor ref="adressItemProcessor" /> <writer ref="adressItemWriter" /> </chunk> </step> </job>
  10. 10. Implementierung - Batchlet Task: Wird einmal im Step ausgeführt. 10 Job.xml: <step id="buildingData" next="adressStep"> <batchlet ref="de.gedoplan.seminar.javabatch.batch.GenerateDataBatchlet" /> </step> Implementierung: public class GenerateDataBatchlet implements Batchlet { @Override public String process() throws Exception { return null; } @Override public void stop() throws Exception { }
  11. 11. Implementierung – Chunk Chunk: Wird solange wiederholt, wie Daten vorhanden sind. 11 Job.xml: <chunk item-count="10"> <reader ref="adressItemReader" /> <processor ref="adressItemProcessor" /> <writer ref="adressItemWriter" /> </chunk> 1. 2. „count“ -mal „count“ -mal Writer ItemReader ItemProcess or
  12. 12. Implementierung – Chunk: ItemReader Wird pro Operation (z. Bsp. Datensatz) einmal ausgeführt 12 @Named public class AdressItemReader implements ItemReader { @Override public void open(Serializable checkpoint) throws Exception { } @Override public String readItem() throws Exception { return null; } @Override public Serializable checkpointInfo() throws Exception { return null; } @Override public void close() throws Exception { }
  13. 13. Implementierung – Chunk: ItemProcessor & ItemWriter Wird pro Operation (z. Bsp. Datensatz) einmal ausgeführt Wird 1 mal alle „item-counts“ ausgeführt 13 @Named public class AdressItemProcessor implements ItemProcessor { @Override public Person processItem(Object arg0) throws Exception { return null; } @Named public class AdressItemWriter implements ItemWriter { @Override public void writeItems(List<Object> arg0) throws Exception { } @Override public Serializable checkpointInfo() throws Exception { return null; } @Override public void open(Serializable checkpoint) throws Exception { } @Override Public void close() throws Exception { }
  14. 14. Implementierung - Properties Möglichkeit 1: Übergabe bei Batch-Start Java.util.Properties erzeugen füllen mitgeben Möglichkeit 2: Auf nahezu jeder Ebene des job.xml können properties definiert werden: 14 <job id=„adressJob"> <properties> <property name=„adressFile" value=„adressen.txt" /> </properties> <step id=„step1"> <chunk> <properties> <property name=„adressFile" value="#{jobProperties[‚adressfile']}" /> </properties> - jobParameters - jopProperties - systemPropertie s - partitionPlan @Inject @BatchProperty(name = „adressFile") private String filename;
  15. 15. Implementierung - CheckPoint Optional, aber: Hilft bei Fehlern nicht komplett wieder von Vorn zu starten Beispiel: 1.000.000 Zeilen einlesen, Zeile 999.000 führt zu einem Fehler. Möglichkeit 1: 15 <chunk checkpoint-policy="item" commit-interval="10" item-count="10"> @Override public void open(Serializable checkpoint) throws Exception { if (checkpoint == null) { this.counter = 0; } else { this.counter = (Integer) checkpoint; } @Override public Serializable checkpointInfo() throws Exception { return 0; }
  16. 16. Implementierung - Checkpoint Schicker: Checkpoint Algorithm 16 @Named public class AdressCheckpointAlgorithm extends AbstractCheckpointAlgorithm { @Override public void beginCheckpoint() throws Exception { System.out.println("Etwas zum Anfang machen."); } @Override public void endCheckpoint() throws Exception { System.out.println("Etwas zum Ende machen."); } @Override public boolean isReadyToCheckpoint() throws Exception { return AdressItemReader.COUNT % 100 == 0; } } Job.xml: <chunk checkpoint-policy="custom"
  17. 17. Implementierung - Partition Möglichkeit auf Step-Ebene Prozesse parallel auf mehreren Threads ablaufen zu lassen 17 Step Chunk ItemReader ItemWriter Chunk ItemReader ItemWriter ItemProces sor ItemProces sor Chunk ItemReader ItemWriter ItemProces sor
  18. 18. Implementierung – Partitioning Entweder PartitionPlan Oder PartitionMapper 18 <chunk> … <properties> <property name="firstItem" value="#{partitionPlan['firstItem']}"/> <property name="lastItem" value="#{partitionPlan['lastItem']}"/> </properties> … </chunk> public class MyMapper implements PartitionMapper{ @Override public PartitionPlan mapPartitions() throws Exception { return null; } public void setThreads(…) public void setPartitionsOverride(…) public void setPartitions(…) public void setPartitionProperties(…) public int getThreads() public boolean getPartitionsOverride() public int getPartitions() public Properties[] getPartitionProperties() <partition> <mapper ref="MyPartitionMapperImpl"/> … </partition> Job.xml: <partition> <plan partitions="2" threads="2"> <properties partition="0"> <property name="firstItem" value="0"/> <property name="lastItem" value="500"/> </properties> <properties partition="1"> <property name="firstItem" value="501"/> <property name="lastItem" value="999"/> </properties> </plan> </partition>
  19. 19. Implementierung - Partitioning Reducer: Implementierung von PartitionReducer Steuerung der Partitionen Collector: Implementierung von PartitionCollector Senden von Zwischenergebnissen einzelner Partitionen Analyser: Implementierung von PartitionAnalyser Analyse der Zwischen- und Endergebnisse 19 <partition> <reducer ref=„…“/> <collector ref=„…“/> <analyser ref=„…“/> </partition>
  20. 20. Implementierung – Flow, Split und Decision Kurz angerissen: Flow: Führt Elemente als Einheit aus Kann weitere Flows, Decision, Splits enthalten Split: Führt Elemente gleichzeitig aus (jedes auf einem eigenen Thread) Kann Flows enthalten Decision: Ermöglicht Entscheidungen bzgl. weiterer Verarbeitung Kann Steps, Flows, Splits enthalten 20
  21. 21. Implementierung Transitions Kurz angerissen: Transitions ermöglichen die Steuerung nach einem Step, Flow, Split oder Decision für die nächsten Schritte: Next: Das nächste Element wird ausgeführt Fail: Job endet mit Status: FAILED End: Job endet mit Status: COMPLETED Stop: Job endet mit Status: STOPPED 21 <next on="{exit status}" to="{step id|flow id|split id}”/> <fail on="{exit status}" exit-status="{exit status}"/>
  22. 22. Flow Wiekann das aussehen? 22 StepI Task StepII Chunk ItemReader ItemWriter StepIII Chunk Deci- sion ItemReader ItemWriter StepIV Chunk ItemReader ItemWriter EndeStart ItemProcessor ItemProcessor ItemProcessor
  23. 23. Implementierung – Listener Für weitere Operationen können auf die verschiedenen Bestandteile des Batch Listener gelegt werden: Job JobListener Step StepListener ItemReadListener, ItemProcessListener, ItemWriteListener ChunkListener RetryReadListener, RetryProcessListener, RetryWriteListener SkipReadListener, SkipProcessListener, SkipWriteListener 23
  24. 24. Implementierung – im xml Job-Ebene Step-Ebene 24 <step id="adressStep"> <listeners> <listener ref="de.gedoplan.seminar.javabatch.batch.listener.MyStepListener"/> <listener ref="de.gedoplan.seminar.javabatch.batch.listener.MyChunkListener"/> <listener ref="de.gedoplan.seminar.javabatch.batch.listener.MyBatchletListener"/> … </listeners> <job id="adressJob" xmlns="http://xmlns.jcp.org/xml/ns/javaee" version="1.0"> <listeners> <listener ref="de.gedoplan.seminar.javabatch.batch.listener.MyJobListener"/> </listeners>
  25. 25. Implementierung - Exceptions 1. es! passieren! keine! Fehler!!!! 2. Aber, was wenn doch? Nicht abgefangene Exceptions terminieren mit Status FAILED Verhalten kann überschrieben werden Retryable Exceptions: Prozess versucht‘s nochmal 25 <skippable-exception-classes> <include class="{fullpackage-classname}"/> <exclude class="{fullpackage-classname}"/> </skippable-exception-classes>
  26. 26. Implementierung – Wie starte ist das Ganze? Starten: Restarten (nach Fehler, Stopp): Wichtig: restart funktioniert nur wenn Status != COMPLETED, ABANDONED 26 JobOperator jobOperator = BatchRuntime.getJobOperator(); Properties props = new Properties(); props.setProperty("parameter1", "value1"); ... long execID = jobOperator.start("simplejob", props); executionId = BatchRuntime.getJobOperator().restart(executionId, new Properties());
  27. 27. Statüsse … Stati … Statanten … Status (plural)! STARTING: Job/Step wurde an die Batch runtime übermittelt. STARTED: Job/Step läuft. STOPPING: Job/Step hat einen entsprechenden Halt-Request. bekommen. STOPPED: Job/Step ist gestoppt. FAILED: Job/Step ist aufgrund eines Fehlers beendet. (z. Bsp. bei jeder nicht gefangenen Exception) COMPLETED: Job/Step ist erfolgreich durchgelaufen. ABANDONED: Job/Step ist beendet. 27
  28. 28. STOPPED Was kann alles so passieren? 28 STARTING STARTED COMPLETED FAILED STOPPING ABANDONED stop() start() abandon() abandon() abandon() restart() restart()
  29. 29. Demo 29
  30. 30. Monitoring – Im WildFly? Fehlanzeige Es gibt zwar Einstellungen für Batching, aber die betreffen mehr die Thread Eigenschaften 30
  31. 31. Monitoring – Gott Sei Dank recht einfach selbst geschrieben Grundlegende Möglichkeiten: JobOperator JobExecution StepExecution Aus der Demo: 31 JobExecution execution = jo.getJobExecution(executionId); List<StepExecution> steps = jo.getStepExecutions(executionId); JobOperator jo = BatchRuntime.getJobOperator(); s.setName(se.getStepName()); s.setStatus(se.getBatchStatus().toString()); s.setExitStatus(se.getExitStatus());
  32. 32. Monitoring – Innerhalb des Batches JobContext StepContext Beispiele: 32 @Inject private JobContext jc; @Inject private StepContext sc; sc.getBatchStatus(); sc.getExitStatus(); sc.setExitStatus();
  33. 33. Fazit Endlich ein Standard Vereinfacht viele Dinge Bietet viele Möglichkeiten … die man selbst schreiben muss (Noch) wenig Infos im Netz Ist neu und es gibt noch keine (nicht viel) Produktiverfahrung. Bisherige Erfahrungen gut! ABER: Oracle, da geht noch was!!! 33
  34. 34. Vielen Dank für die Aufmerksamkeit! Noch Fragen? 34

×