Communication between MDrivenServers
Line 24: Line 24:
The receiving MDrivenServer will use the eventcookie that comes back  when the event is triggered in the ReceiveEvent(theEventGuid, theEventCookie) and create an [[AsyncTicket|SysAsyncTicket]] with the ViewModel and RootId taken from the cookie.
The receiving MDrivenServer will use the eventcookie that comes back  when the event is triggered in the ReceiveEvent(theEventGuid, theEventCookie) and create an [[AsyncTicket|SysAsyncTicket]] with the ViewModel and RootId taken from the cookie.


If you have a non MDrivenServer as a event giver - and you want to hook up the MDrivenServer as an event listener - then the event sending system must allow for the follwing SignalR api:
If you have a non MDrivenServer as a event giver - and you want to hook up the MDrivenServer as an event listener - then the event sending system must allow for the following SignalR api to be called and sent:
  method SubscribeToEvent(string eventguid,string clientcookie )
  method SubscribeToEvent(string eventguid,string clientcookie );
  event ReceiveEvent(string eventguid, string ClientCookie);
  event ReceiveEvent(string eventguid, string ClientCookie);
The event sending MDrivenServer


If you build
==== The event sending MDrivenServer ====
The event sending MDrivenServer will upon executing the RealTimeTrigger serverside vm action use the eventguid and call the ReceiveEvent that will filter out the connected listening clients on eventguid - and send the clientcookie
 
If you build another -non MDrivenServer - system that wants to consume events from an MDrivenServer you must allow for the following SignalR api:
event ReceiveEvent(string eventguid, string ClientCookie);
and in this you must parse the ClientCookie you sent in on SubscribeToEvent and act as you see fit.

Revision as of 18:19, 15 November 2020

If you build a whole (micro) service universe you will soon notice a need for events triggered from one system sent to another.

This can - and is - often handled as Rest-api's on two systems that call each other. While this strategy may get the job done you have an issue with the fact that the two systems must know about each other - and this quickly turns into a spaghetti tangled web of services that cannot really change without breaking something.

A much better approach is to have the more generic of the two systems expose a generic callback - an event.

Such events are best implemented by an open socket that can be used by the generic system to signal events even if it knows nothing about the listener - that in turn may cause action in the caller.

In .net SignalR is implementing this infrastructure.

In MDrivenServer we use SignalR to enable internet signaling and event sending to subscribers

realtimesubscribetoevent

Create an action column on a serverside ViewModel named realtimesubscribetoevent. You will need these columns:

  • realtimehub = the MDrivenServer-url to the system to subscribe to - leave blank for THIS system
  • eventguid = a unique id (as a string) that makes the this event unique on instance level - you will want to share this eventguid with the event sender - because that will make your eventcookie come back to your system in the ReceiveEvent(theEventGuid, theEventCookie) callback
  • eventcookie = what you want the server to send back on event - suggested value 'Viewmodel=SomeVM&RootId='+self.externalid

RealtimeTriggerEvent

Create an action column on a serverside ViewModel named RealtimeTriggerEvent. You will need this column:

  • eventguid = a unique id (as a string) that makes the this event unique on instance level - you want to share this eventguid with the event subscriber - no matter how many subscribers you have - they will receive their eventcookie

The receiving MDrivenServer

The receiving MDrivenServer will use the eventcookie that comes back when the event is triggered in the ReceiveEvent(theEventGuid, theEventCookie) and create an SysAsyncTicket with the ViewModel and RootId taken from the cookie.

If you have a non MDrivenServer as a event giver - and you want to hook up the MDrivenServer as an event listener - then the event sending system must allow for the following SignalR api to be called and sent:

method SubscribeToEvent(string eventguid,string clientcookie );
event ReceiveEvent(string eventguid, string ClientCookie);

The event sending MDrivenServer

The event sending MDrivenServer will upon executing the RealTimeTrigger serverside vm action use the eventguid and call the ReceiveEvent that will filter out the connected listening clients on eventguid - and send the clientcookie

If you build another -non MDrivenServer - system that wants to consume events from an MDrivenServer you must allow for the following SignalR api:

event ReceiveEvent(string eventguid, string ClientCookie);

and in this you must parse the ClientCookie you sent in on SubscribeToEvent and act as you see fit.

This page was edited 53 days ago on 03/26/2024. What links here