Microsoft Great Plains is currently under substantial technology redesign. To remind you the history – Great Plains Dexterity was architectured in earlier 1990th as IDE and shell, written in C programming language to become in turn development tool and scripting – Sanscript language. Later on Microsoft purchased Great Plains Software on the edge of the 21st Century. At about this time we see two emerging products: eXtender, written by Australian company eOne and eConnect – instrument, initially designed for web eCommerce developers. The question of choosing the appropriate tool for your specific GP software development typically requires additional research, so in this small article we will try to orient you, assuming that you are programmer and consultant, having some exposure to accounting and corporate ERP system architecture

o Dexterity. The idea was bright back in earlier 1990th to provide Great Plains Dynamics certain level of DB and computer platform independence and quick switch in the case of emergency. C programming language was introduced for the majority of old-good-days platforms: Unix, IBM PC/Microsoft Windows, Solaris, AIX, later on Linux. As an expense of this flexibility, Dexterity had to use cursor-driven data access/modification engine, to be compared with aggregated SQL SELEC and UPDATE statements. Aggregated statements provide a way more advanced performance

o Extender. Sometimes you think about funny questions in software development. Let’s say we provide a shell over Dex itself and train end-user or developer to prototype new custom logic in forms, tables, views and even provide the mechanism to include dex sanscript scriptlets. Would it be advantage over using raw Dexterity to build all this from scratch. The answer is more likely – yes, this is great and it is much easier and reliable to deploy secondary shell (extender), however you should understand the drawbacks. Extender, being dex construction should probably share the future fate of dex technology. And secondly – if you produce custom add-ons for Dynamics GP, you should probably use initial tool. However if you are end customer and just need to have job done – Extender is a good option

o eConnect. This tool is resolving Dex limitation as proprietary scripting language and opens GP objects pool to Microsoft Visual Studio developers. Plus eConnect has object oriented approach, which means that it is much easier to program it being “modern programmer” – it eliminates the necessity to do a lot of following QA testing, assuming that you as software coder follow object oriented rules precisely. You can use your language of choice or chosen philosophy: C# (former Java developers) or VB.Net – former VB programmers as well as all the spectrum of X.Net languages

o Combining Dexterity and eConnect. In our opinion this is the most recommended way of GP modifications for the following 5-10 years. Dexterity forms integrate you into Microsoft Dynamics GP “fat” client security realm and could be intuitively opened from GP workstation. Then you transfer business logic to Visual Studio developed custom logic, calling eConnect via XML web service interface

o Reporting. Here we see three tools: MS SQL Server Reporting Services, GP Report Writer (legacy dex tool) and Crystal Reports. You should probably consider MS trends here at the first place – SRS (virtually abandoning former Crystal Reports orientation). The good news is that SRS is intuitively understood to former Crystal Reports designer, so don’t fear, install SRS and port your reports to new platform. Regarding ReportWriter, if you have customized SOP Invoice Long Form, or Field Services forms, you should probably keep upgrading these custom reports in ReportWriter. Report Writer is integrated with GP workstation and doesn’t require additional modules to do report calling job

o Dexterity Source Code Programming. MBS has source code programming partners, who in turn have Dexterity programmer, familiar with low level sanscript source code (contained in DYNAMICS.DIC with code in, regular distribution strips sanscript code from this dictionary)

Source by Andrew Karasev