Where are Dynamics GP's Business Rules Defined and Enforced?

In a recent forum post, the question of where the business logic for Dynamics GP resides was raised.  This is an excellent question which, sadly, does not have a simple answer.

When Great Plains Dynamics was first developed for the Ctree and Btrieve ISAM (flat file) databases, there was little demand for external integration.  The only way to get data into the application was via the user interface and the only way to get data out was via the built in Report Writer.

The Dexterity environment was revolutionary (at the time) with its multi-platform, multi-database, translatable object based development.  To provide instant handling of business logic during the data entry process, all the rules and validations were written into the user interface.  As the databases being used did not support referential integrity, all the table relationships were also handled in the Dexterity code.  Most of the core application was developed in this style.

The Purchase Order Processing and Bill of Materials modules have been developed using a different style to the other core modules.  These modules were written using a pseudo object oriented method where the business logic was moved into scripts contained a windowless "object" form.  This did separate the business logic from the user interface and allow the same business logic code to be re-used from more than one location and be maintained in a single place. 

This worked better for the initial development and maintenance of that development, but can make it harder for ISV developers to work with these modules. This object style of development usually breaks down the code into smaller scripts (implemented as form level procedures and functions) which can then be re-used more easily.  While this does provide more integration points to trigger against, the same code can be called from many locations and a developer might only want to work with the one location they are customising.  This is when methods like the Three Trigger Technique become very handy.

Even with this newer "object" style of development, the business logic and referential integrity is still inside Dexterity and not available from outside Dexterity.

Initially, the only integration method available was a direct table import which has no checking of business logic and could easily create corrupt data. To make integrations simpler The Taylor Group created the Dynamics Integration Manager (DIM) tool, which could be used to map the fields from source data to target data. Originally, it still used direct table access, but after it was purchased by Great Plains (and renamed to Integration Manager) it was rewritten for v5.0 to enter data through the user interface and so execute the business logic and validation rules. It was not as fast as direct table access, but it obeyed the business rules (including custom rules added to the forms using Dexterity triggers or Visual Basic for Applications).

When Microsoft SQL Server was introduced as a database platform, some of the business logic for processor intensive tasks like posting and reporting was moved into SQL stored procedures. The stored procedures often did not contain the entire process, it still needs the Dexterity code wrapper before and after it to complete the task.  This means that the stored procedures could not be called directly from SQL.

The addition of eConnect as an integration tool provided SQL stored procedures which contained business logic based on the Dexterity code from the application.  However, the eConnect business logic is usually a subset of functionality available via the user interface and so cannot be directly compared.  Some features that require user interaction or are not likely to be needed for integrated transactions might not have been implemented. The eConnect stored procedures can be called by a variety of methods and are also re-used by the Web Services.

So at this stage the answer is that there is no single, externally accessible location for the business logic and rules for Microsoft Dynamics GP.

For more information on the way that Microsoft Dynamics GP works with the history that explains why have a look at these posts:

Understanding how Microsoft Dynamics GP works with Microsoft SQL Server 

Understanding how Microsoft Dynamics GP works with Microsoft SQL Server continued

Let me know if this information was helpful.

David