.png)
Microsoft Dynamics GP Integration Guide
Connect Microsoft Dynamics GP with enterprise applications through Service Based Architecture REST endpoints, SOAP Web Services, eConnect, and controlled SQL Server access.
Microsoft Dynamics GP integration options at a glance
Microsoft Dynamics GP integrations depend on the deployed GP version, enabled components, and company configuration. Service Based Architecture provides REST-oriented access for selected resources, while GP Web Services exposes SOAP operations for supported business objects and processes. eConnect supports structured XML transactions and is often used for sales, purchasing, inventory, receivables, payables, and general ledger scenarios. Authorized SQL Server access is useful for reporting, extraction, and reconciliation, although direct transactional writes require caution. Martini can consume REST and SOAP services, invoke an eConnect intermediary, read SQL Server through JDBC, transform JSON or XML, expose APIs, and orchestrate scheduled workflows.
| Integration point | Supported by Microsoft Dynamics GP? | Common use cases | How Martini supports it |
|---|---|---|---|
| REST APIs / Service Based Architecture | Yes | Create, update, and retrieve selected GP resources such as Customers, Vendors, Items, Sales Orders, and Sales Invoices. Coverage depends on GP version and configured components. | Martini can consume documented GP REST endpoints, transform JSON payloads, apply workflow rules, and expose a stable API façade for external applications. |
| SOAP Web Services | Yes | Invoke supported GP business-object and process operations where the GP Web Services runtime is deployed. | Martini can consume WSDL-defined services, construct SOAP requests, handle namespaces and company context, and route SOAP faults into workflow error handling. |
| eConnect XML transactions | Yes | Process structured XML transactions for sales, purchasing, inventory, receivables, payables, and general ledger scenarios through an available supported endpoint or intermediary. | Martini can transform canonical data into XML, invoke an eConnect-based service, correlate responses, and manage retries and reconciliation. |
| SQL Server database access | Yes | Extract reporting data, reconcile transactions, stage information, and perform controlled read-oriented integration against GP SQL Server databases. | Martini can use JDBC and SQL workflow capabilities to query authorized tables or views, persist high-water marks, and load downstream systems. Direct writes require explicit governance. |
| Bulk, asynchronous, and batch processing | Limited | eConnect and GP batch concepts support structured or multi-record workloads, but submission, validation, and posting may occur as separate stages. | Martini can batch records, limit concurrency, track document and batch status, and reconcile accepted, rejected, and pending transactions. |
| File and attachment handling | Limited | Selected GP areas support documents, attachments, imports, or exports, but universal attachment API coverage is not confirmed. | Martini can process files where the customer exposes a supported file or service endpoint, while validating object support, storage location, size, and security restrictions. |
| Webhooks and outbound callbacks | Not confirmed | No general-purpose native GP webhook model covering business objects was confirmed. Event-like behavior may be provided by customer-managed infrastructure. | Martini can receive HTTP callbacks from a customer-managed intermediary, but polling or change-detection workflows should be used when no callback source exists. |
| Authentication | Yes | Windows authentication, service accounts, GP security roles, company permissions, and—where enabled—SQL Server authentication are used depending on the interface. | Martini can store environment-specific credentials securely, invoke authenticated APIs and databases, and keep company and permission boundaries explicit. |
How Microsoft Dynamics GP exposes data and business events
Microsoft Dynamics GP REST APIs
Service Based Architecture exposes REST-oriented endpoints for selected Dynamics GP functionality. Available resources and operations depend on the GP release, installed components, configuration, and company permissions; the interface does not necessarily expose every table or business process.
Martini implementation pattern
Martini implementation pattern: Martini consumes the enabled GP REST endpoint, authenticates with the configured Windows or deployment-specific security model, maps external JSON into the GP resource structure, and returns a controlled response or downstream status through a workflow or Martini API.
Implementation sequence
Microsoft Dynamics GP SOAP Web Services
Dynamics GP Web Services provides SOAP operations for selected business objects and processes. Integrations must account for WSDL definitions, endpoint configuration, namespaces, company context, GP permissions, SOAP faults, and business validation errors.
Martini implementation pattern
Martini implementation pattern: Martini consumes the WSDL-defined service, builds SOAP requests from mapped data, invokes the selected operation, interprets SOAP faults separately from transport errors, and records document identifiers and statuses for reconciliation.
Implementation sequence
Microsoft Dynamics GP eConnect XML
eConnect is an XML-based Dynamics GP integration framework used for structured transactions, including sales, purchasing, inventory, receivables, payables, and general ledger scenarios. It may require Windows hosting, installed components, and a service or intermediary that accepts XML messages.
Martini implementation pattern
Martini implementation pattern: Martini validates and transforms canonical business data into the XML contract accepted by the available eConnect service, invokes the intermediary, tracks correlation identifiers, and handles validation, processing, and posting status as separate outcomes.
Implementation sequence
Microsoft Dynamics GP SQL Server
Dynamics GP stores application data in Microsoft SQL Server. Authorized read access is useful for reporting, extraction, staging, and reconciliation, while direct writes can bypass GP validation, posting logic, and business rules and should be avoided unless explicitly governed.
Martini implementation pattern
Martini implementation pattern: Martini uses JDBC and SQL workflow capabilities to read approved tables or reporting views, applies a persisted high-water mark and reconciliation window, transforms the results, and writes them to a reporting or downstream system.
Implementation sequence
Common Microsoft Dynamics GP integration patterns
Pattern 1: Send e-commerce orders to Microsoft Dynamics GP
When to use this pattern
Use this pattern when Shopify or another commerce application is the order-entry system and GP must create Customers and Sales Orders. It supports validation, enrichment, idempotency, and controlled handling of orders that cannot be created immediately.
Integration direction
Example Mapping
| Microsoft Dynamics GP Field | Canonical Field | Target Field |
|---|---|---|
| order.id | externalOrderId | Sales Order source reference |
| customer.email | customerEmail | Customer email |
| line_items[].sku | itemNumber | Item number |
| line_items[].quantity | orderedQuantity | Sales Order quantity |
Martini implementation pattern
Martini exposes or receives the commerce request, validates customer and item mappings, checks the external order ID before creating a Customer or Sales Order, applies tax and shipping rules, and submits the result through Service Based Architecture, SOAP Web Services, or an eConnect intermediary. Rejected orders are retained with a replayable payload and correlation ID.
Martini capabilities used
- APIs
- workflows
- data mapping
- JSON and XML transformation
- business rules
- idempotency
- error handling
Pattern 2: Synchronize invoices and receivables to Salesforce
When to use this pattern
Use this pattern when Salesforce users need financial status associated with customer accounts, opportunities, or sales activity. Incremental extraction and document-number preservation reduce duplicate updates and support reconciliation.
Integration direction
Example Mapping
| Microsoft Dynamics GP Field | Canonical Field | Target Field |
|---|---|---|
| Customer.Number | customerExternalId | Account GP customer number |
| Sales Invoice.DocumentNumber | invoiceNumber | Invoice reference |
| Sales Invoice.Status | invoiceStatus | Financial status |
| Receivables Transaction.Balance | openBalance | Open receivables balance |
Martini implementation pattern
A scheduled Martini workflow retrieves changed Sales Invoices and Receivables Transactions through a supported GP API or authorized SQL query, filters by company and high-water mark, transforms currency and status values, and updates Salesforce. The workflow records source identifiers, retries transient failures, and sends unresolved records to reconciliation.
Martini capabilities used
- scheduled workflows
- API consumption
- JDBC and SQL access
- incremental extraction
- mapping and transformation
- retry handling
Pattern 3: Synchronize vendors and purchase orders
When to use this pattern
Use this pattern when procurement or finance applications need current GP Vendors and Purchase Orders, or when approved procurement transactions must be sent into GP. It is appropriate for company-specific mappings and approval-state controls.
Integration direction
Example Mapping
| Microsoft Dynamics GP Field | Canonical Field | Target Field |
|---|---|---|
| Vendor.VendorNumber | supplierId | Vendor reference |
| Purchase Order.Number | purchaseOrderNumber | Request or order number |
| Purchase Order.Status | approvalStatus | Approval state |
| Purchase Order.Lines[].ItemNumber | itemNumber | Requested item |
Martini implementation pattern
Martini retrieves changed Vendors and Purchase Orders on a schedule or receives approved ServiceNow requests, applies vendor-number and company mappings, validates line numbering and approval status, and calls the appropriate GP or ServiceNow endpoint. Correlation keys, bounded retries, and status reconciliation prevent duplicate purchasing transactions.
Martini capabilities used
- workflow orchestration
- scheduling
- data mapping
- validation
- business rules
- correlation and retry handling
Pattern 4: Load Microsoft Dynamics GP reporting data
When to use this pattern
Use this pattern for financial reporting, inventory analysis, reconciliation, or migration staging where GP SQL Server is the authoritative source. It favors read-oriented access and avoids direct transactional database writes.
Integration direction
Example Mapping
| Microsoft Dynamics GP Field | Canonical Field | Target Field |
|---|---|---|
| Company.Database | companyCode | Company dimension |
| Sales Invoice.PostingDate | postingDate | Fiscal date |
| Item.ItemNumber | itemId | Product dimension |
| Receivables Transaction.Amount | transactionAmount | Amount |
Martini implementation pattern
A scheduled Martini workflow reads approved GP tables or reporting views through JDBC, applies company and fiscal-period filters, transforms the result into a stable reporting model, and loads a reporting endpoint or staging layer. It persists extraction checkpoints, compares totals against GP reconciliation values, and retries or quarantines failed batches.
Martini capabilities used
- scheduled workflows
- JDBC
- SQL queries
- data transformation
- batch processing
- reconciliation
- monitoring
Applications commonly integrated with Microsoft Dynamics GP
Microsoft Dynamics GP commonly participates in enterprise landscapes where financial, sales, procurement, reporting, and operational data must be exchanged across systems. The appropriate direction and interface depend on the GP company, modules, deployment, and system-of-record rules.
| Application | Scenario | Direction | Martini Pattern |
|---|---|---|---|
| Salesforce | Synchronize customers, sales orders, sales invoices, and receivables information with CRM and sales processes. | Microsoft Dynamics GP → Martini → Salesforce | Martini schedules incremental GP extraction through REST, SOAP, or authorized SQL Server queries, maps GP identifiers and financial statuses to Salesforce objects, and sends approved CRM changes back through a controlled workflow where required. |
| Dynamics 365 Sales | Connect GP financial and fulfillment information with Microsoft CRM accounts, opportunities, and order processes. | Microsoft Dynamics GP → Martini → Dynamics 365 Sales | Martini applies object-level ownership rules, transforms GP Customers, Sales Orders, and Sales Invoices into Dynamics 365 payloads, and routes approved customer or order changes to the appropriate GP interface. |
| Shopify | Send e-commerce customers and orders to GP and return inventory or fulfillment information to the commerce platform. | Shopify → Martini → Microsoft Dynamics GP | A Martini API receives Shopify orders, validates customer and line-item mappings, checks the external order identifier for idempotency, and submits Sales Orders through Service Based Architecture, SOAP Web Services, or an eConnect intermediary. |
| NetSuite | Exchange financial, customer, vendor, or operational data during system consolidation or multi-entity operations. | Microsoft Dynamics GP → Martini → NetSuite | Martini coordinates staged extracts and API writes in both directions, preserves source identifiers, applies company-specific mapping rules, and records reconciliation results for migration or coexistence workflows. |
| Power BI | Provide financial, inventory, sales, and purchasing data for reporting and analysis. | Microsoft Dynamics GP → Martini → Power BI | Martini reads approved GP SQL Server tables or reporting views, converts them into a stable reporting model, applies fiscal-period and company filters, and delivers data to a reporting endpoint or staging layer. |
| ServiceNow | Synchronize vendors, purchase requests, approvals, and financial status with enterprise service-management workflows. | ServiceNow → Martini → Microsoft Dynamics GP | Martini receives approved ServiceNow transactions, validates company and vendor mappings, submits supported GP transactions through an application interface, and returns document numbers and status updates. |
| Azure Logic Apps | Coordinate Azure-hosted orchestration, queues, or intermediary services around GP. | Microsoft Dynamics GP → Martini → Azure Logic Apps | Martini exchanges REST, SOAP, XML, or SQL data with Logic Apps or an intermediary, using explicit ownership boundaries, correlation identifiers, retries, and reconciliation rather than assuming atomic cross-system processing. |
| Workday | Exchange supplier, worker-related finance, or accounting data where GP operates as a downstream finance platform. | Workday → Martini → Microsoft Dynamics GP | Martini transforms approved Workday finance or supplier data into GP-compatible requests, enforces company and accounting rules, and publishes GP document or payment status back to Workday where required. |
How to build a Microsoft Dynamics GP integration in Martini
Objective
Confirm the GP version, deployment topology, enabled interfaces, company access, network path, and service-account permissions before selecting an integration design.
Instructions in Martini
- Select Service Based Architecture, SOAP Web Services, eConnect, SQL Server, or a supported intermediary based on the business process.
- Configure Windows-based credentials, GP permissions, company access, and private connectivity where required.
- Store environment-specific credentials and endpoints in secure configuration rather than workflow logic.
Objective
Choose an event, API request, or schedule that matches the confirmed GP capability and the required synchronization latency.
Instructions in Martini
- Use an API or customer-managed callback when an external event source is available.
- Use a scheduler for polling REST, SOAP, eConnect status, or SQL Server changes.
- Define company context and the persisted high-water mark for each synchronization flow.
Objective
Retrieve the relevant GP object or transaction while preserving source identifiers, company context, and processing metadata.
Instructions in Martini
- Retrieve Customers, Vendors, Items, Sales Orders, Sales Invoices, or Purchase Orders through the supported interface.
- Use approved SQL queries for reporting and extraction scenarios.
- Capture document numbers, source identifiers, response status, and timestamps.
Objective
Coordinate validation, enrichment, target calls, status updates, and failure paths in a maintainable Martini workflow.
Instructions in Martini
- Separate transport failures, authentication failures, GP business errors, and duplicate outcomes.
- Use correlation identifiers across requests and responses.
- Route pending, rejected, and accepted transactions to distinct processing or reconciliation paths.
Objective
Convert GP-specific JSON, XML, SOAP, or SQL structures into a canonical model and target application format.
Instructions in Martini
- Map company-specific identifiers and preserve GP document numbers.
- Transform JSON, XML, dates, currencies, quantities, and status values explicitly.
- Validate required fields before submitting transactional requests.
Objective
Enforce customer, vendor, item, tax, approval, posting, and duplicate-prevention rules before writing data.
Instructions in Martini
- Check external order, invoice, or purchase-order identifiers before creating new GP objects.
- Distinguish document creation from validation, posting, and settlement.
- Apply target-specific ownership and company mapping rules.
Common Microsoft Dynamics GP data objects used in integrations
| Object | Typical Use | Common target systems | Martini handling |
|---|---|---|---|
| Customer | Synchronize customer master data, account identifiers, addresses, credit information, and downstream financial status. | Salesforce, Dynamics 365 Sales, Shopify, NetSuite | Martini maps company-specific identifiers to a canonical customer model, validates required fields, and uses existence checks to prevent duplicates. |
| Vendor | Exchange supplier master data, payment details, status, and procurement relationships. | Workday, ServiceNow, NetSuite, procurement applications | Martini preserves vendor numbers, applies company mappings, protects sensitive fields, and routes approved changes through supported GP interfaces. |
| Item | Synchronize product, inventory, pricing, and item identifiers with operational or commerce systems. | Shopify, Power BI, NetSuite, data warehouses | Martini normalizes units, item identifiers, and company context, then applies validation and controlled update rules. |
| Sales Order | Transfer commerce or CRM orders into GP and communicate order status downstream. | Shopify, Salesforce, Dynamics 365 Sales | Martini validates customer and line-item mappings, applies tax and shipping rules, records the external order ID, and submits through REST, SOAP, or eConnect. |
| Sales Invoice | Publish invoicing, payment, and financial status to CRM, reporting, or downstream finance systems. | Salesforce, Dynamics 365 Sales, Power BI, NetSuite | Martini extracts invoices incrementally, maps status and currency, preserves GP document numbers, and supports reconciliation. |
| Purchase Order | Synchronize approved purchasing commitments with procurement and finance processes. | ServiceNow, NetSuite, Workday, reporting systems | Martini maps vendor numbers, approval status, line numbering, and company context, with retries that distinguish unknown outcomes from confirmed rejection. |
Authentication and security considerations
Authentication and security
Dynamics GP authentication depends on the interface and deployment. Windows authentication, Active Directory accounts, service accounts, GP security roles, company permissions, and sometimes SQL Server authentication are common in on-premises environments.
- Use least-privilege service accounts and restrict access to required GP companies and operations.
- Prefer private connectivity, secure gateways, or reverse proxies over exposing GP services directly to the public internet.
- Store credentials and endpoint configuration in secure Martini environment configuration.
- Do not assume OAuth 2.0 or API-key authentication for core GP Web Services or eConnect.
Operational considerations for Microsoft Dynamics GP integrations
Operational considerations
GP throughput is constrained by application processing, SQL Server capacity, locking, posting behavior, network latency, and concurrent users rather than one universal cloud rate limit.
- Use controlled concurrency, bounded retries, and appropriate batch sizes.
- Persist company context, high-water marks, document numbers, and external correlation keys.
- Handle pagination and filtering according to the selected REST, SOAP, or SQL interface.
- Distinguish accepted, created, validated, posted, and settled states.
- Test against the target GP version, modules, customizations, and company configuration before production deployment.
- Monitor schema changes, SQL view changes, endpoint changes, late-arriving updates, and reconciliation totals.
Why use Martini instead of scripts or point-to-point integrations?
Maintainable integration orchestration
Scripts and point-to-point integrations often duplicate authentication, mapping, retry, logging, and company-context logic. Martini provides a workflow-based place to orchestrate GP APIs, eConnect intermediaries, SQL Server reads, and downstream systems.
- Centralize transformations between GP-specific JSON, XML, SOAP, SQL, and canonical models.
- Expose controlled APIs that shield external applications from GP endpoint and deployment details.
- Reuse validation, business rules, correlation, retry, and reconciliation patterns.
- Support scheduled, API-led, batch, and intermediary-driven event flows without bypassing GP application rules.
- Improve operational visibility through workflow logging, monitoring, and replay-oriented error handling.
Frequently asked questions
Microsoft Dynamics GP can be integrated through Service Based Architecture REST endpoints, GP SOAP Web Services, eConnect XML transactions, and authorized SQL Server access. REST and SOAP are appropriate for supported application operations, eConnect is useful for structured transactions, and SQL Server is generally better suited to reporting, extraction, staging, and reconciliation than direct transactional writes.
Yes. Martini can consume Dynamics GP REST endpoints and SOAP Web Services, invoke an eConnect-based intermediary, and read authorized SQL Server data through JDBC. It can orchestrate workflows, transform JSON and XML, expose APIs, and apply company, validation, retry, and reconciliation rules.
No. A dedicated Microsoft Dynamics GP connector is not required. Martini can use the GP integration mechanisms available in the customer environment, including REST, SOAP, eConnect intermediaries, SQL Server access, and callbacks from customer-managed infrastructure.
Lonti does not charge an additional per-connector or per-vendor fee to integrate Microsoft Dynamics GP. Integrations are subject to the provisioned capacity of the Martini environment. Separate costs may apply from Microsoft, infrastructure providers, or other third-party systems depending on licensing, usage, and deployment model.
Use Service Based Architecture REST endpoints for supported resource-oriented operations, SOAP Web Services where the customer already operates GP Web Services or requires SOAP operations, and eConnect for established XML transaction processes. Use SQL Server primarily for reporting, extraction, reconciliation, and controlled read-oriented scenarios. The GP version and installed components determine what is available.
A general-purpose native GP webhook model covering business objects was not confirmed. Event-driven behavior can be implemented through a customer-managed intermediary that publishes GP changes to Martini. Otherwise, Martini can use scheduled polling, API filters, SQL change detection, or reconciliation windows.
Martini can run scheduled or API-triggered workflows that retrieve changed GP objects, maintain a company-specific high-water mark, map data to a canonical model, and write to downstream systems. Stable identifiers, document numbers, reconciliation windows, and explicit status handling help manage late changes and duplicate prevention.
Martini can separate transport, authentication, SOAP fault, schema, GP business-validation, SQL, and duplicate-document errors. Workflows can use correlation keys, bounded retries, persisted payload references, and reconciliation states so a timeout after GP acceptance is not incorrectly retried as a new transaction.
Related Martini documentation
Plan your Microsoft Dynamics GP integration
Assess your GP version, enabled interfaces, company structure, security model, and target business processes, then design a Martini workflow around the supported integration path.