Показаны сообщения с ярлыком OData. Показать все сообщения
Показаны сообщения с ярлыком OData. Показать все сообщения

четверг, 13 ноября 2014 г.

SharePoint 2013 Workflow: HttpSend и DynamicValue

Сегодня я остановлюсь подробнее о ключевой активности при работе с workflow - активности HttpSend. Эта активность является ключевой, потому что приходиться постоянно работать с службами данных, так как собственно других средств для процесса, запущенного в отдельной ферме внутри Workflow Manager, не существует. Активность HttpSend разработана специально для SharePoint и появляется в Visual Studio только в проекте SharePoint 2013, хотя и является универсальной. То есть её вполне можно использовать для запросов к другим разработанным службам данных. Её особенность при работе с SharePoint состоит в том, что эта активность автоматически устанавливает заголовок Authorization: Bearer для аутентификации с помощью OData, в остальном же это обычный запрос с помощью WebRequest.

Рассмотрим работу с активностью HttpSend подробнее. Для начала рассмотрим работу со стандартным сервисом SharePoint.

В первом примере я получаю список приложенных файлов. Адрес запроса для получения списка файлов можно получить из возвращаемого свойства элемента AttachmentFiles/__deferred/uri:
Получив url, отправляем запрос с помощью HttpSend:
Сначала получаем токен S2S с помощью активности GetS2SSecurityToken и сохраняем его в переменной типа SecurityToken. Этот токен подставляем в параметр активности SecurityToken.
Так как у нас будут возвращены комплексные данные, то работать будем с ними с помощью переменной типа DynamicValue. Для этого заводим переменную этого типа attachments. Активность HttpSend имеет следующую приятную особенность: если задать на вход в параметр RequestContent переменную типа DynamicValue, то в тело запроса автоматически вставится JSON и добавится заголовок HTTP Content-Type: application/json; odata=verbose. Также, если задать в выходном параметре ResponseContent переменную типа DynamicValue, то автоматически добавится заголовок HTTP Accept: application/json; odata=verbose, а возвращённый сервером результат в виде JSON будет разобран и помещён в переменную. Поэтому в нашем примере мы получаем структуру данных со списком вложенных файлов сразу в переменной attachments типа DynamicValue.
Для контроля результатов запроса мною используется выходное свойство ResponseStatusCode, которое позволяет сохранить статус ответа HTTP в переменной типа HttpStatusCode.
Для перебора массива в сложной структуре DynamicValue удобнее всего использовать активность ForEach<T>. В нашем примере список файлов возвращается в структуре d/results, для её перебора используем конструкцию: attachments["d"]["results"].

Во втором примере я запрашиваю свой сервис данных WCF. Мне необходимо обновить несколько полей в сущности Equipment (которая фактически является таблицей в базе данных). Для формирования структуры данных, которую мы будем отсылать в сервис, будем использовать тот же самый DynamicValue. Для этого создаём переменную equipmentProperties и инициализируем её с помощью активности BuildDynamicValue:
Сама обновляемая сущность у нас адресуется примерно таким образом: /service.svc/Equipment(guid'XXXXXXXX-XXXX-XXXX-XXXX-XXXXXXXXXXXXX'), где guid - это уникальный идентификатор в таблице. Обновление сущности целиком (всех полей) надо производить с помощью метода PUT. Но, так как мы ходим обновить только несколько полей, то для этого необходимо использовать специальный метод MERGE, который описан в стандарте OData. В выпадающем списке входного параметра Method активности HttpSend такого метода нет, чтобы его задать нужно просто кликнуть на кнопку с тремя точками и воспользоваться текстовым редактором.
Для успешной аутентификации в службе данных обязательно задаём заголовок HTTP Athorization: "" (пустая строка) для того, чтобы сбросить значение Bearer, которое автоматически задаётся (о чём было написано выше).
При успешном обновлении данных сервисом возвращается код 204 (No Content), что я и проверяю после вызова.

Это всё, что хотел рассказать сегодня. Всем удачных разработок!

четверг, 26 декабря 2013 г.

Работаем с внешними данными в Workflow с помощью WCF Data Services и OData

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

Разработка такого сервиса не вызывает проблем, если использовать технологию WCF Data Services.

Очень удобно использовать службы данных WCF с технологией Entity Framework: добавляем модель и создаём службу на её базе:

Надо сказать, что тут есть ограничение: службы данных работают исключительно со стандартными типами данных. Например, у меня в таблице БД есть колонка типа geography. Entity Framework создал мне сущность с полем типа GeographyPoint. Но вот службы данных работать с ним отказались. Пришлось делать отдельную мини-модель без этой сущности, благо работать с ней не нужно было. Может есть ещё какие-то ограничения, пока отдельно этот вопрос не исследовал, если кто-то сталкивался, пишите, пожалуйста, в комментариях.

Итак, служба данных у нас готова. (Всего-то максимум час работы, красота!) Службы данных работают через OData. Это для нас очень удобно, так как позволяют легко вызывать их из рабочего процесса с помощью активности HttpSend(я уже упоминал про работу с HttpSend тут). Для каждого действия с внешними данными (получение или обновление) я создал отдельную активность рабочего процесса.

Трудности могут вызвать формат строки URI для запроса к сервису. Но на помощь приходит документация. Например, тут описание запроса данных с фильтрацией. А здесь описание обновления отдельного свойства.

Отдельно хочу сказать про операции обновления. Выполняются они с помощью операции PUT. В IIS эта операция требует специальных разрешений на папку, в которой находится сервис. Workflow Manager делает запрос из-под своего аккаунта. Поэтому ему необходимо дать разрешения:

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

Про самое главное здесь - про безопасность. Как это всё друг с дружкой увязывается.

Служба данных работает из-под своей учётной записи. Я так и назвал её - DataService. Из-под этой учётной записи будет идти обращение к БД. В настройках IIS должна быть выключена анонимная аутентификация и включена аутентификация Windows для операций обновления. Если операций обновления нет, то в принципе можно оставить анонимность, но я бы всё равно не стал бы так делать.

Безопасность на уровне БД определяется путём заведения специальной роли, я её назвал Data Service. Выдал ей разрешения на нужные объекты БД, и добавил в неё учётную запись DataService.

Workflow Manager работает также под своей учётной записью - sp_workflowmanager. Ей нужны разрешения на папку IIS (см. выше).

HttpSend по-умолчанию посылает HTTP-запрос анонимно, без указания заголовка аутентификации. Для того, чтобы его заставить всё-таки отсылать заголовок, нужно указать пустой заголовок Authorization:

Вот и всё. Надеюсь, кому-нибудь пригодиться.