Background
AsyncTicket is a pattern you can easily add to your model, backed by recent MDrivenServers.
Read about its background here: Doing Stuff Later
Note: This feature is only available for the MDriven Server.
The SysAsyncTicket
The solution to how to easily spin any kind of work and 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.
SysAsyncTicket
Attributes
DeleteTime: DateTime?
This will be set by the server after your work has been executed to Now+KeepReceiptMinutes.
Done: DateTime?
This will be set by the server when work is done.
Error: String?
If there is an initial issue with the ticket – like if the RootId is not valid, or the ViewModel is nonexistent - you will see this property filled with information.
ExecuteEarliest: DateTime?
If you want a delayed start you can set this – but leave it to null for the server to execute it as soon as possible.
KeepReceiptMinutes: Integer=10
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.
RootId: String?
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.
ViewModel : String?
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 in the class, ie: ticket.ViewModel:=YourClass.ViewModels.SomeViewModelName
RootObject: Transient SysSuperClass
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. 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 – i.e. 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 will be looking for SysAsyncTickets that have null in the Done attribute. This job has a 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 have 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 then save the changed state that came out of those actions.
Updates 2020-03-03: No Need for a ServerSide ViewModel - Just Use a Method
Wouldn't it be neat if we could skip the ViewModel step for really small async cases like the number assignment above?
Yes! You can now send the Class.Method in the ViewModel property. The MDrivenServer will execute the method for the root object. However, it will first check the PreCondition of the method.
Given this, the sample above would skip the ViewModel+action and instead add a method on the Customer class:
Customer.AssignNumber: SomeSingleton.oclSingleton.LatestUsedCustomerNumber:=SomeSingleton.oclSingleton.LatestUsedCustomerNumber+1; self.CustomerNumber:=SomeSingleton.oclSingleton.LatestUsedCustomerNumber
Consider having the precondition of the AssignNumber method set to: self.CustomerNumber->isNull
And the ticket:
let ticket = SysAsyncTicket.Create in ( ticket.RootObject:=self; ticket.ViewModel:=’Customer.AssignNumber’ -- This will call the AssignNumber method on self of type Customer, in the server context )
Note: Invoking a method differs from invoking a ServerSide-ViewModel as below.
let ticket = SysAsyncTicket.Create in ( ticket.RootObject:=self; ticket.ViewModel:=Customer.ViewModels.SomeViewModel -- This will invoke the SomeViewModel-ServerSideViewModel with self of type Customer as root )
Updates 2020-07-01
Add the Priority Property to the SysAsyncTicket class:
Priority:integer?
If found, the OCL-PS query will include ->orderby(at|at.Priority) and this will push jobs you know are short and should be done asap to the top of any queue that may form. 1 has a higher priority than 10 and 1 will be taken from the queue before 10 if both are present at the time of decision.
Download a Ready Package to Merge Into Your Model
Gotchas
Executing a Method on a Subclass
If you produce a SysAsyncTicket to execute a method like this:
let ticket=SysAsyncTicket.Create in (
ticket.RootObject:=self;
ticket.ViewModel:='Thing.AssignNumber'
)
The actual type of self is not a "Thing" but rather a "SubClassOfThing" - then you run into trouble with Synchronization. To avoid trouble, name the reference on what to execute like this:
ticket.ViewModel:='SubClassOfThing.AssignNumber'
The problem is that the MDrivenServer would, in the first case, treat your object as a Thing (formally correct) and the changes recorded for Synchronization will assume it is an object of class "Thing" that has changed. When your client refreshes the server's data, they will be notified that a "Thing" with identity X has changed and your client will not be able to associate that to your object of class "SubClassOfThing".
The generic way to name the reference to execute is:
ticket.ViewModel:=self.oclType.asstring+'.AssignNumber'