1

Architecture Oriente
Services
Tout repose sur la mthode

tude de cas Prsentation de

lentreprise
Lentreprise concerne est un distributeur
dnergie (gaz et lectricit) dEurope de lOuest.
Ses clients sont soit des particuliers, soit des
entreprises, PME et grands comptes
Cette entreprise est ce quon appelle gnralement
un oprateur de rseau

tude de cas Prsentation de

lentreprise
Le mtier de cette entreprise est :
de grer et maintenir un rseau de distribution
de fluide sur son territoire de chalandise
dinstaller chez ses clients des Points De
Distribution (PDD) branchs sur son rseau
de facturer la consommation releve dans
chaque Point De Distribution

tude de cas Prsentation de

lentreprise
Jusqu prsent, cet oprateur distribuait lnergie
fournie par le monopole national de production
dnergie, dont il tait de facto une filiale. Son systme
dinformation tait donc intgr dans celui du
monopole, puisque ses clients taient exactement ceux
du monopole de production.

tude de cas Contexte mtier

Sous la pression des instances europennes, la
libralisation du march de lnergie est en route, et
notre oprateur de rseau doit souvrir des
producteurs alternatifs
Ces producteurs veulent distribuer leur nergie vers
leurs propres clients, via les points de distribution et le
rseau grs par loprateur. Ce rseau reprsente en
effet un investissement si considrable, quil nest pas
concevable que chaque producteur alternatif se dote de
son propre rseau de distribution

tude de cas Contexte mtier

Loprateur souhaite transformer cette contrainte
lgale en une opportunit commerciale : les
producteurs alternatifs deviennent en quelque sorte de
nouveaux clients, auxquels loprateur doit fournir des
services, payants, sur un pied dgalit avec lex
monopole national de production dnergie
Louverture la concurrence se fait progressivement :
dans un premier temps, les producteurs alternatifs sont
autoriss servir les clients professionnels. Dans un
second temps, la concurrence concerne galement les
clients particuliers.

tude de cas Objectif du projet

Loprateur souhaite mettre en place dans une premire
tape un portail destin aux producteurs. Ce portail
permet un producteur :
de demander un service loprateur, tel que la mise
en place dun nouveau Point De Distribution
la consultation des relevs de consommation associs
un PDD

tude de cas Objectif du projet

La mise en place du portail saccompagne de la mise en
place des processus back office de traitement de ces
demandes. Il sagit par exemple de planifier et lancer
les interventions des quipes techniques dintervention
sur les PDD. Pour cela la solution mtier sappuie sur
des applications existantes (planification des
interventions, gestion des comptes rendus
dintervention)

tude de cas Objectif du projet

Le premier objectif mtier est donc de permettre un
producteur dmettre manuellement ces demandes de
prestation via des formulaires proposs par le portail, et
de traiter ensuite ces demandes
Dans une seconde tape, il sagit de faire face
laccroissement prvisible des demandes de prestation,
accroissement li louverture aux particuliers.
Loprateur souhaite donc relier directement le systme
dinformation de chaque producteur son propre
systme dinformation

10

tude de cas Objectif du projet

Le deuxime objectif mtier du projet est donc que
chaque producteur envoie directement ses demandes
via un protocole spcifique du monde de lnergie (protocole standard bas sur XML)
Formul autrement : il sagit de mettre en place un
accs multicanal loffre de prestations de service de
loprateur de rseau

11

tude de cas Objectif du projet

Quel que soit le canal dacheminement de la demande
de prestation, loprateur souhaite ne pas multiplier ses
quipes commerciales : le troisime objectif mtier est
de rechercher une automatisation maximale des
processus de traitement des demandes de prestation
Le dernier objectif mtier est bien videmment
doptimiser les cots et encore plus les dlais du projet

12

tude de cas Objectif du projet

Pour rpondre ces objectifs, et malgr la relative
jeunesse de cette approche, il est dcid de sappuyer
sur une architecture SOA, pour bnficier des avantages
de cette approche, notamment :
Mise en place de processus automatiss flexibles
Rutilisation des processus et des services quel que soit le
canal denvoi dune demande de service (mise en place
dune approche multicanal)
Intgration avec les systmes existants via des services
spcifiques

Le projet se nomme PORTOS (Portail Oprateur Rseau

pour la Transmission de demandes, Orient SOA)

tude de cas Cas dutilisation

gnral
Les diffrentes tapes du scnario gnral
dutilisation de PORTOS sont :
tape 1 : Via le portail, un producteur dment
authentifi demande une prestation :
Lutilisateur peut sinterrompre en cours de
saisie (concept de demande brouillon )
Lutilisateur peut galement consulter un certain
nombre dinformations : sur les demandes en
cours, sur les PDD qui lui sont affects, sur les
relevs de consommation associs ses PDD, etc.

13

tude de cas Cas dutilisation

gnral
tape 2 : PORTOS enregistre la demande et cre un
processus mtier automatis de traitement de la
demande
tape 3 : Le processus planifie les interventions des
quipes techniques sur le terrain, puis lance ces
interventions (envoi de message lquipe
concerne en temps et en heure)

14

tude de cas Cas dutilisation

gnral
tape 4 : Chaque producteur peut demander au
systme ltat davancement de chacune de ses
demandes. Ceci implique donc lexistence dune
base historique des demandes
tape 5 : Le systme avertit le fournisseur par mail
de certains vnements mtier : refus de la
demande, fin de traitement de la demande

15

tude de cas Contraintes

principales
La solution doit grer la volumtrie des demandes de
prestation lie louverture la clientle des
particuliers
La solution doit tre volutive peu de frais, afin
doffrir de plus en plus de services aux producteurs
alternatifs : consultation de leurs factures, paiement en
ligne, etc. La mise en place progressive de ces offres
doit tre aussi lgre que possible
La solution doit tre scurise
La solution doit tre mise en place dans des dlais
courts

16

17

Composants de PORTOS
Application interactive : demander une prestation
Processus mtier : traiter automatiquement une
demande de prestation
Application interactive : rechercher une demande dj
transmise
Application interactive : consulter ltat dune demande
particulire

18

Composants de PORTOS
Application interactive : rechercher les Points De
Distribution utiliss par le producteur
Application interactive : consulter les relevs de
consommation associs un PDD
Services : services mtier daccs linformation
Services : services dinterface avec les systmes
existants

19

Composants de PORTOS
Rfrentiels mtier : demandes, PDD, relev de
consommation, identits des utilisateurs du portail
Rfrentiel technique : journal de bord de lutilisation
du systme

20

21

Modliser les services

Deux types de services
Services mtier : Le rle dun service mtier est doffrir un
ensemble cohrent de traitements mtier : cela peut
concerner par exemple laccs la vision client , ou la
simulation dun crdit immobilier, ou le calcul dimpts et
de taxes diverses, etc
Un service mtier peut tre soit un service daccs des
informations, soit un service de calcul et de vrification de
rgles mtier, soit une composition des deux

22

Modliser les services

Deux types de services
Services techniques : Le rle dun service technique est de
donner accs une ressource technique donne : on citera
par exemple laccs aux bases de donnes relationnelles,
une imprimante, etc.
Un service mtier peut sappuyer sur un ou plusieurs
services techniques pour excuter ses traitements.

23

Granularit des services

Des services :
Gros grain
Grain plus fin

Les services gros grain accdent aux services grain

fin pour effectuer leurs traitements

24

Services CRUD
Les services mtier qui mergent spontanment au
dmarrage dun projet SOA sont les services Create,
Read, Update et Delete
Permettent de crer, rechercher, mettre jour et
supprimer de linformation des les rfrentiels du SI
Chaque service CRUD est associ un objet mtier
racine et offre lensemble des oprations permettant
de crer, rechercher et mettre jour les instances de
cet objet mtier

25

Objet mtier racine

Cest un objet mtier qui constitue un point dentre
dans le systme dinformation.
Par exemple, le Client, le Contrat liant lentreprise et
le client, la Commande, le Catalogue des produits, la
Facture...
Par contre, ladresse bancaire dun Client sera un objet
mtier mais ne sera pas un objet racine du systme
dinformation.

26

Services CRUD
Crer un nouvel objet mtier racine (plus exactement
crer une nouvelle instance de la classe mtier) : par
exemple, crer le client [nom prnom] est une
opration offerte par le service CRUD associ lobjet
mtier client
Rechercher dans le ou les rfrentiels concerns
lensemble des objets mtier satisfaisant un critre de
recherche : par exemple, rechercher lensemble des
clients habitant la Marsa
Mettre jour un objet mtier existant : par exemple,
mettre jour ladresse lectronique du client
Mohamed Ali

27

Services CRUD
Pour lire ou crire un objet mtier racine, le service
CRUD associ accdera en gnral plusieurs tables du
rfrentiel concern (table client , table adresse
...), voire plusieurs rfrentiels
Un service CRUD masque la complexit intrinsque du
modle dobjets mtier manipul
Certains services techniques mergent en liaison avec
les services CRUD, par exemple les services de
communication avec les systmes existants, les services
daccs aux rfrentiels SQL, etc.

28

Exercice
Services CRUD PORTOS

29

Services applicatifs
Mettre en place des services faades, cest--dire des
services de haut niveau qui masquent aux applications
composites les services CRUD, de trop bas niveau.
Exercice : Appliquer ce principe PORTOS

30

Services fonctionnels
Mettre en place des Services mtier encapsulant tout ou
partie des rgles de gestion et des traitements mtier
On les appellera des Services Fonctionnels, par analogie
avec les fonctions mtier qui regroupent dans les
systmes classiques un ensemble cohrent de rgles et
traitements mtier
Un Service Fonctionnel sappuie sur un ou des services
CRUD pour lire les informations mtier dont il a besoin
et/ou sauvegarder les informations mtier quil a
modifies/cres

31

Application - PORTOS
Un Service Fonctionnel associ la gestion des
demandes
Un Service Fonctionnel associ la cration dun
nouveau processus mtier afin de traiter une nouvelle
demande
Un Service Fonctionnel associ la gestion automatise
de la prise de rendez-vous.

32

Application - PORTOS
Le Service Applicatif enregistrer la demande de
prestation , appel par le portail, fait lui-mme appel
au Service Fonctionnel crer une demande puis au
Service Fonctionnel crer le processus mtier associ
cette nouvelle demande

33

Application - PORTOS
Le Service Fonctionnel crer une demande excute
les traitements suivants :
Appel du service technique crer un numro unique de
demande : ce service permet de rcuprer un numro
unique didentification auprs du rfrentiel
Appel du service CRUD Crer Demande correspondant
la sauvegarde dans le rfrentiel concern des
informations du formulaire, avec le numro unique
didentification de la demande
Appel du service CRUD Mettre jour Historique de la
Demande : ltat de la demande devient [demande
enregistre]

34

Application - PORTOS
Le Service Fonctionnel crer le processus mtier
associ une demande excute les traitements
suivants
Excution de la rgle de gestion Extraire de la
demande les paramtres dappel du gestionnaire de
processus
Appel du service Crer un processus dans le BPM ce
service renvoie lidentit Id_processus du processus
cre
Appel du service CRUD Mettre jour Demande :
{demande.processus = Id_processus}

35

Application - PORTOS
Larchitecture obtenue rsout les problmes voqus
auparavant
La facilit de mise en uvre de cette architecture est
meilleure, car les concepteurs des Applications Composites,
en particulier les concepteurs des processus mtier, se voient
proposer des services de haut niveau plus facilement
rutilisables
Le prix payer pour obtenir une telle architecture, cest la
rflexion qui doit prsider lmergence de la
bibliothque de services fonctionnels
Si les Services Applicatifs et les services CRUD mergeront
relativement rapidement, il nen va pas de mme pour les
Services Fonctionnels

36

Modliser les processus

Un processus mtier dcrit lensemble des activits
que lentreprise doit excuter pour traiter un
vnement mtier qui lui est adress
Exemple : lenvoi dune commande, une demande
de prestation de service, une demande de
simulation de crdit, lenvoi dune facture, etc.

37

Modliser les processus

Le processus mtier est dfini par
Lvnement mtier dclencheur, qui est lorigine du
processus, mais galement les vnements mtier que le
processus change avec le monde extrieur. Par exemple :
vnement envoi dune lettre au client rclamant des
informations complmentaires pour traiter la demande, et
vnement rception de la rponse du client
Les activits qui doivent tre excutes, et les rgles
conditionnant le passage dune activit une autre
Pour chaque activit, et en fonction des choix
dorganisation de lentreprise, lacteur (ou le groupe
dacteur) qui doit excuter lactivit

38

Modliser les processus

Un modle de processus dcrit de faon gnrique
comment lentreprise ragit un type dvnement
mtier
Une instance de processus associe un modle traite
un vnement mtier individuel
Exemple : Le processus traitement de la demande de
prestation no XYZ en date du 5 novembre 2013 mise
par la socit ABC sera associ au modle de
processus dcrivant comment lentreprise gre un
vnement mtier traitement dune demande de
prestation

39

Modliser les processus

Le concept de processus mtier est troitement
associ au concept de Gestion des Processus Mtier
(ou BPM : Business Process Management)
Lide fondamentale tant que le systme
dinformation soit paramtr par les modles
de processus

40

Modliser les processus

La description dun processus nest plus enfouie
dans le logiciel, mais externalise sous forme de
modle, et il existe un outil spcifique, le moteur
BPM, qui excutera les instances de processus
associes au(x) modle(s)
Lavantage clef obtenu est de pou- voir faire
voluer facilement les processus sans toucher aux
applications associes

41

Modliser les processus

Depuis le dbut des annes 90, lapproche
workflow a considr essentiellement les processus
mtier sous un angle humain : un processus est vu
dans cette approche comme orchestrant une suite
dinterventions humaines pour traiter lvnement
mtier dclencheur

42

Modliser les processus

Lapproche SOA a pris en compte ds le dpart les
processus mtier, en privilgiant une approche
entirement automatise : un processus est vu
comme un chef dorchestre enchanant une
suite dappel des services mtier
Le concept dactivit est assimil un appel de
service mtier, et il ny a plus a priori d homme
dans la boucle

43

Modliser les processus

Le succs de SOA vient en grande partie de cette
prise en compte de ce quon pourrait appeler les
processus e-business : un processus e-business est
un processus automatis, cr suite une
interaction entre une entreprise et son cosystme
via le Web
Lexprience montre que les directions
informatiques convainquent leur direction gnrale
de financer le tournant SOA par lintrt de la mise
en place de tels processus e-business

44

Modliser les processus

Lintrt est tel quil a suscit lmergence de normes
et outils ddis
Un modle de processus SOA, cad la description de
lorchestration du processus partir de services
mtiers, sera ainsi dcrite grce un langage ddi
cet usage et standardis par les acteurs du monde
SOA : BPEL (Business Process Execution Language )

Modliser les processus tapes

clefs
Trois tapes principales :
Exprimer le besoin mtier
Analyser et complter le processus obtenu
Concevoir un modle de processus excutable par un
moteur BPEL

45

46

Expression des besoins

La premire tape de modlisation dcrit le
processus avec le point de vue mtier de la
matrise douvrage. Le modle rsultant a en
gnral deux caractristiques :
Il dcompose trs finement le processus mtier
Il liste les exceptions mtier leves par le
processus

48

Expression des besoins

Le processus dbute par lanalyse de la demande de
prestation mise : est-elle recevable par lentreprise eu
gard diffrents critres mtier ?
Il se poursuit par lenvoi dune demande de planification au
systme de planification des interventions (on fait ici
lhypothse simplificatrice qu une prestation correspond
une et une seule intervention sur le terrain, cest--dire une
intervention sur un Point De Distribution dnergie)
Le systme de planification renvoie une date dintervention
ainsi que lidentit de lquipe dintervention
Le moment venu, le processus lance lintervention (via un
mail lquipe), envoie un compte-rendu dintervention au
demandeur, calcule la facture et lmet vers le demandeur

49

Expression des besoins

Un tel modle permet la MOE de bien
comprendre les objectifs poursuivis par la MOA.
Cependant, dun point de vue technique, ce
modle nest pas directement exploitable pour les
raisons suivantes :
Le modle est dcoup trop finement : excut
tel quel par un moteur BPEL, il conduirait
multiplier lappel des services de grain fin, ce
qui induit des problmes de performances
Le modle liste les exceptions mtier, mais ne
prcise pas comment ces exceptions sont
traites.

50

Expression des besoins

Il existe dautres exceptions, dordre
technique, qui ne sont pas mises en
vidence.
par exemple, que se passe-t-il si le systme de
planification ne rpond pas ?
Que se passe-t-il si lintervention nest plus
possible la date planifie pour une raison
quelconque, ou si la messagerie lectronique
est hors service ?

51

Expression des besoins

Le problme de la granularit du modle de
processus est directement li au problme de la
granularit des services
La vision MOA dun processus SOA ne fait pas
directement merger les services orchestrer :
pour rsoudre ce problme, il est ncessaire de
regrouper les activits du processus pour faire
apparatre les services fonctionnels

52

Expression des besoins

La gestion des exceptions pose deux problmes:
1- Il est ncessaire davoir une vision exhaustive des causes
possibles de dysfonctionnement du processus, et pour cela
ne pas hsiter appliquer la loi de Murphy tout ce qui
peut poser problme posera problme un jour ou lautre
2- Il est ncessaire de savoir qui traite les exceptions dans
un processus automatis, et comment. Rpondre cette
question, cest rflchir la place de lhomme dans le
systme , et mettre en vidence les composants
complmentaires (services, applications composites)
permettant de traiter ces exceptions.

53

Expression des besoins

En bref, cette premire tape conduit une deuxime
tape qui doit prciser le primtre de la solution
mtier incluant le processus, en dfinissant
(1) les services rellement orchestrs par le processus
(services fonctionnels, services techniques)
(2) les applications composites permettant de traiter les
exceptions.

54

Analyse du processus
La deuxime tape vise analyser le processus mtier
pour prciser le primtre de la solution mtier
associe ce processus
Cette analyse doit satisfaire aux exigences de
granularit des services et dexhaustivit de la gestion
des exceptions

55

Analyse du processus
Ce modle est obtenu en appliquant les principes
suivants
Regrouper certaines activits du processus vision MOA ,
pour minimiser le nombre de services appels, et faire
merger les services fonctionnels
Dcrire succinctement la faon dont les exceptions sont
traites, en interaction avec la matrise douvrage qui
statue en dernier ressort

57

Analyse du processus
On remarquera que lon peut grer les exceptions de
deux faons :
Si lexception rsulte de lapplication dune rgle de
gestion par un service appel par le processus, elle peut
tre traite automatiquement. Exemple : si le demandeur
est en contentieux car il na pas rgl ses prcdentes
factures, alors le processus envoie une lettre ou un mail
notifiant le rejet de la demande)
Si lexception rsulte dun problme extrieur au
processus, exemple : un systme extrieur, sollicit, ne
rpond pas dans les dlais), elle ne peut en gnral tre
traite que par une intervention humaine

58

Analyse du processus
Le traitement des exceptions par une intervention
humaine conduit donc au concept de recyclage, qui se
traduit par le scnario suivant :
Le processus mtier lve une exception et signale cette
exception un acteur humain
Lacteur humain tudie lexception : il peut dcider de
clore la demande, ou bien il intervient pour dbloquer
cette demande
Le dblocage dune demande entrane automatiquement la
cration dun processus dit de recyclage. Ce processus de
recyclage peut ou non rutiliser certains services
orchestrs par le processus normal

59

Analyse du processus
La ncessit de modliser non seulement le processus
mtier en lui-mme, mais galement les moyens de
traiter certaines exceptions, faute de quoi la solution
mtier dploye ne sera pas complte

Conception dun processus

excutable
Cette tape vise produire un modle qui, traduit dans le
formalisme dexcution (BPEL dans le contexte SOA), sera :
Fonctionnellement complet
Techniquement excutable avec les performances attendues

Le modle recherch est obtenu en appliquant les principes

suivants :
Introduire dans le modle les services de gestion des
exceptions
Introduire dans le modle les exceptions de type time out ,
cad les temps dattente de la rponse dun systme externe
(systme de planification par exemple), et la faon de traiter
les exceptions

60

62

Rsum mthodologique
Tout processus repose sur lorchestration de
services mtiers dont la granularit ne doit pas
tre trop fine
Un processus sans exception nexiste pas : le
modlisateur doit, pour chaque activit du
processus, se poser la question des exceptions
possibles
Un processus entirement automatis nexiste pas :
la gestion des exceptions implique en gnral de
mettre lhomme dans la boucle

63

Rsum mthodologique
Un processus mtier peut en cacher un autre, par
exemple, un processus de recyclage des exceptions
Si un processus fait appel un service externe la
solution mtier dont il fait partie, le fournisseur de
ce service doit sengager formellement sur la
qualit de service (performances notamment)

64

Rsum mthodologique
Si un processus risque de durer longtemps (
lchelle humaine), il peut tre ncessaire
de mettre en place :
Au sein du processus, une mise jour de ltat
du processus aprs chaque activit effectue
Une application composite complmentaire
permettant au demandeur dinterroger ltat du
processus.

65

Rfrences
SOA : le guide de larchitecte du SI. 2me dition,
DUNOD.