Creating Custom Sync Providers RRS feed

  • Question

  • Howdy from Texas!

    Here is the scenario that I am working with.  I've been tasked to build a synchronization program, which is a WPF desktop app, that will sync data from Microsoft Dynamics WCF endpoint to a SOAP Web Services (ASMX) compliant web-service.  I do NOT have control over these end points.   Love that I found the Microsoft Sync Framework, but as I dig down into it, more and more, it seems that no-one is using it to sync data between web services and WCF end points, everything is about file system or db.  Is utilizing Microsoft Sync Framework in this way, with Web Services and WCF layers on top of the DB recommended?

    If it is recommended, which I'm sure it will be, because it clearly says in the marketing literature, that it can sync any data from any source.  So, I dig down into the code.  Looks like I'm going to have to write a custom sync provider to talk to both the Web Service and WCF that I want to sync  between.  Are there existing sync providers to talk to WCF or WebService end points that know how to leverage the proxy code that VS creates?

    If so, where do I find them?  If not, I'm not having much luck finding anything about creating Custom Sync Providers that really explains the class structure, flow or requirements very well.  I'm currently using VS2010 Class Diagram tool and looking through a lot of sample code to try to make sense of it.  Is there any good resources that discuss creating custom sync providers that talk to Web Services or WCF?  If not, can we start a thread to help others?


    • Edited by BCSATXMatt Wednesday, May 22, 2013 9:27 PM
    Wednesday, May 22, 2013 9:15 PM

All replies

  • before you explore writing a custom provider, have you figured out how to track changes on your data sources? how do you know which records has changed since the last sync?
    Thursday, May 23, 2013 12:24 PM
  • I'm not sure these statements fit into the nomenclature of Microsoft.Synchronization, but hopefully you will get the gist.  In our sync, there are a number of different data objects and by the object type, one side of the sync has authority.  We don't have a unique syncID by row or anything like that.  For about half of the objects, one side of the sync is the authority, and for the rest, the other participant has authority.  So in a lot of ways, our program is just a fancy data copy, but we want to avoid duplicates and for that, we have different columns by authority for the datatype that will give us what we need to say yes or no to creating/deleting or over writing the record.    

    We aren't tracking anything about what was sync'd.  Based on authority and some custom fields, we sync or not.  Given that, we don't really need to keep track of what record has changed, accept in a situation where we have a conflict and even in those cases, we will just assume the side of the sync that has authority for that object becomes the new data and over write the non-authoritative data.  The entire part of the Microsoft.Synchronization namespace that deals with Metadata and its storage, we don't need.  

    Why I originally thought we would use a simple custom provider.  However, when I dug further into the requirements of a simple custom provider, it says it only syncs 1 type of data.  That has me scratching my head as well.  Since a requirement of a simple custom provider is that it only sync 1 type of data, and I have about 15 different types of data to sync, do I build 15 simple custom providers or do I create a managed custom provider that can handle these 15 different types of data?  

    Then add onto that, one of the sync servers, I access via a webservice, the other side I access via WCF.  

    I'm I barking up the wrong tree here thinking about using Microsoft.Synchronization? 

    • Edited by BCSATXMatt Friday, May 24, 2013 8:06 PM
    Friday, May 24, 2013 7:13 PM
  • just to clarify, you want to compare records from one copy to the other and if they are different, sync them? (like tablediff in SQL?)

    Sync Fx is primarily on "incremental syncs" or synching what has changed since the last sync.

    what you have is what i would normally refer to as "differential sync", scanning one copy and comparing to other, if different, decide on how to reconcile the copies.

    i think you'll be better off trying other solutions than weaving your way how to make that work in Sync Fx. 

    a custom app or SSIS may be a better fit.

    Monday, May 27, 2013 5:27 AM
  • Howdy,

    I VERY much appreciate the feedback.  Not to beat a dead horse, but I'm going to give just a bit more detail and then get your recommendation again.  I'll do this by giving a case.  On the WCF side, we have a DB/WCF representation of a user that is different than the user representation on the DB/Web Services (WS) side.  The database schema of all data we are interested in syncing is different, as well as the WCF WSDL and Web Service WSDL definition of the user object.  This is true for all of the data we are interested in syncing.

    User Object - WCF Side has Authority

    Case 1 (create) - If WCF user has a custom field, for the user, defined and that field has value AND the user does not exist on the WS side, then create on the WS side.  

    Case 2 (delete) - If the WCF has a custom field defined and that field has no value and/or the is_inactive field has been set on the WCF side, and the on the WS side if the user exists, set the user to is_active=false on the WS side.  If the user does not exist on the WS side, do nothing.  

    Case 3 (update) - if the WCF user exists and the WS user exists, check 1 or more properties, if they are different, update the WS record with WCF record.  

    In this case, the WCF has authority.  We use the WCF side to populate the WS side with user/meta data initially, and then mostly the program pushes data from the WS side to the WCF side in the form of new records.  Again, hope that all makes some sense.  Still recommend that we don't use Microsoft Sync Framework?

    Tuesday, May 28, 2013 2:32 PM
  • your schemas are different, your change enumeration is different, your change application is different.

    with the amount of work you need to do to bend Sync Fx to make that work, you'll be better off writing a custom solution without using Sync Fx.

    Wednesday, May 29, 2013 1:15 AM
  • Very much thanks for taking the time to provide some assistance!  Much Appreciated!
    Wednesday, May 29, 2013 1:51 PM