← ClaudeAtlas

fabric-eventstreamlisted

Use for Microsoft Fabric Eventstream — the streaming-ingestion item routing CDC / Event Hubs / Kafka / IoT / HTTP / MQTT events into Lakehouse, Eventhouse, Activator, or derived streams. Covers source connectors (Azure SQL / SQL MI / SQL Server VM / PostgreSQL / MySQL / MongoDB / Cosmos DB CDC, Mirrored Database Delta CDF April 2026 preview, Event Hubs / IoT Hub / Kafka / MSK / Confluent / Kinesis / Pub-Sub / Service Bus / MQTT / HTTP / Solace), DeltaFlow CDC → analytics-ready transformation (auto-table-create + schema evolution from Debezium), Activator destination + in-Eventstream `Set Alert` flow (on each event / when / grouped by), the three workspace-monitoring KQL tables (`EventStreamNodeStatus` ~6h, `EventStreamMetrics` 1m, `EventStreamErrorMetrics` 1m) + republish-on-enable requirement, mTLS Key Vault on Kafka-family connectors, edit/publish workflow, VNet injection, gotchas (republish required, 6h status lag, filter by ArtifactId not name, CorrelationId-vs-NodeId, no log messages in preview).
wardawgmalvicious/claude-config · ★ 1 · API & Backend · score 75
Install: claude install-skill wardawgmalvicious/claude-config
# Fabric Eventstream Streaming-data ingestion item that pulls events from a wide source surface (CDC / Event Hubs / Kafka / IoT / HTTP / MQTT) and routes them into Fabric destinations (Lakehouse, Eventhouse, Activator, derived stream, custom endpoint). Authoring is graph-based: source nodes → optional transformations → destination nodes, edited then **published** to go live. ## When to use vs not Use Eventstream when the data is **arriving as events** and needs routing or transformation before it lands. Skip it when the data is bulk / batch (use a Data Pipeline Copy activity), already in the lake (use Spark / SQL directly), or when the only consumer is a Mirrored Database in append-only mode (mirroring lands data straight in OneLake without an Eventstream). For real-time analytics on the resulting events, pair an Eventstream with `fabric-eventhouse` (KQL Database). For real-time **rules**, pair with an Activator destination (covered below). ## Authoring model - **Edit mode** vs **Live mode**: changes only take effect after **Publish**. New nodes added in Edit mode produce no traffic until publish. - **Sources** = where events come from. **Transformations** = inline filter / aggregate / GroupBy / Manage Fields / SQL. **Destinations** = where events go. Each destination can have its own format (Delta / JSON / Avro) where applicable. - **Permissions**: workspace **Contributor** or higher to author; **Viewer** can read **Data insights** monitoring on a published stream. - *