Simulation d'activité

Introduction

Lors de la mise en exploitation d’un système informatique quel qu’il soit, la montée en charge reste un passage critique. Ce qu’il y a de bien en informatique, c’est que l’on peut simuler la réalité. Et cela devient vraiment intéressant quand il est possible de simuler des dizaines, voire des centaines d’utilisateurs. Même si ceux-ci se comportent de manière idéale, sans faire d’erreur (après tout, il s’agit d’automates), cela permet au moins de valider des outils dans un contexte optimal. Rappelez-vous, tout n’est que question de volume et de fréquence. 

Dans ce chapitre, nous allons voir comment simuler une activité d’informatique de gestion avec une pseudo entreprise qui pratique le négoce. C’est un cas facile et classique, mais cela permet de générer de l’activité sur un serveur et du volume de données.

À l’origine, ce petit projet devait me permettre de tester les sauvegardes RMAN de la base de données Oracle, or sauvegarder une base de données sans volume n’a quasiment aucun intérêt.

Effectuer une sauvegarde est toujours la partie la plus facile, c’est la restauration qui est compliquée et difficile. De plus, on restaure des données généralement dans un contexte tendu et stressant avec...

La structure des données

Voici une description de la structure des données.

D’abord, sous forme de schéma :

Structure des données

Puis plus détaillée :

Les tables Client/Produit/Fournisseur :

La Table Stock :

Les commandes clients : les tables COMCLI et LIGCLI.

Table COMCLI (Commandes Client) :

Table LIGCLI (Lignes de commande client) :

La table LIGFOU des commandes fournisseurs :

La gestion des compteurs nécessite la gestion d’une table supplémentaire. Un compteur permet de gérer les numéros de commande client, de commandes fournisseurs, de facture, etc.

Il est nécessaire de se coder une gestion des compteurs pour être indépendant de la base de données.

Cette...

L’initialisation de la base de données

SQLAlchemy a déjà été étudié un peu plus haut dans cet ouvrage et c’est pour cette raison que nous n’allons décrire que l’essentiel.

#fichier : db-activity-gestion/definitions.py 
## ------------------------------------- ...

La connexion à la base de données

Le script précédent n’est à lancer qu’une seule fois pour l’initialisation de la base de données.

Pour la suite de la simulation, chaque script sera autonome, mais fonctionnera de la même manière :

Chaque script aura donc besoin d’une fonction connect() qui renverra un objet session.

C’est le but du script base.py que voici, agrémenté d’une simple fonction de récupération du catalogue des produits pour test :

#fichier : db-activity-gestion/base.py 
 
from sqlalchemy import create_engine, select 
from sqlalchemy.orm import sessionmaker 
 
from definitions import Base, BASE_NAME 
from definitions import Client, Produit, Fourn, Stock, ComCli, 
LigCli, LigFou 
 
def connect(): 
   engine = create_engine(BASE_NAME, echo=False) 
   Base.metadata.bind = engine 
   DBSession = sessionmaker(bind=engine) 
   session = DBSession() 
   return session 
 
def get_catalog(): 
   session = connect() 
   s = select([Produit.id]) 
   prods = session.execute(s) 
   p = [ x[0] for x in prods ] 
   session.close() 
   return p ...

Les compteurs

Initialement, cette simulation a été conçue pour la base de données Oracle, qui possède de base une gestion de séquence. Ces séquences permettent d’obtenir une suite de numéros unique qui se suivent, mais sans garantir la continuité.

Malheureusement, cet objet de base de données n’existe pas dans certaines bases, dont SQLite. Cependant, c’est assez facile à coder, surtout avec Python.

Pour un compteur, c’est juste un nom et une valeur ; on a simplement besoin d’une fonction pour créer un compteur, une autre pour obtenir la prochaine valeur et, au cas où, une fonction pour obtenir la valeur courante.

Chaque fonction sera autonome et créera sa propre session.

Voici le script :

# fichier :  db-activity-gestion/sequence.py 
 
## ------------------------- 
## Librairie des sequences 
## ------------------------- 
 
from sqlalchemy import create_engine, select 
from sqlalchemy.orm import sessionmaker 
 
from base import connect 
from definitions import Compteur 
 
def cr_Compteur(nom): 
   session = connect() 
   c = Compteur() 
   c.nom = nom 
   c.val = 1 
   session.add(c) 
   session.commit() 
   session.close() 
 
def Curr_val(nom): 
 ...

Les commandes clients

Une fois que la base est initialisée, il est possible de se pencher sur la base du négoce, à savoir la commande client.

Pour cette simulation, ce script devra générer une commande client à partir du catalogue complet des produits et pour un client choisi au hasard.

Le script commence donc par récupérer le catalogue des produits, et surtout les informations intéressantes, à savoir l’identifiant du produit et son prix.

Ensuite, il faut trouver un client, et pour cela extraire les identifiants des clients et utiliser la fonction random.choice().

Il reste à sélectionner les produits commandés. Pour cela, la fonction random.sample() permet d’extraire un échantillon significatif.

Dans l’état actuel des choses, le maximum de produits commandés est calculé en fonction du nombre de produits ; cela convient quand il y a peu de produits. Mais si l’on veut un fichier produits plus imposant, il sera nécessaire de borner le nombre de produits commandés, pour ne pas avoir des commandes surréalistes de plusieurs milliers de lignes (même si cela existe réellement…).

Quand on a le client, la liste des produits commandés, on peut générer une commande. On prendra bien soin d’encadrer l’écriture dans la base de données par une gestion...

La livraison des commandes clients

Si on a des commandes et du stock, alors on peut procéder à la livraison des commandes clients.

Ce n’est guère plus compliqué que le reste, il faut rechercher les lignes de commandes dont la quantité commandée moins la quantité livrée est supérieure à zéro.

La requête SQL est beaucoup plus succincte qu’en langue française, car il s’agit ni plus ni moins que de :

select numcom, numlig, produit_id, qcom, qliv 
from LIGCLI 
where qcom-qliv > 0 
order by numcom, numlig 

SQLAlchemy permet d’utiliser directement des requêtes avec la méthode execute() de la session en cours.

À partir du résultat de cette requête, nous pouvons travailler sur chaque commande et chaque ligne de chaque commande.

On commence par récupérer le stock de chaque produit, et si le stock est supérieur à la quantité nécessaire (qcom - qliv), alors nous pouvons allouer notre ligne et décrémenter le stock.

On remarquera la solution trouvée par les développeurs de SQLAlchemy pour exprimer des tests multiples dans la fonction get_stock() en cumulant les ".where".

Il n’y a pas trop de contrôle à ce niveau pour le stock négatif, ni trop de risques tant que ce script est lancé de manière...

La facturation des commandes livrées

Les commandes sont livrées, il est donc possible de les facturer. En fait, il s’agit plus d’un exercice obligeant à réfléchir sur la question.

Le principe de ce script est de rechercher les commandes clients non facturées (champ FACTURE == 0) et de vérifier si toutes les lignes ont été livrées.

C’est ce que réalise la fonction get_ccl_a_facturer() ; elle renvoie une liste des commandes à facturer.

Cette liste permet de lancer, pour chaque commande à facturer, la fonction facture_ccl(). Celle-ci a pour rôle de créer un numéro de facture, de lancer une commande SQL update pour mettre à jour la commande, et de mettre à jour les lignes de commandes en positionnant la quantité facturée à la quantité livrée.

Voici le script :

#fichier : db-activity-gestion/fact_client.py 
 
from sqlalchemy import select 
 
from base import connect 
from definitions import Client, Produit, Fourn, Stock, ComCli, 
LigCli, LigFou 
 
import sequence as seq 
 
import datetime 
import random 
 
# ------------------------------------- 
# Recherche des commandes facturables 
# ------------------------------------- 
def get_ccl_a_facturer(): 
   ccl_a_facturer = [] 
   session...

Le réapprovisionnement du stock

Au bout d’un moment, il n’y aura plus de stock et il faudra bien se fournir quelque part. C’est là qu’intervient le réapprovisionnement.

Dans cette simulation, chaque fournisseur est capable de livrer tous les produits. Dans la vie réelle, c’est beaucoup plus complexe.

Au début, pour effectuer des tests, le délai de réapprovisionnement est positionné à 0 jour pour éviter l’attente. Dans un contexte de simulation plus long, il est souhaitable de le modifier pour reproduire les flux d’une exploitation.

Comment réapprovisionne-t-on un stock ?

En calculant le besoin pour chaque produit. Cela se fait en deux passes :

La première cherche dans les commandes clients le volume de stock nécessaire pour chaque produit, avec une requête comme :

select produit_id, sum(qcom) 'qte' 
from LIGCLI 
where qcom-qliv > 0 
group by produit_id 
order by produit_id 

Cela signifie que l’on veut la liste des identifiants produits avec la somme des quantités commandées pour les lignes de commandes non livrées (qcom-qliv > 0) et, pour se simplifier la vie, on trie et on regroupe par identifiant produit.

Le résultat est la liste triée des besoins (la somme des quantités à livrer) pour chaque produit.

Cette liste brute des besoins...

La réception des commandes fournisseurs

Dernier script pour la gestion de cette petite entreprise de négoce : la réception des commandes fournisseurs.

Il suffit de rechercher les lignes de commandes fournisseurs dont la quantité commandée moins la quantité reçue est supérieur à zéro (qcom - qrecu > 0) et dont la date prévue est inférieure ou égale à la date du jour.

Dans l’affirmative, on récupère l’enregistrement de stock correspondant et l’on incrémente le stock avec la quantité reçue.

Dans la même transaction, on effectue une mise à jour de la ligne de commande fournisseur en incrémentant aussi la quantité reçue.

Voici le script :

# fichier : db-activity-gestion/recept_fou.py 
 
from sqlalchemy import select 
 
from base import connect 
from definitions import Client, Produit, Fourn, Stock, ComCli, 
LigCli, LigFou 
 
import sequence as seq 
 
import datetime 
import random 
 
def get_cfou_ar(date_jour): 
   session = connect() 
   r = select([LigFou]).\ 
       where(LigFou.qcom-LigFou.qrecu > 0).\ 
       where(LigFou.dprevu <= date_jour) 
   cfouar = session.execute(r).fetchall() 
   c...

Utilisation

Voici un exemple d’utilisation pour ces scripts.

La première chose à faire est de choisir la base de données que l’on veut tester.

Ces scripts sont facilement adaptables pour une autre base de données grâce à l’utilisation de SQLAlchemy.

Le deuxième point est d’adapter le script populate.py au volume désiré ; par défaut, ce script crée 10 clients, produits, fournisseurs, ce qui permet de tester les scripts, mais même SQLite ne répond pas trop mal sur ces volumes.

Le dernier point est de choisir une période : heure, journée, 30 minutes. Tout dépend du temps et du volume que vous voulez générer.

Voici le tableau récapitulatif des scripts décrits précédemment :

La période peut correspondre à une journée comme à une heure ou une minute, tout dépend du type de simulation souhaitée.

Voici un tableau de déclenchement des scripts qui pourrait correspondre à une exploitation classique, et qui permet aussi de bien séquencer les opérations afin de ne pas trop agacer le serveur.

Toutes les opérations devaient être terminées pour 22 h, heure à laquelle nous avions prévu une sauvegarde globale de la base de données.

Résumé

À l’origine, ce projet devait permettre de tester sur une grande période les scripts de sauvegarde et de purge liés aux mécanismes d’archivage des fichiers de journalisation d’Oracle, plus connus sous les noms de RMAN et ARCHIVELOG. 

En effet, il est difficile de tester ce genre de choses sur une base qui ne bouge pas et nous voulions un environnement de laboratoire pour comprendre un peu mieux comment évoluaient la consommation des ressources et surtout la ressource disque.

Au bout de quelques jours, cela a dépassé nos attentes, car nous pouvions aussi étudier sur du volume comment se comportait la base en fonction de paramètres volontairement réduits, comme la mémoire cache allouée (SGA, System GlobalArea).

Mais cela peut être transposé sur une autre base de données comme MySQL ou PostgreSQL et ainsi permettre de voir comment celle-ci réagit avec un volume que l’on a décidé et que l’on maîtrise.

Ces scripts sont volontairement simples, voire simplistes. Lorsqu’on a codé dans différents langages des équivalences plus complexes, il ne faut pas longtemps pour créer ces six scripts.

Cependant, il ne s’agit que de simulation, certainement imparfaite, et il ne faut pas trop pousser cette simulation pour que se déclenchent des erreurs...