Integrating Microsoft Dynamics GP Business Application fundamentals

(For more resources related to this topic, see here.)

Defining the project

Before you start installing software and designing windows, you need a plan. It's almost time to search for your flowcharting template, but first you need to answer this query: Just what are you trying to accomplish? Let's begin to define the project by responding to some fundamental questions:

  • Do you want to change the way a window looks or behaves?

  • Do you want to change or extend current Dynamics GP functionality?

  • Do you need to create brand-new functionality?

  • Do you need to exchange data between dissimilar systems?

  • Are you just trying to store some additional static data?

Changing a window's look or behavior

Maybe the field prompts are wrong or the tabbing order is unacceptable. Perhaps there are not enough, or even too many, fields on the window. The window may need additional navigation options such as menus or buttons. You might want a field to be created only if certain criteria are met. For instance, if your customer were a reseller, the Tax Schedule ID field would not be required; but if your customer were not a reseller, the Tax Schedule ID field would be required. Maybe more visual cues should be present on the window, such as a red/green light indicator on the Customer Maintenance window to represent their payment pattern similar to the following screenshot:

You may want a more obvious cue if a record note exists, like a bigger icon or an icon that flashes! You might want to see the quantity of a stock item available in the Sales Order Processing lookup window. This list could go on forever.

Changing current functionality

Many times Dynamics GP is just missing a little something with the way it processes certain transaction types. For example, perhaps you would like to be warned if you are entering a Payables Transaction for a vendor with an outstanding purchase order, or you need a receivables document to move to a history table automatically when you pay it, instead of having to run a monthly routine.

This list does go on forever

Creating new functionality

This category is filled with things that Dynamics GP doesn't do at all. Dynamics GP constructed the foundation, and developers like you make its functionality boundless. Many of our vertical solutions are present here; applications for running mining operations, restaurants, and retail stores have been developed for Dynamics GP. The unique needs of a myriad of industries have been satisfied by third-party applications.

Exchanging data between systems

Very often, you accumulate detailed information in a different system of record and you need to import it into Dynamics GP. Sometimes you need to export information out of Dynamics GP in order to update another system.

For instance, Point of Sale (POS) systems update the general ledger with daily sales, and payroll services send weekly payroll details to upload into the general ledger. Vendors send new price sheets that cause adjustments in the list price. These list price changes need to update the website as well as the accounting system. A constant stream of data flows back and forth every day and it needs to update other systems, or be updated itself. The goal is to take the information from the point of original entry, and electronically place it wherever it needs to go. We only want to touch the data once; dual entry needs to be eliminated. Our aim is to have only one version of the truth.

Storing additional data

Quite often the fields available for user customization, so called user-defined fields, are far too few. This problem is nearly universal when it comes to the inventory.

Take, for example, a company that trades in high-end audio equipment. For a preamp they may need to know the distortion percentage, the number and types of inputs, outputs available, and so on.

For speakers, they need a completely different set of information, such as sizes and types of drivers. Yes, there is much more information that needs to be at a salesperson's fingertips than the part number and the price.

All of that additional information needs a place where you can enter it, and a table to call home.

Types of integrations

At the end of the day, there are generally two types of integrations:

Database-level integrations include tasks such as the following:

  • Importing data into Dynamics GP

  • Exporting data out of Dynamics GP

  • Storing additional data in new tables

  • Synchronizing data between Dynamics GP and peripheral systems

User-interface-level integrations include tasks such as the following:

  • Adding entirely new windows

  • Adding fields or controls to an existing window

  • Adding navigation items to the home page

  • Adding new menus

  • Changing field locations on a window

  • Changing a window's tab order

A single customization often involves both types of integrations.

OK, so now that the interrogation is complete, it's time to find that template and start flowcharting!

Overview of available tools

Once you have defined what you are trying to do, you need to find a tool that will do it. Fortunately, there are many tools available to help you accomplish your goal.

Each tool does something a little different from the others. Which tool to select may be obvious, but often there are several ways to achieve the same result. A hybrid approach may be necessary when no single tool will go the distance.

The several tools at your disposal, which we will discuss in this section, include:

  • Dexterity

  • Visual Studio Tools for Dynamics GP (VS Tools)

  • Modifier with VBA (Visual Basic for Applications)

  • Continuum

  • Extender / eXtender Enterprise

  • DDE / ODBC / ADO / OLE Automation

  • Integration Manager

  • Table Import

  • eConnect

  • Web services

The decision of which tool to use requires careful consideration of the type of customization, the capabilities of the tool, the skills of the developer, and any prerequisites or licensing requirements imposed on the end user.


Dexterity is a complete Integrated Development Environment (IDE) and the native language of Dynamics GP. You can create the tightest, most seamless integrations using Dexterity. All of the resources of a Dexterity integration are stored in a dictionary file. By resources we mean the business logic, fields, windows, table definitions, push buttons, and so on. The runtime engine interprets these resources and presents a single application to the user.

The extensibility of Dynamics GP allows multiple Dexterity integrations to run at the same time, yet appear to the end user as a single program running alone. This unique environment is referred to as a multidictionary environment. The following diagram illustrates a multidictionary environment where several dictionaries are functioning together to create the end-user application.

If you need your application to have access to all of the resources in the Dynamics dictionary and behave exactly as Dynamics GP, Dexterity is your tool.

Capabilities of Dexterity

Using Dexterity, you can perform the following:

  • Access and manipulate all of the resources exposed by the Dynamics.dic file.

  • Create new custom windows using the built-in WYSIWYG graphical forms designer in a style indistinguishable from the native Dynamics GP windows.

  • Create your own version of an existing window to use in place of the original Dynamics GP window (an Alternate Window).

  • Create new reports using the built-in report writer.

  • Create your own version of an existing report to use in place of the original Dynamics GP report (an Alternate Report).

  • Use the sanScript scripting language to create business logic that extends existing Dynamics GP functionality or creates wholly new functionality. Scripts can respond to user actions such as pushing a button, changing a field, or closing a window.

  • Use Dexterity triggers to watch for events such as opening a window or tabbing off a field. You can trigger off events in any customization written in Dexterity; you are not limited to just the Dynamics.dic file. When the trigger fires, it runs a procedure written by you.

  • Use the extensive library of over 1,000 pre-written functions to perform otherwise complicated tasks.

  • Use the integrated debugging tools to debug your application, even when your application is running in multidictionary mode.

  • Create structured error handling.

  • Call the same procedures used by Dynamics GP to execute subroutines.

  • Create SQL tables and automatically generate stored procedures to handle table operations.

  • Include the resources you create in the Dynamics GP security model without writing a line of code.

  • Access the .NET Framework, web services, and any other features made available by other applications through Component Object Model (COM).

  • Provide access to end-user customization tools such as Report Writer, Modifier with VBA, and the Import utility.

  • Create your own toolbar.

  • Create navigation to your application from the homepage.

  • Create a navigation list exposing your data.

Even though Dynamics GP is not open source, all of these capabilities are available because Dynamics GP was written to embrace the creation of integrating applications. In short, if you use Dexterity to create your customization, it can do anything Dynamics GP can do.


As robust as it is, Dexterity does have its limitations:

  • You cannot modify a form in a third-party dictionary, meaning you cannot modify a Dexterity window that lives in a dictionary other than the dynamics.dic file

  • Dexterity does not support Unicode; so if you need support for Chinese, Japanese, and Korean hieroglyphs, you have a problem to solve

  • Dexterity cannot access fields added using the Modifier tool; therefore, you cannot attach sanScript code to those fields

  • Dexterity does not support dynamically loading images from a database

Developer skills required

The following skills are generally necessary to develop an integration using Dexterity:

  • Thorough knowledge of the sanScript scripting language

  • Experience working with the data model of Dynamics GP

  • Experience navigating the user interface of Dynamics GP

  • A proficiency in database design

  • An understanding of SQL Server

  • An understanding of SQL Server stored procedures

End-user prerequisites

There are no end-user prerequisites. The customization results in a .cnk file that any user could drop into the folder containing dynamics.exe. The next time Dynamics GP is launched, the .cnk file gets extracted, adds the appropriate settings to the Dynamics.set file, and becomes a .dic dictionary file.

Visual Studio Tools for Dynamics GP (VS Tools)

The Dynamics GP development community was elated when VS Tools was released. Finally, a non-Dexterity programmer had a real opportunity to customize Dynamics GP! The world was buzzing with rumors that Dynamics GP was being rewritten in .NET, and Dexterity would soon be a thing of the past. Well, that didn't happen; but VS Tools really opened the floodgates for customizations. It turns out that there are actually more .NET programmers than Dexterity programmers! Imagine that.

VS Tools is the .NET API (Application Programmer's Interface) for Dynamics GP. By creating your customization in managed code (a .NET assembly), you can use the exhaustive list of features provided by the .NET Framework against the resources in Dexterity-created dictionaries.

Capabilities of VS Tools

Using VS Tools, you can perform the following:

  • Create WinForm Windows

  • Access tables, table fields, and table buffers

  • Access Original, Alternate, and Modified windows

  • Access window fields and global variables

  • Access fields created using the Modifier tool

  • Execute Dexterity commands, functions, and procedures

  • Use the runtime engine's trigger system to respond to events such as a window opening or a field changing

Developer skills required

The following are the skills the developer requires:

  • Knowledge of the .NET Framework

  • Experience creating applications with Microsoft Visual Studio

  • Understanding of a .NET language, like Visual Basic.NET or C#

  • Experience working with the data model of Dynamics GP to understand which tables to access

  • Familiarity with Dexterity is helpful if you want to invoke Dexterity functions or procedures

  • Experience navigating the user interface of Dynamics GP to understand which events to register

End-user prerequisites

There are no end user prerequisites. The customization results in a .dll file that any user could drop into the AddIns folder inside the main Dynamics GP folder. Using a default installation, the AddIns folder exists here for a 64-bit machine: C:\Program Files (x86)\Microsoft Dynamics\GP2010\AddIns and for a 32-bit machine it is located here: C:\Program Files\Microsoft Dynamics\GP2010\AddIns.

Modifier with VBA (Visual Basic for Applications)

Modifier with VBA is actually two tools: Modifier and VBA. You cannot separate them, but they each do very different things. Modifier is largely a stripped-down version of the graphical forms designer found in the Dexterity tool. Using Modifier, you can make changes to existing windows, such as adding or removing fields, moving things around, or changing the tab order. Changes made with Modifier are stored in a separate dictionary. Modifications to forms in the Dynamics.dic file are stored in the Forms.dic file. Modified windows are not part of, nor do they change, the original resources in the application dictionary. Each application creates its own dictionary for storing changes made with Modifier. For example, the Fixed Asset module's modified windows are stored in the F309.dic file, while modified windows of the Human Resources module are stored in the HRPFRMS.dic file. The filenames that store modified forms are defined in the Dynamics.set file.

The following screenshot shows the Vendor Maintenance window as it appears in the Modifier. To add new fields from the PM_Vendor_MSTR table to the window, simply select a field from the toolbar and then drag it onto the window.

New fields created using Modifier have no life. You can use Modifier to put the button on the window, but you cannot make it do anything when pushed. The VBA side of Modifier with VBA provides the means for you to attach code to new or existing fields. The code is VBA code, not sanScript (Dexterity) code. Once you attach some VBA to the new button's change event, it has life. Modifier is aware of any window created with Dexterity no matter which application dictionary (.dic file) houses it. This fact makes Modifier an attractive tool to use when you need to add a button to a third-party window with the least amount of effort.

Modifier is largely an end-user tool; VBA code runs as clear text and is easily modified by others. You need to keep this in mind if you develop your integrations using Modifier with VBA. Protect your customizations!

Use the Protection tab in the Project Properties window to lock your VBA project from viewing:

Capabilities of Modifier with VBA

The following is a list of capabilities of Modifier with VBA:

  • Modify the appearance of existing windows

  • Add new objects and fields to windows

  • Change the tab order on a window

  • Add additional business logic to windows and reports using VBA

  • Add new VBA forms

  • Modify windows and reports of other integrating applications created in Dexterity

  • Modifier with VBA is COM compliant

Developer skills required

Different skills are required for different actions using Modifier with VBA. The primary difference is that the window changes themselves do not involve any coding, nor require any knowledge of the data model. Once you start adding VBA code to the project, developer skills become necessary.

  • Knowledge of VBA is necessary for adding event code or VBA forms

  • Experience navigating the user interface of Dynamics GP is helpful

  • Knowledge of SQL commands is needed as the project becomes more complex

  • Developer skills are not required to make window changes using the Modifier

End-user prerequisites

You, as the developer, will create a package file once the customization is complete. Any end user can import this package file, provided the Customization Site License or Modifier with VBA module is registered. Customizations created with Modifier and VBA need to be installed on each user's workstation rather than on a network share. Depending on the number of workstations, deployment and maintenance can be inconvenient.


Continuum provides the COM API for Dynamics GP. Continuum, such as VS Tools, takes advantage of the extensive triggering system of the runtime engine. You identify which Dexterity events your application wants to be notified of, such as opening a window or changing a field, and when that event occurs, your application is notified and can execute a procedure in response to the event.

This tool, although no longer being developed, is a favorite among Visual Basic and Delphi programmers. One of the beauties of Continuum is that it comes with add-in wizards that walk you through each step required for creating an integration using a point-and-click interface. Using the wizards, you choose the windows, fields, and controls you want to integrate with, and then it generates the Visual Basic (or Delphi) code needed to complete the integration. Continuum for Visual Basic takes full advantage of Object Linking and Embedding Automation "OLE Automation" to keep data fields and buttons completely synchronized. What could be better than that?

You use a special subset of sanScript with Continuum; that subset is documented in the sanScript Supplement that comes with the Continuum. The Continuum API provides you a means to write pass-through sanScript that will execute against the Dynamics GP application. The files you need to set up a Continuum project, as well as the Continuum API Guide and Continuum sanScript Supplement, are located inside the Tools\Continuum folder of the installation DVD for Dynamics GP.

Capabilities of Continuum

The following are the capabilities of Continuum:

  • Create a form-level integration to add additional business logic to Dynamics GP using pass-through sanScript

  • Create a process integration that reacts to Dynamics GP events

  • Create a database-level integration using pass-through sanScript to register triggers in Dynamics GP

  • Access Dynamics GP resources using COM

Developer skills required

The following are the skills the developer requires:

  • Experience navigating the user interface of Dynamics GP to understand which events to register

  • Experience with whichever COM-capable development tool you selected to create the integrating application (such as Visual Basic .NET)

  • Experience creating applications with Microsoft Visual Basic or Delphi is helpful

  • Knowledge of the Dynamics GP dictionary resources

  • Familiarity with the sanScript statements used by Continuum

End-user prerequisites

There are no end-user prerequisites.

Extender / eXtender Enterprise

Extender is an integration tool that gives you the ability to add additional data entry windows to Dynamics GP. If you have the Enterprise version of the product, you can add new functionality using scripts. eXtender Enterprise is as close to point-and-click Dexterity as you can get. The Enterprise edition is available only from eOne Solutions; it is not sold by Microsoft as part of Dynamics GP.

Extender allows for complete custom applications to be built by end users without a single line of code being written. The new Extender application you create comes automatically linked with all the features of Dynamics GP: SmartList objects, drill downs, advanced lookups, notes, as well as unique Extender features such as detail note tracking, e-mail merges, user-defined searches, imports, and more.

Capabilities of Extender and eXtender Enterprise

The following are the capabilities of Extender and eXtender Enterprise:

  • Create new data-entry windows

  • Link additional windows to any form in any dictionary

  • Create new dialog windows

  • Create new note windows with expanded functionality

  • Create new menus

  • Automate macro execution

  • Create conditional windows using criteria set by the developer

  • Create SQL views of the data collected in the new windows

  • Import information into the new Extender data-entry windows

  • Apply templates to set default values for fields

  • Embed business logic behind Extender data-entry windows (eXtender Enterprise only)

Developer skills required

The following are the skills the developer requires:

  • Experience navigating the user interface of Dynamics GP

  • Development experience using sanScript is necessary for using the scripting functionality of the eXtender Enterprise edition

  • None required for using the Extender module purchased from Dynamics GP; this tool is predominantly an end-user tool

End-user prerequisites

The user needs to have purchased the Extender module or eXtender Enterprise, depending on whether scripting is required.

DDE \ ODBC \ ADO \ OLE Automation

DDE (Dynamic Data Exchange), ODBC (Open Database Connectivity), ADO (Active Data Objects), and OLE Automation (Object Linking and Embedding Automation), are industry standards for accessing and exchanging data.


The primary function of DDE is to allow applications to share data. It uses the Windows Messaging Layer functionality within Windows to allow two running applications to share the same data. DDE is a method of asynchronous communication called a DDE Conversation, which allows one program to communicate with another program. The client application sends a Windows message to the server application. Windows holds the message and sends it to the server application when the server application is ready to process it. The client application can continue processing; it does not need to wait for a response from the other applications.

The only thing DDE can do is transmit data. It only appears to control another application if the other application can treat data as a command. DDE is lean and clean from the programmer's point of view; there are no .dlls required and it doesn't interrupt processing.


ODBC is a technique used for accessing database information using drivers. The drivers provide a universal middleware layer that uses a standard set of commands to communicate with a Database Management System (DBMS). The driver then translates those standard commands into the correct instructions for the specific DBMS. Using ODBC, you can write programs that access data without knowing how the database is implemented. ODBC drivers are considered OLE Providers.


ADO is a collection of COM objects used for accessing data sources. Like ODBC, ADO is a language-neutral object model that exposes data raised by an underlying OLE Provider. ODBC drivers are the most commonly used OLE Providers.

OLE Automation

OLE Automation is a mechanism that allows for the exchange of data between applications. It provides an infrastructure whereby applications, called automation controllers, can access and manipulate shared automation objects that are exposed by automation servers. Automation controllers are also known as automation clients. This concept of client and server is also used in DDE conversations. Dynamics GP can be either an automation server or an automation client.

Capabilities of DDE \ ODBC \ ADO \ OLE Automation

There are some subtle differences between these applications, but we're going to group them together for the purpose of customizing Dynamics GP. These tools have the following capabilities:

  • Create new data records

  • Read existing records

  • Update existing records

  • Delete existing records

  • DDE is capable of asynchronous communication

None of these tools provide a means to modify the user interface of Dynamics GP.

Developer skills required

The following are the skills the developer requires:

  • Experience with the chosen development tool used to access the data.

  • If using OLE Automation, knowledge of how to call the objects is required.

  • If using DDE, knowledge of the supported DDE commands is required.

  • Experience working with the data model of Dynamics GP is essential. No data validation is provided, so it is up to you, the developer, to ensure the correct tables are being accessed.

  • An understanding of how to create a database connection string is helpful.

  • ODBC and ADO require no specific developer skills.

End-user prerequisites

There are no end-user prerequisites. It's possible the end user may require an access license to the database if the database is being accessed outside of the Dynamics GP user interface.

Integration Manager

Integration Manager is an end-user tool used to import data into Dynamics GP. This tool could be used for a one-time import to convert data from an old system, or a periodic import of data in an ongoing manner. VBScript can be added to many events of an integration, allowing for some very complex logic to be executed. Integration Manager has a user-friendly interface for mapping data from a wide array of sources.

The following screenshot shows the destination mapping window for a Payables Transaction where you would identify the source for the data being imported. Most fields have a default value that will be used if the source data does not include a value for that specific field.

Capabilities of Integration Manager

The following is a list of the capabilities of Integration Manager:

  • Import transactions with full business-logic validation

  • Import or update master files with full business-logic validation

  • Use VBScript at distinct points in the integration to expand functionality

Integration Manager is restricted to a predefined set of import destinations. New destinations cannot be added by the user.

Developer skills required

The following are the skills the developer requires:

  • No knowledge of the database is required; this is an end-user tool

  • VBScript can be used, so a proficiency in VBScript would be helpful to fully exploit the capabilities of this tool

  • Integration Manager can be automated using Windows Scheduler, so experience with the Windows Scheduler is a plus

End-user prerequisites

The end user needs to own the Integration Manager module. This module is not included with any of the Dynamics GP Business Ready Licensing models.

Table Import

Table Import is a utility that comes with Dynamics GP and can be used to import data into any Dynamics GP table, regardless of the dictionary. Table Import does only one thing, but it does it very well and very fast. Think of Table Import as the data-slam method of importing data.

You must provide a properly formatted comma-or tab-delimited text file, and then map the file data into the fields in the target table. No translation is available, no links are made to other tables, and you cannot use ODBC. No validation against the business logic is performed. It is a direct-to-table import that you use at your own risk.

A word of caution: although there is nothing stopping you from importing transaction data, you should tread lightly in this area. Remember, you have no business logic validation with the Table Import utility. You would most likely use this utility for populating master file tables, especially tables without an adapter that you can use with Integration Manager. For example, you might use Table Import to bring in account categories or sales tax details.

The Dynamics GP Software Development Kit includes information that will help you use this tool to import master file data as well as a limited number of transaction types.

Table Import can only add data; it cannot update data.

The following screenshot shows the Table Import Definition window. The data you want to import is in the source file. The destination table is where the data will land in Dynamics GP. The scrolling window lists all of the fields in the destination table and how they are mapped to the fields in the source file.

Capabilities of Table Import

The following are the capabilities of Table Import:

  • Import new data into any table in the database

  • Import values into a multi-select listbox field

If you use SQL Server Management Studio to look at a multi-select listbox field, such as the DSPLKUPS (display in lookups) field in the GL00100 table, you will see <Binary data> as the field value. If you use Table Import, you can use a 32-character string field made up of T and F characters and populate the database field correctly. Integration Manager does not support this level of integration with multi-select listboxes.

Developer skills required

The skill required by the developer is as follows:

  • As no validation is done on the imported data, an in-depth knowledge of the Dynamics GP data model is required

End-user prerequisites

None; the end user simply opens the Table Import Definition window, selects the appropriate Definition ID, and then executes the import.


At its root, the eConnect product is a collection of encrypted, stored procedures, and the methods to access them. These stored procedures allow external applications to create, retrieve, update, delete, and void Dynamics GP documents. Unlike the Table Import utility, eConnect uses the Dynamics GP business logic to validate all transactions.

eConnect has become the integration tool of choice across the development world because it can interface with nearly anything. It contains a rich set of interoperability tools that you can use to extend the functionality of Dynamics GP. You can create stored procedures to run before or after the eConnect document exchange. As a bonus, eConnect is very fast.

The principal components and interfaces of eConnect include a .NET-managed code assembly, a Microsoft BizTalk AIC (Application Integration Component), and MSMQ (Microsoft Message Queuing) services. When you install eConnect, it creates a WCF (Windows Communication Foundation) service named eConnect for Microsoft Dynamics GP 2010 Integration Service (eConnect Integration Service). This integration service replaces the eConnect COM+ object that was used in eConnect versions prior to Dynamics GP 2010.

eConnect uses specially formatted XML (Extensible Markup Language) documents to integrate with Dynamics GP; therefore, your application must be able to create or consume XML documents. Business rules are enforced during the integration ensuring all of the necessary tables are updated with each imported item. Over 200 integration points are supported by eConnect. The required XML document schemas are provided in the eConnect documentation.

By using eConnect, external applications such as CRM programs, point-ofsale systems, web services, warehouse management systems, and other legacy applications can interact with Dynamics GP. These external applications can import or update master files and import or void transactions. The following diagram illustrates the different layers and components incorporated with eConnect.

In order to communicate with eConnect Integration Service, you need to include the eConnect assembly and namespace in your development project. However, if you use a Service Reference to interact with eConnect, you do not need to add the Dynamics GP eConnect assembly or namespace to your development project. With a Service Reference, your application will be able to work directly with the eConnect Integration Service.

By using MSMQ services, eConnect integrations can run without user interaction. The MSMQ services do not post the transactions however, so you can't automate the entire process. There is a tool available from Microsoft, the autopost.dll file, that uses the Continuum API to call the Dynamics GP posting procedures. By using this tool, you can post imported transactions automatically instead of requiring the user to complete the post. On the downside, in order for the autopost.dll file to work Dynamics GP must be running. Since Dynamics GP must be running, a user license is consumed.

There is an application available from eOne Solutions, called SmartConnect, that provides a point-and-click interface to eConnect. The SmartConnect application transforms eConnect into a drag-and-drop end-user tool without losing the development capabilities of eConnect.

SmartConnect ships with a shared web service that allows for data to be pushed into Dynamics GP from external applications such as Access or Excel. You can also fully automate posting without the need for autopost.dll\. Using the web service, you can update Dynamics GP without requiring a Dynamics GP login; thus you still have all of your user licenses available.

Capabilities of eConnect

The following are the capabilities of eConnect:

  • eConnect allows external applications to access real-time Dynamics GP data

  • eConnect provides tools that you can use to create, retrieve, update, delete, and void a wide array of Dynamics GP documents

  • Imported data is validated against the Dynamics GP business logic

  • eConnect is compatible with Visual Basic objects, stored procedures, BizTalk Server AIC adapters, COM integration, MSMQ, XML document exchange, and other industry-standard technologies

Developer skills required

The following are the skills required by the developer:

  • Expertise working with XML documents and schemas is a must

  • Experience with the selected programming application you're using to create the integration is necessary

  • Knowledge of Windows Communication Foundation is needed if you are using a Service Reference

  • Familiarity with Dynamics GP documents and operations

End-user prerequisites

To use an eConnect integration, the eConnect runtime components must be installed. In order to use the private message queues for the incoming and outgoing services, Windows Message Queuing must be installed and operating. In order to use the eConnect BizTalk adapter, BizTalk 2006 or later must be installed.

Web services

Web services use XML documents and acts as middleware between eConnect and Dynamics GP. There is no user interface with web services; you design the user interface with your tool of choice and then use the web services to manipulate the data. In order to use web services, the type of transaction you want to execute must be listed as one supported by this tool.

Web services for Dynamics GP integrates with web-based applications using the industry standards of XML, SOAP (Simple Object Access Protocol), WSDL (Web Services Description Language) and UDDI (Universal Description, Discovery, and Integration) on an Internet protocol across a network.

XML provides the language that you can use between different platforms and development tools. XML uses tags to define, transmit, validate, and interpret the data. A tag is written between angled brackets and marks the start point and end point of each logical unit or element of an XML document. The following is an example of a simple XML tag:

<email> <to>Leslie Vail</to> <from>Superman</from> <body>Hello World!</body> </email>

SOAP is a messaging protocol you can use to encode request and response messages. SOAP messages are independent of any operating system or programming language, so they can be transported using popular Internet protocols such as SMTP (Simple Mail Transfer Protocol), MIME (Multipurpose Internet Mail Extensions), IMAP (Internet Message Access Protocol), and HTTP.

WSDL is the language used to describe what the web service does and provides information on how to interface with it.

UDDI is used for listing which specific services are available. UDDI listings are written in WSDL.

Capabilities of web services

The following are the capabilities of web services:

  • Allows integration with external applications

  • Customers

  • Vendors

  • General Ledger accounts

  • Sales Order documents

  • Purchase Order documents

  • Receivable transactions

  • Payable transactions

  • General Ledger transactions

  • Through the web service, an external application can create, retrieve, update, delete, and void supported Dynamics GP documents

  • Provides a means to interact with Dynamics GP using a web browser

Developer skills required

The following are the skills required by the developer:

  • Expertise working with XML documents and schemas is a must

  • Experience with the selected programming application you select to create the integration

  • Familiarity with Dynamics GP documents and operations

  • Knowledge of the Dynamics Security Service

  • Knowledge of Windows Communication Foundation

  • .NET programming abilities

End user prerequisites

A web service solution will need to be installed by qualified IT personnel; after that, there are no end-user requirements.


We just covered a short description of how an integrating application works and a brief overview of various tools you can use to build an integration.

Resources for Article :

Further resources on this subject:

You've been reading an excerpt of:

Developing Microsoft Dynamics GP Business Applications

Explore Title