gandjustas' blog

July 25, 2012

Решил я на ночь глядя поиграться в новым Workflow для SharePoint 2013. Для этого надо поставить Workflow Service (WAW).  Приключения мои начались с того что по ссылке инструкция не правильная. По умолчанию на порту 12290 поднимается HTTPS эндпоинт, в а документации указана команда где используется http.

С этим я быстро разобрался, благо не первый день знаком с SharePoint и его особенностями. Но все равно достучаться до сервиса не получается, отдается ошибка.  Event log написано что не удается распарсить значение конфигурационного параметра которое сейчас 0.1.

Покопавшись в конфигах я обнаружил что нужное значение в базе WFResourceManagementDB в таблице WorkflowServiceConfig, там действительно записано “0.1” в поле типа nvarchar(max).

А причина ошибки банальна. У меня русская версия Windows Server и системный разделитель дробной части стоит запятая, а не точка.

Код внутри сервиса парсит строку вызывая Single.Parse(value) и падает на “неверном” разделителе. Из этого мораль: всегда парси (и записывай) конфигурационные параметры с указанием культуры, лучше инвариантной.

Ниже описание ошибки из event log, чтобы этот пост по тексту находился

The Workflow Service Backend failed to start at location 'WorkflowServiceBackendHost.OnServiceStarted' due to an exception: System.IO.InvalidDataException: Workflow Service configuration 'WorkflowServiceMaxDispatcherFailureRate' is not formatted correctly. The configuration string should be parsable to a 'Single' type. Current config value is '0.1'.

PS. Использование типа Single намекает на то, что WAW написан на VB.NET.

July 5, 2012

На днях провел веб-каст для коллег с демонстрацией как можно создавать артефакты SharePoint в браузере и SharePoint Designer, а потом переносить их в Visual Studio для создания WSP.

Это мой первый опыт веб-каста, он записан в один заход и почти без предварительной подготовки. Прошу не судить строго.

Ссылки, используемые в веб-касте:

• http://spm.codeplex.com – утилита для изменения свойств объектов SharePoint
• http://ilovesharepoint.codeplex.com – решение для SharePoint, позволяющее запускать скрипты PowerShell внутри SharePoint
• http://onlinecoder.blogspot.com/2011/03/simple-way-of-creating-sharepoint-2010.html – статья о том как превратить STP шаблон списка в List Definiton
• http://www.stuartroberts.net/index.php/2011/01/19/package-deploy-sharepoint-designer-workflow/ – статья о развертывании Workflow, созданных в SharePoint Designer

June 19, 2012

Недавно на форуме один посетитель задал простой вопрос, который превратился в очень интересную дискуссию.

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

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

Когда топикстартеру задали вопрос зачем же все-таки так делать он ответил:

так задачу поставили( надо видеть количество страниц и переходы на них...

А дальше еще интереснее:

Руководство сказало "надо", мы сказали "есть!"))

Как ни парадоксально, но тем кто лучше всех должен разбираться в решениях на некоторой платформе совершенно все равно насколько полезны и эффективны их решения. Собственно само решение диктуется людьми (в данном случае “руководством”, иногда бывают аналитики или менеджеры), которые заведомо хуже в этом разбираются.

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

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

Но тут кому-то пришло в голову что там не хватает номеров страниц и перехода по ним. Попробуем разобраться откуда такая мысль.

Вариант первый

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

Скорее всего, именно из-за этих фич используется SharePoint, а не опенсорсная CMS. Но наличие таких фич  приводит к невозможности перехода к конкретной странице и подсчету их количества.

Чаще всего такие требования являются попыткой восполнить пробел обучения путем построения на SharePoint другой, более знакомой, системы.

Создание такой системы – медвежья услуга.  Стандартные возможности SharePoint протестированы, документированы и работают. Создавая свое, похожее но другое, вы не можете вложить столько же сил в тестирование и документирование, сколько вложил Microsoft. Скорее всего решение будет работать гораздо хуже стандартного. Кроме того созданное решение надо поддерживать, апгрейдить итд.

Совокупная стоимость владения повышается, а эффект очень локален. Ведь новая система более привычна узкому кругу лиц.  Гораздо более правильное решение в данном случае – обучить пользоваться возможностями SharePoint.

Вариант второй

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

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

Вариант третий

Кнопочки с номерами страниц – элемент визуального дизайна портала. Такое часто случается когда дизайн создается без оглядки на возможности SharePoint. То есть изначально полезности  в этом элементе нет, есть только визуальная “изюминка”.

В этом случае можно придумать другую “изюминку”. Например сделать unlimited scroll на странице списка. Такой элемент гораздо более удобен для пользователя, но при этом не требует подсчета количества страниц.

Заключение

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

PS. Этот вопрос подробно описан в книге Брукса Design of Design. Рекомендую всем к прочтению.

June 14, 2012

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

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

Третье место

Третье место в хит-параде занимают атрибуты Len и MoreText для элемента FieldRef во ViewFields в схеме CAML запроса (SPQuery). В документации эти атрибуты отсутствуют.  Если указать эти атрибуты для текстового поля, то SharePoint в этом поле вернет урезанную строку, которая вмещается в указанное в Len количество символов, в конце допишет текст, указанный в MoreText.
Причем обрезка текста происходит по границе слова, а не просто по количеству символов.  К сожалению не учитывается Html разметка.

Вот такой код:

using (var site = new SPSite("http://localhost"))
{
    var web = site.RootWeb;
    var list = web.GetList("Lists/Tasks");
    var query = new SPQuery()
    {
        ViewFields = "<FieldRef Name='Body' Len='20' MoreText='...'/>",
        ViewFieldsOnly = true
    };

    foreach (SPListItem item in list.GetItems(query))
    {
        Console.WriteLine(item["Body"]);
    }
}

Дает вот такой результат:

<div>Коллекции на вкладке...
<p>Коллекции на вкладке...
<div>Коллекции на вкладке...

Фича обнаружена Антоном Вишняковым (@avishnyakov).

Второе место

На втором месте находится простая и очень полезная фича. Если обработчик события элемента списка (event receiver) активировать в фиче уровня Site, то независимо от того к какому типу списка был привязан обработчик он будет срабатывать на каждом списке в коллекции сайтов. В том числе на User Information List хотя в MSDN явно написано что на этот список нельзя повесить обработчик. Таким образом можно отслеживать, например, добавление или удаление групп пользователей.
Возможно аналогичное будет работать и для других типов обработчиков событий.

Фича обнаружена Долгополовым Сергеем (http://www.facebook.com/serg3302).

Первое место

Очень простая и часто используемая фича. При развертывании файлов в виртуальной файловой системе с помощью модулей (Module) для элемента File можно указать атрибут DoGUIDFixUp=”TRUE”. Описание в MSDN крайне аскетично.

Если указать этот атрибут, то внутри самого файла и определения его веб-частей(если создается страница) все выражения вида {$ListId: WebRelativeListUrl;} будут заменяться на Guid_ы списка по указанному Url. Точка с запятой в конце Url обязательна. Естественно на момент развертывания указанный список должен существовать.

Как ни странно этот атрибут, видимо, существует еще с SharePoint 2007 и участвует в сохранении сайта в качестве шаблона. Так как при создании сайта из шаблона ID списков получаются новые, а многие компоненты SharePoint ссылаются на списки по ID. Но найти информацию мне не удалось.

Использование DoGUIDFixUp помогает деплоить workflow, веб-части и страницы с веб-частями.

На сладкое

Если вы используете DataFormWebPart (далее DFWP) для вывода данных с SharePoint помощью XSL и хотите создать веб-часть без серверного кода, то возникает проблема. SPDataSource, который используется для получения данных в DFWP, ищет список на текущем сайте.
Даже если, вы используя DoGUIDFixUp, корректно подставите ID списка на корневом сайте, то при размещении веб-части на дочернем сайте выпадет ошибка.

Оказывается если передать в SPDataSource параметр

<asp:Parameter Name="WebUrl" DefaultValue="{sitecollectionroot}"/>

то SharePoint будет искать список на корневом сайте.

Для примера я сделал проект со списком и веб-частью для отображения на основе DFWP абсолютно без кода.

June 13, 2012

Private folder

Третье место в хит-параде почти неизвестных фич занимает каталог _private (начинается с символа подчеркивания) в виртуальной файловой системе SharePoint. Этот каталог находится в корне каждого узла и недоступен для внешнего HTTP запроса, только для API. Таким образом в этом каталоге можно хранить приватные данные, настройки и чтобы они не были доступны непривилегированным пользователям.

SPList.EnforceDataValidation

Второе место в хит-параде занимает это простое свойство, описание которого можно посмотреть по ссылке.
Если создать обязательное lookup поле, то в случае отсутствия элементов в lookup списке можно сохранить элемент с пустым значением lookup. Аналогичные проблемы можно получить и с другими полями если записывать данные в список с помощью SPWeb.ProcessBatchData. При SPList.EnforceDataValidation = true сам SharePoint дополнительно проверяет корректность данных.

Count related lookup

Первое место в хит параде достается особому типу lookup поля. Создав в списке A lookup колонку на список B можно потом создать в списке B lookup на список A. Это поле будет посчитывать количество связанных элементов.

Тоже самое доступно в API через свойство SPFieldLookup.CountRelated.

Далее еще 3 незвестные фичи.