Microsoft Great Plains Data Conversion – overview for developerWritten by Andrew Karasev
Looks like Microsoft Great Plains becomes more and more popular, partly because of Microsoft muscles behind it. Now it is targeted to whole spectrum of horizontal and vertical market clientele. Small companies use Small Business Manager (which is based on same technology – Great Plains Dexterity dictionary and runtime), Great Plains Standard on MSDE is for small to midsize clients, and then Great Plains serves rest of market up to big corporations. If you are developer who is asked: how do we convert our old system data for initial Great Plains setup – read this and you will have clues on where to look further. 1.Great Plains Integration Manager - this is rather end-user tool - it is very intuitive, it validates 100% of business logic, brings in/updates master records (accounts, employees, customers, vendors. etc.) brings in transactions into work tables. The limitation of Integration Manager - it does use GP windows behind scenes without showing them - so it is relatively slow - you can bring 100 records for ongoing integration - for one-time conversion/integration you are probably OK with IM. By way you can program Integration Manager with VBA. 2.eConnect – it is type of Software Development Kit with samples in VB.Net. Obviously development environment should be Visual Studio.Net. eConnect will allow you to integrate master records - such as new customers, vendors, employees, etc., plus you can bring transactions into so called Great Plains work tables (eConnect doesn't allow you to bring open or historical records - you need to post work records in Great Plains, same limitation applies to Integration Manager above). eConnect is rather for ongoing integration. It was initially created for eCommerce application integration to Great Plains. 3.SQL Stored Procedures. Obviously you have unlimited control and possibilities with SQL queries. You need to know Great Plains tables structure and data flow. Launch Great Plains and go to Tools->Resource Description->Tables. Find table in proper series. If you are looking for customers – it should be RM00101 – customer master file. If you need historical Sales Order Processing documents – they are in SOP30200 – Sales History Header file, etc. Do not change existing tables - do not create new fields, etc. Also you need to realize that each GP table has DEX_ROW_ID - identity column. For ongoing integrations - sometimes it is good idea to use inbound/outbound XML in parameters - then you can deploy web service as a middle party between two systems.
| | Microsoft Great Plains Integrations - tips for developerWritten by Andrew Karasev
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 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 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 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)
|
