Aplicatie Windows Phone Pentru Gestiunea Stocurilor Utilizand Microsoft Dynamics

Aplicatie Windows Phone Pentru Gestiunea Stocurilor Utilizand Microsoft Dynamics

Byadmin ianuarie 1, 2024

LUCRARE DE LICENȚĂ

Aplicație Windows Phone pentru gestiunea stocurilor utilizând Microsoft Dynamics

INTRODUCERE

Documentul propune crearea unei soluții prin care utilizatorii pot avea o expriență completă a administrării serviciului de gestiunea stocurilor din cadrul sistemului ERP Microsoft Dynamics AX prin intermediul unei aplicații instalate pe dispozitivul mobil Windows Phone. Pentru a oferi acces rapid și eficient la date, dar și pentru o vizibilitate la nivelul întregii organizații, utilizatorului i se permite să se autentifice în cadrul aplicației mobile cu aceleași date de acces, nume de utilizator și parolă, ca cele folosite la înregistrarea în cadrul clientului aplicației Microsoft Dynamics AX, totodată pastrându-și rolul configurat în serviciul de gestiunea stocurilor. Aplicația servește ca o soluție sigură care păstrează integritatea datelor pe întreg procesul.

În primul capitol este prezentat conceptul de ERP (Enterprise Resource Planning) plecând de la definiția sistemelor informatice destinate mediului de afaceri și dezvoltarea acestora de-a lungul timpului sunt scoase în evidență avantajele și dezavantajele utilizării unui astfel de sistem. O prezentare sumară a structurii generale unei astfel de tehnologii ce susține rolul aplicației în companie. Produsele principalilor furnizori de pe piața ERP sunt descrise în finalul capitolului.

Al doilea capitol descrie în detaliu sistemul ERP folosit în dezvoltarea aplicației mobile, Microsoft Dynamics AX. Pentru o cunoaștere mai vastă a produselor oferite de Microsoft, acestea sunt prezentate sumar ca soluții, integrarea produselor în cloud computing și ilustrarea structurii arhitecturii folosite. Principalul produs, soluția ERP Microsoft Dynamics AX este descris ca structură, implementare, flux informațional și utilizare. Capitolul cuprinde și o analiză critică asupra produsului actual, alături de direcțiile de perfecționare propuse ce au rolul de a rezolva punctele slabe existente.

Capitolul al treilea este destinat descrierii instrumentelor folosite la crearea și implementarea soluției mobile. Fiecare subcapitol are o structură fixă, o introducere prin care sunt definite rolul și utilitatea tehnologiei, utilizarea propriu-zisă a acestuia, respectiv prezentarea sumară a modului în care instrumentul este folosit în implementarea aplicației mobile. În acest capitol sunt prezentate noțiuni precum Microsoft Azure, IaaS (Infrastructure as a service), Windows Phone, respectiv limbajul X++.

În capitolul patru se începe dezvoltarea aplicației de gestiunea stocurilor propusă ca scop al lucrării. Se prezintă scenariul în limbaj natural pentru a se da o definiției clară a ceea ce urmează să se implementeze. Se configurează serviciul folosit în Microsoft Dynamics AX. Se dezvoltă, crează și configurează elementele necesare, precum serviciul de legătură WCF (Windows Communication Foundation), adaptorul Windows Azure Service Bus, serviciul ACS (Access Control Service), AD FS (Active Directory Foundation Server). Toate aceste elemente reprezentând arhitectura necesară pentru integrarea unei soluții mobile de transmitere a datelor între clientul dispozitivului mobil și serviciul aplicației găzduite în cloud Microsoft Dynamics AX într-un mod sigur, păstrând integritatea datelor. Captiolul cuprinde și dezvoltarea clientului aplicației mobile, proiectrea interfeței și implementarea metodelor de manipulare a datelor.

În capitolul cinci aplicația este prezentată sub forma unui produs finit. Se ilustrează cerințele software și hardware minime pe care trebuie să le îndeplinească dispozitivul mobil pentru a putea instala aplicația. Funcțiile aplicației sunt prezentate din punctul de vedere al utilizatorului, cu rolul de a descrie toate funcționalitățiile implementate. Această prezentare este însoțită de capturi de ecran ale aplcației pentru o înțelegere mai ușoară a conceptelor.

Capitolul șase cuprinde concluziile ca puncte cheie privind experiența dezvoltatorului. În primă fază sunt detaliate condițiile privind implementarea aplicației din punct de vedere al instrumentelor, dar și legal, datorită utilizării produselor Microsoft, costul reprezintă un aspect foarte important. Utilitatea actuală a aplicației este concepută pentru a defini locul aplicației pe piața actuală, în principal comparată cu alte aplicații existente privind funcționalitățiile și experiența utilizatorului. În final sunt prezentate modalități de îmbunătățire ale aplicației pornind de la starea actuală.

SISTEME INFORMATICE DE TIP ERP

ERP este acronimul englezescului Enterprise Resource Planning (Planificarea Resurselor Întreprinderii), termen introdus pentru prima dată la mijlocul anilor 1990 de către Gartner ca înlocuitor pentru „Manufacturing Resource Planning” (Planificarea Resurselor de Producție), cunoscut ca MRPII, denumire formală pentru suita de aplicații pe care producătorii o foloseau la organizarea internă a companiei.

1.1. Evoluția sistemelor ERP

Suita de software destinate mediului de afaceri a apărut în anii 1950-1960 o dată cu dezvoltarea de programe de facturare și de administrarea stocurilor, ceea ce a dus la dezvoltarea produsului denumit Planificarea cererii de material, originalul MRP, iar principalele calcule ce se efectuau cu jumătate de secol în urmă cu ajutorul acestuia, constituie baza sistemelor ERP din zilele noastre. Aceste funcții de bază au reprezentat fundația asupra căreia noi funcții au fost adăugate, precum controlul producției și achiziției, planificarea de bază și predicția financiară pe baza acestuia, precum și costurile de toate tipurile. Toatea acestea constituind un MRPII funcțional, integrat într-o suită de aplicații pe care producătorii se pot baza în consolidarea și comunicarea informației din propria firmă. ERP este doar un nou nume ce reflectă continuitatea și creșterea sistemelor precedente, MRP și MRPII într-un set atotcuprinzător de aplicații integrate, incluzând servicii precum managementul relației cu clientul, urmărirea garanției, planificarea distribuției, colectarea datelor direct de la distribuitori, managementul relației cu furnizorul, colaborare online, distribuție online etc.

Creșterea neașteptată a tehnologiilor de comunicație codusă de electronice, calculatoare și sisteme software a influențat organizațiile să se adapteze și să caute soluții la problemele comune utilizând avantajele tehnologiei. În același timp mediul de afaceri a cunoscut o creștere semnificativă prin unități funcționale necesitând din ce în ce mai multe interfuncționalități pentru a influența deciziile și pentru a reduce timpul necesar producției, gestiunii stocurilor, contabilității, resurselor umane și distribuției produselor și serviciilor. În acest context, administrarea eficientă a nevoilor organizației duce la utilizarea unui sistem informațional pentru a îmbunătății acest proces prin logistică și complexitate de procesare. Este recunoscut universal de companiile medii și mari că acestă capacitate de a livra informația la timpul potrivit aduce îmbunătățiri semnificative organizațiilor globale.

Începând cu sfârșitul anilor 1980, începutul anilor 1990 noile sisteme software cunoscute în industrie ca sisteme ERP au împânzit piața având ca public țintă companiile mari. Aceste sisteme complexe, scumpe, puternice sunt soluții ce au nevoie de consultanță și implementare bazată pe nevoile companiei. În cele mai multe cazuri, acestea obligă companiile să-și reorganizeze procesele de afaceri pentru a se acomoda logisticii modulelor software, spre deosebire de sistemele vechi, specifice anumitor domenii ce erau integrate ca pachete comerciale, proiectate să rezolve probleme specifice. Trecând peste barierele impuse de parteneriate și personalizare, se ajunge la o soluție îmbunătățită ce îmbină vechile practici cu cele noi prin Internet și intranet. Furnizorii promit mai multe module ca extensii software, multe dintre ele fiind rezultatul cererii clienților. S-a ajuns la un proces fără sfârșit de reinventare și dezvoltare de noi produse și soluții care să umple golurile pieței ERP. Furnizorii și clienții au reorganizat nevoile pachetelor urmărind o arhitectură deschisă viitoarelor îmbunătățiri cu module interschimbabile, permițând personalizarea proceselor și a interfeței în avantajul utilizatorului.

1.2. Rolul sistemelor ERP în managementul firmei

Sistemele ERP sunt produse software pentru administrarea afacerii atingând arii de expertiză prin module funcționale precum planificare, producție, vânzări, comercializare, distribuție, contabilitate, finanțe, resurse umane, organizare internă, gestiunea stocurilor, servicii și întreținere, transport și tranzacții online. Arhitectura unui sistem ERP facilitează transparență prin integrarea modulelor oferind flux de informații între toate funcțiile companiei într-o manieră vizibilă la nivelul tuturor partenerilor. O soluție ERP permite companiilor să implementeze un singur sistem integrat înlocuind sau reinventând sistemele de gestiune actuale. Un astfel de sistem a fost definit ca o metodă eficientă de planificare și administrare a resurselor, gestionând acțiunile clientului prin ordonare, luare, facere și livrare a produselor sau serviciilor. Ca apoi să se spună că un ERP comprimă pachetul de aplicații comerciale, promițând o integrare simplificată a fluxului informațional într-o companie, din punct de vedere financiar, de contabilitate, resurse umane, gestiunea stocurilor și comercializare. Sistemul este configurabil, alegerea pachetelor fiind făcută în funcție de nevoile companiei și integrează informația și tot ce se bazează pe informație în ariile funcționale în organizație. O bază de date, o aplicație și o interfață comună alcătuiesc acest sistem. Proiectat să proceseze tranzacțiile unei organizații și să faciliteze planificare în timp real a producției și a cererii.

1.3. Structura și funcțiile unui sistem ERP

Folosite inițial de marile companii ale aniilor 1970 și 1980, unele dintre aceste sisteme au fost dezvoltate de programatori neexperimentați în timp ce altele au fost dezvoltate de diferiți furnizori folosind baze de date specifice și pachete terțe, astfel ajungând să se creeze soluții incompatibile între ele. A fost dificil să se crească capacitatea unor astfel de sisteme sau să se îmbunătățească funcționalitățiile exitente în funcție de schimbăriile apărute.

Un sistem ERP are următoarele caracteristici:

Proiectat modular comprimând mai multe module distincte, precum financiar, de producție, de contabilitate, de distribuție etc.

Folosește un sistem de gestiune a bazelor de date comun integrat central

Modulele sunt integrate și oferă un flux de date între acestea, îmbunătățind transparența operațională

Sistem complex

Flexibil, oferind cele mai bune practici

Necesită timp pentru implementare și configurare pentru a se integra cu funcțiile companiei

Modulele funcționează în timp real profitând de o conexiune la Internet și de capacitățiile de procesare în masă

Furnizorii ERP oferă sisteme ERP specializate într-o anumită direcție, dar modulele de bază sunt aproape aceleași la fiecare dintre ele. Câteva din aceste module de bază folosite în cele mai bune sisteme ERP sunt următoarele:

Administrarea contabilității

Administrare financiară

Administrarea producției

Administrarea transportului

Administrarea vânzării și a distribuției

Resurse umane

Gestiunea stocurilor

Relației client-furnizor

Comerț online

Modulele unui sistem ERP pot funcționa împreună sau separat, dar în cele mai multe cazuri acestea alcătuiesc împreună un sistem integrat. Sistemele sunt în general proiectate să funcționeze pe anumite platforme, precum sistemele UNIX, Microsoft Windows NT, Windows 2000, IBM AIX și HP-UX. SAP, cel mai mare furnizor ERP, oferă un număr foarte mare de module integrate în sistemul oferit R/3. Cele mai noi module introduse de acesta sunt cele care utilizează Internetul pentru comerț.

Astfel de sisteme utilizează tehnologia client/server sau arhitectura client/fat, creând un mediu decentralizat. În sistemele client/server un număr de dispozitive client folosite de utilizatori precum serviciul de cerere din aplicația serverului se ocupă de fluxul informațional și de popularea bazei de date. Cererea poate fi configurată ca un fișier, o valoare, un serviciu de comunicație, un proces de tranzacție sau un fișier principal. Cea mai folosită practică este arhitectura pe trei nivele. În acest fel interfața utilizatorului se folosește de dispozitivul client pentru procesare. Pentru a implementa un sistem ERP sunt necesare calculatoare puternice și un server cu viteză de procesare mare deoarece sute de mii de operații sunt procesate aproape în același timp.

1.4. Avantajele și dezavantajele sistemelor ERP

În general există o percepție înșelătoare că implemetarea unui sistem ERP îmbunătățește funcționalitățiile companiei peste noapte. Așteptările mari de a atinge reducerea costurilor și îmbunătățiri în rândul serviciilor depind foarte mult de cât de bun este sistemul ERP ales și cât de bine se potrivește printre funcționalitățiile organizației, chiar și cât de bine a fost implementat și configurat în raport cu procesele ce definesc afacerea, strategia și structura companiei. Cu toate acestea, un sistem ERP este conceput să îmbunătățească atât funcțiile din spatele proceselor, cât și cele vizibile clienților. O companie alege și implementează un sistem ERP pentru beneficiile sale, chiar dacă acestea se vor vedea sau nu, dar în principal din motive strategice. În multe cazuri, calcularea returnării investiției se bazează în principal pe beneficiile tangibile, calculabile. Pentru a profita de un sistem ERP, compania trebuie să depășească eventualele probleme și dezavantaje cu ajutorul sistemului. S-a calculat că în 1998 se cheltuia anual suma de 17 miliarde de dolari pe sisteme ERP, în acel an simțindu-se o creștere de la 30% la 50%. Companiile cumpărau licențe pentru serviciile de implementare și administrare a sistemului software. Astfel, în anul 2000 suma cheltuită a crescut la 21 de miliarde de dolari, reprezentând o creștere cu 13% față de anul 1999 când piața valora 19 miliarde de dolari. Creștere continuă a pieței sistemelor ERP este atribuită faptului că furnizorii adaugă aplicații precum gestiunea stocurilor, administrarea relației cu clientul, respectiv instrumente de comercializare online.

Tabel 1.1. Avantajele unui sistem ERP

Tabel 1.2. Dezavantajele unui sistem ERP

Aproximativ 60% dintre companii folosesc sau sunt în proces de implementare a unui pachet de sisteme ERP pentru a îmbunătății activitățiile din spatele proceselor. Furnizorii de sisteme ERP caută să atingă clienții în creștere cu sisteme scalabile care necesită o singură implementare, adaptându-se apoi pe parcurs. Pachetele vin în primă fază simplificate, mai ieftine și preconfigurate, ca soluții ușor de instalat în bugetul oricărei firme, fără a necesita prea mult timp.

1.5. Furnizori ERP

Există numeroși dezvoltatori ce oferă sisteme ERP. Exemple ce includ distribuitori de top al acestor sisteme sunt SAP, Oracle, Microsoft, Baan, PropleSoft și Infor. Fiecare furnizor tinde să se specializeze pe un singur modul în particular precum Baan în procesul de producție, PeopleSoft în resurse umane, SAP în logistică și Oracle în financiar. În prezent pe piață sunt aproximativ 50 de furnizori ERP, pe lângă dezvoltatorii terțiari. Rezultatul duce la o competiție rigidă și suprapunerea produselor, ceea ce îngreunează decizia clienților. Din cauza competiției strânse privind controlul pieței ERP, furnizorii sunt obligați să-și îmbunătățească continuu produsul și să fie la zi cu noile tehnologii. Pe termen lung, angajamentul față de anumite servicii și module, experiența și puterea financiară sunt considerate principalele calități ale unui furnizor puternic, reprezentând și o opțiune viabilă pentru alegerea produsului și a implementării.

SAP (“Systeme, Anwendungen, und Produkte in Datenverarbeitung”), sau Sisteme, Aplicații și Produse în Procesarea Datelor, a fost fondat de IBM în Germania anului 1972 pentru producția aplicațiilor software integrate în mediul de. Primul său produs a fost R/2, lansat în 1979 folosind o bază de date centralizată ce a fost reproiectată ca software client/server, denimit R/3 în 1992. Sistemul R/3 a reprezentat un mare succes în 1999, SAP devenind al treilea cel mai mare furnizor de software din lume și cel mai mare pe sectorul ERP cu o valoare de piață de aproximativ 36%, având peste 17,000 de clienți în 100 de țări. În 1999 SAP a extins funcțiile ERP adăugând pachete destinate cliențiilor, gestiunea stocurilor, de comercializare și administrarea depozitelor. SAP a investit în sectorul de dezvoltare rezultând noile versiuni R/3.1, 4/0, 4.6, incluzând funcționalități online și multe alte îmbunătățiri. Soluția online oferită de SAP a oferit un nou produs numit mySAP.COM, iar capacitatea sa de a investi în sectorul de dezvoltare, a dus la soluții specifice industriilor și o dominație pe termen lung, fiind și în ziua de astăzi în topul pieței ERP.

Oracle , fondat în 1977 în Statele Unite ale Americii, este cunoscut pentru dezvoltarea de sisteme de baze de date și aplicațiile acestora și numită a doua cea mai mare companie din lume, după Microsoft. Soluția ERP oferită de Oracle a fost lansată în 1987, plasându-se imediat a doua pe piață după SAP, cu peste 5,000 de clienți în 140 de țări. Sistemul ERP Oracle este cunoscut ca Oracle Applications, având peste 50 de module diferite plasate în șase mari categorii: finanțe, contabilitate, resurse umane, producție, gestiunea stocurilor, proiecte și birou central. Oracle deține alte produse populare incluzând gestiunea bazelor de date, administrarea depozitelor, organizarea fluxului informațional, administrarea sistemelor, instrumente de dezvoltare (API) și servicii de consultanță. O caracteristică a Oracle este aceea că reprezintă un competitor, dar în același timp și un partener pentru liderii industriei ERP, precum SAP, Baan și PeopleSoft deoarece aceștia folosesc sistemele de baze de date oferite de Oracle în soluțiile ERP. Oracle a integrat soluția sa ERP online și a introdus câteva aplicații în comerțul virtual atingând aceste noi arii de vânzare. Infrastructura Oracle este creată în jurul a două mari produse: baza de date Oracle9i și aplicația server Oracle9i. Un alt aspect semnificativ este sistemul de operare OSBS sau suita de produse pentru firmele mici, Oracle Small Business Suite care oferă toate funcționalitățiile unui sistem ERP ca serviciu web, fiind o soluție suficientă pentru o afacere de dimensiuni mici.

În funcție de dimensiunea companiei și de servicile necesare există un număr de furnizori ERP ce oferă o soluție generală sau specifică anumitor industrii. Astfel putem găsi trei tipuri de sisteme pe piața ERP, pentru companii mari, medii și mijlocii, și afaceri mici sau de debut. Soluții ERP pentru companiile mari, piața este dominată de trei furnizori: SAP, Oracle și Microsoft. Piața de furnizori pentru companiile mijlocii include Infor, QAD, Lawson, Epicor, Sage și IFS. Iar piață pentru afaceriile restrânse întâlnește soluții de la furnizori precum Exact Globe, Syspro, NetSuite, Visibility, Consona, CDC Software și Activant Solutions.

MICROSOFT DYNAMICS AX

Microsoft, una dintre cele mai mari companii de dezvoltare software, oferind patru sisteme software de Planificare a Resurselor Companiei (ERP), Dynamics AX, Dynamics NAV, Dynamics GP și Dynamics SL. Toate cele patru sisteme ERP Microsoft sunt rezultatul achiziților companiei și toate cele patru sunt lideri de piață pe segmentele specifice. Există peste 300,000 de companii care folosesc aplicațiile Microsoft Dynamics și peste 10,000 de furnizori de soluții Dynamics global. În timp ce fiecare sistem ERP Microsoft se suprapune cu celalalte soluții privind publicul țintă pe canalele de distribuție, fiecare produs diferă semnificativ din punct de vedere al tehnologiei folosite, interfeței utilizatorului, setul de funcționalități și instrumente administrative.

2.1. Microsoft Dynamics ERP

Cu ajutorul soluției oferite de Microsoft Dynamics ERP afacerea poate fi transformată la nevoie pentru a adopta schimbările cu încredere. Această soluție de planificare a resurselor întreprinderii (ERP) ajută productivitatea printr-o metodă ușor de învățat și folosit. Creșterea flexibilității determină viteza prin care organizația se va adapta la schimbare, ușurința prin care va atinge fluxul de clienți si optimizarea gestiunii stocurilor. În plus, pe termen lung afacerea va afișa o valoare crescută printr-o creștere puternică a investiților (ROI), reducere a costurilor și a valorificării mai eficiente a timpului. Odată considerat o comoditate, acum software-ul ERP este văzut un bun strategic pentru organizațiile care doresc să rămână competitive adaptându-se schimbărilor și acelerând performanțele afacerii. Soluțiile Microsoft Dynamics ERP pot consolida poziția afacerii pe piață și oferă baza unui sistem flexibil ce ajută la creșterea afacerii profitând de avantajele noilor oportunități. Ușor de folosit, intuitiv de implementat și ușor de adaptat, Microsoft Dynamics ERP poate fi livrat după nevoile proprii, integrat în cloud sau găzduit local. Poate fi adăugat personalul, regiunea, produsele și chiar afaceri adiționale cu siguranța că sistemul IT este conceput să suporte orice inițiativă strategică.

Microsoft Dynamics ERP oferă soluții esențiale în cadrul activitățiilor de colaborare, întreținerea proiectului, organizarea personalului, întreținere tehnică, servicii software, gestiunea stocurilor, controlul performanței. Toate aceste procese pot fi întreținute printr-o interfață intuitivă oferind organizare pe roluri ce ajută la administrarea internă pentru eficientizare și acces rapid. Microsoft Dynamics ERP ușurează îmbunătățirea performanței prin instrumentele oferite reducănd la minimum timpul de pregătire. De asemenea, sistemul actual poate fi integrat cu produse larg răspândite, oferind posibilitatea de a lucra intr-un spațiu familiar. Produse precum aplicațiile Microsoft Office și Microsoft SharePoint Server integrază propria interfață.

2.2. Integrare în Cloud Computing

Cloud Computing descrie o gamă variată de servicii, ce se împart în trei categorii în felul următor, Software (SaaS), Platformă (PaaS) și Infrastructură (IaaS).

Cloud Computing poate fi reprezentat sub formă piramidală, ca răspuns la varietatea serviciilor ce se construiesc una cu ajutorul celeilalte sub numele de „Cloud”. Conform Institutului Național de Standarde și Tehnologii (NIST) deducem definiția termenului Cloud Computing ca fiind un model convenabil de acces la cerere la o gamă de resurse configurabile (rețele, servere, memorie, aplicații, servicii, etc.) ce pot fi blocate sau eliberate în cel mai scurt timp posibil, cu minimul de efort gestionat.

NIST oferă și o listă de caracteristici ce sunt esențiale pentru ca un serviciu să fie considerat „Cloud”. Aceste caracteristici includ:

Serviciu la cerere, abilitatea utilizatorilor de a se abona la servicii fără întârzierile ce caracterizează IT-ul tradițional

Acces deschis la rețea, abilitatea de a accesa serviciul prin platforme standard (desktop, laptop, mobile)

Punerea la comun a resurselor, resursele să fie accesibile între clienți

Flexibilitate și rapiditate, capabilitatea de a se scala în vederea satisfacerii cererilor

Serviciu măsurabil, facturarea se face pe baza cantității serviciului utilizat

Astfel cele trei categorii considerate soluții ale Cloud Computing sunt în primul rând aplicațiile SaaS (Software ca Servicii) proiectate pentru utilizatori, livrate prin pagini web, PaaS (Platformă ca Software), un set de instrumente și servicii oferite pentru a face aplicațiile mai eficiente prin metode de programare și desfășurare, și nu în ultimul rând, IaaS (Infrastructură ca Software) fiind o soluție hardware și software, servere, spațiu de stocare, rețele, sisteme de operare. Infrastructura, de una singură nu este utilizabilă, aceasta este pusă la dispoziție și așteaptă să devină productivă cu ajutorul platformei și al software-ului.

Microsoft Dynamics ERP ca SaaS este bazat pe un model hibrid de resurse locale și externe. Se pot muta la cerere oricâte funcționalități pe cloud, obținând procese specializate livrate prin Internet sau în rețeaua companiei. Astfel cloud computing devine o componentă flexibilă a soluției ERP la termenii stabiliți. Implementarea depinde de cea mai bună opțiune pentru modelul de afaceri în cauză și apoi, în caz de nevoie poate fi migrat cu ușurință spre o altă abordare în cazul schimbarilor aferente. Având în vedere punctele comune ale diferitelor afaceri, o soluția poate fi livrată ca SaaS găzduit de un partener. Presupune găzduirea parțială a software-ului ERP online prin serviciile puse la dispoziție. Această metodă scade riscurile și reduce costurile de investiție. Există și alte servicii online specializate disponibile pentru a folosi avantajele Internetului, incluzând servicii conectate ce oferă acces rapid la resurse online de pregătire, suport și comunități direct din Microsoft Dynamics, servicii de plată cu ajutorul cărora sunt acceptate cu ușurință tranzacții de credit și debit între conexiuni multiple, inluzând magazinul online, call center și punctele de vânzare, servicii de comerț care extind influența vânzărilor pe multiple canale, incluzând comerțul online, respectiv servicii web ce oferă o variație de instrumente cu ajutorul cărora se pot construi microsite-uri ce extind procesele afacerii pe cloud și se integrează cu soluția Microsoft Dynamics ERP fără ajutorul unei echipe de IT, acest ultim serviciu fiind valabil doar pentru clienții ce au deja un plan activ de afaceri ce se derulează și pe care vor sa-l completeze cu o soluție ERP Microsoft Dynamics. Cât despre resursele locale, există oricând opțiunea de a implementa toate aceste servicii în spațiul de depozitare local în spatele firewall-ului companiei. Dezvoltat pe Microsoft SQL Server și pe Framework-ul .NET Microsoft, deschis pentru servicii web, aplicațiile Microsoft Dynamics ERP sunt proiectate pentru a sprijinii creșterea afacerii și actualizarea tehnică.

2.3. Privire de ansamblu asupra arhitecturii

Microsoft Dynamics AX oferă o soluție pe două medii, ca aplicație și ca platformă. Cea din urmă este proiectată cu scopul de a susține un mediu de dezvoltare scalabil, personalizat și extensibil către toate aplicațiile ERP într-un mod rapid, eficient, pentru a reduce costurile ce vin o dată cu această trecere. Acest lucru este posibil datorită principiilor de proiectare ale arhitecturii.

Principiile de dezvoltare sunt livrate, nu numai de Microsoft Dynamics AX, văzut ca o soluție de legătură, dar de întreaga echipă Microsoft, prin canale partenere prin suport IT și organizare internă. Această separare realizată în arhitectura aplicației face posibilă împărțirea funcționalităților în cinci secțiuni securizate la nivel global. Acest lucru se asigură că funcționalitățiile nu se corup una pe cealaltă prin componentele logice proiectate și dezvoltate de fiecare echipă. Procesele sunt separate cu scopul ca soluția să satisfacă scalabilitatea ce apare în momentul în care un număr larg de utilizatori accesează serviciul. Principiul este implementat în arhitectură prin trei nivele de procesare, nivelul datelor, nivelul de legătură și nivelul de prezentare. Clientul Windows Microsoft Dynamics AX, Portalul Microsoft Dynamics AX și Clientul Microsoft Office sunt componente ale nivelului de prezentare. Serverul de aplicație Microsoft Dynamics AX (AOS), extensiile Portalului Microsoft Dynamics AX către serverul Microsoft SharePoint și serverul Microsoft SQL Server cu serviciile de raport (SSRS) sunt componente ale nivelului de legătură. Tabelele și serviciile de analiză ale Microsoft SQL Server (SSAS) sunt componente ale nivelului de date. Toate aceste trei nivele făcând parte din arhitectura platformei Microsoft Dynamics AX.

Aplicațiile bazate pe funcții pot fi întreținute de o singură echipă în cel mai scurt timp posibil deoarece sunt realizate pe o arhitectură ce face posibil acest lucru împărțind dezvoltarea pe sectoare independente organizate ca un întreg. În acest fel platforma poate fi reprezentată ca o structură ce specifică comportamentul aplicației client și al rapoartelor, al obiectelor aplicației și al entităților de date ce utilizează multiple tehnologii precum clientul Windows Microsoft Dynamics AX, SharePoint Server, SQL Server sau orice altă tehnologie Microsoft, precum .NET. Cu ajutorul dezvoltării independente, funcțiile folosite, precum și fluxul datelor, își păstrează integritatea pe toată durata proceselor.

Figura 2.1. Arhitectura Microsoft Dynamics AX

Toate aceste principii, combinate, crează o arhitectură de cinci nivele, respectând regulile de integritate și securitate ale datelor aplicației Microsoft Dynamics AX. Arhitectura platformei, ilustrată în Figura 2.1, este împărțită în cinci nivele logice, nivelul platformei aplicației, nivelul domeniului aplicației, împărțit în cel de bază, orizontal, vertical și specific industriei. Componentele acestor nivele sunt proiectate pentru a satisface nevoile de internalizare, localizare și securitate, respectând standardele impuse de tehnologiile Microsoft. Această platformă este compusă din clientul Windows, suita produselor Office, Windows Server, SQL Server, SSAS, SSRS, SharePoint Server, ASP.NET, frameworkul .NET și mediul de dezvoltare Microsoft Visual Studio (IDE).

Având toate aceste componente implementate pe o arhitectură pe cinci nivele, pentru o eficiență sporită, dar și pentru flexibilitate, Microsoft Dynamics AX împarte arhitectura 64-bit pe două nivele. În cazul virtualizării în cloud, dar și în cazurile de implementare locală pe server, încărcătura de date poate fi împărțită între multiple aplicații server-obiect (AOS) cu ajutorul acestui principiu. Procesarea în masă permite sistemului să folosească multiple servere ce pot fi configurate să proceseze în paralel sau în serie. La nivel de control, prin multiple aplicații consolă permite centralizarea administrării sistemului de la mai multe terminale la o singură locație. Sistemul este asigurat printr-o centralizare de roluri bazată pe sarcini împărțite între utilizatorii unei organizații.

Cele mai multe reguli sunt în conformitate cu păstrarea integrității datelor și se bazează pe principiile de securitate informațională. Acest lucru include confidențialitate, disponibilitatea datelor, eficientizarea proceselor afacerii și posibilitatea de a urmări, vizualiza și controla cum utilizatorii acesează și folosesc resursele pentru a executa procedurile necesare transmiterii informației necesare. Cele mai noi capacități ale Microsoft Dynamics AX ajută creșterea organizației cu vizibilitate sporită, consistență și control asupra regulilor ce țin de informație, procese și activități. Pentru dezvoltatori Microsoft Dynamics AX oferă un conector DIEF, respectiv AIF (pentru compatibilitate în procesul reversibil) ce permite acces la aplicație fără utilizarea unei interfețe. Acești conectori permit accesarea ierarhică a logicii arhitecturii, inclusiv a datelor, funcțiilor, tranzacțiilor și a rapoartelor la nivel de analiză.

2.4. Microsoft Dynamics AX

Microsoft Dynamics AX este considerat produsul de bază al gamei Dynamics, numărând peste 150,000 de instalări global, în aproximativ 110 țări, livrat în 45 de limbi. Sistemul ERP este conceput pentru sectoarele publice industriale de producție, distribuție, vânzare și servicii. Conține ca module de bază financiar și contabilitate, administrarea realției cu clientul (CRM), gestiunea stocurilor (SCM), resurse umane (HR), gestiunea salariilor, producție, organizare internă și gestiunea performanțelor companiei (EPM).7

2.4.1. Prezentarea aplicației

Sistemul ERP este o soluție de legătură ce extinde funcționalitățile companiei printr-o rețea de aplicații software. Microsoft distribuie produsul prin canalele proprii de distribuție, dar și prin vânzatori independenți oferind peste 2000 de soluții adiționale pe lângă cele implementate în varianta standard. Acestă rețea de parteneri produce suport global pentru Dynamics AX și formează ecosistemul software ce produce funcționalități specifice, personalizate pentru o gamă din ce în ce mai largă de industrii. Ultima versiune a aplicației ERP are ca public țintă companiile medii și mari, oferindu-le funcționalități predefinite pentru industriile de producție, distribuție, servicii și sectorul public, suport financiar și de contabilitate, precum și produsul Microsoft Office integrat în client. Toate aceste funcții sunt suportate pe o arhitectură în nivele bazată pe structuri de date.

Microsoft Dynamics AX este o soluție ERP oferită de Microsoft pentru întreprinderi, ce îmbunătățește performanțele angajațiilor și anticipează schimbările provenite pentru a asigura depășirea acestora cu succes. Combinând un sistem ERP complet, configurabil spre un anumit scop pentru a se dezvolta pe nevoile industriei, această singură soluție oferă creșterea performanțelor în afacere rapid, mărind șansele de profit aduse de schimbările continue ce apar pe piață. Utilizând tehnologiile standard Microsoft sunt reduse costurile de investiție și totodată procesul de implementare este simplificat. Produsul se poate optimiza o dată cu creșterea afacerii pentru a reflecta schimbările apărute pe parcurs, astfel evoluând în același ritm cu activitatea internă. Angajații își pot depune munca într-un mediu familiar, ușor de folosit ce poate fi accesat oriunde în cadrul companiei, în cazul implementării locale sau chiar de la orice computer cu acces la Internet, dacă se optează pentru o implementare în cloud.

Microsoft Dynamics AX este proiectat pentru a fi ușor și rapid de implementat printr-o gamă largă de instrumente oferite și o varietate de materiale ca model de instalare, dezvoltare și de upgrade. Acestea sunt oferite prin cel mai mare sistem de parteneriat ce include sisteme globale de integrare (GSI), furnizori independenți de software (ISV) și o comunitate globală. Producătorii au încercat întotdeauna să îmbunătățească performanțele în detrimentul costurilor, timpului, calității produsului sau gestiunea stocurilor. Adăugând noi unghiuri de dificultate în tendințele actuale ale globalizării, producției în funcție de contract și a mediului ce extinde socializarea global. Toate acestea combinate induc nevoia unei soluții în timp real. Microsoft Dynamics AX oferă funcționalitate puternic operațională ce include procedee și metode de învățare în capacitatea de producție. Cu acces în timp real prin intermediul rolurilor și instrumentelor la informație, angajații pot crește eficiența performanțelor prin comunicare rapidă și transmitere rapidă de informații de la birou, de acasă sau chiar din orice spațiu public de oriunde pe glob. Mai mult, comunicarea liberă integrată în gestiunea stocurilor, administrarea transportului mărfii și organizarea la punctele de vânzare asigură integrtitatea stocurilor pe tot parcursul traseului, de la producție până la vânzare.

Microsoft Dynamics AX oferă o singură soluție unică pentru sectorul public. Asigură modernizarea spațiului de lucru cu ușurință adaptându-se automat proceselor de muncă ale afacerii în ritmul organizației. Folosește instrumente comune din suita Microsoft pentru a transmite date, a eficientiza comunicarea între angajați, parteneri și clienți folosind aceste instrumente de colaborare. Oferă acces rapid la autentificarea bazată pe roluri, oferind acces limitat sau extins la date, sarcini proprii, asigurând transparență, ținând pasul cu legislația și reducând costurile. Cu un serviciu propriu de organizare internă și instrumente de raport, menține contabilitatea financiară, controlează bugetul și întocmește o creștere regulată a în conformitate cu nevoile afacerii.

2.4.2. Modelul conceptual al datelor

Structura de date prezentată de Microsoft Dynamics AX este susținută de SQL Server pentu a facilita comunicarea și sincronizarea tabelelor printr-o soluție de top, marca Microsoft. La nivelul SQL Server sunt definite următoarele obiecte: tabele, câmpuri, chei primare, constrângeri, valori predefinite, indecși.

Cheile primare și constrângerile tabelelor nu sunt definite în SQL Server, fiind stocate în AX. Acest lucru asigură integritatea datelor, oprind accesul inserării sau modificării datelor direct în baza de date, logica și controalele fiind definite doar în aplicație. Relațile tranzacționale și cheile primare sunt bazate pe Recld, care genereaza o valoare unică în aplicație.

Există trei etaloane calculabile în mediul determinat de Microsoft Dynamics AX, tranzacțional, al companiei și secundar.

Etalonul tranzacțional reprezintă informația relevantă tranzacțiilor (factura, tranzacțiile externe generale etc.). Codul datelor (câmpul predefinit numit CurrencyCode) și rata de circulație sunt stocate în același tabel.

Etalonul companiei este definit în tabelul informațional al companiei (CompanyInfo). Toate tranzacțiile sunt convertite la acest etalon conform ratei de circulație definită de tranzacție. Aceste câmpuri au trecut la sfârșitul numelui codul "MST".

Etalonul secundar adaugă posibilitatea de a ține inventarul tranzacților în două rate de circulație. Acest lucru poate fi folositor dacă compania locală face parte dintr-o corporație mai mare și există o diferență de etalonare între cele două. Câmpurile aferente acestui etalon au trecut la sfârșitul numelui codul "MSTSecond".

Partea centrală a unui sistem ERP este registrul general (GL), iar la baza acestuia stă tabelul unde toate sunt trecute toate informațiile legate de tranzacții. În Microsoft Dynamics AX, acest tabel este numit "LedgerTrans", iar datele sunt notate cumulativ. Figura 2.2 descrie tabelele principale ce stochează datele privind registrul general și tranzacțiile respective.

Figura 2.2. Schema relațională a bazei de date

În Figura 2.2 vedem trei tabele dimensionale: LedgerTable (Tabelul de registru), LedgerTableInterval (Tabelul de interval) și Dimensions (Dimensiuni) și alte trei tabele care conțin informații: LedgerTrans (Tranzacții), LedgerBalancesTrans (Etalonul tranzacțional) și LedgerbalancesDimTrans. Tabelul LedgerTable este un registru al conturilor inventarului financiar, tabelul LedgerTableInterval reprezintă o schemă unde se grupează conturile din tabelul LedgerTable, oferind o descriere specifică, iar tabelul Dimensions conține atribute adiționale ale tranzacților în scop analitic pentru scopuri organizaționale ce primesc alte funcționalități din cadrul aplicației. Tabelul LedgerTrans este tabelul central unde toate tranzacțiile sunt stocate, iar tabelele adiționale LedgerBalancesTrans și LedgerbalancesDimTrans conțin date agregate bazate pe datele din tabelul LedgerTrans. În Figura 2.3 apar și două vizualizări, LedgerBalances și LedgerBalancesDim, unde sunt stocate date interne din tabelele LedgerBalancesTrans și LedgerbalancesDimTrans în scop organizațional intern.

2.4.3. Posibilități de personalizare

În Microsoft Dynamics AX, la nivel de utilizator sunt accesibile opțiuni de configurare a aplicației, inclusiv meniuri de personalizare, permisiuni, panouri de control, motoare de procesoare și interfața clientului. Chiar și baza de date poate fi configurată pentru a se sincroniza cu personalizările din AX, un avantaj ce poate ajuta utilizatorul să adopte o strategie cu risc redus la nivel de ERP. Intrefața este bazată pe sistemul de roluri, permițând clienților să acceseze elemente specifice și să folosească opțiunea de căutare pentru a filtra informația corect. Acest lucru permite angajațiilor să prioritizeze, organizeze și administreze volumul de lucru eficient.

Dynamics AX permite personalizarea elementelor cu ajutorul instrumentelor puse la dispoziție, precum MorphX, un mediu de dezvoltare integrat (IDE) în Dynamics AX ce permite dezvoltatorilor să implementeze tipuri de date, enumerații, tabele, interogări, formulare, meniuri și rapoarte. MorphX permite accesul la orice clasă valabilă a aplicației ERP, utilizând editorul de code X++. Pentru că MorphX se folosește de referința la obiect, schimbările, spre exemplu, la tipul de date ale câmpurilor vor fi automat proiectate în locul unde sunt folosite (la fel și în cazul interogărilor, formularelor sau rapoartelor). Desigur, schimbările făcute cu MorphX vor fi proiectate imediat în sistemul ERP după compilare. Implementarea actuală a personalizării poate fi limitată de acest instrument, prin caracteristicile de securitate și integritate, dar aceste lucruri vin în avatajul creării unui cod mai optim în programarea în limbajul X++.

Cu o interfață ușor de utilizat, Microsoft Dynamics AX vine în completare cu un portal ce oferă acces la funcționalitățile modului ERP printr-un motor global care profită de avantajele internetului pentru a transfera date cu ușurință cu ajutorul oricărui dispozitiv cu acces la Internet. Acesta cuprinde alerte, mecanisme de declanșare automată, permisiuni, ce pot fi create, executate și administrare eficient cu o transparența la nivel golbal. Interfața permite crearea acestora prin utilizarea elementelor vizuale, dar și a modelelor predefinite ce pot fi copiate și modificate cu ușurință ca o modalitate eficientă și rapidă de a personaliza modul de lucru.

2.4.4. Analiza critică

Microsoft Dynamics AX este un sistem ERP pentru companii medii si mari. Oferă o soluție robustă, flexibilă și plină de funcționalități, fiind unul dintre produsele Microsoft Dynamics. Prezintă atuuri privind serviciile de producție și distribuție, dar cu toate acestea este un sistem funcțional, capabil să acopere majoritatea domenilor. În plus are capacitatea de a funcționa în mai multe limbi, ceea ce îl face o opțiune populară printre companiile ce urmăresc să centralizeze operațiile efectuate global.

Privind administrarea, Microsoft Dynamics AX oferă funcționalitate completă pentru controlul stocului, efectuarea inventarului, organizarea transportului, planificarea cererii, calcularea materiei prime necesare, administrarea producției, asigurarea calității și adaptabilitate în cazul schimbărilor neașteptate. Poate servii o gamă largă de industrii, fiind dezvoltat cu funcționalități specifice petru a satisface nevoile producătorilor din domenile de tehnologie, electronice, metalurgie, producție de utilaje industriale, aeronave, produse de consum și, inclusiv industria medicală. Oferă suport în procesele repetitive, producție la cerere, întrunirea stocului, îmbinare și ambalare. Procese ce presupun automatizare, formule, principii sau rețete, primesc sprijin din partea Microsoft Dynamics AX, fiind recomandat în special în companiile farmaceutice, de chimicale și alimentare. Rezultatul este unul satisfăcător datorită adaptabilității sistemului.

În general Microsoft Dynamics AX este ales de companiile ce justifică nevoia unui astfel de sistem prin numărul mare de personal, numărul mare de produse, respectiv globalizarea organizației. Aceste companii prezintă un venit de cel puțin 50 de milioane de dolari anual.

O companie ar trebui să achiziționeze un astfel de sistem atunci când:

Are nevoie de funcționalitate în procesele de producție

Caută o soluție adaptabilă la nevoi specifice

Personalul este familiarizat cu produsele populare Microsoft, precum Office și Outlook

Dorește să schimbe sistemul de livrare într-un serviciu găzduit intern sau în cloud

Departamentul IT folosește produse Microsoft, precum SQL Server, Visual Studio, Windows Workflow Foundation, SharePoint sau Communication Server

Mărimea companiei sau complexitatea acesteia este în continuă creștere

Partenerii folosesc ca sistem ERP Microsoft Dynamics AX, SAP, Oracle sau orice alt sistem, comunicarea între acestea fiind facilitată

Dynamics AX poate fi considerat produsul ERP de bază al Microsoft prin complexitatea și flexibilitatea de care dă dovadă. Produsul a depășit 1,000 de actualizări de la prima versiune lansată, astfel devenind un produs de clasa întâi pe piața ERP, alături de SAP și Oracle. Acest lucru a avut un efect și asupra campaniilor mici, devenind un produs mult prea complex pentru nevoile acestora, depășind costurile permise. Totodată puterea sistemului este susținută de mediul partener Microsoft, având una dintre cele mai mari și mai mature rețele de parteneri din lume, cu mii de parteneri certificați, cu peste 2,200 de produse software. Parteneri ce au contribuit la integrarea sistemului, serviciu profesional, suport tehnic, expertiză locală și specializare pe industrie.

2.4.5. Direcții de perfecționare

Ca direcții de perfecționare, având în vedere poziția evidențiată a Microsoft Dynamics AX pe piața de sisteme ERP, acestă soluție este bine conturată de calitățiile sale unice.

În primul rând Dynamics AX oferă o arhitectură proiectată pe mai multe nivele asigurând flexibilitate și rapiditate în satisfacerea nevoilor afacerii. O soluție cu adevărat completă, oferă atât discreție, cât și administrarea proceselor în funcționalitatea producerii de bunuri. Utilizează practicile de nișă ale industriilor și procesează piață verticală în dezvoltarea companiei. Este integrat cu ușurință cu produse familiare din suita Microsoft Office, precum Excel, Word, Outlook. Promovează ofertele companiei printr-un portal web extern, dar prin același tip de comunicare poate asigura și comunicarea internă a personalului, inclusiv cu organizațiile partenere, împărțind informații, precum date de producție și livrare. Serviciul de comunicare oferă și o suită de instrumente, inclusiv Management Reporter (administrarea rapoartelor), tablou de bord, stocarea datelor, pe lângă alte instrumente ce pot fi utilizate colectiv. Procesul se desfășoară prin configurarea unui sistem de roluri pentru utilizatori ce le oferă acestora funcționalități specifice, precum fluxuri de date, liste de sarcini, prin intermediul clientului Windows sau a unui browser web. Suportul se face la nivel global cu capacități procesare în mai multe limbi, asigurând posibilitatea creației unei rețele globale rapid și eficient. Toate aceste calități îi asigură soluției Microsoft Dynamics un loc de top în piața sistemelor ERP, reprezentând chiar un pericol pentru competitori precum SAP și Oracle.

Chiar dacă Microsoft Dynamics AX aduce o suită de avantaje la folosire, sistemul cuprinde și o serie de dezavantaje care în acest moment sunt considerate compromisuri deoarece în balanță cu avantajele, folosirea sistemului ERP duce la o creștere seminificativă a productivității oricărei companii. Astfel, una dintre limitări este numărul de opțiuni al serviciilor software ERP oferite în cloud, chiar dacă opțiunile per total sunt multe la număr, puține din cele care nu utilizează serviciul de cloud reușesc să se ridice la funcționalitățile așteptate. Pe lângă acest lucru Dynamics AX impune costuri mult mai mari și totodată riscuri asociate cu găzduirea prin parteneriat, datorită investițiilor scăzute, decăt competențele și resursele oferite ca serviciu. Interfața utilizatorului este satisfăcătoare, dar nu reușește să profite de ceea ce a învățat din tehnologiile populare la nivel vizual, astfel potențialul nu este ridicat din acest punct de vedere. Microsoft este în urmă la recunoașterea și livrarea soluțiilor de afacere în comparație cu sistemele oferite de Oracle și SAP. Dynamics ERP oferă o paletă limitată de soluții ce nu sunt suportate pe mai multe platforme, inclusiv pe mai multe browsere, sisteme de operare și baze de date, oferind o experiență completă doar pe sistemele de operare Windows, Internet Explorer ca browser și baza de date SQL Sever. De curând Dynamics AX nu mai reprezintă o variantă viabilă pentru companiile mici, un lucru ce a redus un procent din numărul de clienți și potențiali clienți. Chiar dacă Microsoft ca companie are strategia de a atinge toate segmentele de piață, sistemele ERP Dynamics rareori sunt folosite în piețele verticale. Compania se bazează pe furnizorii independenți și pe partenerii săi pentru a dezvolta și integra soluții specifice industriilor.

NOȚIUNI ȘI INSTRUMENTE FOLOSITE LA PROIECTAREA APLICAȚIEI

3.1. Platforma Microsoft Azure

Microsoft Azure este o infrastructură de cloud computing creată de Microsoft, ce oferă o soluție pentru implementarea și întreținerea aplicațiilor și serviciilor printr-o rețea globală de centre de date întreținută de Microsoft. Oferă atât servicii PaaS (Platformă ca software) și IaaS (Infrastructură ca software) ce suportă diferite limbaje de programare, instrumente și framework-uri, incluzând cele specifice Microsoft, cât și software și sisteme terțe.

Principalele caracteristici oferite de platforma cloud Microsoft Azure sunt siteuri web, mașini virtuale, servicii cloud, spații de stocare și servicii media. Siteurile web implementate în Azure sunt concepute pentru a permite utilizatorului să construiască efectele vizuale, dar și funcționalitățiile dorite cu ajutorul ASP.NET, PHP, Node.js sau Python și pot fi lansate utilizând FTP, Git, Mercurial sau Team Fondation Server. O mașină virtuală în cloud oferă dezvoltatorilor același mediu familiar al sistemelor de operare locale și conectivitatea unei mașini virtuale locale permițând migrarea aplicațiilor și a infrastructurii fără a schimba codul existent. Serviciile cloud permit Platformei Microsoft să ofere un mediu propice pentru crearea aplicațiilor și serviciilor scalabile, sprijinind scenariile de toate felurile și configurările automate pentru a ușura procesul. Toate aceste aplicații lansate în cadrul Azure primesc susținere din partea bazelor de date SQL (SQL Azure Database) pentru stocarea datelor.

Platforma Microsoft Azure oferă un API construit pe tehnologiile HTTP și XML ce permite dezvoltatorilor să interacționeze cu serviciile oferite de Microsoft Azure. O altă alternativă este biblioteca Windows Azure SDK pe parte de client, oferită de Microsoft, care conține funcții cu ajutorul cărora se interacționează cu serviciile, integrându-se cu medii familiare precum Microsoft Visual Studio, Git și Eclipse.

Implementarea Microsoft Azure se face prin instrumentele oferite de Microsoft. Sistemul de operare folosit poate fi descris ca o structură cloud ce leagă un număr imens de sisteme Windows Server ce operează Windows Server 2008 și o versiune specifică de Hyper-V, cunoscut ca Microsoft Azure Hypervisor care oferă virtualizarea serviciilor. Flexibilitatea și siguranța acestora este controlată de Microsoft Azure Fabric Controller astfel serviciile și mediul specific nu se pot închide din surse externe. Acest tip de administrare oferă utilizatorului încrederea că resursele aplicației sale se păstrează în memorie în orice circumstanță.

3.1.1. Windows Azure Active Directory

Organizarea datelor de autentificare și acces la aplicație devine din ce în ce mai grea când vine vorba de un flux imens de date, mai ales în cloud unde proporțiile sunt flexibile. În plus administrarea accesului aplicațiilor locale, încep să întâmpine aceiași problemă datorită necesității folosiri aplicațiilor terțe integrate în cloud, la care autentificarea și accesul se face individual. Pe lângă legăturile făcute mai intervine factorul de securitate, unde în ziua de astăzi atacurile informatice pot lovi în orice clipă. Windows Azure oferă abilitatea de a centraliza controlul cu ușurință, asigurând în același timp vizibilitate. Acest lucru este posibil datorită serviciului de cloud ce utilizează administrarea identității prin două servicii: Windows Azure Active Directory (WAAD) și Windows Azure Multi-Factor Authentication (MFA).9

Windows Azure Active Directory ( WAAD ) este o implementare proiectată pentru cloud a Active Directory-ului pentru administrarea identității aplicațiilor. WAAD oferă organizarea centralizată a identității pentru Microsoft Office, Windows Intune și alte peste 580 de aplicații comerciale. În cazul în care nu se dorește unificarea datelor de acces în aplicațiile locale, WAAD poate fi integrat cu Windows Server Active Directory prin DirSync și cu componentele de legătură din Active Directory Federation Services (ADFS). În plus, la serviciul gratuit se poate adăuga opțiunea Premium ce adaugă suport pentru grupurile de aplicații ce împart între ele aceleași date de acces, oferind și servicii, precum rapoarte de securitate și personalizarea portalului de acces la aplicație.

Autentificarea multi-factor (MFA) permite accesul securizat la aplicațiile din cloud, cât și cele locale, depășind autentificarea comună bazată pe parolă, considerată a nu fi destul de sigură având în vedere puterea atacatorilor din ziua de astăzi. Windows Azure Multi-Factor Authentication este livrat ca un serviciu plătit lunar în funcție de numărul de utilizatori, care pot fi organizați cu ajutorul Windows Azure Active Directory și Windows Server Active Directory pentru a adauga serviciul rapid și cu ușurință la cerere. Windows Azure MFA extinde autentificarea pentru a profita de avantajele oferite de dispozitivele mobile. MFA poate fi utilizat pentru a adăuga o autentificare secundară la aplicațiile existente și presupune autentificarea utilizatorilor printr-o aplicație mobilă, un apel automat sau un mesaj text după introducerea datelor de acces clasice, numele de utilizator și parola. Utilizatorii pot alege opțiunea MFA potrivită pentru situația în cauză.

3.2. Microsoft Dynamics AX ca infrastructură

Implementarea Microsoft Dynamics AX ca serviciu infrastructură cu scopul de a dezvolta cererea de producție în Cloud. Există mai multe soluții pentru acest lucru, Cloud privat (centrul de date al companiei), Cloud privat în parteneriat (implementare găzduită de un partener), Cloud public (spre exemplu utilizând platforma Windows Azure). Windows Azure oferă infrastructură la cerere flexibilă ca dimensiune și adaptabilă la nevoile firmei. Chiar dacă se crează noi aplicații sau se folosesc cele existente, Azure oferă, din punct de vedere profesional, dar și al costurilor, cel mai bun serviciu.

Mașinile virtuale Windows Azure livrează o infrastructură flexibilă ce poate oferii resurse la cerere. Sistemul de operare poate fi ales în funcție de nevoi, Windows Server sau Linux cu multiple configurații. Azure oferă virtualizare fără cheltuieli de achiziție și întreținere hardware, cu ajutorul căruia se pot implementa imagini preconfigurate sau se pot încărca discuri virtuale (VHD) ce conțin sisteme de operare server cu toate serviciile incluse. O astfel de mașină virtuală poate fi creată, întreținută și conectată cu multiple mașini virtuale, pentru a transfera traficul între ele, prin metodele puse la dispoziție, precum portalul web (Azure Management Portal), cmdlets pentru Windows PowerShell sau API-urile de întreținere (Service Management API). La orice moment o mașină virtuală creată poate fi ștearsă și apoi recreată ca orice altă mașină virtuală locală. Comunicarea cu propriul servicu se face într-un mod ușor de folosit și profesional în același timp, tocmai datorită extensiilor existente. Pe mașina virtuală este pus la dispoziție un VM agent care este pasiv când nu este folosit, dar la inițializare crește puterea mașinii virtuale creând o legătură sigură cu alte tehnologii, respectiv extensii. Aceste extensii, ca PowerShell, Puppet, Visual Studio și Chef, nu rămân pe imaginea mașinii. Astfel pentru a folosii toate aceste tehnologii trebuie mai întâi instalat VM agent.

Toate mașinile virtuale din același serviciu cloud sau rețea virtuală pot comunica între ele printr-o rețea privată folosind un canal comun. Dar comunicarea cu alte resurse externe pe Internet sau cu o rețea virtuală externă, o mașină virtuală folosește puncte de legătură (endpoints). Aceste puncte de legătură manipulează traficul către mașina virtuală. Crearea punctelor de legătură se face dintr-un portal de întreținere (Management Portal), precum Remote Desktop, Windows PowerShell sau Secure Shell (SSH). Cu ajutorul acestora se poate controla traficul de intrare la portul public configurând regulile rețelei de acces la lista de control (ACL) a punctului de legătură. Fiecare punct are un port public și unul privat. Cel privat este folosit intern de mașina virtuală pentru a verifica traficul prin punctul de legătură. Portul public este folosit de către Azure pentru a controla și a comunica cu mașina virtuală dinspre sursele externe. După crearea unui punct de legătură, se poate folosi lista de control a rețelei de acces ACL pentru a se defini reguli ce ajută izolarea și controlul traficului de intrare prin portul public. Valorile predefinite pentru porturile și protocolul punctelor de legătură asigură acces rapid și usor la crearea acestora prin portalul de întreținere Management Portal. Pentru toate celelalte puncte de legătură, se pot specifica porturile și protocolul când sunt create. Resursele pot fi conectate la aceste puncte de legătură printr-un protocol de tip TCP sau UDP. Protocolul TCP include comunicarea HTTP și HTTPS. Configurarea protecției de tip Firewall se face automat pentru porturile asociate cu Remote Desktop și Secure Shell (SSH. Pentru porturile specificate ale celorlalte puncte de legătură, configurarea nu se face automat pentru firewall-ul sistemelor de operare externe. Când este creat un punct de legătură, trebuie configurate porturile specifice în firewall pentru a permite transmiterea de date prin acel punct.

Modul în care se face autentificarea într-o mașină virtuală depinde de sistemul pe care rulează, Windows Server sau Linux, fiind aceiași metodă ca la un sistem local, dar și de tipul conexiunii prin care este accesată mașina. O mașină virtuală cu Windows Server poate fi accesată prin Remote Desktop. În portalul de întreținere (Management Portal) există comanda Connect ce va crea o conexiune de tip Remote Desktop în câteva secunde. Pentru o mașină cu sistemul de operare Linux, poate fi folosit clientul Secure Shell (SSH) pentru autentificare. Pe computerul local trebuie instalat un client SSH, din cele disponibile, spre exemplu PuTTY pentru un computer cu sistemul de operare Windows, OpenSSH pentru sistemul de operare Linux. Windows PowerShell Remoting este una din soluții pentru un computer cu sistem de operare Windows, client ce permite o conexiune la distanță către unul sau mai multe computere de la un computer local printr-o sesiune Windows PowerShell. Pentru ca acest lucru să fie posibil mașina virtuală trebuie configurată pentru a permite Windows PowerShell Remoting. Configurarea poate fi făcută la crearea mașinii sau în orice moment după aceea. Procesul constă în adăugarea unui punct de legătură ce specifică portul și protocolul folosite.

3.3. Windows Phone

Windows Phone (WP) este un sistem de operare pentru telefoane inteligente (smarthphone) dezvoltat de Microsoft. Acesta este succesor al Windows Mobile, deși este incompatibil cu platforma anterioară. O dată cu Windows Phone, Microsoft a creat și o nouă interfață, denumită Modern UI (cunoscută anterior ca Metro). Spre deosebire de predecesorul său, Windows Phone are ca țintă publicul de consum, și nu mediul companiilor. A fost lansat pentru prima dată în Octombrie 2010 cu versiunea Windows Phone 7. Actuala versiune poartă denumirea de Windows Phone 8, lansată pe data de 29 octombrie 2012, ca o nouă generație de sisteme de operare. Windows Phone 8 înlocuiește arhitectura Windows CE cu cea bazată pe nucleul Windows NT, având componente asemănătoare cu cele din Windows 8, astfel permițând o portare rapidă și ușoară între cele două platforme. În timp ce a fost adăugat un număr esențial de îmbunătățiri la nivel de aplicații, au fost făcute schimbări semnificative și la nivel de hardware, precum suport pentru procesoare cu mai multe nuclee și ecrane cu rezoluții mai mari.

3.3.1. Windows Phone SDK 8

Windows Phone 8 SDK , pachetul de dezvoltare software, permite dezvoltatorilor să folosească Visual C#, Visual Basic și Visual C++ pentru a dezvolta aplicații pentru dispozitivele cu sistemul de operare Windows Phone 8. A fost lansat în februarie 2013, data la care Microsoft a decis oprirea dezvoltării instrumentelor XNA, permițând dezvoltatorilor să programeze jocuri în limbajul .NET. Comunitatea dezvoltatorilor a avut reacții opuse la anunțarea acestei decizii, chiar cu implicări legale. XNA ca limbaj și instrument de dezvoltare, dezvoltat pe lângă DirectX a pierdut în favoarea a Windows Runtime implementat pe DirectX, forțând aplicațiile Windows Phone să fie scrise în limbaj nativ în cazul jocurilor. Totuși încă există software terțe, precum MonoGames ce permit dezvoltatorilor să coninue să folosească XNA în Windows Runtime, Windows Phone 8 și alte platforme. O dată cu noile instrumente îmbunătățite, emulatorul a fost schimbat complet, acum folosind Hyper-V ca hipervizor, acesta fiind valabil doar pe Windows 8 Pro și Windows Server 2012, versiunea 64-bit. Windows Phone 8 suportă un subset al obiectelor Windows Runtime pentru a facilita reutilizarea codului între cele două platforme, Windows 8 și Windows Phone 8. Codul nativ este suportat în Windows Phone 8, dar poate fi utilizat doar pentru dezvoltarea în DirectX sau a componentelor Windows Runtime. Aplicațiile ce folosesc XAML trebuie în continuare implementate cu ajutorul limbajului .NET. O dovadă că trecerea nu a fost completă, este subsetul de aplicații (API) Win32 ce primesc suport prin intermediul Windows Phone 8 SDK. Pentru dezvoltatorii de jocuri care nu doresc să facă acestă trecere, în cazul acestora fiind cea mai radicală, deși este recomandată, Microsoft oferă suport pentru pachetele terțe, precum Unity pentru a permite dezvoltarea jocurilor cu ajutorul acestora, urmând a fi portate cu ușurință pe platforma Windows Phone. În cazul aplicațiilor Windows Phone 7, trecerea nu le-a afectat, acestea fiind compatibile cu Windows Phone 8, eventualele erori de funcționare fiind doar excepții nesemnificative.

Toate pachetele de dezvoltare (Windows SDK) sunt puse la dispoziție gratuit pe centrul de descărcare Microsoft (Microsoft Download Center), în formate ISO și web. Utilizatorii pot instala întregul SDK sau pot alege să instaleze doar anumite componente, precum exemplele de cod sau doar instrumentele de dezvoltare. Unele componente sunt incluse în Microsoft Visual Studio și pot fi adăugate o dată cu instalarea acestuia.

3.3.2. Integrare în Azure

Windows Phone oferă o mulțime de oportunități dezvoltatorilor pentru a crea aplicații. Dar, în unele cazuri, dezvoltatorii se găsesc în situația de a fi limitați de atribute specifice dispozitivelor mobile, procesarea cosntrânsă, viața bateriei, spațiu de stocare limitat și conexiunea la internet. Constant, este important ca serviciile să fie legate de dispozitiv, ideal prin procesare scalabilă, autonomie, spațiu de stocare suficient și conectivitate nelimitată. Toate acestea pot fi oferite de cloud computing cu ajutorul platformei Windows Azure.

În cele mai multe cazuri, cloud computing dictează normele de utilizare. Orice dezvoltator se poate folosi de o lume viruală nelimitată, din punct de vedere al resurselor. Pentru dezvoltatori, Windows Azure reprezintă un complement pentru aplicațiile mobile, permițând concentrarea implementării doar asupra clientului aplicației. Administrarea sau monitorizarea sistemului de operare sau a hardware-ului sunt preluate de Windows Azure.

Pentru a eficientiza procesul de dezvoltare Microsoft oferă pachetul Windows Azure Toolkit pentru Windows Phone, ce permite dezvoltatorilor să creeze aplicații pentru Windows Phone integrate în Windows Azure utilizând Visual Studio. Acesta vine cu modele de proiect predefinite pentru a oferi un punct de start preconfigurat în dezvoltarea serviciilor comune ce se execută în Windows Azure. Pachetul conține biblioteci, exemple de aplicații și documentație.

3.3.3. Interfața utilizatorului

Windows Phone oferă o interfață proiectată de Microsoft pentru sistemul Windows Phone, denumită inițial Metro, iar acum purtând numele de Modern UI, fiind inspirată de interfața folosită în aplicația Zune HD. Ecranul de start, numit "Start screen", este format din forme de dreptunghi (tiles), inspirate din sistemul de operare Windows 8. Acestea fac legătura cu aplicațiile, funcțiile și obiectele sistemului. Utilizatorii pot adăuga, rearanja sau șterge aceste forme, ce nu servesc doar ca butoane sau link-uri, conținutul fiind dinamic, putând fi actualizat în timp real. Spre exemplu, câmpul ce face legătura cu un cont de mail poate afișa numărul de mesaje necitite sau în cazul unei aplicații meteo, temperatura dintr-o anumită zonă. Noua interfață, Modern UI a sistemului de operare Windows Phone este foarte apreciată pentru stilul său, fiind considerată originală și cu un aspect proaspăt și curat.

Unele caracteristici ale Windows Phone sunt organizate în grupuri (hubs), ce combină conținutul local cu cel online prin integrarea Windows Phone cu rețelele de socializare cunoascute, precum Facebook, Windows Live și Twitter. De exemplu, grupul de imagini (Pictures) afișează fotografiile surprinse cu camera foto a dispozitivului, dar și fotografiile din albumele foto de pe contul de Facebook al utilizatorului. Din grup, utilizatorii pot utiliza direct funcții precum comment și like pe rețelele de socializare. Alte grupuri ce pot fi menționate sunt People, Xbox Music, Video și Games, Windows Phone Store și Microsoft Office.

Windows Phone folosește tehnologia de atingere multiplă (multi-touch), integrată cu cele mai multe aplicații disponibile în prezent. Interfața predefinită prezintă o tematică închisă la culoare pentru a prelungi viața bateriei deoarece pe ecranele OLED pixelii de culoare neagră nu emit lumină. Utilizatorii pot schimba oricând acestă temă, optând pentru un fundal colorat sau alb prin utilizarea meniului de setări. Totuși, printre câmpurile de legătură predomină culorile, chiar și în tema predefinită. Multe dintre aceste culori sunt setate automat de aplicația pe care o reprezintă.

Utilizatorii pot introduce text folosind interfața cu ajutorul unei tastaturi virtuale afișate pe ecran care prezintă caracteristici proprii precum inserarea de fețe zâmbitoare (emoticon) sau instrumente de verificare a ortografiei și prezicerea cuvintelor. Dezvoltatorii de aplicații pot crea diferite versiuni de tastaturi, adăugând, modificând sau ștergând caractere, cel mai utilizat caz este acela când utilizatorul este limitat doar la utilizarea caracterelor numerice. Prin intermediul tastaturii standard utilizatorii pot schimba cuvinte ce au fost scrise deja primind opțiuni similare și pot accesa caractere similare ținând apăsat pe caracterele afișate. Caracterele sunt așezate într-un mod ergonomic pe ecran, spațierea permițând utilizatorului să scrie mesaje în mod intuitiv, atât in modul portret, cât și în landscape. Dar aceasta nu este singura opțiune, utilizatorii putând opta pentru un telefon inteligent ce are integrată o tastatură fizică ce înlocuiește acestă funcționalitate, oferind același mod eficient și rapid de a introduce text.

3.4. Frameworkul X++

X++ este un limbaj de programare orientat pe obiect,dependent de aplicație și dependent de date. Limbajul este orientat pe obiect și suportă abstractizarea obiectelor, abstractizarea ierarhiei, polimorfism și incapsulare. Limbajul este dependent de aplicație pentru că include funcții precum client, server, changecompany și deisplay care sunt folositoare pentru a scrie aplicații ERP client/server, respectiv dependent de date pentru că include funcții precum firstFast, forceSelectOrder și forUpdate, și chiar sintaxă de interogare a bazei de date, care sunt folositoare doar în contextul în care există o bază de date.7

Mediul de dezvoltare îl reprezintă clientul Microsoft Dynamics AX care oferă instrumente de proiectare și implementare a structurii datelor aplicației. Se poate specifica comportamentul tipurilor aplicației scriind cod sursă X++ în editorul X++. Compilatorul integrat procesează codul sursă în formatul intermediar pe biți. Structurile de date, codul sursă X++, codul intermediar și .NET, fiind limbajul intermediar comun (CIL) sunt stocate în structura programului. Microsoft Dynamics AX compune dinamic tipuri de obiecte încărcând cod binar de cel mai mare nivel definit. Obiectele sunt instanțiate din aceste tipuri dinamice. Similar, compilatorul produce cod .NET CIL din codul sursă X++ de cel mai în alt nivel. Tipurile sistemului Microsoft Dynamics AX și caracteristicile limbajului X++ sunt esențiale în scrierea aplicațiilor ERP. Acestea ajută și la evitarea greșelilor comune din programare ce provin din implementarea codului.

Limbajul X++ poate fi inclus în familia limbajelor de programare bazat pe paranteze, referitor la delimitarea blocurilor sintactice prin acolade, precum C, C++, C# și Java. Un dezvoltator familiarizat cu unul din aceste limbaje nu va avea probleme în a înțelege sintaxa X++. Spre deosebire de aceste limbaje, X++ nu este sensibil la majuscule, dar se recomandă folosirea denumirilor de tip cămilă (tipCamila) sau de tip pascal (TipPascal) în cazul variabilelelor pentru o mai buna lizibilitate. Clientul Microsoft Dynamics AX vine în ajutorul programatorului cu un instrument ce aplică automat indentarea codului și capitalizarea literelor unde este cazul, numit Source Code Titlecase Update.

4. PROIECTAREA APLICAȚIEI WINDOWS PHONE

4.1. Scenariul aplicației – gestiunea stocurilor

Crearea unei aplicații mobile care permite utilizatorilor Microsoft Dynamics AX să comunice informații către serviciul de gestiunea stocurilor.

Clienții Microsoft Dynamics AX crează un ecosistem prin care personalizează și extind sistemul ERP pentru nevoile individuale ale organizațiilor și industriilor. Ne propunem să creăm o soluție prin care utilizatorii să aibă o expriență plăcută pe orice dispozitiv și prin care să își administreze servicul din cadrul companiei. Această soluție se adrsează scenariului unui utilizator care se află în afara mediului companiei și primește informații privind un transport care trebuie introdus în sistem imediat. Astfel, acesta folosește aplicația pentru a accesa contul de serviciu. Aplicația creată poate accesa serviciul de oriunde din punct de vedere geografic prin acces la Internet. Serviciul de gestiunea stocurilor este un serviciu folosit de aproape orice companie ce fabrica produse, înmagazinează produse sau pur si simplu se ocupă de transportul acestora. Aplicația dorește ușurarea procesului de adăugare a unei noi tranzacții în sistem pentru reducerea timpului.

Aplicația trebuie să asigure activitățiile de bază ale serviciului de gestiunea stocurilor din cadrul sistemului ERP într-un mediu în afara biroului, având în vedere că depozitarea produselor și transportul acestora se face în afara spațiului destinat afacerii propriu-zise și al biroului personalului care organizează aceste activități. Aplicația își propune să ofere vizibilitate personalului din cadrul serviciului, oriunde s-ar afla, prin dispozitivul mobil, dar totodată să le permită acestora să facă modificările necesare deși nu au acces la aplicația ERP integrată local în spațiul companiei.

4.2. Arhitectura aplicației

Din punct de vedere arhitectural ne propunem să construim o soluție prin care utilizatorii să primească informații și să trimită tranzacții către Microsoft Dynamics AX, chiar dacă aceștia nu sunt în același domeniu sau rețea locală în care se află implementat Microsoft Dynamics AX. De exemeplu, o soluție care permite unui client să acceseze un serviciu al unei aplicații care utilizează o protecție de tip firewall.

Vom puncta următoarele aspecte necesare:

Serviciul de gestiunea stocurilor (SCM) implementat în Microsoft Dynamics AX va transmite date din și în aplicație

Utilizatorii vor utiliza aceleași date de acces în clientul aplicației mobile, ca și cele folosite în serviciul creat în Microsoft Dynamics AX

Doar utilizatorii autentificați și autorizați vor putea comunica cu serviciile Microsoft Dynamics AX utilizând clientul aplicației mobile

Figura 4.1 ilustrează cum diferite componente interacționează pentru a permite aplicației mobile să comunice cu Microsoft Dynamics AX.

Figura 4.1. Arhitectura aplicației pentru gestiunea stocurilor

Serviciul de gestiunea stocurilor trebuie proiectat în concordanță cu scenariul propus în aplicația mobilă. Acesta va fi creat ca serviciu și legat de baza de date utilizată, ca apoi să fie implementat un port pentru a expune serviciul la operații externe. Acest serviciu este proiectat din punct de vedere arhitectural pentru a asigura integritatea și securitatea datelor în interiorul rețelei sau domeniului Microsoft Dynamics AX. Din acestă cauză schimbul de date se va efectua printr-un Service Bus, astfel evitându-se expunerea serverului, Information Services (IIS) prin configurări asupra firewall-ului. Avem la dispoziție Microsoft Windows Azure Service Bus, ce permite transmiterea de informații sub formă de mesaje, în cazul aplicației noastre permițând schimbul de informații din alte rețele decât cea locală. Pentru a profita de această capacitate arhitecturală vom folosi un serviciu de legătură Windows Communication Foundation (WCF) construit în scopul rezolvării legăturii dorite în acest scenariu.

Pentru ca toată arhitectura să funcționeze, serviciul de autentificare trebuie să se facă prin Access Control Service (ACS) și Active Directory Federation Services (AD FS) pe client. ACS utilizează un Service Bus dedicat ce joacă un rol foarte important în acestă soluție, autorizând cererea efectuată către un serviciu din Service Bus. Întărește autorizarea prin faptul că o cerere din partea clientului necesită un token de securitate pentru a demonstra veridicitatea identității utilizatorului. Astfel putem folosi Active Federation pentru autentificarea utilizatorului cu propriile date create de Microsoft Dynamics AX păstrând securitatea prin implicarea clientului aplicației mobile să ceară în mod activ un token de securitate de la Active Directory Federation Services (AD FS) utilizând protocolul WS-Trust. Clientul va trimite acest token la ACS, care la rândul lui va genera un token web (SWT) ca formă de autorizare pentru a trimite mesaje în mod securizat prin Service Bus. Pe parte de mobil vor fi introduse decât datele utilizatorului, numele de utilizator și parola, dar acestea se vor găsi și în AD FS, în acest caz este folosit ca un serviciu de securitate (STS) ce își sfârșește rolul după ce va fi consumat în Microsoft Dynamics AX, iar utilizatorul va fi autentificat cu succes pe clientul mobil sau va primi un mesaj de eroare în cazul în care datele introduse nu sunt valide.

4.3. Serviciul de gestiune a stocurilor în Microsoft Dynamics AX

Serviciul de gestiunea stocurilor integrat în Microsoft Dynamics AX își propune să conecteze toate procesele de vânzare și achiziție cu logistica firmei pentru a oferi vizibilitate și organizare întregului lanț de livrare. Administrarea organizațiilor de distribuție în companie este rezolvată printr-o soluție multifuncțională.

Tabel 4.1. Descrierea modulelor serviciului pentru gestiunea stocurilor

Gestiunea stocurilor presupune organizarea produselor din stoc după dimensiunea depozitului, locației, lotului, respectiv numărului de serie. Serviciul profită de avantajul sistemelor de administrare și a metodelor de evaluare a stocului, precum "primul venit, primul servit" (first in/first out, FIFO) sau "ultimul venit, primul servit" (last in/first out LIFO), de costurile standard și de dimensiunile generale pentru a reduce costurile ce implică tranzacțiile și pentru a elimina pierderile.

Funcționalitățiile proiectate să producă vizibilitate între companii și partenerii implicați în afacere sunt punctele cheie ale Dynamics AX. Organizațiile pot vedea stocurile actuale în timp real pe lângă cererile cliențiilor sau punctelor de distribuție ale companiei. Toate aceste procese necesită planificare, iar serviciul de gestiune oferă strategii și metode calculate după algoritmi complecși. Capacitățiile sistemului ERP precum sistemul de ordine automat ce aranjează clienții în funcție de cerere și personalizarea stocurilor după perisabilitate, importanță, localizare geografică etc. , pot fi folosite pentru a eficientiza răspunderea cererilor și a reduce erorile de transport. Abilitatea de a schimba ordinea și detaliile unei tranzacții, modificarea setărilor predefinite pentru a personaliza excepțiile sunt capacități ce pot îmbunătății procesul de gestiune. Microsoft Dynamics AX permite folosirea matriciilor SKU pentru a organiza mai eficient produsele care vin pe mai multe categorii, precum mărimiile în industria textilă, respectiv stil sau culoare. Un lot poate fi urmărit în funcție de numărul de serie, astfel asigurând calitatea produselor pe toată durata tranzacției, funcția responsabilă este cea a controlului calității (QC). Serviciul oferă o experiență completă, deși are câteva deficiențe precum lipsa instrumentelor de vânzare online sau de planificare în detaliu. Unele sisteme de administrare a transportului (TMS) sunt disponibile o dată cu serviciul, dar majoritatea vin ca adiții din surse terțe.

Sistemele ERP create din sisteme de contabilitate financiară au în general predefinite instrumente de organizarea ordinii distribuției vânzărilor, procesarea achiziției și administrarea stocului. Această încercare determină ca instrumentele create să nu fie la fel de sofisticate ca cele oferite de sistemele specifice, care în general sunt construite în scopul gestiunii stocurilor cu funcții precum administrarea depozitelor, planificarea cererilor și organizarea transporturilor.

4.4. Stabilirea conexiunii pentru Windows Azure Service Bus

Stabilirea conexiunii pentru Windows Azure Service Bus presupune folosirea serviciului de gestiunea stocurilor creat în Microsoft Dynamics AX utilizând adaptorul Service Bus și implementarea unui serviciu de legătură WCF. Acesta crează legătura prin Windows Azure Service Bus, o conexiune externă la Service Bus pe care se transmit mesajele de la clientul mobil. Un mesaj transmis în acestă manieră este apoi direcționat spre Microsoft Dynamics AX de serviciul WCF.

Pentru a crea serviciul WCF cu un punct de legătură propriu implementat pe Windows Azure Service Bus trebuie mai întăi să definim un contract de servicii bazat pe serviciul creat in Dynamics AX. Apoi să setăm o legătură HTTP ca fiind un canal sigur pentru Service Bus, prin care vom extrage informațiile primite dinspre client ca mesaje. Clientul va crea o cerere folosind un proxy generat de serviciul WCF și o trimite către punctul de legătură. În acest caz prin Service Bus mesajul va ajunge la serviciul WCF care la rândul său va pasa datele la serviciul preconfigurat din Microsoft Dynamics AX. În toată schema este foarte important ca doar utilizatorii autorizați să poată trimite și primii mesaje prin Service Bus. În plus, pentru siguranța celorlalte conexiuni trebuie să ne asigurăm că doar utilizatorii autorizați pot transmite cereri către serviciul WCF. Verificarea utilizatorilor se va face utilizând datele existente din Active Directory Domain Services și pot fi auntetificați de Active Directory Federation Service. Pe scurt, trebuie să facem o cerere către serviciul de getiunea stocurilor în contextul unui utilizator autorizat, informațiile utilizatorului fiind atașate datelor trimise de client către serviciul WCF.

Pentru a crea serviciul de legătură WCF avem nevoie de următoarele configurări și instrumente:

Certificatul de înregistrare prin token instalat pe serverul AD FS pe mașina virtuală pe care vom implementa serviciul WCF și codul certificatului.

Windows Azure Service Bus creat.

Microsoft Visual Studio și Microsoft .NET Framework

Windows Azure SDK, din a cărui bibliotecă Windows Azure Libraries pentru .NET vom instala componenta Service Bus (Microsoft.ServiceBus.dll).

Windows Identity Foundation (WIF) SDK instalat pe Visual Studio.

Primul pas este crearea contractului de servicii. În Visual Studio se crează un nou proiect Windows Service .NET și definim două metode pentru a deschide, respectiv închide punctul de legătură.

using System.ServiceModel;

using System.ServiceProcess;

namespace TransactionConnectorService {

public partial class ConnectorService: ServiceBase {

private ServiceHost host;

public ConnectorService() {

InitializeComponent();

}

protected override void OnStart(string[] args) …

protected override void OnStop() …

}

Orice client ce folosește serviciul apelează operația CreateTransaction și transmite parametrii necesari definiți metodei. Metoda procesează mesajul primit extrăgând token-ul Security Assertion Markup Language (SAML) din header-ul mesajului. Tokenul este verificat de serviciul Active Directory Federation Service și apoi validat. Conținutul mesajului este transmis ca parametru operației serviciului de gestiunea stocurilor. Procesarea, validarea și extragerea datelor sunt facilitate de bibliotecile WIF.

În continuare adăugăm o referință la serviciul de gestiunea stocurilor. Trebuie să generăm clientul proxy pentru serviciul de stocuri pentru a aduna contractele de servicii, legăturile și adresele pentru punctul de legătură. Pentru a adăuga referința, trebuie să folosim o legătură deschisă a portului intern ce a fost activat în proiectarea clientului. Acest lucru determină expunerea operației createRecord a serviciului. Referința apare ca nod în Service References în Solution Explorer și se poate observa că s-a generat automat și fișierul corespunzător clientului proxy. Aceste schimbări automate sunt făcute de configurația aplicației în concordanță cu legăturile create anterior utilizând protocoalele de securitate corespunzătoare. Acest comportament poate fi observat, verificat și configurat în codul sursă generat.

Elementul <client> configurează adresa punctului de legătură pentru a face trimitere la mașina care găzduiește serverul pe care este implementat serviciul de stocuri. În acest fel, serviciul de legătură poate fi executat pe orice mașină, chiar dacă nu este în rețea cu serverul, apelul făcându-se utilizând NetTcp binding. În acest caz folosim referința creată și folosim contractul operației definit pentru a apela metoda.

Creăm o nouă metodă privată care trimite detaliile tranzacției către serviciul din Microsoft Dynamics AX. Acesta populează valorile din înregistrare cu datele serviciului, apelează operația de creare a înregistrării și returnează valoarea ID-ului operației serviciului. ID-ul înregistrării va folosi apelul următoarei metode ce crează o tranzacție.

private long SubmitTransactionToAX(DateTime dateTime, decimal amount, string sendLocation, string receiveLocation, string comments, string windowsAccountName) {

newTransactionRecord record = new newTransactionRecord() {

parmNotes = comments,

parmTransactionCurrencyAmount = amount,

parmTransactionDate = dateTime,

};

using(newTransactionServiceClient client = new AXTransactionServiceReference.newTransactionServiceClient()) {

newTransactionRecord transactionRecord = record;

CallContext callContext = new CallContext() {

LogonAsUser = windowsAccountName

};

return client.createRecord(callContext, transactionRecord);

}

Metoda definită crează o instanță a serviciului client, setează valorile membriilor și apelează operația de creare a înregistrării. Obiectul CallContext care este transmis apelului serviciului cuprinde valorile necesare header-ului mesajului, precum utilizatorul, compania și alte date de securitate. Astfel apelul de creare se face doar în contextul unui utilizator valid. LogonAsUser, inițializat cu numele de utilizator trebuie să aibă aceiași valoare ca cea primită din Active Directory Federation Service, sub forma domeniu\nume de utilizator și identifică utilizatorul ce trimite o cerere dinspre client. Microsoft Dynamics AX îl validează deoarece folosește același serviciu Active Directory și în același timp verifică și permisiunile adăugate în configurație asupra rolului utilizatorului.

Următorul pas presupune implementarea legăturii Service Bus și a punctului de legătură pentru serviciul WCF. Pentru a configura punctul de legătură al serviciului să primească datele din Service Bus, trebuie configurată aplicația adăugând o legătură standard http care comunică cu Service Bus. Trebuie specificate adresele punctului de legătură și al contractului serviciului, ca apoi să se implementeze legătura dorită în configurație specificând datele de acces din Service Bus.

Figura 4.2. Ilustrarea procesului de legătură la Service Bus

Configurația setează legătura dintre cele două puncte printr-un transport sigur. Pentru a ne asigura de acest lucru trebuie setată și valoarea parametrului ce specifică timpul de autentificare ca fiind bazat pe un token de acces, ceea ce forțează clientul serviciului să valideze datele din Service Bus înainte de a trimite vreun mesaj. Cum apare și în Figura 4.2, pentru a se conecta la Service Bus, clientul prezintă tokenul de securitate (SWT) serviciului ACS. Pentru a defini comportamentul punctului de legătură trebuie configurate valorile din interior, numele de utilizator și parola contului pe Service Bus. În funcție de validitatea acestor valori se stabilește comportamentul față de tranzacția dorită.

Având date de acces valide, punctul de legătură trebuie implementat pentru a specifica contractului din serviciul de legătură comportamentul dorit. Se inițializează adresa din Service Bus sub formă https și se implementează metadata punctului de legătură. Pentru a genera un client proxy pentru clientul mobil trebuie expusă adresa punctului de legătură ca metadata. În nodul în care este specificat comportamentul serviciului se adaugă un nou nod care va avea acest comportament. Pentru a finaliza acest proces trebuie deschisă conexiunea în Service Bus în așa fel încât să pentru primi date dinspre punctul de legătură. Porturile folosite sunt cuprinse între 9350-9354, local, dar în cazul unei conexiuni externe va apela porturile 80 (HTTP) sau 443 (HTTPS).

Următoarea metodă deschide punctul de legătură având comportamentul definit anterior în configurația aplicației din serviciul de găzduire.

protected override void OnStart(string[] args) {

host = new ServiceHost(typeof (TransactionConnectorService.TransactionService));

WriteToEventViewer(host.BaseAddresses[0].ToString());

try {

host.Open();

WriteToEventViewer(string.Format("Listening on: {0}",

host.Description.Endpoints.Find(

typeof (TransactionConnectorService.ITransactionService)).Address));

} catch (Exception e) {

WriteToEventViewer(e.Message);

}

Această conexiune este inchisă prin apelarea metodei OnStop, iar evenimentele ce trebuie inițializate la autentificare trebuie configurate în System.Diagnostics.

Urmărorul pas este validarea și extragerea conținutului mesajelor primite ce presupune inspectarea fiecărui mesaj trimis de client. Mesajul vine sub formă SAML și conține header-ul care este inițializat cu datele de acces și tokenul de securitate generat de Active Directory Federation Service. În acest context Windows Identity Foundation este utilizat pentru a valida tokenul și datele, ca apoi să extragă datele necesare apelului serviciului de gestiunea stocurilor.

Comportamentul trebuie automatizat tot din fișierul de configurație al aplicației, unde adăugăm valorile ce se inițializează cu tokenul de securitate în format SAML. Serviciul STS care a generat tokenul sub formă SAML la schimbul cu serviciul ACS trebuie adăugat ca dată sigură. Valorile amprentei și a numelui trebuie obținute din certificatul public de înregistrare expus în metadata serviciului STS. Datele emise sunt datele de acces ce verifică identitatea utilizatorului, în cazul de față fiind incluse în tokenul de înregistrare prin convertirea la SAML. În acest caz, amprenta tokenului de înregistrare trebuie specificată în configurația serviciului în nodul de validare ca o valoare sigură pentru a fi comparată cu semnătura digitală, oferind un răspuns asupra tokenului.

Crearea tranzacției se face de către operația CreateTransaction utilizând datele extrase din mesaj, după ce tokenul de securitate din header-ul mesajului s-a dovedit ca fiind unul valid, se poate trimite un răspuns către clientul mobil. Comportamentul definit inspectează tokenul, folosește WIF pentru a-l valida comparându-l cu valorile din configurație, extrage numele de utilizator și apelează metoda SubmitTransactionToAX, care apelează serviciul de gestiunea stocurilor.

public long CreateTransaction(DateTime dateTime, decimal amount, string sendLocation, string receiveLocation, string comments){

…

using (XmlReader reader = XmlReader.Create(newStringReader(samlTokenString))) …

IPrincipal principal = new ClaimsPrincipal(claimsIdentity);

IClaimsIdentity identity = (IClaimsIdentity)principal.Identity;

return SubmitTransactionToAX(transactionData, windowsAccountName);

}

Contul de utilizator ce utilizează serviciul trebuie să transmită datele folosind contul proxy alocat de .NET Business Connector. Utilizând un server proxy, ne asigurăm că se poate crea o conexiune de pe clientul mobil, chiar dacă utilizatorul este deja conectat într-o instanță AOS în Microsoft Dynamics AX, pentru a satisface lucrul în paralel. Pentru ca acest lucru să fie posibil contul trebuie să fie creat într-un domeniu Windows, dedicat, să utilizeze o parolă fixă, să corespundă drepturilor de autentificare și să nu se suprapună cu alt cont existent. Configurarea manuală a acestor conturi poate fi făcută doar de către un Administrator cu acces la serviciul de gestiunea stocurilor.

4.5. Dezvoltarea legăturii de date dintre client și serviciul intermediar WCF

Implementăm o aplicație mobilă Windows Phone reprezentând clientul pentru serviciul backend. Limbajul folosit este C#, iar sistemul de operare Windows Phone 8. Pentru dezvoltare, ca instrumente, folosim Visual Studio cu Windows Phone SDK 8 și Windows Azure SDK cu biblioteca Windows Azure Libraries for .NET ce conține componente pentru Service Bus.

Creăm clientul aplicației Windows Phone ce va folosi serviciul de gestiunea stocurilor al Microsoft Dynamics AX găzduit pe platforma Windows Azure folosind adaptorul Service Bus. Începem creând un proiect nou de aplicație Windows Phone în Visual Studio și generăm un client proxy care utilizează serviciul de legătură. Interfața aplicației presupune controale pentru inserarea datelor de acces pentru autentificare, în primă instanță, apoi o vizualizare pe care implementăm controalele necesare evenimentului presupus ca scenariu al aplicației, introducerea unei tranzacții noi.

Pentru proiectul aplicației se poate crea un proiect gol sau se poate folosi un model predefinit din Visual Studio. Având în vedere că pentru prima vizualizare ne propunem un model simplu de autentificare, Visual Studio oferă unul predefinit pe care îl folosim. Cu interfața și controalele deja create trebuie să facem referință la serviciul de legătură WCF. Acest lucru se face introducând adresa MEX specificată la crearea serviciului de legătură. În acest moment se poate verifica dacă legătura s-a făcut, pornind serviciul WCF și activând metadata punctului de legătură, clientul poate obține metadata serviciului și în același timp să genereze fișierul proxy necesar. Pentru a păstra aceste date este creată o configurație în care datele de legătură sunt păstrate.

Punctul de legătură MEX poate fi accesat în afara domeniului în timpul dezvoltării doar dacă punctul de legătură la care se face referință, în cazul de față cel al serviciului WCF este găzduit pe Service Bus. După ce am adăugat referința către serviciul de legătură, în fișierul proxy generat trebuie modificată metoda de creare a tranzacției. Acestă metodă este creată automat și este o operație a serviciului care apelată trimite datele introduse. În vizualizarea aplicației avem cinci câmpuri, data, cantitatea, punctul de plecare, punctul de livrare și comentariile, valori care trebuie transmise ca date în acestă metodă.

public void CreateTransactionAsync(

System.DateTime dateTime, decimal amount, string sendLocation, string receiveLocation, string comments)

{

this.CreateTransactionAsync(dateTime, amount, sendLocation, receiveLocation, comments, null);

}

Dar până când acestă metodă să fie apelată și să trimită datele tranzacției, aplicația trebuie să se autentifice în Service Bus la transmiterea unei cereri către serviciu și să trimită datele de acces ale utilizatorului pentru identificare și autorizare în cadrul serviciului, sub formă de token SAML introdus în mesaj. Bazat pe ceea ce este implementat, aplicația necesită două seturi de date de la utilizator, datele necesare creării unei noi tranzacții în cadrul operației de gestiunea stocurilor în Microsoft Dynamics AX, respectiv datele de acces ale utilizatorului necesare autentificării șî autorizării lucrului cu serviciul menționat.

Pagina de autentificare, în format xaml este implementată de modelul predefinit în Visual Studio și proiectează datele de acces necesare autentificării. Datele sunt introduse ca text de către utilizator.

Figura 4.3. Ecranul de autentificare

Numele de utilizator, parola, numele conexiunii, în cazul de față adresa Windows Azure, precum și adresa serverului de autentificare, punctul de legătură AD FS sunt folosite pentru autentificarea utilizatorului la operațiile serviciului.

Datele tranzacției trebuie introduse în interfața clientului. Astfel în proiectul aplicației creăm o nouă pagină principală xaml unde proiectăm datele din fișier pentru a le stoca.

Figura 4.4. Ecranul de adăugare a unei noi tranzacții

Utilizatorul introduce datele în câmpurile corespunzătoare și apoi trimite tranzacția apăsând butonul Upload. Acest control aplează o metodă pentru a crea un eveniment ce procesează datele introduse și pentru a le trimite către serviciu de gestiunea stocurilor.

4.6. Implementarea sistemului de autorizare și securitate pentru Windows Phone

Implementarea unui serviciu Active Federation este necesară pentru validarea autentificării în clientul aplicației mobile cu aceleași date de acces ca și cele utilizate în clientul Microsoft Dynamics AX.

Primul pas presupune definirea domeiului în Windows Azure și configurarea Service Bus pentru avea o conexiune sigură între Dynamics AX și aplicația mobilă. Service Bus va fi adăugat ca o legătură sigură în ACS, permițând serviciului ACS să ofere control și securitate asupra punctului de legătură. Acest lucru va asigura un canal de transmitere a datelor, dar pentru ca legătura să poată fi folosită trebuie ca AD FS și ACS să fie configurate ca fiind sigure una cu celalaltă pentru a accepta sau transmite date. Serverul Active Directory se comportă ca un validator. Conține informații despre utilizatorii din domeniu și îi poate identifica în funcție de datele de acces, numele de utilizator și parola. Serverul trebuie configurat pentru a procesa în vederea validării prin AD FS. În contextul acesta singurele cereri valide și acceptate trebuie să fie cele venite dinspre ACS prin Service Bus, definit în prima instanță. Punctul de legătură trebuie setat ca fiind sigur în AD FS, să trimită date dinspre ACS ca un link generat ca metadata. Pe partea de serviciu ACS trebuie configurat să primească date valide de acces dinspre AD FS, lucru care poate fi făcut direct dinspre Portalul de administrare al ACS, unde AD FS este adăugat ca un indentificator, ceea ce determină ca toate datele primite să fie înregistrate și folosite în procesul de validare. Aceste date sunt înregistrate în ACS și inspectate în Service Bus. Fiind date de acces de tip nume de utilizator windows, acestea pot fi mapate ca atare pentru ca serviciul să le recunoască tipul și să le atribuie automat atributul de trimitere, asigurându-se că orice utilizator autentificat și validat de AD FS poate trimite mesaje prin Service Bus. În principiu, crearea legăturii dintre serviciul de legătură WCF și AD FS este doar un schimb de date în scopul validării, iar procesarea se face în funcție de formatul acestor date. AD FS utilizează un token de autentificare creat digital în limbaj SAML conținând datele de acces ale utilizatorului.

Datele trimise de pe dispozitivul mobil, colectate și validate sunt trimise către Microsoft Dynamics AX. Numai utilizatorii autentificați și autorizați au permisiunea de a trimite date prin Service Bus către Microsoft Dynamics AX. ACS și AD FS cooperează pentru a asigura această autentificare și pentru a autoriza adaptorul Service Bus pentru procesarea acestor operații. Autorizarea utilizatorilor Microsoft Dynamics AX se face conform rolurilor integrate în aplicație și a privilegilor defnite în instanță. Toate aceste date se obțin printr-o cerere la AD FS prin protocolul de securitate WS-Trust, fiind date valide și active în conformitate cu regulile definite în Microsoft Dynamics AX, iar rezultatul va fi un token de securitate. Prezentat la ACS, tokenul recunoaște identitatea utilizatorului, generând un token web (SWT) și trimis către client. La orice cerere trimisă de către client, procesată ca mesaj prin punctul de legătură Service Bus, se prezintă tokentul SWT, iar validarea acestuia va autoriza accesul de trimitere al mesajului. Tot la trimiterea cererii, am definit operația de trimitere a tokenului în limbaj SAML primit dinspre AD FS, unde este extras după cum am definit. Implementarea soluției de autentificare și autorizare a utilizatorului presupune crearea proiectului aplicației Windows Phone.

În continuare implementăm autentificarea în aplicația mobilă utilizând tokenurile SAML și SWT pentru a crea o transmitere sigură a datelor prin Service Bus către Microsoft Dynamics AX. În aplicația mobilă creată, creăm o nouă clasă ce se ocupă de autentificarea datelor primite ca token. După validare, evenimentul de manipulare trimite rezultatul procesării ca notificare, eroare în caz de insucces și autentificarea utilizatorului în caz de succes.

public delegate void AuthenticationCompletedEventHandler(object sender, AuthenticationMessageArgs e);

…

public class AuthenticationMessageArgs: EventArgs {

public AuthenticationMessageArgs(AuthenticationMessage authenticationMessage) {

this.AuthenticationMessage = authenticationMessage;

}

public AuthenticationMessage AuthenticationMessage …

}

public class AuthenticationMessage {

public AuthenticationMessage(string message, bool isSuccess) {

this.Message = message;

this.IsSuccess = isSuccess;

}

public string Message …

public bool IsSuccess …

}

Clientul este legat la eveniment pentru a fi notificat în legătură cu terminarea autentificării mesajului, primind un mesaj de succes sau de eroare, apelând următoarea metodă:

private void OnAuthenticationCompleted(AuthenticationMessageArgs args) {

AuthenticationCompletedEventHandler handler = AuthenticationCompleted;

if (handler != null) {

handler(this, args);

}

Definim variabilele membru ce vor stoca datele de acces, adresa definită în Microsoft Azure, punctul de legătură STS, tokenul web SWT, data și timpul la care s-a făcut cererea de autentificare. Dinspre client trebuie să acceptăm datele primite, acestea fiind numele de utilizator (în forma domeniu\nume de utilizator), parola, adresa punctului de legătură al serverului AD FS și adresa domeniului Windows Azure.

public AuthenticationProvider(

string userName, string password, string windowsazureNamespace, string stsEndpointUrl) {

credentials = new UserCredentials(userName, password);

azureNamespace = windowsazureNamespace;

stsEndpoint = stsEndpointUrl;

}

O dată cu definirea adresei din Windows Azure putem defini punctele de legătură necesare procesului de autentificare. În AD FS proprietatea la care are acces punctul de legătură este configurată ca având numai drepturi de citire. Valoare acestia permite STS să răspundă în funcție de formatul tokenului, tipul de criptare, datele pe care le conține, durata de valabilitate etc. Proprietatea este preluată de punctul de legătură ACS, unde se află tokenul SAML și crează tokenul web SWT. Configurarea se face în Service Bus, comportamentul fiind dictat de valoare din STS, activând un set de reguli.Verificarea se face la nivel de Service Bus, iar valoarea de succes o reprezintă expunerea punctului de legătură prin care serviciul va apela operațiile, trimițând cererea împreună cu tokenurile.

Procesul de creare al RST presupune crearea unui mesaj trimis către STS în care sunt specificate datele necesare. Valorile vor fi inserate într-un șir definit de clasă, alocat cererii. Timpul de expriare este setat la 5 minute de la formarea cererii.

Metoda de trimitere a tokenului este apelată pentru a-l transmite către AD FS. Datele principale sunt datele de acces, numele de utilizator și parola, create și adăugate în RST și trimise către STS ca mesaj utilizând serviciul HttpWebRequest. În caz de eroare este atribuit un eveniment care se declanșează și trimite aplicației mobile o eroare cu privire la autentificare, fără ca cererea invalidă să fie deja trimisă. Mesajul de cerere conține tokenul SAML cu datele de acces ale utilizatorului. După ce este extrasă cererea, se generează imediat tokenul de răspuns (RSTR), apelând metoda clasei.

public static string GetResponseStringFromResponse(HttpWebResponse response) {

string responseString = string.Empty;

if (response != null) {

Stream streamResponse = null;

try {

streamResponse = response.GetResponseStream();

using(StreamReader streamRead = new StreamReader(streamResponse)) {

streamResponse = null;

responseString = streamRead.ReadToEnd();

}

} finally {

if (streamResponse != null) {

streamResponse.Dispose();

}

return responseString;

}

Creăm procesul din ACS, presupunând extragerea datelor de acces ale utilizatorului în limbaj SAML din cererea RSTR, implementare ce este ilustrată în Figura 4.5.

Figura 4.5. Ilustrarea schimbului dintre client și serviciu

Printr-o metodă extragem tokenul SAML din șirul primit ca răspuns căutând elementul în care este incapsulat și returnăm conținutul elementului. Procesul presupune parsarea codului xml pentru a găsi tagul corespunzător, <saml:Assertion> fiind denumirea standard. Tokenul SAML extras din RSTR este trimis ca cerere către ACS pentru un token web SWT ce conține datele de autorizare. În ACS este procesat, iar cererea generata ajunge la punctul de legătură al ACS.

Astfel din ACS se trimite înapoi un răspuns conținând tokenul web de securitate SWT, necesar autentificării la Service Bus. Dacă datele introduse și trimise de către clinetul aplicației mobile nu sunt valide sau nu sunt autorizate să facă o astfel de cerere, se trimite înapoi un mesaj de eroare, iar procesul este încheiat blocând accesul. Dacă procesul se încheie cu succes, validarea fiind făcută fără erori prin tokenul SWT, procesul întoarce mesaj de succes, iar autentificarea sau autorizarea se face cu succes.

La nivel de producție, o aplicație Windows Phone ia în considerare aspecte precum platforma și funcționalitățile dorite. De exemplu, dacă o aplicație nu necesită o securitate atât de sporită, bazată pe două tipuri de tokenuri generate la cerere pentru fiecare apel, aceste tokenuri pot primii un timp mai mare de valabilitate. Timpul de expirare poate fi ajustat și la nivel de AD FS și în ACS. Timpul trebuie să fie în concordanță cu scenariul aplicației și în funcție de sensibilitatea datelor sau acțiunilor efectuate. De exemplu, aplicațiile la nivel de afacere precum aceasta de gestiunea stocurilor trebuie să aibă tokenuri cu timp de valabilitate scurt deoarece impactul unui token furat poate fi foarte mare, pierzând integritatea datelor deja existente, dar în cazul unei afaceri mici cu o soluție ERP restrânsă la un inventar numărabil, se poate opta pentru o astfel de soluție de refolosire a tokenului, impactul la atacuri fiind nesemnificativ și ușor de reparat. Pe tot parcursul transmiterii datelor este foarte important ca acestea să fie stocate criptat ca date secrete, fie ele date de acces, tokenuri sau chiar configurări.

4.7. Autentificarea utilizatorului și transmiterea de date

Autentificarea utilizatorului se face utilizând Active Federation implementat anterior, iar datele sunt stocate în client așteptând să fie trimise sub formă de cerere serviciului de legătură. Pentru aceast proces este necesar obiectul AuthentificationProvider creat în aplicația Windows Phone.

private void UploadClick(object sender, EventArgs e) {

Submit();

}

Metoda Submit este apelată separat pentru a inițializa obiectul descris și a-l atașa evenimentului de autentificare. Acest proces apelează metoda prin care trimite cererea de token. Sunt transmise datele utilizatorului colectate din vizualizarea de autentificare, pagina xaml pe care le folosim la inițializarea obiectului. Cererea de obținere a tokenului este executată asincron, fiecare cerere așteptând ca rezultat un token corespunzător cererii.

public void Submit() {

authenticator = new AuthenticationProvider("gsapp\\userAlias", "password",

"gsmobile");

authenticator.AuthenticationCompleted += authenticator_AuthenticationCompleted;

authenticator.IssueToken();

}

Metoda manipulează evenimentul de autentificare și trimite datele tranzacției folosind tokenul primit, în situația în care autentificarea s-a făcut cu succes. Datele se trimit prin Service Bus folosind valorile tokenurilor SWT și SAML extrase de metoda de creare a tranzacției definită anterior. După ce metoda de cerere a tokenului este completă, metoda de finalizare a autentificării este apleată, iar rezultatul evenimentului acesteia determină dacă s-a autentificat cu succes sau nu. În caz de succes, aplicația poate folosi tokenul SWT, tokenul de autentificare la Service Bus și tokenul SAML, tokenul ce conține datele de acces. Acestea două sunt introduse în headerul mesajului, conținutul mesajului având datele introduse la crearea tranzacției și sunt trimise la serviciul de legătură WCF.

Adăugăm o metodă de creare a tranzacției ce va crea mesajul cu structura descrisă anterior și trimitem datele la punctul de legătură din Service Bus cu adresa https://<AzureNamespace>servicebus.windows.net/Transaction/. Un apel este făcut către metoda ce crează tranzacții asincron ca operație a serviciului ce folosește clientul proxy.

Luăm parametrul scop al metodei pentru a adăuga headerul mesajului. Tokenul SAML este convertit într-un șir în format binar. Adăugăm tokenul SAML în acest format și tokenul SWT în header. În final apelăm serviciul de creare a tranzacției. Adaptorul Service Bus cere tokenul într-un format automat predefinit pentru rapiditatea procesării, astfel ACS se ocupă de procesarea mesajului. Header-ul este verificat de Service Bus și în caz de succes eliminat pentru ca mesajul care ajunge la serviciu să fie simplificat, conținând doar datele necesare. Desigur și în Service Bus se așteaptă un format predefinit al tokenului.

private class AcsHeader: MessageHeader {

private string token;

public AcsHeader(string token) {

this.token = token;

}

public override string Name {

get {

return "RelayAccessToken";

}

public override string Namespace {

get {

return "http://schemas.microsoft.com/netservices/2014/05/servicebus/connect";

}

Cererea este trimisă la punctul de legătură Service Bus. Acesta validează mesajul primit pentru a fi transmis la serviciul de legătură WCF, examinând tokenul SWT. Datele tranzacției și tokenul SAML sunt transmise serviciului de legătură. Adaptorul Service Bus așteaptă răspuns de la serviciul WCF după ce operația a fost finalizată. Un eveniment este lansat pentru a notifica utilizatorul în legătură cu rezultatul acesteia. În starea actuală utilizatorul primește un mesaj text, de succes în cazul în care tranzacția a fost adăugată sau de eroare în cazul în care mesajul nu a fost validat sau datele introduse nu au fost consistente. Mesajul este procesat de evenimentul lansat cu succes, iar metoda de creare se asigură de succesul acesteia.

4.8. Distribuția aplicației și costuri aferente

Distribuția aplicației se poate face în multiple moduri, contând publicul țintă, nivelul de răspândire dorit, deschidere către public sau utilizare locală în interiorul firmei.

Următoarele soluții servesc la distribuția aplicației:

1. Direct prin Visual Studio sau XAPDeploy conectând dispozitivul prin usb, pentru acest lucru mobilul trebuie atașat unui cont de dezvoltator.

2. Prin magazinul de aplicații al Windows Phone (Store/Marketplace), unde pot fi configurate setările de intimitate, poate fi blocată de la accesul public sau la funcția de search în așa fel încât doar utilizatorii cu o adresă directă către aplicație o pot descărca. Prin Windows Phone Dev Center se poate seta un preț pentru aplicație. Există un preț de bază care este folosit global în orice store și pot fi specificate diferite țări sau regiuni ce pot avea prețuri diferite. Aplicația de gestiunea stocurilor poate avea un preț generic pentru public și să fie distribuită gratuit în interiorul companiei. Conversia la sistemul valutar respectiv fiecărei țări se face automat. Pentru utilizarea acestui serviciu, trebuie atașate contului Microsoft un cont bancar și informațiile de taxare.

3. Ca aplicație în dezvoltare Beta, este destinat testării aplicației și presupune anumite restricții, precum limita la 10,000 de utilizatori, iar fiecare dintre ei trebuie adăugat manual cu o adresă de mail validă pentru a putea downloada aplicația. Testarea aplicației în versiunea beta, are ca scop punerea ei la dispoziția câtorva persoane care beneficiează de funcționalitățile ei gratuit luându-și angajamentul că vor trimite feedback pentru ca eventualele erori sau neplăceri de utilizare să fie modificate înainte de punerea aplicației în producție. Chiar dacă din punct de vedere arhitectural și al implementării aplicația pare funcțională, testării pot semnala greșeli de conținut, neclarități în logica aplicației sau chiar erori ce duc la funcționalități nedorite sau închiderea bruscă a aplicației, erori care de cele mai multe ori nu reies din studiul codului. Testarea beta asigură lansarea unei aplicații de calitate, crescând satisfacția clienților. Aplicația în versiunea beta nu poate avea preț, toate aplicațiile în acestă fază trebuie să fie oferite gratuit, cu licență, ca și cum ar fi fost cumpărate. Totuși testării beta trebuie să aibă un dispozitiv mobil Windows Phone care să întrunească cerințele minime ale aplicației și un cont Microsoft ce poate fi creat gratuit pe pagina oficială Microsoft.

4. Distribuția aplicației în companie, Microsoft oferă dezvoltatorilor să publice și să distribuie aplicația Windows Phone direct angajațiilor sau utilizatorilor prin magazinul Windows Phone Store. Utilizatorii pot instala aplicațiile publicate de compania proprie numai după ce își înregistrează dizpozitivul mobil ca dispozitiv al organizației, doar aceștia vor avea acces la instalarea acestor aplicații. În primul rând compania trebuie să creeze un cont judiciar pe care înregistrează dispozitivele și distribuie aplicațiile acestora. Acest proces se face utilizând Windows Phone Dev Center achiziționând un certificat Symantec. Înregistrarea dispozitivelor se va face pe bază de token (AET), iar utilizatorii înregistrați sunt adăugați la grupul central al companiei unde găsesc aplicațiile disponibile și datele de instalare.

5. PREZENTAREA APLICAȚIEI

5.1. Cerințe software și hardware

Multe aplicații sau jocuri sunt concepute să profite de anumite caracteristici hardware și software ale telefonului Windows Phone. De exemplu, o aplicație foto este posibil să utilizeze camera foto a telefonului, iar un ghid de restaurante este posibil să trebuiască să folosească funcția GPS pentru a utiliza locația dispozitivului pentru a furniza recomandări în apropiere. Cerințele software și hardware ale aplicației trebuie specificate în Magazinul Windows Phone pentru ca utilizatorul să le ia la cunoștiință înainte de a cumpăra sau descărca aplicația. Unele aplicații solicită anumite permisiuni înainte de a utiliza anumite caracteristici ale telefonului. Utilizatorul are opțiunea de a bloca accesul aplicației, dar acest lucru, în cele mai multe cazuri, determină ca aplicația să nu funcționeze corect. O cerință des întâlnită în ziua de astăzi este un minim de 1 GB de memorie RAM.

Aplicația de gestiunea stocurilor dezvoltată are următoarele cerințe din punct de vedere software, respectiv hardware:

Dimensiune de descărcare: 1 MB, recomandat fiind ca spațiul de stocare să aibă cel puțin 3 MB liberi înainte de instalare.

Funcționează pe dispozitive cu unul din următoarele sisteme de operare: Windows Phone 8, Windows Phone 8.1. Exemple de dispozitive, HTC Windows Phone 8X, Nokia Lumia, Samsung ATIV.

Cerințe aplicație, funcționalități necesare ale dispozitivului pe care aplicația le utilizează:

contacte

identitate telefon

servicii de localizare

servicii de date

tastatură telefon

componentă browser web

HD720P (720×1280)

WVGA (480×800)

WXGA (768×1280)

identitate proprietar

redare fișiere media

Limbi acceptate pentru utilizare și introducerea datelor: Română, Engleză

5.2. Funcțiile aplicației

Aplicația de gestiunea stocurilor presupune introducerea datelor de acces înainte ca utilizatorul să poată accesa vreo informație în cadrul serviciului. Astfel prima dată acesta va primi un formular ca cel din Figura 5.1.

Figura 5.1. Ecranul de autentificare

Cu o atingere de ecran în locul unuia dintre câmpurile afișate, tastatura virtuală va apărea, iar utilizatorul o poate folosi pentru a introduce datele. Numele de utilizator (username) este același ca cel folosit la autentificarea în cadrul clientului Microsoft Dynamics AX, fiind validat doar sub forma standard impusă, domeniu\nume de utilizator. Parola este cea corespunzătoare contului introdus, la introducerea aceteia câmpul va transforma fiecare caracter în asterisc pentru a nu putea fi descoperită de cei din jur. Următoarele două câmpuri sunt corespunzătoare adreselor serviciilor folosite, fiind necesare deoarece aplicația este concepută ca un instrument universal, iar fiecare utilizator corespunde unei companii în cadrul serviciului căreia dorește să se autentifice, primind aceste date în cadrul organizației proprii, fiind definite de echipa tehnică.

O dată ce au fost validate, în caz de succes utilizatorul este autentificat și poate accesa serviciul de gestiunea stocurilor. În acest moment utilizatorul vede un ecran precum cele din Figura 5.2 sau Figura 5.3. În prima imagine, Figura 5.2, este reprezentată o aplicație legată la un serviciu în cadrul căreia nu există nicio tranzacție activă fiind disponibil doar butonul de adăugare a unei noi tranzacții.

Figura 5.2. Ecranul home fără tranzacții Figura 5.3. Ecranul home cu tranzacții

În Figura 5.3 este ilustrată o aplicație în cadrul serviciului de gestiunea cursurilor la care face referință unde sunt programate un număr mare de tranzacții active. Acestea sunt afișate în ordine cronologică, în funcție de date la care se vor desfășura. Sunt vizibile încă din acest punct, data, punctul de plecare și punctul de livrare ale fiecărei tranzacții. Aplicația oferă în partea de jos a ecranului butonul de Refresh care este folosit pentru a verifica daca au mai apărut noi tranzacții între timp. Selectarea unui element va oferi utilizatorului o listă cu toate tranzacțiile active, ca cea din Figura 5.4, unde pot fi vizualizate toate detaliile fiecărei tranzacții. Data la care se va desfășura tranzacția în detaliu, afișând data săptămânii și data calendaristică. Punctul de plecare este afișat reprezentativ primul, urmat de punctul la care va fi livrat. În partea dreaptă a fiecărei tranzacții este afișată cantitatea transferată. Din acest punct utilizatorului îi este permis să selecteze tranzacția dorită pe care o poate anula apăsând butonul reprezentat de un X din partea de jos a ecranului sau o poate salva ca importantă apăsând simbolul dischetei.

Figura 5.4. Ecranul de administrarea tranzacțiilor

Din Figura 5.2 unde este disponibil butonul de adăugare a unei noi tranzacții se poate ajunge la formularul din Figura 5.5, reprezentând modalitatea de a introduce datele unei noi tranzacții, necesare serviciului de gestiunea stocurilor. În câmpurile disponibile, cu ajutorul tastaturii virtuale utilizatorul va introduce datele necesare creării unei noi tranzacții. Data, cantitatea, punctul de plecare și punctul de livrare sunt câmpuri obligatorii ce necesită introduse date sub forma cerută. Data, trebuie să fie introdusă sub forma standard acceptată a datei, conținând ziua, luna și anul dorite. Cantitatea trebuie introdusă sub formă numerică, fiind acceptat și caracterul punct cu scopul de a desparte întregul de valoarea zecimală. Locația va fi introdusă sub forma unui șir de caractere. Câmpul de comentariu este opțional și acceptă orice fel de format, servind la introducerea datelor adiționale ce au legătură cu tranzacția dorită. La finalizarea introducerii datelor, utilizatorul poate trimite noua tranzacție creată apăsând butonul din partea de jos a ecranului.

Figura 5.5. Ecranul de introducere Figura 5.6. Ecranul de eroare

a unei noi tranzacții

În caz de succes utilizatorul va fi redirectat pe pagina de start a aplicației putându-și vizualiza noua tranzacție creată, aceasta fiind în acest moment prima în listă, lângă butonul de creare a unei alte tranzacții. În caz de eroare utilizatorul va primi un mesaj ca cel afișat în Figura 5.6, rămânând pe pagina actuală pentru a continua de introdus datele necesare sau pentru a le modifica pe cele actuale pentru a fi în concordanță cu cerințele serviciului.

6. EFICIENȚA ȘI UTILITATEA APLICAȚIEI

Organizația trebuie să dețină o licență validă a sistemului ERP Microsoft Dynamics AX. Aceasta poate fi obținută direct de la Microsoft, de la partenerii săi sau prin furnizorii independenți. Licențele valide presupun stabilirea dimensiunii companiei, precum și numărul de angajați înainte de achiziționare. Implementarea soluției poate fi făcută direct de furnizor, prezentat un serviciu, în cele mai multe cazuri recomandat, sau de o echipă tehnică IT, din interiorul companiei dacă au cunoștiințele tehnice necesare sau cu ajutorul unei echipe de programatori independentă ce poate livra acest serviciu.

6.1. Condiții privind implementarea aplicației

Integrarea aplicației se face într-o infrastructură cloud Microsoft Azure, ceea ce presupune achiziționarea acestor servicii prin intermediul Microsoft. În primul rând infrastructura presupune o mașină virtuala de tip A1 cu sistemul de operare Windows Server, la care se atașează un serviciu cloud standard și un spațiu de stocare de 160 GB. Implementarea aplicației Microsoft Dynamics AX se face pe mașina virtuală unde sistemul va fi configurat în concordanță cu nevoile specifice companiei. În plus, pentru soluția impusă tot prin intermediul Microsoft Azure pot fi achiziționate o rețea virtuală și Windows Azure Service Bus. Acestea sunt cerințele minime din punct de vedere de cloud, iar în funcție de creșterea numărului personalului și de cerințele organizației acestea pot fi îmbunătățite. Astfel, din punct de vedere software și hardware mediul este pregătit pentru utilizarea aplicației de gestiunea stocurilor. Pentru organizațiile ce folosesc o soluție Microsoft Dynamics AX găzduită local este necesar transferul aplicației pe cloud.

Utilizatorii necesită o conexiune stabilă la Internet și trebuie să-și instaleze aplicația pe un dispozitiv mobil compatibil cu cerințele hardware și software ale acesteia. Aplicația suportă dispozitivele populare ce utilizează ca sistem de operare Windows Phone 8 sau Windows Phone 8.1.

6.2. Utilitatea curentă a aplicației

Apicația de gestiune stocuri introduce un nou avantaj din punct de vedere al accesului datelor din aplicația Microsoft Dynamics AX a companiei prin intermediul dispozitivului mobil într-un mod sigur. Include accesul utilizatorilor prin introducerea acelorași date de acces ca și cele folosite la autentificarea la serviciul din cadrul aplicației ERP. Astfel configurarea contului se face o singură dată în Dynamics AX, precizându-se datele utilizatorului, un nume de utilizator, o parolă și un rol atașat contului, iar cu ajutorul AD FS toate aceste informații vor fi automat configurate și gata de utilizare în aplicația mobilă.

Din punct de vedere al funcționalitățiilor implementate aplicația actuală curpinde doar operațiile de bază din cadrul serviciului sistemului. Un utilizator autentificat și autorizat să acceseze serviciul poate vizualiza tranzacțiile curente, având informații despre data în care se va desfășura, punctul de plecare al transportului și punctul de livrare, precum și cantitatea trasnportată. Utilizatorul, în funcție de autoritatea permisă de rolul său în cadrul serviciului poate introduce datele unei noi tranzacții sau poate anula o tranzacție actuală. Acestea sunt toate funcționalitățiile prezente și implementate în aplicația actuală. Pentru un utilizator care dorește să facă o modificare rapidă în cadrul serviciului, aplicația servește această necesitate, dar în cazul unui utilizator ce dorește o experiență completă în cadrul aplicației mobile, comparabilă cu serviciul aplicației sistemului ERP, o va considera incompletă.

Astfel, aplicația actuală cuprinde funcționalitățiile principale ale serviciului, asigură integritatea datelor și permite utilizatorului să acceseze, insereze și șterge date în cadrul serviciului într-un mod sigur, utilizând contul predefinit în Microsoft Dynamics AX. Dar aplicația dezvoltată reprezintă doar fundamentul unei aplicații mobile de gestiunea stocurilor, urmând ca în soluția actuală să fie implementate toate caracteristiciile serviciului pentru a deveni o aplicație vaibilă în cadrul companiei și un concurent pe piața Windows Phone.

6.3. Direcții viitoare

Aplicația de gestiune stocuri implementată în acest fel se concentrează mai mult pe livrarea unei soluții sigure ce permite utilizatorului să se conecteze la aplicația Microsoft Dynamics AX într-un mod sigur pentru a păstra integritatea datelor și mai puțin de implementarea diferitelor funcționalități posibile ce pot fi implementate pe client. Astfel aplicația poate fi privită ca un fundament al viitoarelor funcționalități ce pot fi adăugate la clientul actual.

În cadrul serviciului de gestiunea stocurilor implementat în Microsoft Dynamics și legat de clientul mobil se pot integra toate funcționalitățiile disponibile în aplicația nativă. În primul rând afișarea tuturor informațiilor din cadrul serviciului, de la depozite, locația acestora și numărul de produse până la personalul responsabil și detaliile suplimentare ale produselor. În acest fel aplicația devine un portal nelimitat de resurse pentru utilizator oriunde s-ar afla în momentul în care dorește să acceseze informația necesară. În al doilea rând, utilizatorului i se poate permite să interacționeze cu toate aceste informații, putând să modifice, adauge sau șterge date direct de pe dispozitivul mobil, ca apoi informația să fie vizibilă la nivelul întregii organizații. Arhitectura și sistemul conceput pentru simpla aplicație se poate ramifica în câte feluri este nevoie, iar tot acest flux de informație să fie făcut cu siguranța că datele transmise prezintă principalele caracteristici, integritate și securitate.

O altă caracteristică ce poate profita de funcțiile dispozitivului poate fi implementarea serviciului de apel și mesagerie. Într-o direcție este serviciul de notificare pentru ca utilizatorul să fie la curent cu toate modificările făcute în cadrul serviciului chiar dacă nu are o conexiune de Internet activă. În celălalt sens, aplicația poate fi configurată ca datele stocate să poată fi extrase și transmise extern prin mesageria telefonului, astfel utilizând funcțiile de bază ale telefonului ca instrumente în administrarea serviciului.

Pentru a extinde și mai mult utilizarea dispozitivului, aplicația poate fi configurată să acceseze, cu permisiunea utilizatorului, camera foto a mobilului, împreună cu o aplicație ce suportă capturarea imaginii, majoritatea telefoanelor inteligente având preinstalată o astfel de aplicație. Cu ajutorul acesteia se pot scana coduri QR specifice produselor dintr-un depozit sau poate chiar recunoaște codurile de bare deja utilizate. Printr-o astfel de funcționalitate se poate reduce și timpul și costul inventarierii produselor, compania folosindu-se chiar de dispozitivele personalului angajat.

BIBLIOGRAFIE

ANDEREGG, T. : ERP: A-Z Implementer’s Guide For Success, Resource Publishing, USA, 2000 .

KOCH C. : The ABCs of ERP, Senior Editor CIO.com, 2006 .

VOGEL A., KIMBELL I. : mySAP ERP, Wiley Publishing, Inc., Indiana, 2005 .

BRUNELLI M. : ERP top 2007’s IT spending list, News Editor SearchOracle.com, 2006 .

MICROSOFT : Microsoft Dynamics Official Website, 2014: http://www.microsoft.com/en-us/dynamics/default.aspx .

NIST : NIST Cloud Computing Program, 2014: http://www.nist.gov/itl/cloud/ .

MICROSOFT : Inside Microsoft Dynamics AX : Microsoft Press, Redmond, Washington, 2012 .

MICROSOFT MSDN : What's new in Microsoft Dynamics AX, 2014: http://msdn.microsoft.com/en-us/library/aa654810.aspx .

WINDOWS AZURE : Windows Azure Documentation: Get started building cloud applications, 2014: http://azure.microsoft.com/en-us/documentation/ .

WINDOWS BLOGS : Introducing Windows Phone Preview for Developers, 2013: http://blogs.windows.com/windows_phone/b/wpdev/archive/2013/10/14/introducing-windows-phone-preview-for-developers.aspx .

MICROSOFT MSDN : Windows SDK for Windows 8 – Windows Dev Center, 2014: http://msdn.microsoft.com/en-US/windows/desktop/hh852363.aspx#rn .

MICROSOFT MSDN : Windows Phone Marketplace – Content policies, 2014: http://msdn.microsoft.com/en-us/library/windowsphone/develop/hh184842(v=vs.105).aspx .