Why ServerSide jobs?
ServerSide actions are used when you want to delegate work to the MDrivenServer.
Reasons for delegating to the MDrivenServer might include wanting a single performer (i.e. synchronous execution). This is the case when assigning numbers that must be unique. Other scenarios include calling remote systems to update data or sending emails.
Activate ServerSide jobs for a ViewModel
On the ViewModel Root class, choose the action "Edit criterias for server side execute". You will then see a different green edit area in which to edit ServerSide execution.
ServerSide settings
| Setting | Explanation |
| Interval | How often this is checked by the server |
| Serialized Blocking | When true, the job should be small and quick - it is done within the main loop of server actions. If the job is long-running/slow, it is better to leave it as FALSE so that the server responds to admin events faster (evolve, check checksum, etc.) |
| Max Answers | The PS Ocl expression will return at most this many - -1 is unlimited. |
| Pre EAL | Action language that will be executed before PS-OCL. One example of usage is:
You do not need anything here, but a good example is if you want to limit by a Time: vYesterday:=DateTime.Today.AddDays(-1) -- vYesterday must be a ViewModel variable You can also use this to set something in your model that changes an Access Group that enables this viewmodel to be processed serverside. |
| PS OCL | The expression the server will run every "Interval" seconds, just after the Pre EAL has executed. The result from the expression should be a list of objects of the same class that your ViewModel root has.
For each item in the result, a ViewModel will be created and its actions will be executed in order from top to bottom. Any changed data will be automatically saved to the database. |
Example:
Server Global variables
You can set global variables for a MDrivenServer; see this page for more information Server Wide Variables.
Access group and Restricting Access
You can restrict access to a ViewModel using tagged values and access groups.
Use UIAllowed to disable access from a user's UI by setting it to false.
But you can also use accessgroups to have more precise control over when access is allowed.
The problem is: if you set access groups used by logged-in users, the ViewModel used to execute serverside will not be available to the server itself. An executing serverside ViewModel does not have a logged-in user.
The solution to this problem is to use the Pre EAL to set "something" that you then use in the OCL to enable an access group that has the right to use the ServerSide ViewModel.
For example, as follows:
Create access groups in this example:
- DebugAccess (enabled when an administrator is logged in)
- ServerSideAccess (enabled when the server is running)
In this example, SysSingleton has an added Boolean attribute, ServersideAccess.
By having the same expression on both "Visible expression" and "View Enable Expression", the ServerSide execution can access the ViewModel and run its actions.
Then, in the ViewModel, set the Boolean attribute in SysSingleton to enable the access group when running.
This is the ViewModel - Access Groups settings that enable access for the DebugAccess and ServerSideAccess groups.
The effect of this setup is that the admin or developer users can access the ServerSide ViewModels for testing using one access group, and the server can access the ViewModel ServerSide using another access group. Users who are not logged in (and are not in any of these access groups) will be unable to access the ViewModel.
Troubleshooting
If your ServerSide actions don't do what you expect them to do, check these things:
- Does your OCLPS actually find the objects you expect?
- If you see this in the log: "Skipped <actionsname> due to enable==false <Viewmodelname> touched 0 objects"
- Check the Disable expression
- Check the access groups affecting the view, or the default access group if you have one