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…. [621172]

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
Cuprins

1 Introducere ………………………….. ………………………….. ………………………….. …………………………. 4
2 Planificarea Resurselor Întreprinderii ………………………….. ………………………….. …………………. 6
2.1 Aspecte generale ………………………….. ………………………….. ………………………….. ………….. 6
2.2 Extensii mobile pentru aplic ații ERP ………………………….. ………………………….. …………. 10
3 Tehnologii folosite ………………………….. ………………………….. ………………………….. …………….. 12
3.1 Microsoft Dynamics 365 for Operations ………………………….. ………………………….. …….. 12
3.2 Visual Studio ………………………….. ………………………….. ………………………….. ……………… 14
3.3 Dynamics 365 for Operations Mobile App ………………………….. ………………………….. …. 16
3.4 Aplicații cross -platform mobile ………………………….. ………………………….. ………………… 19
3.5 Xamarin ………………………….. ………………………….. ………………………….. …………………….. 20
4 Studiu compara tiv între două abordări de dezvoltare a extensiilor ERP …………………………. 21
4.1 Prezentarea proiectului ………………………….. ………………………….. ………………………….. … 21
4.2 Adaptarea implementației Dynamics AX ………………………….. ………………………….. …… 22
4.3 Dezvoltarea aplicațiilor middleware ………………………….. ………………………….. ………….. 26
4.4 Dezvoltarea aplicației mobile ………………………….. ………………………….. ……………………. 30
5 Concluzii ………………………….. ………………………….. ………………………….. ………………………….. 41
6 Bibliografie ………………………….. ………………………….. ………………………….. ………………………. 42

4
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 complex pentru luarea deciz iilor, achiziționarea în timp a pieselor de producție, gestionarea
inventarului, contabilitatea, resurse umane, respectiv distribuția bunurilor ș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 asigurarea unei logistici mai bune. Ca
un răspuns pentru ace ste provocă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 in formație.
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 le ale întreprinderii poate să
fie urmărit în timp real. Interfețele utilizator au evoluat împreună cu sistemele ERP, și d in aplicații
desktop au devenit site -uri web, accesibile nu numai din cadrul întreprinderii dar peste tot unde
internetul este disponibil . Cu răspândirea dispozitivelor mobile, companiile software au început să
dezvolte 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, care au
funcționalități mai restrânse, c onsiderând resursele limitate a dispozitivelor mobile, respectiv
datele de tran sfer mai lente de internet.
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ă numele
Dynamics 365 for Operations. În acest st udiu, voi c ompara două abordări pentru dezvoltarea
extensiilor mobile pentru soluția Microsoft Dynamics 365 for Operations. Prima abordare constă

5
din dezvoltare a tradițională de aplicație mobilă cross -platformă, folosind instrumentul de
dezvoltare Visual S tudio, și frameworkul Xamarin. Termenul tradițional î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 conținutului ce va fi disponibil
pentru utilizator prin intermediul aplicației mobilă.
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
extensiilor ERP mobile sunt prezentate în capitolul 5.
În ultimul capitol sunt prezentate concluziile studiului comparativ.

6
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 p relua, 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, î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 . 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. Aplicațiile front
office sunt reprezentate de customer relationship management (CRM) , sales force automation,
customer support și field service.
Aplicațiile back office nu au relație directă cu clienții companiei, dar sunt foarte utile pentru
angajații acesteia . Ele oferă funcționalități pentru operații interne, cum ar fi controlul inven tarului,
producție, și activități asociate cu furnizarea bunurilor, servicilor și al materialelor prime.
Atât aplicațiile front -office, cât și cele back -office împart o interf ață utilizator comun, accesibil
atât de pe calculat oare din întreprindere, sau de dispozitive mobile care au acces la rețea companiei.
Depozitul de informații este î n gen eral o bază de date relațională centrală. Arhitectura unei sistem
ERP este reprezentată de Figura 1: Arhitectura unui si stem ERP :

7

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

Sistemele ERP sunt modulare, adaptându -se astfel la orice scenariu posibil dintr -o
întreprindere. Modulele care pot apare într -un sistem 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, planificare, 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, proiectele de
fabricație, fluxul de producție, gestionarea ciclului de viață a produsului
• Prelucrarea comenzilor: preluarea comenzii, intrarea come nzii, verificarea creditelor,
stabilirea prețurilor, invent ar, transport, analiza și raportarea vânzărilor, sales
commissioning

8
• Managementul lanțului de aprovizionare : planificarea lanțului de aprovizionare,
configurator de produse, order to cash, achiziți onarea, 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
• Gestionarea relațiilor cu clienți : vânzări și marketing, comisioane commissions, servici ,
contactarea clienților, call center support — sistemele CRP nu sunt întotodeauna
considerate ca fiind componente ale sistemelor ERP
• Servici de date : Diferite interfe țe self service pentru clienți, furnizor i și angajați

Figura 2: 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 plasarea
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

9
Dezvoltarea 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 sistemelor 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 cazurilo r 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 poate ține de la câțiva luni până la 2 -3
ani, în funcție de mărimea întreprinderii.
Înaintea apariției sistemelor de planificare a resurselor, s -au folosit sisteme de planificare
a producției (Manufacturing Resource Planning, MRP II). MRP -urile au coordonat procesul întreg
de producție, împreună cu achiziția materialelor, finanțe și relații umane. Scopul MRP -urilor a fost
să ofere date pentru toți participanți din procesul de producție, urmărind produsul prin toate fazele
al producției. (2). Deși utile în activitatea de producție, MRP -urile au fost limitate în sensul că nu
au ofe rit funcționalități importante pentru o întreprindere, precum contabilitate, resurse umane sau
vânzări.
Grupa Gartner a folosit acronimul ERP (Enterprise Resource Planning) pentru prima dată
în anii 1990, în circumstanțe în care sistemele MRP au deveni t mai complexe, oferind acele module
care a u lipsit din MRP -urile până atun ci. (3) Sistemele ERP au răspândit rapid în anii 1990 și 2000,
când multe întreprinderi au schimbat sistemele lor legacy din cauza problemei numit “year 2000”,
respectiv din cauza introducerii monedei euro. Sistemele ERP au concentrat inițial pe
automatizarea funcțiilor back office, funcții care nu afectează clienții în mod direct. Funcțiile front –
office, cum ar fi customer relationship management, prin ca re companiile interacționează cu
clienții în mod direct, au fost integrate când Internet a fost mai răspândit.
Termenul ERP II a apărut pentru prima dată în 2000, descriind o aplicație web -based care
oferă acces în timp real la sistemele ERP pentru angaja ții și partneri. ERP II extinde capabilitățile
ERP-ului oferind posibilități de colaborare cu alte întreprinderi. ERP II este mai flexibil decât
prima generație de ERP, interacționând și cu alte sisteme ERP.

10
2.2 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 liderii întreprinderii au nevoie să pot accesa info rmații 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 sistemele ERP, cu ajutorul
cărora angajații pot vizio na și opera pe informații esențiale. (4)
În timp ce alte sisteme de management au deja aplicații mobile, la sistemele ERP apariția
aplicațiilor mobile este un proces mai lent, din cauza faptului că sistemele ERP sunt de multe ori
atât de complexe încât orice modificare la acesta este riscant.
La dezvoltarea extensiilor mobile, sunt niște 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 s a. Ideal, utilizatorul ar putea să creeze workflow -uri, care le -ar ajuta în
lucru cât timp ei nu sunt la birou. Trebuie considerat și faptul că dispozitivele mobile au resurse
limitate, de aceea limitățile de funcționalitate trebuie acceptate
• Experiența de utilizator: Aplicațiile mobile folosesc Internet ca să acceseze resurse de la
sistemul ERP, iar conexiunea de internet poate să fie lentă sau chiar absentă
• Dimensiunea dispozitivului: Dispozitivele mobile având ecrane mai mici, sunt utile pentru
verificar ea și modificarea datelor, dar nu pentru a face o ofertă unui client potențial
• Aplicații mobile vs. Web -apps: Aplicațiile mobile având acces direct la resursele
dispozitivului, au o putere de calcul mai mare, însă dezvoltarea lor necesită mai mult timp
decât a aplicațiilor web
• 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 pe linia de producție nu neapărat
• 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, dacă experiența de utilizator nu -i destul de fluid, s -ar putea ca
vânzătorii să piardă clienți din aceasta cauză. În acest caz, vânzătorul va utiliza în continuare
metodele vechi de vânzare

11
• Securitate a datelor: Utilizarea aplicațiilor mobile înseamnă ca angajații vor avea acces la
aceleași date, la care au acces și în birou, în cadrul întreprinderii , iar acest lucru aduce multe
probleme de securitate. Trebuie luat în considerare, ca întreprinderile pierd controlul asupra
datelor de business, dacă se folosesc aplicațiile mobile ERP, mai ales dacă comunicația între
aplicația mobilă și sistemul ERP se fa ce prin conexiune Internet. În acest caz s -ar putea ca un
atacator să intervine la mijloc ul comunicației de date și să fure datele.

12
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 (5), și face parte din pachetul Microsoft Dynamics 365
Enterprise . Dynami cs 365 for Operations aparține generației nouă de aplicații ERP (6), permitând
soluția să fie găzduit ă atât în cloud public și privat, sau on -premis, pe serverele întreprinderii.
Microsoft Dynamics 365 for Operations a fost dezvoltat inițial sub numele Axapta, de către
companiile IBM și Danish Damgaard Data (7), î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 cumpărată în 2002 de către Microsoft, iar produ sul Axapta a fost redenumit
în Microsoft AX. Ultima versiune a lui Microsoft AX a apărut în 2016 (versiuna 7, AX 7) , dar a
fost redenumit în Microsoft Dyna mics 365 for Operations. Această versiune de Microsoft AX este
numit neoficial Microsoft AX 7 , denumi re pe care vom folosi și noi în următoarele pagini.
Dynamics AX 7 poate fi g ăzduit în trei moduri:
• Cloud – gestionat în totalitate de către servicii de Microsoft Azure în cloud (nu necesită deloc
infrastructură locală)
• Cloud + Edge – un nod central din cloud cu aplicații și date de business stocate local, în
întreprindere
• Local Business Data – atât procesele business, cât și stocarea datelor se realizează în
infrastructura întreprinderii
Ca și majoritatea soluțiilor ERP, Dynamics 365 for Operations este o soluție de 3 nivele,
astfel se poate diferenția trei componente majore:
• Serverul 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 Microsoft SQL Server , găzduit on -premise sau în cloud

13
• Appl ication Object Server(s) (AOS), servici ul care gestionează toate aspec tele al proceselor
Microsoft Dynamics AX . În ultima versiune de AX AOS este hostat de către serviciile IIS
• Interfața utilizator pentru Microsoft Dynamics AX

Figura 3: Interfața utilizator

În figura Figura 3: Interfața utilizator , este prezentată interfața utilizator pentru Microsoft
Dynamics AX, care este o pagină web, accesibil ă din orice browser, și orice platformă. Se poate
vede că pe partea stânga sunt listate mo dulele soluției ERP, module clasice pentru orice soluție
ERP. În partea dreapta, lângă calendar sunt listate workspaceurile.
Workspaceurile re prezintă un concept nou, și anume modalitatea primară prin care utilizatorii pot
naviga dintre sarcini și pagini. În confor mitate cu Microsoft, ar trebui creat câte un workspace
pentru fiecare activitate de business. Workspaceuri seamănă cu aplicații mici care sunt făcute să
ajute utilizatorul să concentreze doar pe aspectele cele mai importante a lucrului (8). Un workspace
concentrează pe sarcinile necesare pentru munca utilizatorului , oferind o prezentare generală a
unei activitate, și să ajute utilizatorii să înțeleagă statusul current, încărcarea de lucru și

14
performanța procesului sau a utilizatorului. Ideal, utilizatorii ar trebui să fie capabili să înceapă
activitățile în mod direct din workspace, respectiv să le termine pe baza informațiilor primite din
workspace (9).
Modulele prezentate în figură din punct ul de vedere al aplicației AX, 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 este un element de interfață , setul de
ferestre ce este afișat utilizatorului, și prin care utilizatorul poate să opereze asupra datelor.
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 Dynamics AX pacakageuri,
care 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 poate să fie deployat într -un environment de producție sau
staging. (10) Pentru adaptarea unei implementații de AX, modelele deja create se pot ext inde.
Pentru studiul de caz, am folosit o imagine virtuală descărcat ă de pe pagina oficială de Microsoft.
Imaginea virtuală este un Windows Server 2016, cu sistemul AX preinstalat. Pentru ca sistemul
AX să poate să fie accesat atât local cât și de pe dispozitivele mobile din rețea, am configurat
routerul wireless să folosească de DNS server de pe server, astfel sistemul AX să fie vizibil din
toată rețea.
3.2 Visual Studio

Pentru extindera modelelor Dynamics AX, se folosește interfața de dezvoltare integra tă
Visual Studio. Visual Studio se utilizează atât pentru dezvoltarea programelor Microsoft Windows,
cât și pentru crearea site -urilor web, aplicațiilor web, servicii web, aplicații mobile, sau pentru
implementarea soluțiilor personalizate AX. În cazul în care programul se folosește pentru
implementare de AX, Visual Studio trebuie să fie integrat cu sistemul AX, astfel încât acesta să
aibă acces la modelele, și packageurile existente în sistem.
O instanță de Visual Studio integrată cu sistemul AX se diferă prin două proprietăți. Prima
este existența elementului Dynamics 365 în bara de meniu:

15

Figura 4

În acest meniu (Figura 4) avem posibilitat ea 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 AOT -ului în application
explorer ( Figura 5: 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 View, se vor lista toate
modele și package -urile a ferente pentru implementația AX (packageurile sunt afișate în dreapta
modelului, între paranteze). Dacă se expandează un model, se vor afișa elementele care alcătuiesc
modelul respectiv. Selectând un element 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). Prima abordare se numește overlayering approach, atunci când modificările sunt efectuate
în proiectul existent, iar a a doua abordare se numește extensio n approach, când se crează un
package nou pentru efectuarea modificărilor.

16

Figura 5: AOT

3.3 Dynamics 365 for Operations Mobile App

Microsoft Dynamics 365 for Operations Mobile App este o aplicație mobilă, care face
posibilă ca formurile existente pe o implementație AX să fie accesibilă ș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 And roid.

17
Microso ft Dynamics 365 for Operations Mobile A pp permite angajaților să aibă acces la
procesele întreprinderii nu numai prin aplicația web, dar și prin dispo zitive mobile. Aplicația
funcționează ca și un container prin care utilizatorii pot folosi workspaceurile dezvoltate în special
pentru aplicația mobilă (11). 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 dispozi tivul 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 mobile w orkspace este un workspace special, 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 business logic și confi gurația de securitate poate 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
• Administratorii IT sau dezvoltatorii pot optimiza capabilitățile offline a worskapceurilor
folosind frameworkul Business Logic. Folosind acest tool workspaceurile mobile vor
garanta o experiență fluidă și în cazul în care conexiunea de internet nu este bună

18
Aplicația are structura prezentată în Figura 6: Structura aplicației Mobile App :

Figura 6: Structura aplicației Mobile App

• La pornirea aplicației apare dashboard
• Pe 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 văd datele încarcate 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 permite adăugarea, modificarea sau ștergerea datelor

19
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 aplicațiilor
mobile cross -platform este un subiect interesant, deoarece permite dezvoltarea unei singură
aplicație, care pe urmă poate fi instalată pe mai multe sisteme de operare mobile:
• Android
• iOS
• Windows Phone
Dezvoltarea unei aplicație cross -platform de obicei durează mai mult, și poate aduce multe
probleme greu de rezolvate din cauza diferențelor de platformă. Pentru a uș ura munca
devoltatorilor, sunt disponibile două tipuri de frameworkuri, respectiv două modalități de
implementare.
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 context 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ă poate 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 folos irea 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 superioar e decât aplicațiile hibride. Frameworkul cel mai răspândit
pentru dezvoltarea acestui tip de aplicații este Xamarin.

20
3.5 Xamarin

Xamarin este un framework care permite dezvoltarea aplicațiilor mobile pe platformele iOS,
Android, și Windows Phone, folosind l imbajul 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 l ibrării implementează librăriile native iOS și
Android, servind ca și librării mijlocii care fac legătura între limbajele diferite de programare, și
nu adaugă nimic în plus la apelurile de API.
Librăriile Xamarin.iOS și Xamarin.Android permit implementare a părților platform specifice
a aplicației. Aspectele platform specifice 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ă.

21
4 Studiu comparativ între două abordări de dezvoltare a
extensiilor ERP

4.1 Prezentarea proiectului

Pentru comparația celor două modalit ăți de dezvoltare, vom considera un proiect pentru
crearea unei extensii de 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 view -uri: listarea clienților, detaliile clientului selectat,
și comenzile clientului. Aplicația va folosi de două tabele T -SQL, tabela Cust, în care sunt păstrate
recordurile clienților și tabele CustSale, în care se păstrează comenzile asociate clienților.
În următoarele pagini va fi prezentat ă elaborarea proiectului folosind două abordări:
1. Dezvoltarea unei aplicații cross -platform nativ e care comunică cu un middleware API.
API-ul este o aplicație Web, găzduit în Azure, care acceptă apeluri REST. API -ul folosește
de servicii de Dynamics 365 for Operations
2. Dezvoltarea workspaceurilor mobile, care vor fi consumate de către aplicația Microsof t
Dynamic s 365 for Operations Mobile App. Aceste workspace -uri sunt create în mod
exclusiv pentru a fi folosit de către aplicația mobilă
Aplicația cross -platform nativă a fost dezvoltată folosind 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 folosi de o implementare
mai nouă de AX , și anume Dynamics 365 for Operations. Tabelele în acest caz au fost
implementate de către m ine, dar ca și structură sunt la fel ca și tabelele din cazul anterior, de aceea
nu voi prezenta implementarea acestora.

22
Dezvol tarea aplicațiilor mobile , în amândouă cazuri, prevede trei etape:
• adaptarea instalației Dynamics 365 pentru cerințele aplicație i
• implementarea unei aplicații middleware, prin care se realizează comunicarea între
serviciile Dynamics și aplicația mobilă
• dezvoltarea aplicația mobilă, respectiv crearea aplicației workspace -urilor mobile
4.2 Adaptarea implementației Dynamics AX

Folosind s erviciile 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 folosim dezvoltare a tradițională a
aplicației mobile. API -ul middleware va face reqeusturi către endpointurile SOAP/ODATA deja
existente.
Aplicația Dynamics 365 for Operations Mobile App, este o aplicație Android sau iOS, deja
existentă pe Google Play sau Apple AppStore, care poate folosi atât formuri existente, cât și
formuri special create de către dezvoltatori . Astfel, aplicația poate să folosească de formuri deja
existente, create de către Microsoft, însă abordarea corectă este crearea unor formuri mobile
specifice, pentru a avea performanțe mai optime.
Creare a formurilor mobile se face în Microsoft Visual Studio 2015, cu extensia Dynamics
365, într -un proiect nou X++. Modificările făcute pentru implementările AX, se fac în modele de
tip extension sau overlayering. Overlayering îns eamnă, că modificările făcute la un model AX, vor
avea loc în același package cu modelul or iginal, efectiv suprascriind modelul. Abordarea de
extension prevede crearea unui package nou, iar modificările la modelul original vor fi făcute prin
referirea modelului original, astfel, la un update al implementării AX, modificările făcute în
packageuri le separate vor rămâne intacte.
Pentru crearea modelului, vom alege opțiunea Create Model, din meniul Dynamics 365. Va
apare o fereastră, unde va trebuie setat numele modelului, numele creatorului, etc ( Figura 7:
Crearea modelului ). Este important, ca numele modelului să urmărească un anumit șablon, și
anume trebuie să fie prefixat. Î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

23
proiect. La crearea modelului, va apare o listă cu modelele ce pot fi referențiate în modelul de
extensie. În modelul DMClientSalesManagement vom referenția modelele
ApplicationFoundation, ApplicationSuite, aceste modele conținând elementele cele mai
importante.

Figura 7: Crearea modelului

Când s -a adăugat modelul, vom crea un proiect nou X ++. În acest proiect vom adăuga
formurile și elementele de meniu. Pentru fiecare view specificat în proiect, vom avea câte un form
element.

24

Figura 8
DMMobAllClients va fi responsabil pentru afișarea listei de clienți. Crearea unui form în Visual
Studio se realizează cu ajutorul Form Designerului:

Figura 9

25

Form Designer -ul are trei ferestre. Fereastra din stânga sus arată care tabele sunt folosite pentru
furnizarea datelor. Partea dreapta arat ă ce elemente de form sunt folosite pentru realizarea
formului. La crearea unui form pentru listarea unor entități, se folosește Grid element, iar datele
unei entități care vor fi afișate utilizatorului se specifică luând câmpurile de date din fereastra
stânga sus, și copiându -le în elementul grid în fereastra dreapta sus. A treia fereastră este folosită
ca un preview, pentru a arăta cum vor arate elementele în web client.
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 sunt DMMobCust și
DMMobCustSale. Al treilea form creat pentru crearea workspace -ului este DMMobCustSales,
care listează comenzile unui client.
La dezvoltarea unui workspace mobi le, formurile create trebuie să fie accesibile la nivel de
rădăcină, fapt 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 nu me 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, care conține o listă de meniuri.

Figura 10

26
Pentru ca elementele de meniu să aibă alt nume decât numele elementului din proiect, vom folosi
label -uri pentru a le specifica un nume mai ușor de înțeles. 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
unic. Aceste labele pot fi localizate, prin furnizarea fișiserelor label pentru fiecare limbă
implementată de către soluția AX.
Dintre meniuri le listate în figura vom alege Sales and M arketing, și îl vom include în proiectul
curent alegând opțiunea Add to project. Această acțiune va rezulta în crearea unui element de tip
menui sub folderul Menu E xtensions. În această extensie vom include elementele de menu item
create anterior:

Figura 11

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 a cțiune , comunicația între aplicația mobilă și Dyn amics AX fiind rezolvat automat,
cu ajutorul lui AOS.
Aplicația mobilă comunică cu Application Object Server (AOS) pentru a cere metadata -urile
pentru mobile workspaces (și toate p aginile ca re apar pe pagină), respectiv să descarce datele
pentru câmpurile de pe paginile. De fiecare dată când aplicația mobilă face o cerere pentru o
pagină, AOS crează o sesiune nouă, care folosește contextul utilizatorului logat în mobile app.
AOS folosește con textual utilizatorului să deschidă form -urile corespunzătoare. AOS poate să

27
deschidă mai multe formuri una după alta, și să efectueze diferite acțiuni pe acele formuri, de
exemplu filtrarea rezultatelor, deschiderea FactBox -urilor, schimbarea ordinea tabur ilor și click de
butoane. Orice logică business de pe form se performă ca în mod normal . Prin acel proces, AOS
strange valorile din câmpurile cerute și trimite datele înapoi la mobile app.

Figura 12

În cazul aplicației XamUniDyn App, între aplicația mobilă și implementația AOS trebuie să
existe un middleware, care transformă cererile REST făcute din aplicația mobilă în requ esturi
SOAP/ODATA. Pentru acest scop, am dezvoltat o aplicație Web, de tip Web API, care este găzduit
în Azur e, sub forma unui Azure Web Application. Aplicația se numește UniDynWebApi, și are
următoarea structură:

28

Figura 13
API-ul acceptă doar apeluri autentificate, astfel încât requestul să aibă un Authentication
Header, cu un Bearer Token valid. Acest token va fi obținut printr -un apel inițial de login, la
endpointul login, furnizând date valide de atutentificare. Aplicația va verifica datele de
autentificare în clasa AXAuthenticationProvider, și va returna un bearer token, care va fi folosit
de către aplicația mobilă în fiecare request.
Clasele ClientController și SalesOrderController conțin acțiunile care aștept cererile făcute
prin aplicația mobilă, și returnează date sub forma unui obiect JSON. Clasa ClientController este
responsab ilă pentru returnarea datelor clienților, iar clasa SalesOrderController pentru returnarea
comenzilor făcute de către clienți. Acțiunile din clasele controller folosesc de clasele provider
pentru apelarea serviciilor AX. Astfel, pentru returnarea listei de clienți, se utilizează metoda
GetCustomerList din clasa AxCustomerProvider.

29

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 14

Odată dezvoltată, aplicația a fost deployată în Microsoft Azure, folosind mecanismul OneClick
Publish din Visual Studio:

Figura 15

30
4.4 Dezvoltarea aplicației mobile

Partea care se diferă cel mai mult între cele două abordări, este dezvoltarea 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 făcut este să descărcăm aplicația din Google Play sau din
Apple App S tore, și după aceea să implementăm workspaceurile 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. Dezvoltarea aplicației mobile folosi nd abordarea
tradițională este însă o sarcină mult mai dificilă, și necesită programatori de aplicații mobile, care
sunt familiar e cu dezvoltarea cross -platformă. Până acest punct, diferența de timp dintre cele două
abordări n -a fost foarte semnificativă, abordarea cu Dynamics 365 for Mobile având nevoie de
modificări pe partea de 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
proces mult mai l lung și complex.

Abordarea de a crea 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 dezvoltare 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ă îndplinească următoarele
cerințe:
• Pentru dezvoltarea aplicației Android, trebuie 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 si stemul 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 dezvoltar ea iOS.

31
Pentru a dezvolta o astfel de aplicaț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:

Figura 16

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.
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 pornirea aplicației:

32

[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 17
În acțiunea OnCreate 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 LoginService, ClientService, și SalesOrderService, respe ctiv pentru
inițializarea paginii Main, pagina rădăcină a aplicației.
Proiectul XamUniDynApp 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ă
îndeplinească cerințele MVVM . Acest proiect este referențiat de către toate proiectele platform –
specifice , și are următoarea structură:

Figura 18

33
După cum se observă și din figură, proiectul urmărește șablonul de MVVM – Model Vi ew
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 (12).

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

Figura 19

Figura arată conceptul unei implementări MVVM, și astfel interfața utilizator, “View”, știe de
view model, 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ției XamUniDynApp, partea de view este implementată din pagini Xaml și o clasă
LoginPage. Paginile 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ă.
Limbajul XAML este un limbaj de tip markup, derivat din XML, ideal pentru crearea interfețelor
UI. Elementele cele mai importante în crearea interfețelor XAML sunt GridLayout și

34
StackLayout. Astfel, în cazul paginii ClientsPage, avem un Grid, în care este inclusă un
<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 20
StackLayout. StackLayout 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 ClientsPageViewModel. Acest ViewModel are un
ObservableCollection Clients care face posibil ca orice modificare făcută la
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 21
elementele colecției să fie reflectată pe UI. Această colecție este populată prin metoda
GetClientListAsync, î n același viewmodel. Metoda apelează acțiunea GetClients pe serviciul
ClientService, care va face un apel GET către aplicația middlewar e.
response = await httpClient.GetAsync( string.Format( "{0}{1}" , App.ServiceUrl,
_ApiFunction));

35
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 se
implementează folosind Designer -ul de Aplicații Mobile, accesibil din interfața web al lui
Dynamics 365 for Operati ons.
Designer -ul lasă utilizatorul să selecteze date specifice de la form -uri care ar trebui să apare
în aplicația mobile. Pentru a acessa Designer -ul, trebuie să accesăm site -ul Dynamics 365 for
Operations, furnizând argumentul mode=mobile în URL.

Figura 22

Furnizarea argumentului mode=mobile face să apare elementul Mobile app în meniul de setări.
Dacă alegem “Mobile app” din meniul dropdown, în partea dreapta vor apărea workspaceurile
mobile existente, pe care le putem edi ta, respectiv avem posibilitatea de a crea un workspace nou
apăsând butonul “Add”.

36

Figura 23
În urma acestui pas va apare pagina Manage mobile app:

Figura 24

În această fereastră se poate specifica titlul workspaceului, respectiv se poate alege un icon pentru
workspace. Sub fieldurile dropdown apar taburile Pages, Actions și Logic. Tabul Pages are butonul

37
Add Page, cu care se poate adăuga o pagină nouă pentru w orkspace -ul mobil. Pentru crearea
paginii All Customers, facem click pe butonul Add Page , unde va apare linkul Select fields

Figura 25
Opțiunea Select fields este folosit pentru a indica care fieldurile să fiu folosite dintr -un form, astfel
indicăm ruta pe care AOS va trebuie să parcurgă pentru selectarea fieldurilor, și a datelor potrivite.
Pentru pagina All Customers, vom naviga pe partea stânga a aplicației Web la modulul Sales and
Marketing.

Figura 26
În urma acestei acțiuni, va apare meniul acestui modul, iar sub meniul Customers vor apare și
menu item -urile create anterior.

Figura 27
Prin 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ă câmpurile care pot
fi adăugate în pagina mobilă.

38

Figura 28
După ce am ales câmpul, acesta va apare în secțiunea Manage mobile app:

Figura 29
Similar, la crearea paginii Customer Details, putem crea pagina mobilă selectând câmpurile
necesare din formul corespunzător:

Figura 30

Când utilizatorul a terminat de creat workspace -ul mobil, acesta va fi publicat cu opțiunea Publish
workspace:

39

Figura 31

Aplicațiile rezultate vor fi prezentate în screenshoturile atașate. Figura 32: XamUniDynApp
șiFigura 32 Figura 33 arată paginile All Clients. Se poate observa pe Figura 32: XamUniDynApp
aspectul nativ al elementelor, însă rezultatul este similar: ambele pagini au o listă de utilizatori,
respectiv o bară de căutare unde se poate căuta după utilizator.

Figura 33: AX Mobile App

Trebuie menționat faptul că ambele aplicații suportă navigarea prin aplicație fără conexiune de
internet. Figura 34 și Figura 35 prezintă paginile de detalii clienți. Sim ilar ca în cazul paginilor de
listare a clienților, se poate observa aspectul nativ a aplicației XamUniDynApp (versiunea de
Android folosită este 4.4.2).
Figura 32: XamUniDynApp

40

Figura 35 Figura 34

41
5 Concluzii

Dezvoltarea extensiilor mobile pentru soluțiile ERP folosind metodele de dezvoltare
tradițională are ca rezultat o aplicație care poate să fie personalizată, respectiv a cărei funcționare
este înțeleasă de către programator. În același timp, dezvoltarea ex tensiilor mobile cross platforme
durează mult, făcând procesul de creare a unei soluții ERP mai complex, și mai costisitor.
Folosind feature -ul Mobile App, furnizat de către Microsoft, dezvoltatorii respectiv
administratorii IT a sistemului ERP au o alter nativă simplă și rapidă de a crea o interfață mobilă
pentru angajații companiei. În plus, aceste interfețe pot fi ușor modificate, și actualizate, lucru greu
de realizat în cazul aplicațiilor mobile create în mod tradițional. Există însă dezavantaje folosi nd
această abordare: este greu de folosit elementele custom de interfață, din cauza limitării designer –
ului de aplicații mobile.

42
6 Bibliografie
1. The Evolution of ERP. Rashid, Mohammad A. Albany : Massey University, 2001.
2. Wikipedia. Manufacturing Resource Planning. [Online] [Cited: 05 28, 2017.]
https://en.wikipedia.org/wiki/Manufacturing_resource_planning.
3. Wikipedia. Enterprise resource planning. [Online] [Cited: 05 28, 2017.]
https://en.wikipedia.org/wiki/Enterprise_re source_planning.
4. 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.
5. Wikipedia. Microsoft Dynamics 365 for Finance and O perations. [Online] [Cited: 05 22,
2017.]
https://en.wikipedia.org/wiki/Microsoft_Dynamics_365_for_Finance_and_Operations.
6. 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/.
7. Wikipedia. Microsoft Dynamics AX. [Online] [Cited: 05 24, 2017.]
https://en.wikipedia.org/wiki/Microsoft_Dynamics_AX.
8. 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/.
9. 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.
10. mbspartner. 80730AE: Development Basics in Microsoft Dynamics AX. [Online] [Cited:
05 23, 2017.] https://mbspartner.microsoft.com/AX/CourseModules/ 1181.
11. 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/.
12. Britch, David. Enterprise A pplication Patterns using Xamarin.Forms. s.l. : DevDiv, .NET
and Visual Studio produc teams, 2017.
13. Wikipedia. Microsoft Dynamics. [Online] [Cited: 05 17, 2017.]
https://en.wikipedia.org/wiki/Microsoft_Dynamics.
14. Sherweb. What is Microsoft Dynamics 3 65. [Online] [Cited: 05 20, 2017.]
http://www.sherweb.com/blog/what -is-microsoft -dynamics -365/.

43
15. Microsoft .NET. Cross -Platform Development 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.
16. Microsoft Developer Network. Implementing the Model -View -ViewModel Pattern.
[Online] [Cited: 05 28, 2017.] https://msdn.microsoft.com/en -us/library/ff798384.aspx.