eventhouse

15 Topics

Fabric Business Events: what delivery guarantees and replay pattern should we design for?
Hi all, I am testing the newer Business Events capability in Fabric Real-Time Intelligence and trying to understand what reliability assumptions should be made for a production design. The pattern I am looking at is roughly: Eventstream → Business Event → Activator → downstream action / User Data Function with Eventhouse enabled so the published business events are also retained for historical analysis. The current documentation explains the publisher/consumer model and shows how Eventstream can publish a governed business event that Activator then consumes. What I have not been able to find clearly documented is the delivery contract between the published business event and its consumers. A few things I am trying to clarify: If an Activator consumer or downstream action is temporarily unavailable, does Fabric retry delivery of the business event? Should consumers assume at-least-once delivery and therefore be designed to handle duplicate events, or is a different delivery model used? Is event ordering guaranteed in any scope, for example for events from the same Eventstream publisher? Since published business events can also be retained automatically in Eventhouse, is that retained history intended to support replay/reprocessing after a consumer outage, or is it primarily an analytical record and replay would need to be implemented separately? Are there documented retry or delivery-retention windows that should be considered when designing an operational workflow? I am mainly trying to understand what a resilient production pattern should look like when the business event triggers something with side effects, where processing the same event twice or silently missing an event would matter. Would you generally make the downstream consumer idempotent and treat Eventhouse as an audit/recovery store, or is there a more Fabric-native pattern for this? Interested to hear how others are approaching this with Business Events and Activator.
ShivekMaharaj
6 days ago Place Real-Time Intelligence
45Views
0likes
2Comments
Best practice for handling schema evolution in Fabric Eventstream before data reaches Eventhouse?
I have an Eventstream receiving operational events where the schema may evolve over time. For example, the producer initially sends: DeviceId, Timestamp, Temperature, Status but later adds fields such as: Location, FirmwareVersion, ErrorCode I want the pipeline to continue ingesting events without breaking downstream KQL tables, update policies, materialized views, or Real-Time Dashboards. I am trying to understand where schema evolution should ideally be handled in a production Fabric RTI architecture. Would you: enforce the contract upstream using Schema Registry normalize changing fields inside Eventstream before Eventhouse ingestion land the raw payload first and handle schema evolution inside Eventhouse/KQL maintain separate versioned event schemas/tables How are people handling this in production when producers can add fields without notice? I am particularly interested in avoiding a design where every small upstream schema change forces updates across Eventstream, KQL tables, update policies, and downstream dashboards.
Solved
ShivekMaharaj
11 days ago Place Real-Time Intelligence
94Views
0likes
2Comments
Best practice for deciding between Eventstream transformations and Eventhouse update policies
Hi Fabric Community, I am exploring a Real-Time Intelligence architecture and would appreciate some guidance on where transformation logic should ideally be placed. The proposed flow is: Azure Event Hubs → Fabric Eventstream → Eventhouse → Real-Time Dashboard / Power BI Fabric Eventstream supports filtering, field management, aggregation and other processing before events are written to the destination. An Eventhouse can also ingest the raw events first and transform them into curated tables through KQL update policies. I am trying to understand the recommended boundary between these two layers. For example, assume the incoming event contains: Device or customer identifier Event timestamp Event type Location Numeric readings Additional JSON properties The required processing includes: Removing events that fail basic validation Renaming and standardizing fields Converting timestamps and data types Flattening selected JSON properties Enriching the event with reference data Creating five-minute aggregates Preserving the original event for auditing and future reprocessing My current thinking is: Use Eventstream for lightweight filtering, routing and simple schema normalization. Land the original event in a Bronze table whenever replay or auditing is required. Use Eventhouse update policies or KQL for enrichment, reusable business logic and curated Silver tables. Use materialized views for frequently queried aggregations rather than calculating them repeatedly in dashboards. However, I am unsure where Microsoft recommends drawing the line. A few questions: Are there transformation types that should generally remain in Eventstream rather than Eventhouse? Is it considered good practice to send both the raw stream and a transformed derived stream into separate Eventhouse tables? When using Eventstream’s Event processing before ingestion mode, what are the trade-offs compared with direct ingestion followed by an Eventhouse update policy? How do teams handle changes to transformation logic when historical events need to be reprocessed? For reference-data enrichment, would you normally perform the lookup in Eventstream or after ingestion with KQL? Are five-minute or hourly aggregations better implemented in Eventstream, through an update policy, or with an Eventhouse materialized view? Microsoft’s Eventstream destination guidance documents both direct ingestion and event processing before ingestion, while the KQL update-policy documentation provides another way to transform ingested data. I would be interested to hear how others divide responsibility between Eventstream and Eventhouse in production, particularly where auditability, reprocessing and maintainability are important. Thanks in advance!
Solved
ShivekMaharaj
17 days ago Place Real-Time Intelligence
96Views
0likes
2Comments
How do you decide when to use Real-Time Intelligence instead of batch processing in Microsoft Fabric
Hi everyone, I'm learning Microsoft Fabric and recently started exploring Real-Time Intelligence. I understand that it can process streaming data, but I'm trying to understand when it's the right choice compared to traditional batch processing. I have a few questions: What types of business scenarios benefit the most from Real-Time Intelligence? When would you choose streaming over scheduled batch processing? What are some common real-world use cases you've worked on? Are there any performance or cost considerations that beginners should be aware of? I'd really appreciate hearing about your experiences and any best practices you recommend. Thank you!
Solved
binitafulpagare
1 month ago Place Real-Time Intelligence
336Views
1like
6Comments
Real‑Time Dashboards cannot be created
Hi all. We’re currently facing an issue in the a Fabric tenant that prevents us from creating Real‑Time Dashboards. According to Microsoft documentation, this feature requires either a Fabric Premium capacity or a Premium Per User (PPU) license. Reference: Create a Real-Time Dashboard - Microsoft Fabric | Microsoft Learn For example: In one tenant (F4 capacity, North Europe) with a user licensed as Premium Per User, the feature works as expected. In another tenant (F16 capacity, Southeast Asia) with a user licensed as Pro, Real‑Time Dashboards cannot be created. The error shown is: “Real‑Time Dashboard item can only be created if this action is enabled in the tenant. Ask your tenant admin to enable this.” This error is confusing, as the option to enable the feature is no longer available in the Admin Portal. Anyone had a similar issue?
diegoelasta
1 month ago Place Real-Time Intelligence
6.5KViews
2likes
15Comments
Working with Microsoft Fabric Support - A Collaborative Approach
At Microsoft Fabric Support, our goal is simple: help you resolve issues as quickly and smoothly as possible. Just like the recommendations shared in the Microsoft Fabric Community’s guidance on getting questions answered effectively, providing clear and complete information upfront helps everyone move faster and avoid unnecessary back-and-forth. Support is most effective when it’s a collaborative process. You bring the knowledge of your environment and workloads, and we bring deep platform expertise and diagnostics to help investigate the issue together. Help Us Help You When opening a support case, please include as much of the following information as possible: Issue Details Clear description of the problem Expected behavior vs. actual behavior Is the issue intermittent or consistently reproducible? Approximate timeframe of when the issue occurred (UTC preferred) Error Information Please include: Full error message text Screenshots (highly recommended) Activity IDs / Correlation IDs if available Even small details can significantly speed up investigation. Environment Information That Helps Investigation Depending on the Fabric workload being used, please provide the relevant item IDs and environment details. Workspace Information Workspace ID / Workspace URL To find this: Open the Fabric workspace Copy the URL from your browser Example: ".. https://app.fabric.microsoft.com/groups/<WorkspaceID>/… …" The value after /groups/ is the Workspace ID. Screenshot example above showcases the WorkspaceID and EventhouseID. Fabric Item IDs Please provide the item ID related to the affected workload, such as: EventhouseID ActivatorID LakehouseID WarehouseID SemanticModelID EventstreamID PipelineID These IDs help us locate telemetry and backend diagnostics more efficiently. You can typically find these: In the browser URL while inside the Fabric item Within item settings/details pages From the Fabric portal navigation pane Additional Environment Details Please also include: "… WorkspaceID: Capacity Name: Region …" Example: "… WorkspaceID: xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx Capacity Name: Fabric-Prod-EastUS Region: East US …" This information helps us identify: Capacity-level issues Regional service impact Configuration-specific behavior Why This Matters Microsoft Fabric is a distributed cloud platform, and troubleshooting often depends on correlating logs, telemetry, timestamps, and resource identifiers together. Providing complete details upfront helps: Reduce delays Avoid repeated clarification requests Accelerate root cause analysis Create a smoother support experience for everyone involved We’re here to partner with you throughout the process, and we truly appreciate your collaboration in helping us investigate issues effectively. We look forward to working with you!
krlitt
1 month ago Place Real-Time Intelligence
1.1KViews
5likes
3Comments
Digital Twin Builder (preview): Bounding storage growth for an incremental time-series
Is there any supported way to apply a retention horizon to a Digital Twin Builder time-series mapping that uses incremental processing, so the underlying dtdm table doesn't grow without bound? My scenario: high-frequency live telemetry landing in an Eventhouse, surfaced to DTB through a lakehouse table (I've used both shortcuts and pipeline copy activities in my tests). The static layer and relationships are working well. The question is purely about the time-series layer. With incremental mapping enabled, the series appends continuously and the dtdm table grows linearly with no eviction. I've confirmed a couple of things that don't solve it, so I'll pre-empt them: Retention on the source table doesn't bound the twin copy. Incremental processing is forward-only, so source rows aging out are never removed from data the mapping already ingested. A mapping filter governs ingestion, not eviction, and only limits initial backfill (no relative/dynamic date filter). I assume full reload (incremental disabled) over a windowed source table does keep things bounded, since each run replaces the prior load, and that's my current fallback. But I'd like to confirm whether there's any retention/TTL control I've missed for the incremental path specifically, at the mapping, entity, or item level, or any sanctioned way to age out rows from the dtdm time-series table. If the answer is "not currently supported," that's useful to know too, and I'll file it as an Idea. Running on a Fabric capacity, DTB still in preview. Thanks in advance
Solved
smorenodev
1 month ago Place Real-Time Intelligence
1KViews
0likes
5Comments
Error in Microsoft Applied Skills: Implement a Real-Time Intelligence Assessment Lab : Need help
Hello All, since a week I was stuck on one error in Microsoft Applied Skills: Implement a Real-Time Intelligence solution with Microsoft Fabric Lab. Did anyone face the same issue if so, can anyone help me out how to resolve it. Attaching the error and related images below. Error: It says " unable to load container blobs. Verify that workspace identity is enabled and has storage blob data reader access to the storage account" . I am familiar with this permission and have enabled it in my own azure environment for my own blob that I have created but since these are pre created by Microsoft, I don't have access to these storage blobs and hence I am not sure how to proceed here. I have attempted this twice but I was stuck at the same point. I really appreciate your help and taking time in looking into my post. Thank you so much.
Solved
AshikaAlvakonda
3 months ago Place Real-Time Intelligence
1.8KViews
0likes
7Comments
How to reset Eventhouse Ingestion from Batching to Streaming ?
Hi everyone, I am experiencing a persistent latency issue in our Microsoft Fabric Eventhouse. A table that was previously performing perfectly has suddenly "downgraded" its ingestion path from Streaming to Batching and refuses to recover. The Situation: The Problem: In our PROD Eventhouse, ingestion latency is stuck at 12–15 seconds. The table is generating 45+ shards (extents) every 10 minutes, confirming it is in Batching Mode. The Discrepancy: Our DEV Eventhouse (identical schema and higher data volume) is still Streaming perfectly with ~5-second latency and 0 shards created per 10 minutes. The History: PROD was working fine (5s latency) and then switched to this slow Batching state on its own without any schema or policy changes. What we have verified: Streaming Policy: Both DEV and PROD have streamingingestion enabled. Batching Policy: We tested various ingestionbatching settings in a separate environment. We confirmed that the 12s latency in PROD is a result of the Batching Path overhead Unable to restore streaming: Running .alter table ... streamingingestion enable in PROD does not trigger a return to the Streaming. Our Questions: Why would an Eventhouse suddenly "blacklist" a table from the Streaming path and move it to permanent Batching if the Capacity (CU) is healthy (~50%)? How do we reverse this process? Once a table is stuck in this "Permanent Batching" state, what is the specific command or workflow to force the Eventhouse to re-evaluate it for the Streaming (Fast) Lane? We need to restore the 5-second latency to meet our real-time requirements. Any insights into the internal health-check logic of the Eventhouse would be incredibly helpful. Thank you !
Solved
lavginqo
4 months ago Place Real-Time Intelligence
32KViews
0likes
15Comments
Azure Maps base layer not loading in Real-Time Dashboard - Only points visible
Hi Fabric Community, I'm experiencing an issue with Map visualizations in Real-Time Dashboards. The data points are rendering correctly, but the Azure Maps base layer (streets, terrain, satellite) is not loading - only a white/blank background appears. **Environment:** - Microsoft Fabric Real-Time Intelligence - Real-Time Dashboard with KQL queries - Eventhouse as data source - Browser: Chrome/Edge (tested both) - Region: South Central US **Steps to reproduce:** 1. Create a KQL query with latitude/longitude columns 2. Add to Real-Time Dashboard 3. Change visual type to "Map" 4. Configure: Latitude column, Longitude column, Label column 5. Points appear but no map background **What I see:** - Colored circles representing my 10 GPS devices - Correct relative positions between points - Zoom controls (+/-) present but don't show map tiles - "Center" button works for positioning **What I expected:** - Azure Maps base layer with streets/roads visible behind the points **Troubleshooting attempted:** - Tried different browsers (Chrome, Edge) - Cleared browser cache - Verified coordinates are correct (Mexico City area: 19.5, -99.3) - Checked browser console - no obvious errors **Questions:** 1. Is there a known issue with Azure Maps in Real-Time Dashboards? 2. Are there specific tenant/admin settings required for Azure Maps? 3. Is this a preview limitation? Screenshots attached showing points without map background. Thank you for any guidance!
Solved
jhrjdata
6 months ago Place Real-Time Intelligence
4.1KViews
0likes
2Comments