none
[E2010] [EWSMA] Using Exchange Web Services in SQL Server with EWSMA or XML? RRS feed

  • Question

  • hi all,

    we are looking into EWS for a exchange <-> crm integration through SQL Server 2005. We have started coding a C# demo application to see how EWS works and where its limitations. So far so good, we are pretty happy.

    as a 2nd step, we've used the "Exchange UDF" example (http://www.microsoft.com/downloads/en/details.aspx?FamilyID=D6924897-7B62-46FD-874E-24FB0FBA2159&amp;displaylang=en)

    to evaluate the possibilities of sql server integration, which makes us also pretty happy.

    as our 3rd step we want to but the pieces together: our demo c# code (based on EWS API/SDK) and the sql server integration based on the above ExchangeUDF sample. Here comes the suprise which made us stuck in progressing: the exchangeUDF example is not based on the EWSMA. it uses the soap class and does the xml on its own.

    the main problem is, we do not understand WHY the sample makes no use of the EWSMA. And we are not sure where to go from here. Throw away the exchangeUDF direct xml/soap and replace it with EWSMA? Throw away the API and progess on the xml/soap road to access EWS?

    background information on this and all and every advices are highly appreciated

    tia

    Gregor Stefka

    Friday, December 3, 2010 9:12 PM

Answers

  • Hello Gregor,

    Your questions are now outside the scope of my expertise. I'm not familiar with SQL Server CLR integration and the associated architectural requirements for that system. For one, you don't want to manually move dependencies as that may or may not be in conflict with terms of use.

    At this point, I'd suggest you post your questions and background information to the SQL Server forums. Members of that forum should have experience/knowledge about SQL Server CLR integration with assemblies that contain dependencies that are not contained in SQL Server CLR. There may be very good reasons why the SQL Server CLR is a subset of the greater CLR.

    After further investigation through the SQL Server forums and and documentation, if it is not possible to integrate EWSMA in to your current application architecture, you may want to consider an alternative architecture. Another possibility to consider is if you are using a limited set of EWS functionality, then you may want to roll your own client with the use of the System.Web.Services namespace. And if that doesn't fit your needs, then you should look at the auto-generated proxy API is a resource. Your choice really depends on the architecture and feature requirements.

    I hope this helps.

    With regards,

     


    Michael | Microsoft Exchange SDK

    The Exchange Development Forum Guide has useful information for using the Exchange Development Forum.

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    • Marked as answer by Gregor Stefka Friday, December 17, 2010 2:32 PM
    Monday, December 13, 2010 6:49 PM
    Moderator

All replies

  • Hello Gregor,

    The sample that you reference was created before work had started on the EWS Managed API. That is the only reason why it uses the auto-generated proxy classes and not the EWS Managed API.

    I suggest that you perform a functional decomposition on the EWS auto-generated proxy API components of that sample to identify which calls are being made. Then, once you have identified the components, their actions, and to which parts of the process they contribute, then you should map those components to functionality exposed in the EWS Managed API.

    We strongly suggest that you use the EWS Managed API while we strongly suggest that you not use auto-generated proxy APIs.

    With regards,


    Michael | Microsoft Exchange SDK
    Thursday, December 9, 2010 7:06 PM
    Moderator
  • Hello Michael,

    thank you for helping. We did what you've said and replaced the " auto-generated proxy API components " with EWSMA.

    Now, when it comes to the SQL Server integration we ve got another issue which makes us a bit uncomfortable:

    the EWSMA references assamblies which are not available in the SQL Server CLR. We can include them manually, but this situation brings us back to the original question:

    is it better to use the EWSMA or the " auto-generated proxy API components " in our situation?

    For everyone out there who are trying to integrate EWSMA in SQL Server, you need the following assamblies included in the SQL Server CLR (note: DB needs trustworthy=1):

    CREATE ASSEMBLY SystemCoreKey
    FROM 'C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Core.dll'
    WITH PERMISSION_SET = UNSAFE
    
    CREATE ASSEMBLY SystemDirectoryServicesKey
    FROM 'c:\Windows\Microsoft.NET\Framework\v2.0.50727\System.DirectoryServices.dll'
    WITH PERMISSION_SET = UNSAFE
    
    --depends on SQL Server (x86/x64): 
     ASSEMBLY SystemWebKey 
    FROM 'c:\Windows\Microsoft.NET\Framework64\v2.0.50727\System.Web.dll'
    WITH PERMISSION_SET = UNSAFE

     

     

     

    maybe this one is better placed in the sql server forums, but whats your opinion on that from the MS Exchange point of view?

    tia

    Gregor Stefka

    Friday, December 10, 2010 12:06 PM
  • Hello Gregor,

    Your questions are now outside the scope of my expertise. I'm not familiar with SQL Server CLR integration and the associated architectural requirements for that system. For one, you don't want to manually move dependencies as that may or may not be in conflict with terms of use.

    At this point, I'd suggest you post your questions and background information to the SQL Server forums. Members of that forum should have experience/knowledge about SQL Server CLR integration with assemblies that contain dependencies that are not contained in SQL Server CLR. There may be very good reasons why the SQL Server CLR is a subset of the greater CLR.

    After further investigation through the SQL Server forums and and documentation, if it is not possible to integrate EWSMA in to your current application architecture, you may want to consider an alternative architecture. Another possibility to consider is if you are using a limited set of EWS functionality, then you may want to roll your own client with the use of the System.Web.Services namespace. And if that doesn't fit your needs, then you should look at the auto-generated proxy API is a resource. Your choice really depends on the architecture and feature requirements.

    I hope this helps.

    With regards,

     


    Michael | Microsoft Exchange SDK

    The Exchange Development Forum Guide has useful information for using the Exchange Development Forum.

    Please remember to click “Mark as Answer” on the post that helps you, and to click “Unmark as Answer” if a marked post does not actually answer your question. This can be beneficial to other community members reading the thread.

    • Marked as answer by Gregor Stefka Friday, December 17, 2010 2:32 PM
    Monday, December 13, 2010 6:49 PM
    Moderator
  • Hi have you solved your problem? because I have too the same problem
    Wednesday, June 29, 2011 10:35 AM