1

RAPPORT DE STAGE D’ETE

Spécialité : Informatique

Option : Ingénierie Informatique

Par

Rawdha MABROUKI

Entreprise d’accueil

Encadrant professionnel

Madame Malek MOKLINE

Année universitaire

2015/2016

Année universitaire 2015/2016

Conception et Développement d’un Module

Dynamics Ax de Gestion de Visa

ii

Remerciements

Mes remerciements les plus distingués sont adressé au membre des jurys qui m’ont fait

l’honneur de bien vouloir accepter d’évaluer ce modeste travail et d’avoir accepté de rapporter

ce modeste travail et d’avoir trouvé la force de lire, corriger et critiquer. Enfin je remercie

madame Safa RAFAI rapporteur pour les critiques relatives au rapport.

Je tiens à exprimer toutes mes gratitudes à Mme Malek Mokline pour avoir supervisé le

cheminement de ce travail, aussi pour ses encouragements et surtout pour ses conseils et ses

orientations précises émanant d’une rigueur et d’une expérience précieuse.

iii

Sommaire

Introduction générale ............................................................................................................... 1

Chapitre I. Contexte de Projet ............................................................................................ 3

1.1 Introduction ................................................................................................................ 3

1.2 Présentation de l’entreprise d’accueil ........................................................................ 3

Objectifs ................................................................................................................. 3

Domaines d’activités .............................................................................................. 3

1.3 Présentation du projet ................................................................................................. 4

Motivations ............................................................................................................. 4

Objectif du projet ................................................................................................... 4

1.4 Méthodologie et formalisme adoptées ....................................................................... 4

1.5 Etat de l’art ................................................................................................................. 5

Entreprise Ressource Planning ............................................................................... 5

Microsoft Dynamics ............................................................................................... 5

Architecture fonctionnel de Dynamics AX ............................................................ 6

Architecture en couches de Dynamics Ax ............................................................. 7

Architecture Technique de Dynamics Ax .............................................................. 7

Niveau accès aux données ...................................................................................... 7

Niveau intermédiaire .............................................................................................. 7

Niveau présentation ................................................................................................ 8

1.6 Problématiques ........................................................................................................... 8

1.7 Conclusion .................................................................................................................. 8

Chapitre II. Mise en œuvre ............................................................................................... 9

2.1 Introduction ................................................................................................................ 9

2.2 Spécification des besoins ........................................................................................... 9

Diagramme de cas d’utilisation générale ............................................................... 9

Prototypes ............................................................................................................. 11

2.3 Conception ............................................................................................................... 17

iv

2.4 Environnement de développement ........................................................................... 20

MorphX IDE ........................................................................................................ 20

Langage X++ ........................................................................................................ 21

Pattern de formulaire de Dynamics Ax ................................................................ 21

Service de reporting ............................................................................................. 22

2.5 Architecture de l’application .................................................................................... 22

2.6 Réalisation ................................................................................................................ 23

2.7 Conclusion ................................................................................................................ 27

Conclusion générale ............................................................................................................... 28

Bibliographies ............................................................................................................................ i

Webographies ........................................................................................................................... ii

iv

Liste des figures

Figure I-1 : Les différentes vues du langage UML .................................................................... 5

Figure I-2 : Architecture fonctionnel d’AX [W1] ...................................................................... 6

Figure I-3 : WorkerList Page ..................................................................................................... 6

Figure I-4 : Architecture technique d’AX .................................................................................. 8

Figure II-1 : Diagramme de cas d'utilisation générale ............................................................. 10

Figure II-2 : Prototype List Page .............................................................................................. 11

Figure II-3 : Prototype demande de visa de sortie terminale ................................................... 12

Figure II-4 : Prototype demande de visa entré sortie pour plusieurs voyages ......................... 13

Figure II-5 : Prototype Demande de visa pour une mission Temporaire ................................. 14

Figure II-6 : Prototype demande de visa pour une entré sortie un seul voyage ....................... 15

Figure II-7 : Prototype Demande de visa pour une résidence temporaire ................................ 16

Figure II-8 : Modèle conceptuel de données ............................................................................ 17

Figure II-9 : Diagramme de classe ........................................................................................... 18

Figure II-10 : Schéma relationnel de la base de données ......................................................... 19

Figure II-11 : Table HCMPerson Private Details ..................................................................... 19

Figure II-12 : MorphyX le Developper Workspace ................................................................. 20

Figure II-13 : MorphX IDE éditeur de code X++ .................................................................... 21

Figure II-14 : Architecture d'une Business Application ........................................................... 22

Figure II-15 : Interface Visa Request List page ....................................................................... 24

Figure II-16 : Interface Visa Request Master Détails Page ...................................................... 24

Figure II-17 : Interface Master Détails page de gestion de visa pour un employé................... 25

Figure II-18 : Interface de grille de Modification de demande de Visa ................................... 25

Figure II-19 : Interface vue en tête de la page Transactional détails d'ajout de demande ....... 26

Figure II-20 : Interface transactionnel Détails Page vue ligne ................................................. 26

v

Liste des tableaux

Tableau I-1 : Modèle de couches de Dynamics Ax.................................................................... 7

Tableau II-1 : Liste des classes................................................................................................. 18

1

Introduction générale

Un système d'information est un ensemble organisé de ressources qui permet de collecter,

regrouper, classifier, traiter et diffuser de l'information sur un environnement donné. C’est un

système dédié et ouvert sur son environnent. Il produit des informations en utilisant le cycle de

sortie du processus d’entrée. L'élément le plus important dans un système d'information est ces

données.

Les systèmes d'information traditionnels présentent un inconvénient majeur. En effet, ces

systèmes ne donnent que les informations, qui ont été conçus d’être produites au moment où ils

ont été construits. Or dans une entreprise, les employés appartenant à un département donné ne

disposent pas d'information sur les autres départements. Au niveau de la direction, les rapports

de synthèses sont distribués à tous départements, mais ces rapports ne permettent pas de capter

l’image réelle sur l’état globale de l’entreprise. D’où vient le besoin d’avoir une vue globale

sur différents départements d’une entreprise.

De nombreuses grandes entreprises utilisent les systèmes d’informations appelées progiciel de

gestion d’entreprise ou Entreprise Ressources Planning (ERP), car ils fournissent un soutien

rentable pour les employés, superviseurs, chef de projet et gestionnaires de l'entreprise.

L’ERP est prévu d'améliorer le flux de l'information et de formaliser, intégrer et automatiser

tous les processus et les flux de travail qui existent dans une organisation. L’ERP peut exécuter

des fonctions effectuées par les employés comme l’enregistrement des données, le contrôle des

procédures, les calculs ou la préparation des rapports.

Les ERP sont des applications permettant de coordonner l'ensemble des activités d'une

entreprise (activités dites verticales telles que la production, l'approvisionnement ou bien

horizontales comme le marketing, les ventes, la gestion des ressources humaines, etc.) autour

d'un même système d'information. Ils offrent à l'entreprise, une solution globale et transversale

[1]. Notamment, il garantit la fiabilité la non redondance et non modification non permise des

informations ainsi qu’il permet la visibilité en temps réel des activités et d’éviter la double

saisie.

Les principaux éditeurs des ERP propriétaires du marché on peut citer SAP (leader mondiale),

Oracle/People Soft, Sage ADONIX, Microsoft, SSA Globale etc. Microsoft vend des ERP,

2

nommé Dynamics tel que Microsoft Dynamics Navision pour petites et moyennes entreprises

et Dynamics Axapta pour les entreprises de grande taille.

Dans le cadre de stage d’été de la deuxième année ingénierie informatique, nous avons visité

une société travaillant dans le consulting ERP Microsoft. ODI.C Sarl est spécialisée dans le

domaine du consulting, sur les deux solutions de Microsoft Dynamics Navision et Axapta. Elle

prend en charge l’intégration ERP, la réalisation d’audit, le suivie des spécifications, la

formation des utilisateurs support clients et le suivie des projets. Les consultants en entreprise

sont des professionnels, qui se spécialisent dans le développement de techniques et de méthodes

pour faire face à la mise en œuvre et les différents problèmes. Ils sont experts dans

l’administration, la gestion et le contrôle des projets.

Le projet tel qu’il m’a été présenté à ODI.C consiste à développer une application sur Dynamics

Ax, permettant de gérer la totalité des dossiers de demande de Visa des employés d’une

compagnie libyenne d’activité pétrolière. Ce projet devra inclure la traduction des documents

en arabes à des prototype puis la conception et création des formulaires Dynamics Ax.

Afin de réaliser ces tâches, il sera nécessaire de définir les besoins fonctionnels ou cas

d’utilisation, et créer une nouvelle table dite VisaRequest.

Ce travail sera traité en deux chapitres. Le premier sera consacré à étudier l’environnement de

travail professionnel et technique ce qui inclut une étude de l’aspect technique et fonctionnel

de l’ERP Dynamics Ax. Le deuxième se penchera sur l’analyse et la conception de la solution

adéquate. En fin, nous montreront les formulaires que nous avons réussi à développer et nous

finirons par une conclusion rappelant les travaux réalisés.

3

Chapitre I. Contexte de Projet

1.1 Introduction

Dans ce chapitre nous présenterons le contexte général du projet. Nous commencerons par

présenter la société « ODIC ». Nous allons détailler les services qu’elle offre ainsi que les

domaines de compétences qui font sa renommée. Ensuite, nous introduisions le cadre général

de notre travail. Enfin nous présentant l’état de l’art et le problématique.

1.2 Présentation de l’entreprise d’accueil

Ce projet a été réalisé au sein de la société « Organisation Développement Intégration et

Consulting » ou « ODI.C » qui peut se targuer d’être le leader en Tunisie dans le domaine

d’intégration des progiciels centralisant les données et les fonctions de gestion de l'entreprise

dit « Progiciel de Gestion Intégrer » ou encore PGI de type « Microsoft Dynamics Axapta »

ODI.C une société de conseil en informatique spécialisée dans la mise en œuvre d’E.R.P. ODIC

Sarl est fondée en 2007 en Tunisie, ayant un effectif de 20 collaborateurs. Elles offrent des

solutions pour plus de 20 clients en Tunisie et à rangé pour les domaines d’industrie, textiles et

pétrole.

Objectifs

Les objectifs d’ODI.C se résument dans l’assistance des clients dans la définition de leur

politique informatique. Puis l’accompagnement des clients dans le développement de leur

système d’information, Anticipation des évolutions. Enfin le support des clients lors de la

gestion de leurs données.

Domaines d’activités

ODIC travaille dans trois domaines d’activités, ce sont : le consulting organisationnel, la mise

en place de système d’informations et l’analyse et exploitations des bases de données. Le

consulting est constitué des activités de la mise en place et suivi de l’application, les méthodes

de gestion ; stocks, ventes et approvisionnement …la mise en place de système d’information

consiste à l’assistance au déploiement d’ERP, la maîtrise d’ouvrage sur des projets ERP et

infrastructure, la gestion de projets, l’intégration et le développement de l’ERP Dynamics

Navision et Dynamics Axapta. En fin l’analyse des données consiste à développer le reporting

et business intelligence spécifique en utilisant les outils les outils BI de Microsoft.

4

1.3 Présentation du projet

L’objectif du stage consiste à développer un module de gestion des visas des employés dès

l’élaboration d’une demande vers la clôtures de leurs visas. Dans cette partie nous allons

présenter les motivations de choix du sujet et l‘objectif du projet.

Motivations

Le choix du projet de stage d’été est une étape délicate, puisqu’elle matérialise la transaction

entre l’environnement éducationnel et la vie professionnelle.

Plusieurs motivations ont orienté notre choix :

En premier lieu, notre sujet fait le lien entre nos atouts qui sont l’informatique et la gestion.

En second lieu, l’ERP est devenu un sujet très important voire un sujet d’actualité. Il est au

cœur des préoccupations de toutes les entreprises qui cherchent à automatiser ses processus

métiers.

En troisième lieu, il nous permet d’approfondir encore plus nos connaissances en matière

d’ingénierie informatique en ayant l’occasion de travailler avec des technologies innovantes

telle que la technologie MorphX et SQL Server 2012.

Objectif du projet

Le travail demandé consiste à concevoir et à implémenter un module de gestion et suivi de visa

des employés d’une entreprise travaillant dans le domaine de production pétrolière. Notre

objectif est de développer une application Dynamics Ax qui permet le suivie des dossiers de

demande de visa en traduisant les documents de demande de visa en arabe en des formulaires.

1.4 Méthodologie et formalisme adoptées

Le plus grand avantage d’une méthode orientée objet est qu’elle permet de structurer un

système sans centrer l’analyse uniquement sur les données ou uniquement sur les traitements

mais sur les deux à la fois. Une telle approche a pour but de modéliser les propriétés statiques

et dynamiques de l’environnement du système. Elle met en correspondance le problème et la

solution, en préservant la structure et le comportement du système analysé.

Ceci, nous a conduit à adopter l’approche orientée objet pour modéliser notre système en se

basant sur les diagrammes UML [3].

La figure I-1 illustre les diagramme d’UML. Nous allons utiliser le diagramme de classe afin

de modéliser l’aspect statique du module, le diagramme de cas d’utilisation afin de modéliser

l’aspect fonctionnel.

5

1.5 Etat de l’art

Dans cette partie nous allons présenter l’état de l’art de notre projet. Donc cette partie nous

allons détailler le système existant (l’ERP Dynamics Ax). Ainsi que nous allons présenter la

problématique du projet.

Entreprise Ressource Planning

Un ERP est un « logiciel qui permet de gérer l’ensemble des processus d’une entreprise en

intégrant l’ensemble des fonctions de cette dernière comme la gestion des ressources humaines,

la gestion comptable et financière, l’aide à la décision, et aussi la vente, la distribution,

l’approvisionnement, la commerce électronique ».

Microsoft Dynamics

Dynamics est une gamme de progiciels de gestion d’entreprise conçue par Microsoft. Cette

gamme, qui fut également connue sous le nom de Project Green. Il est le successeur de

l’ancienne famille de logiciels destinée à la gestion d’entreprise, Microsoft Business Solutions.

Il est présent dans 28 pays pour un effectif de 4 000 salariés. Il inclut les logiciels suivants,

Dynamics Ax, Dynamics GP (anciennement Great Plains), Dynamics NAV (anciennement

Navision) et Dynamics SL (anciennement Solomon). Étude fonctionnelle de Dynamics Ax.

Ax est un ERP générique conçu pour les entreprises de 200 à 7500 utilisateurs. Il soutient les

organisations mondiales en gérant plusieurs sites opérationnels par le biais de Master data et

les processus métier. Ainsi que les capacités propres à chaque pays sont gérées en une seule

instance.

Figure I-1 : Les différentes vues du langage UML

6

Architecture fonctionnel de Dynamics AX

La solution Microsoft Dynamics AX est un progiciel de gestion intégré PGI (ERP Entreprise

Resource Planning) qui intègre la gestion des ressources financière, la gestion de la chaine de

production, et le processus de gestion des ressources humaines (cf. figure I-2). Dynamics AX

inclut des fonctionnalités embarquées pour les secteurs de l’industrie, de la distribution, des

services, du commerce et y compris le secteur public [2].

La figure ci-dessus illustre un aperçu sur l’architecture fonctionnel de Dynamics Ax. Cette

architecture englobe aussi les fonctions de vente et marketing, des outils de reporting et

l’informatique décisionnel ainsi que le workflow et l’espace de travail collaboratif.

Enfin nous avons fait une étude sur le module gestion des ressources humaine existants tels que

List Page Workers.

La figure ci-dessus illustre la page liste des employées. Nous allons personnaliser cet interface.

MS

Dynamics

AX

Gestion Financiére

production

Approvisionnement

Marketing et VentesGestion de

projet et comptabili

té

Gestion des Ressources Humaine

Décisionnel et reporting

Espace de travail

collaboratif

Figure I-2 : Architecture fonctionnel d’AX [W1]

Figure I-3 : WorkerList Page

7

Architecture en couches de Dynamics Ax

Le tableau I-1 illustre chaque couche dans Microsoft Dynamics Ax. Nous allons créer notre

module sur la couche VAR.

Tableau I-1 : Modèle de couches de Dynamics Ax

Architecture Technique de Dynamics Ax

L'architecture logique du système est une architecture 3tier (cf. figure I-4). Divisée en trois

niveaux ou couches : niveau Accès aux données, niveau intermédiaire, niveau présentation.

Niveau accès aux données

La base de données est gérée par MS SQL Server 2012. Le serveur de base de données héberge

le contenu SharePoint Server et la configuration des bases de données, la base de données de

l’application, la base de données de SSRS et la base de données SSAS. Enfin les relations entre

les tables de la base de données sont gérées coté AOS (Application Object Server).

Niveau intermédiaire

Le niveau intermédiaire comprend le serveur Application Object Server. L’AOS est le serveur

d’application de MS Dynamics Ax. C’est là où le logique métier s’exécute. Notamment l’AOS

permet d’exécuter des services d'application MorphX. Les services sont invoqués par la

technologie RPC et Windows Communication Foundation (WCF) dans le .NET Framework.

L’AOS peut être hébergé sur un ordinateur, mais il peut aussi évoluer sur de nombreux

ordinateurs lorsque des sessions utilisateur simultanées supplémentaires ou des serveurs dédiés

sont nécessaires.

Couche Description

USR User layer : La couche d’utilisateur pour les modifications réalisé par l’utilisateur, tels que les

rapports.

CUS Customer layer : La couche de client permet d’apporter des modifications qui sont spécifiques à

une entreprise.

VAR Value Reseller layer : Revendeurs à valeur ajoutée (VAR) peut apporter des modifications ou de

nouveaux développements de la couche VAR comme spécifié par les clients ou comme une

stratégie de création d’une solution spécifique de l’industrie.

ISV Independent software vendor layer : Quand un fournisseur indépendant de logiciels (ISV) crée

sa propre solution, les modifications sont enregistrées dans la couche ISV.

SLN Solution layer : La couche de solution est utilisée par les distributeurs à mettre en œuvre les

solutions des partenaires verticaux.

FPK Feature Pack layer : La couche FPK est une couche de brassage de l’objet de l’application

réservée par Microsoft pour les mises à jour.

GLS Globalisation layer : Lorsque l’application est modifiée en fonction de besoins juridiques propres

à chaque pays ou région, ces modifications sont enregistrées dans la couche GLS.

SYS System layer : L’application standard est mise en œuvre au niveau le plus bas, dans la couche

SYS. Les objets d’application dans la couche SYS ne peuvent jamais être supprimés.

8

Niveau présentation

Le niveua présentation est constitué du client Windows et Entreprise Portal. Le Client Windows

exécute les applications Microsoft Dynamics AX et .NET développées dans MorphX et Visual

Studio. L'application client communique avec l'AOS principalement en utilisant RPC (cf.

Figure I-4). Client Workspace ou Rich Client présente deux parties : navigation pane et content

pane. Navigation pane est le menu à gauche qui affiche tous les modules accessibles par

l’utilisateur selon son rôle défini. Le content Pane affiche tous les données spécifiques (reports,

alerts, tasks …) d’un module selon le rôle de l’utilisateur. Ils existent des patterns d’interface

de Dynamics Ax : nous allons utiliser seulement : ListPage, MasterDétails, Transactional

Détails.

1.6 Problématiques

La gestion de demande de visa doit comprendre les demandes pour une mission temporaire,

demande de résidence temporaire, le renouvellement d’un visa de résidence temporaire,

l’extension d’un visa, la demande de sortie et entré etc. Le problème des systèmes de gestion

de visa c’est qu’il coute très cher. En fait ces applications ne permettent pas une interopérabilité

avec les autres modules de Dynamics ax tel que le module de gestion de ressources humaines.

Puis ces systèmes n’offrent pas la fonctionnalité de traduction vers d’autre langue tel que

l’arabe. Donc le développement d’un nouveau module Dynamics Ax de gestion de visa est

nécessaire afin de garantir les besoins de l’entreprise cliente.

1.7 Conclusion

Dans ce chapitre nous avons introduit la technologie d’ERP Dynamics AX de Microsoft. Nous

avons détaillé l’aspect fonctionnel et technique de cet ERP. Nous avons présenté les outils de

développement que nous allons utiliser afin d’implémenter notre application. Ainsi que nous

avons présenté les différents outils de Reporting utilisé au niveau de Dynamics Ax. Plus

précisément l’outil de SSRS qui sera la suite de notre projet si enfin nous avons terminé avec

les formulaires.

Figure I-4 : Architecture technique d’AX

9

Chapitre II. Mise en œuvre

2.1 Introduction

Dans ce chapitre nous allons détailler le design de notre application en mettant en œuvre

l’expérience utilisateur. Afin de concevoir une application en suivant les patterns de Dynamics

Ax nous allons réaliser le prototypage. Avons tous nous allons définir les besoins de l’utilisateur

puis concevoir la structure de données. Enfin nous allons réaliser les interfaces utilisateurs.

2.2 Spécification des besoins

Afin de dégager les besoins de notre application nous avons examiné les différents documents

(version papier) de demande de visa d’une employée. Nous avons convertie chaque document

en un prototype.

Diagramme de cas d’utilisation générale

Cette étude nous a donné les cas d’utilisation suivant :

Demander visa pour une mission temporaire

Demander visa de résidence temporaire

Renouveler un visa de résidence temporaire

Extension d’un visa

Demander visa de sortie et entré pour un seul voyage

Demander visa de sortie et entré pour plusieurs voyages

Déclarer un changement de données

Demander visa de sortie finale

Demander visa business trip

Choisir catégorie de visa

Imprimer information

Chaque cas d’utilisation peut être fini par l’exécution d’un cas d’utilisation de reporting

imprimer information (cf. Figure II-1).

10

La figure ci-dessus illustre le diagramme de cas d’utilisation générale.

Figure II-1 : Diagramme de cas d'utilisation générale

11

Prototypes

Afin de développer un prototype nous avons choisi GUI design Studio. C’est un logiciel

professionnel qui permet de crée des maquettes pour le design des interfaces graphique des

utilisateurs pour les applications windows. GUI design studio permet de vérifier le design,

documenter la spécification des besoins, évalué les différents scénarios et démontrer les

prototypes. Afin de convertir les informations citées sur les papiers de visa en arabe à des

informations numérique en anglais, nous avons créé pour chaque document un prototype.

La figure ci-dessus illustre le prototype de la page de type List Page. Nous envisageons à

afficher les détails d’une demande et les informations du demandeur.

Figure II-2 : Prototype List Page

12

La figure ci-dessus illustre le prototype du document de demande de visa de sortie terminale.

Figure II-3 : Prototype demande de visa de sortie terminale

13

La figure ci-dessus illustre le prototype de la demande d’une entrée et sortie pour plusieurs

voyages.

Figure II-4 : Prototype demande de visa entré sortie pour plusieurs voyages

14

La figure ci-dessus illustre le prototype converti du document d’une demande de visa pour une

mission temporaire.

Figure II-5 : Prototype Demande de visa pour une mission Temporaire

15

La figure ci-dessus illustre le prototype converti du document demande de visa pour une entrée

et sortie pour un seul voyage.

Figure II-6 : Prototype demande de visa pour une entré sortie un seul voyage

16

La figure ci-dessus illustre le prototype converti du document d’une demande de visa pour une

résidence temporaire.

Figure II-7 : Prototype Demande de visa pour une résidence temporaire

17

2.3 Conception

Afin de concevoir notre module, nous avons créé le modèle conceptuel de données avec la

spécification des relations et clé primaires. En effet un employé inscrit dans les activités de

l’entreprise peut être affecté à une nouvelle demande de visa.

Une demande de visa est relative à un et un seul employé

Un employé peut être affecté à un ou plusieurs demandes de visa

La figure ci-dessus illustre le modèle conceptuel de données qui permet de convertir les

Business rules à des entités et relations.

VisaRequest

#

o

o

o

o

o

o

o

o

o

o

NumVisa

ResidenceN

DateExpiration

ResidenceType

Travel to

ReasonOfTrip

DateOFTrip

PasseportNum

ExpirationPasseport

DateIssue

PlaceIssue

Number

Number

Date

Text

Text

Text

Date

Number

Date

Date

Text

Person

#

o

o

o

PersonID

FirstName

LastName

PersonBirthCountryRegion

Number

Text

Text

Text

HCMWorker

#

o

o

o

reqId

coût($/H)

Partitien

PersonelNumber

Integer

Number

Variable characters (254)

Variable characters (254)

HCMPersonPrivateDetails

o

o

o

o

o

o

o

o

o

o

o

BirthDate

CitizenshipCountryRegion

DeceasedDate

DisabledVerificationDate

Education

EthnicOrigin

FatherBirthCountryRegion

Gender

IsDisabled

IsFullTimeStudent

NativeLanguage

Date

Text

Date

Boolean

Text

Text

Text

Short integer

Boolean

Boolean

Text

demander pour

1,1

0,n

détail

1,1

0,n

identifier par

1,10,n

Figure II-8 : Modèle conceptuel de données

18

Nous avons défini le diagramme de classe avec une précision de nouvelles classes. Nous avons

ainsi ajouté la classe VisaRequest dans le systéme existant. La figure ci-dessus le diagramme

de classe de module.

Tableau II-1 : Liste des classes

Classe Détails

HCMPersonPrivateDetails Permet de stocker les information privées d’un employé afin de

l’utiliser dans la demande de visa.

HCMWorker Permet d’explorer la liste des employé inscrit dans l’entreprise, qui

peuvent être candidatas d’une acceptation de visa

Person Permet de stocker les détails d’une personne

VisaRequest Créer afin de stocker les informations relatives à une demande de

visa pour un employé candidat d’une sortie

Le tableau ci-dessus illustre les détails des classes du module.

VisaRequest

+

+

+

+

+

+

+

+

+

+

+

NumVisa

ResidenceN

DateExpiration

ResidenceType

Travel to

ReasonOfTrip

DateOFTrip

PasseportNum

ExpirationPasseport

DateIssue

PlaceIssue

: double

: double

: Date

: String

: String

: String

: Date

: double

: Date

: Date

: String+

+

+

Add ()

Update ()

Delete ()

Person

+

+

+

+

PersonID

FirstName

LastName

PersonBirthCountryRegion

: double

: String

: String

: String

HCMWorker

+

+

+

+

reqId

coût($/H)

Partitien

PersonelNumber

: int

: double

: String

: String

HCMPersonPrivateDetails

+

+

+

+

+

+

+

+

+

+

+

BirthDate

CitizenshipCountryRegion

DeceasedDate

DisabledVerificationDate

Education

EthnicOrigin

FatherBirthCountryRegion

Gender

IsDisabled

IsFullTimeStudent

NativeLanguage

: Date

: String

: Date

: boolean

: String

: String

: String

: short

: boolean

: boolean

: String

Figure II-9 : Diagramme de classe

19

Nous avons transformé le modèle orienté objet en modèle physique de données. Notamment le

modèle physique de données permet de valider le schéma de la base de données en spécifiant

les clés étrangères à partir des cardinalités et relations entre classes.

Afin de créer la table VisaRequest nous avons utilisé les champs des tables HCMWorker,

HCMApplicant (candidature) et HCMPerson.

La figure ci-dessus illustre la table existante HCMPersonPrivateDetails et la table DirPerson.

VisaRequest

NumVisa

reqId

ResidenceN

DateExpiration

ResidenceType

Travel to

ReasonOfTrip

DateOFTrip

PasseportNum

ExpirationPasseport

DateIssue

PlaceIssue

numeric

int

numeric

datetime

varchar(254)

varchar(254)

varchar(254)

datetime

numeric

datetime

datetime

varchar(254)

<pk>

<fk>

Person

PersonID

FirstName

LastName

PersonBirthCountryRegion

numeric

varchar(254)

varchar(254)

varchar(254)

<pk>

HCMWorker

reqId

PersonID

coût($/H)

Partitien

PersonelNumber

int

numeric

numeric

varchar(254)

varchar(254)

<pk>

<fk>

HCMPersonPrivateDetails

PersonID

BirthDate

CitizenshipCountryRegion

DeceasedDate

DisabledVerificationDate

Education

EthnicOrigin

FatherBirthCountryRegion

Gender

IsDisabled

IsFullTimeStudent

NativeLanguage

numeric

datetime

varchar(254)

datetime

bit

varchar(254)

varchar(254)

varchar(254)

smallint

bit

bit

varchar(254)

<fk>

reqId = reqId

0..*

PersonID = PersonID

0..*

PersonID = PersonID0..*

Figure II-11 : Schéma relationnel de la base de données

Figure II-10 : Table DirPerson et HCMPersonProvateDetails

20

la figure ci-dessus illustre la table HCMWorker.

2.4 Environnement de développement

Microsoft Dynamics AX comprend un ensemble d'outils de développement ou IDE, que nous

pouvons utiliser pour construire et modifier notre application.

La figure ci-dessus illustre le workspace développeur nommé MorphyX. Nous avons utilisé cet

outil afin de créer les tables, les énumérations, les type de données étendues dans le dictionnaire

de donnes et les formulaires.

MorphX IDE

MorphX est un environnement intégré de développement dans Microsoft Dynamics AX qui

permet de développer des modèles de données et des codes en utilisant un outil de modélisation

Figure II-13 : MorphyX le Developper Workspace

Figure II-12 : Table HCMWorker

21

de l'application AOT (Application Object Tree). Ainsi qu’il permet de réaliser des

personnalisations faites graphiquement pour concevoir des types de données, des tables, des

requêtes, des formulaires, des menus et des rapports. Cet environnement de développement

accède aux services de serveur d'applications AOS grâce à RPC (Remote Procedure Call) [2]

L’AOT est le point principal pour l’activité de développement. Il permet de parcourir le

référentiel (repository) de tous les éléments qui composent l’application. Nous pouvons utiliser

l’AOT pour invoquer des autres outils et d'inspecter et de créer des formulaires, des Rapports

et des Requêtes.

Langage X++

Le langage utilisé pour développer des applications Dynamics AX se nomme X++. Il s’agit

d’un langage respectant les principes de la programmation orientée objet tels que

l’encapsulation, l’héritage, les classes, les objets, les méthodes et les propriétés. La syntaxe du

langage X++ est proche de celle du langage C# ou java. Ajoutons aussi que X++ permet la

manipulation des données par l'intermédiaire du langage SQL [2].

La figure ci-dessus illustre l’éditeur de code X++ sous MorphX.

Pattern de formulaire de Dynamics Ax

Les formulaires sont créés de telle sorte que l'utilisateur final peut entrer et afficher des données

de manière flexible. Les patterns de formulaires permettent la navigation plus facile pour

l'utilisateur final, les menus et les options de menu sera créé sur tout type de formulaire.

Type des formulaires

List Page

Figure II-14 : MorphX IDE éditeur de code X++

22

DetailsFormMaster

DetailsFormTransaction

SimpleListDetails

SimpleList

TableOfContents

Dialogue

DropDialog

Service de reporting

Le terme "reporting" désigne une famille d'outils de business intelligence destinés à assurer la

réalisation, la publication et la diffusion de rapports d'activité selon un format prédéterminé.

[W6]. Le reporting permet de prendre des décisions stratégiques ou des actions sur la base des

connaissances acquises (analysis) à partir de sources de données. Il permet donc de réduire la

charge du service informatique grâce à l’auto-génération de rapports. SQL Server Reporting

Services crée des rapports standards ou personnalisables. [W1] Microsoft SQL Server

Reporting Services est la plateforme basique de reporting dans Microsoft Dynamics AX.

2.5 Architecture de l’application

Elle est constituée généralement de trois niveaux : l’interface utilisateur, le logique métier et la

structure de donnée (cf. figure24).

Nous allons développer des formulaires et des menus constituant l’interface utilisateur. Puis

nous allons attacher pour chaque interface des classes constituant le logique métier de notre

module. Mais avons tous allons créer une table constituant la structure de données de notre

module.

User Interaction

(Layout)

Forms

Menus

Business Logic

Classe

Méthode

Data Structures

Data Dictionnary

Tables

Filds

Figure II-15 : Architecture d'une Business Application

23

2.6 Réalisation

Dans cette phase, les concepts et les objectifs sont traduits en actions concrètes, et en

conséquence, il est peut-être l’une des phases les plus difficiles du projet. Nous décrivons

brièvement les interfaces créées.

24

Le premier formulaire qui s’affiche dans l’application est le List Page. Il fournit une vue simple

et ergonomique.

Nous pouvons ajouter une nouvelle demande de visa en cliquant sur le boutant new ou nous

pouvons modifier un enregistrement sélectionné. La figure ci-dessus illustre l’interface listPage

de demande de visa.

La figure ci-dessus illustre la page de type master détails de gestion de demande de visa.

Figure II-17 : Interface Visa Request Master Détails Page

Figure II-16 : Interface Visa Request List page

25

Si l’utilisateur a choisi de modifier les enregistrements il peut ouvrir la grille de modification

pour éditer les enregistrements. La figure ci-dessus illustre la page de modification de la

demande sur la grille.

La figure ci-dessus illustre l’interface master détails de gestion de gestion d’un visa.

Or, si l’utilisateur a choisi de modifier un enregistrement particulier il peut continuer avec le

formulaire type détails page et modifier sur la grille.

La figure ci-dessus illustre l’interface de modification dans la grille.

Figure II-19 : Interface de grille de Modification de demande de Visa

Figure II-18 : Interface Master Détails page de gestion de visa pour un employé

26

La figure ci-dessus illustre l’interface de gestion des demandes de type Transactional détails.

Ce formulaire à deux pages : en tête et ligne.

La figure ci-dessus illustre la vue en tête de la page Transactional détails d’ajout d’une

demande. Dans cette page l’utilisateur peut ajouter les dépendants d’un demandeur de visa dans

la grille.

Figure II-21 : Interface transactionnel Détails Page vue ligne

Figure II-20 : Interface vue en tête de la page Transactional détails d'ajout de demande

27

2.7 Conclusion

Dans ce chapitre nous avons réussi à définir exactement les besoins fonctionnels de notre

application en utilisant le diagramme de cas d’utilisation et les prototypes. Puis nous avons

réussi à concevoir le module en utilisant le diagramme de classe et les modèles physique et

conceptuel. Ainsi que nous avons présenté les différents formulaires que nous avons réussis à

implémenter.

28

Conclusion générale

Ou cour de ce stage d’été nous avons bénéficié d’une expérience enrichissante du milieu

professionnel. Nous avons profité d’une expérience théorique et pratique afin de saisir les

différents aspects technique et fonctionnels d’un ERP Puissant : Dynamics Ax. Alors, Nous

avons eu deux semaines pour la recherche des informations relatives à cet ERP. Puis nous avons

eu deux autres semaines pour faire des études pratiques des différents composants et outils de

développement sur Dynamics Ax. Nous avons réalisé la spécification des besoins en deux

semaines et une autre pour la conception. Afin de réaliser la spécification des besoins nous

avons converti les documents de visa en arabe en des prototype en anglais. Puis nous avons

réalisé les interfaces dans une semaine.

Enfin, nous avons réussi à concevoir et à implémenter un module de gestion des demandes de

visa sous les exigences demandés et les standards de Microsoft Dynamics Ax.

Notre module nécessite d’autre amélioration en termes de navigation entre formulaires et design

de l’expérience utilisateur. Ainsi qu’une extension de ce module peut être le sujet d’une

perspective. Nous pouvons donc développer une application mobile qui permet de gérer les

visas en communiquant avec notre module.

Bibliographies

[1] Enterprise Resource Planning by Alexis Leon L&L Consultancy Services Prt Ltd Chennao

Tata McGraw-Hill Publishing Company Limited New Delhi

[2] Inside Microsoft Dynamics® AX 2012, by the Microsoft Dynamics AX Team, Published

by Microsoft Press

[3] Microsoft Dynamics AX 2012 – Une nouvelle génération de système ERP AD Ultima

Group

[4] Microsoft System Center Reporting Cookbook Samuel Erskine Dieter Gasser Kurt Van

Hoecke Nasira Ismail BIRMINGHAM - MUMBAI

Webographies

[W1] https://msdn.microsoft.com Consulter le 29/07/2015

[W2] https://community.dynamics.com/ Consulter le 31/7/2015

[W3] https://technet.microsoft.com Consulter le 30/7/2015

[W4] http://www.ignify.com/axapta.asp Consulter le 30/7/2015

[W5] http://blogs.adobe.com/ consulter le 31/07/15

[W6] http://www.piloter.org/ consulter le 03/08/2015

[W7] https://www.youtube.com/ Consulter le 16/08/2015