L'entreprise
L’entreprise se nomme UPPA, c’est une université publique. Elle est divisée en plusieurs “collèges” qui représentent différents établissements, comme par exemple un établissement présent à Tarbes.
Contexte
Mon maître de stage souhaitait réaliser un site web permettant d’afficher des informations de la base de données pour les rendre plus visuelles et pour pouvoir détecter les erreurs de saisie, les incohérences et les manques par exemple. Pour ce faire, j’avais accès à une copie de la base de données sous forme de fichier Microsoft Access. De plus, le site web devait être réalisé grâce au Framework Python Django sous l’environnement de développement Pycharm pour respecter les méthodes de travail de mes collègues.
Explication du découpement de la base de données
La base de données est divisée en quatre “catégories”.
Tout d’abord, on trouve les processus. Ces processus sont eux même découpés en trois grandes catégories : le pilotage qui représente les facteurs externes à l’entreprise, l’opérationnel qui est l’activité principale de l’entreprise et le support qui regroupe les différents services. Le bon fonctionnement du processus opérationnel est étroitement lié au deux autres. C’est la raison pour laquelle, les processus doivent être correctement renseignés dans la base de données. Dans le cas contraire, l’application doit remonter l’information à l’équipe du système d’information pour qu’elle puisse agir en conséquence.
Ensuite, nous trouvons les secteurs fonctionnels qui représentent une couche supplémentaire. Ils sont eux-même divisés en quatre secteurs : les domaines, les zones, les quartiers et les blocs, où les domaines représentent les secteurs les plus hauts et les blocs qui sont les plus bas dans la chaîne. Les secteurs fonctionnels ont besoin, pour fonctionner correctement, d’être utilisés par un processus, de manipuler un ou plusieurs objets métiers. Ces objets sont les activités métiers des salariés comme l’emploi du temps qui est lié au secteur fonctionnel et au processus de planification des enseignements par exemple. Enfin, le secteur doit être réalisé par une application qui, comme son nom l’indique, est une application qui réalise le processus. Les applications sont liées à un référentiel qui est une base de données. Il existe des connecteurs qui permettent de récupérer des données d’autres référentiels et de les écrire dans un autre. Cependant, ce système est très lourd et les données peuvent parfois être faussées d’une copie à une autre.
Présentation de l'application
L'accueil
Au lancement de l’application, l’utilisateur arrive sur cette page contenant un menu de navigation, un bouton retour, le logo, qui permet de retourner en haut de la page et trois liens qui expliquent le fonctionnement de l’urbanisation du système d’information. Par exemple, si on clique sur “Le plan d’occupation des sols de l’UPPA”, on arrive sur la page ci-dessous.
Les secteurs fonctionnels
Lorsque l’utilisateur clique sur “Les secteurs fonctionnels” présent dans le menu de navigation, il arrive sur cette page qui présente tous les secteurs fonctionnels sous forme d’arborescence en respectant les niveaux de chacun (les domaines en premier puis les zones, quartiers et blocs). En bas de la page, on trouve une légende qui rappelle le code couleur et l’ordre. L’utilisateur a également la possibilité de chercher un secteur fonctionnel s’il connaît son nom ou son code grâce à la barre de recherche qui se trouve à droite de la page.
Quand l’utilisateur clique sur un secteur fonctionnel, il est redirigé vers une autre page qui affiche la page détail de celui-ci comme ci-dessous. Elle présente le secteur fonctionnel de manière détaillée et montre aussi son impact au niveau du SI avec les objets métiers liés et les applications liées à ce secteur fonctionnel. Il montre aussi les impacts SI de ses enfants s’il en a.
Les processus, les applications et les attributs
Les processus, les applications, les attributs et les objets métiers sont tous affichés de la même façon. Il s’agit d’un tableau contenant leur code ainsi que leur nom. Dans le cas des processus, le niveau et leur type sont également affichés. De plus, un logo permet de différencier les applications.
Les attributs, les processus et les applications ont chacun une fiche détail avec des liens cliquables vers d’autres fiches. Cependant, nous allons nous concentrer sur la fiche détail d’une application qui est la plus fournie.
Tout d’abord, le haut de page de la vue fiche contient les informations générales de l’application.
Ensuite, “les impacts SI” de l’application dépendent du type de l’application. Si c’est une application classique alors son impact sera l’impact de gauche. Si c’est un consommateur ou une autre alors son impact sera celui de droite car il utilise un référentiel nommé “BUS” qui permet de transférer des objets métiers et le consommateur récupère les objets métiers dont il a besoin et écrit dans d’autres référentiels.
Les objets métiers
Comme les autres, les objets métiers ont une vue qui les affiche tous avec un barre de recherche.
Tout comme les autres, le haut de page affiche les informations sur l’objet métier concerné. Cependant, cette page affiche plus d’information comme les objets métiers qui lui sont liés. Par exemple, si on se réfère aux captures d’écran ci contre, un “lieu peut être” une “pièce” etc.
Ensuite, un objet métier possède des attributs comme un “identifiant de lieu” par exemple. Enfin, on peut voir les impacts SI de cet objet métier. On voit à quels secteurs fonctionnels ainsi que les processus auxquels il est associé. De plus, on voit les applications qui sont liés aux secteurs fonctionnels et aux processus.
Explication du code
Tout d’abord, il faut comprendre que chaque dossier encadré en rouge représente une application et que le dossier “hubCartoWeb” est le dossier principal de l’application. C’est lui qui relie toutes les “applications” entre elles. De plus, chaque “application” possède les mêmes fichiers. Par exemple, on trouve le fichier “urls.py” qui contient toutes les urls de l’application et le fichier “views.py” qui possède toutes les fonctions permettant à l’application d’afficher des vues.
Nous allons maintenant étudier le code pour afficher tous les objets métiers.
Fichier "urls.py"
La ligne 8 correspond à l‘url permettant d’afficher les objets métiers. Tout d’abord, dans le “path“, on donne le lien affichable dans l’url. Ensuite, on donne le nom de la fonction qui va permettre d’afficher les éléments dans la vue. Cependant, avant le nom de la fonction, on indique où elle se trouve. Ici c’est dans le fichier “views.py”. Pour finir, on donne un nom à cette url. Cela va nous servir plus tard dans la vue pour les liens avec d’autres pages.
from django.urls import path
from . import views
urlpatterns = [
path('InfoSurLOM/<int:omCode>/', views.om_information, name='infoSurLOM'),
path('', views.om_liste, name='om'),
path('rechercheOm/', views.om_cherche, name='omAvecRecherche'),
#path('ToutesLesLiaisonsDeLOM/<path:omCode>/', views.ToutesLesLiaisonsDeLOM, name='toutesLesLiaisonsDeLOM'),
]
Fichier "views.py"
# Fonction qui affiche les OM
def om_liste(request):
try:
str_requete ='SELECT * FROM om order by omNom'
list_om = execute_requete(str_requete, True, True)
if list_om:
# récupération du formulaire de recherche
form = FormulaireDeRecherche()
return render(request, 'objetMetier/lesOM.html', {'oms': list_om, 'form': form})
else:
return render(request, 'erreur.html')
except pyodbc.Error as e:
print("error in om_liste ", e)
return render(request, 'erreur.html')
Dans cette fonction, on utilise un “try” au cas où la requête se passe mal. Si elle échoue, on renvoie une page d’erreur sinon cela signifie qu’elle a abouti. Dans ce cas, on vérifie que le résultat ne soit pas null. Si ce n’est pas null, on renvoie la vue qui affiche les objets métiers et le formulaire sinon on renvoie une page d’erreur. Pour que la vue affiche le résultat il faut, dans le “render“, mettre entre accolade une clé et une valeur. Ici la clé est ‘oms’ et la valeur “list_om” qui contient tous les objets métiers. La clé permet à la vue d’utiliser la variable “list_om”.
Fichier "lesOM.html"
Tout d’abord, le “extends” permet de récupérer le contenu d’un fichier. L’appel à cette page HTML permet d’éviter la recopie du bloc de code afin que toutes les pages aient le même header ou footer par exemple. Grâce à cette ligne, on écrit une seule fois le header et il sera présent sur toutes les pages qui ont cet “extends”.
Ensuite, le “load static” permet que le fichier ait accès aux images par exemple.
Les “blocks” permettent de différencier les éléments, ils n’ont aucun impact pour l’utilisateur. Cela permet au HTML de savoir où il doit placer l’élément car on a défini par exemple le “block contenu” dans la “template_base.html”
{% extends 'template_base.html' %}
{% load static %}
{% block titre %}Les objets métiers{% endblock %}
{% block contenu %}
<div class="titre-barreRecherche">
<div><h3><img decoding="async" class="img-couche" src="{% static 'images/VueFonctionnelle.png' %}"> <img decoding="async" class="img-logo-titre" src="{% static 'images/ObjetMetierT.png' %}"> Les objets métiers</h3></div>
<div>
<form class="search-container" action="{% url 'omAvecRecherche' %}" method="get">
{% include 'barre-de-recherche.html' %}
</form>
</div>
</div>
{% if oms %}
<table class="table">
<thead>
<tr>
<th>Code</th>
<th>Nom</th>
<th>Etat</th>
<!-- Add more headers for other columns -->
</tr>
</thead>
<tbody>
{% for om in oms %}
{% if om.omNom != None %}
<tr>
<td>{{ om.omCode }}</td>
<td><img decoding="async" class="img-logo-liste" src="{% static 'images/ObjetMetierT.png' %}"/><a href="{% url 'infoSurLOM' om.omCode %}"> {{ om.omNom }}</a></td>
<td>{{ om.omEtat }}</td>
</tr>
{% endif %}
{% endfor %}
</tbody>
</table>
{% else %}
<p>Aucun objet métier trouvé.</p>
{% endif %}
{% endblock %}
Langages utilisés
Outils utilisés
