Microsoft Dynamics Gp 10.0 Technical Notes or Under the Hood

By: Andrew Karasev

Nowadays Microsoft Great Plains or any other ERP application should be rather considered as the platform for integration of your peripheral applications: CRM, eCommerce, Custom Sales Order Processing, EDI (Electronic Document Interchange) and others. Plus of-the-shelf available business logic often requires customization, where you got to select appropriate software development tools to do the job. Since the time of Great Plains Software being purchased by Microsoft, Great Plains was under the way of being redesigned to be tightly integrated with .Net and Microsoft Outlook and Office stack of products. Let's take a look at the GP technical layer:

1.Microsoft Dynamics GP Dexterity architecture. Great Plains Dex was designed to serve as Great Plains Dynamics platform in earlier 1990th, when similar approaches were taken by SAP - ABAP and Navision - C/SIDE. Dexterity is in turn written in C++ programming language. To give you Dex architecture surface signs: DYNAMICS.DIC, DEX.INI files, DEX_ROW_ID that you see in each GP table. If you plan to use Dexterity for customization, then you need to locate Dex developer, especially the one who has access to Dexterity source code

2.eConnect. This SDK was specially created for e-commerce developers to enable GP backoffice integration for eCommerce web sites. Since the initial version back in earlier 2000th, eConnect covered more GP modules and business objects: SOP, POP, Project Accounting, General Ledger, Receivable Management, Payables Management modules. The core of eConnect are encrypted SQL stored procedures

3.GP Integration Manager. If you review GP IM 10.0, you will see that IM connectors are now available in most of the business logic cases in eConnect. EConnect connectors drastically improve IM performance and doesn't require GP workstation running on the same computer (old IM connectors were using GP workstation as OLE server)

4.SQL Scripting and Stored Procedures. If performance is the imperative, then you should consider SQL scripting, which will allow you to create primitive business logic, where you don't need complete business logic validation, made by eConnect. Also stored procedures will allow you to utilize aggregations in SQL, versus SQL cursors, deployed in eConnect

Microsoft
 • 
 • 
 • 
 • 
 • 
 • 
 • 
 • 
 • 
 • 
 • 
 • 
 • 
 • 
 • 
 • 
 • 
 • 
 • 
 • 

» More on Microsoft
 



Share this article :
Click to see more related articles