Cellule transversale Architecture d'entreprise

VERSION POUR ACCORD

Cellule transversale Architecture d'Entreprise Environnement d'excution des Batchs ?

Demande d'avis
Rfrence du document Type de document Status crit par Revu par Diffusion Contact Version 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 Description Version initiale Rvision Rvision

Version Nr 0.9 du 8/04/2009

CELLULE_TRANS-ARCHI-DmdAvis-Batch-2009xxxx Document de rponse POUR ACCORD Lilian Duchne (LDU) Carine D'Hamers (CDH), Oliver Schneider (OSC), ric Nolmans (ENO), Stphane Tongres (STT), Anne Noseda (ANO) Carine D'Hamers (DEV) / Oliver Schneider (EXPL) Lilian Duchne (02 / 800.11.30) crit par LDU LDU LDU LDU LDU LDU LDU LDU LDU OSC CDH OSC Revu par STT, ENO ANO Date 29/01/09 10/02/09 13/02/09 27/02/09 09/03/09 11/03/09 23/03/09 26/03/09 08/04/09

Ajout de la table des dcisions prendre Ajout d'actions suite l'accord de CDH Ajout action n0 pour Cellule transversale architecture Rvision de la conclusion Ajout section Cot de la solution Modifications suite aux remarques d'OSC : Re-formulation de la Dcision n1 Modification de ASAP en ' planifier' Ajout Section 'Cas concrets'

Rsum court
la question Sur quel environnement d'excution devons-nous faire tourner les Batchs ? , il a t dmontr qu'uniquement deux environnements suffisent l'ensemble des besoins fonctionnels et techniques de l'ETNIC. Il s'agit : D'un environnement Batch pour temps rel : Celui-ci recevra les demandes directement des applications qui veulent fonctionner en asynchrone. Le traitement de ces demandes se fera sur base d'une charge disponible ou sur base horaire (Scheduler). D'un environnement Batch pour temps diffr : Celui-ci fonctionnera toujours pour de gros volume de donnes et sera contrl par un Scheduler. L'avantage de ces deux environnements est d'avoir d'un ct une solution qui rponde aux besoins d'un fonctionnement la demande entre le monde temps rel (par exemple application web) et le monde batch et de l'autre une solution qui rponde aux besoins du temps diffr dtach et indpendant du temps rel. Avec ces deux solutions l'ETNIC gagnera en cohrence et pourra construire sur cette base des solutions gnriques telles qu'un serveur d'impression ou un gnrateur de batch la demande qui pourront tre intgrs dans toutes les applications.

CELLULE_TRANS-ARCHI-DmdAvisBatch2009xxxx

Version : 0.9 / Mise jour le :08/04/2009

Cre le : 29/01/2009

Page 1/18

Cellule transversale Architecture d'entreprise

VERSION POUR ACCORD

DCISIONS PRENDRE
N 1 QUI DEV / EXPL QUOI Donner son accord sur le lancement d'un environnement Batch pour temps rel dans l'architecture d'entreprise.
Si 1 accorde alors dcisions prendre ci-dessous

'1.1

DEV / EXPL

Donner son accord pour que l'environnement Batch pour temps rel soit constitut des composants existants suivants: plateforme de notification, ESB, EGL, Scheduler...
Si 1.1 accorde alors dcisions prendre ci-dessous

'1.1.1 DEV / EXPL

Donner son accord pour que le nouveau scheduler (march Scheduler gr par JC Mertens) contrle des batchs pour temps rel

DEV

Donner son accord pour que le langage utilis pour crer les batchs soit uniquement EGL.

PROPOSITION DE LISTE D'ACTIONS

N 0 1 2 3 4 5 6 7 8 QUI (si accord sur la liste ci-dessus alors voici une proposition de liste d'actions) ACTIONS QUAND planifier planifier Aprs choix solution Scheduler planifier planifier CELLTRANS Analyser les possibilits de convergence entre les environnements d'excution. DEV DEV/EXPL EXPL EXPL EXPL DEV EXPL EXPL Dfinir les standards de dveloppement dans le cadre d'un batch en EGL Choisir le langage de script pour l'environnement de batch pour temps rel lorsqu'il est contrl par un Scheduler. Dfinir les procdures de mise en opration des batchs pour temps rel. Mise en place d'un environnement de batch pour temps rel

Intgrer les contraintes d'un environnement de batch pour temps rel Avant lancement dans le march Scheduler. march Scheduler Analyser les batch en Php, Python et Perl pour les r-crire en EGL Intgrer la problmatique des scripts et des formations pour les batchs pour temps rel dans le march Scheduler. Intgrer la problmatique des scripts et des formations pour les batchs pour temps diffr dans le march Scheduler. planifier Avant lancement march Scheduler Avant lancement march Scheduler

CELLULE_TRANS-ARCHI-DmdAvisBatch2009xxxx

Version : 0.9 / Mise jour le :08/04/2009

Cre le : 29/01/2009

Page 2/18

Cellule transversale Architecture d'entreprise

VERSION POUR ACCORD

Demande d'avis Environnements d'excution des Batchs

Table des matires

DCISIONS PRENDRE.........................................................................................................................................2 PROPOSITION DE LISTE D'ACTIONS.....................................................................................................................2 OBJECTIFS DU DOCUMENT...................................................................................................................................4 GLOSSAIRE .............................................................................................................................................................4 INTRODUCTION ......................................................................................................................................................5 DFINITION DE BATCH .....................................................................................................................................5 TRAITEMENT PAR LOTS....................................................................................................................................5 TRAITEMENT SQUENTIEL...............................................................................................................................6 TRAITEMENT PARALLLE..................................................................................................................................6 GESTION DES BATCHS OU SCHEDULER.............................................................................................................7 CONTEXTE D'UTILISATION.....................................................................................................................................8 POINTS DE VUE SCHEDULER...........................................................................................................................8 POINTS DE VUE STABILIT...............................................................................................................................8 POINTS DE VUE ARCHITECTURE.....................................................................................................................8 POINTS DE VUE SCURIT...............................................................................................................................9 POINTS DE VUE ENVIRONNEMENTS D'EXCUTION......................................................................................9 POINTS DE VUE PERFORMANCES...................................................................................................................9 CONCLUSIONS DU CHAPITRE........................................................................................................................10 BESOINS FONCTIONNELS CF / ETNIC................................................................................................................10 ENVIRONNEMENTS D'EXCUTION......................................................................................................................11 ENVIRONNEMENT BATCH POUR TEMPS REL............................................................................................11 SOLUTION TECHNIQUE AUX BATCHS PROCESSING..............................................................................11 SOLUTION TECHNIQUE AUX BATCHS QUEUING.....................................................................................12 ENVIRONNEMENT BATCH POUR TEMPS DIFFR......................................................................................13 RPONSE LA QUESTION ET CONCLUSION....................................................................................................14 COTS DE FONCTIONNEMENT DE LA SOLUTION.............................................................................................15 ENVIRONNEMENT BATCH POUR TEMPS REL............................................................................................15 ENVIRONNEMENT BATCH POUR TEMPS DIFFR......................................................................................15 CAS CONCRETS....................................................................................................................................................16 QUESTIONS POSES LORS DE L'ANALYSE.......................................................................................................17 BIBLIOGRAPHIE.....................................................................................................................................................18

CELLULE_TRANS-ARCHI-DmdAvisBatch2009xxxx

Version : 0.9 / Mise jour le :08/04/2009

Cre le : 29/01/2009

Page 3/18

Cellule transversale Architecture d'entreprise

VERSION POUR ACCORD

OBJECTIFS DU DOCUMENT
L'objectif du document est de fournir une rponse claire et prcise la question :

Sur quel environnement d'excution devons-nous faire tourner les Batch ?

GLOSSAIRE
Nom Services Prsentation Description Les services Prsentation grent l'interactivit avec les utilisateurs. Ils ont la responsabilit de toute la dfinition de l'ergonomie de travail de l'utilisateur et de son accessibilit aux crans. Les services Scurit protgent les accs aux diffrents services de l'architecture. Ceux-ci identifient l'utilisateur par l'intermdiaire de services d'authentification et l'autorisent suivant les permissions qui lui sont attribus. Ils communiquent l'ensemble des autorisations - associs des contextes d'utilisation organisationnels et/ou gographiques - chacun des business appels afin qu'ils ralisent une autorisation d'accs aux donnes. Les services de mdiation grent les changes d'information entre le monde extrieur et les services Mtier. Ils interviennent galement dans les changes d'information entre les services Mtier Les services de notification grent l'ensemble des notifications de cette architecture entre les services Prsentation et tous les services Mtier. C'est dire qu'ils grent tous les abonnements des sujets (topics) et les publications / notifications aux diffrents intervenants. Ces services sont une des solutions la mise en place d'une communication asynchrone entre services Mtier Les services Mtier sont les moteurs d'excution des rgles appliquer dans un des contextes Mtier de la CF. Ils contiennent tous les algorithmes spcifiques au traitement de l'information dans ce contexte. S'ils doivent faire appel d'autres services Mtier alors ils ont l'obligation de passer par les services de mdiation. Les services transversaux fournissent des services gnriques ne ncessitant aucune modification pour rpondre aux besoins des autres services de l'architecture. Les services Processus assurent l'excution des workflow Entreprise. C'est dire les processus entre les utilisateurs et les autres services condition que ces processus ne soient pas spcifiques un mtier (sauf exception1) Les services Donnes vont fournir une vue abstraite des donnes persistes. Ils ont la responsabilit d'accder aux diffrents systmes de persistence de manire fiable et optimale. Leurs avantages sont de fournir toujours les mmes services d'accs quelque soit le systme de persistence cible. Si une modification de base de donnes doit tre ralise, aucune modification dans les services Mtier ne devra tre effectue puisque l'impact ne sera dtect que dans les services Donnes.

Services Scurit

Services de mdiation

Services de notification

Services Mtier

Services Transversaux

Services Processus

Services Donnes

Pour plus d'explication sur les notions de Services telle que dfinies dans le Glossaire, veuillez vous rfrer au document Architecture Globale

Une exception pourrait tre par exemple la demande d'un service Mtier pour des raisons techniques ou de ressource.

CELLULE_TRANS-ARCHI-DmdAvisBatch2009xxxx

Version : 0.9 / Mise jour le :08/04/2009

Cre le : 29/01/2009

Page 4/18

Cellule transversale Architecture d'entreprise

VERSION POUR ACCORD

INTRODUCTION
La question a t pose lors de la dernire runion sur la dfinition des standards de dveloppement l'ETNIC. Pour rpondre cette question, il faut tout d'abord tre sr de la bonne comprhension de ce qu'est un batch et ensuite tudier quand et comment il faut l'utiliser. L'approche pourrait paratre inhabituelle tant donn que les besoins fonctionnels sont tudis en dernier lieu. Ici elle se justifie par une volont de ne pas rinventer la roue et de considrer que l'utilisation de batch est connue depuis longtemps et donc qu'il y a lieu de regarder l'existant au travers de l'exprience des spcialistes dans ce domaine. Proposition de structure du document : 1. Dfinition de Batch 2. Gestion des Batchs 3. Contexte d'utilisations des Batch 4. Besoins fonctionnels de l'ETNIC 5. Environnements d'excution des Batchs 6. Conclusion

DFINITION DE BATCH
Un Batch est un enchanement automatique de commandes sans intervention d'un oprateur (humain). Au regard d'internet et des diffrents dictionnaires de l'Informatique, il existerait trois notions de Batch: 1. Batch processing : traitement par lots, 2. Batch queuing : traitement squentiel, 3. Batch parallel (//) : traitement parallle. Pour la dfinition de chacun des points ci-dessous, les notations suivantes ont t utilises: {} : dsigne un ensemble. Par exemple A = {a} signifie que A est un ensemble compos de l'lment 'a'. : indique est lment de . Par exemple a A signifie 'a' est lment de l'ensemble 'A'. # : indique nombre d'lments d'un ensemble . Par exemple #A=1 signifie que le nombre d'lments de l'ensemble 'A' est 1. + : indique la mise en parallle de 2 batchs * : indique la mise en srie (l'un aprs l'autre) de 2 batchs.

TRAITEMENT PAR LOTS

Le principe du traitement par lots est d'excuter une action - ou quelques actions cohrentes sur tout un ensemble de donnes la fois. Voici un schma reprsentatif du fonctionnement par lots :

Considrons E comme un ensemble de donnes traiter de 'n' lments et T comme un ensemble d'actions de une et une seule action. Cette dernire s'appliquera sur l'entiret de E. L'excution de ce batch (batch processing) consistera rcuperer l'ensemble E et excuter T sur E. Ce type de batch sera reprsent dans la suite du document par ce symbole :

BP
CELLULE_TRANS-ARCHI-DmdAvisBatch2009xxxx
Version : 0.9 / Mise jour le :08/04/2009 Cre le : 29/01/2009 Page 5/18

Cellule transversale Architecture d'entreprise

VERSION POUR ACCORD

TRAITEMENT SQUENTIEL
Le principe du traitement squentiel est d'excuter un ensemble d'actions sur une donne la fois. Voici un schma reprsentatif du fonctionnement squentiel :

Considrons E comme un ensemble de donnes traiter de 'n' lments et T comme un ensemble de plusieurs actions. Ces dernires s'appliqueront sur un et un seul lment de E la fois. L'excution de ce batch (batch queuing) consistera prendre un lment de E et excuter T sur cet lment. Excuter ce batch une seule fois n'impactera qu'un seul lment de l'ensemble E. Pour impacter la totalit de E il faut obligatoirement excuter n fois le batch (avec n = #E). Ce type de batch sera reprsent dans la suite du document par ce symbole :

BQ
TRAITEMENT PARALLLE
Le principe du traitement parallle est d'excuter un (petit) ensemble d'action sur plusieurs (petits) ensembles de donnes en mme temps. Voici un schma reprsentatif du fonctionnement parallle :

Considrons E comme un ensemble de donnes (peut-tre vu comme une agrgation d'ensembles) traiter de 'n' lments et T comme des ensembles de plusieurs actions. Ces dernires s'appliqueront sur un et un seul sous-ensemble de E chaque fois. L'excution de ce batch (batch parallel) consistera lancer des BP en parallle sur des sous-ensemble de E. Ce type de batch sera reprsent dans la suite du document par ce symbole :

B//
CELLULE_TRANS-ARCHI-DmdAvisBatch2009xxxx
Version : 0.9 / Mise jour le :08/04/2009 Cre le : 29/01/2009 Page 6/18

Cellule transversale Architecture d'entreprise

VERSION POUR ACCORD

GESTION DES BATCHS OU SCHEDULER

Un scheduler (batch scheduler ou job scheduler) est un outil qui lance un batch - BP, BQ ou B// - sur base d'une condition ou plusieurs conditions. Celles-ci peuvent-tre sur base horaire, vnementielle ou les deux. Par abus de langage, le mot 'Scheduler' est employ pour dsigner un outils de gestion de batchs. Un outil de base de gestion de batchs a pour objectif de : monitorer l'activit des batchs; monitorer la performance des batchs; crer un rapport d'activit globale du scheduler; afficher la liste des vnements reus; faciliter l'administration et la dfinition des batchs ou chane de batchs (dpendance, priorit ...) Certains produits tendent leurs objectifs en donnant la possibilit de : grer les rpartitions de charge. Par exemple en travaillant non plus sur une heure prcise mais sur des fourchettes (fentre) de temps d'excution (au plus tard, au plus tt). Intercepter les erreurs. notifier des erreurs. grer les erreurs (action/raction sur erreur). Rejeu et recovery des vnements en cas d'erreur ou de panne du scheduler (capacit tre stateful , mmoriser les tats). Aujourd'hui trois types de fonctionnalits existent : 1. en traitement par lots : il s'agit d'un mode qui lance des batchs sur une base horaire ou une priode. 2. orient sur des vnements : il s'agit la diffrence du prcdent d'un mode qui lance les batchs sur base d'un ou plusieurs vnements extrieurs. 3. orient sur des services : il s'agit de permettre la rutilisation des services (webservices dans la plupart des cas) d'une architecture IT. Tous les produits srieux de scheduling l'heure actuelle offrent au moins les deux premires fonctionnalits. La troisime se retrouve sur des produits comme : CA 7 Workload Automation ou IBM Tivoli Workload Scheduler. Ces produits ont la particularit d'tre multiplateformes. Certains produits comme OpenSource-JobScheduler intgre les trois fonctionnalits condition que les traitements se fassent uniquement sur des environnements Microsoft, Linux ou Unix. La manire de dfinir au minimum un batch dans les 3 outils tels que dfinis ci-dessus est de configurer : un job principal : cette partie reprend les conditions pour que le systme lance le batch. Ici, suivant les produits, on indique galement qui doit tre notifi sur un succs de l'excution et/ou sur un chec. une chane de dfinition du batch : cette chane reprend les dpendances entre les programmes excuter. Cette dpendance peut tre marque pour une condition de succs de l'excution du programme mais galement sur une erreur (code) retourne par le programme. les programmes excuter : ils peuvent tre des excutables classiques mais galement des procdures stockes excutes dans des DB's telles que DB2 ou MySQL. Pour information l'environnement de Scheduling install sur le mainframe IBM z10 l'ETNIC permet les fonctionnalits 1 et 2 limites des appels ou vnements locaux. Cet environnement est compos des produits suivants : CA-7 TM : CA 7 Workload Automation CA-11 TM : CA 11 Workload Automation Restart and Tracking CA-Dispatch TM : CA Dispatch Output Management

CELLULE_TRANS-ARCHI-DmdAvisBatch2009xxxx

Version : 0.9 / Mise jour le :08/04/2009

Cre le : 29/01/2009

Page 7/18

Cellule transversale Architecture d'entreprise

VERSION POUR ACCORD

CONTEXTE D'UTILISATION
Ce chapitre va permettre de fournir une vue sur les caractristiques techniques des diffrents types de batch en rapport des besoins techniques. Les diffrents points de vue sont exprims en terme de facilit implmenter le besoin technique. C'est dire qu'un point de vue exprim par - - signifie qu'il est trs difficile raliser avec les langages, les outils d'administration, etc tels que prvu l'ETNIC. Si des solutions alternatives via des produits ou des modifications existent alors des remarques dans les sous-chapitres prciseront l'orientation prendre. La pertinence de prendre en compte ces remarques ou non n'est pas indiqu dans ce chapitre.

POINTS DE VUE SCHEDULER

Besoins techniques
Type de Scheduler utiliser Recovery sur {} Recovery sur 1 lt Rejeu sur {} Rejeu sur 1 lt Replannification

BP
Par lots ++ -++ -++

BQ
vnementiel / Services ++ + ++ ++

B//
Services + -+ -++

Remarque : Le besoin Recovery sur {} exprime l'ide de pouvoir relancer l'ensemble des traitements. Le - pour BQ indique uniquement que cette fonctionnalit n'est pas de base au niveau du Scheduler.En effet cette fonctionnalit peut tre ralise par programmation en tenant jour un historique des programmes excuts.

POINTS DE VUE STABILIT

Besoins techniques
viter les deadlock Diminuer le record locking

BP
++ -

BQ
+ ++

B//
+

Remarques : Le - de BP au niveau de la diminution du record locking, tient compte du fait que l'objectif mme du BP est de travailler sur l'ensemble complet des donnes. De ce fait le - prcise plus la dpendance la base de donnes et donc au manque de flexibilit rpondre ce besoin. Le + au lieu de ++ de BQ sur viter deadlock indique que l'analyse doit prvoir ce besoin avant de raliser les programmes.

POINTS DE VUE ARCHITECTURE

Besoins techniques
Debug sur 1 lt Transactionnel sur {} Transactionnel sur 1 lment // interactif et batch Partage de services Rutiliser des services existants Partage de CPU Partage de mmoire Multi-CPU

BP
-++ --++ + ou - ++ ---

BQ
++ -++ ++ ++ ++ -++ ++

B//
---+ + + +

CELLULE_TRANS-ARCHI-DmdAvisBatch2009xxxx

Version : 0.9 / Mise jour le :08/04/2009

Cre le : 29/01/2009

Page 8/18

Cellule transversale Architecture d'entreprise

VERSION POUR ACCORD

Remarques : Le ++ de BP dans Transactionnel sur {} doit tre vu dans les limites des possibilits de la DB. Le - - de BQ ne prend pas les possibilits de la technique de compensation. Le besoin // interactif et batch exprime l'ide de faire coexister le lancement de batch en mme temps que l'interactif sur la mme DB dans les limites d'une cohrence fonctionnelle. Le besoin Partage de services exprime l'ide qu'un batch puisse exposer des services. Le + ou - - de BP dans Rutiliser des services existants tient compte du fait de la spcificit de BP de devoir travailler sur un ensemble complet. Ce qui signifie que les services existants doivent tre prvus pour travailler sur un ensemble. Si les services le prvoient alors la cotation est + sinon - car trs grosse perte de performances.

POINTS DE VUE SCURIT

Besoins techniques
Contrle d'accs / utilisateur Contrle d'accs aux donnes (primtre)

BP
---

BQ
++ ++

B//
---

Remarques : Les contrles d'accs sont fournis par utilisateur donc incompatibles dans le cadre d'un BP ou d'un B// puisqu'ils sont prvus pour fonctionner hors contexte utilisateur (principe de la vue d'ensemble).

POINTS DE VUE EXCUTION

Besoins techniques
Serveur VMWARE / (Java-Cobol) Mainframe / Cobol Serveur / (Java-Cobol) Base de donnes

BP
+ ou (si trs gros batch) ++ ++ ++

BQ
++ -++ --

B//
+ --

Remarques : Le - - de BQ dans Mainframe / cobol indique qu'il est fortement dconseill d'utiliser cette technologie sur mainframe puisqu'elle a pour but de s'appuyer sur le CPU pour un fonctionnement optimal. Type d'infrastructure conseille dans le cas d'excution de batch sur serveurs VMWARE : Caractristiques du serveur : 4 CPU quadcore SERVEUR PHYSIQUE plusieurs Go de mmoire. VM WARE 1 Caractristiques des vmwares : Le serveur physique est identique celui ci-dessus; VM WARE 2 VMWARE 0 vmware 1 3 ne reoivent qu'un CPU quadcore avec peu de mmoire et sont en priorit basse; VM WARE 3 vmware0 reoit l'ensemble de la mmoire avec un CPU quadcore et est en priorit haute.

POINTS DE VUE PERFORMANCES

Besoins techniques
Utilisation optimale du CPU Utilisation optimale de la mmoire Capacit fournir un rsultat sur une donne d'un ensemble Capacit fournir un rsultat sur un ensemble CELLULE_TRANS-ARCHI-DmdAvisBatch2009xxxx

BP
-++ -++

BQ
++ -++ --

B//
+ + +

Version : 0.9 / Mise jour le :08/04/2009

Cre le : 29/01/2009

Page 9/18

Cellule transversale Architecture d'entreprise

VERSION POUR ACCORD

CONCLUSIONS DU CHAPITRE
la vue des rsultats ci-dessus nous constatons que chaque type de batchs rpond des besoins spcifiques. Ceux-ci pourraient s'exprimer de la manire suivante : 1. La possibilit de travailler directement sur un ensemble de donnes sans subir les perturbations du monde extrieur. La rapidit fournir une rponse suite un traitement sur un seul lment ou synchroniser avec le monde interactif n'a pas d'importance. 2. La possibilit de traiter de trs gros volumes. 3. La possibilit de pouvoir rejouer l'entiret des traitements. 4. La possibilit de travailler avec des traitements parallles de types diffrents. Le monde interactif et le monde batch devrait tre capable de travailler ensemble. 5. La possibilit de pouvoir rejouer un traitement spcifique. 6. La possibilit de pouvoir rutiliser un service existant. L'aspect performance (dure du traitement) n'a pas d'importance. 7. La possibilit (l'obligation) de pouvoir rutiliser les donnes de scurit de l'utilisateur (aspect dlgation de traitement). Les batchs par traitement par lots sont plus aptes rpondre en terme de solution aux points 1,2 et 3. Par contre les batchs squentiels sont plus appropris pour les points 4,5,6 et 7. Les batchs parallles doivent tre vus comme un compromis BP et BQ o la rponse un besoin spcifique d'accs des DB de types diffrents. Conseils : Les connexions locales une DB seront toujours plus performantes que les connexions distance. De ce fait le traitement de trs gros batch ayant une exigence forte sur la performance est conseill sur le mme environnement local que DB2.

BESOINS FONCTIONNELS CF / ETNIC

Les besoins fonctionnels ont t exprims par les documents de Jean-Paul Thilemans et Philippe Dejaer. 1. Communication asynchrone Nous sommes ici dans un cas purement vnementiel donc la rponse ce besoin est du BQ. 2. Lancement la demande de requtes par un utilisateur final Hypothse 1 : impossibilit de cadrer le volume de donnes car les droits sont sur l'ensemble du domaine fonctionnel. Ici la probabilit est grande de devoir traiter un gros volume de donnes donc la rponse ce besoin est du BP. Hypothse 2 : Limitation dans le primtre d'accs aux donnes. Ici si le volume de donnes reste sous contrle et faible, la rponse ce besoin est du BQ sinon du BP. 3. Lancement la demande d'impression (courrier, rapport journalier d'activit ) par un utilisateur final Le volume de donnes est faible puisqu'un seul vnement li un profil utilisateur donc la rponse ce besoin est du BQ. Lancement la demande d'impression de masse par un utilisateur final Le volume de donnes est trs lv (par exemple fiches de paie, courrier aux citoyens ) donc la rponse ce besoin est du BP. L'vnement sera envoy un Scheduler. Lancement de batch par dlgation de droit La rponse ce besoin a dj t voque aux points 2 et 3. La diffrence est la livraison du dlivrable qui sera dirige vers l'utilisateur final. Les droits prendre en compte lors de l'excution sont ceux de cet utilisateur final. Une analyse doit tre faite pour tudier les aspects de scurit. Si celle-ci identifie une contrainte forte en scurit alors du BQ est conseill. Lancement de batch par un Scheduler La rponse ce besoin est du BP avec la contrainte suivante : Pr-condition l'utilisation d'un scheduler : Travailler sur des chanes batch uniquement si traitement trs lourd et/ou si devant tourner en dcal par rapport l'interactif. Synchroniser des DB / Backups / Jobs du Datawarehouse. Ici la probabilit est grande de devoir traiter un gros volume donc la rponse ce besoin est du BP.
Version : 0.9 / Mise jour le :08/04/2009 Cre le : 29/01/2009 Page 10/18

4.

5.

6.

7.

CELLULE_TRANS-ARCHI-DmdAvisBatch2009xxxx

Cellule transversale Architecture d'entreprise

VERSION POUR ACCORD

8.

Accs plusieurs DB de types diffrents. L'accs des bases de donnes diffrentes pour un mme type de traitement est la raison d'tre des B// donc il est normal qu'ils soient la rponse ce besoin.

ENVIRONNEMENTS D'EXCUTION
Ce chapitre a pour objectif de dfinir le meilleur environnement d'excution par rapport aux rponses des besoins fonctionnels du chapitre prcdent. Deux environnements d'excution des batchs sont ncessaires pour rpondre aux besoins fonctionnels : un environnement batch compatible avec le temps rel (interactif) et un environnement batch en temps diffr contrl par un Scheduler.

ENVIRONNEMENT BATCH POUR TEMPS REL

La solution pour rpondre la compatibilit d'excution du monde temps rel avec le monde batch doit s'appuyer sur le service de notification 2 de l'architecture globale. Solution technique aux Batchs Processing La solution technique la plus apte rpondre dans ce cadre aux besoins de BP est la suivante :

Schma 1: Diagramme de communication: Batch pour temps rel - BP

Le scnario est le suivant : 1. L'utilisateur confirme sa demande de lancement d'un batch via une application web; 2. Celle-ci est transfre au service notification sur un sujet (topic) attribu au Scheduler; 3. Le Scheduler est notifi de la demande; 4. Il gre la notification comme un vnement dclencheur. Ds que sa fentre d'excution commencera il pourra lancer le batch; 5. Le programme lanc par le batch (ou chane batch) enverra sa rponse au service notification ; 6. Le service notification transfre la rponse au systme eBAL3. Ce transfert s'appuie sur une donne de type 'Rpondre ' transmise au point 2 par l'application appelante. Cette donne indique qui le service notification doit rpondre. 7. Le systme eBAL notifie l'utilisateur que sa rponse est arrive. 8. L'utilisateur tlcharge la rponse en se connectant eBAL. L'avantage d'utiliser comme indiqu au point 6 la donne de type 'Rpondre ' signifie que la rponse peut tre envoye d'autre systme. Comme par exemple la GED ou encore une autre application via son service mtier . Pour ce dernier exemple le service de mdiation devra intervenir. Afin de mieux comprendre voici un schma explicatif :

Pour plus d'information sur le service notification de l'ETNIC, cfr le document Architecture globale . Un rsum est disponible au chapitre glossaire 3 Pour plus d'information sur le systme e-BAL du service transversal de l'ETNIC, cfr le document Architecture globale
2

CELLULE_TRANS-ARCHI-DmdAvisBatch2009xxxx

Version : 0.9 / Mise jour le :08/04/2009

Cre le : 29/01/2009

Page 11/18

Cellule transversale Architecture d'entreprise

VERSION POUR ACCORD

Solution technique aux Batchs Queuing La solution technique la plus apte rpondre dans ce cadre aux besoins de BQ est la suivante :

Schma 2: Diagramme de communication: Batch pour temps rel - BQ

L'exemple de scnario ci-dessus met en scne les besoins fonctionnel d'un utilisateur d'imprimer des courriers. Bien entendu le serveur d'impression est optionnel puisque e-BAL peut transformer un message XML en cran de type web. Ce scnario est comme suit : 1. Un utilisateur confirme une demande de lancement d'impression (gnration d'un pdf par exemple) via une application web; 2. Celle-ci est transfre au service notification sur un sujet (topic) attribu la demande; 3. Le service de mdiation est notifi de la demande; 4. Il gre la notification comme un vnement dclencheur. Il lance une orchestration qui dans notre exemple pourrait appeler le service Scurit pour de plus amples informations sur l'utilisateur puis ensuite un ou plusieurs services Mtier; 5. Les services mtier retournent leurs rponses afin de complter la demande; 6. la fin du processus le systme d'impression reoit la demande complte; 7. Ici l'exemple consiste en l'impression d'un simple courrier dont la gnration du fichier pdf prend quelques secondes. Le systme d'impression retourne le fichier en rponse; 8. Le service de mdiation transmet la rponse au service notification ; 9. Le service notification transfre la rponse au systme eBAL4. Ce transfert s'appuie sur une donne de type 'Rpondre ' transmise au point 2 par l'application appelante. Cette donne indique qui le service notification doit rpondre. 10. Le systme eBAL notifie l'utilisateur que sa rponse est arrive. 11. L'utilisateur tlcharge la rponse en se connectant eBAL.

Pour plus d'information sur le systme e-BAL du service transversal de l'ETNIC, cfr le document Architecture globale

CELLULE_TRANS-ARCHI-DmdAvisBatch2009xxxx

Version : 0.9 / Mise jour le :08/04/2009

Cre le : 29/01/2009

Page 12/18

Cellule transversale Architecture d'entreprise

VERSION POUR ACCORD

ENVIRONNEMENT BATCH POUR TEMPS DIFFR

La solution pour rpondre la compatibilit d'excution du monde temps diffr avec le monde batch doit s'appuyer uniquement sur le Scheduler. De ce fait uniquement les BP et B// sont intressants dans ce contexte. Les BQ n'interviennent pas dans cet environnement. La solution ci-dessous est base sur un Scheduler.

Schma 3: Diagramme de communication: Temps diffr

Le scnario est comme-suit : 1. Un oprateur configure une chane batch via la console d'administration. 2. Lorsque l'oprateur confirme la configuration, le scheduler mmorise les donnes. 3. Ds que les conditions sont respectes, le Scheduler dmarre le lancement du ou des batchs. 4. Suivant la dfinition de la chane le Scheduler excute le ou les programme(s). 5. Chaque programme lanc traite des donnes soit dans une DB soit sur un disque dur.

CELLULE_TRANS-ARCHI-DmdAvisBatch2009xxxx

Version : 0.9 / Mise jour le :08/04/2009

Cre le : 29/01/2009

Page 13/18

Cellule transversale Architecture d'entreprise

VERSION POUR ACCORD

RPONSE LA QUESTION ET CONCLUSION

la question Sur quel environnement d'excution devons-nous faire tourner les Batchs ? , il a t dmontr que seulement deux environnements suffisent l'ensemble des besoins fonctionnels et techniques de l'ETNIC. Il s'agit : D'un environnement Batch pour temps rel : Celui-ci recevra les demandes directement des applications qui veulent fonctionner en asynchrone. Le traitement de ces demandes se fera sur base d'une charge disponible ou sur base horaire (Scheduler). Et d'un environnement Batch pour temps diffr : Celui-ci fonctionnera toujours pour de gros volume de donnes et sera contrl par un Scheduler. L'avantage de ces deux environnements est d'avoir d'un ct une solution qui rponde aux besoins d'un fonctionnement la demande entre le monde temps rel et le monde batch et de l'autre une solution qui rponde aux besoins en temps diffr dtach et indpendant de tout temps rel. Avec ces deux solutions l'ETNIC gagnera en cohrence et pourra construire sur cette base des solutions gnriques telles qu'un serveur d'impression ou un gnrateur de batch la demande. En effet l'architecture actuelle est prvue uniquement en synchrone par rapport aux utilisateurs ou uniquement en temps diffr. Elle ne permet pas aux applications dites temps rel de fonctionner en asynchrone par rapport leurs utilisateurs. Ceci a pour effet de crer une charge en dents de scie sur les environnements, d forte dpendance des applications par rapport au nombre d'utilisateurs connects, alors qu'en fonctionnant en asynchrone (avec un mode la demande) la charge pourra tre lisse plus naturellement . Un gain de charge pourra ainsi tre gagn sur les environnements web et backend. Vu de l'utilisateur les applications paratront beaucoup plus fluide car l'application web ne sera jamais ralentie (ou en attente) cause d'une surcharge du back-end. Un autre avantage du fonctionnement la demande est sa capacit identifier plus facilement les composants transversaux. Puisque le fonctionnement asynchrone se dconnecte de tout contexte mtier, il est beaucoup plus facile de se concentrer sur les aspects gnriques. De ce fait des besoins en serveur d'impression ou en gnrateur de batch la demande deviennent tout fait ralisable. Toutefois l'ergonomie des applications web devra tre pense par rapport un fonctionnement asynchrone. Il s'agit du principal inconvnient des environnements en temps rel. L'utilisateur n'aura pas instantanment son rsultat, il faut donc l'habituer l'accepter. Pour raliser ces deux environnements des lments existants peuvent tre r-utiliser. Le service de mdiation , le service de notification , Cerbre, l'architecture des applications EGL sont des lments dj oprationnels et r-utilisables sans aucune modification pour raliser un environnement Batch pour temps rel. L'analyse en plus de rpondre la question a galement permis d'identifier un gros manque en monitoring du ct des applications. Ce point devra donc tre analyser en profondeur. Concernant l'environnement Batch pour temps diffr, le tout nouveau mainframe pourrait tre une premire rponse. En effet il rpond trs bien de grosses charges de BP en tant qu'hardware mais n'est utilisable que pour des programmes dvelopps sous Cobol (hormis la DB). Du fait des limitations de ce langage de nombreuses limitations techniques l'empchent de le prendre en compte comme solution technique convenable aux besoins des systmes ouverts . Ces limitations peuvent tre leves uniquement par un investissement soit dans l'ouverture des programmes Cobol vers les systmes ouverts soit dans l'intgration de certaines parties des systmes ouverts dans le mainframe soit dans une tude approfondie d'une utilisation commune ESBEGL/Cobol via CICS.

CELLULE_TRANS-ARCHI-DmdAvisBatch2009xxxx

Version : 0.9 / Mise jour le :08/04/2009

Cre le : 29/01/2009

Page 14/18

Cellule transversale Architecture d'entreprise

VERSION POUR ACCORD

COTS DE FONCTIONNEMENT DE LA SOLUTION

ENVIRONNEMENT BATCH POUR TEMPS REL
La mise en place de l'environnement Batch pour temps rel rutilise les composants et/ou standards de l'architecture globale ETNIC suivants : Services de notification : La plateforme de notification sera utilise pour le fonctionnement asynchrone; Services de mdiation : L'ESB ETNIC / CF (si besoin) sera utilis pour le dcouplage entre applications; XML / webservice : pour la communication avec les applications temps rel ; Services de donnes : Bases de donnes DB2, MS SQLServer, MySQL ... existantes.

L'lment obligatoire qu'il faut implmenter pour avoir un fonctionnement minimal tel que dcrit dans ce document est: Serveurs Linux sous VMWare : 1 serveur Linux sous VMWare dans un premier temps est ncessaire. L'lment ncessaire qu'il faudrait implmenter pour avoir un fonctionnement complet tel que dcrit dans ce document est: Scheduler : 1 scheduler compatible monde ouvert permettra de rpartir la charge sur un base temporelle et non vnementielle ( la demande ). Les besoins en administration pour grer cet environnement sont : 1 administrateur systme : pour la gestion VMWare et Linux 1 administrateur applicatif : pour intervenir sur la configuration des scripts administratifs, du monitoring, des jobs, les logs, les plateformes ESB/Notification ... 1 oprateur Scheduling : pour la configuration des batchs. 1 administrateur rseau : pour la surveillance du fonctionnement rseau (bande passante, cblage ...) Le cot initial sera calcul sur base de la mise en place d'un serveur sous Linux VMWare et d'un Scheduler. Ce cot n'est pas possible aujourd'hui valuer car il dpend du march Scheduling . Le cot de fonctionnement (ou rcurrent) sera calcul sur base du temps d'administration de cette solution. Le temps d'administration sera comme suit sur base de : Hypothses : 5 nouveaux batchs configurer par mois 30 batchs excuts en moyenne par jour 1 serveur Linux sous VMWare monitor Estimations du cotl : Administration systme : 1h au total par mois. Administration applicatif : suivi monitoring : 1h au total tous les deux jours. configuration / dploiement / test / documentation des programmes :1h par nouveau batch. Scheduling (dpendra du produit) : suivi monitoring : 1h au total tous les deux jours. configuration / dploiement / test / documentation :1h par nouveau batch. Administration rseau : suivi monitoring : 1h au total par semaine. Le temps d'administration par mois est de 36h. En tenant compte d'un tarif horaire pour un AP de 68 (source : contrat de gestion, page 44), le cot de la solution pour un an est de 29.376 (36h*12m*68)

ENVIRONNEMENT BATCH POUR TEMPS DIFFR

Aucun besoin en ressources hardware et humaines n'est identifi pour la mise en place de cet environnement car il existe dj. Le calcul du cot de fonctionnement tel que dcrit dans ce document est dj connu du dpartement Exploitation car il est identique ce qui existe actuellement.
CELLULE_TRANS-ARCHI-DmdAvisBatch2009xxxx
Version : 0.9 / Mise jour le :08/04/2009 Cre le : 29/01/2009 Page 15/18

Cellule transversale Architecture d'entreprise

VERSION POUR ACCORD

Les investissements effectuer tel que dcrit dans la conclusion seront valus dans le document Demande d'avis-Convergence des environnement d'excution des Batchs ? .

CAS CONCRETS
Cette solution Batch pour temps rel se place au niveau des composants transversaux dans l'architecture d'Entreprise donc potentiellement l'ensemble des projets de l'ETNIC pourrait tre concerns et devront tenir compte de cette solution. Toutefois afin d'aider comprendre l'intert de la solution vis vis des projets de l'ETNIC voici une liste non exhaustives de ceux qui utiliseront ce nouvel environnement : Subsides ADEPS pour la gnration des rapports Cadastre de l'emploi pour la gnration des rapports (solution existante qui sera modifie) PPT pour la gnration des rapports (solution existante qui sera modifie) CIOC pour la gnration des rapports et de la synchronisation entre Cerbre et Mimsis FADI pour le traitement des actions des utilisateurs (dveloppement en cours prvus pour fin 2009) SIEL pour les batchs Php convertir SIEL-PROECO pour les batchs Php convertir OBSI pour les batchs Php convertir PRIMVER pour les batchs Php convertir ONSS (prvue fin 2009) pour la communication avec ONSS-DMFA les nouvelles applications de GIEI qui seront dveloppes en 2010 ( long ou moyen terme) Alfresco ( moyen terme) Datawarehouse

CELLULE_TRANS-ARCHI-DmdAvisBatch2009xxxx

Version : 0.9 / Mise jour le :08/04/2009

Cre le : 29/01/2009

Page 16/18

Cellule transversale Architecture d'entreprise

VERSION POUR ACCORD

QUESTIONS POSES LORS DE L'ANALYSE

Lors de l'analyse, des questions hors contextes mais pertinentes ont t poses. En voici la liste : Quel langage faudrait-il utiliser pour dvelopper les programmes batchs ? : cette question la rponse est simple, c'est EGL. Pourquoi? Tout simplement parce qu'il est le seul langage aujourd'hui l'ETNIC capable de gnrer des programmes pour des serveurs (en Java) et pour le mainframe (en Cobol). Du fait que l'EGL est un langage de programmation dpendant de la plateforme d'excution le programmeur EGL devra respecter les bonnes pratiques de programmation pour toujours garder la compatibilit en Cobol. Avec EGL l'ETNIC gagnera en flexibilit au niveau de son architecture. En effet si des batchs viennent ne plus tre compatibles avec le temps rel alors ils seront dplacs facilement dans l'autre environnement. D'autres solutions sont possibles mais tudier plus en profondeur. Faut-il un gros serveur pour des batchs en temps diffr ? : seuls des besoins fonctionnels ou techniques pourront y rpondre. l'ETNIC aujourd'hui de trs nombreux petits serveurs font tourner des batchs dans plusieurs langages. Leur raison d'tre se justifie uniquement comme solution technique au B//. Dans un premier temps une tude devrait tre ralise pour essayer de dplacer et de rassembler ces programmes sur un seul et mme serveur afin de garder une cohrence ne serait-ce qu'au niveau du Scheduler. Ensuite il faudra les rpartir et donc prendre en compte la rcriture pour certains s'ils ne sont pas en EGL- entre les deux environnements Batch pour temps rel et diffr. partir de ce moment et uniquement ce moment, le besoin d'un gros serveur apparatra (si ncessaire). Bien entendu les besoins de certains projets comme GIEI devront tre anticips. Comment rpondre aux besoins de 24/7 de certains programmes temps rel alors que nous avons des besoins de temps diffr ? : en effet des besoins ct temps rel demandent une disponibilit de la DB sur mainframe en 24/7 alors que pour d'autres programmes (la paie par exemple) exigent des ressources qui imposent un isolement du mainframe par rapport au temps rel. D'un point de vue 'Architecture' il n'y a pas qu'une seule rponse simple. Dans le pire des cas il faut raliser une copie de la DB pour que le monde temps rel puisse toujours fonctionner ( condition que les donnes ne soient pas utilises par les batchs du temps diffr). Dans le meilleur des cas l'environnement Batch pour temps rel suffira rsoudre le problme. Seule une analyse de l'existant et du nouveau besoin en 24/7 permettra de trouver une et une seule rponse technique au problme. Faut-il un et un seul Scheduler pour grer ces deux environnements : L'idal serait effectivement d'en avoir qu'un seul mais en plus du prix d'un tel produit qui est dj un problme, le risque est d'ouvrir la porte usine gaz . En effet un tel produit permettrait par exemple de pouvoir lancer l'excution de programmes quel que soit son environnement d'excution. Le risque dans un tel contexte d'arriver des dpendances tellement fortes entre environnements et programmes au point qu'une modification devienne impossible, est trs grand. La solution la plus raisonnable est d'avoir un mme produit Scheduler qui puissent tre dploy sur chacun des environnements. Ainsi le jour o des programmes doivent passer de l'un l'autre les rgles d'excution peuvent galement suivre. Faut-il rellement un Scheduler pour l'environnement Batch pour temps rel ? : Effectivement des solutions bases sur des moteurs de rgles (BRMS) lis un ESB sont possibles et mme conseilles dans certains cas puisqu'elles augmentent la rutilisation des rgles d'entreprise et amliorent galement la flexibilit de l'architecture globale. Seulement cette solution ne rpond pas tous les besoins donc dans tous les cas il en faut quand mme un pour cet environnement.

CELLULE_TRANS-ARCHI-DmdAvisBatch2009xxxx

Version : 0.9 / Mise jour le :08/04/2009

Cre le : 29/01/2009

Page 17/18

Cellule transversale Architecture d'entreprise

VERSION POUR ACCORD

BIBLIOGRAPHIE
Cadre belge d'interoprabilit (BELGIF) : http://www.belgif.be Scheduler - OpenSource-JobScheduler : http://jobscheduler.sourceforge.net/ Scheduler IBM Tivoli Workload Scheduler : http://www-01.ibm.com/software/tivoli/products/scheduler/ Scheduler - CA 7 Workload Automation : http://www.ca.com/fr/products/product.aspx?id=1171 CA 11 Workload Automation Restart and Tracking http://www.ca.com/fr/products/product.aspx?id=1169 CA Dispatch Output Management http://www.ca.com/fr/products/product.aspx?id=1250 The Shorcut GuideTM to IT Workload Automation and Job Scheduling http://nexus.realtimepublishers.com/SGITWAJS.htm

CELLULE_TRANS-ARCHI-DmdAvisBatch2009xxxx

Version : 0.9 / Mise jour le :08/04/2009

Cre le : 29/01/2009

Page 18/18