La Taverne d'Arma

Spring Batch est un framework Java qui a pour objectif de donner aux développements de batch Java un vrai cadre, avec son architecture et ses outils dédiées. Spring Batch s’appuie sur le framework Spring et son mécanisme d’injection de dépendance (et donc son conteneur léger).

Concrètement, ça fonctionne comment ?

Spring Batch permet de définir des Job (un batch dans son ensemble), euh même décomposer en Step. Les steps correspondent aux différentes étapes de traitements d’un batch.

Par défaut les tâches suivent l’organisation suivantes :

• Un reader : indique comment les données doivent être lus et accéder

• Un ou plusieurs procésseurs : chaque processeur effectue un traitement particulier sur les données. Pour chaque ligne lu par le reader, les processeurs vont être appellées un à un.

• Un writer : indique comment les données vont être restitué (fichier, base de données, …).

Il est binesur toutefois possible de définir des tâches qui ne répondront pas à ce schéma.

Pour faciliter l’élaboration du batch, SpringBatch fournit des classes utilisables tels quels ou dérivable. Il fournit également un mécanisme de gestion de transaction (et de gestions des commits intermédiaires).

SpringBatch permet également de gérer le déroulement des Steps (quels steps appellés quand, dans quels conditions, …), de gérer une relance automatique des steps suites à échec, ou même la parallellisation de Step.

Un petit exemple ?

J’ai réalisé il y a peu un petit batch d’archivage Java. Ce batch est très simple et est constitué d’un seul step avec reader / writer.

Définition du batch

Le début du paramétrage se passe coté Spring. Je vous passe la définition du datasource, du transaction manager, et du jdbc template qui sont des objets Spring standard (de simple bean instancié et que l’on retrouve dans quasiment tout projet utilisant Spring).

Une fois ces trois objets disponible, je vais crée un repository (qui contiendra les jobs et leurs exécutions) et un launcher (pour permettre l’exécution du batch). Je rajoute donc dans mon fichiers Spring :

<!– 3/ Depot des jobs Spring Batch –>

<bean id=“jobRepository”class=“org.springframework.batch.core.repository.support.MapJobRepositoryFactoryBean”>

<property name=“transactionManager” ref=“transactionManager”/>

</bean>

<!– 4/ Lancement des jobs –>

<bean id=“jobLauncher” class=“org.springframework.batch.core.launch.support.SimpleJobLauncher”>

<property name=“jobRepository” ref=“jobRepository”/>

</bean>

Vous pourrez constater que j’initialise les Beans sans vraiment faire de spécifique. Le job launcher est un launcher simple : il faut donc l’appeller par code Java pour lancer l’archivage.

Je définit ensuite mon batch et ses steps :

<!– 5/ Définition du batch d’archivage –>

<batch:job id=“archivage” job-repository=“jobRepository”>

<batch:step id=“archiveLog”>

<batch:tasklet transaction-manager=“transactionManager” >

<batch:chunk reader=“logReader” writer=“logWriter” commit-interval=“500″/>

</batch:tasklet>

</batch:step>

</batch:job>

Voyons un peu ces quelques lignes.

1. Je crée un job nommé « archivage»

2. Je crée un step nommé «archiveLog»

3. Je définit le step comme étant transactionnel, et je référence le reader (logReader) et le writer (logWriter).

4. J’indique également un commit-interval : le batch va travailler par lot de 500 lignes.

Le Reader et le Writer vont également être des beans référencés dans Spring.

Le Reader

La définition que j’utilise pour le Reader est la suivante :

<!– Declaration des beans d’archivage pour la table de Log –>

<bean id=“logReader” class=“org.springframework.batch.item.database.JdbcCursorItemReader”>

<property name=“dataSource” ref=“dataSource” />

<property name=“sql” value=“SELECT IOL_NOM_FICHIER, IOL_DAT_HEURE, IOL_COD_TRAITEMENT, IOL_COD_ETAPE, IOL_NIV_INFO, IOL_LIB_MESSAGE FROM T_IO_LOG_IOL WHERE IOL_DAT_HEURE &lt; SYSDATE – 7 “/>

<property name=“rowMapper” ref=“logMapper” />

</bean>

Vous pourrez remarquer que j’utilise directement un objet fourni par Spring : JdbcCursorItemReader. Celui ci prend en paramètre ma base de donnée, une requête SQL a executer, et un rowMapper indiquant dans quels objets stockés les lignes. Rien de bien compliqué donc. Le row mapper est le suivant :

@Component(“logMapper”)

public class LogMapper implements RowMapper<DTOLog> {

@Override

public DTOLog mapRow(ResultSet rs, int rowNum) throws SQLException {

DTOLog dto = new DTOLog();

dto.setNomFichier(rs.getString(LogEnum.FILENAME.getPosition()));

dto.setDatHeure(rs.getDate(LogEnum.DAT_HEURE.getPosition()));

dto.setEtape(rs.getString(LogEnum.COD_ETAPE.getPosition()));

dto.setMessage(rs.getString(LogEnum.LIB_MESSAGE.getPosition()));

dto.setNiveauInfo(rs.getString(LogEnum.NIV_INFO.getPosition()));

dto.setTraitement(rs.getString(LogEnum.COD_TRAITEMENT.getPosition()));

return dto;

}

}

Rien de bien compliqué ici, inutile que je vous l’expliquer : la seul particularité est l’implémentation de l’interface RowMapper fourni par SpringBatch. Il y a également l’annotation @Component qui m’évite de rajouter une ligne dans mon fichier xml pour déclarer le batch.

Le Writer

Implémenter le Writer signifie implémenter l’interface ItemWriter. J’obtient donc la classe suivante :

@Component(“logWriter”)

public class LogWriter implements ItemWriter<DTOLog> {

@Autowired

private DataSource dataSource;

@Override

public void write(List<? extends DTOLog> listItems) throws Exception {

Connection dbConnection = dataSource.getConnection();

try {

for (DTOLog item : listItems) {

insertDataArchive(dbConnection, item);

deleteOriginData(dbConnection, item);

}

} catch (Exception e) {

throw e;

} finally {

dbConnection.close();

}

}

}

Je vous passe le détail des deux fonctions qui sont juste des requêtes JDBC. Encore une fois, rien de compliqué. Vous remarquerez que l’on travaille ici avec des listes d’objets. Le contenu de ces listes dépends du commit-interval : dans mon cas j’aurai donc des blocs de 500 lignes.

En Conclusion

Jusqu’à maintenant, le Batch était un peu la parent pauvre de Java : on réalisait tout from Scratch, avec des solutions très manuels et très « coding». Chaque batch était donc totalement différent : passer d’une application à une autre vous faisait perdre tous vos repères.

Spring Batch offre ici un cadre propre, bien pensée, et donne en plus nombre d’outils qui diminue la quantité de code nécessaire. Certes, la configuration Spring Batch devient vite verbeuse avec un fichier XML qui va grossir, toutefois ce fichier est simple et facile à générer. Vous pourrez également le spliter en différent fichier (1 par batch ? ) pour plus de clareté.

Les Batchs réalisées avec Spring Batch sont solide, facilement paramétrable, et offre de nombreuses fonctionnalités (paralléllisation, enchainement, …) qui sont normalement rébarbative à implémenter. La montée en compétence est en réalité un peu dure : peu d’exemple ou de tutorial. Par contre une fois les concept saisies, s’est un vrai plaisir

Le Lyon JUG (Java User Group) était présenté par Alexis Moussine-Pouchkine, membre d oracle, et Julien Ponge, professeur a l‘INSA. Ce Lyon JUG avait pour but de présenter la nouvelle version de Java : Java 7.

Globalement java 7 est une petite version de java : ajoutant principalement de la cosmétique ayant pour but de faciliter le travail des développeurs et d’améliorer la lisibilité.

Il y a toutefois deux réelles évolutions amené dans le langage.

· L api filesystem a été refondu pour offrir plus de fonctionnalité et de faciliter. Il sera possible de manipuler directement le filesystem : parcours comme un arbre, copie, surveillance d’événements tels que la modification d un fichier ou son arrive. Toutefois les fonctionnalités avance de cette api ne sont pas 100% portable et ne fonctionneront pas, par exemple, sur Windows.
· Java 7 offre également une nouvelle api de gestion du multithread : l envoi des threads est alors laissées a l api qui optimise en fonction du nombre de cœur présent.

Dans les évolutions mineures, il y a quelques ajouts sympathiques :

· Try catch avec ressources : facilite la gestion des ouvertures et fermeture de ressources.
· Try catch multiple : permet d gérer plusieurs exception dans un seul block catch
· String utilisable tel quel dans les Switch
· Lors de l’instanciation d’une Collection, il ne sera plus nécessaire de repréciser le type présent dans la définition. Ex : List a = new List<>() ;

La JVM voit également l’apparition d’un type « InvokeDynamic » (typage dynamique) destiné à faciliter l’exécution des langages dynamiques dans la JVM.

Nous avons également eu quelques infos sur le développement de Java 8. La communauté Java travaille actuellement à intégrer certaines fonctionnalités présentes dans la jvm Rockit : suppression de la zone permgen, nouveau outils de monitoring de la jvm, …

Un projet de modularisation de la JRE est actuellement en cours. L’objectif est de crée une JRE plus lite qui pourra ensuite est compléter par des modules complémentaires (module JDBC, module JMX, …).

De son coté, le JCP est également en cours d’évolution : l’objectif est d’accélérer la structure de décision autour de Java et de son évolution.

Alors que la version 3.7 vient tout juste de sortir, la fondation nous fait la surprise de publier une “Early Release” de la version 4.0 ! Que nous réserve donc cette version majeure ?

Un thème graphique retravaillé

Un gros travail a été réalisé sur l’interface graphique dont le moteur a été visiblement refondu ! Les élements restent classiques (vue, workspace, perspective) mais eclipse bénéficie maintenant d’un réèl thème graphique coloré et assez joli.

Le positionnement des élements dans l’interface a été retravaillé pour le rendre toujours plus flexible ! Il est nottament possible de faire passer n’importe quelque vue comme une fenetre dans l’éditeur, ou d’avoir plusieurs éditeurs en parallèle.

Le menu principale devient également “variable” en fonction de l’endroit où l’on se trouve. On retrouve nottament certain menu tels que “Source” ou “Réfactor” qui avant ne se trouvait que sous le click droit.

Un champs “Rechercher”

L’interface se dote également d’un champs Rechercher. Ce champs permet de chercher parmis les vues, les perspectives, les configurations, et un peu tous les autres élements d’Eclipse). Pas révolutionnaire mais assez pratique.

Une application allegée

Un point qui nous fera plaisir à tous, l’application connait une net diminution des ressources consommées ! En temps normal, le Heap Space de l’appli tourne autour de 50M (contre 100M pour Eclipse 3.6).

Une mécanique retravaillé

Il y a également quelques modifications “interne” à l’outils qui, pour l’instant, vont être beaucoup moins visible. Globalement le moteur de fonctionnement a été refondu pour être plus propre et plus découplé.

Etant donné que je n’ai jamais encore développé de plugin Eclipse, je ne rentrerai pas dans le détail sur ces points.

Eclipse annonce également une meilleur intégration de certains outils tels que Maven. Je n’ai toutefois pas encore pu le constater.

Une application pas encore prêt à la prod !

Attention également, nous somme en Early Release. Autrement dit l’application n’est pas “stable”. Eclipse en lui même marche très bien, mais un grand nombre de plugin ne fonctionne pas encore.