Automating Distribution of Customizations Part 1

This is a reposting of an article I originally wrote on my Developing for Dynamics GP blog.

A long time discussion in the Microsoft Dynamics GP world is how to handle the distribution of customizations and updates. There are a number of approaches available and this article discusses the benefits and issues of the different configurations.

The Microsoft Dynamics GP client application is made up of a number of components. The main components are listed below (Note: Not all versions will have all of the components listed):

• The Dexterity Runtime engine, which includes Dynamics.exe, Dex.dic and the *.dll and *.tlb files.
• The Dexterity Shared Components installed into the path C:Program FilesCommon FilesMicrosoft SharedDexterity.
• The settings file, which is the Dex.ini file.
• The launch file, which is the Dynamics.set file. It contains a list of the installed products and the paths to locate the application dictionaries and custom forms and reports dictionaries for each product.
• The application dictionaries, which include Dynamics.dic, Exp1493.dic, XLBudget.dic, AdvSecur.dic, etc.
• The custom forms and reports dictionaries, which include Forms.dic, Reports.dic, etc.
• The Visual Basic for Applications files, which have the same name as the application dictionaries with the .vba extension.
• The Help files (*.chm) and manuals in the documentation folder (*.pdf).
• The Visual Studio Tools assembly object files, these are the Application.*.dll files.
• The Visual Studio Tools add-in applications in the AddIns folder.
• The Homepage files in the Background folder.
• The SQL objects used by Dynamics Utilities in the SQL folder

Below is a list of the common configurations used with workstations.

Configuration 1: Everything local

In this environment all of the client components are local to the workstation.

Benefits: This gives the best performance and stability.

Issues: Updates require a visit to each workstation.

Configuration 2: Everything shared

In this environment all of the client components are installed into a shared network location.

Benefits: A single client install makes updates simple. Changes made to customizations are immediately available to all users.

Issues: Performance will suffer and high network traffic as all files must be loaded from the shared location. There is a risk of corruption to custom forms and reports dictionaries if making changes to forms and reports while they are being used. Mistakes made to customizations are immediately available to all users.

Configuration 3: Dictionaries shared

In this environment most of the client components are local with only the application and custom forms and reports dictionaries being shared.

Benefits: The performance is a little better than the previous configuration. Updates to custom forms and reports are simple. Changes made to custom forms and reports are immediately available to all users.

Issues: Performance will still suffer as the application dictionaries are large and so network traffic will be unnecessarily generated. There is a risk of corruption to custom forms and reports dictionaries if making changes to forms and reports while they are being used. Mistakes made to custom forms and reports are immediately available to all users.  VBA and Visual Studio Addins still need to be updated manually as they must reside with the runtime components.

Configuration 4: Custom Dictionaries shared

In this environment most of the client components are local with only the custom forms and reports dictionaries being shared.  This is the most common configuration.

Benefits: The performance is better than the previous configuration. Updates to custom forms and reports are simple. Changes made to custom forms and reports are immediately available to all users.

Issues: Performance will still suffer a bit as base resources from the application dictionaries will be read from the custom forms and reports dictionaries if they exist. There is a risk of corruption to custom forms and reports dictionaries if making changes to forms and reports while they are being used. Mistakes made to custom forms and reports are immediately available to all users.  VBA and Visual Studio Addins still need to be updated manually as they must reside with the runtime components.

Configuration 5: Everything local with automatic updates

In this environment all of the client components are stored locally, but a script is used to update the client files from a central update share when the workstation logs in.  You can also run this script manually from a batch file if desired.  This is my preferred configuration.

Benefits: Best performance and stability, and less network traffic because everything is local. Reduced chances of corruption the custom dictionaries. Changes to customizations can be fully tested before being deployed. Never being locked out of report writer or modifier because others users are in the system.

Issues: None

Note: Configuration 5 can also be used for a Terminal Server environment.  While it is not possible to run the update script on login, it can be run manually from a batch file once all users have exited the application.

So you ask… How can I implement Configuration 5?

Part 2 of this posting can be found at the link below:

Automating Distribution of Customizations Part 2

Please post comments with your thoughts on the different approaches.

David

This article was originally posted on the Developing for Dynamics GP Blog and has been reposted on http://www.winthropdc.com/blog.