API
Is there an API-first alternative for Dual Write?
This is a question which has been bugging me for the last 3 years..
Every time I read a Technet article about D365 SCM or D365 CE being the price master (example), I catch myself thinking halfway:
“Really? Isn’t there an easier way?”
Here’s what we’re doing today:
- 1️⃣ The process (e.g. quote-to-order) runs in system A – D365 CE
- 2️⃣ System A asks system B – D365 SCM to recalculate pricing
- 3️⃣ The recalculation happens in B
- 4️⃣ System B syncs the data back to A
- 5️⃣ The process continues… hopefully
But what if something fails halfway?
⚠️ What if the recalculation (step 3) throws an error?
⚠️ Or the data sync (step 4) doesn’t bring back all price components — discounts, attribute pricing, shipping charges, minimum-order fees, overrides?
Couldn’t we do this faster, cleaner, and more reliably?
✅ My suggestion: API-first.
Let CE call SCM’s pricing engine directly in real time — no sync, no waiting, no partial data. You get a single, complete response containing every price component.Instant feedback, fewer moving parts, and a process that never pauses “mid-flow.”. But that’s theory? Can it work in reality?
An API-First Approach
Let’s explore the approach: there’s no data sync between D365 CE and D365 ERP. Instead, quote or order lines in CE are sent to an API endpoint that returns a detailed pricing breakdown — typically within 500–750 ms ⚡.
CE can trigger this in multiple ways:
- as an in-process (underwater) flow, automatically invoked when a quote line is added, updated, or deleted,
- or more explicitly via a JavaScript-enabled “Recalculate Pricing” button.
But the real question is… 👉 What’s behind that API endpoint?
D365 SCM OData and custom APIs aren’t known for stable, high-volume performance. They work fine for batch integrations, but for consistent real-time request/response patterns, they often fall short. There are many reasons — complex data models, non-optimized joins, limited caching — but the bottom line is: ⚠️ it’s very hard to make them truly performant consistently, especially under high volume.
By contrast, the D365 Commerce APIs are built for speed and consistency. They’re optimized for high-frequency scenarios like online cart operations and POS transactions, where performance must be predictable.
Even better: the Commerce Cart APIs support both the existing SCM pricing engine and the new Unified Pricing model — built on the same Commerce pricing foundation, now enhanced with attribute-based pricing.
SCM and Unified Pricing API for Quote to Order
So, to explore the options, I decided to develop a single API endpoint, implemented via an Azure Logic App, which wraps several existing D365 Commerce APIs into one cohesive call.
- Create Cart
- Add Cart Line
- <Placeholder for adding shipping address and mode of delivery in the future>
- Delete Cart
The API requires a very simple request body:
But it returns full pricing, including gross pricng, net pricing, shipping charges, minimum order fee, taxes, customers discounts, attribute based discounts etc. – Just a snippet:
No data sync. No duplication of logic. Just a question and a fast, detailed answer — so the Quote-to-Order process can simply continue. ✅ No process breaks. ✅ No endless loading spinners.
But wait… doesn’t Commerce require a Channel and an OUN (Operating Unit Number) to function? Can it really work with just a customer and quote lines as input? 🤔
How to “hide” the Commerce channel concept for Dataverse
By implementing a very simple Default flag on the channel in the Customer hierarchy form in D365 SCM, we can relate a B2B customer to 1 default channel in D365 SCM:
We can then accept the B2B customer as header parameter in the request from Dataverse, as opposed to the OUN (=Commerce channel):
Benefits
In my view, this API-first approach offers significant advantages over Dual Write, especially for the “Better Together” stories between D365 Dataverse (CE, Sales, Field Service, IOM, etc.) and D365 SCM — where large data volumes and complex business logic come into play.
If you’d ever count how many data entities need to sync through Dual Write just to make advanced pricing details flow between the two ecosystems… you’d quickly see how fragile and maintenance-heavy that becomes.
To make it concrete, the table below summarizes the most relevant benefits of API-first vs. Dual Write for this scenario 👇
Further optimization
The Logic App which I pragmatically built for my prototype is a so called Composite API: it wraps multiple standard Commerce APIs into 1 end point. There are platforms which do this wrappin more efficiently at run time than a Logic App. An example is FastAPI.
Another optimization would be to implement api-key authorization between Dataverse and D365 SCM. The ideal platform for this is Azure API Management. APIM can abstract Commerce CSU App or Customer based authorization and work securely with api-key towards Dataverse for simplification (which is easier to implement between the systems).
If you’re interested in this API-first approach, feel free to send me a dm on info@365connect.tech. We are specialised in API development and integration between D365 SCM, Dataverse, Commerce and 3rd party systems.
D365 Commerce + IOM = SUPERPOWER!
Microsoft Intelligent Order Management (IOM) is a powerful solution for effectively orchestrating Order Fulfillment scenarios.
D365 Commerce is D365 Finance & Operations plus the Headless commerce engine with more than 400+ Commerce APIs and a local database which is installed on a separate Retail Cloud Scale Unit.
The combination of IOM + D365 Commerce offers next level capabilities for any Retail Enterprise 🚀.
In below video I’ll demonstrate an integrated scenario in which Orders from an E-commerce platform are orchestrated in IOM and fulfilled via D365 Commerce.
D365 F&O/Commerce interfacing via Azure API Management: My Best Practices
I am seeing more and more customers and partners who actively promote the use of Azure API Management for D365 F&O backend and/or D365 Commerce Scale Unit ODATA interfacing. See for example, this blog post by Adrià Ariste Santacreu. However, there’s still a significant number of customers and partners who shrug their shoulders while thinking: “Why would we use it when we can interface ‘directly’?”. In this blog post I’ll address this question by sharing my best personal best practices in using Azure API Management for D365 F&O backend and/or D365 Commerce Scale Unit ODATA interfacing. But before sharing the best practices, we first have to explode the myth that interfacing via Azure API Management (APIM) would not be DIRECT.. 😉.
D365 Retail APIs Part III: How to use the Retail APIs from Power Automate (Flow) and Logic App
After walking through the overall D365 Retail API Architecture in part I and II of this series on the D365 Retail APIs, it’s now time to enable anyone to actually use the Retail APIs. To allow this, this blog post will contain all details on how to construct a request to most of the 400 out-of-box D365 Retail APIs – Beyond that, I’ve included a step-by-step instruction on how to use any of the Retail APIs from Microsoft Power Automate (Flow).
But before we can really get things rolling, we first need to apply some additional D365 setup and we need to choose the right security pattern. So that’s where I’ll start this blog post.
Note: to effectively consume the content of this blog post, please ensure to familiarise with the content of Part I and Part II.
The Power of the D365 Retail APIs/CRT – Part I: The Basics
Did you know that D365 for Retail contains more than 400 out-of-box Retail APIs (for the non-techies: interfaces) ranging from Loyalty management, Gift card management, Omni order management to Stock counting and Retail Logistics? These interfaces allow you to easily integrate with any 3rd party systems like e-commerce platforms, POS systems and Consumer Apps. It also allows you to quickly enrich your Retail Solution with handy Power Apps, for example for in-store Goods receipt, Stock counting, Labelling or Clienteling.
Unfortunately I still notice that many Customers and Partners do not consider the Retail APIs in their designs, which goes around all the ‘free’ Retail Business Logic which comes with them. Instead, Customers and Partners start a custom coding exercise (re-inventing the wheel!) which often limits rather than empowers the Omni-channel capabilities of D365.
This is all mainly caused by the lack of documentation – It’s time to change that! In this series of blog posts we’ll explore the Power of the Retail API’s so we can all benefit from them by using them to enhance the Retail experience for the Retail Businesses we serve. As we need the non-techies on this journey, I’ll try to make it understandable for all of us. Making the right Architectural decisions starts with a good understanding of the solution. So let’s dive into that first!
1 – D365 Retail API Architecture explained
D365 Retail comes with 3 major components – Below description is a little bit technical, but it’s good to keep these components in mind for a better understanding of the main picture (picture 1) below:
Let’s go through each element in the picture, step-by-step:
- The Letter. An app (e.g. a POS system, e-commerce platform or Power App) can send a request to 1 of the 400+ D365 Retail end points. This request can be to Request information such as the loyalty balance of a customer or to Send information.
- The public Mailbox. Metaphorically you can compare this request with a letter which is dropped into a mailbox. The mailbox in this case is the ODATA end point of Retail Server (1A). It’s a public mailbox, so any App can drop letters in there. But there are 2 prerequisites which need to be met to allow this: the App needs to be a registered ‘member’ in the Receiver’s domain and the App must have received a pre-authorisation code (token) which needs to be sent with the letter.
- The Internal Mailbox. Once successfully received in the public (ODATA) Retail Server mailbox, the letter (request) is forwarded to an internal mailbox: a specific Commerce Run Time (CRT) operation (1B). This CRT operation is responsible for processing the letter. In order to get this done, the CRT operation contacts 1 or multiple Retail Services (1C).
- Processing of the letter. The Retail Services work with subcontractors. There are 2 types of subcontractors: Data services which can read/write information from/to the local Retail Database or Remote Data services which can receive/send information from/to the D365 backend. The Retail Services have been instructed (programmed) to contact either of the subcontractors or both subcontractors to process a certain letter (request). For example, a letter to update the Loyalty Balance for a customer is forwarded to the D365 backend (since other Apps should work against the latest balance) whereas a new customer is created both in the local Retail Database and forwarded to the D365 Backend. In some case the Retail Service has to read specific parameter settings first to determine which subcontractor to forward the work to. These parameters have been set in D365 backend but are locally available for the Retail Services after sync to the local Retail Database. For example, a parameter which controls whether e-com orders are created into the local Retail database (and from there synched to D365 backend in bulk) or whether these orders are forwarded to the D365 backend in real time.
- Another Public mailbox. Remote Data Service ‘Subcontractors’ will drop the original letter in the Public mailbox of the D365 Backend: a SOAP mailbox, often referred to as Real Time Service (2A). This mailbox has a trust relationship with the Remote Data Service ‘subcontractor’ which is confirmed by a certificate.
- Another Internal mailbox. Very much similar to the way Retail Server is organized, the agent looking after the Real Time Service mailbox, forwards the letter to an internal mailbox for processing: the RetailTransactionService class in the D365 Backend (2B). From there, Retail Services in the D365 backend take care of the actual processing which ties into many standard D365 (Retail) classes packed with Business Logic (2C and 2D). For example in case of customer creation, these services will include the customer in the address book of the Retail channel, assign Retail affiliations and Customer attributes. In other words: even though not all this information was part of the original letter, the Retail Services ensure the letter is processed in line with D365 (Retail) Parameters settings and Retail Business Logic.
- Response. As a sender of a letter, you’d love to get a response on your respect, right? This is organized as follows: whenever an exception occurs somewhere across the chain of ‘middlemen’ subcontractors as described above, the exception is written into a response letter which is returned to the sender (the App) following the chain in reverse order. If no exceptions occur, the original letter will reach it’s final destination. There, a response letter is written which is an in-depth response on the actual request, for example a response letter full of information on a newly created customer. Similar to what happens in case of an exception, the response letter is returned to sender following the chain in reverse order.
2. Teaser
In below video I am trying to illustrate how powerful the Retail APIs can be. In the video, I am using Microsoft Forms (an Office 365 App) to capture information as part of an imaginary Customer Sign up process. Power Automate picks up the information and forwards it to D365 Retail Server to create the customer in the D365 backend in real time. As you will see in the video, the standard D365 Retail Business logic is fully utilized here as if the customer was captured on D365 MPOS: for example, the new customer is automatically included in the Retail channel’s address book.
3. The potential
The left Table below provides a break down of the Retail areas the 400+ Retail APIs apply to. A significant number of these APIs are built to provide real time data exchange with the D365 backend. The right table below presents the Retail areas for which real time connectivity to the D365 backend is supported.
Looking at the functional breadth of the Retail APIs and the video in this blog post, I hope you’re inspired to think about all the opportunities provided by the D365 Retail APIs. In upcoming blog posts on this topic, we’ll make deeper dives into the various aspects of these Retail APIs so we can all use this knowledge to further enrich the D365 Retail experience for our customers.
1yr with AX7 Data Management – My top 12 learnings
We’re so used to the speed of current evolvements around Microsoft Dynamics AX (or should I say Dynamics 365 ;-)), that most of us who are interested in integrations have familiarized themselves for long with concepts like data entities and entity stores. In this blog post, I would like to go beyond the ‘obvious’ by sharing 1 year of personal project experience in working with AX7 Data Management.
To enable you to quickly scan this blog post according to your own points of interest, I have listed my experiences in a top 10-alike pattern in random order.