This is a reposting of an article I originally wrote on my Developing for Dynamics GP blog.
Many times on the newsgroups, I see questions from developers new to Microsoft Dynamics GP along the lines of:
“How can I customize Microsoft Dynamics GP when I don’t have the source code?”
This post discusses the benefits of having access to the Microsoft Dynamics GP source code and explains how it can be used. It also covers how the entire design of Dexterity is such that access to source code is not required to create customisations.
How Dexterity Customisations are Created (Boring Theory Bit)
Dexterity customisations are created by starting with a copy of the Dynamics.dic dictionary from the application folder. This dictionary does not have any source code in it as this is stripped out during the build process. With the Dexterity IDE (Integrated Development Environment), you can add new resources (data types, fields, tables, forms, reports, etc.) and scripts (event scripts, procedures and functions).
You can also modify original forms and reports to create alternate versions. You cannot change any other of the original resources; Dexterity only supports modification to original forms and reports. Once all of your changes are made, you use Dexterity Utilities to extract all your added (3rd party) resources and transfer the modified forms and reports into an extracted dictionary. Then the extracted dictionary is used to create a chunk file (self installing dictionary). The chunk file is normally created with the source code stripped.
Note: Creating alternate forms and reports should be avoided if possible as you can only have one alternate version of a form or report in use for a user and company at any one time. By avoiding alternate forms and reports unless absolutely necessary, the chances of a clash with an alternate resource from another developer is minimised.
So, you ask…
“I now understand how I can add new functionality, but how can I alter existing functionality?”
Dexterity allows the developer to register triggers before and after any script in the original application. Using triggers you can easily extend the functionality of the original code to include the features and functionality added by your code.
To change the behaviour of original code is a little more complex. Unlike an application where you make changes to source code, you cannot just make your alterations to the source. You will need to use before and after triggers to either change parameters to change behaviour, or to undo some the data changes made by the original code and redo the data changes how you want them. This means that it can sometimes be more work to initally create the code to change behaviour than if we did have access to source code.
On the plus side… when it comes to upgrading your application, because you did not change source code, you can just update your changes from the source code repository into the new version of Microsoft Dynamics GP and then test your code. There is no need to do a line by line comparison of source code between the old version, the custom version and the new version. This means that Dexterity customisations (depending on size) can usually be upgraded in a single day.
Do I need Source Code?
A developer does not need source code. There are a number of techniques for identifying what code is run when you perform actions in the application. You can obtain logs using the methods described in the Knowledge Base (KB) article below or by using the Support Debugging Tool, and then identify where your triggers should be registered.
How to obtain the parameter lists for the trigger registration is explained in the recent posts showing methods of identifying parameters for procedures, functions and reports:
So while I believe that source code is not required, I also know from experience that access to source code can speed up the development cycle and make it easier to create very tight integrations. With source code you will be able to:
Trace the code using the debugger.
Quickly find the scripts which are performing the actions you need to trigger against.
Easily identify function and procedure parameters.
Be able to see how the original code achieves what it does.
When I first started with Dexterity I did not have access to source code and worked without source code for many years. I wrote Named Printers which triggered on almost every report in the system without source code. As you cannot actually trigger on the report, Named Printers had to trigger on the script that contain the run report command.
Having access to source code though should not change how you write code. The source code is to be used only as a reference. You should not cut and paste entire scripts to replace an original script and then edit it to make your changes. This method (while it can work) is extremely bad practice and will prevent the easy upgrade process mentioned earlier. It is also in breach of the source code license agreement.
Note: A Visual Studio Tools for Microsoft Dynamics GP developer will also benefit from having Dexterity knowledge and access to source code.
How do I get Source Code?
To gain access to the source code you must be a Microsoft partner and you must join the Source Code Program. There are fees involved, but the program is much less expensive than it was a few years ago.
[Edit: Links no longer work]
If you have any questions, email firstname.lastname@example.org.
09-Feb-2010: Added link for APAC Source Code Program and announcement post.
This article was originally posted on the Developing for Dynamics GP Blog and has been reposted on http://www.winthropdc.com/blog.