Комментарии 13
Я не хочу подробно рассказывать о возможностях этого продукта
По-моему, Вы именно это и сделали.
Статья интересная, но позволю заметить, что state machine на русский переводится обычно как «конечный автомат».
:) спасибо за замечание. Так и есть. Правда по опыту общения с людьми, не знающими функций sm, замечено, что словосочетание «машина состояний» вызывает более адекватные ассоциации. Только поэтому использовала именно его
А позвольте тогда поинтересоваться как будет обычно переводиться понятие из Cisco IVR 2.0 «Finite State Machine (FSM)»? :)
Я выбрасываю белый флаг:) Вы абсолютно правы:)
Я думаю, точно так же. Во-первых, обычно, когда говорят state machine, подразумевают finite, а во-вторых, исторически в русском не сложилось двух разных понятий для этих моделей.
Чтоб проверить, вы можете зайти на википедию, на статью state machine, и потом выбрать слева русскую версию статьи--вы окажетесь на статье «конечный автомат»)
Чтоб проверить, вы можете зайти на википедию, на статью state machine, и потом выбрать слева русскую версию статьи--вы окажетесь на статье «конечный автомат»)
Скажите, какова цена вопроса? На сайте можно сделать запрос на расценки в зависимости от кол-ва серверов (страшно не люблю такие вещи)
Опишу свои впечатления от работы с NW с позиции разработчика SharePoint:
1) Функционал. В самом начале работы с NW, количество activity конечно впечатляет, но при дальнейшей разработке начинаешь натыкаться на неприятные ограничения.
Например: часто для построение маршрута процесса нам нужно читать какие-нибудь настроечные списки и использовать прочитанные данные. Тут мы автоматом натыкаемся на то, что прочитать из списка стандартным действием мы можем только одну колонку. Приходится извращаться, плодить коллекции для каждой колонки и потом определенным образом каждую из них читать.
Из этой же серии — невозможность нормального задания due date при создании flexi task или, например, сборе рецензий. Или, еще нельзя задать необходимые разрешения на задачу: это означает, что у всех участников должны быть права, как минимум, contributor на весь список задач и все участники всегда будут видеть все задачи всех процессов.
А с каким-то из недавних билдов, разработчики NW вообще отмочили — теперь Flexi task activity пишет ID созданного таска не при создании задачи, а при её выполнении. Приходится самому лезть в список задач (в параллельном действии, еще и подождав при этом минут 5, чтобы быть уверенным, что задача уже создана) и пытаться определить какая задача нам нужна.
Хотя, надо отметить, что плагины на nintex connect, в половине случаев, помогают решить косяки разработчиков Nintex.
2) Надёжность. Надо понимать, что Nintex — это всего лишь надстройка над SharePoint Workflow, т.е. вы наследуете все проблемы как SharePoint Workflow, так и WWF. Так, на одном из проектов, при большом количестве процессов, «удалось» словить мощный глюк, когда большое количество процессов тупо лочило все свои задачи и никто из участников не мог их сдвинуть. Проблема массу раз описана на форуме Nintex, ТП Nintex кивает на MS, ТП MS кивает на Nintex, заказчик в бешенстве.
3) Стоимость. Согласен с автором, насчёт округляющихся глаз заказчика. Поэтому, как правило, покупка Nintex планируется под набор процессов.
Если кому интересны аналоги Nintex — основные, это K2 BlackPoint (у них свой движок) и Datapolis Workbox 2010.
1) Функционал. В самом начале работы с NW, количество activity конечно впечатляет, но при дальнейшей разработке начинаешь натыкаться на неприятные ограничения.
Например: часто для построение маршрута процесса нам нужно читать какие-нибудь настроечные списки и использовать прочитанные данные. Тут мы автоматом натыкаемся на то, что прочитать из списка стандартным действием мы можем только одну колонку. Приходится извращаться, плодить коллекции для каждой колонки и потом определенным образом каждую из них читать.
Из этой же серии — невозможность нормального задания due date при создании flexi task или, например, сборе рецензий. Или, еще нельзя задать необходимые разрешения на задачу: это означает, что у всех участников должны быть права, как минимум, contributor на весь список задач и все участники всегда будут видеть все задачи всех процессов.
А с каким-то из недавних билдов, разработчики NW вообще отмочили — теперь Flexi task activity пишет ID созданного таска не при создании задачи, а при её выполнении. Приходится самому лезть в список задач (в параллельном действии, еще и подождав при этом минут 5, чтобы быть уверенным, что задача уже создана) и пытаться определить какая задача нам нужна.
Хотя, надо отметить, что плагины на nintex connect, в половине случаев, помогают решить косяки разработчиков Nintex.
2) Надёжность. Надо понимать, что Nintex — это всего лишь надстройка над SharePoint Workflow, т.е. вы наследуете все проблемы как SharePoint Workflow, так и WWF. Так, на одном из проектов, при большом количестве процессов, «удалось» словить мощный глюк, когда большое количество процессов тупо лочило все свои задачи и никто из участников не мог их сдвинуть. Проблема массу раз описана на форуме Nintex, ТП Nintex кивает на MS, ТП MS кивает на Nintex, заказчик в бешенстве.
3) Стоимость. Согласен с автором, насчёт округляющихся глаз заказчика. Поэтому, как правило, покупка Nintex планируется под набор процессов.
Если кому интересны аналоги Nintex — основные, это K2 BlackPoint (у них свой движок) и Datapolis Workbox 2010.
У меня дружба с flexi task так и не сложилась. Я использую практически на всех проектах обычные to-do task. В них можно добавить необходимые варианты выбора, а остальные поля скрыть или закрыть от редактирования. Единственный минус — тут не применишь лэйзик. При таком подходе Ваша проблема с id и с due date легко решаема.
Проблема с правами вообще общая для SharePoint и зачастую для реализации нормального защищенного доступа к данным требуется разрыв прав.
Насчет уязвимости согласна. Практика показала, что уязвимы очень большие процессы и автозапускаемые процессы. При нагрузке с ними бывают проблемы. Есть способы обойти некоторые тонкие места, но нужно смотреть на конкретный случай.
Проблема с правами вообще общая для SharePoint и зачастую для реализации нормального защищенного доступа к данным требуется разрыв прав.
Насчет уязвимости согласна. Практика показала, что уязвимы очень большие процессы и автозапускаемые процессы. При нагрузке с ними бывают проблемы. Есть способы обойти некоторые тонкие места, но нужно смотреть на конкретный случай.
А подскажите пожалуйста какие-нибудь конкретные характеристики, чтобы можно было быстро оценить пользу предлагаемого решения. Например, о цене вы говорите с загадочностью посвященных в тайное знание. Подскажите просто цену в рублях или долларах для какой-нибудь конфигурации. Еще вопрос: нагрузочные характеристики. Сколько «одновременно» работающих пользователей реально смогут работать без блокировки, описаной в комментарии. Можно ли подключать базу данных (сделать CRM систему на базе Shate Point). И неужели нет разделения прав пользователей?
Я понимаю, что все это можно прочитать в материалах Microsoft, но тем и ценно сообщество, что кто-то на практике сталкивается с продуктом и может буквально в паре строк описать его реальные достоинства, недостатки и ограничения. Заранее благодарен за ответ.
Я понимаю, что все это можно прочитать в материалах Microsoft, но тем и ценно сообщество, что кто-то на практике сталкивается с продуктом и может буквально в паре строк описать его реальные достоинства, недостатки и ограничения. Заранее благодарен за ответ.
sergeypip, постараюсь раскрыть Вам тайные знания :) О цене — цена на серверную лицензию зависит от типа этой самой лицензии (Standard Edition, Enterprise Edition и Workgroup Edition) и действительно составляет от 3 до 15 тыс у.е. ИМХО, для автоматизации малого и среднего бизнеса достаточно Standard, но в Enterprise на мой взгляд больше возможностей для ведения статистики по процессам.
По нагрузке: все зависит от оборудования. SharePoint вообще любит хорошие сервера с хорошими же мощностями. Нагрузочные тесты показали, что при одновременной работе 100 человек, на системе, построенной на связке SharePoint+Nintex сервер с оперативкой 16 Гб справляется и процессы не встают в очередь.
По правам: в SharePoint права на уровне коллекции-сайта-библиотеки-списка распределяются отлично. Другое дело, когда Вам нужно в рамках одного списка разделять права на элементы. По умолчанию, чтобы создавать и редактировать элементы у пользователей должны быть определенные права (минимум на создание и резактирование). Но что делать, когда например появляются требования: доступ к созданным элементам должен иметь только автор. А это классическое требование для многих систем. В SharePoint есть возможность сделать настройку списка так, что читать и изменять элементы могут только авторы. Но в этом случае выдача дополнительных прав на элемент ничего не дает (я отправила свой элемент на согласования, а согласующий его все равно не видит). Для того, чтобы покрыть это требование, делается разрыв прав. При создании элемента права на него отбираются у всех пользователей и выдаются обратно автору, а по ходу обработки элемента и еще кому-то. Этот подход далеко не идеальный. Кстати, если у кого-то был более удачный опыт борьбы с этой проблемой — буду очень признательна обмену опытом.
CRM создать можно. Пользуюсь как раз CRM на SharePoint. Тут вопрос весь в том, какую базу будете подключать.
По нагрузке: все зависит от оборудования. SharePoint вообще любит хорошие сервера с хорошими же мощностями. Нагрузочные тесты показали, что при одновременной работе 100 человек, на системе, построенной на связке SharePoint+Nintex сервер с оперативкой 16 Гб справляется и процессы не встают в очередь.
По правам: в SharePoint права на уровне коллекции-сайта-библиотеки-списка распределяются отлично. Другое дело, когда Вам нужно в рамках одного списка разделять права на элементы. По умолчанию, чтобы создавать и редактировать элементы у пользователей должны быть определенные права (минимум на создание и резактирование). Но что делать, когда например появляются требования: доступ к созданным элементам должен иметь только автор. А это классическое требование для многих систем. В SharePoint есть возможность сделать настройку списка так, что читать и изменять элементы могут только авторы. Но в этом случае выдача дополнительных прав на элемент ничего не дает (я отправила свой элемент на согласования, а согласующий его все равно не видит). Для того, чтобы покрыть это требование, делается разрыв прав. При создании элемента права на него отбираются у всех пользователей и выдаются обратно автору, а по ходу обработки элемента и еще кому-то. Этот подход далеко не идеальный. Кстати, если у кого-то был более удачный опыт борьбы с этой проблемой — буду очень признательна обмену опытом.
CRM создать можно. Пользуюсь как раз CRM на SharePoint. Тут вопрос весь в том, какую базу будете подключать.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Опыт работы с Nintex Workflow for SharePoint 2010