Synchronize data between MDriven systems
You can synchronize selected data between two MDriven systems by sending tabular data from a sending ViewModel to an import seeker in a receiving ViewModel; this page is for developers designing offline, distributed, or integration scenarios.
Choose what moves and in which direction
Define the data flow before you implement it. Synchronization works best when you explicitly decide which system sends each data set and which system receives it, rather than attempting a fully automatic synchronization of every object.
For example, an offline MDriven-based system with a local database can send selected changes to a central Turnkey system when a connection is available. Define separate sending and receiving ViewModels for the data that must move. If the data has different structures or dependencies, divide it into multiple ViewModels.
Keep the receiving and sending ViewModels compatible by name matching. The sender produces tabular data, and the receiver imports that data through its seeker.
Build the receiving import seeker
An import seeker is a ViewModel seeker that identifies an existing object from the first input column and updates the remaining editable columns.
- Create a seeker ViewModel in the receiving model.
- Define the seeker criteria that finds the receiving object. The first input column is always the key used by this search.
- Add the columns that the import may write to the seeker result grid, and make those columns editable.
- Make the default seeker field,
vSeekParam, multi-line so that it accepts multiple lines and tab-separated values. - Add a ViewModel action named
CreateNewwhen an input row whose key is not found must create an object.
For example, the following input has a key in the first column and a value to update in the second column:
793e00a1-7e61-4261-a2ed-7e9047e2c5c4 My new value 1
6d47193c-e4b9-486b-827d-104e01466a81 My new value 2
The seeker searches for each key and writes My new value 1 or My new value 2 to the corresponding editable result column. Read-only result columns are skipped.
If a key is not found, the import logic looks for CreateNew. When that action exists, it creates an object and adds it to the search result before applying the row data. Without CreateNew, do not treat an unmatched row as an insert.
Handle key types
The standard seeker parameter is vSeekParam : String. When the first-column key is a GUID or an integer, define the matching additional variable so that the seeker can use the typed value:
| Key type | Variable to define |
|---|---|
| String | vSeekParam : String
|
| GUID | vSeekParamAsGuid : Guid
|
| Integer | vSeekParamAsInt : Integer
|
This avoids comparing a string seeker parameter with a GUID in a seeker query that is translated to SQL.
Send, apply, and save
After the receiver is defined, the sending system prepares the selected data as tab-separated rows. To apply a batch, set the receiving ViewModel's vSeekParam to that tabular data, execute the seeker search, and save.
For recurring batch loads or updates, use server-side ViewModels; manual runs can use the debugger.
Preserve model rules during synchronization
Treat synchronization as a data-changing use case in the receiving model. Imported data must continue to respect business rules, derivations, access groups, user authorization, association updates, merge and update behavior, inserts, and transaction handling.
For example, if an imported value is governed by a model rule, apply the data through the receiving ViewModel rather than bypassing the model's behavior. Use AccessGroups and ViewModel-Enable to control whether a user can perform persistent changes through the receiving ViewModel.
Distinguish the synchronization mechanisms
| Need | Mechanism | Example |
|---|---|---|
| Move selected records between two different MDriven systems | Sending and receiving ViewModels with a tabular, keyed seeker import | An offline local database sends selected records to a central Turnkey system. |
| Keep multiple clients aware of changes in one MDrivenServer-backed system | Client synchronization managed by MDrivenServer | A user sees updates made by another client without refreshing the complete business-object cache. |
| Replicate MDrivenServer data to slave servers | MDrivenServer Master/Slave synchronization | A Slave receives commit-blocks and evolves its model when the Master model checksum differs. |
Master/Slave synchronization requires the Slave to apply commit-blocks using the correct model. MDrivenServer scaling describes how MDrivenServer manages commit-block handling, rerouting updates to the Master, and model evolution for Slaves.
Integration boundary
MDrivenServer also provides JSON-based access for non-MDriven applications that perform CRUD operations on model data. Define the system-specific contract, mapping, direction, error handling, and scheduling for an external integration before treating it as a synchronization flow.