In this short FAQ style article we would like to introduce you - software developer, programmer, database administrator into Microsoft Great Plains Integration tools and options

Microsoft Great Plains is main Microsoft Business Solutions product for US mid-market. Historically Great Plains Software designed Great Plains Dynamics and Dynamics C/S+ as multiplatform application and the integration was possible via Great Plains Dexterity or Dexterity-based end user tools, such as Import Utility and later on via Integration Manager. When Microsoft Windows platform won the OS market (the last battle was in 1997 with PowerMac) Great Plains recommended OLE Server approach: Continuum for VB and Delphi and new Microsoft light programming technology - VBA (Visual Basic for Applications), which was integrated into Dexterity application - Great Plains Modifier (requires customization site enabler license). Since then Great Plains Dynamics/eEnterprise integration techniques use Microsoft technologies.

1. Microsoft SQL Server approach. This integration technique uses SQL stored procedures and views to pull data from your legacy or third party application and push it into Great Plains. The nice thing about MS SQL Server - it has linked server technology - you can establish the link to virtually all ODBC ir OLEDB compliant databases: Oracle, DB2/Unidata, Sybase, Ingress, Lotus/Domino, Pervasive SQL/Btrieve, Ctree/Faircom, Microsoft Access, Foxpro to name a few. You can schedule your integration as maintenance job or DTS package. However keep in mind that Great Plains tables structure is rather complex (it has master records, summaries, historical, work, open tables) and you should probably verify your stored procedures business logic with Great Plains source code (DYNAMICS.DIC with Dexterity procedures and functions scripts - in regular DYNAMICS.DIC these are stripped out - not every MBS partner has source code subscription - so do your selection work)

2. Great Plains Dexterity integration with Great Plains process server. This is more advanced and recommended approach, however it requires advanced Dexterity programming skills and access to the source code. The idea behind is simple - you populate so-called triggering custom table and then check it from Dexterity custom application every 5 seconds or so. If the record is there - then you process it. Processing is usually Dexterity source code stored procedure call. Great Plains uses similar logic when you post the batch and see the status in Process Monitor window. If you don't have source code - you can try to do the best guess with Microsoft Great Plains Software Development Kit (SDK)

3. Great Plains Integration Manager. This is end user tool and is easy to use. However - it uses Great Plains as OLE Server and calls Great Plains forms behind the scenes. As the result - it is very slow - we recommend using integration manager when you have up to one thousand transactions per day.

4. eConnect