Unlocking Fabric Automation: Lessons, Possibilities, and Real-World Insights
Join me as I introduce FabricCatalyst, a PowerShell-driven solution that automates Microsoft Fabric deployments using the Fabric REST API. Discover three deployment approaches—Auto, Custom, and Map—along with real-world use cases, challenges, and insights to kickstart your automation journey!
Session
Abstract
As Microsoft Fabric continues to grow as a unified data platform, the need for automation in managing and deploying Fabric environments has never been greater. In this session, I’ll introduce FabricCatalyst, a PowerShell-driven solution that automates and streamlines the creation and deployment of Fabric items by leveraging the Fabric REST API. I'll show you two deployment approaches enabled by FabricCatalyst: Auto & Map; throughout the session, I’ll share my personal experience building FabricCatalyst, including Real-world use cases (When and why each deployment method is most useful) and insights into current gaps in the Fabric API and where workarounds were necessary.
By the end of this session, you’ll leave with a broader understanding of the automation possibilities in Microsoft Fabric, practical insights into real-world challenges, and ideas to inspire your own automation journey.
Video
Highlights
- 0:00 - Welcome
- 2:40 - About the session & agenda
- 5:40 - Inception: Solving a Real-World Problem
- 11:24 - Introduction to FabricCatalyst (what is it?)
- 13:40 - Fabric arch. pattern in a nutshell
- 17:12 - Auto Deployment Operations Workflow (Normal vs Long-running)
- 19:31 - Long-Running Operations (LRO) & Invoke-WebRequest
- 20:45 - Demo - FabricCatalyst Auto Deployment
- 38:05 - The other two deployment methods: Custom & Map
- 39:46 - Demo - FabricCatalyst Map Deployment
- 47:16 - Current challenges with Fabric Automation
- 52:18 - Question from the audience
- 56:30 - Wrap it up and farewell ... thanks for watching!
Presentation
Extras
Invoke-WebRequest vs Invoke-RestMethod
Below is a summary chart that highlights the key differences between Invoke-WebRequest and Invoke-RestMethod in PowerShell:
| Aspect | Invoke-WebRequest | Invoke-RestMethod |
|---|---|---|
| Primary Use Case | General web requests, including retrieving HTML pages, files, and resources | Designed for interacting with REST APIs, particularly when JSON/XML content is returned |
| Output Format | Returns a detailed response object (includes properties like Content, Headers, StatusCode, ParsedHtml, etc.) | Returns parsed data directly. Automatically converts JSON/XML to native PowerShell objects |
| Parsing Capabilities | Provides HTML parsing (via ParsedHtml property) and raw text content | Focused on data; no built-in HTML parsing – returns the deserialized content |
| Ease of Use for APIs | Requires additional processing if deserialization is needed | Simplifies working with APIs by returning already-processed objects |
| Error Handling | Provides comprehensive response details which can be useful for debugging | Focuses on returning the core data; may require additional handling if more response details are needed |
| Typical Scenarios | Web scraping, downloading files, obtaining headers and status codes | Consuming RESTful APIs where the response is in JSON or XML format |
When to Use Which
- Invoke-WebRequest:
Use when you need the complete HTTP response, want to parse HTML content, or require access to metadata like headers and status codes. - Invoke-RestMethod:
Use when interacting with RESTful APIs and you need the response automatically deserialized into PowerShell objects for easier manipulation.
This chart should help you decide which cmdlet best fits your scenario based on the type of content and the processing you need to perform after the request.
Handling Long-Running Operations (LRO)
- Calling an API Endpoint that supports LRO (usually the method is POST), if the return status code is 202, that means "The request has been accepted for processing"
- Read the operation ID from the Response-object's header 'x-ms-operation-id' and call a function that enters a while ($true) loop
- We invoke the operation's API endpoint, asking the status of the operation id previously received and break the loop when receiving a status code 200, that means "Success"
- Return the Operation details, in Fabric, it returns the id of the item requested on step #1
For additional details, check MSFT article:
KesemSharabi
