Microsoft Dynamics GP "12" Web Client Architecture - Part 2
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.
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!
MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
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 |
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!
MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/
Comments