Why ServerSide jobs?

ServerSide actions are used when you want to delegate work to the MDrivenServer.

Reasons for delegating to the MDrivenServer might be that you want 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 colour green edit area to edit ServerSide execution.

ServerSide settings

Setting	Explanation
Interval	How often is this 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 this many at most - -1 is unlimited.
Pre EAL	Action language that will be executed before PS-OCL. One example of usage is: You do not need anthhing here but a good example is if you want to limit on 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 it's 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 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: 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 like this:

Create access groups - in this example

• DebugAccess (enabled when a 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 enabling access for the DebugAccess and ServerSideAccess groups.

The effect of this setup: the admin or developer users can access the ServerSide ViewModels for testing using one access group, and the server accessing the ViewModel ServerSide using another access group. Users not logged in (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 it to do, check these things:

1. Does your OCLPS actually find the objects you expect?
2. If you see this in the log: "Skipped <actionsname> due to enable==false <Viewmodelname> touched 0 objects"
   1. Check the Disable expression
   2. Check the access groups affecting the view, or the default access group if you have that