Comments 37
UFO just landed and posted this here
Написание высоконагруженных корпоративных решений на SharePoint… невозможно
А если невозможное преодолеть, то потом выходит новая версия sharepoint, инженеры которого, раскаявшись в смертных грехах, перелопатили вообще все и…
У нас есть портальчик, который держит 10 запросов в секунду на WFE, при этом имеет базу в 2 ТБ и на главной странице (60% запросов) делает в выборки последних новостей\картинок\видео итп с таргетингом по региону пользователя, учитывая права доступа. Открывается за 2-3 секунуды при этом. И это еще не предел оптимизации.
И это, по-вашему, высокая нагрузка?
Не низкая уж точно. Уточню: 10 страниц в секунду. Клиентского кеширования страниц нет.
Я просто оставлю несколько ссылок, где люди обсуждают requests per second (с точки зрения cpu and memory bounds) в разных условиях.
10 запросов в секунду—это мизер даже для одного веб-сервера с минимальной конфигурацией. Для шарепоинта, может, это большое достижение, но это потому что он, в моем представлении—огромная машина с ужасной архитектурой. Точно так же asp.net намного медленнее asp.net mvc—потому что для отображения той же странички asp.net обрабатывает page life cycle, все события, viewstate, session state, бла-бла-бла, т.е. по пятнадцать раз проходит по дереву контролов вверх и вниз. Если сильно напрячься, то по меркам asp.net можно сделать очень быстрый сайт, но он все равно будет медленным. Выше головы, конечно, не прыгнуть, но это не повод говорить, что 10 запросов в секунду—это очень много.
10 запросов в секунду—это мизер даже для одного веб-сервера с минимальной конфигурацией. Для шарепоинта, может, это большое достижение, но это потому что он, в моем представлении—огромная машина с ужасной архитектурой. Точно так же asp.net намного медленнее asp.net mvc—потому что для отображения той же странички asp.net обрабатывает page life cycle, все события, viewstate, session state, бла-бла-бла, т.е. по пятнадцать раз проходит по дереву контролов вверх и вниз. Если сильно напрячься, то по меркам asp.net можно сделать очень быстрый сайт, но он все равно будет медленным. Выше головы, конечно, не прыгнуть, но это не повод говорить, что 10 запросов в секунду—это очень много.
О какой высокой нагрузке можно говорить, если в книге sharepoint as a development platform есть раздел «Highly efficient data access», где рассказывается, как с помощью рефлексии .NET хакнуть sql базу шарепоинта (найти маппинг сущностей шарепоинта на сущности базы), чтоб делать запросы к листам руками. До такой степени он медленный и неэффективный. Да это же просто за гранью фантастики.
10 страниц в секунду дают около 140 rps, причем статики там немного. Вопрос не в скорости самого SharePoint, а в том что он делает. Можно вообще положить голый HTML на сервер и радоваться тысячам RPS. Вот только что они вам дадут в реальной жизни? Когда надо из 10к документов вытащить топ 10 по динамическому рейтингу (который нельзя просто хранить, надо считать) это все с учетом прав текущего пользователя?
Я видел подобную систему на супер-пупер-быстром asp.net. Валилась она на 5 пользователях, каждая страница генерилась по 15-20 секунд, очередь IIS быстро переполнялась.
Я видел подобную систему на супер-пупер-быстром asp.net. Валилась она на 5 пользователях, каждая страница генерилась по 15-20 секунд, очередь IIS быстро переполнялась.
я не пойму, с чем вы спорите.
в статье же ясно написано, насколько в родном Sharepoint (Foundation) бывает сложно разработать высоконагруженное решение.
а все остальное — о том, как это можно обойти.
в статье же ясно написано, насколько в родном Sharepoint (Foundation) бывает сложно разработать высоконагруженное решение.
а все остальное — о том, как это можно обойти.
1) Вешать вызов механизма синхронизации на событие SaveItem кнопки формы — достаточно плохая идея. Если я обновлю через офисное приложение/веб-сервис/REST запрос/клиентскую объектную модель и т.п. — синхронизация не отработает.
2) Если внешнюю базу вы используете исключительно для выгрузки списков SP и последующего рид-онли доступа (а судя по статье, так и есть), то в ней нет никакого смысла. Проще и быстрее настроить индексацию и получать данные через API поиска.
2) Если внешнюю базу вы используете исключительно для выгрузки списков SP и последующего рид-онли доступа (а судя по статье, так и есть), то в ней нет никакого смысла. Проще и быстрее настроить индексацию и получать данные через API поиска.
1) Согласен, но это справедливо, когда речь идет об универсальном решении. Если речь идет о СЭД (довольно узконаправленное решение), которая работает только через веб-интерфейс, проблемы нет. Вообще это вопрос не принципиальный. от себя могу добавить разве что использование ресиверов имеет много подводных камней, некоторые из которых далеко не логичны.
2) В Server — возможно. В Foundation попробуйте идексацию настроить) Кроме того не рид-онли доступ, данные меняются в базе при изменениях в списке, через ресиверы, например. БД и приложение-служба нужны для быстрого доступа к данным.
2) В Server — возможно. В Foundation попробуйте идексацию настроить) Кроме того не рид-онли доступ, данные меняются в базе при изменениях в списке, через ресиверы, например. БД и приложение-служба нужны для быстрого доступа к данным.
1) Не соглашусь про узконаправленные решения. Простой сценарий: к вашему заказчику прийдет новый вендор, которому нужно будет интегрироваться с вашим СЭД и вашими списками SP, например. Естественно, он будет обновлять их через стандартные API SP и вся ваша синхронизация рассыпется. При этом я не могу представить ни одного сценария, когда использование SaveItem может быть быстрее или надёжнее, чем ресивер.
Согласен, с интеграцией получится тяжко. Но тут ресиверы будут меньшим из сложностей, кастомное решение в Sharepoint все равно придется синхронизировать кастомно.
По поводу сценария — попробуйте обновить решение на существующее семейство сайтов (накатив новый WSP с новыми ресиверами). У меня после такого приходилось проделывать танцы с Sharepoint Manager.
По поводу сценария — попробуйте обновить решение на существующее семейство сайтов (накатив новый WSP с новыми ресиверами). У меня после такого приходилось проделывать танцы с Sharepoint Manager.
Я один не понял зачем чето во внешнюю базу выгружать? Отчеты сделать? Тогда зачем все эти пляски с ServiceApp, проще взять SSIS и выгрузить данные в список с помощью sqlsrvintegrationsrv.codeplex.com/releases/view/17652. Дальше поставить Reporting Services в режиме интеграции и налепить отчеты. Кастомного кода в SharePoint будет ровно ноль.
В самом SharePoint эффективно использовать поиск для построения выборок по большому объему данных, он, в отличие от кастомной базы, учитывает права на элементы. Если у вас SharePoint Enterprise, то это тоже не требует кастомного кода.
В принципе не понимаю зачем нужно покупать любой продукт типа XXX for SharePoint, почти все можно сделать средствами изкаропки. А что нельзя требует небольших локальных доработок.
В самом SharePoint эффективно использовать поиск для построения выборок по большому объему данных, он, в отличие от кастомной базы, учитывает права на элементы. Если у вас SharePoint Enterprise, то это тоже не требует кастомного кода.
В принципе не понимаю зачем нужно покупать любой продукт типа XXX for SharePoint, почти все можно сделать средствами изкаропки. А что нельзя требует небольших локальных доработок.
Чтобы ответить на ваш вопрос, приведу конкретный пример:
Государственный университет в регионе N хочет себе СЭД, пользователей на 100. Кроме СЭД хочет простенький портал, телефонную книгу, новости, календарики.
На Sharepoint Server денег тратить не хочется, да и нет необходимости — рейтинги, социальные сети, политики хранения контента не в почете у сотрудников.
Поэтому решили купить СЭД на Foundation, заплатив только за СЭД-надстройку (будем считать что лицензионные права на Foundation у них уже есть).
За 2-3 года документов скопилось около 60-80 тыс. (по всем группам). По ним нужно, в самом простейшем случае:
а) осуществлять быстрый и легко настраиваемый поиск (по конкретным атрибутам и без управляемых метаданных) по любым элементам и с учетом прав
б) быстро искать и исполнять задачи. задач при этом становится = (кол-во документов * 5)
Если знаете способ реализовать это на Foundation «изкаропки», пожалуйста, расскажите, очень интересно.
Государственный университет в регионе N хочет себе СЭД, пользователей на 100. Кроме СЭД хочет простенький портал, телефонную книгу, новости, календарики.
На Sharepoint Server денег тратить не хочется, да и нет необходимости — рейтинги, социальные сети, политики хранения контента не в почете у сотрудников.
Поэтому решили купить СЭД на Foundation, заплатив только за СЭД-надстройку (будем считать что лицензионные права на Foundation у них уже есть).
За 2-3 года документов скопилось около 60-80 тыс. (по всем группам). По ним нужно, в самом простейшем случае:
а) осуществлять быстрый и легко настраиваемый поиск (по конкретным атрибутам и без управляемых метаданных) по любым элементам и с учетом прав
б) быстро искать и исполнять задачи. задач при этом становится = (кол-во документов * 5)
Если знаете способ реализовать это на Foundation «изкаропки», пожалуйста, расскажите, очень интересно.
Ваш пост говорит о том, что вы немного не разобрались в вопросе. И вот почему:
1. Да, Sharepoint Server классный, да там можно чудеса делать, но, повторю, настоящий российский документооборот с нормальным юзабилити и необходимым набором функций написать на нем стоит очень и очень дорого. Любому, кто представляет себе, что такое современная российская СЭД, ясно, что 16 часов — это фантастика. Даже для специалиста такого уровня как вы. Если нужно, могу аргументировать подробнее (о том, для чего все же приходится писать кастомизации).
2. Неясно, откуда вы взяли скидку в 90% для гос. ВУЗов.
3. Вы почему-то считаете стоимость времени разработчиков, хотя из статьи ясно, что речь идет о тиражируемом решении. Его установка, как правило, даже практически не требует усилий разработчиков и специалистов по Sharepoint.
4. Вы делаете акцент на доработках вроде создания приложения-службы и собственной БД как поводе для покупки. В XXX for Sharepoint это скорее приятное дополнение. Покупают-то их не из-за этого.
Я думаю, не стоит считать заказчиков и их айтишников за дураков, которым вы открываете глаза. Может, они и дураки, но вы сейчас скорее толкаете их на ошибки. И без того многие считают, что смогут сделать свою крутую СЭД (или КИС) на Sharepoint а потом горько жалеют о своей недальновидности (я лично знаю несколько таких примеров).
Просто попробуйте как-нибудь потестить серьезное решение вроде XXX for Sharepoint или XXX Docs прежде чем обвинять компании в недобросовестном выманивании денег, и я думаю вы поймете, что я имею в виду.
1. Да, Sharepoint Server классный, да там можно чудеса делать, но, повторю, настоящий российский документооборот с нормальным юзабилити и необходимым набором функций написать на нем стоит очень и очень дорого. Любому, кто представляет себе, что такое современная российская СЭД, ясно, что 16 часов — это фантастика. Даже для специалиста такого уровня как вы. Если нужно, могу аргументировать подробнее (о том, для чего все же приходится писать кастомизации).
2. Неясно, откуда вы взяли скидку в 90% для гос. ВУЗов.
3. Вы почему-то считаете стоимость времени разработчиков, хотя из статьи ясно, что речь идет о тиражируемом решении. Его установка, как правило, даже практически не требует усилий разработчиков и специалистов по Sharepoint.
4. Вы делаете акцент на доработках вроде создания приложения-службы и собственной БД как поводе для покупки. В XXX for Sharepoint это скорее приятное дополнение. Покупают-то их не из-за этого.
Я думаю, не стоит считать заказчиков и их айтишников за дураков, которым вы открываете глаза. Может, они и дураки, но вы сейчас скорее толкаете их на ошибки. И без того многие считают, что смогут сделать свою крутую СЭД (или КИС) на Sharepoint а потом горько жалеют о своей недальновидности (я лично знаю несколько таких примеров).
Просто попробуйте как-нибудь потестить серьезное решение вроде XXX for Sharepoint или XXX Docs прежде чем обвинять компании в недобросовестном выманивании денег, и я думаю вы поймете, что я имею в виду.
Ну да, конечно. Вы обманываете заказчиков, а я не разобрался в вопросе.
«настоящий российский документооборот» это госы? Я делал документооборот в коммерческих структурах, описанных проблем не было. У госов есть другая проблема, им в принципе не нужна СЭД, у них документооборот преимущественно бумажный. Им нужна база учета-движения бумажек, а не СЭД.
Еще иногда система поручений из-за директивного метода управления, она закрывается тупо exchange, в нем есть все чтобы создавать и делегировать задачи. При небольшом кодинге можно вытаскивать отчет об исполнительской дисциплине.
16 часов это на решение одной задачи, и это много. Большинство полезных вещей в шарике можно сделать за час-два. Погружение в кодинг увеличивает время в десятки и сотни раз и чаще всего финансово неоправдано.
Скидку взял у МС.
Тиражируемое решение или нет — неважно, вы предлагаете решение проблем, которые и без вашего продукта отлично решаются. Это по сути обман покупателя, построенный на асимметричности информации.
Почему покупают — написал в посте, я миллион раз слышал ушлых продавцов решений, которые рассказывали, что шарик четотам не умеет.
ЗЫ. Я тестил хренов тучу решений, а также ковырял, смотрел как сделано внутри. Увы большинство решений полнейший отстой. EOS for SharePoint это отстой в кубе. Кстати своим постом про Service App вы это очень хорошо показали ;)
«настоящий российский документооборот» это госы? Я делал документооборот в коммерческих структурах, описанных проблем не было. У госов есть другая проблема, им в принципе не нужна СЭД, у них документооборот преимущественно бумажный. Им нужна база учета-движения бумажек, а не СЭД.
Еще иногда система поручений из-за директивного метода управления, она закрывается тупо exchange, в нем есть все чтобы создавать и делегировать задачи. При небольшом кодинге можно вытаскивать отчет об исполнительской дисциплине.
16 часов это на решение одной задачи, и это много. Большинство полезных вещей в шарике можно сделать за час-два. Погружение в кодинг увеличивает время в десятки и сотни раз и чаще всего финансово неоправдано.
Скидку взял у МС.
Тиражируемое решение или нет — неважно, вы предлагаете решение проблем, которые и без вашего продукта отлично решаются. Это по сути обман покупателя, построенный на асимметричности информации.
Почему покупают — написал в посте, я миллион раз слышал ушлых продавцов решений, которые рассказывали, что шарик четотам не умеет.
ЗЫ. Я тестил хренов тучу решений, а также ковырял, смотрел как сделано внутри. Увы большинство решений полнейший отстой. EOS for SharePoint это отстой в кубе. Кстати своим постом про Service App вы это очень хорошо показали ;)
Сорри, пост не ваш. Но качество решения EOS for SharePoint он показывает прекрасно.
Про российский документооборот — любое крупное предприятие, подчиняющееся нормативному законодательству. Не было проблем у вас — не значит что их не было ни у кого.
Знаю как минимум 2 примера того, как в крупном предприятии устали от задач в Exchange (нет контроля, слишком много свободы у исполнителя и т.д.). Это про коммерцию. Про госструктуры — бумаги много, но это вершина айсберга. Руководитель с айпадом и ЭЦП вместо бумажек, контроль, сложный поиск документов, номенклатуры дел. межведомственный документооборот вы как будто не учитываете.
Покупают не только потому, что продажник ушлый(хотя и это бывает), а потому что во всем этом есть потребность.
Знаю как минимум 2 примера того, как в крупном предприятии устали от задач в Exchange (нет контроля, слишком много свободы у исполнителя и т.д.). Это про коммерцию. Про госструктуры — бумаги много, но это вершина айсберга. Руководитель с айпадом и ЭЦП вместо бумажек, контроль, сложный поиск документов, номенклатуры дел. межведомственный документооборот вы как будто не учитываете.
Покупают не только потому, что продажник ушлый(хотя и это бывает), а потому что во всем этом есть потребность.
Какому, простите, законодательству? Приведите номера законов, обязательных для выполнения коммерческими структурами, которые требуют кастомизации шарика? Про ЭЦП и юридически значимый ДО не надо, мы не про нее говорим, мы говорим про внутренний документооборот.
ЭЦП внутри организации не нужен. Нет ни одного закона, который требует юридически значимый документооборот внутри компании. Это тоже обман, но уже в совсем другой области.
Не переводите тему. Вы же сами написали про две конкретные (и видимо самые насущные) задачи. Оказывается там не нужна кастомизация. Далее вы начинаете вилять, приплетая ЭЦП (зачем она не ясно), межведомственный ДО (который только у госов и вообще другая тема, в которой Ростелеком сидит), exchange, от которого «устали» аж две (из тысяч) компании, которым, скорее всего, чето вроде project server нужно было.
Давайте останемся в поле, которое вы изначально определили — электронный ДО (не электронно-бумажный как в госах) + мелкие портальные функции 80к документов и связанных элементов по которым надо искать.
Вы будете продолжать утверждать, что решение с кучей кастома на Foundation выгоднее для заказчика, чем Server? особенно с учетом скидок на лицензии.
ЭЦП внутри организации не нужен. Нет ни одного закона, который требует юридически значимый документооборот внутри компании. Это тоже обман, но уже в совсем другой области.
Не переводите тему. Вы же сами написали про две конкретные (и видимо самые насущные) задачи. Оказывается там не нужна кастомизация. Далее вы начинаете вилять, приплетая ЭЦП (зачем она не ясно), межведомственный ДО (который только у госов и вообще другая тема, в которой Ростелеком сидит), exchange, от которого «устали» аж две (из тысяч) компании, которым, скорее всего, чето вроде project server нужно было.
Давайте останемся в поле, которое вы изначально определили — электронный ДО (не электронно-бумажный как в госах) + мелкие портальные функции 80к документов и связанных элементов по которым надо искать.
Вы будете продолжать утверждать, что решение с кучей кастома на Foundation выгоднее для заказчика, чем Server? особенно с учетом скидок на лицензии.
Я не ухожу от темы. Вы говорите про СЭД в целом, и я про СЭД в целом.
Про поле не совсем так, не упрощайте, и обратите пожалуйста внимание на строку «в самом простом случае».
Ок, мы выяснили, что какое-то решение на Sharepoint Server может оказаться дешевле чем тяжелая кастомизация на Foundation, при наличии нормальных спецов и четком понимании, что нужно сделать (не применительно к статье). Если выгоду измерять деньгах — без вопросов, такое возможно.
Другой вопрос, насколько это решение будет соответствовать функциональным потребностям и насколько им можно будет пользоваться (выгода от практического применения).
Как я понял, о чем разговор сейчас:
Вы говорите «сделать самим дешевле, продавцы СЭД на Sharepoint вас, как правило, накалывают», я говорю «нет, не накалывают».
Чтобы не быть голословнымм, приведу несколько (далеко не все) востребованных функций СЭД, которые сложно реализовать в шарике из коробки, и для которых в коробочных СЭД есть кастомизации:
1. Поля типа «расширенный лукап». Не стандартный лукап sharepoint (который не слишком удобен), а нормальный такой контрол, позволяющий искать подходящие организации (например) по инн, e-mail и на лету добавлять новые. Полезно при регистрации входящих писем.
2. Разграничение прав по полям. Особые права, например, требуются для поля «рег. номер».
3. Сложное (и быстро работающее, без потолка в 50 000) разграничение прав доступа. Не просто с наследованием от родительского элемента, а с многими хитрыми дополнениями.
4. Легко настраиваемые РП согласования, с возможностью запуска доп. согласований, условий, циклов, настройки прав на каждом этапе. Без Sharepoint Designer, в котором, даже для создания простого РП потребуется понимание того, что же внутри системы происходит.
5. Контроль и иерархия поручений.
6. Единое и настраиваемое рабочее пространство с задачами из разных разделов и удобным исполнением, с предпросмотром документа из окна исполнения задачи. Интуитивно понятный интерфейс риббона и других окон. Что, кстати, особенно важно для заказчика.
Влегкую заточенный под СЭД Sharepoint Server продать ему вполне можно, вот только он быстро взвоет от того, что какие-то простые вещи ему приходится делать через одно место, а для доработки звать дорогого специалиста. А звать придется точно, потому что ни один заказчик не знает в точности, что ему нужно. Вообще думаю, вы согласитесь с очевидной вещью:
«Продуманный аналитиками, протестированный множеством пользователей функционал и интерфейс пользователя сложной информационной системы, в среднем, намного лучше чем качественная одиночная кастомизация продукта, изначально под предметную область слабо приспособленного»
И весь вопрос сейчас в том, что вы считаете, что шарик для СЭД норм, а я считаю, что шарик для СЭД нужно серьезно доделывать. Если согласны, давайте говорить по существу этого вопроса, не отвлекаясь.
Про поле не совсем так, не упрощайте, и обратите пожалуйста внимание на строку «в самом простом случае».
Ок, мы выяснили, что какое-то решение на Sharepoint Server может оказаться дешевле чем тяжелая кастомизация на Foundation, при наличии нормальных спецов и четком понимании, что нужно сделать (не применительно к статье). Если выгоду измерять деньгах — без вопросов, такое возможно.
Другой вопрос, насколько это решение будет соответствовать функциональным потребностям и насколько им можно будет пользоваться (выгода от практического применения).
Как я понял, о чем разговор сейчас:
Вы говорите «сделать самим дешевле, продавцы СЭД на Sharepoint вас, как правило, накалывают», я говорю «нет, не накалывают».
Чтобы не быть голословнымм, приведу несколько (далеко не все) востребованных функций СЭД, которые сложно реализовать в шарике из коробки, и для которых в коробочных СЭД есть кастомизации:
1. Поля типа «расширенный лукап». Не стандартный лукап sharepoint (который не слишком удобен), а нормальный такой контрол, позволяющий искать подходящие организации (например) по инн, e-mail и на лету добавлять новые. Полезно при регистрации входящих писем.
2. Разграничение прав по полям. Особые права, например, требуются для поля «рег. номер».
3. Сложное (и быстро работающее, без потолка в 50 000) разграничение прав доступа. Не просто с наследованием от родительского элемента, а с многими хитрыми дополнениями.
4. Легко настраиваемые РП согласования, с возможностью запуска доп. согласований, условий, циклов, настройки прав на каждом этапе. Без Sharepoint Designer, в котором, даже для создания простого РП потребуется понимание того, что же внутри системы происходит.
5. Контроль и иерархия поручений.
6. Единое и настраиваемое рабочее пространство с задачами из разных разделов и удобным исполнением, с предпросмотром документа из окна исполнения задачи. Интуитивно понятный интерфейс риббона и других окон. Что, кстати, особенно важно для заказчика.
Влегкую заточенный под СЭД Sharepoint Server продать ему вполне можно, вот только он быстро взвоет от того, что какие-то простые вещи ему приходится делать через одно место, а для доработки звать дорогого специалиста. А звать придется точно, потому что ни один заказчик не знает в точности, что ему нужно. Вообще думаю, вы согласитесь с очевидной вещью:
«Продуманный аналитиками, протестированный множеством пользователей функционал и интерфейс пользователя сложной информационной системы, в среднем, намного лучше чем качественная одиночная кастомизация продукта, изначально под предметную область слабо приспособленного»
И весь вопрос сейчас в том, что вы считаете, что шарик для СЭД норм, а я считаю, что шарик для СЭД нужно серьезно доделывать. Если согласны, давайте говорить по существу этого вопроса, не отвлекаясь.
Ок, давайте:
1) sptypescript.codeplex.com/SourceControl/latest#SPTypeScript/Sample_FieldLookupBySearch/ Сделал за день. Допилить до нужной кондиции еще день.
2) Честное разграничение прав по полям в шарике не сделаешь. На уровне UI легко можно, из этого же репозитария: sptypescript.codeplex.com/SourceControl/latest#SPTypeScript/Sample_CSRComplexityField/
3) Отдельные папки\списки\сайты и поиск. Ограничения «хитрее», чем даются платформой не сделаешь, или это будут не ограничения, а фикция.
4)Встроенный WF, возможно потребуется добавить несколько workflow action, у меня создание сложного WFAction заняло 4 часа.
5)Встроенный список задач в SP 2013
6)бла-бла-бла. слова ни о чем.
На этом думаю можно закончить. Пока вы не сможете использовать возможности, перечисленные выше вы вряд ли научитесь делать нормальные решения.
Еще раз повторю, решения на Foundation обычно повторяют функционал Server. Впаривать их со словами что «стандартный так не умеет и вообще у нас все особенное» — обман. Я не против доделывать шарик, я говорю что можно доделывать на порядок дешевле.
1) sptypescript.codeplex.com/SourceControl/latest#SPTypeScript/Sample_FieldLookupBySearch/ Сделал за день. Допилить до нужной кондиции еще день.
2) Честное разграничение прав по полям в шарике не сделаешь. На уровне UI легко можно, из этого же репозитария: sptypescript.codeplex.com/SourceControl/latest#SPTypeScript/Sample_CSRComplexityField/
3) Отдельные папки\списки\сайты и поиск. Ограничения «хитрее», чем даются платформой не сделаешь, или это будут не ограничения, а фикция.
4)Встроенный WF, возможно потребуется добавить несколько workflow action, у меня создание сложного WFAction заняло 4 часа.
5)Встроенный список задач в SP 2013
6)бла-бла-бла. слова ни о чем.
На этом думаю можно закончить. Пока вы не сможете использовать возможности, перечисленные выше вы вряд ли научитесь делать нормальные решения.
Еще раз повторю, решения на Foundation обычно повторяют функционал Server. Впаривать их со словами что «стандартный так не умеет и вообще у нас все особенное» — обман. Я не против доделывать шарик, я говорю что можно доделывать на порядок дешевле.
Кстати я сам продавец и знаю откуда берутся потребности ;) Готов утверждать, что таких потребностей у не-госов нет в принципе.
Я не продавец, но утверждаю что лично и не раз слышал о таких потребностях у не-госов.
Давайте спорить не будем — видимо вы встречаете одних заказчиков, а я других.
Давайте спорить не будем — видимо вы встречаете одних заказчиков, а я других.
Кто вам это говорил? Мне вот довелось общаться с пользователями. Они даже говорили такие слова, но на вопрос «зачем?» ответить не смогли. Просто увидели функционал где-то. После выявления реальных потребностей оказывалось, что оно им совсем не нужно.
вышесказанное относится только к одной статье.
другие статьи вашего блога читаю с большим интересом уже давно.
другие статьи вашего блога читаю с большим интересом уже давно.
И еще один момент, который, вы, возможно, не учитываете.
СЭД — это не портал. Принципы разграничения прав не по элементам, а по карточкам документов, например. То же самое и при отображении. Документ в СЭД — это же не просто элемент в списке или библиотеке, это элемент, связанный с кучей всего, вроде связанных файлов, других документов, журналов, поручений (которые еще связаны с задачами). Принципы работы довольно сильно отличаются. XXX for Sharepoint нужны как раз для адаптации Sharepoint к российскому документообороту, чего из коробки никак не сделать.
СЭД — это не портал. Принципы разграничения прав не по элементам, а по карточкам документов, например. То же самое и при отображении. Документ в СЭД — это же не просто элемент в списке или библиотеке, это элемент, связанный с кучей всего, вроде связанных файлов, других документов, журналов, поручений (которые еще связаны с задачами). Принципы работы довольно сильно отличаются. XXX for Sharepoint нужны как раз для адаптации Sharepoint к российскому документообороту, чего из коробки никак не сделать.
масштабируемость (приложение-службу можно размещать на нескольких серверах);
Я вас расстрою, но в таком виде ваше приожение-службу нельзя размещать на нескольких серверах. Я не вижу чтобы ваш ServiceApplication реализовывал интерфейс веб-сервиса, и код в эвент-ресивере, скорее всего, лезет непосредственно в базу
Если не обращать внимание на передергивание в заголовке, то gandjustas говорит о том что, если есть скидка 90% на Майкрософт, если есть своя команда специалистов по Шарепоинт, и есть много разных задач «на будущее» то купить за 10% от прайса SharePoint Standard в этом случае выгоднее чем готовую надстройку на SharePoint. И в ряде случаев с этим утверждением не поспоришь, но обобщать на все ситуации, а заодно на «почти все Российские решения» скорее всего не стоило.
Плюс можно долго изобретать велосипед, разрабатывая и учитывая все особенности российского документооборота, все тонкости движения документов, работу с штрих-кодами, ЭЦПой, мобильными клиентами, юзабилити и прочее и прочее и прочее, разрабатывая самому систему год или полтора, или не изобретать велосипед и купить готовое решение, внедрить за короткий промежуток времени, и решать задачи бизнеса, а не желание ИТ-отдела по хардкоддингу. У каждого свой путь, как пел Фрэнк Синатора ;)
Плюс можно долго изобретать велосипед, разрабатывая и учитывая все особенности российского документооборота, все тонкости движения документов, работу с штрих-кодами, ЭЦПой, мобильными клиентами, юзабилити и прочее и прочее и прочее, разрабатывая самому систему год или полтора, или не изобретать велосипед и купить готовое решение, внедрить за короткий промежуток времени, и решать задачи бизнеса, а не желание ИТ-отдела по хардкоддингу. У каждого свой путь, как пел Фрэнк Синатора ;)
Sign up to leave a comment.
Написание высоконагруженных корпоративных решений на SharePoint