GRAF–Outillage pour les nuls / saisir une propriété

 

Lançons VISIO pour réaliser un premier schéma très simple.

Avant de dessiner le schéma, s’assurer que le dock de la configuration VISIO contient :

• Les icones de l’architecture logique
• Les icônes des flux logiques
• la fenêtre qui affiche les propriété des objets, dans laquelle les propriété GRAF pourront être renseignées

 

Ces fenêtres sont accessibles depuis le menu “Affichage” de visio

 

 

 

 

 

 

 

 

 

Réalisons un premier schéma d’un système qui permet à un commercial de prendre une commande en utilisant un ERP (SAP par exemple).

 

Première remarque : si les sous-systèmes et les modules ont un nom, les flux n’en ont pas, ce qui pourrait être gênant pour la génération documentaire

Ajouter les noms systématiquement sur le schéma peut par ailleurs l’alourdir.

On choisira dans ce cas de saisir le nom sur la propriété “GRAF_dénomination” des flux

En cliquant sur le flux, la fenêtre des données de forme est rafraîchie et on peut saisir le nom du flux

 

Ici, nous sélectionnons la deuxième flèche bleue et nous saisissons la propriété GRAF_dénomination

 

 

Il peut être intéressant pour la suite de nommer un flux synchrone par la raison qui motive ce flux, et un flux de données par les données qu’il transporte.Il y a d’autres solutions mais celle-ci est en accord avec notre stratégie de génération documentaire. Nous verrons pourquoi un peu plus tard.

GRAF - Anticiper la charge d'un système d'information - fin

Les performances dépendent pas seulement de la consommation en CPU. Elle sont également dûes au débit aux termes d’entrées-sorties. 

Ce débit peut également être mesurée avec l’utilitaires NMON puis être extrapolé avec le VAT de GRAF.

Lorsque l’on effectue la mesure d’un traitement, on comptabilise le nombre d’IO générées lors de l’exécution du traitement, que l’on divise ensuite par le nombre d’objet traités.

Dans le fichier NMON

1. On crée une variable M_IO  qui contient toutes les valeurs de la colonne  IO/sec de l’onglet DISK_SUM du fichier NMON.
2. On crée une variable M_Heure_IO qui contient toutes les dates de l’onglet DISK_SUMM.
3. On rajoute l’onglet « Mesure » qui contient les valeurs suivantes (On a dans cet exemple effectué 2 mesures sur un batch de facturation) :

Batch	Output	Unité O	Début	Durée	Fin	IO brut	IO	IO par output
Facturation	179	Postes	28/11/2014 13:15:52	43,157	28-11/2014 13:16:35	26368,6	25867,8673	144,5132252
Facturation	179	Postes	28/11/2014 13:28:52	62,79	28-11/2014 13:29:55	50046,2	49545,4673	276,7903201

Le nombre d’IO brut est fourni par la formule matricielle :

{SOMME(M_IO*SI(M_Heure_IO>=[Début];1;0)*SI(M_Heure_IO<=[Fin] ;1;0))}

Pour éliminer le « bruit » de fond, on calcule un nombre d’IO « net » :

[IO Brut] - MOYENNE(M_IO)

Puis on divise par le nombre d’objets métiers analysés au cours du traitement, soit dans l’exemple un nombre d’IO moyen par ligne de facture égal à 211.

Dans le VAT

Les plages, les serveurs, les composants et les macroflux ayant été renseignés comme dans l’article http://vincentlacroixgraf.blogspot.fr/2014/12/graf-anticiper-de-la-charge-dun-systeme.html, il nous reste à compléter l’onglet « traitements » en remplissant pour chaque traitement considéré, la colonne « SAN ». avec le nombre d'IO moyen par objet métier mesuré.

On actualise les données de l’onglet « X_SAN_t », puis on affiche le graphique de l’onglet « G_SAN_t ».

GRAF - Anticiper la charge d'un système d'information - suite

Afin de pouvoir simuler la charge d’un système d’information avec la méthode décrite dans l’article précédent (Cf  http://vincentlacroixgraf.blogspot.fr/2014/12/graf-anticiper-de-la-charge-dun-systeme.html), il faut être en mesure de mesurer la consommation CPU unitaire moyenne des différents traitements.

Pour cela il est nécessaire de :

1. Choisir les objets métiers représentatifs des flux à mesurer.
2. Préparer l’échantillon, en notant le nombre d’objets métier utilisés dans l’échantillon
3. Choisir l’outil de mesure.
4. Être capable de noter l’heure de début et la durée du traitement de l’échantillon.

Les objets métier représentatifs

Afin d’obtenir une mesure représentant  fidèlement la moyenne, il est préférable de choisir des objets « atomiques », pour lesquels la charge traitement varie peu d’un objet à l’autre. Par exemple, on choisira de préférence la « ligne de facture » plutôt que la facture elle-même, car cette dernière peut contenir un nombre de lignes très variable.

Il faut ensuite, dans l’étude de volumétrie, être en mesure de dénombrer le nombre d’objets métier qui devront être traités à la cible (Cf. l’article précédent sur l’utilisation du VAT).

Préparer l’échantillon

Comme dans les sondages d’opinion, plus la quantité d’objets métier est importante, plus la mesure de la moyenne est fiable. Le nombre minimal d’objets que l’échantillon doit contenir tourne autour de la cinquantaine.

Choisir l’outil de mesure

Suivant l’application considérée, on pourra utiliser :

un outil de monitoring système tel que NMON (LINUX) ou Perfmon (Windows)

un outil de monitoring applicatif comme Solution Manager de SAP (Transaction ST03)

Exemple

Dans notre exemple, nous allons utiliser NMON, qui mesure l’activité des CPU vue par le système d’exploitation. Il faut pour cela effectuer le test de mesure sur un environnement « silencieux », c'est-à-dire qui est dédié à la mesure au moment du test. Par exemple on réservera un environnement de recette ou de développement pendant la durée de la mesure.

NNOM construit un fichier Excel avec plusieurs onglets. l’onglet intéressant est l’onglet CPU_ALL, qui contient, pour chaque période de temps, le pourcentage moyen d’occupation des CPU.

NMON peut être paramétré de façon à ce qu’une période de temps ait une durée d’une seconde. 1% d’occupation est alors équivalent à une charge d’un centième de seconde sur le CPU.

Rappelons que dans la méthode d’utilisation du VAT présentée dans l’article précédent, on utilise la milliseconde comme unité de consommation CPU.

L’obtention, pour chaque seconde de temps de la charge consommée sur l’ensemble des CPU en milisecondes est fournie par :

%occupation_CPU * 10 * Nombre_CPU

Dans le fichier NMON :

1. On crée une variable M_CPU qui contient toutes les valeurs de la colonne CPU% de l’onglet CPU_ALL du fichier NMON.
2. On crée une variable M_Heure qui contient toutes les dates de l’onglet CPU_ALL.
3. On rajoute l’onglet « Mesure » qui contient les valeurs suivantes (On a dans cet exemple effectué 2 mesures sur un batch de facturation) :

Batch	Output	Unité O	Début	Durée	Fin	Pourcentage CPU	Consommation CPU
Facturation	179	Lignes facture	28/11/2014 13:15:52	43,157	28-11/2014 13:16:35	123	14734,41379
Facturation	179	Lignes facture	28/11/2014 13:28:52	62,79	28-11/2014 13:29:55	117	14014,41379

Le pourcentage d’occupation CPU est calculé par la formule matricielle :

={SOMME(M_CPU*SI(M_Heure>=[Début];1;0)*SI(M_Heure<=[Fin];1;0))}

La mesure unitaire de l’occupation CPU pour le traitement d’une ligne de facture est finalement fournie par la formule :

=[Pourcentage CPU]*10*Nombre_CPU/[Output]

On obtient 82 millisecondes de traitement pour une ligne de facture dans la première mesure, et 78 dans la seconde.

GRAF - Anticiper de la charge d'un système d'information

le VAT (Volumetrics Analysis Tool) de GRAF permet de simuler la charge d’un système d’information dès la phase de la réalisation, et ce, sans qu’il soit besoin d’installer un environnement de performances.

Il suffit pour cela au cours de la réalisation de mesurer la consommation unitaire des différents traitements et de modéliser la volumétrie des différents flux, puis d’utiliser le VAT pour obtenir les différentes consommations de ressource sur les différents serveurs de l’environnement de production.

Il y a pour cela deux environnements à considérer :

• L’environnement sur lequel la mesure unitaire peut être effectuée (par exemple, l’environnement de développement ou l’environnement de recette)
• L’environnement de production sur lequel le système doit tourner à la cible

Prenons le cas le plus simple (mais souvent vérifié dans la pratique), dans lequel le serveur sur lequel s’effectuent les mesures a le même modèle de processeur que le serveur cible. Notons au passages que ces processeurs peuvent être logiques ou physiques.

L’unité de mesure de puissance (GVPU - GRAF Virtual Power Unit) la plus simple à considérer est la milliseconde d’occupation du processeur, que l’on pourra utiliser dans les deux environnements.

Il suffit pour cela d’utiliser comme unité dans GRAF la transaction étalon (te), et de déclarer que chacun des processeurs de l’environnement cible a une puissance de 1000 te :

Exemple, dans un environnement SAP on pourra déclarer dans l’onglet « serveur » :

nom	description	Gvp	Gvpu
ECC_AS_SD	Serveurs ECC AS et SD	1000	te/s
CP1PROLASx	Serveur AS CRM	1000	te/s

Tentons à présent de simuler à la cible la consommation de ressources d’un batch de facturation. Nous supposerons pour cela que le batch s’exécute dans une plage d’activité nocturne de 22 h00 à 7h00

On déclare donc dans l’onglet « plage »  son profil d’activité : « Prof_NuitA_22_7 » :

Il nous faut connaitre, maintenant la volumétrie du flux de facturation. Pour cela, on choisit le type d’objets métier que l’on va dénombrer dans la mesure. En l’occurrence nous avons choisi le « poste », c'est-à-dire la ligne de facture. L’analyse fonctionnelle doit nous permettre d’évaluer le nombre d’objets traités par jour.

On décrit alors  dans l’onglet « macroflux » le macroflux de facturation :

nom	description	plage	vol/j
			/j
MF_Facturation	Génération des factures	Prof_NuitA_22_7	10 725 000

Il faut ensuite décrire dans l’onglet « hébergement » un composant (virtuel dans l’exemple) qui héberge le traitement de ce macroflux sur le serveur (ou le groupe de serveurs) considéré :

composant	description	serveur
C_COM_967_Facturation_AS_SD	Génération des factures dans sur les serveurs ECC (Aplication serveur et serveur de données)	ECC_AS_SD

Notons au passage que pour simplifier la modélisation et la mesure, nous avons dans cet exemple simulé l’ensemble des serveurs de SAP ECC comme un seul serveur. Il est bien sûr possible d’être plus fin dans la modélisation et de séparer AS et SD.

Nous sommes prêts à présent à décrire le traitement dans l’onglet « traitement » et à reporter la mesure unitaire que nous avons réalisée dans l’environnement de mesure :

nom	description	composant	serveur	macroflux	plage	vol/j	prop%	trt/j	c cpu
						/j	%	/j	Gvcu
T_C_COM_967_Facturation_AS_SD	Génération des factures dans sur les serveurs ECC (Aplication serveur et serveur de données)	C_COM_967_Facturation_AS_SD	ECC_AS_SD	MF_Facturation	Prof_NuitA_22_7	10725000	100%	10725000	183,582

Nota : nous verrons dans un prochain article comment on peut effectuer cette mesure unitaire.

Le VAT fournit alors la consommation de ressources en terme de CPU à la cible :

GRAF - BPMN ET PROCESSUS MÉTIER Suite

Nous avons vu dans l'article précédent comment mixer GRAF et BPMN pour illustrer la conception logique d'un processus métier. Le schéma obtenu est très parlant. A ce stade néanmoins il reste assez abstrait et il manque une quantité importante de détails pour être capable d'organiser l'implémentation du système.

Pour préparer l'implémentation nous ajouterons donc un certain nombre de composants :

1. Tout d'abord, le swinlane BPMN peut être implémenté par un orchestrateur BPM
2. Les demandes client sont stockées dans une base de données. 
3. Une fois les demandes affectées aux vendeur, elle sont transformées en tâches qui sont  stockées dans une base de données contenant les différentes corbeilles de tâches des différents vendeurs
4. Un composant alimente périodiquement l'orchestrateur avec les demandes déposées par les clients
5. Un composant assure l'interface entre le portail du vendeur et l'orchestrateur.

Le schéma GRAF peut alors être représentée de la manière suivante :

3 GRAF - BPMN ET PROCESSUS MÉTIER

GFAF permet de mixer des modèles de représentation de façon à s’assurer de la cohérence complète du système d’information.

Par exemple, l’association entre GRAF « logique » et la notation BPMN permet de représenter le fonctionnement « organique » d’un processus métier. Cette représentation illustre directement l’interaction entre les activités (notamment les activités humaines) et les composants du système d'information.

Reprenons encore une fois l’exemple de l’agence de voyage et illustrons par un  Diagramme GRAF+BPMN le processus  de gestion des réservations qui permet la constitution d’un dossier voyage.

Le processus de gestion des réservations peut être activé par la réception de l’un ou l’autre de ces deux événements :

• A1 : Le client dépose une demande sur le portail client.
• A’1 : Le vendeur ouvre la fonction de réservation

Dans le premier cas, une première activité du processus consiste à affecter la demande à un vendeur qui va la traiter. Cette activité consiste à déclencher le composant « Affectation demande » (A2), qui va pousser la demande dans la corbeille de tâches d’un vendeur.

• B0, B1 Un vendeur ouvre une demande de sa corbeille des tâches

Il doit effectuer deux activités (peu importe l’ordre) :

• Réserver un hôtel
• Réserver un avion

Ce sont des activités qui nécessitent une interaction avec l’utilisateur, d’où la présence de l’icône représentant un personnage.

Au cours de ces deux activités :

• C0 : Il y a un échange (en général téléphonique) entre le client et le vendeur
• C1, C2 Cet échange entraîne l’envoi d’un ordre de réservation :

1.     C3 : à un hôtel, via l’usage du connecteur « Résa hotel »
2.     C’3 : à une compagnie aérienne, via l’usage du connecteur « Résa avion »

• D1, D2 : puis aboutit à l’enregistrement du dossier

GRAF - Génération automatique de la préparation des ateliers

Cette fonctionnalité est disponible à partir de la version 2.3.1 de GRAF

GRAF permet d’accélérer la préparation des ateliers collaboratifs de définition de l’architecture.

Pour préparer un atelier rapidement et efficacement, l’idéal est que tous les participant disposent :

• d’un ou plusieurs schémas GRAF de la portion d’architecture à examiner
• d’une explication des différents éléments du schéma, qui explique notamment la cinématique des flux.

CalliGRAF propose un outil très simple permettant de pré-générer un texte décrivant les différents flux.

Ce texte pourra bien sûr être adapté manuellement de façon à apporter des précisions qui améliorent la lisibilité de la représentation. Toutefois, l’usage des propriétés GRAF sur les objets visio permet d’avoir déjà un niveau de lisibilité élevé dans le texte généré.

Le texte généré est élaboré de façon à ce qu'on puisse facilement y insérer les n° de séquence (manuellement) avant de re -trier le tout (manuellement toujours, en utilisant le mode « plan » de word) de façon à ce que les séquences arrivent en ordre.

Remarque : certaines explicitations de flux devront également être dupliquée manuellement  lorsque plusieurs séquences utilise le même flux.

Chacun des flux génère un texte conforme à la grammaire suivante :

[SEQ]: < GRAF_désignation (composant source)><GRAF_dénomination (composant source)>

envoie 

< GRAF_désignation (flux)><GRAF_dénomination (flux)>[<GRAF_documentation(flux)>]

vers

< GRAF_désignation (composant cible)><GRAF_dénomination (composant cible)>

Exemple :

Supposons que pour notre agence de voyage nous ayons préparé un atelier « Décisionnel » à l’aide du schéma suivant :

Renseignons quelques propritétés GRAF. Par exemple sur flux qui porte la séquence A2 :

GRAF_désignation : « le’ordre d’insertion »

GRAF_dénomination : « Données métier »

GRAF_documentation : « dans la base en étoile »

Remarquons au passage que dans GRAF, une désignation, qui sert à clarifier le type de l’objet GRAF considéré doit avoir la syntaxe :

<article porteur du genre>[<apostrophe si élision>]<syntagme nominal de la désignation>

d’où la formulation « le’ordre » plutôt que « l’ordre » pour aider CalliGRAF à connaitre le genre du nom qui suit.

Il suffit, une fois que le diagramme et éventuellement les propriétés ont été élaborées, d’ajouter la directive « générer atelier » dans le fichier de paramétrage « plan.txt » de l’arborescence CalliGRAF.

Le texte généré est alors :

·         [SEQ] : le silo de données transactionnelles « Réservations client » envoie le résultat de l'extraction de données « Données métier [lues via des requêtes informatica] » vers le module de paramétrage « Alimentation reporting »

·         [SEQ] : le silo de données transactionnelles Factures envoie le résultat de l'extraction de données « Données métier [lues via des requêtes informatica] » vers le module de paramétrage « Alimentation reporting »

·         [SEQ] : le module de paramétrage « Alimentation reporting » envoie l'ordre d'insertion des « Données métier [dans la base en étoile] » vers le silo de données décisionnelle « Décisionnel voyage »

·         [SEQ] : le silo de données décisionnelle « Décisionnel voyage » envoie le résultat des requêtes « Données métier [depuis la base  en étoile] » vers le module d'accès à la base décisionnelle « Requêtes reporting voyages prédéfinies »

·         [SEQ] : la page écran « IHM reporting voyage » envoie l'invocation de service « Exécuter rapport » vers le module d'accès à la base décisionnelle « Requêtes reporting voyages prédéfinies »

·         [SEQ] : l'agent interne « Responsable Marketing » envoie l'ordre « Demander rapports » vers la page écran « IHM reporting voyage »