Publishing Business Events from Fabric workloads

Microsoft Employee

1 month ago

In the previous article, we started with the contract before writing publishing code. We defined the business fact, selected fields that give consumers enough context to act, and added an explicit data version so the contract can evolve safely. That schema establishes what the signal means; the next design decision is where the signal should originate.

In this article, we build directly on that schema-first foundation by choosing the Fabric workload that naturally detects each business condition and by defining the responsibilities of reliable publishing code. The guiding principle is simple: publish the event where the business signal is detected.

Choose the publisher based on ownership

Start with the workload that owns the business decision, not the workload that is easiest to call. The publisher should have enough context to determine that a meaningful state change occurred, construct a schema-valid payload, and assign the correct data version. Keeping those responsibilities together reduces duplicated rules and makes the source of each signal easier to trace.

Use three questions to evaluate a candidate publisher. Which workload first knows that the condition is true? Which workload has the authoritative values required by the event schema? Which team can monitor and update the publishing logic when the contract changes? If the answers point to different workloads, clarify ownership before adding publishing code.

Also consider execution behavior. A scheduled notebook is appropriate for batch detection, a User Data Function fits request-driven signals, Eventstream supports continuous evaluation, and Activator can publish a derived business state. In every case, design retries and diagnostics so transient failures do not create silent data loss or duplicate business actions.

Publish where the signal is detected

Business Events are most useful when the publisher is close to business conditions.

Publish each Business Event from the Fabric workload that first detects the business condition. A notebook can publish a sales anomaly it calculates, while a User Data Function can publish an event from an incoming webhook. Eventstream can publish when continuous data crosses a meaningful threshold, and Activator can publish when a rule derives a new business state.

Do not centralize publishing just because it feels tidy. Event-driven architecture works best when signals originate near the workload that detects them.

Figure: Business Events should be published from the Fabric workload that naturally detects the meaningful condition.

Notebook publishers

A notebook is a strong publisher when it already calculates the condition. For example, a notebook may compare expected and actual transactions by store, detect a deviation, and publish only when the deviation crosses a meaningful threshold.

The notebook should not need to know whether the response is a Teams alert, a KQL table, or a downstream process. It should publish the event and move on.

Explore the Sales Volume Alert scenario for an end-to-end notebook publishing example.

For implementation details, see the Microsoft Spark utilities documentation.

User Data Function publishers

A User Data Function is useful when the signal begins outside of Fabric. The external payload may be inconsistent or shaped for another app. The function can normalize it into a clean Business Event schema and publish it into Real-Time Hub.

This pattern is useful for webhooks, custom integrations, and lightweight APIs that need to translate external activity into Fabric-native events.

Explore the Low Stock Threshold scenario for a webhook-driven User Data Function example.

For implementation details, see the User Data Functions documentation.

Eventstream publishers

An Eventstream is the right publisher when the condition appears in continuous data. The key is to publish a Business Event only when the stream produces a discrete business signal, such as a high value transaction, not for every raw event in the stream.

This distinction matters. Eventstream handles continuous data. Business Events represent meaningful moments.

Explore the Real-Time Stream Alert scenario for a continuous Eventstream publishing example.

For implementation details, see the Eventstream documentation.

Activator publishers

Activator becomes a publisher when a rule detects an outcome that is meaningful to other consumers. Publishing a new Business Event from Activator can support automation loops, but use this pattern only when the derived condition represents a meaningful business stage rather than an internal implementation detail.

Explore the Customer Loyalty Milestone scenario for an Activator-derived business state example.

For implementation details, see the Fabric Activator overview.

Publishing example

payload = {
    "store_id": "store-mx-042",
    "expected_transactions": 1250,
    "actual_transactions": 743,
    "deviation_pct": -40.56,
    "window_start": "2024-06-22T09:00:00Z",
    "severity": "high"
}

notebookutils.businessEvents.publish(
    eventSchemaSetWorkspace=WORKSPACE_NAME,
    eventSchemaSet=SCHEMA_SET_NAME,
    eventTypeName="Retail.Sales.VolumeAlert",
    eventData=payload,
    dataVersion="v1"
)

Good publishing code has five responsibilities:

Use the right workspace.
Use the right Event Schema Set.
Use the right Business Event name.
Send fields that match the schema.
Send the right data version.

Notice what the publisher does not do. It does not send the Teams message directly. It does not write the analytical table directly. It does not decide how many consumers should exist. Those decisions belong outside the publisher.

This is the core design benefit. The publisher owns detection and publication. Consumers own reaction. Real-Time Hub connects the two without making the publisher responsible for every downstream behavior.

Common publishing mistakes

Avoid publishing events with incomplete payloads and expecting consumers to fill in the blanks immediately. That creates hidden coupling.

Avoid publishing too many low-value signals. A Business Event should be worth naming, versioning, and subscribing to.

Finally, do not hide schema mismatches behind broad exception handling. If the payload does not match the schema, fix the contract or the publisher. A failed publication during development is a useful signal that the design needs attention.

Conclusion and where to go next

Publishing Business Events is about emitting a versioned, schema-valid signal from the workload that detected the condition. Keep the publisher close to the business moment and let consumers decide how to react.

To continue, explore the community Business Events scenarios and read the official Business Events overview. Then choose a publisher workload and test a schema-valid event in your Fabric workspace.

Business events in Fabric series

This article is the fourth installment in an eight-part series exploring Business Events and event-driven architecture in Microsoft Fabric. Throughout the series, we'll cover the concepts, patterns, and implementation guidance needed to design, publish, process, and scale business events across Fabric workloads.

The next article will explain how Activator and Eventhouse react to Business Events.

Article links