Microsoft Dynamics GP "12" Architecture: Correction!

June 6, 2011

In past days I released an article explaining the upcoming Named Systems Database architecture enhancement in codename GP “12” release. However, this article was incorrectly released under the title Microsoft Dynamics GP “12” Multi-tenancy Architecture. The article’s title, content, and graphics have been corrected since and re-released under the title Microsoft Dynamics GP “12” Named System Database Architecture under my Community site column, IMHO with The Dynamics GP Blogster.

For your convenience, the link remains the same and your bookmarks should continue to work. To compensate for this mishap, I have also included additional information on the Named System Database feature and the problems it’s trying to solve.

The Multitenacy Architecture concept is still very much alive and I will pick this up in an upcoming article. Please stay tune as you will sure like this one!

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC


Microsoft Dynamics GP "12" Named System Database Architecture

May 23, 2011

I received a lot of feedback from the community as a whole on the 3-part series of articles on Microsoft Dynamics GP “12” Web Client Architecture and I was pleased to know that many of you are embracing the fact that there will be a Web client version of the product and are asking numerous questions about readiness.

While these articles addressed the client portion of the solution, I really did not mention anything about changes in the database architecture and how these will impact the future deployment options. So, I have released a new architecture article on Microsoft Dynamics Community, this time addressing Microsoft Dynamics GP “12” Named System Database Architecture.

In this article I look at the named system database capabilities to be released in GP “12”. This is, the ability to set any name to the traditional, hardcoded DYNAMICS database. Hope you enjoy the article and if you have any comments or questions please feel free to post back.

For convenience sake, I will be adding a new link to the architecture series.

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC


06/06/2011 – Changed article title to fit instructions provided by Microsoft Escalation team and current developments out of Fargo.

Microsoft Dynamics GP "12" Web Client Architecture – Part 3

May 16, 2011

This is article 3 of 3 from the series Microsoft Dynamics GP “12” Web Client Architecture. Some images and content reproduced with express permission from Microsoft Business Solutions, a division of Microsoft Corporation.

In Part 2 we explored the Microsoft Dynamics GP “12” Web Client’s Rendering Engine and how it had to be decoupled from the overall Dexterity Runtime Engine functions, in order to create a Generic Window Object that could be rendered as a Windows Form or a Silverlight interface.

Today this article discusses how a Generic Window Object is transformed into a Windows form or a Silverlight UI, but before, let’s remember that the Window Manager, a former part of the Dexterity Runtime Engine, is still in charge of processing the UI events while  the Rendering Engine presents the interface to the end-user.

Dynamic Form Rendering with Template Processor

Now that the Dexterity Runtime Engine has been freed of these tasks, the resulting Generic Window Object must be processed to produce either interfaces. For this, the Development team has created Template Processor.

Template Processor takes a generic representation of a window and is able to deliver an XML version of its content (fields, buttons, and events in the case of a traditional Dexterity window), called a Window Template, but as well delivers a version that the Dexterity Runtime Engine can still display in the classical client, also known as coreTemplate. The technique of processing a Generic Window Object into an XML Window Tempalte and a coreTemplate has been labeled Dynamics Form Rendering.

The XML Window Template is then delivered to Silverlight via a browser application – explicitly Internet Explorer given the use of Silverlight – where the Rendering Engine uses a Converter to serialize into a Silverlight UI. Since the Dexterity Runtime Engine retains the ability to understand the coreTemplate elements, displaying a Windows form is still a natural function.

Dynamic Form Rendering – Developer’s Experience

The result will still allow developers to create traditional Dexterity customizations against the classic client UI or the XML Window Template generated by the Template Processor.

On a closing note, GP “12” aims to provide additional deployment methods to the traditional classical client deployment, where the client is either delivered as an installation at desktop level or in a Terminal Server or Citrix environment. With the Silverlight client, users can rely on their Internet Explorer browser and the Silverlight plug-in to run their Microsoft Dynamics GP application, while retaining the feature rich functionality of the classical client.

To make things even more interesting, a deployment environment can take advantage of both the classical client and the Silverlight client at the same time. Why would you need both? I suspect certain application functions like maintenance are best executed from the classical client, however in the scheme of things, it allows for a smooth end-user transition.

Finally, I hope you enjoyed this series of articles and I will continue to work with the Microsoft Dynamics GP Product Management team to deliver information to you as it becomes available (and needless to say, not deemed a trade secret). There is more to all this than meet the eyes.

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC

Microsoft Dynamics GP "12" Web Client Architecture – Part 2

May 11, 2011

This is article 2 of 3 from the series Microsoft Dynamics GP “12” Web Client Architecture. Some images and content reproduced with express permission from Microsoft Business Solutions, a division of Microsoft Corporation.

In Part 1 of this series I went through the architecture transition from the classic client (the traditional Microsoft Dexterity interface and its evolution) to the Microsoft Dynamics GP “12” Web Client and introduced some elements of that architecture (Silverlight, .NET C#, and .NET Runtime) and how these elements fall into the “Built to Last” philosophy outlined in the overall Architectural Foundation.

Today, this article will continue down the lines outlining some of the technology challenges posed by the introduction of the Web Client and the highlighting some of the radical changes (from a development perspective) needed at the core of Microsoft Dexterity and Microsoft Dynamics GP to enable the Microsoft Silverlight interface.

The Rendering Engine

If you are a Microsoft Dexterity developer, you are already in tune with the purpose of forms (windows in the general sense) as an essential part of any Microsoft Dexterity application or integrating solution. After all, there are a key mechanism by which a user will interact with the Microsoft Dynamics GP system.

As such, a Microsoft Dexterity window typically includes sanScript code associated to the controls on that window. This code executes in response to events given the intended function of the window and the controls, i.e., save a transaction, post a batch, etc., under the direction of the Script Interpreter.

Note: The process of chunking a dictionary typically involves the removal of source code for shipping of the dictionary. Hence the need for the Script Interpreter as an integral component of the Runtime Engine.

Under the hood though, the user interface is administered by the Window Manager, which in turn talks to the Rendering Engine to display the actual Microsoft Dexterity window on the screen with the control elements previously laid out by the developer.

Web Client Architecture

The tight bond between UI and code has served well up to now, but it hasn’t been without its drawbacks. One of the biggest complaints registered by developers and users alike is the fact that too much of the Microsoft Dynamics GP code resides within the user interface and the confines of the dictionary which makes for a heavy client – nonetheless, fitting the traditional client/server application architecture.

To facilitate the transition to the Web Client, the Window Manager and Rendering Engine have been decoupled from the functions of the Runtime Engine, allowing the Microsoft Dexterity Runtime Engine to produce a Generic Window Object instead. With a generic window, a classic client can continue to serve up the typical Win32 forms all the while allowing a Silverlight client to serve up a web based representation of that form. Decoupling the Window Manager and Rendering Engine allows for forms to move freely between the Win32 and Web worlds with the help of another key piece of technology – more on this in the next installment.

With the Window Manager and Rendering Engine decoupled, you can now conclude that a Microsoft Dexterity application can run as a service in the background, awaiting for events that would be either received via a traditional Win32 form or a Silverlight client, and STILL be able to execute script events regardless of the type of form they were submitted through. The theory also would indicate that a Microsoft Dexterity application is the basis for a Web Client version of itself. This is, a Microsoft Dexterity applications can leverage the new architecture elements to become web enabled – but not the other way around (yet!).

But how is the classic UI transformed into a web version? In the next and final installment, I will dig a bit more into the patent worthy elements of the architecture: Template Processor and Dynamic Window Rendering.

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC

Microsoft Dynamics GP "12" Web Client Architecture – Part 1

May 9, 2011

This is article 1 of 3 from the series Microsoft Dynamics GP “12” Web Client Architecture. Some images and content reproduced with express permission from Microsoft Business Solutions, a division of Microsoft Corporation.

In past weeks I mentioned expanding a bit more on the Web Client to be introduced with codename GP “12”.

Web Client Overview

The Web Client is the full GP application delivered through the Web. The key pieces to be delivered will be the core application components, ISV dictionaries, and in-house customizations – Dexterity customizations. At the core of the web client is the UI update which will feature new homepage tiles, ribbons and tabs. Microsoft expects that UI performance will rival that of Terminal Server or better.

Client/Server Architecture Transition

Historically, the Microsoft Dynamics GP application has followed a 2-tier client/server architecture, which divides the application functions into two distinct, but very interrelated components: the database server and the client application.

The database server, which relies on Microsoft SQL Server, hosts the system and company data, along with extended business logic that allows it to process some of the heavier operations that would be extremely time consuming to perform at the client, for example, transaction posting business logic.

In turn, the Microsoft Dynamics GP client application, built on Microsoft Dexterity, has always performed the functions of delivering the user interface, providing data entry validation, and rendering reports – ok, so it does a bit more at times, but in context these are the key functions.

Transition from current Client/Server architecture to the Web Client architecture

A Microsoft Dexterity application is divided into two distinct elements: 1) a Runtime Engine that deals with the technology aspects of the application environment, like communicating to the operating system and establishing and managing the connection to the databases, and 2) a dictionary which hosts all the core application components and business logic, such as the forms, reports, and the sanScript code that makes the entire user interface and reports do something in response to user commands and input.

This architecture has been time tested and has served its purpose even after numerous technology changes over the years. In fact, application users have seen no disruption to the application functionality due to technology changes. The same could be said for changes in functionality- see Microsoft Dynamics GP Architectural Foundation Series with Tim Brookins for a primer on GP’s architecture.

The Web Client, built on Microsoft Silverlight delivers a set of components and services oriented toward the UI and user interaction, including user input, lightweight UI controls for use in Web applications (some other Silverlight features that probably won’t be a part of the Web Client include media playback, digital rights management, data binding, and presentation features, including vector graphics, text, animation, and images). Also Silverlight includes the Extensible Application Markup Language (XAML) for specifying layout which is heavily used by the Web Client.

The Silverlight Web Client application uses a subset of the .NET Framework that contains components and libraries, including data integration, extensible Windows controls, networking, base class libraries, garbage collection, and the common language runtime (CLR). The development language of choice, of course, is C#.

Some parts of the .NET Framework for Silverlight are deployed with the Web Client application. These “Silverlight Libraries” are assemblies not included in the Silverlight runtime and are instead shipped in the Silverlight SDK. The Silverlight Libraries used by the Web Client, are packaged up with the application and downloaded to the browser from the Server. These include new UI controls, XLINQ, Syndication (RSS/Atom), XML serialization, and the dynamic language runtime (DLR). Perhaps, not all these elements will make it to the initial release of the Web Client, but will gradually make their way in the future.

For more on Silverlight architecture click here.

Tomorrow, I will cover in more detail some of the changes required in the current architecture (from a technology stand point) to be able to serve up the Silverlight UI.

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC

Microsoft Dynamics GP "12" Web Client Architecture Series

May 9, 2011

You’ve got a peek at the past Microsoft Dynamics GP Technical Conference, you saw it at Microsoft Dynamics Convergence Atlanta 2011. But do you really understand what goes on “under the hood”. If you are intreagued by the upcoming codename GP “12”, today I begin a series of articles oriented to shed some light on the new application architecture. Get a review of the web client and the transition from the classic client to the new architecture environment, understand what changes went into rendering the Silverlight interface, how UI templates work and future deployment options, get an introduction to Dynamic Form Rendering and why this technology is so cool.

The publishing schedule for these articles are as follows:

Published Date Featured Article
05/09/2011 Microsoft Dynamics GP “12” Web Client Architecture – Part 1
05/11/2011 Microsoft Dynamics GP “12” Web Client Architecture – Part 2
05/16/2011 Microsoft Dynamics GP “12” Web Client Architecture – Part 3
05/23/2011 Microsoft Dynamics GP “12” Named System Database Architecture 

Disclaimer: Some images and content reproduced with express permission from Microsoft Business Solutions, a division of Microsoft Corporation. The content of these articles should not be reproduced without permission from this author.

Until next post!

Mariano Gomez, MVP
IntellPartners, LLC

05/23/2011 – Added link to Named System Database Architecture article on Dynamics Community.