Das sieht dann z.B. so aus:

declare
    v_id      number;

begin

 ----------------------------------------------------------------
 -- insert new record
 ----------------------------------------------------------------
  v_id := 159;

   begin
      select t.id
         into v_id
      from myTable t
      where t.id = v_id;

      dbms_output.put_line('existing record ... ' || v_id);

      exception
      when NO_DATA_FOUND then
         insert into myTable
            (id,
             description)
            values
            (v_id,
             'test');

         dbms_output.put_line('inserting record ... ' || v_id);
   end;
end;

In diesem Beispiel wird dabei nur auf den Primärschlüssel geprüft. In der Praxis ergeben sich meist bessere Möglichkeiten einen Datensatz zu identifizieren und seine Existenz festzustellen.

In der Java-Klasse, die mit Hibernate persistier werden soll, kann man wie folgt mit JPA annotieren:

   @Id
   @Column (name="MY_ID", length=16)
   @GeneratedValue (generator="GenAccId" )
   @GenericGenerator(name="GenAccId", strategy = "cc.raupach.MyNumberGenerator")
   private String myId;

Nun kann man die eigentliche Java-Klasse anlegen, die den ID-Generator enthält. Dazu implementier man das von Hibernate bereitgestellte Interface “IdentifierGenerator“:

public class MyNumberGenerator implements IdentifierGenerator
{
    static String query ="SELECT MySpezialSequence.nextval as myid FROM dual";

    public Serializable generate(SessionImplementor session, Object object) throws HibernateException
    {
       // hier wird eine eigene Session geöffnet und darin eine eigene Transaktion für Hibernate angelegt
       // um z.B. in einer DB-Abfrage eine ID zu gewinnen.
       Session sessionX=session.getFactory().openSession();
       sessionX.beginTransaction();
       BigDecimal seqNumber = (BigDecimal) sessionX.createSQLQuery (query).uniqueResult();
       sessionX.getTransaction().commit();

       String seqNumberStr = seqNumber.toString();
       String id = "ABCD_" + seqNumberStr;

       return id;
    }
}

Der Generator erzeugt in diesem Fall eine numerische ID aus einer eigenen Sequence, die ein Prefix “ABCD_” hat. Man kann mit der Methode im Prinzip alles zurückgeben was man will – nur unique sollte es natürlich sein. Über den Parameter “object” hat man auch Zurgriff auf das zu persistierende Object und kann darauf zugreifen und die generierung der ID so z.B. von bestimmten Attributen des Objekts abhängig machen und steuern.

Hier ein Beispiel. Gegeben sind die zwei Tabellen:

create table tbl_a
(
   id integer,
   description varchar(100)
);

create table tbl_b
(
   id integer
);

Aus der Tabelle “tbl_a” sollen nun alle Datensätze gelöscht werden, die in der Tabelle “tbl_b” enthalten sind – also für die gilt tbl_a.id = tbl_b.id. Dies funktioniert dann mit:

delete from tbl_a a
 where exists
 (select (1) from tbl_b b where a.id = b.id)

Dieses Beispiel basiert auf der Datenbank Oracle.

Eingesetzte Komponenten

Für dieses Setup verwende ich folgende Komponenten:

• Java 1.6
• Eclipse 3.5 Galileo
• Spring-Batch 2.0.3
• Maven 2.1.0
• M2Eclipse (Maven-Eclipse Integration)

Für das m2eclipse-Plugin kann folgende Eclipse-Update-Seite verwendet werden: http://m2eclipse.sonatype.org/update/

Leeres Projekt mit Maven anlegen

Ich starte mit einem neuen Eclipse-Workspace und lege ein neues Maven-Projekt an. Dabei wähle ich als Artifact-ID den Typ maven-archetype-quickstart aus.

Als Group-ID habe ich hier cc.raupach gewählt und die Artifact-ID ist batch1. Dieser Archetyp erzeugt eine ganz einfache Projektstruktur mit Source- und Test-Verzeichnis mit JAR-Packaging. Zusätzlich lege ich noch den Source-Folder src/main/resources an. Hier kommt später die eigentliche Spring-Batch Konfiguration hinein. Der Verzeichnisbaum sollte dann in etwa so aussehen:

POM anpassen und Dependencies aktualisieren

Als nächsten Schritt muß das POM von Maven angepasst werden. Dabei füge ich hier die Bibliotheken Spring-Batch 2.0.3 und Commons-Lang 2.1 hinzu.

Mein POM-File sieht dann so aus:

<project xmlns="http://maven.apache.org/POM/4.0.0" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
	xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/maven-v4_0_0.xsd">
	<modelVersion>4.0.0</modelVersion>
	<groupId>cc.raupach</groupId>
	<artifactId>batch1</artifactId>
	<version>0.0.1-SNAPSHOT</version>
	<name>batch1</name>
	<url>http://maven.apache.org</url>
	<packaging>jar</packaging>

	<dependencies>
		<dependency>
			<groupId>junit</groupId>
			<artifactId>junit</artifactId>
			<version>4.7</version>
			<scope>test</scope>
		</dependency>
		<dependency>
			<groupId>org.springframework.batch</groupId>
			<artifactId>spring-batch-core</artifactId>
			<version>2.0.3.RELEASE</version>
			<type>jar</type>
			<scope>compile</scope>
		</dependency>
		<dependency>
			<groupId>commons-lang</groupId>
			<artifactId>commons-lang</artifactId>
			<version>2.1</version>
		</dependency>
	</dependencies>
</project>

Den STEP anlegen

Jetzt kan der eigentlich Step angelegt werden, der später den Text “Hallo München” ausgibt. Die von Maven angelegt Klasse App.java kann nun gelöscht werden. Sie wird für dieses Projekt nicht benötigt, da Spring-Batch einen eigenen Command-Line-Runner mitbringt, der über ein main verfügt.

Ich habe die neue Klasse für den Step einfach mal TuNix.java genannt. Hier ist sie:

package cc.raupach.batch1;

import org.springframework.batch.core.StepContribution;
import org.springframework.batch.core.scope.context.ChunkContext;
import org.springframework.batch.core.step.tasklet.Tasklet;
import org.springframework.batch.repeat.RepeatStatus;

public class TuNix implements Tasklet
{

   public RepeatStatus execute(StepContribution arg0, ChunkContext arg1) throws Exception
   {
      System.out.println("Hallo München.");
      return RepeatStatus.FINISHED;
   }
}

Der Name stimmt nicht ganz, wie man sieht tut die Klasse natürlich schon etwas. Sie gibt ja den Text aus. Die Klasse implementier hier das Intaface Tasklet mit der Methode execute. Ein Tasklet ist vergleichbar mit einer einfachen Prozedur, die aufgerufen wird. Also ohne eigentliche Datenverarbeitung in Form von Items.

Spring-Batch konfigurieren

Nun geht es weiter mit der eigentlichen Konfiguration von Spring-Batch, in der alles zusammengefügt wird. Wie immer bei Spring ist es wieder eine XML-Datei. Der Name ist beliebig und ich habe sie hier einfach mal hello-spring-batch.xml genannt und in src/main/resources abgelegt:

<?xml version="1.0" encoding="UTF-8"?>
<beans:beans xmlns="http://www.springframework.org/schema/batch"
     xmlns:beans="http://www.springframework.org/schema/beans"
     xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
     xsi:schemaLocation="

http://www.springframework.org/schema/beans

http://www.springframework.org/schema/beans/spring-beans-2.0.xsd

http://www.springframework.org/schema/batch

http://www.springframework.org/schema/batch/spring-batch-2.0.xsd">

	<!-- Transaktions-Manager -->
	<beans:bean id="transactionManager"
      class="org.springframework.batch.support.transaction.ResourcelessTransactionManager"/>

	<!-- Memory-Repository -->
	<beans:bean id="jobRepository"
      class="org.springframework.batch.core.repository.support.MapJobRepositoryFactoryBean">
		<beans:property name="transactionManager"
           ref="transactionManager"/>
	</beans:bean>

	<!-- JobLaunscher -->
	<beans:bean id="jobLauncher"
       class="org.springframework.batch.core.launch.support.SimpleJobLauncher">
		<beans:property name="jobRepository"
           ref="jobRepository" />
	</beans:bean>

	<!--  Job -->
	<job id="mySampleJob" job-repository="jobRepository">
		<step id="mySampleStep">
			<tasklet ref="myTuNixTasklet" />
		</step>
	</job>

	<!-- Step -->
	<beans:bean id="myTuNixTasklet" class="cc.raupach.batch1.TuNix"/>

</beans:beans>

Für die Spring-Batch Konfiguration werden hier die folgenen Teile benötigt:

• Job-Repository (Zeile 15-20): In diesem Fall handelt es sich um eine Memory-Repository. Das bedeutet, der Zustand der einzelnen Jobs geht nacht dem beenden der Anwendung wieder verloren.
• Transaktions-Manager (Zeile 11-13): Hier auch nur der Default-Transaktionsmanager, da ja hier keine echten Transaktionen existieren.
• Job-Launcher (Zeile 22-27): Der Job-Launcher versorgt den Job mit zusätzlichen Parametern
• Der Job (Zeile 29-34): Er besteht in diesem Fall nur aus einem einzigen Step
• Der Step (Zeile 36-37): Hier wird die Klasse TuNix konfiguriert, die den Text ausgibt.

Eine Eclipse Run-Configuration anlegen

Jetzt muß noch Eclipse so konfiguriertwerden, dass Spring-Batch richtig gestartet werden kann. Dazu lege ich eine neue Run-Config in Eclipse an. Wichtig dabei ist, dass die main aus Spring-Batch kommt, nämlich diese:

org.springframework.batch.core.launch.support.CommandLineJobRunner

Zusätzlich wichtig ist nun noch den CommandLineJobRunner von Spring mit den richtigen Parametern zu versorgen. Diese kann man auf dem Reiter “Arguments” in der Run-Config eintragen. Der CommandLineJobRunner benötigt als ersten Parameter den Namen der XML-Config, also in diesem Fall hello-spring-batch.xml und als zweiten Parametern den Namen des Jobs, der gestartet werden soll. Das ist hier der Name mySampleJob. So es dann aus:

Nach dem Start sieht man folgenen Output in der Console. Es hat funktioniert: