Microsoft Dynamics GP Development Environment Overview

The Dynamics GP product platform is modeled to allow robust application customizations to be created in order to meet the unique needs of the installed company base.  Since Dynamics GP is, for the most part, an interpreted language that references resources dynamically via dictionary files, it is a relatively simple process to augment the core functionality of the application.  To that end, there are several tools available to the Dynamics GP developer, ranging from the simplest to the most complex, which allow the Dynamics GP system to be extended to meet the unique needs of its users.  An important concept to remember is that the highest order of functionality is afforded with the most complex tool, but even the simplest tool can have a powerful impact on the Dynamics GP user experience.  The development options are listed belo , in order of increasing complexity:

• Modifier with VBA.  These technologies are mature within the Dynamics product space and represent a relatively simple manner of extending the Dynamics GP system according to clients’ business needs.  The Modifier product allows new fields to be added to the system while Visual Basic for Applications, a core feature of Microsoft Office, allows new windows and data storage to be available to the Dynamics GP system via user forms.  These technologies do not, however, allow for application triggers, which are basically a mechanism to tell a third-party add-on to perform some action at the conclusion of another process.  As a customization solution, though, Modifier with VBA allows the core data capture functionality of Dynamics GP to be extended using a subset of Visual Basic 6.0.  Security can be granted or revoked to the modified resources using the standard Dynamics GP security model and the DUOS object model can be utilized for data storage.  As an alternative, external tables (or any other data storage medium) can be used.  However, any external Microsoft SQL Server objects that are created are outside the security model of GP and must be explicitly granted the DYNGRP SQL permissions.
• Continuum.  This is an older COM technology that has been discontinued but can still be used to extend the functionality of Dynamics GP using Visual Basic 6.0 or any of the CLR languages.  Like Modifier, new windows can be added but, unlike Modifier, existing windows cannot be altered.  However, Continuum does allow for application triggers so that a pseudo-workflow can be developed.  (Note that Continuum is no longer supported but previous versions of the COM objects can be found and utilized to interface with current versions of Dynamics GP.)
• Dynamics GP Toolkit for Visual Studio.  These assemblies are the next-generation replacement for Continuum and allow the Dynamics GP system to be extended by using the .NET development environment.  New windows with the same look-and-feel of the core Dynamics GP system can be created and application triggers can be coded to augment the existing functionality.  This technology cannot, however, modify existing windows or reports and the resources in this solution live outside the Dynamics GP security model.  Additionally, any new data storage will exist outside the standard Dynamics GP table universe, which means that the SQL permissions must be explicitly granted to the Dynamics GP users in the form of a manual or automatic setup routine.  Note also that the Developer’s Toolkit contains Web services and the eConnect API to allow external applications to interface with Dynamics GP without tapping into the Dynamics GP user experience.  The Dexterity runtime is written using .NET technologies so the contract concepts should be familiar to any .NET developer.
• Dexterity.  This is the most complex and powerful customization available to Dynamics GP developers.  With that power, however, comes a greater chance for errors since the sanScript language does not take advantage of the IntelliSense built into the Visual Studio IDE.  The core Dynamics GP system is built using Dexterity so every feature in the system, from modified resources to application triggers, to a complete overhaul of the visual experience, is available to the GP developer.  There is a significant learning curve, though, since sanSancript is a C-like scripting language—actually, it is closer to C++ without the object-oriented concepts--that is interpreted by the Dexterity runtime.  To use Dexterity, a developer needs to know the transaction flows and function parameters passed to each routine within the Dynamics GP environment in order to properly interface with the system.  Any tables created within Dexterity will automatically have the optimization stored procedures added and will inherit the DYNGRP SQL permissions, though, so data storage is seamless to the end user.  The core Dynamics GP application dictionary (DYNAMICS.DIC) itself is written using Dexterity.
  

The table below summarizes the capabilities and limitations of each development tool available in Dynamics GP.

By William Schroeder, Practice Manager, at your Chicago Microsoft Dynamics Great Plains Partner, Crestwood Associates.