Создание WCF сервиса для выгрузки данных в список SharePoint

Вся информация, представленная в этой статье, не является выдуманной. Она является результатом долгих и мучительных поисков в глубинах интернета, а так же горьким опытом, набранным в ходе в реализации.

Основные статьи, которыми я пользовалась при создании внешнего списка на основе WCF сервиса и на которые в последствии я буду ссылаться в своей статье являются:

1.                  http://sharepointdragons.com/2012/02/13/creating-a-bcs-net-assembly-connector/ (моя статья основана именно на базе этой статьи)
2.                  http://dev.net.ua/blogs/evgeniymuzika/archive/2011/05/02/10799.aspx (в этой статье подробно описано создание endpointsв Web.config для WCF-сервиса)
3.                  http://axforum.info/forums/showthread.php?t=31634 (еще одна хорошая статья разворачивания WCF-сервиса при помощи SharePointDesigner)
4.                  http://msdn.microsoft.com/ru-ru/library/gg318616.aspx (аналогично 3 ссылке, за исключением типа подключения метаданных в SPD)
5.                  http://brijbhushan.net/2011/06/27/could-not-load-file-or-assembly-presentationcore-or-one-of-its-dependencies-an-attempt-was-made-to-load-a-program-with-an-incorrect-format-a-solution/ (когда у меня возникли проблемы с IIS, я наткнулась на решение своей проблемы по этой ссылке)
6.                  http://webactivedirectory.wordpress.com/2012/02/20/asp-net-4-0-error-could-not-load-file-or-assembly-some-dll-or-one-of-its-dependencies-an-attempt-was-made-to-load-a-program-with-an-incorrect-format/ (похожая на предыдущую статью)

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

Передо мной стояла проблема отображения определенных данных в виде списка на портале SP.

Основной проблемой было то, что отображаемые данные должны были составными. Данные должны были подтягиваться из определенного набора таблиц базы данных на SQL сервере. Причем для выгрузки должны были учитываться определенные условия, такие как дата и текущий пользователь.

С учетом некоторых особенностей SharePoint-а работы с внешними данными из некоторого количества вариантов реализации этой задачи было выбрано решение, создать WCF-сервис, который будет представлять собой прослойку между БД и самим порталом.

Ну, что ж, тогда с его создания мы и начнем.

Запускаем Visual Studio 2010 с правами администратора на сервере, где развернут SP.

Создаем новый проект типа ClassLibrary. Назовем его Notice.Data. Удаляем из него Class1.cs.

Вместо него добавляем новый элемент типа ADO.NET Entity Data Model. Назовем его NoticeModel.edmx.

Дальше по стандартной схеме добавляем из базы данных таблицы и хранимые процедуры в модель.

Кстати говоря, для группировки данных и их фильтрации по определенным условиям я написала хранимую процедуру, которую включила в модель данных.

Хочется отметить еще один момент, для подключения хранимок , не забываем открыть Model Browser в нем найти свою хранимку, правой кнопочкой открыть контекстное меню, в нем выбираем Add Function Import… и по необходимости настраиваем возвращаемые ею значения.

Итак, к нас готовая модель с которой мы можем запросто работать.

Создаем новый проект WCF Service Application с более ли менее подходящим названием.

Через Reference… подключаем нашу модельку и System.Data.Entity.

А в Web.config копируем строку подключения к базе данных (<connectionStrings>) из проекта NoticeModel.edmx-> App.config.

Теперь немного полезной теории. Одной из особенностей работы SP с внешними данными является то, что он предоставляет свои стандартные функции отображения данных. Это очень важно для нас, т.к. созданные нами функции должны в последствии быть сопоставлены со стандартными SP-ыми.

Поэтому в интерфейсе мы описываем, какие действия с данными мы хотим совершать.

Так же нам необходимо описать класс, который будет описывать возвращаемые данные. Здесь я тоже немного остановлюсь. Типы свойств данного класса должны быть стандартными, а не типами из вашей модели. Т.е. если вы хотите отобразить название своего продукта, ваш класс должен возвращать название строкой, а не тип Продукт, у которого вы впоследствии взяли бы название.

Итак, мы создали класс и описали действия с объектами этого класса, которые нам будут необходимы (и среди них, конечно же, есть тот, который возвращает список всех объектов, который возвращает отдельный объект, выбирая его по ID, метод для создания нового объекта и для редактирования с удалением, опять же с входным параметром идентификатора объекта). Опишем их подробнее в Service.svc.cs.

Еще одна заметка на будущее, вернуть все вам все равно придется, хотите вы того или нет, поскольку SP очень любит списки. А остальные операции с элементами будут основаны именно на этом списке, поэтому не забываем возвращать объекты с ID.

Более подробно создание WCF и тестирование можно посмотреть в первой статье.

Ну, что ж, все готово и отлажено…? Идем дальше?

Теперь выложим наш сервис на IIS.

Создадим новый ApplicationPool с версией .NET 4.0.

Создадим новый Sites. Укажем имя сайта, в ApplicationPool укажем наш только что созданный пул. В физическом адресе укажем путь до новой созданной папочки в C:\inetpub\wwwroot.

По необходимости (а разработчики SharePoint настоятельно рекомендуют) поменяем localhost на ip и порт или зададим имя хоста, где будет развернут наш сервис.

Далее добавляем Application (правой кнопочкой по сайту -> Add Application). В поле Alias вводим название, физический адрес указываем к нашей созданной папочке в C:\inetpub\wwwroot.

Далее открываем эту папочку и копипастим туда исходники своего сервиса. Основными файлами являются файл конфигурации, библиотечки из папочки bin (там должны лежать 2 dll – одна ваш сервис, а вторая ваша моделька). При изменении вашего сервиса по каким либо причинам именно их и придется менять.

Теперь открываем VS2010 под правами админа и загружаем Web.config. Мы будем его править.

Вначале вставляем следующий код в область <system.web>, для того что бы наш сервис знал про то, что он вообще умеет работать с Entity.

</assemblies>

</compilation>

Далее правим область <system.serviceModel> <services>

Указываем следующие

<host>

</baseAddresses>

</host>

</service>

Важным является добавление конечных точек подключения. Для более подробного изучения можно обратиться ко второй статье.

Для отлаживания ошибок можно также добавить <customErrors mode="RemoteOnly"/> в область <system.web>, но это не является принципиальным.

Сохраняем все внесенные изменения. И перегружаем сайт на IIS.

И еще одна не менее важная деталь, которую мы обязаны сделать на IIS. Переходим к нашему пулу приложений. В контекстном меню выбираем Advanced Settings… В General-> Enable 32-Bit Application меняем false на true. (см 5-6 ссылку)

А в Process Model-> Identy указываем пользователя у которого хватает прав на внесение изменений в вашу базу данных. Под его учеткой сервис будет ломиться с запросами на SQL.

И обновляем/перезапускаем Application Pool.

Итак проверяем работоспособность сервиса при помощи тестового приложения (это может быть ConsoleApplication) и движемся дальше.

Запускаем SharePoint Designer. Указываем сайт, на котором будет отображаться наш список. Переходим в External Content Types. Создаем новый (на ленте выбираем External Content Type).

Указываем имя и в External Content Type Operation кликаем по ссылке.

Затем Add Connection -> Data Source Type задаем WCF service.

Итак, Service Metadata URL задаем адрес вашего опубликованного сервиса + “?wsdl”, приблизительно это должно выглядеть так “http://172.0.0.0:8080/TestServices/Service.svc?wsdl”.

В Metedata Connection Mode выбираем WSDL. Ниже задаем физический адрес сервиса(предыдущая строка только без wsdl) http://172.0.0.0:8080/TestServices/Service.svc/. Нажимаем Ок. И ждем пока SPD думает.

Ну, что все готово и в Data Source Explorer отобразился наш сервис, тогда нажимаем на ‘+’ и видим наши методы для доступа к данным.

Правой кнопкой по методу и мы увидим что SPD предлагает нам на выбор какие действия мы хотим прописать. Более подробно можно найти в 1 статье. Я приведу один пример. К примеру наш метод определяет список только для текущего пользователя сайта, для чего наш метод принимает входным параметром логин. Как же нам правильно задать эти данные. Выбираем New Read List Operation и в открывшемся окне настройки жмем “Далее”.

Мы в разделе входных данных метода сервиса. Переходим по ссылочке Filter. Создаем новый фильтр. Нам предоставляется возможность выбора поля фильтрации. Для нас Filtert Type = User Profile, User Profile Property Name = Account Name.

Жмем Ок и едем дальше. На вкладке возвращаемых значений мы должны указать связку данных. Выбираем Id -> ставим галку Map to Identifier и Финиш.

По аналогии и другие методы.

Когда мы закончили с настройкой Обязательно сохраняемся.

Открываем SCA. Application Management-> в Service Applications

переходим в Manage service applications -> выбираем Business Data Connectivity Service.

Находим наш ECT и устанавливаем права на доступ к данным (Set Permissions).

Правой кнопкой по созданному ECT в меню External List.

Задаем название и жмем Ок. Та-дам! Вот и Все! Список у вас на сайте.

Почти ничего сложного!

Читабельные названия колонок/свойств задаем в дизайнере при настройке методов в поле Display Name для каждого возвращаемого параметра.

Еще пару замечаний в настройках списка на сайте при наличии у нас прав порядок колонок можно изменять, можно их скрывать.

А вот если вам необходимо будет поменять последовательность при отображении подробной информации то, в дизайнере переходим в наш список и в области Forms жмем на DispForm.aspx. Мы попадем в дизайнер формы. Там мы можем переставлять области как душе угодно.

На этом пока все!

Imagining and perceiving

Поиск по этому блогу