You can use MDrivenServer periodic server-side actions to find model objects on a schedule and execute ViewModel actions for each selected object; use them when work must run centrally rather than in one user's client.

MDrivenServer also calls these jobs server-side jobs or periodic actions. They are the same capability: MDrivenServer periodically evaluates a selection expression, loads a ViewModel for each selected object, executes the actions in the ViewModel root, and saves resulting changes.

When to use a server-side job

Use a server-side job when an operation must be performed by MDrivenServer, including when it must be coordinated across users or should not block UI work.

Typical uses include:

• Move an object to its next state when its conditions are met.
• Perform asynchronous work requested by a user.
• Assign values, such as order numbers, in one central server-side flow.
• Start import or export-related work. For importing from another SQL source, see Training:Import data from other SQL servers.

A job is not a client-side ViewModel periodic action. A ViewModel periodic action runs in the client/ViewModel context. A MDrivenServer job runs on MDrivenServer and is commonly paired with a client refresh mechanism when the client needs to observe the result.

How a job runs

A server-side job has two essential parts:

Part	Purpose	Example
Selection expression	Selects the objects that need work.	o.State='AssignNumber')
Server-side ViewModel	Defines the object cluster to load and the actions that MDrivenServer executes for every selected object.	An Order-focused ViewModel whose root actions assign a number and change the state.

For every object returned by the selection expression, MDrivenServer loads the associated ViewModel. It executes the actions found in that ViewModel's root, in order, and saves changes made by those actions. Define the ViewModel to include the object graph that the actions need. This avoids loading an insufficient or unnecessarily broad object cluster.

For example, an action that changes an Order and reads a related customer must have a ViewModel that makes the required Order and customer data available to the action.

Create a periodic server-side job

Create the model logic in MDriven Designer, then publish the model and update the server-side jobs on MDrivenServer.

1. Create a ViewModel for the server-side work. Make its root class the class selected by the job, such as Order.
2. Add the attributes, associations, nestings, and other ViewModel content required by the action logic.
3. Add the root actions that MDrivenServer should execute. Put the actions in the intended execution order.
4. In the ViewModel Editor, choose Edit criterias for server side execute. Enable the ViewModel for server-side execution.
5. Set the selection expression that identifies the objects to process. For example:

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

6. Set the interval at which MDrivenServer checks the selection expression. For example, an interval of 20 seconds means that the server checks for qualifying objects every 20 seconds.
7. Save and upload the model to MDrivenServer.
8. In the MDrivenServer web interface, update the server-side jobs. The new ViewModel should then appear under Periodic Actions.
9. Verify the job by checking its execution indication and log, or force it to run from the Periodic Actions view when you need to test it.

The server schedules jobs according to their intervals. If several jobs are due, do not assume that all queued work will run at once; design every job so that it can be executed repeatedly and safely.

Example: assign an order number centrally

Number assignment is a common reason to move work to MDrivenServer. A client cannot safely decide that it owns the next number when multiple users can request numbers at the same time. Instead, use a state transition to request the work and let one server-side flow perform the assignment.

Model the request and completion states

Give Order a state that represents the request and a state that represents completion. This example uses:

State	Meaning
AssignNumber	The client has requested a number.
NumberAssigned	The server-side job has assigned the number.

Also give the order an attribute for the assigned number.

Configure the server-side ViewModel

1. Create an Order-based server-side ViewModel.
2. Add root actions that assign the next number and set State to 'NumberAssigned'.
3. Enable server-side execution and use this selection expression:

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

4. Set an appropriate job interval, upload the model, and update server-side jobs on MDrivenServer.

Let the client request and observe the work

1. Let the user invoke a client action that sets the order state to 'AssignNumber'.
2. Show that work is in progress while the order remains in that state.
3. If you use client polling, add a client periodic action that executes selfVM.Refresh.
4. Set that periodic action's EnableExpression to self.State='AssignNumber'. The client then refreshes only while it waits for the server result.
5. When the server-side job changes the order to 'NumberAssigned', the next refresh shows the number and the UI can hide the progress indication.

This pattern keeps the user request separate from the central assignment operation. The selection expression finds pending orders, and the changed state prevents an already completed order from being selected again.

Recommended update pattern

For the number-assignment pattern, mark both the state attribute and the number attribute with the tagged value Realtime. This removes the need for a client periodic action that polls with selfVM.Refresh.

Combine the request with SysAsyncTicket and reduce or remove the frequency of the server-side job execution as appropriate for the asynchronous flow. Server-side jobs remain useful for scheduled and centralized processing; the ticket-based trigger avoids relying on frequent client polling to show completion.

Design guidelines

• Make the selection expression select only objects that still need processing. A state such as 'AssignNumber' is a clear work-queue condition.
• Make the root actions move an object out of the selected condition when processing is complete. Otherwise the job will select it again on the next check.
• Keep the ViewModel focused on the data the actions need. The ViewModel is the load definition for the object cluster processed by the job.
• Treat each execution as repeatable. A scheduled job can be invoked again, so state-based conditions and completion transitions are important.
• Use server-side work for shared coordination and lengthy work rather than tying it to the UI execution path.
• Inspect Periodic Actions after publishing a model to confirm that the job was created and is executing. Use the job log when diagnosing failures.

Troubleshooting

If a job does not appear or does not perform work, check the following:

1. Confirm that the ViewModel is enabled through Edit criterias for server side execute.
2. Confirm that the selection expression currently returns objects. For the order example, at least one Order must have State='AssignNumber'.
3. Confirm that the model was uploaded and that server-side jobs were updated in the MDrivenServer web interface.
4. Confirm that the ViewModel root contains the actions expected to run and that it loads the required object cluster.
5. Review the periodic-action execution information and log. For detailed diagnosis, see Documentation:Debugging MDrivenServer Serverside actions.

See also

• Documentation:Serverside jobs
• Documentation:Periodic action
• Documentation:Debugging MDrivenServer Serverside actions
• Training:Import data from other SQL servers
• HowTos:Configure and Maintain MDriven Server