|
03.06.2010, 16:36 | #1 |
Участник
|
Спасибо за замечательное обсуждение. Я тоже, как и Шурик71 подозреваю, что проблема имеется, и она концептуальная. Вроде знаю 3 подхода к описанию процессов - алгоритмический, функциональный, и стейт-машина.
В современных языках это все реализовано. Для обслуживания алгоритмов используются: - операторы ветвления и перехода - циклы - рекурсия - стек, в котором сохраняется весь контекст нитки - цепочка вызовов и данные. - объекты синхронизации ниток (семафоры-мониторы) Нити выполнения в нормальных языках типа Java являются сериализуемыми, что позволяет нитке заснуть в базе данных, и проснуться по событию. Проблема - все жизненные ситуации надо описать отдельными ветками, а это не всегда возможно, да и дерево получится нечитаемое. Для функционального подхода используют декларативные языки типа SQL или XSLT, которые интерпретируются неким "оптимизатором". Проблема - надо иметь оптимизатор, который на самом деле является шайтаном Для стейт-машин существуют механизмы событий (асинхронных и синхронных), подписок, и собственно устройство синхронизации (типа тактового генератора, или прерывания таймера). Тут не надо описывать все возможные варианты, и даже предсказать поведене системы не всегда возможно. Больше соответствует нашей жизни, чем первые 2. На этих механизмах стоит вся ИТ-индустрия. Но все это очень наукоемко и сложно для понимания, и бизнес хочет чего-нибудь попроще, и применительно к системе управления социумом. Вот и возникают всякие теории процессного менеджмента, а к ним - и инструменты автоматизации. Но на практике те БП, которые я видел в текстовом виде, больше напоминают помесь декларативного описания результата и таблицы состояний/реакций для каждого исполнителя. И описывать это все на алгоритмах - просто ужас. Вроде в WSS подписки на события имеются, значит стейт-машину реализовать можно, но наш опыт пилотного проекта на MOSS пока не очень впечатляет - функционала Дизайнера не хватает, а БП, разработанные в Студии - не визуализируются. Кругом засада. Последний раз редактировалось Индра; 03.06.2010 в 16:56. |
|
|
За это сообщение автора поблагодарили: Nick (2). |
07.06.2010, 15:12 | #2 |
Участник
|
Две недели промэксплуатации. 247 записей трекинга, 75 требований. Скрины приложил.
Файловая база, сервер приложений 1С не устанавливали - весь код, насколько я понимаю, выполняется в адресном пространстве IIS, файлы лежат там же. Больше 10 одновременных подключений не замечено. Пока все неплохо работает. Разбираюсь как приспособить объект "Задача" для целей уведомления ленивого пользователя об изменении важного документа (чтобы не просто письмо получил, а нажал кнопку "я прочитал"). Последний раз редактировалось Индра; 07.06.2010 в 15:15. |
|
07.06.2010, 18:29 | #3 |
Участник
|
Я надеюсь, что вы в курсе, что при таком подходе у вас нет параллельной работы пользователей и код всех сеансов выполняется последовательно по ФИФО? Это хуже чем в 1С 7.7. с ее общим журналом - там стопорились транзакции, а тут весь код.
|
|
|
За это сообщение автора поблагодарили: mazzy (2). |
07.06.2010, 18:53 | #4 |
Участник
|
1. Индра, спасибо.
2. Продолжаем отслеживать эволюцию взглядов на проект. Начал FE здесь Было. Цитата:
Сообщение от Индра
Крупный заказчик на 500 пользователей хочет конструктор для автоматизации бизнес-процессов. ТЗ выглядело примерно так - "хочу позвонить в секретариат, и поручить девушкам к завтрашнему утру нарисовать бизнес-процесс, а к обеду запустить в промышленую эксплуатацию в масштабах холдинга".
... Ну и традиционные сомнения - потянет ли 500 пользователей и 100 Гб файловый архив. Цитата:
Сообщение от Индра
К сожалению - не успел пощупать объекты "Задача" и "Бизнес-процесс" (в текущем функционале информобмен строился на смене статусов и трекинге значимых атрибутов).
Дальнейшие планы - запустить сотню пользователей, посмотреть на поведение платформы, параллельно усложнить логику программы - порождать объекты "Задача", а для отдельных случаев и бизнес-процесс запустить... |
|
08.06.2010, 08:45 | #5 |
Участник
|
Друзья, спасибо что не забываете !
Про ФИФО - по моему не совсем так. IIS держит пул тредов для обслуживания HTTP-запросов, и в каждом треде создается объект WEB-расширения 1C. Я не знаю как сам 1С реализовал этот модуль - если там используется синглтон (единственный экземпляр объекта) и всего одна сессия к файлу - это грустно. Надеюсь что парни из 1С умные. Если на каждый IIS-тред создается отдельный экземпляр коннектора, который самостоятельно открывает файл - это очень даже хорошо, потому что позволяет управлять количеством сессий к файлу через размер пула IIS. Но даже если там жесткое ФИФО - пока никто особо не жалуется, а перейти на серевер приложении или даже на SQL мы всегда успеем. Будем решать проблемы по мере их поступления. Маззи, не надо передергивать. Глобальная задача, озвученная мной в начале никуда не делась. Но чтобы не опозориться, я запустил маленький бесплатный пилотный проект, поставив эту программу в жесткие условия. И то, что она до сих пор жива - это хоть и странно, но приятно. Также приятно, что количество запросов на поддержку намного меньше количества транзакций в нашей учетной системе, которая Axapta. Ура, товарищи ! |
|
08.06.2010, 10:32 | #6 |
Участник
|
Цитата:
06.04.2010 вы запустили эту ветку, сказав что к этой дате уже 2 месяца изучали SharePoint. 08.06.2010, сегодня, вы сказали, что запустили всего-лишь пилотный проект на 1С (т.е. опять же 2 месяца "изучали"). Собственно что интересует: Каково ваше мнение (мнение человека, который изучал по 2 месяца оба подхода), какое решение (SharePoint или 1С) больше подходит для решения первоначальной задачи? Цитата:
конструктор для автоматизации бизнес-процессов - "хочу позвонить в секретариат, и поручить девушкам к завтрашнему утру нарисовать бизнес-процесс, а к обеду запустить в промышленую эксплуатацию в масштабах холдинга".
|
|
08.06.2010, 12:00 | #7 |
Участник
|
Цитата:
Как портал + хранилище документов - MOSS имеет большую фору за счет тесной интеграцией с офисом (правка задачи прямо из Word/Excel, передача параметров из MOSS в шаблон Ворд, наличие всех необходимых ActiveX в последних версиях IE). Для слабо-формализованной среды MOSS - идеальная система. Там же, где логика более жесткая, необходимы функции учетной системы - система слабая, и 1С больше подходит, хотя и не так красиво выглядит. |
|
|
За это сообщение автора поблагодарили: mazzy (2). |
08.06.2010, 12:36 | #8 |
Участник
|
Для решения первоначальной задачи нужен дохтур, который доходчиво втолкует, что бизнес-процессы должен рисовать бизнес-аналитик, который хорошо видит бизнес в целом, а не девочки из секретариата =)
|
|
08.06.2010, 13:36 | #9 |
Участник
|
Совсем без кода у Вас не получится. Программа пишет историю изменения всех атрибутов, отправляет емейлы подписчикам, автоматически подписывает автора и исполнителя, допустимые ответственные привязаны к проектам, если ответственный не указан - система подбирает его сама - из "первой линии" проекта, и наименее загруженного (считает количество незакрытых требований), ежедневно отслеживает просрочку. Такое не параметризуется, или мне пора на пенсию
PS Доктор не нужен. БП уже описаны, но в Ворде. Задача условного секретариата - переложить на систему. Если будет система... PPSS Почему не в Аксапте. Я не смог получить от вендора устраивающего меня ответа о правилах лицензирования собственных модулей. Предполагается, что круг пользователей системы сервис-деск шире, чем пользователей Axapta, а докупать лицензии по нашей текущей цене слишком дорого. А другой цены нет. Последний раз редактировалось Индра; 08.06.2010 в 13:52. |
|
08.06.2010, 12:24 | #10 |
Участник
|
Цитата:
Что мешало тоже самое сделать в Аксапте? =) З.Ы. Посмотрел по скриншотам, imho, на WSS + SRS при небольшой сноровке такое можно за неделю сделать без программирования с большими перерывами на кофе и чтение формумов. Выглядеть может немного неуклюже, но работать будет =) З.З.Ы. На MS CRM такую шнягу можно сделать за полдня (без программирования) + отчеты на SRS + часик на настройку всяких напоминаний и рассылок. |
|
Теги |
sharepoint, выбор системы, документооборот |
|
|