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.
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.
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.
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:
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/
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 |
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 |
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 |
 |
| 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/
Comments
I have been doing this for a while and I am not sure I have had to use any "tricks". My system is also a 64-bit system and I can't say I have experienced the same issues.
My question is, however, are you even able to see any modified object in the form? Also, are you adding the namespace to your VST project once you reference the assembly? The namespace is as follows:
using Microsoft.Dexterity.Applications.DynamicsModifiedDictionary;
MG.-
Mariano Gomez, MVP
This is a very informative post. Thanks!
I do have a question though. I'm assuming you're familiar with Workflows for Dynamic GP. If a certain window (let's say the SOP Entry window) has a workflow enabled, there would be "ribbon" that would be visible on top of the form. Would you know how I would be able to access that "ribbon"? Thanks!
Regards,
Ric
Thanks,
Darren