Archives du mot-clé batch

« Make or Buy » sur les plateformes d’intégration : un modèle de choix

Ce billet a pour objectif de proposer un modèle de choix pour répondre aux problématiques de « Make or Buy » rencontrées lors des phases de conception d’une plateforme d’intégration, en entreprise, à savoir choisir une solution outillée du marché – qu’elle soit dans le « cloud » , open source ou non – ou bien choisir de bâtir une solution spécifique, et sur-mesure.

Cette notion de plateforme d’intégration est à rapprocher de la notion d’iPaaS[1] très en vogue actuellement, mais pour un usage interne à l’entreprise. Nous parlerons davantage de retours d’expériences que des aspects académiques, néanmoins nous donnerons une définition de plateforme d’intégration qui correspond au métier d’architecte d’enioka.

I) Plateforme d’intégration : kesako ?

Qu’est-ce qu’une plateforme d’intégration ?

Une plateforme d’intégration est un middleware, c’est à dire un logiciel d’infrastructure fournissant des fonctions d’intégration aux applications du SI, et dont la valeur ajoutée pour le SI est d’abstraire et de réduire la complexité liée aux chaînes de liaison techniques des échanges inter-applicatifs, en proposant des solutions « clés en main » pour les principaux cas d’intégration.

Le schéma ci-après illustre la position du middleware d’intégration dans l’architecture :

Quels sont les principales caractéristiques d’une plateforme d’intégration ?

Parmi les critères fondamentaux caractérisant un service middleware on retrouve toujours:

  • l’interopérabilité inter-applicative, notamment sur la connectivité proposée aux applications, avec notamment des connecteurs pour l’intégration (annuaires, bases de données, outils MFT[2]/MOM[3]…) et une API[4] de développement pour l’intégration des applications,
  • l’abstraction de l’hétérogénéité des infrastructures techniques sous-jacentes,
  • le passage à l’échelle par administration et paramétrage plus que par développement logiciel.

Quels sont les enjeux de maîtrise de la complexité du SI ?

Un service middleware d’intégration répond à plusieurs enjeux de maîtrise de la complexité des SI :

  • réduire les coûts et délais liés à l’intégration d’applications et formaliser des abaques,
  • proposer une architecture d’intégration homogène,
  • industrialiser la supervision et l’exploitation techniques de l’intégration,
  • fonder des modèles d’architecture et de service d’intégration « clés en main ».

 

 

II) Identification des critères pour un choix « Make or Buy »

Nous nous proposons de sélectionner les critères déterminants pour décider de l’implémentation d’une plateforme d’intégration par un produit du marché ou par un développement spécifique.

La maturité technique du SI client

La maturité technique du SI client est un critère majeur de décision.

Si la maturité est faible, faire le choix d’un développement spécifique serait risqué, l’accent est donc généralement mis sur le choix d’un produit du marché, et une intégration faible de celui-ci au SI pour limiter les impacts. Et si les besoins en évolution des fonctions d’intégration sont méconnus, il est préférable de mettre en œuvre un développement spécifique léger en forme de prototype permettant aux équipes IT d’identifier les premiers éléments de complexité, et de faire évoluer la solution d’intégration avec les besoins des applications au fur et à mesure de la croissance du SI.

A l’opposé, pour un SI dont la maturité est forte, le choix portera davantage sur un outil du marché avec une forte industrialisation de son intégration au SI, ou bien sur un développement spécifique avancé pour une intégration «sur mesure».

La vitesse d’évolution du SI est également un paramètre à prendre en considération au regard du cycle de vie d’un produit du marché (nouvelles versions, support fin de vie).  Par exemple, dans le cas d’un SI à évolution rapide – cas courant – un développement spécifique peut jouer un rôle de « joint de dilatation » entre les interfaces et les produits qui implémentent le service middleware et limiter les impacts de montée de version sur les applications du SI.

Le modèle technique de répartition

Le modèle technique de répartition est également l’une des clés de décision pour le choix. Une faible répartition correspond à un modèle client-serveur classique, avec une centralisation des fonctions d’intégration sur le serveur, et l’appel de ces fonctions par les clients. Une forte répartition correspond davantage à un modèle peer-to-peer qui permet à chaque client de disposer localement des fonctions d’intégration sans faire appel à un tiers sur le réseau.

Le modèle de répartition peut engendrer selon les produits du marché des coûts conséquents de licence (produits payants) et des coûts d’administration importants en cas de croissance rapide du SI.

La plupart des produits du marché proposent un modèle à faible répartition.

La complexité des chaînes d’intégration

Plus les chaînes d’intégration sont complexes (nombre d’étapes, nombre d’applications, topologie de la chaîne d’intégration, règles de gestion, hétérogénéité technologique, interactivité homme-machine, …) plus les contraintes sont fortes sur le service middleware. Rares sont les produits du marché capables de maîtriser de facto cette forte complexité tout en respectant les exigences de la Production. Il est souvent utile dans ce cas de fournir un développement spécifique qui implante du liant entre Intégration et Production.

Le choix d’un outil du marché – seul – ne permettra pas la flexibilité requise de bout en bout, et souvent l’intégration du « dernier kilomètre » est le maillon faible qui masque toute la valeur du middleware d’intégration. Par exemple, ce sujet est particulièrement visible lorsqu’il s’agit d’interfacer la chaîne d’intégration avec les outils de la Production (ordonnancement, supervision, …) et les différents outils métier, de bout en bout et de manière homogène!

Les compétences

Les compétences internes (ou externes) sont celles qui à moyen et long terme sont garantes, au quotidien, du maintien en condition opérationnelle du socle, et de l’accompagnement des projets jusqu’en production.

Dans ce contexte, le choix d’un développement spécifique est à proscrire si les équipes ne sont pas suffisamment formées pour le développement de services middleware complexes.

Par son positionnement dans l’architecture et dans les processus IT, un socle d’intégration est par nature à mi-chemin entre le monde des Etudes, et le monde de la Production. Afin de sécuriser l’avenir d’un développement spécifique, il est presque indispensable de recruter des compétences qui puissent comprendre ces deux mondes. Par exemple, une DSI qui ne dispose pas de ces compétences fera davantage le choix de l’achat d’un produit du marché.

A l’inverse, le choix d’un produit du marché peut nécessiter des compétences d’administration spécifiques, et donc des formations à prendre en compte lors de la contractualisation.

Les normes et standards des développements projets et de la Production

Les normes et standards des développements et d’infrastructure peuvent conditionner la décision. Il est nécessaire de contrôler que les normes en vigueur ne sont pas incompatibles avec la portabilité des développements sur le produit du marché et/ou sur son exploitation. En effet, il est fréquent dans un SI de voir tout un périmètre implémenté par un outil du marché qui ne respecte par les normes et standards définis en interne. Dans tous les cas, des exemples (ou templates) de développement respectant les normes et standards sont souvent les bienvenus pour montrer l’exemple aux équipes études.

La prise en charge de protocoles spécialisés

La prise en charge de protocoles spécialisés comme Odette FTP ou EDIFACT/EANCOM pour l’industrie, ou NOEMIE pour le secteur de la Santé, peut nécessiter le choix d’une solution du marché disposant du support intégré de ces protocoles. D’autant que l’implémentation de ces protocoles peut faire l’objet d’une certification par leur autorité de gestion ou tout simplement s’avérer coûteuse. A l’opposé, des protocoles standards et simples d’accès pour le développement logiciel comme FTP et HTTP/SOAP seront plus pertinent dans le cadre d’un développement « maison ».

Le modèle de coûts

Enfin, le critère coût restera déterminant pour le choix, avec un équilibre à trouver entre CAPEX et OPEX en fonction du budget. Il faut prendre en compte le cycle de vie « classique » d’un middleware d’intégration et projeter une vision d’architecture à 3-5 ans. Dans les deux cas, il y aura des postes de coûts en CAPEX et en OPEX.

Dans le choix « make », le CAPEX sera moindre la plupart du temps, parce que les coûts de licence des produits du marché sont encore importants pour ce type de service middleware, mais l’OPEX peut être en retour élevé (coût de maintenance logicielle). Néanmoins, dans le choix « buy », la problématique est la visibilité sur l’OPEX (coûts de maintenance et renouvellement de licences) dans une vision à 3-5 ans, ce qui n’est pas toujours simple en fonction du modèle de licence plus ou moins flou proposé par les éditeurs. Les solutions iPaaS dans le « cloud » peuvent à ce titre proposer une alternative avec un bon compromis, mais les offres restent encore un peu jeunes et ce choix pose de nouvelles questions en termes technique, fonctionnel, et financier.

 

III) Conclusion

En conclusion, bien que la notion de middleware ne soit pas nouvelle et que l’implantation de produits middleware dans les SI contemporains soit une pratique répandue de facto, le besoin d’adaptation et mise à niveau est toujours présent. Il n’y a pas de réponses à la complexité à travers un modèle unique de middleware. Les produits du marché ne satisfont pas toujours les contraintes et les exigences des entreprises et des organisations, qui doivent répondre à des problématiques techniques et humaines toujours plus ambitieuses. Et les solutions « cloud » qui se développent amènent de nouvelles solutions avec leurs contraintes spécifiques… Le choix est guidé en fonction d’échéances dans l’évolution du SI, de contraintes d’architecture, et de possibilité budgétaire de la DSI et de compétences.

[1] Integration Platform as a Service

[2] Monitored File Transfer

[3] Message Oriented Middleware

[4] Application Programming Interface

JQM : un serveur de batch asynchrones en Java

JQM (Job Queue Management) est un gestionnaire de batch sous licence Apache qui permet de traiter sur des noeuds de traitement répartis toutes les tâches potentiellement longues qui ne sont pas désirables dans un serveur d’application à travers un système de files de priorité. Ce logiciel s’adresse à toute application qui souhaite gérer l’exécution de ses tâches hors du serveur d’application.

Une tâche peut être déclenchée depuis un appel Web Service ou une API par une application web, un ordonnanceur ou un flux d’interface.

L’outil propose de nombreuses fonctionnalités comme l’arrêt d’une tâche, la récupération de fichiers générés, la priorisation d’une tâche et bien d’autres. JQM a été développé en Java SE 1.6, utilise Hibernate/JPA 2.0 comme ORM, et une base de donnée comme référentiel de configuration et file d’attente des traitements. JQM est compatible avec les bases HSQL, MySQL et Oracle, les serveurs d’application WebSphere et Glassfish (prochainement Tomcat) pour l’API cliente et gère les ressources JNDI pour les bases de données et les brokers de messages.

L’outil est compatible avec les projets Maven et tout particulièrement la gestion des dépendances et des projets parents.
Architecture

JQM est composé de trois grandes parties :

  • les moteurs de traitements (des JVM standalone) qui exécutent les tâches. Il est possible de déployer plusieurs moteurs (ou noeuds) de traitements pour des raisons de performance ou de haute disponibilité
  • une base de données qui joue le rôle de file de traitement et de référentiel de configuration
  • les clients (une application Web dans un serveur d’application, une ligne de commande, un ordonnanceur, un autre job JQM etc.) qui soumettent des jobs à JQM

Les noeuds de traitement sont reliés à des files de traitement en base de données et ont chacun un intervalle de polling et un nombre défini de jobs pouvant tourner simultanément.

Par exemple:

  • VIPqueue = 10 jobs simultanées + intervalle de polling de 1 seconde
  • SLOWqueue = 3 jobs en simultanés + intervalle de polling de 15 min
schema_jqm

Cycle de vie d’une tache

Le cycle de vie d’un job passe par quatre états différents.

Après avoir été ajoutée à la file d’attente, la tâche prend le status « SUBMITTED ». Une fois  que le job est « attrapé » par un noeud, son statut passe à l’état « ATTRIBUTED » suivi de  « RUNNING » une fois que l’exécution de celui-ci a commencé.

Le job à la fin de son execution a deux états possibles, « CRASHED » si le job n’a pas  fonctionné correctement ou « ENDED » si tout le processus s’est déroulé correctement.

cycle_of_life_JQM

 

Fonctionnalités 

Pour les développeurs
  • Pour les développeurs de traitement
Un job est défini comme tel une fois qu’il « extends » de la classe JobBase de l’API jqm-api. Au sein d’un job, il est possible de récupérer des ressources via JNDI (base de données, broker de message, répertoire de traitement…), d’envoyer une progression, un message de log ou de mettre en file un autre job.
  • Pour les clients des traitements

Il existe plusieurs moyens d’utiliser JQM.

– Par le biais de l’API jqm-clientapi qui permet d’avoir toutes les fonctionnalités existantes, à savoir la possibilité de mettre un job en file, de regarder son état, de l’annuler, de le changer de file et bien d’autres.
  • Par le biais d’un web service
  • Par une interface en ligne de commande
  • Par une IHM web (très frustre à l’heure actuelle)

Pour les administrateurs

Un administrateur à la possibilité de consulter les logs, de gérer les connexions JNDI, de paramétrer les associations entre les jobs et  les files.

Exemple de job

public class Caller extends JobBase
{
    @Override
    public void start()
    {
        Map<String, String> params = new HashMap<String, String>();
        p.put(“myParam1”, “Pouet”);
        p.put(“myParam2”, “Tut tut”);
        // enQueue is a JobBase method.
        // It is used to enqueue a Job, here “Called”.
        enQueue(“CalledJob”, “Bob”, null, null, null, null, null,
                 null, null, null, null, params);
        }
}
 

Exemple d’intégration de JQM dans un SI

Dans cet exemple, JQM est utilisé pour gérer une intégration au fil de l’eau de message dans un ERP qui ne possède qu’une interface d’entrée de type table / prodédure stockée.
JQM joue un rôle de « joint de dilatation » entre un système évènementiel qui gère des pics à 200 000 messages par heure et une interface de type procédure stockée qui traite des données en masse mais ne se prête pas à de nombreuses exécutions simultanées.
Chaque message est traité par un thread d’un conteneur MDB (Message Driven Bean) et déclenche un job JQM. La file de job JQM est paramétrée pour n’exécuter qu’un seul job à la fois et annuler les lancements surnuméraires. Le job lance la prodédure stockée de l’ERP qui traite toutes les données en attente dans la table d’interface.
En pic, plusieurs centaines de messages n’occasionneront qu’un ou deux lancement de la procédure stockée qui traitera en masse les données. Le système permet ainsi de rester très réactif en période creuse (au contraire des systèmes de type batch cyclique) tout en permettant la montée en charge lors des pics.

 

integration_jqm

Origine du projet

Le projet a été développé par la société enioka dans le cadre d’un projet pour l’un de ses clients pour l’intégration d’un ERP.
Suite à la réalisation de ce projet, il a été convenu que JQM deviendrait open source afin de combler le manque actuel de ce type d’outils libres dans un contexte java SE/EE 6.

Le code source et la documentation sont disponibles sur Github.