Подключение WCF от Webpart - PullRequest
       6

Подключение WCF от Webpart

0 голосов
/ 20 апреля 2010

Я использую Службу WCF из веб-части в Sharepoint 2007. Но она дает мне следующую ошибку:

Конечная точка не прослушивала http://locathost:2929/BusinessObjectService что может принять сообщение. Это часто вызвано неправильным адресом или действие SOAP. Смотрите InnerException, если настоящее время, для более подробной информации. ---> System.Net.WebException: удаленный сервер вернул ошибку: (404) не Found.

Мои обязательные данные в WCF web.config:

<system.serviceModel>
    <diagnostics performanceCounters="All">
      <messageLogging logEntireMessage="true" logMessagesAtServiceLevel="false"
        maxMessagesToLog="4000" />
    </diagnostics>
    <services>
      <service behaviorConfiguration="MyService.IBusinessObjectServiceContractBehavior"
        name="MyService.BusinessObjectService">
        <endpoint address="http://localhost:2929/BusinessObjectService.svc"
          binding="wsHttpBinding" contract="MyService.IBusinessObjectServiceContract">
          <identity>
            <dns value="localhost" />
          </identity>
        </endpoint>
        <endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
      </service>
    </services>
    <behaviors>
      <serviceBehaviors>
        <behavior name="MyService.IBusinessObjectServiceContractBehavior">
          <serviceMetadata httpGetEnabled="true" />
          <serviceDebug includeExceptionDetailInFaults="false" />
        </behavior>
      </serviceBehaviors>
    </behaviors>
  </system.serviceModel>

Мои обязательные данные на сайте Sharepoint web.config:

<system.serviceModel>
    <bindings>
      <wsHttpBinding>
        <binding name="WSHttpBinding_IBusinessObjectServiceContract"
                    closeTimeout="00:01:00" openTimeout="00:01:00" receiveTimeout="00:10:00"
                    sendTimeout="00:01:00" bypassProxyOnLocal="false" transactionFlow="false"
                    hostNameComparisonMode="StrongWildcard" maxBufferPoolSize="524288"
                    maxReceivedMessageSize="65536" messageEncoding="Mtom" textEncoding="utf-8"
                    useDefaultWebProxy="true" allowCookies="false">
          <readerQuotas maxDepth="32" maxStringContentLength="8192" maxArrayLength="16384"
              maxBytesPerRead="4096" maxNameTableCharCount="16384" />
          <reliableSession ordered="true" inactivityTimeout="00:10:00"
              enabled="false" />
          <security mode="Message">
            <transport clientCredentialType="Windows" proxyCredentialType="None"
                realm="" />
            <message clientCredentialType="Windows" negotiateServiceCredential="true"
                algorithmSuite="Default" />
          </security>
        </binding>
      </wsHttpBinding>
    </bindings>
    <client>
      <endpoint address="http://localhost:2929/BusinessObjectService.svc"
          binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_IBusinessObjectServiceContract"
          contract="BusinessObjectService.IBusinessObjectServiceContract"
          name="WSHttpBinding_IBusinessObjectServiceContract">
        <identity>
          <dns value="localhost" />
        </identity>
      </endpoint>
    </client>
  </system.serviceModel>

Я могу просматривать WCF (и его wsdl) в браузере, используя URL-адрес, указанный в конечной точке. Итак, я думаю, что URL-адрес определенно правильный. Пожалуйста, помогите !!!

Ответы [ 2 ]

1 голос
/ 20 апреля 2010

Я скопировал ваш код, и он работает для меня правильно, но есть несколько несоответствий.

Во-первых, , указанная вами конфигурация на стороне сервера не завершена. Конечная точка mex терпит неудачу, потому что у меня нет контракта IMetadataExchange. Когда вы просматриваете WSDL, это, вероятно, конечная точка, которую вы просматриваете.

Я просто полностью удаляю эту конечную точку. Исходя из этого, я указываю адрес для элемента serviceMetadata в таком поведении:

<serviceMetadata httpGetEnabled="true" httpGetUrl="http://localhost:2929/BusinessObjectService.svc?wsdl" />

Не идеально, но это работает, чтобы позволить мне найти услугу. Тогда мой сгенерированный файл конфигурации клиента такой же, как ваш, за исключением ...

Во-вторых , у меня есть messageEncoding="Text" вместо messageEncoding="Mtom"

Попробуйте изменить кодирование сообщений на Текст. Вы не указали на стороне сервера, что это должен быть Mtom, поэтому я не понимаю, почему он был создан на стороне клиента как Mtom.

Помимо этих двух проблем, моя конфигурация такая же, как у вас, и она работает без проблем. Я не уверен, что вторая проблема, которую я обнаружил, является реальной проблемой вообще (я не могу понять, как обмен метаданными дал бы неправильную кодировку сообщений), но первая проблема не дает службе работать на моей стороне. .

0 голосов
/ 22 августа 2016

Я получил ошибку, которая выглядела почти идентично описанной ошибке. Однако моя ошибка была 503, и я вызывал веб-сервис на внешнем сервере.

Когда я вызывал службу из отдельного приложения, у меня не было проблем, но когда я вызывал службу из веб-части в SharePoint, это не удавалось.

Решения, которые помогли мне, без каких-либо дополнительных объяснений, потому что я не совсем понял, почему это работает (Если вы знаете, пожалуйста, просветите меня :))

Первое решение, которое работало для меня, состояло в том, чтобы использовать мою собственную учетную запись домена вместо служебной учетной записи для пула приложений, который использовался SPWebApplication.

2-е решение состояло в том, чтобы установить атрибут привязки службы UseDefaultWebProxy в false

UseDefaultWebProxy = false

Конечно, эти решения зависят от ваших настроек прокси и пользовательских настроек. Мои настройки прокси-сервера были настроены так, чтобы обходить прокси-сервер для службы, которую я вызывал, поэтому я подозреваю, что настройки прокси-сервера (настроенные здесь: IE-> Свойства обозревателя-> Соединения-> Параметры локальной сети) не относятся к учетной записи службы, а только авторизованному пользователю. К этому моменту я и буду расследовать подробнее.

РЕДАКТИРОВАТЬ 1: Хм. это на самом деле не принесло ничего нового в таблицу, я использовал psexec для просмотра настроек прокси-сервера в качестве учетной записи службы (netsh-> winhttp-> show proxy), и это выглядело правильно, поэтому я не думаю, что это может быть проблемой.

РЕДАКТИРОВАТЬ 2: Окончательное решение , поэтому проблема заключалась в том, что мое веб-приложение SP не использовало параметры прокси-сервера, которые я настроил в IE, когда пул приложений запускался в контексте учетной записи службы, когда я использовал свою учетную запись пользователя для у пула приложений у меня проблем не было и использовались настройки прокси в IE. После небольшого исследования выяснилось, что я могу определить параметры прокси для своего SPWebApplication в web.config, и я решил просто отключить прокси

<system.net> <defaultProxy enabled="false" /> </system.net>

...