By Brandon Taylor

Last year, when Serenic made the decision to join the Microsoft Dynamics NAV 6.0 SP1 TAP (technology adoption program), there was that brief moment of, what have we done? As an embedded solution, Serenic Navigator is roughly 30% larger than base Dynamics NAV.  That translates into a lot of work, and we were aware that there was a lot that we didn’t know when entering the program.

As discussed in my last posting, there ended up being three primary areas that we really needed to understand: menus for the role-tailored client, roles and activities, and pages.

Let’s break these down.

Before jumping right in, I would like to apologize as the following contains development rated material – screenshots of the NAV object designer.  So, if you haven’t had the luxury of spending much time in the NAV development environment, this is where programmers spend the majority of their time.

It turns out that menus for the role-tailored client are modeled in the exact same way as the classic menus.  The only difference is that instead of having an object number of 52, they start in the thousands, i.e. 1055.  During the transformation cycle we had a non-developer update these.  That should give you an indication of how we started to feel—piece of cake !

Next up, we needed to understand the most important framework of the role-tailored client – roles and activities.  These are the basis for the whole “Role-Tailored Experience,” so it was critical that we shipped product with roles that were relevant for the NonProfit/NGO/Public Sector market.  As with menus, Microsoft’s implementation of roles and activities fit within the NAV architecture by utilizing the new page object.  Both the role and activities each require one page.  Below are the roles and activities we shipped with Navigator 6.0.

Finally, now that we understood menus to be an extension of the classic model along with roles and activities that are really just pages, the only new thing we needed to learn were pages.  Below is a partial shot of the Fund Card page object.  If you have ever looked at XML code from a web page you will see some similarities in the layout.  In fact, the page object gets compiled into managed C# code on the service tier.

Below is how the role-tailored client renders and presents the page to the user.

All in all, it took a couple of weeks for it to become clear on what we needed to do.  It then became an exercise based on the volume of work rather than the technical unknown (although there were the typical technical hurdles associated with any early adopter program).

Hopefully, this provides a little more clarity to what’s under the hood related to the role-tailored client.  It really comes down to a new object type called a page.  As is usually the case, Microsoft has done all of the heavy lifting and we now get to build and deliver some pretty cool stuff.  But, that’s for next time…