Interfacing with Excel Services by means of WCF can be somewhat difficult at first and very subject to a trial and error experience.

On my development environment I started by generating the Excel Web Services proxy using svcutil.exe. One of the key aspects for success started at this stage by telling svcutil to generate the proxy using the XmlSerializer as opposed to the default DataContractSerializer (.NET 3.5). This is because whenever I tried to use the DataContractSerializer I would get serialization/deserialization errors.

The next step consisted on properly configuring the generated binding and endpoint.

For the binding I used the following configuration:

<binding name="ExcelServicesSoapBindingConfiguration"
         closeTimeout="00:01:00" openTimeout="00:01:00"
         receiveTimeout="00:01:00" sendTimeout="00:01:00"
         allowCookies="false" bypassProxyOnLocal="false"
         hostNameComparisonMode="StrongWildcard"
         maxBufferSize="65536" maxBufferPoolSize="52428"
         maxReceivedMessageSize="65536"
         messageEncoding="Text" textEncoding="utf-8"
         transferMode="Buffered" useDefaultWebProxy="true">
    <readerQuotas maxDepth="32" maxStringContentLength="8192"
                  maxArrayLength="16384" maxBytesPerRead="4096"
                  maxNameTableCharCount="16384" />
    <security mode="TransportCredentialOnly">
        <transport clientCredentialType="Ntlm"
                   proxyCredentialType="None" realm="" />
        <message clientCredentialType="UserName" algorithmSuite="Default" />
    </security>
</binding>

The relevant aspect here was the security with clientCredentialType set to Ntlm. Maybe this can be related with the authentication method that I choose for the SharePoint WebApplication/SiteCollection but I didn’t tested any other way.

The next part consisted on defining a Allow Impersonation behaviour. This behaviour as important in allowing the WCF service to act as the client while performing the operations with Excel Services (using the credentials of the client).

<endpointBehaviors>
    <!-- Impersonation endpoint behavior -->
    <behavior name="AllowImpersonationBehavior">
        <clientCredentials>
            <windows allowedImpersonationLevel="Impersonation"/>
        </clientCredentials>                    
    </behavior>
</endpointBehaviors>

This behaviour is used by the endpoint together with the binding configuration.

<endpoint address="http://localhost/_vti_bin/excelservice.asmx"
    binding="basicHttpBinding"
    bindingConfiguration="ExcelServicesSoapBindingConfiguration"
    behaviorConfiguration="AllowImpersonationBehavior"
    contract="Excel.WebServices.Proxy.ExcelServiceSoap"
    name="ExcelServiceSoapEndpoint" />

 

With this WCF configuration I managed to successfully call and use the Excel Web Services, and also to call other SharePoint Web Services from WCF (e.g. lists service).

A final note is related with the readerQuotas and message sizes that you see in the binding configuration. These can be important depending on the amount of information that you exchange with the Web Services. Whenever you start to get deserialization errors or other “unexplainable” errors, always check these parameters because they can be smaller that the message sizes that you are trying to exchange. (It should be noted that this does not only apply to Excel Web Services but to services invocations in general).

 

Please let me know of your own successes and experiences when using WCF with Excel or SharePoint Web Services.

LEAVE A REPLY

Please enter your comment!
Please enter your name here