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.

Date Java8: Exemples de manipulation des dates en java 8

L'un des changements importants en java 8 est l'introduction de nouvelle Api (JSR 310) pour la gestion des dates.

La nouvelle api datetime introduite dans java 8 s'est inspirée de Joda-Time (cette dernière est très utilisée dans les projets).
Ceci dit, l'api java.time de java 8 est différente de Joda sur certains détails.

A ce propos, l'auteur de Joda-Time (Stephen Colebourne) a participé à la réalisation de la  JSR 310.

En effet, la pratique de l'api java.util.Date (donc pour les version java <8) a mis en évidence que son design est assez déroutant, voire peu intuitif, sur certains points:

  • les années des dates démarrent de 1900,
  • les jours commencent à 1, les mois à 0,
  • pas thread safe,
  • sans parler de la gestion du lenient.

La nouvelle api java date & time est donc guidée par ces trois axes:

  • domain driven design (voir site oracle pour plus de précisions),
  • immutabilité renforcée pour garantir thread safe,
  • séparation des calendriers et chronologies.

L'objet de ce blog est de vous donner quelques concepts avancés par des exemples sans rentrer dans la théorie.

Notez donc que ce billet n'est pas structuré comme une introduction à l'api java.time.

JBehave, BDD et test d’acceptation/acceptance: Démo pratique en 20 min

blog_jbehave_bdd_titre1  blog_jbehave_jira_titre1b blog_bdd_titre2

 

Nous nous intéressons dans ce billet à l'utilisation des tests d'acceptation et le concept BDD (Behaviour Driven Development) implémenté par le framework JBehave.

Nous le pratiquons au cas particulier d'une entreprise morale ayant plusieurs établissements souhaitant ajuster automatiquement l'effectif global en fonction du turn-over effectif dans ses divers établissements (simpliste pour que le billet reste accessible).

Notre démo traite le scénario suivant avec un langage (naturel) d'acceptation proche de celui de la maîtrise d'ouvrage (MOA).

Voici donc les étapes du scénario inspiré de mon article sur design pattern observer.

Introduction à Spring Integration

Cet article a pour objectif d’introduire Spring Integration. Dans un premier temps, j’y décrirai les différents concepts inhérents à Spring Integration, puis nous verrons un exemple basique d’intégration dans une application.

Spring integration est, comme son nom l’indique, un projet du framework Spring. Il respecte donc tous les principes de Spring dont voici les plus importants : la séparation des préoccupations (separation of concerns), l’injection de dépendances (dependency injection) ou le couplage lâche (loose coupling). En revanche, Spring Integration permet de pousser ces principes encore plus loin en permettant de faire communiquer facilement des beans Spring de manière asynchrone et indépendante via un système de messaging, sans qu’ils aient besoin de se connaître mutuellement.

De plus, Spring Integration fournit également des outils pour communiquer avec des systèmes externes (JMS, RabbitMQ, etc).

Spring Integration est une implémentation des Enterprise Integrations Patterns. Il est construit autour du modèle pipes-and-filters. Les pipes sont n’importe quel composant capable de transporter les messages alors que les filters sont ceux capables de produire ou consommer des messages.