You can use MDrivenServer to receive an MDriven Designer model, maintain the relational database schema for that model, and make the model data available to MDriven-based and other applications.
What MDrivenServer does
MDrivenServer runs the server-side representation of your model. When you upload a model from MDriven Designer, MDrivenServer creates or evolves the database schema it uses to store the model data.
For example, if you add a class named Class1 and upload the model, MDrivenServer adds storage for objects of that class. If you then add attributes to Class1 and upload again, it changes the schema to store those attributes. An association, such as one between Class1 and BrandOfCar, causes MDrivenServer to add storage for the database-level foreign key that represents the association.
By default, the installed MDrivenServer uses a SQL Server Compact Edition database. You can configure MDrivenServer to use another database, including SQL Server in Azure, by supplying a connection string. See HowTos:Configure and Maintain MDriven Server for configuration and maintenance guidance.
Upload a model and verify the server
Use this development workflow to put your current model under MDrivenServer control:
- Start an MDrivenServer instance and select it as the active server in MDriven Designer's cloud-connection dialog.
- Select Upload model to send the current model to the active MDrivenServer.
- Select Check Server Status. If the upload has only just completed and the response is incomplete, wait briefly and select it again.
- Confirm that the status reports the database creation or the schema changes made for the uploaded model.
- Open the MDrivenServer Web UI and inspect the uploaded model and its data when required.
In the local training setup, the MDrivenServer Web UI is available at http://localhost:5000. In the Web UI, choose Running and then Model to confirm that the model has been uploaded. Choose Running and Data in A0 to browse data for a class.
For the complete local-server setup, active-server selection, model upload, and data-migration walkthrough, follow Training:Bootcamp:Chapter 14. For installation instructions, see HowTos:Installing MDriven Server on Windows or HowTos:Local Installation.
Understand schema evolution
MDrivenServer keeps the database schema aligned with the uploaded model. The following changes are reflected when you upload the model:
| Model change | Database effect |
|---|---|
| Add a class | Adds storage for objects of that class. |
| Add an attribute | Adds storage for the attribute. |
| Add an association | Adds storage for the foreign key that represents the association at database level. |
| Remove an attribute | Removes the corresponding column. |
| Remove a class | Drops storage for the class and removes association storage that is no longer needed. |
Important: Removing attributes or classes changes the database schema and can remove the corresponding stored data. Treat model uploads that remove model elements as database changes and verify them before using them against data you need to retain.
Work with persisted data
MDrivenServer exposes model data through multiple interfaces.
MDriven Framework PersistenceMapper API
Applications built with MDriven Framework can use the PersistenceMapper API to query and retrieve data in a multi-user environment. The API supports capabilities including:
- Create, read, update, and delete (CRUD) operations in transactions.
- Optimistic locking.
- Client synchronization.
- OCL queries executed as SQL in the database.
For example, an application can use an OCL selection to find a set of stored objects while MDrivenServer executes the query in the database rather than requiring the application to load all objects first.
JSON-based access
MDrivenServer also provides access to data as JSON objects. This allows a non-MDriven application to perform CRUD operations on data defined by your model.
Move existing development data
If you have been prototyping with XML persistence, you can migrate that data to MDrivenServer persistence:
- In MDriven Designer, start the system using XML persistence.
- Use Migrate and save the exported data to an XML file.
- Switch the system to MDrivenServer persistence.
- Use Migrate again, select the saved XML file, and save the imported objects and relations.
- In the MDrivenServer Web UI, choose Running and then Data in A0, select the relevant class, and select Search to verify the imported data.
Review the detailed migration steps and the singleton-data troubleshooting example in Training:Bootcamp:Chapter 14.
Run server-side work
MDrivenServer can execute periodic server-side actions. A periodic action selects objects, loads an associated ViewModel, executes the actions in its root ViewModel class, and saves changed state.
For example, a client can put an Order into an AssignNumber state. A server-side action can select orders in that state, assign each one a number, and save the result. This serializes the assignment on the server rather than relying on competing clients to choose the next number.
Define this behavior in the ViewModel Editor and update server-side jobs after changing them. See Training:MDrivenServer periodic server-side actions for the full pattern, including the use of SysAsyncTicket and the Realtime tagged value.
Secure and operate the server
Use HTTPS when MDrivenServer is reachable beyond a local development environment. HTTP does not enforce security limitations because sending passwords over an open connection is unsafe.
Configure authentication for the Admin UI and for the web interfaces that MDrivenServer exposes. When requiring Admin UI identification, ensure that you have a SuperAdmin user so that you do not lock yourself out. See Training:Security concerns for MDriven Server.
For deployment, maintenance, logs, and recovery topics, use HowTos:Configure and Maintain MDriven Server and Documentation:MDrivenServer log. When you deploy an application to users, run MDrivenServer and MDriven Turnkey on a server that those users can reach, either on an internal network or on the internet.