🚀 Welcome to MDriven Learn –  MDriven is now on Discord!  Don’t miss the latest Release Notes.
Event-Driven Architecture
This page was created by Wikiadmin on 2026-07-29. Last edited by Wikiadmin on 2026-07-29.

You can use MDrivenServer SignalR events to notify subscribing systems when something happens; this page is for architects designing communication between MDrivenServer-based services.

Event-Driven Architecture

In MDriven, the documented event-driven integration mechanism is SignalR-based realtime signaling between systems. A publisher signals an event over an open socket, and subscribers react to the notification. This avoids requiring one system to know each listener directly.

For example, an IoT device can publish a MovementDetected event. Many services can subscribe with their own client cookies and react when the movement is detected. A subscriber can then retrieve details through an authenticated REST call.

Documented capabilities

Need Documented approach Example
Notify multiple systems Subscribe to an event GUID and trigger that event from a server-side ViewModel. Multiple services subscribe to MovementDetected; each receives its own event cookie when the event is triggered.
Notify one calling system when work completes Use an event GUID shared by the caller and the service. A PDF conversion service receives a REST request and an event GUID, then signals completion to the caller.
Receive notifications from a non-MDrivenServer publisher The publisher must call the SignalR subscription and receive-event API expected by MDrivenServer. The external publisher calls SubscribeToEvent(string eventguid,string clientcookie) and receives ReceiveEvent(string eventguid, string ClientCookie, string eventData).
Refresh changed realtime data Tag an attribute with Realtime=true so systems using WebApi communication with MDrivenServer can invalidate the attribute shortly after it is committed. A client receives a realtime update, invalidates a loaded attribute, and retrieves its current value when needed.

Read Documentation:Communication between MDrivenServers for the subscription, triggering, and receiving flow. Read Documentation:SignalR and Realtime for realtime attribute invalidation and client refresh behavior.

Implement an event subscription

  1. Create a server-side ViewModel action column named RealtimeSubscribeToEvent.
  2. Provide realtimehub with the MDrivenServer URL to subscribe to. Leave it blank to subscribe to the current system.
  3. Provide eventguid, a unique string that identifies the event at the instance level. Share this value with the event sender.
  4. Provide eventcookie, the value returned to the subscriber when the event occurs. For example, Viewmodel=SomeVM&RootId= followed by the object's external ID lets the receiver identify the ViewModel and root object to open.
  5. To change the cookie for the same server and event GUID, subscribe again.
  6. To remove the subscription, send a blank eventcookie or set it to endsubscription.

Trigger an event

  1. Create a server-side ViewModel action column named RealTimeTrigger.
  2. Set eventguid to the same unique event string used by subscribers.
  3. Optionally set eventdata.

When the event is triggered, every subscriber for that event GUID receives its event cookie. A receiving MDrivenServer uses the cookie in ReceiveEvent(theEventGuid, theEventCookie) to create a SysAsyncTicket using the ViewModel and RootId in the cookie.

Security

Events are open and unauthenticated. Do not send sensitive data in an event GUID, event cookie, or event data.

Use the event as a notification, then retrieve the required details through an access-controlled REST GET. For example, send a MovementDetected notification and let the receiving service perform an authenticated REST request for the movement details.

Scope of this documentation

This documentation covers SignalR-based realtime signaling, event subscriptions, and event triggering with MDrivenServer. It does not document webhook integration, event streaming, Kafka, RabbitMQ, or other message-broker integration patterns. Confirm support and recommended integration guidance for those technologies before selecting them for an MDriven solution.

See also