Hybrid development for the Managed Code developer

A few weeks aback, I co-presented a deep dive session with my partner in crime, David Musgrave, at Microsoft Dynamics Convergence Atlanta 2011 DDGP03 Microsoft Dynamics GP Customization & Integration Tools Review - see Microsoft Dynamics Convergence Atlanta 2011: Day 3 for more on what happened that day.

During our session, we introduce a Visual Studio Tools sample that left a few managed code developers scratching their heads - a bit. The sample in question used Modifier, Dexterity, and Visual Studio Tools to provide a customization to the Vendor Maintenance window. So let's break down the customization.

The Modifier bit

One of the limitations of Visual Studio Tools is that it cannot modify existing Microsoft Dynamics GP windows to incorporate new controls. In addition, if this particular window, the Vendor Maintenance window, was a third party dictionary resource, frankly, Dexterity won't be the tool to modify the window either - Dexterity cannot modify third party dictionary resources.

In addition, sometimes the user requirements need the customization to be implemented on the same window where they conduct most of their work on, understandabily so, as this simplifies the navigation process. 

Vendor Maintenance with customizations

The only way to bridge the gap between the aforementioned tools limitations and the user requirements is to use the Modifier tool. Modifier will allow a developer to deliver the controls needed by the user within the desired window. In turn, by using Modifier, we are ensuring that the changes can be displayed to the user on an "as needed" basis through the implementation of standard Microsoft Dynamics GP security.

However, by adding the controls to the window, the information selected by the user still has nowhere (yet) to be stored.


The Dexterity bit

By using Dexterity, we can implement the table metadata information that will allow the data selected by the user from the newly added controls to be stored. This will require a brand new Dexterity dictionary to be created.

If you are a Visual Studio developer you may still be asking, why can't I implement the table and storage mechanism in SQL directly. The answer? Of course you can! However, by using Dexterity, you are able to expose your table to Microsoft Dynamics GP security model as well as simplifying the calls by using standard range methods in Visual Studio Tools.

In addition, if you need to make special calls to existing Microsoft Dynamics GP programatic objects (functions, procedures, etc.) which may require you to create wrappers, you can do so from Dexterity and perform the calls from Visual Studio Tools.

xmpVendorMaster table definition

On a more mundane note, Dexterity will create the table auto procedures and automatically add the DEX_ROW_ID identity column that will allow the runtime engine to control row level locking for you. By implementing your table in Dexterity, you are also providing a failsafe mechanism against deploying incorrect table structures or a different version of the table. If you are familiar with Microsoft Dynamics GP, you will know that the SQL Server tables must strictly match the metadata definition stored in the dictionary.

However, we still don't have a glue for the UI changes and table storage and retrieval - commonly known as CRUD operations.

The Visual Studio Tools bit
Because the UI does not know of the table or the table of the UI, you must now implement the Visual Studio Tools portion to attain the final pieces. But first, you must do a few things...
 
In order to expose the controls added with Modifier to your Visual Studio Tools project, you must create an assembly for the modified window. In order to do so, you must use the Dictionary Assembly Generator tool (DAG.EXE).
 
In addition, exposing the table you created in Dexterity will also require you to DAG your Dexterity dictionary. Once you have generated both assemblies, you can then reference them in your Visual Studio project.

Solution Explorer

Once you have the code necessary to drive the interface and store the data, you can then build your assembly. The overall architecture of this solution is as follow:
 

Customization Architecture

 
You can download the code for this sample by visiting the Convergence Atlanta 2011 materials post below:
 
Microsoft Dynamics Convergence Atlanta 2011: Presentation Materials

Tomorrow I will talk about how to deploy this solution.

Until next post!

MG.-
Mariano Gomez, MVP
IntellPartners, LLC
http://www.IntellPartners.com/