‘De top 3 van verbeteringen in het applicatiebeheer van AX2012, zou je die mij kunnen geven?’ vroeg onlangs een collega. Toen ik over deze vraag nadacht betrapte ik me erop dat deze lijst wel te geven is, maar dat dit niet allemaal de punten zijn waar ik direct na de release van AX2012 aan gedacht zou hebben, als mij toen dezelfde vraag was gesteld.
Maar nu, vele trainingen en cursisten verder, heeft een top 3 voor mij steeds vastere vormen gekregen. Ik noem ze in een willekeurige volgorde:
1. Autorisatiebeheer
Het autorisatiebeheer heeft in Dynamics AX2012 een zeer ingrijpende wijziging ondergaan. Er is m.i. een grote stap voorwaarts gezet met de introductie van een getrapt model. Daarbij worden drie verschillende niveaus onderscheiden. Op het hoogste niveau bevinden zich de ‘rollen’. Een rol omvat een bundel van taken en elke taak omvat vervolgens een bundel van privileges. Onder de privileges vallen de menu items. Hoewel het pakket een standaard set van 81 rollen met taken en privileges meelevert blijkt in de praktijk dat bedrijven daarmee niet altijd uit de voeten kunnen. Op zich is dat geen probleem. In elk van de drie lagen kunnen aanpassingen worden uitgevoerd. Desnoods kunnen de rollen helemaal opnieuw worden opgebouwd.
De grote verbetering zit hem hierin dat op dit moment na het aanklikken van een menu entry geen foutmelding meer verschijnt omdat er nog rechten worden gemist voor bijvoorbeeld een specifieke tabel. De afhandeling van privileges, taken en rollen bevindt zich nu in de software en niet meer in de data. Overigens betekent dit voor software ontwikkelaars dat ze hiermee, veel meer dan in voorgaande versies, een taak hebben in het autorisatiebeheer.
De autorisatie structuur in AX2009 moet tijdens de implementatie van de software vanaf nul worden opgebouwd. Er wordt gewerkt met groepen. Dat geeft in de praktijk altijd veel gedoe met de inrichting van de autorisaties: foutmeldingen m.b.t. tabellen die niet zijn toegekend aan de groep omdat die, onzichtbaar voor de beheerder, door de code worden benaderd. Eigenlijk vreemd, inrichten van de autorisatiestructuur is toch een taak van de beheerder.
2. Gebruikersbeheer
AX2009 kent alleen domain gebruikers. Wil je toegang krijgen tot de applicatie dan moet je toegevoegd worden in de Active Directory. Dat wil je niet altijd voor gebruikers die geen deel uitmaken van de organisatie, zoals klanten, leveranciers of extern ingehuurde medewerkers die uren moeten verantwoorden. In AX2012 kunnen ook externen toegang krijgen tot de applicatie via de Enterprise Portal. Stel dat je een medewerker uit de organisatie van de klant toegang wilt geven tot de applicatie. Die medewerker is bekend in de Active Directory van de klant. Hij kan nu middels de Enterprise Portal toegang krijgen tot AX2012. De toegang wordt hierbij gevalideerd door de Active Directory van de klant. Hij krijgt dan alleen de gegevens te zien die voor hem van belang zijn, orders, ed. Alle andere gegevens zijn dan voor hem afgesloten.
3. AX2012 code in de database
In alle voorgaande versies staat de code in aparte bestanden op de object server. Let wel, vaak op elke object server. Dat betekent dat de code in geval van meerdere object servers dan ook meerdere keren is opgeslagen. Dat levert in de praktijk nogal eens een synchronisatieprobleem op: de benodigde code staat niet op elke server.
In AX2012 is dit probleem gelukkig opgelost: de code van AX2012 zit ook in de database. In R1 nog weliswaar gecombineerd met de data, maar in R2 volledig gescheiden van de data in een aparte database. Het gevolg? Minder synchronisatieproblemen en meer eenvoud in het ‘backuppen’ en ‘restoren’ van software en data.
Image courtesy of stockimages / FreeDigitalPhotos.net
