Reprenons notre exemple de l'architecture de l'agence de voyage.
Ouvrons le référentiel généré préalablement par GRAFlux (FX)
ainsi que le tableur FluPhy (FY)
lançons tout d'abord la macro "synchronisation"
(alt-F8)" et allons dans l'onglet "asel"
Les composants du référentiel ont été importé
|
id
|
lg
|
descr
|
obsol
|
YSMCP
|
type
|
|
|
|
|
|
|
|
|
Y
|
2
|
GRAFVOYAGE
|
+
|
Y
|
SY
|
|
YE
|
3
|
Echanges
|
+
|
S
|
SS
|
|
YE_PasseMail
|
4
|
Passerelle mail
|
+
|
M
|
CE
|
|
YE_ResaAvion
|
5
|
Résa Avions
|
+
|
M
|
CE
|
|
YE_ResaHotel
|
6
|
Résa Hotels
|
+
|
M
|
CE
|
|
YF
|
7
|
Facturation comptabilité
|
+
|
S
|
SS
|
|
YF_Facturati
|
8
|
Facturation
|
+
|
M
|
PA
|
|
YF_Factures_
|
9
|
Factures
|
+
|
M
|
DO
|
|
YG
|
10
|
Gestion demandes client
|
+
|
S
|
SS
|
|
YG_Clients__
|
11
|
Clients
|
+
|
M
|
DO
|
|
YG_GestiClie
|
12
|
Gestion des clients
|
+
|
M
|
SD
|
|
YG_GestiRese
|
13
|
Gestion des réservations
|
+
|
M
|
SD
|
Notons la colonne « obsol » qui a pour valeur
« + » indiquant qu’il s’agit d’une première importation.
Dans l’onglet « Ccum » (Cluster matériel) on
saisit les nom des serveurs que nous avons identifié dans les §
précédents :
|
nom
|
descr
|
admin
|
o
|
r
|
u
|
|
|
|
|
#
|
#
|
#
|
|
P-MVO-W
|
Frontal web (Apache)
|
ssh
|
0
|
0
|
0
|
|
P-MVO-T
|
Application (Catalogue produits + réservation voyage)
|
ssh
|
0
|
0
|
0
|
|
P-MVO-D
|
Données (Catalogue produits + réservation voyage + base clients)
|
ssh
|
0
|
0
|
0
|
|
P-ECH-T
|
Echanges
|
ssh
|
0
|
0
|
0
|
|
P-IMP-T
|
Serveur d'impression
|
ssh
|
0
|
0
|
0
|
|
P-FAC-T
|
Serveur de facturation (Aplication server)
|
ssh
|
0
|
0
|
0
|
|
P-FAC-D
|
Serveur de facturation (Central Instance)
|
ssh
|
0
|
0
|
0
|
|
P-MVO-P
|
Poste de travail Agent
|
ssh
|
0
|
0
|
0
|
|
X-CLI-P
|
Poste de travail Client
|
ssh
|
0
|
0
|
0
|
|
X-AVI-T
|
Serveurs externes de réservation d'avion
|
ssh
|
0
|
0
|
0
|
|
X-HOT-T
|
Serveurs externes de réservation d'hotel
|
ssh
|
0
|
0
|
0
|
|
X-JMS-T
|
Provider JMS
|
ssh
|
0
|
0
|
0
|
Puis de nouveau dans l’onglet « asel », on associe
les composants importés et les serveurs pour décrire le déploiement
physique :
|
id
|
lg
|
descr
|
obsol
|
YSMCP
|
type
|
clum_1
|
|
|
|
|
|
|
|
|
|
Y
|
2
|
GRAFVOYAGE
|
+
|
Y
|
SY
|
|
|
YE
|
3
|
Echanges
|
+
|
S
|
SS
|
P-ECH-T
|
|
YE_PasseMail
|
4
|
Passerelle mail
|
+
|
M
|
CE
|
P-ECH-T
|
|
YE_ResaAvion
|
5
|
Résa Avions
|
+
|
M
|
CE
|
P-ECH-T
|
|
YE_ResaHotel
|
6
|
Résa Hotels
|
+
|
M
|
CE
|
P-ECH-T
|
|
YF
|
7
|
Facturation comptabilité
|
+
|
S
|
SS
|
|
|
YF_Facturati
|
8
|
Facturation
|
+
|
M
|
PA
|
P-FAC-T
|
|
YF_Factures_
|
9
|
Factures
|
+
|
M
|
DO
|
P-FAC-D
|
|
YG
|
10
|
Gestion demandes client
|
+
|
S
|
SS
|
|
|
YG_Clients__
|
11
|
Clients
|
+
|
M
|
DO
|
P-MVO-D
|
|
YG_GestiClie
|
12
|
Gestion des clients
|
+
|
M
|
SD
|
P-MVO-T
|
|
YG_GestiRese
|
13
|
Gestion des réservations
|
+
|
M
|
SD
|
P-MVO-T
|
|
YG_PorBacOff
|
14
|
Portail Back office
|
+
|
M
|
CA
|
P-MVO-T
|
|
YG_PortaClie
|
15
|
Portail client
|
+
|
M
|
CA
|
P-MVO-T
|
Puis on liste les règles dans l’onglet « regle »
|
nom
|
bus
|
type_f
|
type_s
|
type_d
|
descr
|
o
|
r
|
u
|
|
|
|
|
|
|
|
#
|
#
|
#
|
|
$ff
|
FF
|
flux de fichiers
|
0
|
0
|
1
|
|||
|
$ff
|
bus
|
FF
|
flux de fichiers
|
0
|
0
|
1
|
||
|
$callEch
|
FS
|
CE,SX
|
Appel synchrone d'un composant "Echange"
|
0
|
0
|
0
|
||
|
$callSvc
|
FS
|
SD
|
Appel synchrone d'un service
|
0
|
0
|
0
|
||
|
$ecrBD
|
FD
|
DO
|
écriture dans une BASE DE DONNÉES
|
0
|
0
|
0
|
||
|
$bus
|
bus
|
découper en deux moitiés
|
0
|
0
|
0
|
|||
|
$lecfic
|
FD
|
DF
|
lecture fichier (flux à retourner)
|
0
|
0
|
0
|
||
|
$lecBD
|
FD
|
DO,D*
|
lecture BD (flux à retourner)
|
0
|
0
|
0
|
||
|
$ihmAI
|
AI
|
accès à l'IHM depuis son poste pour acteur interne
|
0
|
0
|
0
|
|||
|
$ihmAE
|
AE
|
accès à l'IHM depuis son poste pour acteur externe
|
0
|
0
|
0
|
|||
|
$Async
|
FA
|
Message asynchrone
|
0
|
0
|
0
|
Ces règles utilisent
des attributs qui sont présent dans le référentiel FX :
- le type du flux (Par exemple : FS = Flux synchrone,
FA = Flux asynchrone)
- le type du composant source (Par exemple : DO :
silo de donné, AE : acteur externe)
- le type du
composant destination.
Le corps de la règle est décrit dans l’onglet
« étape ». Ici on prend la règle « $Async »
|
nom
|
étape
|
src
|
dst
|
clum_1
|
prot
|
rpp
|
dpp
|
cat
|
descr
|
|
|
|
|
|
|
|
|
|
|
|
|
$Async
|
1
|
src
|
rgl
|
X-JMS-T
|
M
|
Envoi du message au provider JMS
|
|||
|
$Async
|
2
|
rgp
|
dst
|
M
|
Du provider JMS au serveur de destination
|
Précisons le mode de description des étapes
C’est dans l’étape que l’on spécifie le mode de génération
de chacun des flux physiques. Les colonnes de l’onglet \_étape_/ sont les suivantes :
-
nom nom de la règle contenant l’étape
-
étape numéro de l’étape dans la règle (1,2,…)
-
src choix du serveur à utiliser comme
source du flux généré :
o
« src » utiliser le serveur source du flux logique
o
« dst » utiliser le serveur destination du flux logique
o
« via » utiliser le serveur intermédiaire spécifié dans les colonnes
« via_# » de \_flul_/
si via_# dans \_flul_/ est vide, on prendra par défaut le serveur spécifié dans la colonne « clum_# » de l’étape
si via_# dans \_flul_/ est vide, on prendra par défaut le serveur spécifié dans la colonne « clum_# » de l’étape
o
« rgl » utiliser le serveur spécifié dans les colonnes « clum_# »
de l’étape
o
« rgp » utiliser le serveur spécifié dans les colonnes « clum_# »
de l’étape précédente
o
« rgs » utiliser le serveur spécifié dans les colonnes « clum_# »
de l’étape suivante
-
dst choix du serveur à utiliser comme
destination du flux généré :
o
« src » utiliser le serveur source du flux logique
o
« dst » utiliser le serveur destination du flux logique
o
« via » utiliser le serveur intermédiaire spécifié dans les colonnes
« via_# » de \_flul_/
si via_# dans
\_flul_/ est vide, on prendra par défaut « clum_# » de l’étape
o
« rgl » utiliser le serveur spécifié dans les colonnes « clum_# »
de l’étape
o
« rgp » utiliser le serveur spécifié dans les colonnes « clum_# »
de l’étape précédente
o
« rgs » utiliser le serveur spécifié dans les colonnes « clum_# »
de l’étape suivante
-
clum_# serveur
à utiliser comme source ou destination du flux généré quand on a spécifié
« rgl » dans les colonnes src ou dst ; sert également de valeur par défaut pour « via ».
# est le numéro de modèle d’environnements [1..4] (permet de faire 4 variantes)
« rgl » dans les colonnes src ou dst ; sert également de valeur par défaut pour « via ».
# est le numéro de modèle d’environnements [1..4] (permet de faire 4 variantes)
-
prot protocole
à utiliser si différent de celui du flux logique
-
rpp seulement
si « prot » est spécifié
règle d’attribution des ports :
règle d’attribution des ports :
o
0 port
par défaut du protocole
o
1 premier
port alternatif du protocole + dpp
o
2 second
port alternatif du protocole + dpp
o
vide port
par défaut du protocole (comme 0)
-
dpp seulement
si « prot » est spécifié
décalage dans la plage de ports (ports alternatifs)
(si vide : pas de décalage)
décalage dans la plage de ports (ports alternatifs)
(si vide : pas de décalage)
-
cat catégorie
du flux généré (une lettre préfixant l’id du flux)
par défaut : A (applicatif)
ex. : U (utilisateur)
par défaut : A (applicatif)
ex. : U (utilisateur)
-
descr description
courte du flux généré
sera placé devant le nom du flux logique dans la description du flux généré
sera placé devant le nom du flux logique dans la description du flux généré
Donc dans notre exemple :
Etape 1 :
- le serveur source est « src » : la source
du flux logique considéré
- la destination est « rgl », soit le serveur
spécifié dans « clum_1 » : à savoir, le provider JMS
Etape 2 :
- le serveur source est « rgp » : le serveur
spécifié dans la colonne « clum_1 » de l’étape précédente : à
savoir, le provider JMS
- la destination est « dst », soit la destination
du flux logique
Une fois les règles établies, nous pouvons lancer la macro « génération ».
Le résultat se trouve dans l’onglet « flug » dont voici un extrait :
|
descr
|
obsol
|
menv
|
src
|
dst
|
prot
|
|
|
|
|
|
|
|
|
écriture base pour flux logique YGYG_Client___ (Client) et lecture
base pour flux logique YGYP_Clients__ (Clients) et écriture base pour flux
logique YGYG_Demandes____1 (Demandes) et lecture base pour flux logique
YGYG_Demandes____2 (Demandes) et écriture base pour flux logique
YPYP_DossiVoya (Dossier Voyage) et écriture base pour flux logique
YGYG_MisJouDon (la mise à jour de données) et lecture base pour flux logique
YGYP_Reservati (Réservations)
|
+
|
1
|
P-MVO-T
|
P-MVO-D
|
sqlnet
|
|
accès au serveur apache depuis l'extérieur pour flux logique
C_YG_DemanVoya (Demander voyage)
|
+
|
1
|
X-CLI-P
|
P-MVO-W
|
http
|
|
du serveur apache au serveur d'application pour flux logique
C_YG_DemanVoya (Demander voyage) et du serveur apache au serveur
d'application pour flux logique M_YM_GererCata (Gérer catalogue) et du
serveur apache au serveur d'application pour flux logique V_YG_TraDemVoy___1
(Traiter demande voyage) et du serveur apache au serveur d'application pour
flux logique V_YG_TraDemVoy___2 (Traiter demande voyage)
|
+
|
1
|
P-MVO-W
|
P-MVO-T
|
RMI
|
La première ligne identifie un flux physique (protocole
SQLNET) qui permet de supporter l’ensemble des flux logiques accédant au
serveur de données.
La troisième ligne identifie un flux physique (protocole
RMI) qui permet l’accès au serveur applicatif depuis le serveur frontal
Aucun commentaire:
Enregistrer un commentaire