С момента релиза SharePoint 2013 прошел ровно год. Я специально не писал ничего про Apps, собирал информацию и анализировал опыт.
Что такое Apps
Краткий дисклеймер для тех, кто не в курсе что такое Apps. Идея apps заключается в том, что пользователи смогут самостоятельно устанавливать приложения для SharePoint из Market или внутреннего каталога компании. Примерно также, как это происходит на мобильных устройствах. Но, в отличии от мобильных устройств, любой посторонний код для SharePoint очень опасен. Поэтому нужно этот код максимально изолировать, ограничить в правах и жестко контролировать.
Кажется мы то уже слышали в 2010 году, и тогда это были Sandbox Solutions? Именно! Мотивация такая же, как и раньше – увеличить стабильность фермы и дать больше возможности устанавливать решения пользователям.
Но Microsoft решил пойти шире и сказал что apps вообще не должны работать на серверах SharePoint. Это может быть JavaScript в браузере, или внешний веб-сервис, общающийся с SharePoint с помощью клиентской объектной модели.
Так как код становится внешним, по отношению к SharePoint, то там можно использовать любые языки и библиотеки. Angular или Backbone на клиенте, ASP.NET MVC+EF или даже PHP+MySQL на сервере.
Архитектура Apps
Здесь и далее я буду называть apps - приложениями, а solutions – решениями.
Приложения ставятся на сайт (SPWeb) из того же интерфейса, из кодоторого создаются списки. Более того, теперь списки тоже называются приложениями, но это не более чем маркетинговый ход.
Технически приложения для SharePoint представляют манифест, который описывает как можно обратиться к App. Способов на самом деле немного:
- Переход по ссылке на сайт приложения, это обязательно для любого приложения.
- Отображение в iframe на странице SharePoint, примерно как веб-часть в решении.
- Переход по ссылке или отображение в iframe в виде диалога из Ribbon или меню, примерно как custom action в решении.
Еще можно привязать внешний event receiver, но это уже нужно делать в коде приложения.
А теперь главный вопрос: где же будет работать приложение?
Тут два варианта:
- Внешний, по отношению к SharePoint, веб-сервер. Его разработчик должен самостоятельно развернуть, настроить SSL, обеспечить доступность, изоляцию между экземплярами приложений, и прочие радости. Это называется Provider-hosted app. Есть еще вариант автоматического развертывания сайта в Azure из пакета приложения (AutoHosted), но он, спустя год после релиза, толком не работает в Office 365, а onprem скорее всего никогда не будет.
- Подсайт в SharePoint. Для экземпляра приложения может быть создан отдельный сайт (appweb). На сайт можно разворачивать обычные артефакты SharePoint – страницы, файлы, списки, workflows. Серверный код нельзя деплоить, поэтому доступен только код на JavaScript. AppWeb автоматически удаляется при удалении приложения. Это называется SharePoint-hosted.
Эти два варианта не взаимоисключающие. Вы можете иметь отдельный сервер, где будет работать код на любимом вами языке, при этом приложение будет создавать AppWeb и писать данные туда. Или наоборот, код у вас будет на JavaScript в AppWeb и будет обращаться к веб-сервисам на внешнем сайте.
Маркет и монетизация приложений
Главная завлекаловка для разработчиков – возможность монетизировать приложения. Приложение может быть плантым и иметь разные варианты лицензирования. Платные приложения можно распространять только через маркет, при этом приложения проверяются людьми до попадания в маркет и требуется соблюдение правил (правила).
Маркет очень удобен для пользователей, они могут сами находить и ставить приложения. Не требуется качать файлы, запускать скрипты и делать другие непонятные вещи.
Что может делать приложение
Потенциально почти все. Клиентская объектная модель покрывает очень много возможностей – работа с артефактами SharePoint (сайтами, списками, элементами), поиск, таксономия, профили пользователей, публикация, социальные возможности, BCS и даже Project Server.
При этом для приложений назначаются разрешения, которые запрашиваются при установке. Для вычисления эффективных разрешений права пользователя и разрешения приложения пересекаются. Если приложение имеет доступ на запись, а пользователь может только читать, то записать что-либо не получится.
Еще есть app-only policy, когда права пользователя не учитываются, учитываются только разрешения приложения. Это как повышение привилегий, которого так не хватало в Sandbox. Но, увы, не работает в JavaScript коде.
Стоит ли использовать apps?
Спустя год вполне можно оценить насколько apps получили распространение, достаточно заглянть в маркет: http://office.microsoft.com/en-us/store/results.aspx?avg=osu150. Приложений не просто мало, а очень мало. Немалая часть из них – не живые. Также можно найти аналитику по использованию приложений - http://www.instantquick.com/index.php/one-month-since-release-observations-lessons-learned-and-future-plans.
Среди моих знакомых мало кто пишет apps, несмотря на то что половина новых проектов стартует на SharePoint 2013.
Есть мнение что apps вообще не приносят ничего полезного для разработчиков: http://blog.furuknap.net/sharepoint-2013-app-model-solves-non-problems-only.
Все это составляет грустную картину про приложения. В следующий раз постараюсь проанализировать недостатки apps и дать развернутый ответ для чего стоит использовать приложения и решения SharePoint...
