From Chaos to Clarity: A Supply Chain Response App with Fabric's SQL Database
Supply chains break in ways that rarely announce themselves in advance. A supplier goes dark, a shipment stalls at a border, a single component runs low in a warehouse halfway across the world — and suddenly a business is scrambling to figure out what's actually happening and what to do about it. The businesses that recover fastest aren't the ones with the fewest disruptions; they're the ones who can see the problem the moment it appears. That's the premise behind a hands-on project I've been working through: building a Supply Chain Disruption Response App entirely inside Microsoft Fabric, using its native SQL database capability. No separate database server to provision, no disconnected BI layer bolted on afterward — just one unified platform taking raw supplier and warehouse data and turning it into something a team can actually act on. It's a big enough build that I'm splitting it into a short series. This first post covers the full data foundation — standing up the workspace and database, loading and shaping the data, layering analytical views on the SQL analytics endpoint, and turning it all into a live Power BI report. Later posts will pick up from here and cover notebooks, DevOps, a GraphQL API, and finally a real web application. Here's how the foundation came together, and what stood out along the way. Starting with a Workspace, Not a Server The first thing that struck me about Fabric is how little "infrastructure thinking" it requires. There's no spinning up a VM, no configuring a database engine from scratch. Everything begins with a workspace — essentially a shared home for every item in the project: databases, pipelines, notebooks, and reports all live side by side. Setting one up is a matter of naming it, attaching it to a Fabric capacity, and deciding on a semantic model storage format. Ten minutes in, I had a dedicated space — Supply Chain Analytics Workspace — ready to hold the entire project without a single line of provisioning script. Spinning Up the Database From there, creating the actual SQL database is almost anticlimactic in its simplicity: a name, a click, and Fabric provisions a fully managed SQL database behind the scenes. I called mine supply_chain_analytics_database, and within moments it was ready to accept data. Fabric even ships with sample retail data (the familiar SalesLT schema — customers, products, orders) that loads in with one click. It's a small touch, but it meant I could start writing real queries immediately instead of wrestling with seed data. Teaching the Database to Think About Supply Chains Sample sales data is useful, but it doesn't know anything about supply chains. So the next step was to give the database a vocabulary for the problem at hand: a dedicated SupplyChain schema, and inside it, a Warehouse table modeling the essentials — which product ties to which component, which supplier provides it, where that supplier is located, and how much stock is currently on hand. Rather than hand-typing rows, I populated the table directly from the existing product catalog, using T-SQL to generate plausible component, supplier, and location IDs on the fly. In a few lines of script, the database went from "generic retail demo" to "a working model of a multi-tier supply network" — the exact structure you'd need to trace a disruption back to its source. One small but genuinely useful discovery here: Fabric's query editor has a Copilot-style assist built in. Typing a plain-English comment like "show the total number of customers" and pressing Tab generates the T-SQL for you — and there's an "Explain query" option that annotates existing code step by step. For anyone who's ever inherited a gnarly SQL script with zero comments, this alone is worth the price of admission. Bringing in the Outside World Real supply chains don't live in one database — they're distributed across vendors, partners, and legacy systems that were never designed to talk to each other. To simulate that, I used a Fabric Data Pipeline with a Dataflow Gen2 to pull supplier data from an external OData feed (in this case, the Northwind Traders sample service), representing a partner organization sharing the same supplier network. https://services.odata.org/v4/northwind/northwind.svc/ What made this step interesting wasn't the mechanics — point, click, choose a table, run — but what it represents: Fabric's pipelines are built to treat "connect to an external partner's data" as a first-class, repeatable operation rather than a one-off script someone writes and forgets. Once the dataflow published and the database refreshed, a new Suppliers table appeared right alongside the internally generated data, ready to be joined. Turning Rows into Answers With warehouse and supplier data now living in the same database, the real payoff arrives: queries that answer questions a disruption-response team would actually ask. A simple ranking query — which products are moving the most — is useful on its own. But the more important artifact is a view: a saved query, vProductsbySuppliers, that joins warehouse inventory against supplier records and groups the results by supplier location. That view becomes a reusable lens on the data — the kind of object that can sit quietly behind a dashboard, or be exposed through Fabric's SQL analytics endpoint and GraphQL API for a front-end app to query directly. It's the difference between running a report once and building infrastructure a team can lean on every day. The Parts You Don't Have to Build Perhaps the most understated part of the whole exercise was everything I didn't have to configure. Fabric's SQL database comes with a built-in Performance Dashboard tracking CPU consumption, connection counts, and allocated storage, plus automatic indexing that tunes itself based on query patterns over time. Backups happen on a schedule without anyone setting up a maintenance window. For a demo project this is a nice-to-have; for a production disruption-response system running around the clock, it's the difference between a database that needs a dedicated administrator and one that mostly looks after itself. Querying Through the SQL Analytics Endpoint Every SQL database in Fabric quietly maintains a second identity: the SQL analytics endpoint. It's a read-only, automatically synchronized mirror of the same data, purpose-built for analytical querying rather than transactional writes. Practically speaking, that means I could point ordinary T-SQL at it — no different syntax, no separate connection ceremony — and start layering real analytical logic on top of the operational tables without ever putting extra query load on the transactional database itself. That separation turned out to be the right place to build out the analytical model properly. Rather than one flat query, I created three views, each with a distinct job: vProductsBySupplier rolls up order quantities by product and supplier; vSalesByDate breaks sales volume down by year and month; and vTotalProductsByVendorLocation sits on top of the first view and groups everything by supplier location — the exact cut a disruption-response team needs when a single region goes offline. Building views on top of other views felt like the right instinct here rather than a shortcut. vTotalProductsByVendorLocation didn't need to know anything about sales order headers or line-item details — it just needed the already-summarized product-and-supplier numbers, joined once more against the warehouse table to bring location into the picture. Each layer stays simple, and each one is independently reusable. CREATE VIEW SupplyChain.vProductsBySupplier AS -- View for total products each supplier SELECT sod.ProductID , sup.CompanyName , SUM(sod.OrderQty) AS TotalOrderQty FROM SalesLT.SalesOrderHeader AS soh INNER JOIN SalesLT.SalesOrderDetail AS sod ON soh.SalesOrderID = sod.SalesOrderID INNER JOIN SupplyChain.Warehouse AS sc ON sod.ProductID = sc.ProductID INNER JOIN dbo.Suppliers AS sup ON sc.SupplierID = sup.SupplierID GROUP BY sup.CompanyName, sod.ProductID; GO CREATE VIEW SupplyChain.vSalesByDate AS -- Product Sales by date and month SELECT YEAR(OrderDate) AS SalesYear , MONTH(OrderDate) AS SalesMonth , ProductID , SUM(OrderQty) AS TotalQuantity FROM SalesLT.SalesOrderDetail AS SOD INNER JOIN SalesLT.SalesOrderHeader AS SOH ON SOD.SalesOrderID = SOH.SalesOrderID GROUP BY YEAR(OrderDate), MONTH(OrderDate), ProductID; GO CREATE VIEW SupplyChain.vTotalProductsByVendorLocation AS -- View for total products by each supplier by location SELECT wh.SupplierLocationID AS 'Location' , vpbs.CompanyName AS 'Supplier' , SUM(vpbs.TotalOrderQty) AS 'TotalQuantityPurchased' FROM SupplyChain.vProductsBySupplier AS vpbs INNER JOIN SupplyChain.Warehouse AS wh ON vpbs.ProductID = wh.ProductID GROUP BY wh.SupplierLocationID, vpbs.CompanyName; GO From Views to Visuals: Building the Power BI Report Views are only half the story — someone still has to look at them. Fabric makes the handoff from database to BI tool almost seamless, but there's a small manual step worth calling out: grabbing the connection string. Under the database's Settings, the connection string contains both the server name and the database name buried inside a longer string, and it's these two values — not the full string — that external tools like Power BI Desktop or SQL Server Management Studio actually want. Inside Fabric itself, though, the path to a report is more direct. Selecting New semantic model over the SQL analytics endpoint pulls in the tables and views I'd built — including all three SupplyChain views — and wraps them in a data model describing how everything relates. One default was worth overriding immediately: the Location field on vTotalProductsByVendorLocation is a location identifier, not a quantity, so it needed Summarize by set to None. Otherwise Power BI happily sums location IDs together into a meaningless total, which is a small trap worth knowing about before it shows up in a report. Why This Pattern Matters Fabric collapses a workflow that traditionally spans several tools — a database server, an ETL tool, a BI platform, a monitoring dashboard — into one connected environment. For a supply chain disruption app specifically, that matters because disruptions don't wait for data to be reconciled across systems. The faster raw supplier and inventory data can be joined, queried, and visualized, the faster a team can answer the question that actually matters in a crisis: what's affected, and what do we do next? Building this out end-to-end — workspace, database, ingested and generated data, a layered set of analytical views, and a working Power BI report — took a single sitting. That speed is really the headline feature. The tools get out of the way fast enough that most of the effort goes into modeling the problem, not the plumbing. What's Coming Next in This Series With the data foundation and the first report in place, the next posts in this series will build on top of it: Part 2 — Notebooks, DevOps, and GraphQL: exploring the data interactively in a Fabric Notebook, bringing the database schema under source control with Azure DevOps, and standing up a GraphQL API on top of the vProductsbySuppliers view. Part 3 — The Application: wiring all of it together into a working ASP.NET web app that lets a disruption-response team type in an affected location and instantly see every supplier and product count at risk. Stay tuned — the foundation and the first report are in place; next up is making the data interactive.One SQL Anywhere – Part 4: Serving RAG Through a GraphQL API in Fabric
One SQL Anywhere – Part 4: Serving RAG Through a GraphQL API in Fabric In Part 3, we built a complete, vector-backed RAG pipeline sitting entirely inside a Fabric SQL Database. In Part 4, we put it to work. No custom backend services, no Express servers, and zero manual resolver code. See how Microsoft Fabric's API for GraphQL turns a T-SQL stored procedure into a fully typed, secure, and production-ready GraphQL endpoint in just a few clicks. Check out the final entry in the One SQL Anywhere series to see the full architecture come together!Open Mirroring in Microsoft Fabric: A Step-by-Step Hands-On Guide
Microsoft Fabric continues to evolve as a unified analytics platform, and Open Mirroring is one of its most powerful additions. It enables seamless, near real-time data ingestion into OneLake without managing complex pipelines or connections. In this blog, I’ll walk you through Open Mirroring in Microsoft Fabric using a practical, hands-on example, covering initial load, incremental updates, and schema changes.Google BigQuery Mirroring in Microsoft Fabric: A Step-by-Step Guide
In this blog, we will walk through how to mirror Google BigQuery tables into Microsoft Fabric using the Mirrored Google BigQuery (Preview) feature. This allows organizations to operationalize data across cloud platforms without building or maintaining complex ETL pipelines. Let’s get started.
