Server-side actions let you configure a ViewModel for execution by MDrivenServer, for work that must run centrally rather than in an individual user interface.

When to use server-side actions

Use a server-side action when MDrivenServer must perform work for the application. A server-side job can run periodically or in response to an application-triggered mechanism such as a SysAsync Ticket; see Documentation:Serverside jobs.

Typical uses include:

• Serialize shared work. Assigning the next unique order number must have one performer when many users can request a number at the same time.
• Call external systems. Let the server update a remote system without relying on a user keeping a client open.
• Send email. Prepare the email data in a server-side ViewModel and let MDrivenServer send it. See Documentation:Emailing from an app using MDrivenServer.
• Move objects through a workflow. Select objects in a waiting state, perform actions on them, and save their new state.

For example, a client can set an Order state to AssignNumber. The server-side selection can find orders in that state:

Order.allinstances->select(o|o.State='AssignNumber')

The server-side ViewModel actions assign the number and change the state to NumberAssigned. Because the server performs this work centrally, requests are serialized without making each client choose the next number. For the full periodic-action pattern, including client updates and the Realtime recommendation, see Training:MDrivenServer periodic server-side actions.

Configure a ViewModel for server-side execution

A server-side job needs a ViewModel that loads the objects to process and contains the actions to perform on those objects.

1. Open the ViewModel in MDriven Designer.
2. Select the ViewModel root class.
3. Choose Edit criterias for server side execute.
4. Define the server-side selection criteria in the green server-side editing area. The selection must identify the objects the job should process.
5. Add the actions on the root ViewModel class that should run for the selected objects. The periodic-action logic loads the ViewModel, runs the actions it finds on the root ViewModel class, and saves changed state.
6. Configure the corresponding job execution as described in Documentation:Serverside jobs.

Keep the selection narrow. For example, select orders waiting for number assignment rather than all orders. A narrow selection reduces unnecessary loading and avoids repeating work on objects that are already complete.

Control access to a server-side ViewModel

You can restrict a ViewModel with tagged values and access groups. This requires special handling for server-side execution: an executing server-side ViewModel does not have a logged-in user.

UIAllowed

Set the UIAllowed tagged value to false when users must not open the ViewModel from the user interface. This does not replace access control; use access groups when you need to control who, or what context, can use the ViewModel.

Separate developer access from server access

Do not rely only on an access group that is enabled for logged-in users. If that is the only group allowed, the server cannot access the ViewModel because the server execution has no logged-in user.

Use two access groups instead:

Access group	Enabled when	Purpose
DebugAccess	An administrator or developer is logged in	Lets authorized people open and test the ViewModel.
ServerSideAccess	The server-side ViewModel is executing	Lets MDrivenServer load and run the ViewModel without a logged-in user.

One way to implement this pattern is to add a Boolean attribute named ServersideAccess to SysSingleton.

1. Create the DebugAccess and ServerSideAccess access groups.
2. Configure DebugAccess to be true for the administrator or developer context.
3. Configure ServerSideAccess from the SysSingleton Boolean attribute.
4. In the server-side ViewModel, use Pre EAL to set the Boolean value used by the ServerSideAccess group before the job actions run. EAL is the action language used for this setup.
5. Give the ViewModel both DebugAccess and ServerSideAccess in its access-group settings.
6. Apply the same access condition to both Visible expression and View Enable Expression.

The result is deliberate separation: administrators and developers can test the ViewModel through DebugAccess, MDrivenServer can execute it through ServerSideAccess, and users in neither group cannot access it.

Use server-wide variables for environment-specific behavior

Server Wide Variables give a server-side ViewModel values that differ by environment. Declare a server-wide variable in MDrivenServer, then add a variable with the same name to the server-side ViewModel. The Server Wide Pre EAL runs before the rest of the job actions.

For example, use a variable to distinguish production from a non-production environment. Your job can then hold back an export outside production, or direct it to a different external system. Server-wide variables also support special variables for skipping a job query; see Documentation:Server Wide Variables for the exact names and behavior.

Troubleshoot a server-side action

Start by confirming that the job selects the objects you expect and that the ViewModel is allowed to execute.

1. Check the server-side selection expression. Confirm that it returns the expected objects in their current state.
2. If the log says Skipped <actionsname> due to enable==false <Viewmodelname> touched 0 objects, check the action's Disable expression and enable conditions.
3. Check the ViewModel access groups, including any default access group. Confirm that the server-side access condition is true during server execution.
4. Check that the selected objects satisfy the intended state and that the server-side actions change that state so the same work is not repeatedly selected.
5. Review the execution history and logs using Documentation:Debugging MDrivenServer Serverside actions. That page describes the periodic-action administration page, WorkInfo timing view, log correlation, and error handling with root ViewModel columns beginning with ErrorInfo, ExceptionInfo, and an OnException action.

When an exception occurs in a server-side ViewModel, changes made before the exception are rolled back before the documented error handling runs. Add the error-information columns when you need to retain diagnostic details in the model.

Related execution options

Server-side actions are part of the broader action model. Use a server-side job when work should be scheduled or handled centrally. For immediate execution of a server-side ViewModel from an OCL expression, see Documentation:OCLOperators RunServerSideViewModelNow.

See also

• Documentation:Serverside jobs
• Training:MDrivenServer periodic server-side actions
• Documentation:Debugging MDrivenServer Serverside actions
• Documentation:Server Wide Variables
• Documentation:Emailing from an app using MDrivenServer