Free Articles, Free Web Content, Reprint Articles
Thursday, May 23, 2019
 
Free Articles, Free Web Content, Reprint ArticlesRegisterAll CategoriesTop AuthorsSubmit Article (Article Submission)ContactSubscribe Free Articles, Free Web Content, Reprint Articles
 

Dynamics GP Dexterity Custom Software Programming Notes

Microsoft Dynamics GP, or how it was known in the past – Great Plains Dynamics has several customization tools, including Great Plains Dexterity.

This is in essence GP architecture, specially created in earlier 1990th to provide Great Plains Dynamics ERP product some level of neutrality – from those days computer platforms (such as MS Windows, Mac OS, Solaris, Unix to be examples) and database vendors (Oracle, Btrieve, earlier Microsoft SQL Server to name a few).  Neutrality and its reasonable performance those days was typically achieved by programming so-called Shell in one of the cross-platforms programming languages (in the case of Dexterity it was C).  Modern GP Dexterity has its Integrated Development Environment with graphical form, tables, reports and other objects designer, plus it has its own proprietary programming language Sanscript.  Before you dive into programming itself, it is important to understand such concepts as Dexterity Dictionary, alternate and new Dex forms, and reports (here you do not have an option to modify existing table, if it was not introduced in your customization, but is taken directly from main dictionary Dynamics.dic or from another Dynamics GP ISV add-on product dictionary, where you do not have control over the source code).  Let’s review some techniques, attributed to Dexterity coding:

1. Dexterity triggers.  If you want your Dexterity custom product to be friendly to most or all the other Dexterity dictionaries, instead of altering existing form or report, you think if the same goal is possible through field or even driven triggers.  To give you good example – in Dynamics GP Sales Order Processing Transaction form is famous to be customized in large number of Dynamics GP ISV products.  If you alter SOP Transaction form (by taking it directly from Dynamics.dic dictionary) – your Alternate SOP Transaction form will disable potentially other add-ons, where this form is also altered.  If what you need to do is to set some restrictions on one or several fields in this form – you may do it in the triggers (this triggers are not physically located on the form itself, instead they are registered when user logins Great Plains client interface)

2. SQL Stored Procedure call outs from Dexterity, versus Dex traditional cursor driven records update and insert techniques.  This was one of the interesting dilemmas in earlier Dexterity design.  As you may know – SQL select or update statement deploys so-called aggregation and its performance is astonishing.  However it is difficult to program SQL, which is compatible with multiple SQL vendors directly in C programming language.  What is more natural to be created neutral to various DB platforms is cursor.  Dexterity cursors are definitely very efficient, but when Microsoft acquired Great Plains Software in late 1990th, the question of being neutral to non-Microsoft DB vendors lost its actuality.  The last version of Great Plains, where non-Microsoft database platforms were supported (Pervasive SQL 2000/Btrieve and Ctree) was version 7.5.  Since the release of Microsoft Dynamics GP 8.0 release – this mid-market Corporate ERP application was only available on Microsoft SQL Server platform.  Giving such excurse to the history, if you are coding in Dexterity – the recommendation is to create efficient SQL Stored Procedure and call it directly from Sanscript Dexterity code

3. Where to learn Dexterity.  If you would like to dedicate yourself to Dexterity programming the best way is to find the job with one of the major Dynamics GP technology partner, especially the one, who is in Dynamics GP Source Code program.  If you would like to learn it on your own – the learning curve might be too long and your earlier programmed products might be not perfect.  Some notes, Dex is not technical Object Oriented Programming compliant, it is rather legacy procedural programming language.  There were some attempts to make Dexterity object look like OOP ones in Great Plains Purchase Order Processing module, where in our opinion the code, due to that, is more complex and not friendly to Dexterity developer with long experience and proven expertise.  So, if you dream about programming something very elegant, Dexterity might be a bit disappointing.  But its custom dictionaries are absolutely integrated and user interface have the same look and feel, as native Dynamics GP forms, reports, menus, etc.  Plus module coded in Dexterity automatically fits into GP security model

4. For additional information, please feel free to call us 1-866-304-3265 or 1-269-605-4904 (this number works for international customers) or email us help@alba866.com  We serve you USA/Canada nationwide via remote support (web sessions and phone/Skype conferences).  Local service is available in Western Michigan, Chicagoland, Southern California (LA, Orange County, San Diego)Psychology Articles, Houston area of the state of Texas

Source: Free Articles from ArticlesFactory.com

ABOUT THE AUTHOR


Andrew Karasev, http://www.alba866.com   Great Plains Dynamics GP and eEnterprise Certified Master, Microsoft MVP and consultant with 10 years and plus experience and expertise.  Alba 866 Corporation, 1-866-304-3265, 1-269-605-4904, help@alba866.com If you are thinking to implement Dynamics GP in challenging environment, we recommend you to give us a call.  Our information portal is http://www.pegasplanet.com Pegas Planet



Health
Business
Finance
Travel
Technology
Home Repair
Computers
Marketing
Autos
Family
Entertainment
Law
Education
Communication
Other
Sports
ECommerce
Home Business
Self Help
Internet
Partners


Page loaded in 0.058 seconds