Insérer un code personnalisé dans un job Talend avec tJava

Dans cet article, nous allons voir comment insérer du code java dans un job Talend afin d’étendre ses fonctionnalités. Talend open studio est une plate-forme d’intégration de données, basée sur le langage java. C’est un outil qui permet de répondre à toutes les problématiques liées au traitement de données : ETL (Extraction, Traitement et chargement de données), EAI (Echange de données Inter-Application) et synchronisation de données. L’avantage des solutions talend réside dans leur facilité de prise en main, leur souplesse, leur flexibilité et un excellent résultat graphique des jobs grâce aux interfaces des composants.

Spring : la validation simplifiée avec Spring. Démos pratiques.

Ce post a pour objectif de vous faire découvrir les nouveautés de Spring bean validation capable dorénavant de supporter les  JSR 303 & 349. En exemple, nous verrons comment réaliser des tests unitaires et des tests d'intégration (où le validator est injecté par spring) et nous rédigerons des tests d'intégration dans lesquels nous abuserons des nouvelles annotations de spring-boot. A titre d'exemple, nous verrons également comment employer les annotations @RunWith(SpringRunner.class) et @SpringBootTest.

Java 8: Collections, Stream et opérations IO par l’exemple. Déboguer les streams

 

Ce billet aborde par la pratique le nouveau design pattern de gestion des collections en java 8 : Stream.

En java 8, le design iterator est abandonné au profit d'une meilleure conception basée sur le Stream.

Nous pouvons dire brièvement, qu'en java 8, la programmation impérative est remplacée par la programmation déclarative (penser au langage  SQL).

Les exemples démos choisis sont des opérations sur les répertoires et fichiers avec des assertions sur le nombre de lignes et sur les contenus de ces fichiers.

Nous donnons aussi une manière de déboguer les streams.

Voici les ingrédients utilisés dans ce blog: Java 8, Stream, l'api AsssertJ pour le test Junit.

Pratiquons le Design Pattern Delegate (ou Façade) : Démos avancées

 

Le design pattern delegate ( ou façade ) est un pattern très utilisé et facile à expliquer.

Deux démos, une simple et une seconde très avancée, vous permettent de pratiquer sereinement ce design sans difficulté.

Ainsi, les ingrédients de ce blog sont divisés en deux parties:

  • La première partie, contenant une démo simple, n'exige aucun prérequis (mis à part un peu de java 8).
  • La seconde partie, contenant une démo très avancée, nécessite de connaître un peu spring-batch et en particulier son FlatFileItemReader (retrouvez un article sur le sujet ici).

Spring-Batch (Part III) : Comment lire ou parser efficacement divers fichiers CSV avec RecordSeparatorPolicy?

 

L'objet de ce billet est de vous présenter les "best-practices" afin de lire les divers de formats de fichiers csv du simple à l'exotique.

Le reader de spring-batch doit être configuré (et uniquement si possible 🙂 ) pour gérer des formats particuliers de fichiers csv.

La démarche reste identique pour les autres formats de fichiers.

Comme il est difficile de traiter tous les cas pour un blog, la démo ci-après se focalise sur ce fichier csv:

Spring-Batch (Part II): Validation and Skip Policy. Ou comment gérer les données non valides dans un batch?

Après la première partie sur les tests unitaires du reader de Spring-Batch, nous passons à la validation des données input.
Ce second volet exige un minimum de connaissances sur spring & spring-batch.

Nous tentons de relever plusieurs défis majeurs correspondants aux attentes en production:

  • identifier avec précision le numéro de la ligne invalide (non traitée par le batch lancé la veille),
  • générer un rapport exploitable du déroulement du batch (exécutée la nuit),
  • porter en base les erreurs rencontrées en traçant correctement leurs causes exactes,

Nous nous posons la question de la validation des lignes lues par le Reader et aussi comment définir une politique d'éviction (skip) de ces lignes non valides.

En franglais, c'est la question validate & skip policy dans les batchs.

Ce sont deux notions bien distinctes mais fort bien liées.

Spring-Batch (Part I) : Tester unitairement & mocker simplement. FlatFileItemReader

 

 

 

 

Comment tester unitairement et simplement les trois composants principaux de Spring-Batch: Reader, Processor, Writer?

Plus précisément comment mocker le(s) contexte(s) spring-batch pour ces trois composants?

Ce billet, sur plusieurs parties, présente quelques démos pratiques permettant de réaliser ce genre de tests unitaires (et d'intégration en prime).

Les démos sont réalisées en combinant le duo de spring: spring-batch et spring-boot.
Ce duo simplifie grandement (voire à outrance) la configuration de spring et laisse en arrière-plan beaucoup trop de complexité.

La première démo permet de réaliser un projet spring-batch avec un job contenant un seul step, le tout configuré avec java (no xml).

L'unique (step du) job consiste à charger en base (BD) les lignes d'un fichier csv nommé entreprises.csv.

Nul besoin à ce stade de processor!

Ainsi, notre job contient uniquement les composants nécessaires: un reader et un writer.

A la fin de cette première partie, nous écrirons un test TU Junit du reader.

Le seul intérêt de tester unitairement le(s) reader(s) est lorsque le métier exige un traitement personnalisé ce qui est généralement le cas! 🙁

Une fois le test TU posé et automatisé, le(s) refactoring(s) et les évolutions (agilité oblige) deviennent des opérations plus sûres.