You can use SignalR-based events to let one MDrivenServer notify another system that work or data is available, without making services poll each other or maintain direct callback endpoints.

When to use MDrivenServer events

Use an event when a system needs to react promptly to something that happened in another system, but the event publisher should not need to know what each listener does.

For example, an IoT service can publish a MovementDetected event. Many independent systems can subscribe to it. Each listener decides what to do when it receives the event, such as retrieving current movement details through its own authenticated REST request.

This differs from a design where every system exposes a REST endpoint and every other system calls it directly. Direct service-to-service callbacks create dependencies between systems: a publisher must know every receiver, and changing a receiver can break the publisher. An event publisher instead exposes an event identified by an event GUID, and listeners subscribe to that event.

MDrivenServer uses SignalR and Realtime communication for these subscriptions and notifications. SignalR keeps an open connection so the publisher can notify connected listeners when the event occurs.

Concepts

Term	Meaning	Example
Event GUID	A string that identifies one event at the required instance level. The publisher and subscriber must use exactly the same value.	MovementDetected, or a GUID supplied for one PDF conversion job.
Event cookie	A string supplied by the subscriber and returned to it when the event is triggered. In an MDrivenServer receiver, use it to identify the ViewModel and root object that must handle the notification.	Viewmodel=PdfCompleted&RootId= followed by the external ID of the job object.
Publisher	The system that exposes an event and triggers it when something happens.	The PDF conversion service.
Subscriber	The system that registers interest in an event.	The application that submitted a PDF conversion job.
Receiver	The connected client or MDrivenServer logic that receives ReceiveEvent when the publisher triggers the event.	A server-side ViewModel started through a SysAsyncTicket.

Prerequisites

Before using server-to-server events:

• Enable WebSocket support in IIS for each IIS-hosted system that participates in SignalR communication.
• Ensure that the subscribing MDrivenServer can reach the publisher URL.
• Decide on an event GUID convention. The value must be shared between the publisher and every intended subscriber.
• Treat an event as a notification, not as a trusted data transport. See Security.

Subscribe from an MDrivenServer

To make an MDrivenServer subscribe to an event, create a server-side ViewModel action column named RealtimeSubscribeToEvent.

Add the action columns

Add the following columns to the server-side ViewModel that performs the subscription.

Column	Value and purpose
realtimehub	The MDrivenServer URL of the system that publishes the event. Leave this blank when subscribing to an event published by this same MDrivenServer.
eventguid	The event identifier. It must match the publisher's eventguid exactly.
eventcookie	The value returned when this event is triggered. A recommended MDrivenServer format is Viewmodel=SomeVM&RootId= followed by self.externalid.

Configure and execute the subscription

1. Create the server-side ViewModel action and name its action column RealtimeSubscribeToEvent.
2. Set realtimehub to the publisher's MDrivenServer URL. Leave it blank if the publisher is the current server.
3. Set eventguid to the shared event identifier.
4. Set eventcookie to tell the receiving MDrivenServer what it should execute when notified.
5. Execute the action.

For example, a system waiting for a PDF conversion can subscribe with these values:

realtimehub  = https://pdf-service.example
 eventguid   = 8a29d6e1-a-job-specific-guid
 eventcookie = Viewmodel=PdfCompleted&RootId=<self.externalid>

When the PDF service later triggers 8a29d6e1-a-job-specific-guid, the subscribing MDrivenServer receives the cookie and can start the PdfCompleted server-side ViewModel for the specified root object.

Update or remove a subscription

You can execute RealtimeSubscribeToEvent more than once.

• For the same server and event GUID combination, MDrivenServer retains only the latest event cookie.
• To remove the subscription, provide a blank eventcookie or set it to endsubscription.

This means a later subscription for the same event GUID replaces the earlier cookie. Do not rely on multiple cookies for the same server/event-GUID combination.

Trigger an event from an MDrivenServer

To publish an event from an MDrivenServer, create a server-side ViewModel action column named RealtimeTriggerEvent.

Add the action columns

Column	Value and purpose
eventguid	The identifier of the event to trigger. It must match the value used by subscribers.
eventdata	Optional string supplied by the publisher. The MDrivenServer receiving flow described on this page does not currently use it.
eventRemoveAfterSend:bool	Optional Boolean value. The default is false. Set it to true when each subscriber should be notified only once.

Trigger the notification

1. Create the server-side ViewModel action and name its action column RealtimeTriggerEvent.
2. Set eventguid to the identifier shared with subscribers.
3. Optionally set eventdata.
4. Set eventRemoveAfterSend:bool to true if this is a one-time subscription.
5. Execute the action when the business event occurs.

MDrivenServer finds connected listeners that subscribed to the event GUID and calls ReceiveEvent for each of them. Each listener receives its own event cookie together with the event data.

How an MDrivenServer receives an event

When an MDrivenServer subscribes by using RealtimeSubscribeToEvent, it uses the returned event cookie in this callback:

ReceiveEvent(string theEventGuid, string theEventCookie)

The receiving MDrivenServer reads the ViewModel name and root ID from the event cookie and creates a SysAsyncTicket. The ticket starts the identified server-side ViewModel for that root object.

Use an event cookie that names a ViewModel designed for notification handling. That ViewModel should perform the work required after notification, such as retrieving the finished result from the publisher through an authenticated REST call.

Interoperate with non-MDrivenServer systems

A non-MDrivenServer publisher can notify an MDrivenServer subscriber if it exposes the required SignalR contract:

SubscribeToEvent(string eventguid, string clientcookie);
ReceiveEvent(string eventguid, string ClientCookie, string eventData);

The external publisher must accept SubscribeToEvent. When it later has an event to publish, it calls ReceiveEvent for connected subscribers that match the event GUID.

A non-MDrivenServer subscriber can consume events from an MDrivenServer publisher by connecting and handling:

ReceiveEvent(string eventguid, string ClientCookie, string eventData);

The subscriber must parse the ClientCookie that it originally supplied with SubscribeToEvent and take the action appropriate to that cookie.

Security

Events are open and unauthenticated. Do not send sensitive information in eventguid, eventcookie, or eventdata.

Use the event only to say that something has changed or that work is ready. Then let the receiver make a just-in-time REST request for the required data. Protect that REST request with AccessGroups.

For example, send an event that means “PDF conversion completed,” then have the receiving ViewModel retrieve the finished PDF through an authenticated endpoint. Do not place the PDF, credentials, personal data, or authorization decisions in the event payload.

Examples

Notify many independent listeners

An IoT device detects movement. Two hundred and fifty systems need to react quickly, but the device has limited capacity and a slow network connection.

1. The IoT device exposes the event GUID MovementDetected.
2. Each listener calls SubscribeToEvent("MovementDetected", clientcookie) and supplies its own cookie.
3. When movement is detected, the device triggers MovementDetected.
4. Each connected listener receives its own cookie over the existing connection.
5. A listener that needs details makes an authenticated REST call to the device.

This avoids continuous polling by every listener and avoids requiring the device to establish a new connection to each listener. It also allows listeners to be changed or removed without changing the publisher.

Receive completion for one PDF conversion job

A PDF conversion service receives document data through a REST POST. The caller needs completion feedback without repeatedly asking whether the job has finished.

1. The caller creates a unique GUID string for this conversion job.
2. The caller includes that GUID in the REST POST to the PDF service.
3. The caller executes RealtimeSubscribeToEvent with the PDF service URL, the job GUID, and an event cookie such as Viewmodel=PdfCompleted&RootId= followed by self.externalid.
4. The PDF service completes the conversion and triggers the same job GUID.
5. The caller's MDrivenServer receives the event and starts the PdfCompleted server-side ViewModel for the root object.
6. The PdfCompleted ViewModel retrieves the finished PDF from the service and updates the application state.

If the application displays an attribute tagged Realtime=true, the normal SignalR and Realtime flow can help connected clients discover the update promptly.

See also

• Documentation:SignalR and Realtime
• Documentation:Debugging MDrivenServer Serverside actions
• Documentation:Additional considerations with load balancing Turnkey and MDrivenServer
• Documentation:Scaling MDrivenServer for multiple reasons