Connect Mendix with REST-DB for Backup

Part 3

Max Bareis
4 min readDec 8, 2020

< Part 2

Putting things together

In Part 1 of the series we created a Data Model which content needs to be saved on a different server. We have chosen restdb.io as our target DB and have setup the rest in- and output methods in Part 2. Now we will create the mechanisms to backup the actual data and the ability to restore the backed up data from the backup overview.

We will use JSON as our backup structure. All we need to do, is to create a mapping of the Person entity to JSON with the address as subentry. We write the JSON into the changes entry. When we retrieve the PersonJSON we have to be sure only to create missing entries and change the existing. For that we need a key for Person and Address. Unfortunately the entries in Person can have duplicate values so we need to add an ID to the Person entity (If you want to see a cool feature make sure you have some entries in Person before you add the AutoNumber field):

Add a column to the Person_Overview page and choose PersonID as attribute. If you had some entries in the DB you see that they received their IDs automatically…

Now open the existing Message_definition file and add a Person entry. Press Expand all and then Check all. Press the Generate mappings button and again choose both import and export.

Open the Person_Import file and Select elements. Check the Person ID. You see on the overview page that PersonID mapping has a red dot. This is because it is a autonumber and can therefore not be set. But we can do better things with it. Double click the grey person mapping and change Method to Find an Object (by key). Leave if no object was found to Create, map PersonID to PersonID and mark PersonID as key:

Now open Address mapping and also change Method. I now hereby declare a street, zip, city is always a street, zip, city and may not be duplicated. So we mark all fields as key. Now, if an address has all three values the same it must not be created.

The mapping page now should look like this:

It’s time to put real data in our changes field of the backup. Open the EXE_Backup microflow and add these actions to the beginning of the workflow:

Thats it for the backup part.

Now add a button to the buttonGrid of Backup_Overview and choose as onClick event Call a microflow with the new microflow UPD_Changes. Press show and OK to jump directly into the microflow:

That’s it. Time for some testing. First you need to backup. Then you should see an entry in the Backup Grid. Make some changes to your address / name etc. Select the backup and press restore to selection button. Now the changes should be undone.

This solution works only for simple datamodels without generalisations. But for small projects I can imagine a lot of development possibilities. For example the changes could really be changes of a certain period, or we use it as history for the entities.

--

--

Max Bareis

Full Stack Developer. Building digital things from the early 90s until now. Currently focused on low code development.