How to integrate with Dynamics 365 Finance and Operations Part -3

 

7️⃣ Bring Your Own Database (BYOD)

Let's you export D365 FO data to your own Azure SQL database.

BYOD allows you to export entity data to a user created SQL Server database instead of the Entity store AXDW, which is currently not allowed to be accessed by end users in production environments. Using BYOD you can export D365FO data entities to your database manually or with batch update or change tracking options using the standard DMF export projects page. To start using BYOD, you need to configure your SQL Server database in the “Data management” workspace “Configure Entity export to database” tile:

Then you can use the Publish button to create SQL tables for selected data entities in the target database. After these steps are completed, you can export the data to your SQL database using DMF export jobs and selecting your BYOD SQL Database from the list as a target.

✅ Key Features of BYOD:

1. Custom Reporting:

   • Use tools like Power BI, SSRS, Excel, or third-party apps to run reports directly on exported data.

2. Azure SQL Support:

   • Exported data lands in a customer-provisioned Azure SQL Database, enabling flexible access.

3. Data Entities:

   • Uses data entities to define the structure and scope of the data being exported.

4. Incremental Push:

   • Supports full or incremental data push, minimizing data transfer and improving performance.

5. Scheduled or Manual Exports:

   • Data exports can be triggered manually or on a schedule using batch jobs.

🛠️ How to Configure BYOD:

1. Provision Azure SQL Database

   • Create a SQL Database in Azure (with appropriate firewall and access configurations).

2. Register Database in D365FO

   • Go to Data Management > Bring your own database.

   • Register and validate your Azure SQL connection.

3. Publish Data Entities

   • Choose the data entities you wish to export and publish them to the registered BYOD.

4. Export Projects

   • Create and configure data export projects to schedule exports to BYOD.

🔐 Security and Access:

• Use read-only access to the BYOD database for reporting purposes.

• Be cautious with sensitive or PII data—ensure your access model complies with your organisation's security policies.

⚠️ Limitations and Considerations:

• No automatic schema updates: If you update a data entity in D365FO, you must republish it to BYOD.

• BYOD is read-only; no reverse synchronisation to D365FO.

• Does not support all entities (especially non-persisted or virtual entities).

• Consider Export to Data Lake a modern alternative for large datasets or near-real-time scenarios.

• Use case: Full control over data for downstream apps or reporting.

• Setup: Define entities to export via the data management framework.

✅ Ideal for complex BI environments or legacy system syncs.

More info: https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/analytics/export-entities-to-your-own-database

8️⃣ Azure Data Lake

With the Export to Data Lake feature, D365 FO continuously exports data entities to Azure Data Lake Gen2.

A feature still in public preview, Azure data lake publishing provides a more practical, cheaper and faster storage option for your big analytical and integration databases, which you used to access using Entity store or BYOD options before. It can publish data from entity store, data entities and standard FO tables to a “Data Lake Storage Gen2” storage, in a “near real-time” speed using the new D365FO “Data feed service”. This new data feed service works faster and saves you the hassle of maintaining DMF export jobs and batches.

Publishing your data into a data lake storage brings many benefits. It costs much less to store data in a Data Lake compared to a SQL Server data space in Azure. Plus data lake allows you to combine your FO data with data from other applications, and also CDS inside the same data lake space and run consolidated reports with them. Data lake supports Common Data Model folder structure, which can be understood by many Cloud applications and services, and it is also possible to move the data from and to CDS using CDS Data lake integrations. Usage of Azure data transformation tools like Azure Data Factory is also possible.

All in all, it brings you a couple of steps closer to Azure cloud integration and provides you with the future-proof “near-real-time” data synchronisation.

At the time of writing, Azure data lake options are still in public preview and need to be enabled from the D365FO “Feature management” window first. Then you will be able to choose tables to be published to the data lake from the “Export to Data Lake” form and push the Entity Store to the Azure data lake from the Entity Store window:

✅ Advantages of Azure Data Lake with D365FO

Advantage	Description
Near Real-Time Data Export	Automatically syncs entity data to Data Lake with minimal delay—ideal for up-to-date reporting.
No Need to Republish Entities	Unlike BYOD, you don’t need to republish when the data model changes—auto-handled by the platform.
Scalable Storage	Can handle petabytes of data efficiently; no size restrictions.
Open Data Format	Stores data in open formats (CSV/Parquet), which are supported by most analytics tools.
Advanced Analytics Ready	Easily connects with tools like Power BI, Azure Synapse, Databricks, and Azure ML.
Better Performance	Offloads heavy reporting from the D365FO database, improving overall performance.
Secure & Compliant	Uses Azure security, RBAC, and encryption; suitable for enterprise-grade deployments.

❌ Disadvantages of Azure Data Lake with D365FO

Disadvantage	Description
Read-Only Data	You cannot write back to D365FO—one-way export only.
Initial Setup Complexity	Requires coordination between the D365FO team and the Azure team (security, firewall, permissions).
Azure Knowledge Required	You need a basic understanding of Azure Storage, IAM, Synapse, etc., for effective usage.
No Ad-Hoc SQL Queries	Unlike BYOD (Azure SQL DB), you can’t directly query using SSMS or ad-hoc SQL.
First-Time Sync Delay	Initial sync of large volumes can take time, especially in Production environments.
Custom Entity Support Limited (Initially)	Only selected entities are available out-of-the-box; custom entities require extra setup or a workaround.

• Use case: Big data analytics, integration with Synapse or custom data lakes.

• Architecture: Fully managed and scalable.

✅ Best for enterprise-scale analytics and centralised data platforms.

More info: https://docs.microsoft.com/en-us/dynamics365/fin-ops-core/dev-itpro/data-entities/azure-data-lake-overview

9️⃣ Dual Write

A near-real-time bi-directional sync between D365 FO and Dataverse (Power Platform).

Dual-write is a real-time, bi-directional integration between Dynamics 365 Finance and Operations (D365FO) and Dataverse (Power Platform + CE apps like Sales, Customer Service, etc.).

It provides seamless data synchronisation so that records created or updated in one app (e.g., FO) automatically reflect in the other (e.g., CE), and vice versa, without the need for custom integrations or data sync jobs.

🧩 Key Concepts

Feature	Description
Entity Mapping	Maps D365FO tables (data entities) with Dataverse tables (entities).
Real-time Sync	Updates flow instantly between systems.
Out-of-the-box Templates	Microsoft provides prebuilt mappings for common entities (Customer, Vendor, Product, etc.).
Custom Entity Support	You can define custom mappings for custom tables/entities.
Power Platform Integration	Enables usage of Power Apps, Power Automate, AI Builder with FO data.

✅ Advantages of Dual-write

Advantage	Description
Real-time Data Flow	Any change in D365FO or Dataverse reflects instantly in the other system.
No Need for Manual Integration	Eliminates need for custom middleware or ETL tools between CE and FO.
Unified User Experience	Sales, Finance, and Operations users work with one version of truth.
Tight Integration with Power Platform	Use FO data in Power Apps, Power Automate, AI Builder, etc.
Prebuilt Templates	Microsoft provides more than 30 ready-to-use mappings to speed up setup.
Custom Mappings	Supports extensibility for ISVs and partners.
Error Handling UI	Errors are logged with detailed traceability in the UI with retries and fixes.

❌ Disadvantages of Dual-write

Disadvantage	Description
Initial Setup is Complex	Requires careful setup and validation, especially in large or customised implementations.
Performance Overhead	Real-time sync can cause latency or impact performance if not managed properly.
Customization Conflicts	Customisations in FO or CE can break mappings or cause sync issues.
Tightly Coupled Systems	High dependency between FO and Dataverse can become a risk during updates or outages.
Monitoring and Maintenance	Requires regular monitoring, handling sync failures, and managing error logs.
Limited Offline Capability	Dual-write only works when both systems are online and reachable.

🏗️ Typical Use Cases

• Sales to Cash Integration
  Customer data entered in Dynamics 365 Sales (CE) syncs with D365FO for invoicing and fulfilment.

• Product Sync
  Products created in FO are synced to CE so sales reps can quote and sell accurately.

• Vendor Management
  Vendors created in CE (via Power Apps) get synced to FO for procurement processes.

• Use case: Sync customers, orders, vendors, etc., with Power Apps or D365 CE.

• Setup: Prebuilt mappings and extensible framework.

✅ Great for connected apps, low-code solutions, and seamless FO + CE experiences.

More info: https://docs.microsoft.com/en-nz/dynamics365/fin-ops-core/dev-itpro/data-entities/dual-write/dual-write-home-page

🔟 Consuming External Web Services (from X++)

D365 FO can consume external API's directly via X++.

🔍 Overview

D365FO supports integration with external systems via HTTP-based web services (REST/SOAP). As a technical consultant, you often need to call third-party APIs for real-time data exchange like:

• Fetching exchange rates

• Sending invoice data to an external system

• Validating GST/TIN

• Sending SMS or email notifications

This article explains how to consume external REST/SOAP web services from X++ using System.Net.HttpWebRequest, System.Net.HttpClient, or a custom .NET class wrapper in D365FO.

🔐 Security Considerations

• D365FO runs in sandboxed environments, so HTTP calls are allowed only from batch or async operations.

• Use Azure Key Vault to store API keys or secrets securely.

• Use Sys.Net.HttpClient only in trusted and controlled scenarios.

• Avoid direct synchronous API calls in forms or synchronous processes.

🛠️ Common Use Cases

Use Case	API Type	Call Type
Get weather data	REST	GET
Validate GSTIN/PAN	REST	POST
Send SMS via Twilio	REST	POST
Fetch stock prices	REST	GET
Submit Invoice to Tax Portal	SOAP	POST

🚧 Best Practices

• Use Batch Jobs or SysOperation Framework for calling external APIs.

• Log responses for traceability in a custom log table.

• Implement retry logic for transient failures.

• Use Sys.Net.HttpClientFactory if you're managing many connections.

📝 Summary

Feature	REST (HttpClient)	SOAP (Service Ref)	.NET DLL
Ease of Use	✅ Easy	⚠️ Moderate	✅ Flexible
Real-time	✅ Yes	✅ Yes	✅ Yes
Reuse Logic	⚠️ Low	⚠️ Medium	✅ High
OAuth/JWT Support	✅ Yes (custom headers)	❌ Manual	✅ Excellent

• Class used: System.Net.HttpClient, CLRObject, etc.

• Use case: Call a shipping API to get tracking info, or sync the external catalogue.

✅ Enables integration with external REST/SOAP services from within D365 FO.

✅ Final Thoughts

D365 FO offers integration options for every need — real-time APIs, bulk syncs, event-driven messaging, and analytics.