Microsoft Dynamics project was first known as Microsoft Project Green, and got its current name in September 2005.  Currently Microsoft Dynamics unifies the family of former Microsoft Business Solutions ERP & CRM products: Great Plains, Microsoft CRM, Axapta, Navision, Solomon.  The idea of former Project Green was to create several Microsoft Suites: Financial, HR, Manufacturing, Supply Chain (SCM) on the base of its ERP products, where they would assumedly take the best core for each suite from one of MBS ERPs.  Microsoft Dynamics seems to emphasize interfaces unification and merge, so you should not be confused if all the sudden instead of GP database you will be switching to say Axapta database for SCM.  Obviously in the initial phase of Microsoft Dynamics each product: GP, NAV, AX, CRM, SL has its own integration methods and tools.  Let’s consider Microsoft Dynamics GP 9.0 integration tools in this small article

Microsoft Dynamics GP Integration Manager.  It is end-user tool and as the user you should feel free to experiment.  You should understand that Integration Manager is in the redesigning phase when instead of using GP workstation or so-called fat client as OLE server and use behind the scenes forms data entry and update validation – it will be using more eConnect, which  is repeating the data entry logic on the SQL stored procedure level and this is definitely way faster and efficient.  Some drawbacks – as Integration Manager is switching from OLE to eConnect – VBA scripting becomes not available too, so you should redesign your old integrations if you use a lot of custom integration logic via VBA scripting

Microsoft Dexterity.  We would say that Dexterity should be avoided in integration logic, however you can use custom dex forms to initialize integration parameters and then pass them to SQL Stored procedures, eConnect, etc.  The reason for avoicing Dexterity – the complexity to create dex integration is similar of exceeds the complexity to create stored procedure.  At the same time dex is cursor driven language and in SQL you can use aggregation and get higher performance

eConnect.  It was initially designed for eCommerce web developers to enable them use Microsoft Great Plains as backend for eCommerce application.  So – the answer is natural – it is good tool to create GP objects, such as Customer, Product, Sales Order or Invoice.  Later on eConnect logic took over almost every object in Microsoft Dynamics GP.  eConnect has some limitations, however – it was designed to take care of creation and update of so-called work records, such as enter Sales Order, then Sales order transfer to Invoice and Invoice posting were supposed to be the duty of GP operator – in the case if you need posting to be done automatically you need eConnect extensions

SQL Stored Procedures.  We do not recommend you to use DTS directly, because data validation is pretty sensitive and you need to imitate it in the code of more flexible stored procedure.  Also stored procedure may be the way to go, when your integration is pretty simple and straightforward and it is not feasible to pay for eConnect or Integration Manager.  As developer / programmer what you need to do is enter transaction you expect to integrate in GP test environment and look how do they go to SQL tables.  In GP you have DYNAMICS (or system) database and multiple company databases, you integration is usually hits company database only.  The most typical tables for integrations: SOP10100 – Sales Header, SOP10200 – Sales Lines, RM00101 – Customer master, RM00102 – Customer Address Master, PM00200 – Vendor Master, etc.