Communication between MDrivenServers
No edit summary
Line 1: Line 1:
If you build a whole (micro) service universe you will soon notice a need for events triggered from one system sent to another.
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 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.
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.
A much better approach is to have the more generic of the two systems expose a generic callback - an event.
Line 12: Line 12:


==== realtimesubscribetoevent ====
==== realtimesubscribetoevent ====
Create an action column on a serverside ViewModel named realtimesubscribetoevent. You will need these columns
Create an action column on a serverside ViewModel named realtimesubscribetoevent. You will need these columns:
* realtimehub = the url to the system to subscribe to - leave blank for THIS system
* realtimehub = the MDrivenServer-url to the system to subscribe to - leave blank for THIS system
* eventguid = a unique id that makes the this event connection unique   
* 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=externalid
* eventcookie = what you want the server to send back on event - suggested value 'Viewmodel=SomeVM&RootId='+self.externalid


==== realtimetriggerevent ====
==== 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 [[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:
method SubscribeToEvent(string eventguid,string clientcookie )
event ReceiveEvent(string eventguid, string ClientCookie);
The event sending MDrivenServer
 
If you build

Revision as of 18:09, 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 follwing SignalR api:

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

The event sending MDrivenServer

If you build

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