PROGRAMUL DE STUDIU: MANAGEMENT ÎN TEHNOLOGIA INFORMAȚIEI FORMA DE ÎNVĂȚĂMÂNT: ÎNVĂȚĂMÂNT CU FRECVENȚĂ Disertație COORDONATOR ȘTIINȚIFIC Prof. Ing…. [621173]

UNIVERSITATEA DIN ORADEA
FACULTATEA DE INGINERIE ELECTRICĂ
ȘI TEHNLOGIA INFORMAȚIEI
PROGRAMUL DE STUDIU: MANAGEMENT ÎN
TEHNOLOGIA INFORMAȚIEI
FORMA DE ÎNVĂȚĂMÂNT: ÎNVĂȚĂMÂNT CU FRECVENȚĂ

Disertație

COORDONATOR ȘTIINȚIFIC
Prof. Ing. Dr. GYŐRÖDI ROBERT

ABSOLVENT: [anonimizat]
2017

2
UNIVERSITATEA DIN ORADEA
FACULTATEA DE INGINERIE ELECTRICĂ
ȘI TEHNLOGIA INFORMAȚIEI
PROGRAMUL DE STUDIU: MANAGEMENT ÎN
TEHNOLOGIA INFORMAȚIEI
FORMA DE ÎNVĂȚĂMÂNT: ÎNVĂȚĂMÂNT CU FRECVENȚĂ

Studiu comparativ între modalități de
dezvoltare a extensiilor mobile pentru
Microsoft Dynamics 365 for Operations

COORDONATOR ȘTIINȚIFIC
Prof. Ing. Dr. GYŐRÖDI ROBERT

ABSOLVENT: [anonimizat]
2017

3
UNIVERSITATEA DIN ORADEA
FACULTATEA DE INGINERIE ELECTRIC Ă ȘI TEHNOLOGIA INFORMAȚIEI
DEPARTAMENTUL CALCULATOARE ȘI TEHNOLOGIA INFORMAȚIEI

TEMA Studiu comparativ între modalități de dezvoltare a extensiilor mobile pentru
Microsoft Dynamics 365 for Operations

Lucrare de Finalizare a studiilor a student: [anonimizat]
1). Tema lucrării de finalizare a studiilor: Studiu comparativ între modalități de dezvoltare
a extensiilor mobile pentru Microsoft Dynamics 365 for Operations
2). Termenul pentru predarea lucrării: 05.07.2017
3). Elemente inițiale pentru elaborarea lucrării de finalizare a studiilor
Microsoft Dynamics 365 for Operations
Xamarin
4). Conținutul lucrării de finalizare a studiilor:
Capitolul 1 – Introducere
Capitolul 2 – Planificarea Resurselor Întreprinder
Capitolul 3 – Tehnologii Folosite
Capitolul 4 – Studiu comparativ între două abordări de dezvoltare a extensiilor ERP
Capitolul 5 – Concluzii
Bibliografie
5). Material grafic : Imagini prin care se prezintă studiul co mparativ , screenshoturi, scheme
bloc
6). Locul de documentare pentru elaborarea lucrării:
Biblioteca Universității Oradea
Sala V205
7). Data emiterii temei : octombrie 2016

Coordonator științific
Prof. Ing. Dr. GYŐRÖDI ROBERT

4
Cuprins

1 Introducere ………………………….. ………………………….. ………………………….. …………………………. 5
2 Planificarea Resurselor Întreprinderii ………………………….. ………………………….. …………………. 7
2.1 Aspecte generale ………………………….. ………………………….. ………………………….. ………….. 7
2.2 Interfețele utilizator ………………………….. ………………………….. ………………………….. …….. 11
2.3 Extensii mobile pentru aplic ații ERP ………………………….. ………………………….. …………. 12
3 Tehnologii folosite ………………………….. ………………………….. ………………………….. …………….. 14
3.1 Microsoft Dynamics 365 for Operations ………………………….. ………………………….. …….. 14
3.2 Visual Studio ………………………….. ………………………….. ………………………….. ……………… 17
3.3 Dynamics 365 for Operations Mobile App ………………………….. ………………………….. …. 19
3.4 Aplicații cross -platform mobile ………………………….. ………………………….. ………………… 21
3.5 Xamarin ………………………….. ………………………….. ………………………….. …………………….. 22
4 Studiu comparativ între două abordări de dezvoltare a extensiilor ERP …………………………. 23
4.1 Prezentarea proiectului ………………………….. ………………………….. ………………………….. … 23
4.2 Extinderea soluției Dynamics 365 for Operations ………………………….. ……………………. 24
4.3 Dezvoltarea aplicațiilor middleware ………………………….. ………………………….. ………….. 28
4.4 Dezvoltarea aplicației mobile ………………………….. ………………………….. ……………………. 32
4.5 Prezentarea aplicațiilor ………………………….. ………………………….. ………………………….. … 41
4.6 Sumarea diferențelor dintre abordările de dezvoltare ………………………….. ……………….. 43
5 Concluzii ………………………….. ………………………….. ………………………….. ………………………….. 44
6 Bibliografie ………………………….. ………………………….. ………………………….. ………………………. 45

5
1 Introducere

Aceast ă lucrare are ca scop realizarea unui studiu comparativ între modalități le de
dezvoltare a aplicațiilor mobile pentru gesti onarea resurselor întreprinderi i folosind Microsoft
Dynamics 365 for Operations.
Evoluția fără precedentă a tehnologiilor de informație și de comunicare bazate pe hardware
și software a influențat toate aspectele a aplicațiilor de calcul din întreprinderile . În același timp,
mediul de afaceri a devenit din ce în ce mai complex cu unități funcționale care necesită un flux
de date pentru luarea deciz iilor, achiziționarea în timp a pieselor de producție, gestionarea
inventarului, contabilitatea, resurse umane, respectiv distribuția bunuril or și serviciilor. În acest
context, gestionarea întreprinderilor necesită sisteme de informație eficiente care îmbunătățesc
performanțele organizațiilor prin reducerea costurilor și prin asigurearea unei logistici mai bune.
Ca un răspuns pentru aceste pro vocări au apărut sistemele de planificare a resurselor întreprinderii.
Sistemele de planificare a resurselor întreprinderii (Enterprise Resource Planning, ERP)
asigură integrarea tuturor proceselor ale unei întreprinderi într -un singur sistem de informați e.
Aceste sisteme sunt alcătuite din aplicații softw are modulare, care ajută o întreprindere atât cu
module prin care compania stă în legătură directă cu clienții (front -office) cât și cu module prin
care se planifică, se gestionează , respectiv se coordonează producția produselor (back -office).
Aceste sisteme au o interfață utilizator prin care toate datele, procese ale întreprinderii
poate să fie urmărit e în timp real. Interfețele utilizator au evoluat împreună cu sistemele ERP,
furnizând din ce în ce mai multe informații despre procesele întreprinderii, într-o manieră
prietenoasă . La început, interfețele utilizator au fost oferite prin intermediul aplicații lor desktop,
care au fost instalate pe calculatoarele utilizatoarelor. Următor ul pas în dezvoltarea interfețelor
utilizator era utilizarea paginilor web, care au oferit aceleași informații ca și soluțiile desktop, cu
avantajul că nu a necesitat instalare . Cu răspândirea dispozitivelor mobile, companiile software au
început să dezvol te extensii mobile pentru sistemele ERP, cu ajutorul cărora angajații întreprinderii
pot accesa sistemul ERP indiferent de locație. Aceste extensii ERP sunt aplicații mobile, cu
funcționalități mai restrânse, c onsiderând resursele limitate a dispozitivelo r mobile, respectiv
ratele de transfer de date mai lente de internet.

6
Sistemele ERP pentru întreprinderile mari sunt dezvoltate doar de către trei companii de
software: SAP, Oracle și Microsoft. Microsoft are gama proprie de soluții ERP, care poartă numel e
Dynamics 365 for Operations. În acest studiu, voi c ompara două abordări pentru dezvoltarea
extensiilor mobile pentru soluția Microsoft Dynamics 365 for Operations. Prima abordare constă
din dezvoltare a tradițională de aplicație mobilă cross -platformă, fo losind instrumentul de
dezvoltare Visual Studio, și frameworkul Xamarin. Termenul tradițional în acest caz înseamnă
crearea aplicației mobile “de la zero”, folosind limbaje de programare, și instrumente de dezvoltare
integrate. A doua metodă va prezenta o modalitate de dezvoltare care nu necesită neapărat
cunoștințe de programare. Această abordare folosește de aplicația Microsoft Dynamics 365 for
Operations Mobile App, care se poate descărca gratuit din magazine online de aplicații. În acest
caz, dezvoltarea aplicației se limitează la crearea workspaceurilor , a spațiilor de lucru ce va fi
disponibil pentru utilizator pr in intermediul aplicației mobile .
Capitolul 2 și 3 prezintă câteva aspecte teoretice despre sistemele ERP, arhitectura
acestora, respectiv câteva trăsătur i despre extensiile mobile ERP.
Tehnologiile și mediul de dezvoltare utilizat în cadrul acestei lucrări sunt prezentate în
capitolul 4 , în timp ce studiile de caz și comparațiile între cel e două abordări de dezvoltare a
extensiil or ERP mobile sunt prezentate în capitolul 5.
În ultimul capitol sunt prezentate concluziile studiului comparativ.

7
2 Planificarea Resurselor Întreprinderii

2.1 Aspecte generale

Planificarea resurselor întreprinderii (enterprise resource planning, ERP) reprezintă o
colecție mare de activități care facilitează gestionarea unei afaceri.
American Production and Inventory Control Society a definit sistemele ERP ca o metodă
pentru planificarea și controlul efectiv al tuturor resurselor necesare pentru a prelua, a efectua, a
distribui comenzile clienților într -o companie de producție , distribuție sau de service . (1) După o
altă definiție un ERP constă dintr -un pachet de software care presupune integrarea informațiilor
care circulă printr -o companie, în timp real, și într-o manieră vizibilă.
Arhitectural, un si stem ERP se constituie din aplicații front -office și back -office care
comunică direct cu un depozit de informații (Figura 1: Arhitectura unui si stem ERP ). Aplicațiile
front office reprezintă orice aplicație care au relație directă cu clienții. Ele ofer ă funcționalitățile
și datele necesare pentru preluarea comenzilor, configurarea produselor complexe, respectiv suport
pentru clienți. Câteva exemple pentru aplicații front office ar fi customer relationship management
(CRM), sales force automation, relați i clienți și muncă de teren .
Aplicațiile back office constă din acele module care sunt accesibile doar în cadrul firmei,
informațiile oferite de acestea fiind private, accesibile doar de angajații firmei . Aceste informații
reprezintă datele esențiale pentru funcționarea întreprinderii. Modulele back office oferă
funcționalități pentru operații interne, cum ar fi controlul inventarului, controlul și supravegherea
producție i, contabilitate, activități asociate cu furnizarea bunurilor, servicilor și al m aterialelor
prime.
Atât aplic ațiile front -office, cât și aplicațiile back -office salvează, respectiv citesc datele
dintr -un depozit de date central, asigurând integrarea tuturor informațiilor într -o singură locație .
Depozitul de informații este de regulă o bază de date relațională , întreținută de către un sistem de
gestionare de bază de date. Commented [MR1]: https://faculty.biu.ac.il/~shnaidh/zool
oo/nihul/evolution.pdf

8

Baza de date
centrală
Raportaje
Front -Office
Vânzări și
distribuție
Clien ții
Furnizori
Resurse umane
Aplicațiile
service
Aplicații
financiale
Aplicații de
producție
Gestionarea
inventarului
Back -Office

Figura 1: Arhitectura unui si stem ERP

Din punctul de vedere al componentelor funcționale, un sistem ERP are o arhitectură pe trei
niveluri (Figura 2: Arhitectură pe trei niveluri ), astfel se diferențiază nivelul de prezentare, nivelul
de aplicație, respectiv nivelul de baze de date. Nivelul de prezentare poate să conține aplicația
desktop, aplicația web, sau aplicaț ia mobilă, prin intermediul căror a se accesează datele din sistem.
Interfețele utilizator în cadrul unui sistem ERP sunt folosite de către utilizatorii pentru a vizualiza
datele unui proces, starea unei comenzi, de a urmări stocul materialelor prime, respectiv pentru a
crea entități noi , comenzi pentru materiale, etc .
Datele pentru interfața utilizator sunt furnizate de către nivelul mijlociu, nivelul de aplicație, ca re
include modulele back -office și front -office. Serverul de aplicație poate să fie găzduit atât local,
în cadrul firmei, cât și în cloud, astfel întreprinderea nu trebuie să gestioneze infrastruct ura
sistemului ERP. Nivelul trei este reprezentat de baza de date, care poate să fie g ăzduit ă și ea atât
local, cât și în cloud, sau printr -o manieră hibridă, păstrând datele mai sensibile într -un depozit
local de date .

9

Nivelul de prezentare
Nivelul de aplicație
Nivelul de baza de dateClienții
Serveri de aplicație
Serveri de baze de date
Figura 2: Arhitectură pe trei niveluri

Sistemele ERP sunt modulare, adaptându -se astfel la orice scenariu posibil dintr -o
întreprindere. Modulele care pot apare într -un sistem ERP (

10

Figura 3: Modulele cele mai comune ale sistemelor ERP ) :
• Contabilitate financiară : registru general , active fixe , datorii împreună cu vouchering ,
corespondență și plată , gestiune numerar , consolidare financiară
• Contabilitate de gestiune : bugetare , cost uri, gestionarea costurilor , costuri bazate pe
activități
• Resurse umane : recrutare, training, pl anificare, salarizare, beneficii, planuri de pensii,
managementul diversității, pensionare
• Producție : inginerie, factura de materiale, comenzi de lucru, planificare, capacitate,
gestionarea fluxului de lucru, controlul calității, procesul de fabricație, pr oiectele de
fabricație, fluxul de producție, gestionarea ciclului de viață a produsului
• Prelucrarea comenzilor : preluarea comenzii, intrarea comenzii, verificarea creditelor,
stabilirea prețurilor, invent ar, transport, analiza și raportarea vânzărilor, sales
commissioning

11
• Managementul lanțului de aprovizionare : planificarea lanțului de aprovizionare,
configurator de produse, order to cash, achiziționarea, inventarierea, claims processing,
depozitarea
• Management de proiect : planificarea proiectului, planificarea resurselor, costul
proiectului, work breakdown structure, facturare, timp și cheltuieli, unități de performanță ,
managementul activităților
• Relații cu clienți : vânzări și marketing, comisioane , servici , contactarea clienților, call
center support — sistemele CRP nu sunt întot deauna considerate ca fiind componente ale
sistemelor ERP
• Servici de date : Diferite interfețe self service pentru clienți, furnizor i și angajați

Figura 3: Modulele cele mai comune ale sistemelor ERP
Întreține relații cu clienți,
facilitează utilizarea
experiențelor clienților
Scopul este de a
eficientiza și a obține
un control mai mare
asupra serviciilor
corporative clienților
Întreține o bază de date a
angajaților să eficientizeze
angajații Automatizarea operațiuni lor
financiare Controlează procesele de
depozitare și gestionează
mișcările din depozit Ajută în planificarea și
optimizarea capacității de
producție și a materialelor
prime. A evoluat din MRP Maximizează economiile de
costuri cu sprijinul
proceselor de achiziții
publice și de logistică Include funcții de plasare a
comenzilor, programarea
comenzilor, expedierea,
facturare
Servici cu clienț i
(CRM)
Business Intelligence
Enterprise asset
management Comerț electronic
Multe altele Producție Achiziții
Vânzări
Guvernarea
întreprinderii
Resurse Umane Contabilitate Distribuție Analiza datelor
Gestionarea eficientă a
ciclului de viață pentru
resursele companiei

12
Implementarea unui sistem ERP pentru o întreprindere este un proces lung și complex. De
regulă, întreprinderile iau legătură cu consultanți ERP, care le ajută în alegerea unui sistem ERP.
Sistemele ERP sunt dezvoltate de către diferite vendori, care la crearea sistemel or ERP consideră
practici des utilizate în cadrul întreprinderilor. Best practices reprezintă acele procese care sunt
folosite de către mai multe firme, și despre care se consideră că aduce un benefit companiilor. La
alegerea unui sistem ERP se consideră ș i munca necesară de a adapta un sistem ERP la procesele
întreprinderii, dar în majoritatea cazurilor companiile decid schimbarea proceselor de muncă, ca
să se adapteze cât mai mult la sistemul ERP ales.
Procesul de dezvoltare/integrare unui sistem ERP poa te ține de la câțiva luni până la 2 -3
ani, în funcție de mărimea întreprinderii.
2.2 Interfețele utilizator

Partea cea mai importantă al unui si stem ERP este interfața utilizator, aceasta fiind
elementul prin care utilizatorii interacționează atât cu modulele front -office cât și cele back -office.
De aceea, interfața trebuie să garantează o experiență fluidă, prietenoasă, deoarece o interfață slab
făcută p oate să încetinească lucrul, respectiv să genereze o rezistență din partea angajaților către
sistemul ERP (2). Un factor important în crearea interfețelor utilizator îl constituie timpul de
răspuns a l aplicației. Sistemul trebu ie să fie suficient de rapid încât să fie aproape nesesizat
existența acestuia în majoritatea situațiilor. Serverele, și sistemele desktop trebuie să fie dotate cu
componente performante, acestea influențând producția angajaților cel mai mult.
Considerând că sistemul este suficient de performant, factorul următor în cre area unei
experiențe prietenoase este interfața utilizator în sine. Cheia succesului este ca toate
funcționalitățile oferite de aceasta să fie rapide, ușor de accesibile și ușor de utilizate . Partea cea
mai importantă în crearea unei interfețe este să ne asigurăm ca interfețele de intrare și de ieșire
sunt rapide, simpe de folosite, și cer și oferă doar informațiile esențiale. De exemplu, la crearea
unei comenzi noi, doar câmpurile relevante ar trebui afișate, respectiv, finalizarea comenzii ar
trebui să se întâmple instant. La af ișarea comenzilor existente, utilizatorul trebuie să aibă
posibilitatea de a căuta după comandă, folosind cuvinte de cheie.

13
Interfețele utilizator de obicei sunt con figurabile, astfel utilizatorul poate să -și seteze
mediul de lucru după preferințe personale. Modulele, și resursele afișate utilizatorului se poate
diferi și pe baza rolului acestuia în firmă. Acest aspect se realizează prin autentificarea utilizatorilor
în aplicație, și verificând rolul lor în companie. Astfel, de exemplu, muncitorii de pe producție nu
vor avea acces la modulele de contabilitate a sistemului ERP.
O altă trăsătură comună pentru interfețele de utilizator ale sistemelor ERP este existența
paginii Dashboard, punctul de intrare în aplicație. Această pagină conține modulele cele mai
folosite de utilizator, respectiv workspace -urile acestuia. Workspaceurile reprezintă spații de lucru
în cadrul interfeței, care concentrează pe compeletarea unei s arcini, oferind toate informațiile
necesare în acest scop.
Interfețele ERP permit utilizatorilor o colaborare mai eficientă, permitând împă rțirea
fișierelor, calendarelor, utilizatorii având posibilitatea de a crea directoare de fișiere partajate cu
coleg ii lor.
2.3 Extensii mobile pentru aplic ații ERP

Cu răspândirea dispozitivelor mobile, a apărut nevoia ca procesele întreprinderilor să fie
urmărite nu numai în cadrul întreprinderii, dar și în afara ei. Angajații pe drum, cum ar fi agenții
de vânzare, sau li derii întreprinderii au nevoie să pot accesa informații le din sistem, dar și să
introducă înregistrări noi, de exemplu un client potențial pe urma unei întâlniri. În acest context,
dezvoltatorii sistemelor ERP sunt nevoiți să dezvolte extensii mobile la si stemele ERP, cu ajutorul
cărora angajații pot viziona ș i opera pe informații esențiale (3).
În timp ce sistemele de gestionare a relațiilor cu clienți au extensii mobile de mai mult timp,
extinderea sistemelor ERP este un proces mai lent, din cauza faptului că sistemele ERP sunt de
multe ori atât de complexe încât orice modificare la acestea este riscantă. La dezvoltarea extensiilor
mobile, sunt nișt e aspecte ce trebuie respectate:
• Funcționalități: Aplicațiile trebuie să conține doar funcțiile esențiale care chiar ajută pe
angajatul în munca sa. Ideal, utilizatorul ar putea să creeze workflow -uri personaliza te, care
le-ar ajuta în lucru cât timp ei nu sunt la birou. Trebuie considerat și faptul că dispozitivele

14
mobile au resurse limitate, de aceea trebuie gândită cu mare atenție ce fel de procese sunt
accesibilie din aplicație
• Experiența de utilizato r: Aplica țiile mobile folosesci nternet ca să acceseze resurse de la
sistemul ERP, însă de mule ori conexiunea de internet poate să fie lentă, sau chiar absentă.
Astfel, aplicațiile trebuie implementate într -o manieră încât să permită introducerea datelor,
respectiv interogarea acestora și în cazul în care dispozitivul nu are acces la internet. Pentru
acest fapt se folosește de regulă un mecanism de caching, aplicația sincronizându -și datele
atunci când are acces la internet.
• Dimensiunea dispozitivului: Dispozitivele mobile au ecrane mai mici, de aceea sunt utile
pentru verificarea datelor pe drum, dar nu sunt potrivite pentru a prezenta o ofertă unui client
potențial
• Aplicații mobile vs. Web -apps: Implementarea unei extensii mobile ERP se poate realiza atât
prin dezv oltarea unei aplicații web, accesibilă doar de pe dispozitive mobile, sau prin
dezvoltarea unei aplicații native. Aplicațiile web au avantajul că dezvoltarea lor necesită mai
puțin timp, însă nu oferă aceleași performanțe precum o aplicație nativă
• Nu toți angajații au nevoie de aplicații mobile: Agenții de vânzare fiind mult pe drum, au
nevoie de aplicații mobile, dar lucrătorii de p e linia de producție nu au neapărat nevoie de
extensiile mobile ERP
• Ușor de utilizat: Este foarte important ca aplicația mobil ă să fie ușor de folosit, altfel angajații
nu o vor folosi. De exemplu, da că experiența de utilizator nu este destul de fluid, s -ar putea ca
vânzătorii să pi ardă clienți din aceasta cauză.
• Securitate a datelor: Utilizarea aplicațiilor mobile înseamnă ca ang ajații vor avea acces la
aceleași date, la care au acces și în birou, în cadrul întreprinderii , prin rețea locală, securizată.
Odată ce datele întreprinderii devin accesibile prin intermediul internetului, se pierde controlul
datelor, acestea fiind expuse la oameni malițioși. Din această considerare, trebuie luate măsuri
de securitate împotriva atacurilor posibile, altfel întreprinderea ar putea pierde date sensibile.

15
3 Tehnologii folosite

3.1 Microsoft Dynamics 365 for Operations

Microsoft Dynam ics 365 for Operations este un sistem ERP dezvoltat de către Microsoft
pentru întreprinderi medii și mari (4), și face parte din pachetul Microsoft Dynamics 365
Enterprise . Dynami cs 365 for Operations aparține generației nouă a soluțiilor ERP (5), permitând
soluția să fie găzduit ă atât în cloud public și cât și în cloud privat, sau local , pe serverele
întreprinderii.
Microsoft Dynamics 365 for Operations a fost dezvoltat inițial sub numele Axapta, de căt re
companiile IBM și Danish Damgaard Data (6), în anii 90 . Pe urmă, IBM și -a vândut toate
drepturile la Danish Damgaard Data, care a fuzionat cu Navision Software pentru a forma Navision
A / S . Compania a fost achiziționată în 2002 de către Microsoft, iar produsul Axapta a fost
redenumit în Microsoft AX. Ultima versiune a lui Microsoft AX a apărut în 2016 (versiuna 7, AX
7), sub denumirea Microsoft Dyna mics 365 for Operations. Neoficial, se mai folosește și
denumirea veche M icrosoft AX sau Microsoft AX 7, denumire pe care vom folosi și noi în
următoarele pagini .
Arhitectural, Microso ft Dyn amics AX urmărește arhitectura clasică a sistemelor ERP, fiind
un sistem alcătuit din trei niveluri, astfel în structura sistemului se poate diferenția trei componente
majore :
• Nivelul de baze date: s erverul de baze de date, care stochează atât datele cât și fișierele de
aplicație pentru Microsoft AX 7 . Baza de date este găzduită de către o instanță de Microsoft
SQL Server , care poate să ruleze local, pe serverele din infrastructura întreprinderii sau în
Azure cloud
• Nivelul de aplicație: nivelul mijlociu este reprezentat de către serviciul A pplication Object
Server(s) (AOS). Acest serviciu gestionează toate aspec tele al proc eselor Microsoft Dynamics
AX. În ultima versiune de AX , AOS este hostat de către serviciile IIS , care, similar cu nivelul
de baze de date, poate să fie găzduit atât local cât și în cloud

16
• Nivelul de prezentare: nivelul de prezentare este constituită dintr -o aplicație web (web client)
respectiv extensia mobilă Microsoft Dynamics 365 for Operations Mobile App

Figura 4: Aplicația web a soluției AX (web client)

În Figura 4: , se prezintă clientul web, care oferă interfața utilizator pentru Microsoft Dynamics
AX. Fiind vorba despre o aplicație web, aplicația este accesibil ă din orice browser, și orice
platformă. Pagina web din Figura 4: Aplicația web a soluției AX (web client) reprezintă
dashboardul aplicației web, care constituie punctul de intrare în sistem. În panoul din partea stângă
sunt listate modulele sistemul ui AX , module clasice pentru orice soluție ERP. În partea dreapta,
lângă calendar sunt afișate workspaceurile (Bank Management, Payroll Management, etc) .
Workspaceurile (spațiu de lucru) reprezintă un concept nou, și anume modalitatea primară prin
care uti lizatorii sistemului AX pot naviga dintre sarcini și pagini. Workspaceurile pot fi privite ca
și aplicații individuale care sunt menite să ajute utilizatorul să fie mai eficient în munca sa (7). Un
workspace concentrează pe sarcinile necesare pentru munca utilizatorului , oferind o prezentare
generală a unei activitate, afișând statusul procesului actual, încărcarea curentă de lucru, și

17
performața utilizatorului pe sarcină . Ideal, utilizatorii ar trebui să fie capabili să înce apă activitățile
în mod direct din workspace, respectiv să le termine pe baza informațiilor primite din workspace
(8).
În soluțiile Microsoft AX, m odulele prezentate în Figura 4: sunt numite modele. Un model este o
colecție sau grup de elemente, care reprezintă o soluție software. De exemplu, modulul pentru
Project management este un model. Un model este alcătuit din form -uri și tabele , tipuri de date de
bază și tipuri de date derivate . Un form reprezintă o pagină individuală , alcătuită din elemente UI,
conținând atât elemente pentru afișarea datelor cât și câmpuri de date pentru introducerea
informației . Tabelele sunt tabele T -SQL, și ele sunt gestionate de către Microsoft SQL Server.
Un model Dynamics AX poate să fie alcătuit din mai multe proiecte Visual Studio, însă un proiect
poate să fie asociat doar unui singur model. Modelele sunt incluse în pacakageuri de Dynamics
AX. Un package este o unitate de deployment, și poate să conține unul sau mai multe modele. Un
package poate să fie exportat într -un fișier, care poat e să fie instalat într-un mediu de producție sau
staging. (9)
Adaptarea soluției AX la cerințele în trepriderii , se întâmplă printr -o abordare de extindere . Pentru
implementarea extensiilor, Microsoft oferă posibilitate a de a extinde modelele de sistem, prin două
abordări: overlayering și extension . Folosind abordarea de overlayering, modificările pe model
sunt făcute în același package în care stă și modelul original. Dezavantajul acestei abordări este că
printr -o actualizare a sistemului AX, modificările implementate se vor pierde. În cazul în care
extinderea soluției AX se realizează cu abordarea de extension, modificările realizate pe model
vor fi incluse în pachete separate. Modelele care necesită modificările, vor fi referențiate în aceste
pachete de extensie.
Pentru studiul de caz, am folosit o imagine virtuală descărcat ă de pe pagina oficială de Microsoft.
Imaginea virtuală conține un sistem de operare Microsoft Windows Server 2016, cu o soluție
Microsoft Dynamics 365 for Operations preinstalat ă. Pentru ca sistemul AX să fie accesibilă atât
local cât și de pe dispozitivele mobile din rețea, am configurat un router wireless care folosește
serverul DNS hostat de către serverul meu Microsoft, astfel serviciile AOS, respectiv clientul web
vor fi disponibile în toată rețea.

18
3.2 Visual Studio

Pentru extindera modelelor Dynamics AX, se folosește mediul de dezvoltare Visual Studio.
Visual Studio se utilizează atât pentru dezvoltarea programelor Microsoft Windows, cât și pentru
crearea aplicațiilor web, servicii web, aplicații mobile, sau pentru implemen tarea soluțiilor
personalizate AX. Pentru extinderea soluțiilor AX, instanța de Visual Studio trebuie să fie integrată
cu sistemul AX, astfel încât ace asta să aibă acces la modelele, și pachetele existente în sistem.
O instanță de Visual Studio integrată c u sistemul AX se diferă prin două trăsături . Prima este
existența elementului Dynamics 365 în bara de meniu:

Figura 5: Meniul Dynamics 365

În meniu l prezentat în Figura 5 avem posibilitatea de a crea pac kage -uri deployabile, respectiv de
a gestiona și de a crea modele.
A doua diferență existentă în instanța de Visual Studio este apariția panoului AOT în A pplic ation
Explorer ( Figura 6: AOT ). AOT este o abreviere pentru Application Object Tree, și are două
modalități de afișare: classic view și model view. Dacă se alege Model Vi ew, se vor lista toate

19
modele le și package -urile a ferente pentru implementația AX (packageurile sunt afișate în dreapta
modelului, între paranteze ). Dacă se expandează un model, vor fi afișa te elementele care alcătuiesc
modelul respectiv. Selectând un elem ent din Application Object Tree, se poate implementa
modificările fie în packageul curent (Add to new Project) fie într -un package nou (Add to new
Project)

Figura 6: AOT

20
3.3 Dynamics 365 for Operations Mobile App

Microsoft Dynamic s 365 for Operations Mobile App este o aplicație mobilă, care face
posibilă ca formurile existente pe o im plementație AX să fie accesibile și pe dispozitive mobile.
Microsoft Dynamics 365 for Operations Mobile App este o aplicație mobilă cross -platform, și
poate să fie descărcată gratuită atât pe platforma iOS cât și pe platforma Android.
Microso ft Dynamics 365 for Operations Mobile A pp perm ite angajaților să aibă acces la
procesele întreprinderii nu numai prin clientul web, dar și prin dispo zitive mobile. Aplicația
funcționează ca și un container prin care utilizatorii pot folosi spațiile de lucru (workspaceurile)
dezvoltate în special pent ru aplicația mobilă (10). Posibilitatea dezvoltării workspace -urilor
mobile face parte dintr -un hotfix package, ce trebuie instalat pe sistemul AX.
Dynamics 365 for Operations mobile app include următoare le caracteristici care pot ajuta în
îmbunătățirea productivității întreprinderii:
• Utilizatorii pot viziona, modifica și opera pe date de business, și în cazul în care conexiunea
de internet este intermitentă, sau sunt offline. Când dispozitivul va avea acces din nou la
internet, operațiile offline vor fi sincronizate în mod automat cu Dynamics 365 for
Operations
• Administratorii sau dezvoltatorii pot crea și publica workspaceuri mobile care au fost
dezvoltate pentru organizație. Un workspace mobil este dezvoltat în mod special pentru a
fi folosit de pe dispoz itive mobile. Aceste workspaceuri folosesc cod existent, ceea ce
înseamnă că procesele deja dezvoltate nu tr ebuie reimplementate, respectiv logica de
business și configurația de securitate po ate să rămâne nemodificate
• Administratorii IT sau dezvoltatorii pot dezvolta workspaceuri mobile foarte ușor, folosind
designerul de mobile workspace, inclus în clientul web pentru Dynamics 365 for
Operations

21
• Administratorii IT sau dezvoltatorii pot optim iza capabilitățile offline a works paceurilor
folosind frameworkul Business Logic. Prin utilizarea acestui instrument, spațiile de lucru
mobile vor oferi o experiență fluidă și în cazul în care conexiunea de internet este
intermitentă
Aplicația are structura logică prezentată în Figura 7: Structura aplicației Mobile App

Figura 7: Structura aplicației Mobile App

• La pornirea aplicației apare pagina dashb oard
• Pe pagina dashboard sunt listate workspaceurile mobile, publicate pentru Dynamics 365
Mobile App
• În fiecare workspace sunt disponibile câte o listă de pagini
• Pe o pagină se sunt accesibile datele încă rcate de pe una sau mai multe pagini de Dynamics
365 for Operations .
• De la o pagină se poate naviga la alte pagini, care pot conține detalii pentru o entitate
• Pe o pagină sunt disponibile o listă de acțiuni
• Acțiunile permit adăugarea, modificarea sau ștergerea datelor

22
3.4 Aplicații cross -platform mobile

O aplicație se consideră cross -platform, dacă este capabilă să funcționeze pe mai multe
arhitecturi de calculatoare, respectiv pe mai multe sisteme de operare. Dezvoltarea apli cațiilor
mobile cross -platform este un subiect interesant, deoarece permite dezvoltarea unei singură
aplicație, care pe urmă poate să fie instalată pe mai multe sisteme de operare mobile:
• Android
• iOS
• Windows Phone
Dezvoltarea unei aplicație cross -platform de obicei durează mai mult decât implementrea unei
aplicații platform specifice , și poate aduce multe provocări greu de rezolvate din cauza diferențelor
dintre platformele mobile . Pentru a ușura munca devoltatorilor, sunt disponibile două tipuri de
framewo rkuri, respectiv două modalități de dezvoltare .
Prima modalitate este folosirea unui framework HTML -Javascript, care facilitează
dezvoltarea aplicațiilor cross -platform hibride. Un astfel de framework este Apache Cordova sau
Angular Ionic. În acest contex t termenul hibrid înseamnă că aplicațiile nu sunt cu adevărat native
dar nu sunt nici aplicații web -based. Aplicațiile acestea nu sunt native, deoarece nu folosesc de
elemente UI specifice platformei țintă, dar nu se consideră nici web -based pentru că poat e să ruleze
ca o aplicație stand -alone. Aplicațiile acestea împart același aspect vizual peste toate platformele.
A doua modalitate de crearea aplicațiilor cross -platforme mobile este folosirea unui
framework care permite dezvoltarea aplicațiilor cross -platforme native, abordare folosită și în
această lucrare. O aplicație cross platform nativă dispune de aspecte vizuale caracteristice a
platformei țintă, respectiv oferă performanțe superioare decât aplicațiile hibride. Frameworkul cel
mai răspândit pentru d ezvoltarea acestui tip de aplicații este Xamarin.

23
3.5 Xamarin

Xamarin este un framework care permite dezvoltarea aplicațiilor mobile pe platformele iOS,
Android, și Windows Phone, folosind limbajul C# . Xamarin este produsul al companiei cu același
nume, care a fost achiziționat de către Microsoft în 2016 .
Pentru dezvoltarea aplicațiilor mobile pe platformele iOS și Android, Xamarin folosește
librăriile Xamarin.iOS și Xamarin.Android. Aceste librării implementează librăriile native iOS și
Android, servind ca și librării mijlocii care fac legătura între limbajele dife rite de programare, și
nu adaug nimic în plus la apelurile de API.
Librăriile Xamarin.iOS și Xamarin.Android permit implementarea părților platform specifice
a aplicației. Aspectele platform sp ecifice a unei aplicații Xamarin sunt reflectate în proiectele
platform specifice. Logica comună, și anume business logic, care nu se schimbă în aplicațiile
platform specifice, sunt incluse într -un proiect comun, de tip Portable Class Library.
Dezvoltarea interfeței utilizator se poate face atât în proiectele platform specifice cât și în
proiectul Portable Class Library, folosind librăria Xamarin Forms. Aplicațiile create folosind
frameworkul Xamarin vor avea un aspect nativ pe platforma țintă.

24
4 Stud iu comparativ între două abordări de dezvoltare a
extensiilor ERP

4.1 Prezentarea proiectului

În acest studiu comparativ vom prezenta difențe le dintre două abordări de dezvoltare pentru
imlementarea extensiilor mobile ale unei soluție ERP. În acest scop, vom considera un proiect
pentru crearea unei extensii mobile bazată p e soluția Dynamics 365 for Operations. Proiectul are
următoarele specificații :
• Listarea clienților curenți
• Afișarea detaliilor clientului selectat
• Listarea comenzilor pentru clientul selectat
• Utilizatorul trebuie să fie autentificat ca să aibă acces la aplicație
• Aplicația trebuie să fie cross platformă (Android și iOS)
În ambele cazuri, aplicația va avea 3 pagini : listarea clienților, detaliile clientului selectat, și
comenzile clientu lui. Aplicația va folosi de două tabele T -SQL, tabela Cust, în care sunt păstrate
recordurile clienților și tabela CustSale, în care se păstrează comenzile asociate clienților.
În următoarele pagini va fi prezentat ă elaborarea proiectului folosind două abo rdări de
dezvoltare diferite :
1. Dezvoltarea unei aplicații cross -platform nativ e care comunică cu o aplicație intermediară
Web API ( middleware API ). API -ul este o aplicație Web, găzduit ă în Microsoft Azure, și
acceptă apeluri REST. API -ul va apela servicii d e Dynamics 365 for Operations
2. Dezvoltarea workspaceurilor mobile, care vor fi consumate de către aplicația Microsoft
Dynamic s 365 for Operations Mobile App. Aceste workspace -uri sunt create în mod
exclusiv pentru a fi consumate de către aplicația mobilă
Aplicația cross -platform nativă a fost dezvoltată folosind frameworkul Xamarin, în anul
2015. Aplicația comunică cu o implementație AX mai veche, versiunea 2012, folosind modele, și
tabele implementate de către Microsoft. Aplicația Dynamics Mobile App va fol osi de o

25
implementare mai nouă de AX , și anume Dynamics 365 for Operations Update 3 . Tabelele în acest
caz au fost implementate de către mine, și au aceeași structură ca și tabelele furnizate de către
Microsoft AX, de aceea implementarea tabelelor nu va fi prezentată în acest studiu
Cele două modalități de dezvoltare vor fi prezentate considerând trei etape distincte a
dezvoltării a aplicațiilor :
• Extinderea soluției Dynamics 365 pentru cerințele aplicației mobile
• Implementarea unei aplicații middleware, pr in care se realizează comunicarea între
serviciile Dynamics și aplicația mobilă
• Dezvoltarea aplicației mobile , respectiv crearea spațiilor de lucru mobile (mobile
workspaces)
4.2 Extinderea soluției Dynamics 365 for Operations

Folosind serviciile SOAP, sau endp ointurile ODATA, la acest prim pas nu suntem nevoiți
să facem modificări la implementația AX, în cazul în care dezvoltăm aplicația mobilă cu abordarea
tradițională. API-ul middleware va face reqeusturi către endpointurile SOAP/ODATA deja
existente.
În cazul în care decidem lângă implementarea și folosirea spațiilor de lucru mobile, va deveni
necesară extinderea soluției AX, pentru a obține performanțe mai optime. Extinderea soluției are
ca scop dezvoltarea formurilor mobile, folosite în mod exclusiv pen tru crearea paginilor mobile
accesibile din aplicația mobilă. Pentru extinderea soluției AX, vom utiliza abordarea de extension,
care prevede crearea unui model nou într -un pachet nou.
Pentru crearea modelului, vom alege opțiunea Creat e Model, din meniul D ynamics 365, care
va deschide fereastra Create model. În aceasta fereastră vor fi specificate numele modelului,
numele creatorului , publicatorul , etc ( Figura 8: Crearea modelului ). Câmpul Layer este folosit
pentru a preciza nivelul pe care sunt implementate modificările. La alegerea numelor e ste
important, ca numele modelului să urmărească un anumit șablon, prefixând numele modelului cu
prescurtarea modulului . În cazul meu, prefixul este DM, care provine din Disertație Masterat.
Prefixul este important, deoarece ar putea să existe și alte modele cu același nume (Sales
Mangement). Acest prefix, împreună cu MOB (Mobile) va fi folosit pentru toate elementele din

26
proiect. L a crearea modelului, va apare o listă cu modelele ce pot fi referențiate în modelul de
extensie. În modelul DMClientSalesManagement (Figura 8: Crearea modelului ) vom referenția
modelele ApplicationFoundation, ApplicationSuite, aceste modele conținând elementele de bază
pentru soluția AX

Figura 8: Crearea modelului

Odată ce am adăugat modelul, vom crea un proiect nou X ++. X++ este limbaj ul de
programare folosit în special pentru implementarea soluțiilor AX. Proiectele X++ pot conține
formuri, elemente de menu item, tabele de date, respectiv tipuri de date extinse. În cazul de față,
proiectul X++ va fi folosit pentru crearea formurilor mob ile și a elementelor de meniu . Elementele
de meniu sunt utilizate pentru a include formurile în structura clientului web. Pentru fiecare view
specificat în proiect, vom avea câte un form element. Figura 9: Structura proiectului de extensie
arată st ructura proiectului de extensie, numit DMProject1:

27

Figura 9: Structura proiectului de extensie
Crearea unui form în Visual Studio se realizează cu ajutorul Form Designerului (Figura 10: ):

Figura 10: Form designer

Editorul de formuri (Form Designer) are trei ferestre. Fereastra din stânga sus arată care tabele
sunt folosite pentru furnizarea datelor (Data Sources) . Partea dreapta arată ce elemente de UI sunt

28
folosite pentru implementarea formului. La crearea unui form pentru listarea unor entități, se
folosește element ul Grid. Câmpurile prezenteate în elementul grid se specifică luând câmpurile de
date din fereastra stânga sus, și copiându -le în elementul grid în panoul din dreapta sus. A treia
fereastră este folosită pentru previzualizarea formului. Pentru crearea formului DMMobCustSales,
am folosit ca sursă de date tabela DMMobCustSale, incluzând în form pe toate câmpurile de date
a tabelei.
Crearea formului pentru pagina de detalii, se diferă în faptul că de data aceasta se precizează două
tabele ca sursă de informație pentru form. Aceste două tabele s unt DMMobCust și
DMMobCustSale.
La dezvoltarea unui workspace mobile, formurile create trebuie să fie accesibile la nivel de
rădăcină, fa pt ce înseamnă ca formurile trebuie să apare în meniul modulelor AX. Pentru acest
motiv vom crea câte un Menu Item pentru fiecare form implementat. Menu Item -urile vor purta
aceleași nume ca și formurile pe care le reprezintă, și odată create, acestea vor fi incluse în meniul
modului țintă. În cazul nostru, modulul țintă este Sales And Marketing, și de aceea vom extinde
modulul Application Suite (Figura 11: Meniurile AX ), care conțin e o listă de meniuri.

Figura 11: Meniurile AX

Pentru ca elementele de meniu să fie etichetate altfel decât numele elementului din proiect, vom
folosi label -uri pentru a specifica o etichetă mai relevantă . Label -urile sunt înregistrări într -un
fișiser txt, numit Labels.txt, în care se specifică pentru fiecare element AX câte un label, cu un ID

29
unic. Aceste labele pot fi localizate, prin furnizarea fișiserelor label pentru fiecare limbă
implementată de cătr e soluția AX.
Pasul următor este să ne asigurăm ca formurile noi create vor fi accesibile în clientul web AX, sub
modulul Sales and Marketing. În acest scop, vom alege meniul Sales and Marketing din panoul
Application Object Tree, cum este prezentată în Figura 11: Meniurile AX . Deoarece modelul
DMClientSalesManagement extinde pachetul Application Suite, putem adăuga meniul Sales and
Marketing la proiectul curent . Această acțiune va r ezulta în crearea unui element de tip men iu sub
directorul Menu E xtensions. În această extensie vom include elementele menu item create anterior
(Figura 12: Adăugarea elementelor de meniu ):

Figura 12: Adăugarea elementelor de meniu

Cu acest pas ne -am asigurat ca formurile create vor fi accesibile pe nivel de rădăcină.
4.3 Dezvoltarea aplicațiilor middleware

Acest pas din punctul de vedere al aplicației Dynamics 365 for Operations Mobile, nu
prevede nici o acțiune , comunicația între aplicația mobilă și Dyn amics AX fiind rezolvat ă în mod
automat, cu ajutorul lui AOS. Aplicația mobilă comunică cu Application Object Server (AOS)
pentru a cere metadata -urile pentru spațiile de lucru mobile (și toate p aginile care apar pe pagină),
respectiv să descarce datele pentru câmpurile de pe paginile (Figura 13: Comunicare între aplicație
și AOS ). De fiecare dată când aplicația mobi lă face o cerere pentru o pagină, AOS crează o sesiune
nouă, care folosește contextul utilizatorului logat în mob ile app. AOS folosește contextu l
utilizatorului să deschidă form -urile corespunzătoare. AOS poate să deschidă mai multe formuri

30
una după alta, și să efectueze diferite acțiuni pe acele formuri, de exemplu filtrarea rezultatelor,
deschiderea Fac tBox -urilor, schimbarea ordinei a taburilor, etc . Orice logică business de pe form
se performă ca în mod normal . Prin acel proces, AOS strâ nge valorile din câmpurile cerute și
trimite datele înapoi la mobile app.

Figura 13: Comunicare între aplicație și AOS

În cazul aplicației mobile dezvoltate cu abordare tradițională , comunicarea între aplicația
mobilă și AOS se realizează prin intermediul unei aplicații web api. Această aplicație va fi de tip
middleware (mediator), și va accepta apeluri REST din partea aplicației mobile. Apelurile REST
vor fi mapate la apeluri de SOAP , tratate de către AOS. AOS va apela serviciile specificate în
cererile SOAP, și va returna rezultate, respectiv va crea sau va edita entități. Aplicația middleware
va returna datele către aplicația mobilă.
Aplicația middleware a fost dezvoltat în Visual Studio, folosind șablonul Web Api. Web
Api este șablonul folosit pentru crearea aplicațiilor web API, care respectă arhitectura REST.
Aplicația middleware este găzduită în cloud, în Microsoft Azure, sub forma unui Azure Web
Application. Aplicația se numeșt e UniDynWebApi , și structu ra sa este prezentată în Figura 14:
Structura aplicației middleware :

31

Figura 14: Structura aplicației middleware

Folosirea aplicației middleware , necesită ca apelurile REST să fie autorizate. Pentru ca
cererile să fie autorizate, aplicația mobilă trebuie să se autentifică în aplicația middleware. Odată
autentificat, aplicația middleware va returna un Bearer Token. Un Bearer Token este un “jeton”
de securitate, care autorizeaz ă apelurile REST. În cazul aplicației UniDynWebAPI, tokenul este
generat de către clasa AXAuthenticationProvider. Tokenul obținut va fi inclus în fiecare apel de
web api, în header -ul de Authentication.
Apelurile REST vor fi t ratate de către acțiunile din clasele ClientController și
SalesOrderController. Aceste acțiuni sunt metode C#, expuse prin intermediul aplicației
middleware. Acțiunile returnează datele sub forma unor obiecte JSON. Clasa ClientController este
responsabil ă pentru returnarea datelor clienților , respectiv pentru crearea clienților noi. C lasa
SalesOrderController oferă acțiuni GET pentru returnarea detaliei unei comenzi respectiv pentru
returnarea tuturor comenzi făcute de către clienți. Acțiunile din clasele c ontroller folosesc clasele
provider pentru apelarea serviciilor AX. Astfel, pentru returnarea listei de clienți, se utilizează
metoda GetCustomerList din clasa AxCustomerProvider , prezentată în Figura 15: Apelarea
serviciilor AX pentru descărcarea clienților .

32

public class AxCustomerProvider : ICustomerProvider
{
///…
public object GetCustomerList()
{
///…
AXCustomerListService. CriteriaElement customerListCriteria = new
AXCustomerListService. CriteriaElement ();
customerListCriteria.DataSourceName = "CustTable" ;
customerListCriteria.FieldName = "AccountNum" ;
customerListCriteria.Operator =
AXCustomerListService .Operator .GreaterOrEqual;
customerListCriteria.Value1 = "";

///…
var customerList = customerListClient.find(customerListContext,
querycriteria );
List<CustomerModel > customers = new List<CustomerModel >();
foreach (var customer in customerList)
customers.Add( new CustomerModel (customer));
return new ResponseModel (customers, "success" );
}
Figura 15: Apelarea serviciilor AX pentru descărcarea clienților

Ultimul pas în implementarea aplicației middlew are este public area ei pe internet. În Visual Studio,
publicarea aplicațiilor se realizează cu ajutorul mecanismului OneClick publish, care oferă o
interfață minimalistă, prezentată în Figura 16: Publicarea API -ului în Azure . În cazul în care contul
Visual Studio este asociat unui cont Microsoft Azure, se poate crea o aplicație azure web, în care
va fi găzduită aplicația web.

Figura 16: Publicarea API -ului în Azure

33

4.4 Dezvoltarea aplicației mobile

Partea care se diferă cel mai mult între cele două abordări de dezvoltare , este implementarea
aplicației mobile. În cazul în care utilizăm Microsoft Dynamics 365 for Operations Mobile App,
aplicația mobilă este practic gata făcută, tot ce avem de făcut este să descărcăm aplicația din
Google Play sau din Apple App Store, și după aceea să implementăm workspace urile mobile .
Implementarea workspaceurilor mobile este simplă, și poate să fie făcut atât de dezvoltatorii
aplicațiilor mobile, cât și de administratorii IT a întreprinderii. În același timp, d ezvoltarea
aplicației mobile folosind abordarea tradițională e ste o sarcină mult mai dificilă, și necesită
programatori de aplicații mobile, care sunt familiar e cu dezvoltare cross -platformă. Până acest
punct, diferența de ti mp dintre cele două abordări nu a fost foarte semnificativă, abordarea cu
Dynamics 365 for Mo bile având nevoie de extinderea soluției AX , iar abordarea tradițională a
necesitat dezvoltarea aplicației middleware. Acest ultim pas însă este cel care face dezvoltarea
aplicației mobile tradițională un pr oces mult mai lung și complex.
Abordarea de a cre a aplicația folosind instrumentele clasice de dezvoltare, este un proces
mai lung, dar la final vom avea o aplicație mai performantă, respectiv mai personalizată, care va
putea funcționa pe toate cele trei platforme (inclusiv Windows Phone) . Mediul de dezv oltare pe
care vom folosi este Microsoft Visual Studio 2015 cu Xamarin instalat. Pentru a începe dezvoltarea
aplicațiilor mobile pe toate cele trei platforme, sistemul trebuie să înd eplinească următoarele
cerințe:
• Pentru dezvoltarea aplicației Android, tre buie instalat separat Java Software
Development Kit , de preferat ultima variantă, respectiv un emulator Android
• Pentru dezvoltarea aplicației iOS, trebuie să avem la dispoziție un sistem Mac, cu care
va comunica sistemul nostru Windows. Mac -ul este necesar pentru compilarea aplicației
cu Xcode
Aplicația ce va fi prezentată în următoarele pagini, se numește XamUniDynApp, și o vom
compila doar pe sistemul de operare Android, neavând resursele necesare pentru dezvoltarea iOS.

34
Pentru a dezvolta o astfel de apl icație, putem alege dintre mai multe templateuri Visual
Studio Cross -Platform. Aplicația XamUniDynApp folosește templateul Xamarin.Forms. Portable ,
care oferă o soluție alcătuită din patru proiecte , după cum se vede și în Figura 17: Structura
proiectului Xamarin :

Figura 17: Structura proiectului Xamarin

Proiectele XamUniDynApp.Droid, XamUniDynApp.iOS, și XamUniDynApp.WinPhone
reprezintă proiectele pentru platformele Android, iOS, respectiv Windows Phone. Aceste proiecte
sunt proiectele platform specifice, care conțin codul, care nu a putut să fie partajat pentru aceste
platforme, respectiv clasele care servesc ca și clasele de pornire. Proiectul iOS este nedisponibil,
din cauza faptului că nu avem un dispozitiv Mac conectat în rețea pentru compilarea proiectului.
Aplicația XamUniDynApp a fost compilată și pe Windows Phone, dar în cazul acestui studiu
comparativ ne vom limita doar la aplicația Android.

35
XamUniDynApp.Droid, similar cu proiectele native Android, conține o clasă
MainActivity, care servește ca și clasa de entrypoint, unde intră execuția la porni rea aplicației:
[Activity (Label = "XamUniDynApp" , Icon = "@drawable/icon" , MainLauncher = true,
ConfigurationChanges = ConfigChanges .ScreenSize | ConfigChanges .Orientation)]
public class MainActivity :
global::Xamarin.Forms.Platform.Android. FormsApplicationActivity
{
protected override void OnCreate( Bundle bundle)
{
base.OnCreate(bundle);

global::Xamarin.Forms. Forms.Init(this, bundle);
LoadApplication( new App());
}
}

Figura 18: Punctul de intrare în aplicație

În acțiunea OnCreate (Figura 18: Punctul de intrare în aplicație ) se inițializează
ViewEngine -ul Xamarin.Forms, și se predă execuția la clasa App.cs, situat în proiectul
XamUniDynApp. Clasa App.cs este responsabil ă pentru iniț alizarea serviciilor LoginServ ice,
ClientService, și SalesOrderService, respectiv pentru inițializarea paginii Main, pagina rădăcină a
aplicației. Aceste servici sunt folosite pentru comunicarea a realiza comunicarea între aplicația
mobilă și aplicația middleware.
Proiectul XamUniDynA pp este un proiec t de tip Portable Class Library, și conține atât
clasele de service, cât și clasele care sunt responabile pentru afișarea datelor , și care împreună
îndeplinesc cerințele MVVM . Proiectul portable Class Library este referențiat de către toate
proiectele platform -specifice , și are următoarea structură:

36

Figura 19: Arhitectura MVVM
Figura 19: Arhitectura MVVM prezintă stru ctura proiectului PCL (Portable Class Library).
Proiectul urmărește șablonul de MVVM – Model View ViewModel, care prevede separarea
interfeței utilizator de la logica de prezentare și logica de business. Prin menținerea unei sepa rări
clare între logica de aplicație și interfața utilizator, MVVM ajută la adresarea multor probleme de
dezvoltare de aplicații, și face o aplicație mai ușor de testat , mentenat și dezvoltat (11).

View View Model Model Data Bindings și ComenziViewModel face
update
pe Model
Trimite notificări Trimite notificări

Figura 20: Funcționarea arhitecturii MVVM

Figura 20 arată conceptul une i implementări MVVM, și astfel nivelul de prezentare , “View”, știe
de view m odel, iar view modelul știe de model, însă modelul nu știe nimic despre viewmodel iar
viewmodelul nu știe nimic de view. Astfel, viewmodelul ajută la izolarea view -ului de model, și
permite ca modelul să se dezvolte separat față de view.
În cazul aplicație i XamUniDynApp, partea de view este implementată prin pagini create cu
Xamarin.Forms. Xamarin.Forms permite implementarea paginilor în proiectul comun, ele fiind

37
compilate la pagini native când se face build la proiect. Paginile astfel create au extensia X AML,
care este un limbaj de tip markup, derivat din XML
În cazul aplicației XamUniDynApp, p aginile XAML derivă din clasele BaseContentPa ge și
BaseMasterDetailPage, în care se face override asupra funcției OnAppearing, în care se verifică
dacă utilizatorul este autentificat în aplicație. Dacă nu, utilizatorul va fi redictat către LoginPage,
unde utilizatorul este nevoit să se autentifică. Elementele cele mai importante în crearea
interfețelor XAML sunt GridLayout și StackLayout. Astfel, în cazul paginii ClientsPage, avem un
Grid, în care este inclusă un StackLayout.
<Grid HorizontalOptions ="CenterAndExpand ">
<StackLayout >
<SearchBar x:Name="searchBar " Placeholder ="Search"
TextChanged ="SearchButtonPressed ">
</SearchBar >
<ListView x:Name="listView " ItemSelected ="OnListItemSelected "
IsPullToRefres hEnabled ="True">
<ListView.ItemTemplate >
<DataTemplate >
<TextCell Text="{Binding Name} " />
</DataTemplate >
</ListView.ItemTemplate >
</ListView >
</StackLayout >

Figura 21: Listarea clienților în ClientsPage
Elementul StackLayout (Figura 21: Listarea clienților în ClientsPage ) permite poziționarea
elementelor într -o manieră verticală, unul sub altul. Elementul cel mai important în această pagină
este ListView, care permite listarea clienților printr -un model binding la viewmodelul

38
ClientsP ageViewModel. Acest ViewModel are un ObservableCollection Clients care face posibil
ca orice modificare făcută la elementele colecției să fie reflectată pe UI.
public class ClientsPageViewModel : ViewModelBase
{
///…
public ObservableCollection <ClientData > Clients { get; set; }

public async Task GetClientListAsync( CancellationToken cancellationToken,
List<ClientData > clients)
{
///…
await _service.GetClients(cancellationToken). ContinueWith(
m =>
{
App.Clients = m.Result;
///..
if (Clients != null && Clients.Any())
{
foreach (var clientData in App.Clients)
Clients.Add(clientData);

Figura 22: Încărcarea clienților prin middleware
Această colecție este populată prin metoda GetClientListAsync, î n același viewmodel (Figura 22:
Încărcarea clienților prin middleware ). Metoda apelează acțiunea GetClients pe serviciul
ClientService, care va face un apel GET către aplicația middleware.
response = await httpClient.GetAsync( string.Format( "{0}{1}" , App.ServiceUrl,
_ApiFunction));
Serviciul va returna o listă de ClientData, care servește ca și clasa model pentru viewmodelul
ClientsPageViewModel.
Paginile ClientDetails, SalesOrders urmăresc același șablon de MVVM ca și pagina Clients.

În cazul aplicației Dynamics 365 for Operations Mobile App, w orkspace -urile mobile sunt
implemente folosind Designer -ul de Aplicații Mobile, ac cesibil din interfața web al lui Dynamics
365 for Operations.
Designer -ul permite utilizatorul ui să selecteze date specifice de la form -uri care ar tre bui să
apare în aplicația mobilă . Pentru a acessa Designer -ul, trebuie să accesăm site -ul Dynamics 365

39
for Operations, furnizân d argumentul mode=mobile în URL ( Figura 23: Dynamics 365 for
Operations Web Client deschis cu modul mobile ):

Figura 23: Dynamics 365 for Operations Web Client deschis cu modul mobile

Furnizarea argumentului mode=mobile rezultă în apariția opțiunii Mobile app în meniul de setări.
Dacă alegem “Mobile app” din meniul dropdow n, în partea dreapta a paginii web va apare
designerul de mobile workspaces, prezentat în Figura 24: Editorul de mobile app . În acest designer
putem să edităm workspaceurile existente, putem să le edităm, respectiv putem deci de care dintre
ele să fie publicate în aplicația mobilă. Avem posibilitatea și de a crea un workspace mobil nou,
apăsând pe butonul “Add”.

Figura 24: Editorul de mobile app
În urma acestui pas va apare pagina Manage mobile app (Figura 25: Crearea unui workspace
mobil ):

40

Figura 25: Crearea unui workspace mobil

În această fereastră se poate specifica titlul workspaceului, respectiv se poate alege un icon pentru
workspace. Sub câmpurile Name, Description apar taburile Pages, Actions și Logic. Tabul Pages
are butonul Add Page, cu care se poate adăuga o pagină nouă pentru workspace -ul mobil. Pentru
crearea paginii All Customers, facem click pe butonul Add Page , unde va apare linkul Select fields

Figura 26: Crearea unei pagini
Opțiunea Select fields (Figura 26: Crearea unei pagini ) este folosit ă pentru a indica care cămpurile
să fie folosite dintr -un form, astfel indicăm ruta pe care AOS va trebuie să parcurgă pentru

41
selectarea câmpurilor , și a datelor potrivite. Pentru pagina All Customers, vom naviga pe partea
stânga a aplicației Web la modulul Sales and Marketing ( Figura 27):

Figura 27: Meniul Sales and marketing
În urma acestei acțiuni, va apare meniul acestui modul, iar sub meniul Customers vor apare și
menu item -urile create anterior ( Figura 28: Elementele de meniu din Sales and marketing,
împreună cu elementele de meniu create anterior :

Figura 28: Elementele de meniu din Sales and marketing, împreună cu elementele de meniu create anterior
Dintre aceste elemente de meniu vom selecta All Clients, iar ca rezultat va apare formul All
Clients, cu toate câmpurile de date create în form . Butonul “+” lângă câmpul nume indică faptul
că suntem în modul de edit, iar câmpurile marcate cu semnul “+” pot fi adăugate în pagina mobilă
(Figura 29: Crearea paginii, selectând câmpuri de date :

42

Figura 29: Crearea paginii, selectând câmpuri de date
După ce am ales câmpul, acesta va apare în secțiunea Manage mobile app (Figura 30::

Figura 30: Câmpurile de date selectate
Similar, la crearea paginii Customer Details, putem crea pagina mobilă selectând câmpurile
necesare din formul corespunzător (Figura 31: Crearea paginii de detalii clienților ):

Figura 31: Crearea paginii de detalii clienților

Când utilizatorul a terminat de creat workspace -ul mobil, acesta va fi publi cat cu opțiunea Publish
workspace, prezentat în Figura 32:

43

Figura 32: Publicarea spațiului de lucru mobil

4.5 Prezentarea aplicațiilor

La pornirea aplicațiilor, ambele soluții vor necesita introducerea contului utilizatorului. În cazul
aplicației mobile AX, utilizatorul trebuie să -și introducă contul său de Active Directory, iar pentru
aplicația nativă utilizatorul trebuie să -și introducă co ntul creat pentru aplicația mobilă.
Aplicațiile rezultate vor fi prezent ate în screenshoturile atașate. Figura 33 și Figura 34 arată
paginile All Clients. Se poate observa pe Figura 33: XamUniDynApp aspectul nativ al elementelor
UI, însă rezultatul este similar: ambele pagini dispun de c âte o listă de utilizatori, respectiv o bară
de căutare unde se poate căuta după utilizator.

Figura 34: AX Mobile App

Trebuie menționat faptul că ambele aplicații suportă naviga rea prin aplicație fără conexiune de
internet. Figura 35 și Figura 36 prezintă paginile de detalii clienți. Similar ca în cazul paginilor de
Figura 33: XamUniDynApp

44
listare a clienților, se poate observa aspectul nativ a aplicației XamUniDynApp (versiunea de
Android folosită este 4.4.2). La capitolul de performanță, nu există diferențe majore dint re cele
două aplicații, însă este foarte posibilă ca în cazul mai multor date, aplicația nativă va oferi o
exeperiență mai bună de utilizare.

Figura 36: Apli cația XamUniDynAPp Figura 35: Aplicația Dynamics for Mobile

45
4.6 Sumarea diferențelor dintre abordările de dezvoltare

Studiul comparativ a arătat, că pentru scenariile simple de business, workspaceurile mobile
se pot implementa ușor și rapid, cu interacțiune minimă din partea dezvoltatorului software. Însă,
în cazul în care proiectul ar avea nevoie de grafici dinamice, implementarea acesto ra ar fi mult mai
dificilă în cazul în care folosim spațiile de lucru mobile.
Dacă ne uităm la cele trei pași de dezvoltare al aplicațiilor, se poate vedea că aproape în
fiecare caz, abordarea tradițională a necesitat mai mult efort din partea dezvoltatoru lui.
1. Primul pas, implementarea modificărilor AX este singurul pas, care n -a necesitat niciun
efort de dezvoltare, folosind abordarea clasică de dezvoltare. În cazul creării workspace –
urilor mobile, am implementat form -urile personalizate, mai optime pentr u aplicația mobilă
2. Dezvoltarea aplicației middleware poate necesita mult timp în cazul dezvoltării
tradiționale, în timp ce sarcinile de middleware sunt rezolvate de către serverul AOS, și nu
necesită nici o modificare din partea dezvoltatorilor
3. Dezvoltare a interfeței utilizator reprezintă concepte radical diferite la cele două abordări.
În cazul dezvoltării tradiționale, trebuie implementată o aplicație întreagă cross -platformă,
în timp ce pentru Dynamics 365 for Operations Mobile App trebuie create doar i nterfețele
utilizator, folosind Designerul de Formuri mobile , ce poate fi făcut cu ușurință și de
administratorii IT a sistemului. Acest ultim pas este cel care necesită o implicare mult mai
serioasă în cazul abordării tradiționale, și cu acest pas impleme ntarea aplicației poate să ia
mai mult de cât o lună , în timp ce modificările la AX în cazul dezvoltării cu Dynamics
Mobile App, poate fi făcute și într -o săptămână

46
5 Concluzii

La alegerea unei soluții ERP, extensiile mobile reprezintă un criteriu important pentru
întreprinderile. Dezvoltatorii soluțiilor ERP trebuie să ofere puncte de extensie pentru sistemul
ERP, astfel încât sistemul să fie ușor extins cu aplicația mobilă.
În acest studiu am prezentat punctele de extensie oferite de către Micros oft pentru soluția lor
ERP, Microsoft Dynamics 365 for Operations. Sistemul poate să fie extins atât cu o aplicație
dezvoltată cu abordarea tradițională, apelând niște servicii, sau prin implementatea spațiilor de
lucru mobile. Cu ajutorul workspace -urilor mobile crearea extensiilor mobile, a devenit foarte
simplu. Workspace -ul mobil poate să fie asamblat folosind interfața web, și apoi consumat din
aplicația mobilă, astfel munca dezvoltatorilor poate să fie minimalizată. În același timp, folosirea
abordări i clasice, de a dezvolta aplicația de la zero, necesită mai mult timp, respectiv vine cu
costuri mari.
Dezvoltarea aplicațiilor mobile, cu abordarea clasică are relevanță atunci când apare
necesitatea integrării unei grafici, sau reprezentare tabelară a informațiilor , facilități ce încă nu
sunt suportate de către Microsoft Dynamics 365 for Operations Mobile App. Celălalt avantaj al
aplicației mobile dezvoltat în mod tradițional, este faptul că oferă o experiență de utilizator nativă,
utilizatorii aplicațiil or mobile preferând de multe ori experiența platformei cu care sunt obișnuiți.
Din punct de vedere de performanță, s -ar putea să apare diferențe în favoarea aplicației native.
În concluzie, Microsoft Dynamics 365 for Operations, este o platformă formidabil ă, care oferă
multe posibilități la capitolul de extensii mobile. Aplicația mobilă cu workspaceurile mobile este
o alternativă bună pentru aplicațiile native, și merită să fie luată în calcul dacă vine vorba de
dezvoltare extensiilor mobile pe Dynamics AX.

47
6 Bibliografie

1. The Evolution of ERP. Rashid, Mohammad A. Albany : Massey University, 2001.
2. Inside -ERP. http://it.toolbox.com/blogs/inside -erp/the -importance -of-erp-user-interfaces –
68042. The Importance of ERP User Interfaces. [Online ] [Cited: 07 01, 2017.]
http://it.toolbox.com/blogs/inside -erp/the -importance -of-erp-user-interfaces -68042.
3. enterpriseappstoday. 10-keys to creating a mobile erp strategy. [Online] [Cited: 06 03,
2017.] http://www.enterpriseappstoday.com/erp/10 -keys -to-creating -a-mobile -erp-
strategy.html.
4. Wikipedia. Microsoft Dynamics 365 for Finance and Operations. [Online] [Cited: 05 22,
2017.]
https://en.wikipedia.org/wiki/Microsoft_Dynamics_365_for_Finance_and_Operations.
5. docs.microsoft.com. Overview of Microsoft Dynamics 365 for Finance and Operations for
Developers and IT Pros. [Online] Microsoft. [Cited: 06 20, 2017.]
https://docs.microsoft.com/en -us/dynamics365/operations/dev -itpro/.
6. Wikipedia. Microsoft Dynamics AX. [Online] [Cited: 05 24, 2017.]
https://en.wikipedia.org/wiki/Microsoft_Dynamics_AX.
7. Cole, Ivan. eclipse. 10 Feature Highlights to Know About in The New Microsoft Dynamics
AX (AX7). [Online] [Cited: 06 12, 2017.] http://www.uxceclipse.com/10 -feature -highlights –
know -new-microsoft -dynamics -ax-ax7/.
8. Microsoft Docs. Workspace form pattern. [Online] [Cited: 05 23, 2017.]
https://docs.microsoft.com/en -us/dynamics365/operations/dev -itpro/user –
interface/workspace -form -pattern.
9. mbspartner. 80730AE: Development Basics in Micros oft Dynamics AX. [Online] [Cited:
05 23, 2017.] https://mbspartner.microsoft.com/AX/CourseModules/1181.
10. Erickson, Sally. Dynamics 365 for Operations Help Wiki. Dynamics 365 for Operations
mobile app home page. [Online] [Cited: 05 28, 2017.]
https://ax. help.dynamics.com/en/wiki/dynamics -365-for-operations -mobile -app/.
11. Britch, David. Enterprise Application Patterns using Xamarin.Forms. s.l. : DevDiv, .NET
and Visual Studio produc teams, 2017.
12. Wikipedia. Enterprise resource planning. [Online] [Cite d: 05 28, 2017.]
https://en.wikipedia.org/wiki/Enterprise_resource_planning.
13. Wikipedia. Microsoft Dynamics. [Online] [Cited: 05 17, 2017.]
https://en.wikipedia.org/wiki/Microsoft_Dynamics.

48
14. Wikipedia. Manufacturing Resource Planning. [Online] [Cited : 05 28, 2017.]
https://en.wikipedia.org/wiki/Manufacturing_resource_planning.
15. Sherweb. What is Microsoft Dynamics 365. [Online] [Cited: 05 20, 2017.]
http://www.sherweb.com/blog/what -is-microsoft -dynamics -365/.
16. Microsoft .NET. Cross -Platform Devel opment with the Portable Class Library. [Online]
[Cited: 06 12, 2017.] https://docs.microsoft.com/en -us/dotnet/standard/cross –
platform/cross -platform -development -with -the-portable -class -library.
17. Microsoft Developer Network. Implementing the Model -View -ViewModel Pattern.
[Online] [Cited: 05 28, 2017.] https://msdn.microsoft.com/en -us/library/ff798384.aspx.

49

DECLARAȚIE DE AUTENTICITATE A
LUCRĂRII DE FINALIZARE A STUDIILOR

Titlul lucrării: Studiu comparativ între modalități de dezvoltare a extensiilor mobile
pentru Microsoft Dynamics 365 for Operations
Autorul lucrării : Marczin Robert -Gyula

Lucrarea de finalizare a studiilor este elaborată în vederea susținerii
examenului de finalizare a studiilor organizat de către Faculta tea de Inginerie
Electrică și Tehnologia Informației, din cadrul Universității din Oradea, sesiunea
iulie a anului universitar 2016 -2017 .
Prin prezenta, subsemnatul (nume, prenume, CNP) Marczin Robert -Gyula,
CNP:1920731055081, declar pe proprie răspundere că această lucrare a fost scrisă
de către mine, fără nici un ajutor neautorizat și că nici o parte a lucrării nu conține
aplicații sau studii de caz publicate de alți autori.
Declar, de asemenea, că în lucrare nu există idei, tabele, grafice, hărți sau alte
surse folosite fără respectarea legii române și a convențiilor internaționale privind
drepturile de autor.

Oradea,
05.07.2017 Semnătura

50