Bi-Directional Sync AND Upload Only Sync

[fishtech]

Hi,

We have approx 3.5GB in 3 files. The data changes quite a lot.

My users go into the field with laptops, gather data and do a full, bi-directional sync. This sync works great, but can sometimes take considerable time depending on how much data has been changed/gathered on the server since the last sync.

Is is possible to create a second sync option so that, in addition to 'Full Sync', the user would have an 'Upload Only' sync option. They could use the latter to quickly offload their gathered-data to the mothership.

It looks like the section in the documentation called "Can I have different sync scripts to sync different tables?" indicates this can be done by creating a second configuration, but it's not explicit. I am double-checking before getting myself in trouble :).

One question I have is if the database has 2 configurations does it matter which is used to create a download link? Also there must be duplicates of the MirrorSync scripts/folders... does each config have it's own folder name?

Thanks,

ft.

[Ocean West]

I believe that is the intent of the add-on configurations so that you can do limited syncs either directional or bi-directional.

or tie a sync logic to a particular workflow. clicking a button does a limited sync for a subset of data, before you can proceed to another task.

In MS 5 there is a new feature that allows you to initial sync server side where it would create a clone hosts it and do initial sync server side based on your logic then deliver to the user the file intact it could greatly increase initial speed of first sync - however good bandwidth would be ideal for delivery of the file.. 

[NateJames]

I can answer the second part.

During setup you provide a name for the second sync configuration, so mirror sync will append that sync name to the new sync scripts. So you will have to paste the additional scripts into your file as normal. In my testing it doesn't seem to matter which one you distribute for your download link, because your triggering 2 different sets of scripts.

For your first question I have struggled and have had some good discussions and have multiple trial and errors to setup exactly what your looking to do. MirrorSync imho really needs to clarify having multiple sync configurations on one application. One technician says you can't have the same tables in each sync configuration, but in the advanced setup it says you can. 

 

I too want to set up exactly what your saying and my lack of understanding and having to infer what is going on has been painful.

I can tell you that I tried to be clever and have my one way sync run at startup. And this is BAD (unless you create a skip on first run step to bypass this first initial one way sync). My one way sync was filtering the user data, and once completed the 2 way sync was no longer functional and would fail. (If you run the 2 way first which also has the same filters because its a "full" sync, than I have had no issues with running a one way sync (spoke --> host) later on).

😀One thing to share with you also, that I recently caught and makes sense. If you have large attachments and containers and those records get modified. Your users end up having to redownload the container. That might help your field guys if your solution uses a lot of containers, and for example you have a photo gallery full of cat photos and user manuals...Then you may be downloading them all the time

• Quote

  Container fields are transferred when any field on the same record is changed, even if the container has not been modified. To prevent unnecessary container syncing, move container fields to their own table, so that they will only be transferred when they are changed.

   

 

[NateJames]

On 3/5/2019 at 8:36 AM, Ocean West said:

In MS 5 there is a new feature that allows you to initial sync server side where it would create a clone hosts it and do initial sync server side based on your logic then deliver to the user the file intact it could greatly increase initial speed of first sync - however good bandwidth would be ideal for delivery of the file.. 

Caveat to that method that is not talked about very well... if you are using SQL filtering using say the MIRRORSYNC_USERTOKEN. The server file does not know what the MIRRORSYNC_USERTOKEN is

example is I am filtering timesheets to only give the user there timesheets and no other. than my sql statement is

where (id_staff = '{MIRRORSYNC_USERTOKEN}' )

but the initial sync on server will never know the token and well it doesn't work than.

 

Fishtech,

I have struggled half the morning with coming back to trying and setup multiple configurations for one file. I tried

3 configurations in my file and did not have the same tables in any of the configurations

my 3rd sync was a one way with 2 tables (products and product images). I was able to do one initial 2 way sync, and than tried the one way product sync (initial). It failed miserably. 

I would suggest staying away from multiple configurations until MS tells us otherwise. 

[fishtech]

Please can we have clarification from 30Works whether 2 MirrorSync configs can be created in the same solution as follows:

 

Sync Config 1 -  Bi-Directional sync, all tables

Sync Config 2 - Upload-only sync (from Spoke to Hub) including only a subset of tables from Config 1.

 

Thanks,

ft 

[SolutionPronto]

I have a situation where I am wanting to sync invoices out in the field back to home office every day.  and only do a customer list bi directional once a week.

[Jesse Barnum]

Hi everybody - sorry that I did notice this discussion thread, thanks Nate for bringing it to my attention.

MirrorSync SHOULD support multiple configurations for the same (or different) set of tables. For instance, you should be able to have one configuration does table A, B, and C bidirectional, and a second configuration with just a one-way sync from spoke to hub for tables A and B.

When you set up multiple configurations this way, you'll end up with multiple MirrorSync scripts, one for each configuration.

As noted by Nate, I would definitely recommend running the full bidirectional sync during the initial sync process, and then using a combination of bidirectional and one-way syncs for incremental syncs after the initial sync completes. If you do that and it's still failing, please submit a problem report so that we can review the log file.

Also, when using the new server-side initial sync feature in MirrorSync 5, we are using JDBC to communicate with the spoke database (because it's faster for write operations, and we're assuming we'll need to do a lot of writes on the initial sync). That means that the customization script does not run for that initial sync on the spoke side, which explains why the MIRRORSYNC_USERTOKEN does not get set. MirrorSync 6 will get rid of JDBC altogether and use the Data API instead, so this will fix the issue.