ml-connector
Microsoft Dynamics GPDatabricks

Microsoft Dynamics GP and Databricks integration

Microsoft Dynamics GP holds your financial data on-premises: vendors, payables invoices, GL accounts, and journal entries. Databricks is your cloud data warehouse. Connecting the two lets you build a unified finance data lake, run analytics across ERP and non-ERP sources without manual exports, and keep your warehouse in sync with every posting cycle. ml-connector handles the translation between GP's on-premises architecture and Databricks' cloud APIs, so your finance team can focus on insights.

How Microsoft Dynamics GP works

Microsoft Dynamics GP is an on-premises ERP for SMBs covering financials, payables, receivables, purchasing, and inventory. It exposes GL accounts, GL journal entries, vendors, payables invoices, purchase orders, and customers through REST Service Based Architecture (SBA, available in GP 2015+) at https://<server>:<port>/GPService/Tenants(<TenantName>)/Companies(<CompanyName>)/<Module>/<Resource>, or through SOAP Web Services (GP 2010+). Authentication uses Windows domain credentials tied to Active Directory; there is no OAuth2 or API key option. Data is read via polling with ModifiedDate filters; GP does not support webhooks or push notifications. Company names are actual SQL Server database names. Posted transactions are read-only; only unposted Work transactions can be modified.

How Databricks works

Databricks is a cloud data platform built on Apache Spark and Delta Lake, typically used as a data warehouse or transformation layer. It exposes clusters, jobs, SQL warehouses, catalogs, schemas, and tables through REST APIs at https://<workspace-id>.cloud.databricks.com/api/2.0/ (or Azure/GCP variants) with workspace-specific URLs. Authentication uses OAuth 2.0 Client Credentials via Service Principal with client_id and client_secret; bearer tokens expire every 3600 seconds. Databricks does not expose native finance or ERP objects like invoices or GL accounts; instead it is a data destination where ERP records are modeled as tables. Outbound webhooks exist only for MLflow Model Registry events, not for data or compute events, so polling or external trigger patterns are required. Table data writes happen via SQL or Spark; REST calls are metadata-only.

What moves between them

Financial records flow one direction: from Microsoft Dynamics GP into Databricks. ml-connector polls GL accounts, GL journal entries, vendors, payables invoices, and purchase orders from GP on a cadence you set (typically daily or per-posting-cycle), applies any field mappings (such as GL account numbers to cost centers), and writes rows into Databricks as Delta tables. Reference data such as vendors and GL account master records are replicated first so dimension keys exist before fact loads. Databricks tables are append-only or merge-on-key, depending on your change-data-capture strategy; updated records in GP (vendor address changes, GL account reclassifications) can be upserted into Databricks via the same job.

How ml-connector handles it

ml-connector stores GP credentials as a dedicated Windows domain account created by your IT team and scoped to a specific GP company database. On each poll cycle, it connects to the SBA or SOAP endpoint, filters records by ModifiedDate if available or by status, and transforms the response. GP's SBA requires request bodies to be wrapped in a top-level Payload key: ml-connector handles this automatically. For Databricks, ml-connector obtains an OAuth 2.0 access token once per schedule run (caching it for the 3600-second lifetime), then uses the token to call the REST catalog and SQL warehouse endpoints to append or upsert records into the target schema and tables. Because GP is pull-only and Databricks tokens expire, ml-connector implements exponential backoff for transient failures and re-queues jobs that fail midway through a table write. Vendor IDs and GL account numbers become the merge keys in Databricks, aligning with your chart of accounts. A full audit trail tracks which records arrived from which GP posting date, so month-end reconciliation can trace a Databricks balance back to the original GL entry.

A real-world example

A mid-market wholesale distributor runs Microsoft Dynamics GP for AP, AR, purchasing, and GL across three distribution centers. Their finance team needs to build a consolidated view of margin by vendor and product category, but GP reporting is limited to single-company extracts. They deploy Databricks as a data lake, connecting it to GP via ml-connector to ingest vendors, invoices, and GL postings every business day. Once the ERP data lands in Databricks, they join it with external product catalogs and pricing feeds, then build dashboards showing vendor performance and margin trends. Previously, an analyst manually exported AP registers and GL trial balances weekly and stitched them in a spreadsheet; now the data arrives automatically and updates are available within hours of posting.

What you can do

  • Replicate GL accounts, GL journal entries, vendors, and payables invoices from Microsoft Dynamics GP into Databricks Delta tables on a schedule you control.
  • Bridge Windows Authentication on the GP side to OAuth 2.0 Client Credentials on Databricks, handling token refresh and SBA Payload-wrapped requests automatically.
  • Poll GP with ModifiedDate filters to extract only changed records, reducing load on your on-premises system and cloud API quota.
  • Merge vendor and GL account updates into Databricks using natural keys, so dimension changes flow without duplicating history.
  • Maintain a full audit trail of every record's source posting date and sync timestamp, enabling month-end reconciliation and replay of failed loads.

Questions

Does ml-connector handle GP's Windows Authentication requirement?
Yes. ml-connector stores a dedicated Windows domain account (created by your IT team) and uses it to authenticate to the GP SBA or SOAP endpoint via Negotiate or NTLM. Databricks is authenticated separately via OAuth 2.0 Client Credentials, so ml-connector bridges the two auth models without exposing credentials.
What if Microsoft Dynamics GP is behind a firewall?
Your network team must expose the GP SBA or SOAP endpoint through the firewall with a valid SSL certificate, or deploy ml-connector's optional local polling agent inside your network. ml-connector then calls the endpoint remotely and pushes data to Databricks in the cloud. Confirm with your IT team that the SBA endpoint is installed (many GP instances run SOAP-only).
Can ml-connector keep Databricks in sync with real-time GL postings?
No. GP does not support webhooks or push notifications, so ml-connector polls on a schedule (daily, every few hours, or per-posting-cycle). For real-time analytics, use Databricks' scheduled SQL jobs to refresh aggregations hourly or on-demand. Audit records include the exact GP posting timestamp, so you can trace any Databricks balance back to the source GL entry.

Related integrations

Connect Microsoft Dynamics GP and Databricks

Free to use. Add your credentials, ping your real systems, and see if we fit.

Get started