locked
Synchronisation between Outlook and CRM App RRS feed

  • Question

  • Hi,

    we want to implement a prototype for synchronisation between Outlook and our CRM application (Database can be Access or SQL Server). So we have to check wheter the sync framework meets our needs. We now have some questions and hope that we can find the answers here.

    1. I think that it isn't possible to synchronise between an ADO.NET Sync Provider and a custom Provider.
    So we have to implement two custom providers: One for Outlook and one for our CRM application? Right?

    2. If we use two custom providers we also have differnt metadata. On the Outlook side for examle a ContactItem and on
    the other side an AddressItem (from our CRm App). What is the best way to connect these items? Does each proivder have to know what type of data it receives? And how is it possible to map the propertys of the different Items?
    The ManagedNTFSProvider-Sample didn't really help us because it uses the same providers and the same ItemMetdata.

    3. How can we identify which Outlook contact corresponds to which address in our CRM app based on criterias?

    Thanks you very much!
    Stefan




    Wednesday, December 12, 2007 10:05 AM

Answers

  • Hi Stefan,

     

    I think you are primarily on the right track, but let me see if I can clarify a few things for you.

     

    1) Sync Services for ADO.NET is for synchronizing relational database in offline or collaboration (peer to peer) scenarios.  The reason why you can not currently synchronize using the existing Sync Services for ADO.NET provider to a non-relational database (such as Outlook) is because this provider uses DataSets to exchange the data back and forth.  Since Outlook can not accept DataSets and does not have an ADO.NET interface this will not currently work.  We may choose to change the Sync Services for ADO.NET provider in the future to support synchronizing to non-relational data stores such as outlook. 

     

    Luckily, Sync Services for ADO.NET is built on top of the Microsoft Sync Framework runtime which means that you can still do synchronization between a relational database and Outlook (and in fact this exact scenario was demonstrated during our release at TechEd).  As such, you will need to create two providers.  One for your database and one for Outlook.  The one that connects to your database could use ADO.NET, ODBC, or whatever connectivity you like. 

     

    For Outlook, you might choose to use Outlook WCF

     

    Just as an aside we are working on packaging up this sample and will hopefully put it on our Microsoft Sync Framework Blog soon.  I do not yet have an expected date though.

     

    2) Yes, since these datastores keep the information in a different format you need to have a common mapping mechanism.  For our demo we chose to map everything to the VCard format for contacts but you can choose any mapping mechanism you feel is most appropriate for your needs.  Also for the database metadata store you might want to store the metadata right within the database.  That was as changes happen you can easily update the metadata.  For Outlook we chose to store the changes in some files simply because there was no convenient way of storing it within Outlook that we could think of at the time. 

     

    3) This is a really good question since Outlook does not give you a unique Primary Key for a contact that you can use to map the Outlook information to the database.  For us we chose to use the name as the unique value, but even that can be a poor choice since names can change.  If you can think of a required field that does not change that will be the best mapping field to use.

     

    I hope that helps,

    Liam

    Wednesday, December 12, 2007 5:29 PM

All replies

  • Hi Stefan,

     

    I think you are primarily on the right track, but let me see if I can clarify a few things for you.

     

    1) Sync Services for ADO.NET is for synchronizing relational database in offline or collaboration (peer to peer) scenarios.  The reason why you can not currently synchronize using the existing Sync Services for ADO.NET provider to a non-relational database (such as Outlook) is because this provider uses DataSets to exchange the data back and forth.  Since Outlook can not accept DataSets and does not have an ADO.NET interface this will not currently work.  We may choose to change the Sync Services for ADO.NET provider in the future to support synchronizing to non-relational data stores such as outlook. 

     

    Luckily, Sync Services for ADO.NET is built on top of the Microsoft Sync Framework runtime which means that you can still do synchronization between a relational database and Outlook (and in fact this exact scenario was demonstrated during our release at TechEd).  As such, you will need to create two providers.  One for your database and one for Outlook.  The one that connects to your database could use ADO.NET, ODBC, or whatever connectivity you like. 

     

    For Outlook, you might choose to use Outlook WCF

     

    Just as an aside we are working on packaging up this sample and will hopefully put it on our Microsoft Sync Framework Blog soon.  I do not yet have an expected date though.

     

    2) Yes, since these datastores keep the information in a different format you need to have a common mapping mechanism.  For our demo we chose to map everything to the VCard format for contacts but you can choose any mapping mechanism you feel is most appropriate for your needs.  Also for the database metadata store you might want to store the metadata right within the database.  That was as changes happen you can easily update the metadata.  For Outlook we chose to store the changes in some files simply because there was no convenient way of storing it within Outlook that we could think of at the time. 

     

    3) This is a really good question since Outlook does not give you a unique Primary Key for a contact that you can use to map the Outlook information to the database.  For us we chose to use the name as the unique value, but even that can be a poor choice since names can change.  If you can think of a required field that does not change that will be the best mapping field to use.

     

    I hope that helps,

    Liam

    Wednesday, December 12, 2007 5:29 PM
  • Thank you for your answers Liam!
    That's exactly what we wanted to know!

    Stefan


    Friday, December 14, 2007 8:11 AM
  • Hi Stefan,

     

    I have uploaded a sample that shows contact synchronization to Outlook.  I would be very interested in your feedback if you have a chance to take a look at it. 

     

    Sync Code Gallery - Outlook Sync

     

    Thanks,

    Liam

    Tuesday, March 11, 2008 5:56 PM
  • Hi Liam,

    many thanks for that great example. I will have a closer look soon!

    Stefan.


    Wednesday, March 26, 2008 3:27 PM
  • Hello Stefan,

    My company has developed application based on Sync Framework which can synchronize MS Outlook with SQL, MySQl or other databases. The program is highly customizable so you can implement it the way you need. You can learn more at www.sync2db.com. Also if you need a free license to test it out do not heistate to ask.
    Thursday, March 19, 2009 2:23 PM