Automating Distribution of Customizations Part 1


David Meego - Click for blog homepageThis 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.

18 thoughts on “Automating Distribution of Customizations Part 1

  1. Dave,
    Nice post. It left me with a couple of thoughts.
    In scenario 1 wouldn’t it be that SOME updates require touching the box now that GP has update capability for service packs and hot fixes?
    In scenario 4 one of the risks is customizing reports after the fact. In this case, a previously local dictionary now needs to be shared because one report has been customized. Now every box needs to be touched (via hand or script) to update the locations.
    All of these scenarios assume that everyone needs the same customizations. In a scenario that requires 6 custom invoice formats, some folks may have a different custom reports dictionary since there are only 4 custom invoice formats by default. The scenarios still work but it takes some coordination to get it all right.
    Personally I’m seeing a shift from scenario 5 to scenario 4 in the field. It’s been a while since I’ve seen corruption to the reports and forms dictionaries and I think that this has made everyone bolder.
    Mark

    Like

Please post feedback or comments

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

This site uses Akismet to reduce spam. Learn how your comment data is processed.