четверг, 14 июня 2012 г.

Тонкости получения списка SharePoint

Есть несколько способов получения списка по его названию без выбрасывания исключения. Это индексатор SPListCollection и метод SPListCollection.TryGetList. Однако не стоит исключать, что в процессе жизни решения названия списков могут измениться. Это вполне вероятно, особенно при переходе от пилотной эксплуатации к промышленной. В это время решением попользовались простые пользователя и поняли как всякие мелочи, вроде названия списка, будут удобны именно им, а не разработчикам, которые эти названия придумывали.
В отличии от названия, Url и Guid списка не меняются на протяжении жизни развернутого решения. При каждом разворачивании Guid'ы списков меняются, поэтому использовать их для поиска нужных списков не удобно. А вот Url, пожалуй, является самым главным претендентом для поиска списков. Мне удалось найти только один метод, позволяющий получить список по Url, это SPWeb.GetList. Однако его недостатком является выбрасывание исключения при попытке получения списка по несуществующему Url. Это можно обойти при помощи объекта SPFolder. Каждый список имеет RootFolder, в котором хранятся страницы для просмотра списка элементов и форм элемента. Для его получения есть метод не выбрасывающий исключений. Вот как можно получить список, обезопасив себя от исключений:

SPWeb web          = site.RootWeb;
SPFolder folder    = web.GetFolder("your list url");
if (true == folder.Exist)
    //Если библиотека
    if (null != folder.DocumentLibrary)
        return folder.DocumentLibrary;
    else
        return web.GetList(folder.Url);

Таким образом, исключение может возникнуть только при попытке получить список по Url существующей на сайте папке, не принадлежащей к списку. Например, "Lists". Однако, вероятность того, что программист сам попытается получить список по такому Url мала и в большинстве случаем достаточно описанного выше метода.

суббота, 24 марта 2012 г.

Полезные протоколы SharePoint

Мало кто знает (а я ни от кого ещё не слышал), что SharePoint имеет протокол удаленного вызова процедур, который дает некоторые вкусные возможности.

URL протокол


При помощи URL протокола, можно получить, например, Caml схему любого списка коллекции введя в строке адреса браузера http://Server_Name/[sites/][Site/]_vti_bin/owssvr.dll?Cmd=ExportList&List={ListID} или получить представление папки таким, как оно выглядит в диалоге проводника(когда сохраняем файл в библиотеку SharePoint), набрав http://Server_Name/[sites/][Site/]_vti_bin/owssvr.dll?dialogview=FileOpen&location=Document_Library[/Folder][/File]


Есть ещё несколько методов, которые можно вызвать набрав параметры в строке адреса браузера. Очень интересным так же может быть RenderView (Формат URL не просто понять из статьи, вот пример). Полный поддерживаемых команд находится в этой статье: http://msdn.microsoft.com/en-us/library/ms478653.aspx
.

Протокол SharePoint Foundation RPC


При помощи этого протокола можно выполнить несколько различных методов, позволяющих работать с элементами списков, списками, представлениями, столбцми и пр. Полный список методов в этой статье: http://msdn.microsoft.com/en-us/library/ms480784.aspx.
Из кода любой метод можно вызвать при помощи SPWeb.ProcessBatchData. Причем за один вызов можно выполнять несолько методов, благодаря чему открывается side effect, который подметили разработчики - обработка большого количества данных при помощи SPWeb.ProcessBatchData происходит гораздо быстрее, чем при использовании объектной модели. Для демонстрации я написал консольное приложение, сравнивающее производительность обоих методов. Код получилася простой и громоздкий, посмотреть его можно по ссылке. Результат получился таким:


Как видно, метод SPWeb.ProcessBatchData примерно в два раза быстрее.

Протокол SharePoint Foundation RPC так же содержит методы и для получения данных. Возвращает данные в виде XML на основе указанного View. В простеньком тесте, скорость возвращения данных у меня была быстрее чем при помощи SPQuery с указанием ViewFields примерно в 5 раз. Глубже этот метод я ещё не рассмотрел. Есть у меня подозрение, что Xslt List View Web Part и ей подобные могут использовать именно этот механизм для получения данных.
В методе SPWeb.ProcessBatchData скрыты грабли. Скрыты, на мой взгляд весьма успешно, так что и не разглядишь. Парсер, который разбирает переданный батч, весьма привередлив и не всегда воспринимает апостроф. Например, при использовании метода "display" и написании xml в таком виде: "<SetVar Name='Cmd'>Display</SetVar>" метод SPWeb.ProcessBatchData выбрасывает ошибку неуправляемого кода. А вот если использовать экраннирование и ковычки ("<SetVar Name=\"Cmd\">Display</SetVar>"), то метод срабатывает. При использовании метода "Save" у меня такой проблемы не возникало.

Протокол Stssync


Stssync протокол позволяет добавить SharePoint списки контактов и событий в Outlook или другие приложения. Подробнее.

FrontPage Server Extensions RPC Methods


Данное расширение дает ряд административных методов, позволяющих, например, работать с сайтами и документами. Здесь есть методы для создания директорий и документов сайта, создания/изменения/удаления сайтов и ещё много возможных полезностей. Полный список в этой статье: http://msdn.microsoft.com/en-us/library/ms443099.aspx.

Что дальше?


Если вы решите использовать этот функционал в своих решениях, то вам будет полезно ознакомиться со статьями Method Syntax и Return Values. Статья Error Message Format for SharePoint Foundation упростит вам жизнь при отладке.

воскресенье, 4 декабря 2011 г.

Стажировка в Microsoft Consulting Service Russia. Пост второй.

Первая статья серии

С начала стажировки прошло уже три месяца. Произошли некоторые интересные события. Мне довелось повидать главного операционного директора корпорации Microsoft – Кевина Тернера, который посетил нас после выступления на TechEd 2011. Он рассказал о планах компании на будущее и отвечал на вопросы сотрудников. Радовался вопросам и с неподдельным вниманием выслушивал каждый вопрос. Думаю такое внимание связанно не только с трудностью понимания им русского английского=).

Как я рассказывал ранее, каждый интерн определил совместно с ментором и менеджером планы развития. В моем плане до конца этого года значились сдача экзамена 70-668: PRO: Microsoft SharePoint 2010, Administrator, изучение MSF и полезное участие в проектах.

пятница, 4 ноября 2011 г.

Возникла неожиданная ошибка


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

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

Типичный сценарий

 При открытии страницы получаем окно вида




Или на русском:

Ошибка
Возникла неожиданная ошибка.
Устранение неполадок в работе службы Microsoft SharePoint Foundation.
Идентификатор взаимосвязи: a90f0e23-675e-4eee-ba8f-2cb3be4dcc3e

Что же делать?


Найти подробный текст ошибки можно в папке 14 hive\LOGS
В этой папке много файлов с логами, которые по умолчанию создаются каждые полчаса и в их названии указывается дата и время создания. Можно открыть их блокнотом и найти нужную строчку по CorrelationID, который указан на странице ошибки. Более удобно их открывать при помощи программы ULS Viewer. этой программой можно открыть как любой из старых файлов, так и текущий для просмотра логов в реальном времени. Удобно настраиваемые фильтры помогают отобрать нужные строки логов

В абсолютном большинстве случаев этих знаний о логировании администратору SharePoint хватит на всю жизнь, однако это не вся информация. SharePoint так же пишит логи в Windows Events, а так же в базу данных логирования, где уже можно найти логи со всех машин SharePoint фермы. Подробнее об этом вы можете прочитать в чудесной книжке Professional SharePoint 2010 Administration


Полезные ссылки:

Technet: Monitoring overview (SharePoint Server 2010)
SharePoint 2010 Logging Improvements – Part 1
ULS Viewer
Professional SharePoint 2010 Administration

воскресенье, 18 сентября 2011 г.

Стажировка в Microsoft Consulting Service Russia

Не так давно в блоге Career&Development было объявлено о начале активного рассмотрения кандидатов на оплачиваемую стажировку в Microsoft Consulting Service. Цели и обязанности весьма заинтересовали меня. Работа в Microsoft, думаю, почти каждому айтишнику будет весьма интересна. Методики, обтесанные десятилетиями, коллектив одних из самых продвиннутых в своей сфере коллег, крупные, интересные проекты и куча разных корпоративных плюшек. Я решил подать резюме. Вскоре после SPC.Russia 2011, оставившего очень много впечатлений, случился первый звонок.
Собеседования
Первая беседа была вводной. HR расспросила кто я, чем занимаюсь, как учусь и прочие подобные вопросы, после чего мне велено было ждать второй звонок. Второй раз мы лишь договарились о дате и времени видео беседы, которая была более содержательной и интересной. Меня расспрашивали о проектах, которыми я занимался, спрашивали почему хочу в ms, оценили мой уровень английского, расспросили о предыдущих местах работы. Мне показалось, что ещё были какие-то психологические хитрости, но в этом я уж не силен.
Следующим шагом было техническое собеседование. Изначально планировалось провести эту беседу лично, но все же решили провести эту беседу удаленно, при помощи телефона. Собеседовали меня три специалиста. После видео беседы я решительно вознамерился переехать в Москву и к моменту технического собеседования в MCS у меня уже был опыт технических собеседований. Беседа со специалистами MCS была самой трудной. Скорее всего причиной этому было моё большое желание пройти это собеседование. Из всей беседы мне запомнился только факт того, что вопросы задавались в непривычных формулировках, и лишь один вопрос. Ответ на него есть в любой книге по разработке под SharePoint, но я с ним давно не сталкивался на практике, не задумывался об этой проблеме и ответил с затруднением.
Последнее собеседование было личным. Офис Microsoft на крылатских холмах навеял много мощных впечатлений. Даже в сравнении с офисами московских компаний, в которые я в этот же день собеседовался, офис Microsoft выглядел другой планетой, а в сравнении с родной провинцией - далекой вселенной. Последняя беседа была с приятным человеком в должности MCS Lead. Беседа носила скорее характер беседы о жизни. Рассказали о работе в MCS, в целом о карьере в Microsoft. Пожалуй, самая вдохновляющая беседа.

Начало работы

24 августа я получил оффер и уже 6 сентября приступил к работе. Первый день, как и полагается, был вводным. Началось все с собрания, где мы узнали интересные вещи о компании, увидели своих менеджеров и менторов, немного познакомились друг с другом(очень разными людьми оказались стажеры, объединяет разве что то, что все недавно окончили или скоро окончат вузы), получили очень полезный «Microsoft welcome guide». После чего  нам показали офис, в котором мы теперь работаем, рассказали где что находится и как этим пользоваться, помогли получить и настроить технику и на этом программа первого дня закончилась. Далее у каждого была индивидуальная программа. Кого-то отправили на проект, кто-то получил темы и материалы для изучения. В беседе с менеджером и ментором мы установили, какие именно цели мне нужно достичь в ближайшие 3 месяца, каковы будут параметры оценки достижения этих целей и когда будут проводится оценки. На ближайшие 9 месяцев план не во всем столь четкий. Среди целей изучение определенных технологий, наработка полезных часов на проектах и сдача экзаменов.
Каждую неделю у стажеров назначенна встреча с HR, на которых с нас собирают feedback о работе. В ближайшие понедельник и вторник нас пригласили на new employees orientation days. Обещают познакомить с руководителями ключевых подразделений, лучше узнать ценности и философию компании.

Заключение

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

воскресенье, 31 июля 2011 г.

Опыт сдачи PRO: Designing and Developing Microsoft SharePoint 2010 Applications


План подготовки к экзамену был уже опробован и показал себя и на этот раз достаточно эффективным: training test помогает понять, что за вопросы будут в экзаменах, выявить свои слабые зоны, далее поиск материалов для подготовки по слабым направлениям и изучение материалов. Прохождения этого теста сразу показало, что экзамен гораздо интереснее чем 70-573, что очень здорово и очень мотивирует.

суббота, 2 июля 2011 г.

Опыт реализации многоязычного сайта на платформе SharePoint 2010

SharePoint 2010 имеет встроенный функционал, помогающий в реализации многоязычного сайта. В книгах не трудно найти информацию о легкости перевода пользовательского интерфейса, навигации и списков, в том числе столбцов списков. Достаточно установить language pack, указать возможные языки для сайта и пользователь будет иметь возможность выбрать язык отображения сайта. Пользовательский интерфейс сразу будет переведен на выбранный язык, списки, столбцы и пункты навигации достаточно один раз перевести вручную и введенные значения сохранятся только для текущего языка. Куда труднее обстоят дела с переводом контента. Создавать отдельный сайт для контента каждого языка – неизбежность. Поиски (1, 2) материалов по этой теме навели меня на variation feature. Статьи в блогах гласили, что этот инструмент копирует весь контент и структуру (списки и подсайты) с сайта источника на остальные сайты настраиваемой иерархии. Скопированный контент становится черновиком и ждет ручного перевода. Видимо так было для SharePoint 2007. Развернув этот инструмент, я обнаружил, что нет ни малейшего намека на копирование контента.

Продолжив исследования, я нашел статьи на technet, посвященные развертыванию многоязычного сайта и в частности variation feature: Plan for multilingual sites (SharePoint Server 2010), Variations overview, Plan variations.

Статья variation overview прямо говорит о том, что variation feature не копирует контент, за исключением библиотеки Pages инфраструктуры публикации, от которой я отказался в виду сложностей с версткой. Аналогично состоят дела и с копированием структуры сайтов – копируется только структура сайтов (то есть подсайты), а списки и библиотеки не затрагиваются. Итого в моем случае полезность variation feature – это автоматическое перенаправление на сайт, соответствующий текущему языку посетителя сайта. На первый взгляд это кажется упущением разработчиков, однако это дает бОльшую гибкость (списки на разных языковых версиях можно делать разными), при незначительно бОльших затратах на разработку.

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

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

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

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