Hans Karlsen (talk | contribs) (Created page with "AsyncTicket is pattern easily added to your model and backed by recent MDrivenServers Read about its background here https://blog.mdriven.net/doing-stuff-later/ == The SysAs...") |
Hans Karlsen (talk | contribs) No edit summary |
||
Line 1: | Line 1: | ||
AsyncTicket is pattern easily added to your model and backed by recent MDrivenServers | AsyncTicket is a pattern easily added to your model and backed by recent MDrivenServers | ||
Read about its background here https://blog.mdriven.net/doing-stuff-later/ | Read about its background here https://blog.mdriven.net/doing-stuff-later/ |
Revision as of 09:45, 14 April 2020
AsyncTicket is a pattern easily added to your model and backed by recent MDrivenServers
Read about its background here https://blog.mdriven.net/doing-stuff-later/
The SysAsyncTicket
The solution on how to easily spin of any kind of work and to do it later – or async – is implemented by part model-pattern, part framework support and part MDrivenServer support. That being said it is important that you have versions from 2020-feb-28 or later for this to work as described below.
The contract that instructs the system that you want this ability is fulfilled by adding a class that is defined like this:
- Named SysAsyncTicket
- Has attribute DeleteTime with DateTime-nullable type. This will be set by the server after your work has executed to Now+KeepReceiptMinutes.
- Has attribute Done with DateTime-nullable type. This will be set by the server when work is done.
- Has attribute Error with string (nullable optional) type. If there is an initial issue with the ticket – like if the RootId is not valid, or the ViewModel is not existing you will see this property filled with information.
- Has attribute ExecuteEarliest with DateTime-nullable type. If you want a delayed start you can set this – but leave to null for the server to execute it as soon as possible.
- Has attribute KeepReceiptMinutes with Integer type – with an initial value set to your liking. Signals that the auto cleaning of a used ticket should happen X minutes after the job finishes.
- Has attribute RootId with string (nullable optional) type. This is resolved and set by the framework to the external id that the RootObject association points to. If it points to a yet unsaved object the framework will discover this and set this property after a valid key is retrieved. If this extra pass was needed the framework will automatically resave the SysAsyncTicket with the updated rootid property.
- Has attribute ViewModel with string (nullable optional) type. This must be a valid name of a ViewModel existing in your model – it does not need to be a serverside-viewmodel. Any rooted-viewmodel will make do. You should use the constants found on the class, ie: ticket.ViewModel:=YourClass.ViewModels.SomeViewModelName
- Has a transient(Persistent=false) single association RootObject navigable in the direction of the most abstract class you ever want to use for async work (ie the SysSuperClass in a standard model). It is important that this link is set to Persistent=false since pointing out a hyper-abstract-class in a persistent association is really bad practice, as it would require the framework to ask all possible subclasses if they have the key (this process is called exactification of a foreign key). In a system with hundreds of classes this means hundreds of queries – ie do not set persistent links to abstract classes if the key is stored outside the abstract class – it will work but it will hurt performance.
Once you have this in your model and the server sees it – the server will create 2 new administrative serverside jobs. One job is looking for SysAsyncTickets that has null in the Done attribute. This job has high frequency – just like a key assigning job would have – but it is more ok for the SysAsyncTicket-job since there is only one of it. The other job deletes tickets that has a DeleteTime older than now – this job has a very low frequency.
The high frequency SysAsyncTicket job will look up the root object from RootId – look up the referred ViewModel – and then execute the viewmodel just as a normal serverside job. Typically this means it will execute the actions on the root-level in order from top to bottom – and then save and changed state that came out of those actions.