Машина разработчика SharePoint в Windows Azure

Ранее я занимался разработкой под SharePoint  на компьютере, стоящим под столом. На нем была развернута виртуальная ферма. Последнее время я всю разработку перенес в облако. Apps отлаживаю на Office 365, серверный код SharePoint создаю и отлаживаю на виртуальной машине в Windows Azure, код храню в Team Foundation Service.

Office 365 и Team Foundation Service – это SaaS, поэтому не вызывает проблем использование и расчет эффективности. А вот виртуалки в Windows Azure (Iaas) вызывают много вопросов.

Почему облака

Доступность

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

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

Гибкость

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

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

Бесплатно

Как владельцу MSDN подписки мне это ничего не стоит. Если же вам все таки придется платить, то расчеты в конце.

Конфигурация

Для того чтобы поднять полноценную среду для разработки вам нужны: контроллер домена с DNS сервером, SQL Server и собственно сам SharePoint. Для целей демонстрации еще понадобится Office Web Apps Server. Причем DC и WebApps должны стоять отдельно, а SQL Server и SharePoint можно совместить. Для разработки это удобно, так как это увеличивает утилизацию ресурсов и не надо по отдельности выключать виртуалки.

А теперь по порядку:

Сеть

Чтобы виртуалки видели друг друга, для начала надо создать виртуальную сеть. Все виртуалки начинают получать адреса по порядку из этой сети. Причем начиная с xx.xx.xx.4 и в порядке включения. В настройках сети также задаются адреса внутренних DNS серверов. Руками править настройки сети в Azure нельзя! Это означает что DNS серверы должны быть включены всегда или должны включаться в определенном порядке, чтобы из IP адреса не менялись.

У меня один DNS сервер на контроллере домена на XS виртуалке и он всегда включен.

Контроллер домена

Тут все просто. Одна XS виртуалка и дополнительный диск для данных домена. Установлены роли AD DS и DNS. Если понадобятся сертификаты, то надо добавить AD CS.

Машина разработчика

Я использую XL виртуалку, на которой стоит SQL Server и SharePoint 2013. На борту 8 ядер (честных, не виртуальных) и 14 ГБ памяти. Для целей разработки этого более чем достаточно.

Но самое главное при работе SharePoint это диски. Быстродействие фермы SharePoint упирается в первую очередь в диски. Когда вы читаете документацию по развертыванию SQl Server и SharePoint там указаны требования к объему дисков, неявно предполагая что все это разные физические диски или как минимум разные LUNы на СХД. Когда разворачивается тестовая ферма или ферма для разработки, то все виртуальные диск попадают на один физический и все дико тормозит.

Диски в Windows Azure это блобы в Azure Storage. Максимальня пропускная способность одного блоба – 60 мегабайт в секунду(http://blogs.msdn.com/b/windowsazure/archive/2012/11/02/windows-azure-s-flat-network-storage-and-2012-scalability-targets.aspx). Внутри виртуальной машины файлы между дисками копируются со скоростью 10 мегабайт в секунду. Но самое главное что для масштабирования IO вы можете добавить столько дисков сколько нужно.

Для SharePoint+SQL Server оптимальной будет такая конфигурация:

  • Диск для данных SQL (можно масштабировать по количеству баз)
  • Диск для логов SQL (можно масштабировать по количеству баз)
  • Диск для tempdb
  • Диск для текстовых логов IIS и SharePoint
  • Диск для индекса поиска

Кроме того можно подключать два виртуальных диска и делать из них striped volume, что должно увеличивать пропускную способность в два раза, но это надо тестировать, я разницы между обычными дисками и striped не увидел при нагрузочном тестировании.

Такая конфигурация работает быстрее, чем на домашнем компьютере.

Тестирование

Для тестов я поднял еще одну машину с Visual Studio и сделал нагрузочный тест для SharePoint. Увы базы SharePoint у меня пустые и кастома почти нет, поэтому результаты тестирования не очень показательны.

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

Результаты нагрузочного теста:

  • 100 requests per senond
  • Все уперлось в процессоры (75% IIS, 25% SQL)
  • Памяти свободной – 1,5 гб (потому что базы пустые)
  • Диски загружены на 15% максимум
  • Примерно на 70 виртуальных пользователях некоторые страницы стали отвечать более 10 секунд
  • IIS ошибок не отдавал

Интересные наблюдения:

  • Для WFE в SharePoint очень важны процессоры, так как страницы “тяжелые” и требуют много ресурсов на рисование.
  • WFE дает нагрузку на диск из-за записи текстовых логов (около 3 мб\сек) в режиме Verbose.
  • Для SQL очень важны диски. Даже в сценарии открытия страниц нагрузка на LOG файлы БД около 1,5 мб\сек.
  • Поиск SharePoint все кеширует в памяти, поэтому для серверов поиска очень важен объем памяти. А также диск, он влияет на скорость индексирования.

Стоимость

В Azure считается время работы машин, гигабайты данных, количество транзакций и трафик. Самое дорогое, естественно, часы виртуальных машин. На время неактивности машины надо отключать.

Расходы:

  • DC – виртуалка XS, работает постоянно – 491 рублей в месяц.
  • SharePoint – виртуалка XL, работает в среднем 172 часа в месяц (8x5) - 4086,72 рублей в месяц.
  • 100гб данных – 231 рублей в месяц.
  • Трафик и тразакции за месяц на разработческой машине стоят меньше 100 рублей.

Итого – чуть меньше 5 тысяч рублей в месяц. С подпиской MSDN дешевле почти в 2 раза.

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

Масштабирование

Для команд разработки SharePoint иметь машины на Azure может быть очень выгодно. Сильно повышается мобильность. Можно сэкономить на использовании общего SQL Server на несколько разработчиков, ведь диски масштабируются практически бесплатно.

Заключение

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



Скрытая стоимость решений на SharePoint

Когда сталкиваюсь с разработкой решений на SharePoint часто наблюдаю парадоксальную на первый взгляд картину. С одной стороны заказчик постоянно хочет с экономить на решении. Очень часто исполнитель выбирается исключительно по самой низкой цене. Заказчик часто пытается сократить расходы на анализ потребностей, проектирование и тестирование. С другой стороны к решениями часто предъявляются совершенно неразумные требования, часто противоречащие эффективному использованию этих самых решений. Все это бьет по качеству решения.

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

Из чего складывается скрытая стоимость

Затраты на ожидание

Первый пункт самый банальный. Любая компьютерная система имеет время реакции на действия пользователя. Самое простое – время открытия страницы. Если пользователь открывает 20 страниц в час, то за день выходит 160 страниц. Если вместо двух секунд страница открывается 6 секунд, то за день только в ожидании страниц пользователь проводит 10 минут. Для 100 пользователей это уже значительное время. А время = деньги.

Сюда относится время простоя системы из-за неполадок, обновлений и тому подобных вещей.

Слишком много ручных действий

Казалось бы, в чем проблема нажать кнопку, или вбить значение в поле. Но если это делается много раз  в день, то возникает две проблемы. Первая – время затраченное на эти действия. Вторая – чем больше ручных действий, тем больше вероятность ошибиться.

Поиск информации

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

Исследования показывают, что сотрудники, занимающиеся обработкой информации тратят на её поиск от 15% до 35% времени. Источник: http://www.kmworld.com/Articles/Editorial/Features/The-high-cost-of-not-finding-information-9534.aspx.

Обходные пути

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

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

Обращения в службу поддержки

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

Доработки

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

Стоимость апгрейда

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

Стоимость обслуживания решения

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

Как бороться со скрытыми затратами

Большинство скрытых затрат происходят от дефектов решения, которые невозможно выявить на приемо-сдаточных испытаниях. Чаще всего это:

  • Непроработанность пользовательских сценариев
  • Дефекты в модели данных, усложняющие масштабирование
  • Низкое качество кода, большое количество дефектов в реализации
  • Дефекты сценариев развертывания
  • Решение не адаптировано к работе в довольно динамичной среде SharePoint

А теперь собственно как бороться:

Пилотные проекты

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

Ранее прототипирование

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

Слабосвязные сервисы

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

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

Не пытаться покрыть 100% потребностей

Это очень важно. SharePoint, как и любая другая платформа имеет свои ограничения, то сделать на нем можно все что угодно, но некоторые вещи будут крайне дорогими. Тут нужно применять правило Парето: 20% усилий дают 80% результата. Остальные 80% лучше потратить на создание других сервисов.

Придерживайтесь best practices

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

Design review

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

Проверка решений

По возможности делайте аудит кода. Для этого существуют инструменты, например SPCAF (http://www.spcaf.com/). А особо сложных случаях также можно привлечь консультантов.

Имейте все исходники и документацию

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

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

Заключение

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

Исследования множества проектов разработки (Shull defects paper) говорят о том, что 20%-80% стоимости разработки занимает переделывание работы, связанное с исправлением дефектов. Разброс большой, точная величина зависит от уровня зрелости разработки у исполнителя.

Ранее я приводил таблицу результативности методов устранения дефектов (http://gandjustas.blogspot.com/2013/07/code-review-vs-testing.html). Прототипирование, инспекции дизайна и кода показывают одни из лучших результатов. В совокупности они могут дать до 95% устранения дефектов до релиза. Правильный подход к разработке может сократить общие затраты на создание решения более чем в два раза, добавив незначительные затраты на прототипирование и инспекции.

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

В итоге делать хорошие решения получается быстрее и выгоднее для обоих сторон.



Связанные элементы в SharePoint 2013

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

Копая JSOM, я недавно обнаружил, что в SharePoint 2013 есть такой функционал.

“Изкаропки” он доступен в списке задач. У каждой задачи есть “связанные элементы”.

image

При нажатии на “добавить связанный элемент” появляется стандартный asset picker

image

Можно выбирать любой элемент в пределах коллекции сайтов.

Внутренности “связанных элементов”

“Связанные элементы” это кастомное поле с ID равным значению Microsoft.SharePoint.SPBuiltInFieldId.RelatedItems. Это поле скрытое и добавить его в список из интерфейса не получится. Но в решении вы совершенно спокойно можете добавить это поле в тип контента.

Сам касс поля определен в сборке Microsoft.SharePoint и доступен, в том числе, в Foundation. Для работы с полем доступны только клиентские API, серверный класс для них помечен как internal.

На клиенте можно обращаться с помощью классов SP.RelatedItemManager в sp.js (http://msdn.microsoft.com/en-us/library/jj838582.aspx) и Microsoft.SharePoint.Client.RelatedItemManager в сборке Micrsosoft.SharePoint.Client (http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.client.relateditemmanager.aspx).

Если интересна реализация поля, то смотрите с помощью IlSpy класс Microsoft.SharePoint.RelatedItemManager в сборке Microsoft.SharePoint. Рендеринг поля описан в файле sp.ui.relateditems.js

Реализация поля предельно простая – в текстовом поле сохраняется сериализованный в json массив элементов Microsoft.SharePoint.RelatedItem. Есть ограничение – не более 9 связанных элементов. Скорее всего оно связано с необходимостью secutrity trimming ссылок на связанные элменты, а это делается крайне медленно в SharePoint. Для security trimming ссылок в ленте новостей используется поиск+кеширование, но функционал “связанных элементов” рассчитан на работу в foundation и не может использовать такие возможности.

Применение

Из-за ограничения количества связанных элементов использовать данную возможность для разработки большой системы не получится. Хотя во многих сценариях данное поле может заменить лукапы. Кроме того API позволит вычислять “транзитивное замыкание” связанных элементов.

Наибольший интерес “связанные элементы” представляют как пример качественно сделанного расширения платформы. Оно включает в себя Custom Field Type с контролом, API на сервере и на клиенте, рендеринг поля в формах и использование asset picker. Если будете делать что-то подобное, то изучите реализацию “связанных элементов”.



Code Review vs Testing

Почти все знают, что баг в программе, исправленный на этапе использования, стоит примерно в 100 раз дороже, чем исправленный до использования. Кто не верит – может почитать результаты исследования Shull defects paper.

Если спросить программистов какой метод исправления поиска и исправления багов наиболее эффективный, то большинство ответит - “тестирование”. И будут неправы…

Эффективность различных методов устранения ошибок

В книге МакКоннелла CodeComplete есть статистика (да-да, все её читали, но никто сходу не может вспомнить что там написано), которая разрывает мозг многим апологетам тестов.

Методика

Результативность в среднем

Regression test 25%
Informal code reviews 25%
Unit test 30%
New function (component) test 30%
Integration test 35%
Low-volume beta test (< 10 users) 35%
Informal design reviews 35%
Personal desk checking of code 40%
System test 40%
Formal design inspections 55%
Formal code inspections 60%
Modeling or prototyping 65%
High-volume beta test (> 1000 users) 75%

То есть в среднем все методы тестирования менее результативны, чем формальные инспекции дизайна и кода. А если еще поделить результативность на затраченное время, то review становится в разы эффективнее тестирования.

Как делать review

Для начала надо почитать того же МакКоннелла, у него все более чем подробно описано. Ключевые моменты:

  • Чтобы проводить инспекции нужны чек-листы.
  • Темп code review составляет 120-200 строк в час.
  • Инспекторов должно быть как минимум два.
  • Должны быть адекватно описаны требования к коду: быть полными и не содержать противоречий и неточностей.
  • Код должен компилироваться.
  • Код должен быть проверен разработчиком, как минимум выполнять основные сценарии на его машине.

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

Как повысить эффективность code review

Средняя продолжительность продуктивного писания кода – 4-5 часов в день. То есть 3-4 часа в день программист не занимается написанием кода, или занимается, но лучше бы этого не делал. Можно скорректировать время работы программистов, чтобы 4 часа в день они писали код, два часа делали review, еще два часа занимались проектированием, митингами и административными задачам. То есть review получается практически бесплатно.

Команда в 3-4 человека будет вполне успевать проводить review написанного за день кода в оставшиеся 2 часа после кодирования.

Значительную часть review можно автоматизировать, есть множество инструментов, которые проверяют качество кода.

Если все так круто, то почему же все занимаются тестированием?

Ответ на этот вопрос я долго искал, пока не наткнулся на презентацию Эрика Липперта о психологических аспектах анализа кода (http://www.slideshare.net/Coverity/the-psychology-of-c-analysis-24025354). Несмотря на то, что в презентации рассказывается об автоматизированном анализе, причины недоверия более чем верны для code review.

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

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

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

Заключение

Несколько статей про code review, в них есть много интересных ссылок на исследования и книги:

Немного про SharePoint. Джентльменский набор для анализа кода:

ЗЫ. Все написанное выше не означает что надо бросить тестирование и все силы перекинуть на review. У того же МакКоннелла написано, что наибольший эффект достигается при применении минимум трех методик.



SharePoint и Ajax

Как вы думаете, сколько способов сделать ajax запрос в SharePoint? А без jQuery и дополнительных библиотек? Нет, XMLHttpRequest руками писать на надо.

Sys.Net.WebRequest \ Sys.Net.WebRequestExecutor

Эти классы находятся в библиотеке MicrosoftAjax. Она подгружается на каждой странице SharePoint и вы можете использовать её на своих страницах.

Класс Sys.Net.WebRequest описывает параметры запроса, а Sys.Net.WebRequestExecutor, вернее его наследник, выполняет запрос с указанными параметрами. Можно создавать свои реализации WebRequestExecutor, например для тестирования или для проксирования запросов.

Недостаток этих классов в чрезмерной многословности.

var request = new Sys.Net.WebRequest();         
request.set_url(url);
request.set_httpVerb("GET");         
request.add_completed(function(executor, eventArgs) {             
    if(executor. get_responseAvailable()) {
        //do stuff
    }
});

request.invoke(); 

Вот так придется писать на каждый запрос. Семантически похоже на то, что есть в C#, но после jQuery выглядит страшно. Тем не менее этот api является базовым для всего, что работает в SharePoint.

Ссылки на MSDN:
Sys.Net.WebRequest - http://msdn.microsoft.com/en-us/library/bb310979(v=vs.100).aspx
Sys.Net.WebRequestExecutor- http://msdn.microsoft.com/en-us/library/bb397434(v=vs.100).aspx

SP.PageRequest

Этот класс находится в библиотеке sp.js и доступен с SharePoint 2010.

У нем есть два статических метода doGet и doPost.

SP.PageRequest.doGet(
    url,'application/json', 
    function(o, args) {
        var webRequestExecutor = args.get_executor();
        //do stuff
    }, 
    function(o, args) {
        //args.get_errorMessage();
    });

Аналогично работает метод doPost, который может также передавать body.

Огромный недостаток этих методов в том, что они не позволяют указать загловки запроса. А второй параметр, который называется expectedContentType, сравнивается с Content-Type результата и выкидывает исключение при несовпадении.

Конечно можно создать экземпляр SP.PageRequest, из него получить объект Sys.Net.WebRequest, и через него выставить заголовки. Но это будет еще более многословно, чем при использовании Sys.Net.WebRequest напрямую.

Но есть и преимущество. SP.PageRequest обрабатывает RequestDigest, что поможет делать запросы к SharePoint.

Если вы не знаете, то в SharePoint  в post запросе к странице нельзя делать Update, если не передан корректный Request Digest. Аналогично нельзя обращаться к REST эндпоинту для изменения данных без RequestDigiest. Это должно защищать от CSRF атак.

Документация по SP.PageRequest - http://msdn.microsoft.com/en-us/library/ee547454(v=office.14).aspx

SP.WebProxy

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

Кстати он не менее многословен, чем Sys.Net.WebRequest, так что у вас и желания не будет его использовать для всего подряд.

var context = SP.ClientContext.get_current();
var request = new SP.WebRequestInfo();
request.set_url(
    "http://services.odata.org/Northwind/Northwind.svc/Categories"
    );
request.set_method("GET");

request.set_headers({ "Accept": "application/json;odata=verbose" });
var response = SP.WebProxy.invoke(context, request);
context.executeQueryAsync(successHandler, errorHandler);

function successHandler() {
    if (response.get_statusCode() == 200) {
        //Do stuff
    }
}

Но и это еще не все. Чтобы код выше заработал надо в манифест приложения вписать следующий элемент:

<RemoteEndpoints>
    <RemoteEndpoint Url=" http://services.odata.org" />
</RemoteEndpoints>

Подробно о применении класса SP.WebProxy по ссылке - http://msdn.microsoft.com/en-us/library/fp179895.aspx

SP.RequestExecutor

Этот класс находится в отдельном файле sp.requestexecutor.js, может работать как в SharePoint, так и вне его.

По-умолчанию на страницы SharePoint он не загружается и чтобы его использовать надо написать такой код:

SP.SOD.registerSod('sp.requestexecutor.js',
            '/_layout/15/sp.requestexecutor.js');
SP.SOD.executeFunc('sp.requestexecutor.js', 
            'SP.RequestExecutor', 
            function() {
                //Do stuff
            });

Если у вас html страница в SharePoint, то можете просто подключить скрипт на страницу и не использовать Script On Demand.

Использовать SP.RequestExecutor гораздо проще, чем предшествующие варианты:

var re = new SP.RequestExecutor(targetSiteUrl);
re.executeAsync({
    url: targetUrl,
    method: 'GET',
    success:function(response) {
        //console.log(response.body);
        //do stuff
    }
});

Также, как и SP.PageRequest, SP.RequestExecutor автоматически отправляет RequestDigiest. Так что руками передавать его, как написано во многих примерах, не обязательно.

SP.RequestExecutor может работать с бинарными данными, но из-за ошибки надо устраивать пляски с бубуном чтобы все заработало - http://techmikael.blogspot.ru/2013/07/how-to-copy-files-between-sites-using.html

В зависимости от того какой url вы передали в конструктор SP.RequestExecutor будет иметь разное поведение.

  • Если hostname в targerSiteUrl совпадает с hostname текущей страницы, то будут обычные ajax запросы.
  • Если не совпадает, то RequestExecutor будет пытаться отправлять запросы через AppProxy. Этот сценрий будет работать если у вас страница находится в SharePoint App.

Кроме того, можно передать вторы параметром в конструктор адрес хендлера, который использует класс Microsoft.SharePoint.Client.RequestForwarder (ни разу не видел чтобы им кто-либо пользовался). Это позволит обращаться к серверу SharePoint из javascript, расположенного на внешнем сайте и не использующем модель приложений. Ранее я про эту возможность писал в статье http://gandjustas.blogspot.com/2012/03/silverlight-sharepoint-2.html.

Кстати Microsoft.SharePoint.Client.RequestForwarder использует класс HttpContext, который создает ссылку на сборку System.Web. Из-за этого сборку Microsoft.SharePoint.Client нельзя использовать в Windows 8 приложениях.

Примеры SP.RequestExecutor по ссылке - http://msdn.microsoft.com/en-us/library/jj164022.aspx

SP.ProxyWebRequestExecutor и SP.ProxyWebRequestExecutorFactory

Эти два класса дополняют SP.RequestExecutor. SP.ProxyWebRequestExecutor является наследником Sys.Net.WebRequestExecutor и использует SP.RequestExecutor для выполнения запросов. Вы можете использовать его в любом коде, работающим с Sys.Net.WebRequest (интересно есть у вас такой), например чтобы заработало в Apps.

Класс SP.ProxyWebRequestExecutorFactory необходимо использовать если вы собираетесь использовать JSOM на не-SharePoint страницах.

var factory = new SP.ProxyWebRequestExecutorFactory(targetUrl);
var ctx = new SP.ClientContext(targetUrl);
ctx.set_webRequestExecutorFactory(factory);

Документации по этим классам нет, но в проект SPTypeScript я недавно залил дефинишены (описания типов) для всех полезных классов sp.requestexecutor.js  - http://sptypescript.codeplex.com/SourceControl/latest#Definitions/SP.RequestExecutor.d.ts
API небольшое и понять семантику несложно.

Рекомендации

Если вы делаете javascript для работы с SharePoint на страницах SharePoint, то используйте JSOM. Она достаточно мощная в 2013 и покрывает почти все сценарии. Для обращения к таким вещам как ExcelRest используйте SP.PageRequest.

Если вы делаете не-SharePoint, или в других сложных случаях, страницы используйте SP.RequestExecutor и JSOM с помощью SP.ProxyWebRequestExecutorFactory.

Если вас пугает многословный API для JSOM, то используйте TypeScript и дефинишены из проекта http://sptypescript.codeplex.com/, они почти полностью покрывают JSOM.

А как же jQuery?

В SharePoint 2013 почти не нужно. Ajax запросы можно делать и без нее, а для манипуляций с DOM есть библиотека mQuery. Про анимацию в SharePoint 2013 напишу в следующий раз.