Microsoft Great Plains Dexterity Customizations – overview

Mar 19
12:12

2007

Andrew Karasev

Andrew Karasev

  • Share this article on Facebook
  • Share this article on Twitter
  • Share this article on Linkedin

This small article is written, based on new features of the product, as well as considering Microsoft Dynamics GP customization tools combining: Dex, eConnect, SQL Stored Procs, Extender. Currently we assume that you are using Microsoft Dynamics GP version 9.0, soon we should expect Microsoft Dynamics GP 10.0 to be released

mediaimage
  • Microsoft Dexterity.  It is also often associated with so-called Dynamics GP source code programming.  MBS VAR,Microsoft Great Plains Dexterity Customizations – overview Articles who has access to source code (DYNAMICS.DIC dictionary with dex sanscript scripts present).  Dexterity has no limits in accessing and modifying GP resources, such as tables, forms, reports, scrolling windows, data types, etc.  Obviously, when you get such a powerful tool, you should expect that it will have as pluses as well as minuses.  Dexterity is not formally object oriented language – you will need to program old-good-days procedures, functions and dex cursors.
  • Dexterity improvements.  Beginning with version 7.0 – you may operate COM objects.  Historically when SQL Server 6.5 was introduced Dex enabled calling stored procedures, more resent improvements allowed developers call SQL scripts from dex.
  • Dexterity and eConnect.  Contrary to Dexterity, eConnect allows you to manipulate GP objects: Customer, Vendor, Sales Order, Purchase Order, Employee, etc. – and so has elements of object-oriented programming.  We recommend you to consider scenario, when Dexterity is used for new form generation and then from these new forms you call eConnect via eConnect XML Web Services interface.  This approach allows you to create seamless GP client/workstation integrated custom logic
  • Extender.  eOne Extender is very flexible module, allowing you to “send back” dex complexity and prototype GP forms, tables, some posting logic, plus add Dex sunscript code to these new constructions.  We would recommend Microsoft Visual Studio development approach here – when you are done with tables prototyping in Extender, please consider Visual Studio DLL project to work with newly created tables and call eConnect methods to manipulate GP objects
  • SQL Scripting.  In new Microsoft ERP products, such as Axapta or Microsoft CRM – direct SQL scripting is typically not supported.  GP was traditionally leveraging SQL coding, so you are welcome to create SQL integrations, however you should have some familiarity with Microsoft Great Plains Dexterity architecture: DEX_ROW_ID, for example.  Dexterity has so-called atomic scripts – stored procs, allowing Dex shell, written in C programming language to read SQL tables by dex indexes, these stored procs have prefix zdp_*