Lotsia PLM: Форум по семейству систем PLM/PDM/TDM/ERP/Workflow

Всем привет, нужна консультация.
Мы запускаем первый в жизни бизнес процесс - не знаю зачем, но не важно
картинка такая в двух словах,
- работа стартует и в ней параллельно могут быть запущены блоки 3,4,5 (причем блоков типа 3 может быть запущено неограниченное количество)
- блок типа 2 может быть запущен из любого блока бизнес процесса, но не больше чем один раз для одного блока типов 3,4,5 (т.е. одновременно их может быть запущено несколько)
- текущее состояние выполнения каждого блока будет отражено на форме начала работы в виде индикаторов прогресса (правда для типа 3 непонятно - ведь сколько их будет неизвестно заранее)
ps
каждый из блоков 2,3,4,5 крутится внутри себя пока не выполнится

вопрос такой - какого типа нужно определить блоки 2 и 3 (внешние или внутренние работы) чтобы это вписалось в концепцию т.е. можно было бы посмотреть контроль выполнения в рамках одного бизнес процесса?

1!
вложенные работы должны быть, тогда контроль исполнения будет один общий.
но в принципе можно сделать и внешние - тогда просто основной процесс завершится, оставив после себя самостоятельные процессы. и их тоже можно будет контролировать.
тут смотря как хочется организовать контроль исполнения. если по атрибутам - то не важно, внешние или вложенные.
если по контролю - то лучше наверное вложенные.
кстати, не уверен, что на форме начала объекта будет прогресс процесса. и дело тут не в неопределенности кол-ва процессов.. этот прогресс бар лучше сделать где то отдельно. объект ведь будет какой то ходить по этому процессу?

спасиб!, нужно в рамках бизнес процесса, тогда только вложенные (просто из хелпа не совсем ясно и я думал что это просто разгрузка основной картинки алгоритма)
вообще контроль исполнения наверно по отчету придется, без прогресс баров... ведь неясно общее количество вложенных работ...
или
скажи - а чтобы не трогать атрибуты, можно ли прогрес прогрессов организовать на переменных вложенных работ?

объект наверно ходить не будет...
объект будет для старта работы (кнопка на атрибутивной форме объекта) с одной стороны, для задания начальных условий с другой, и как корень для создания дерева карточек документов накапливаемых по ходу бизнес процесса - лишних атрибутов для сопровождения внутренних работ не хотелось бы использовать...

ps
а почему на форме начала работы ничего не получится - ведь мы ее запустили из нее запустили вложенные работы и в ней же контролируем...
или это из за переходов? но ведь их можно зациклить на блок начала работы? или нет

ps
Андрей, сори я текст топика поправил

Александр писал(а):нужно в рамках бизнес процесса, тогда только вложенные (просто из хелпа не совсем ясно и я думал что это просто разгрузка основной картинки алгоритма)

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

Александр писал(а):скажи - а чтобы не трогать атрибуты, можно ли прогрес прогрессов организовать на переменных вложенных работ

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

Александр писал(а):а почему на форме начала работы ничего не получится - ведь мы ее запустили из нее запустили вложенные работы и в ней же контролируем...

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

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

ну с переменными вложенных работ ведь можно сделать следующее (в плане прогресс баров на переменных (динамическом массиве) родительской формы работы)
вложенная работа может завершаться не по завершению ее алгоритма а сразу же после старта... тут же запускаясь вновь, уже автоматом, с другими начальными атрибутами
другими словами
- или запустили вложенную работу в ней стартовали счетчик до 10 и когда он кончится - вышли
- или запустили вложенную работу в ней увеличили счетчик на 1, вышли и тут-же в автомате стартовали с начальным значением +1
(при этом отключив все сообщения от старта стопа вложенной работы - чтобы внутренний почтовый ящик Лоции не повесить)
ps
хотя при таком раскладе вложенная работа будет терять смысл - я хотел в ней контролировать дату и прикладывать документы по кнопке... а так это все будет пролетать мимо, хотя наверно можно как-то обойти предложив юзеру - а не хотите ли выполнить те или иные действия...
ладно вообще это бред

1. слушай а из вложенной работы мы можем управлять переменными родительской работы? (по аналогии с тем что из внедренного массива на форме мы можем обратиться к переменным самой формы)
2. ты мне главное скажи - вложенную работу можно запустить несколько раз на параллельное выполнение?, типа на форме есть кнопка - запустить процесс мы ее 100 раз нажали и сто внутренних работ крутится одновременно? (при этом понятно что родительская работа не завершится пока не закончатся все дочерние вложенные работы))

Александр писал(а):- или запустили вложенную работу в ней стартовали счетчик до 10 и когда он кончится - вышли
- или запустили вложенную работу в ней увеличили счетчик на 1, вышли и тут-же в автомате стартовали с начальным значением +1
....

ээээ.. не уверен, что вложенные работы потерпят такое отношение к себе

Александр писал(а):1. слушай а из вложенной работы мы можем управлять переменными родительской работы? (по аналогии с тем что из внедренного массива на форме мы можем обратиться к переменным самой формы)

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

Александр писал(а):2. ты мне главное скажи - вложенную работу можно запустить несколько раз на параллельное выполнение?, типа на форме есть кнопка - запустить процесс мы ее 100 раз нажали и сто внутренних работ крутится одновременно? (при этом понятно что родительская работа не завершится пока не закончатся все дочерние вложенные работы))

запустить можно, причем, в шаблоне это может бы не определено заранее и решаться при запуске. но другое дело, что, запустив в рамках одной пары разделитель-объединитель (Р-О) 3 вложенных работы, мы не можем передумать и запустить еще 2. пока эта пара РО не завершится, новые вложенные работы внутри нее мы не запустим.
поэтому, если хочется запускать вложенные работы (с расчетами, например) сколько угодно раз и не зависеть от от уже запущенных расчетов, лучше их сделать отдельными процессами. в рамках одного процесса будет сложновато и не так гибко. задачи, которые одновременно могут быть невыполненными, могут быть только в внутри одной пары Р-О. а запустить новые вложенные задачи можно только из невыполненной задачи. и может быть придется делать возможность запуска других вложенных работы внутр уже запущенной вложенной работы. в принципе это работает, но вряд ли это всегда будет удобно

...
в итоге для решения этой задачи - параллельности/многозадачности.. (с заранее неизвестным количеством дочерних процессов)
1. остаются только Внешние работы которые и в родительский бизнес процесс (блок схему) включать необязательно, просто запуская их как самостоятельные из формы начала работы кнопками и передавая в них параметры...
2. а в качестве хранения глобальных переменных (для обмена и контроля внутри основного процесса) использовать атрибуты объекта от которого стартовала работа (например в текстовой разметке хml для хранения в одном атрибуте массива переменных от параллельных работ.. правда длина строки только 2000 символов и массив всегда будет ограничен((( )
3. и контроль исполнения вести штатными средствами отдельно по каждой внешней работе отдельно, и по атрибутам объекта на форме начала работы для всего процесса в целом...
ps
правда и форма работы тогда уже не нужна - можно напрямую все нарисовать, стартовать и отслеживать с атрибутивной формы объекта + несколько форм пользовательских отчетов для этого объекта (типа контроль исполнения дочерних и основного процесса)
pps
и получается что WorkFlow (для решения данной задачи в рамках одного алгоритма) опять не в кассу

правильно я понял?
Слушай Андрей а есть ли какие нибудь интересные ходы если работать по такой асинхронной схеме, или подводные камни - чтобы время не терять?

Александр писал(а):и получается что WorkFlow (для решения данной задачи в рамках одного алгоритма) опять не в кассу

хм... это как посмотреть..
с п.1-3 и ps согласен. все именно так и можно сделать.
нужен ли воркфлоу?
если будет объект в дереве, по которому кто то будет время от времени тыкать и запускать "процесс" в рамках которого просто придет задача другому юзеру, юзер ее выполнит и на этом процесс закончится - то может быть и не нужен воркфлоу
хотя юзера же надо как то известить, что у него появилась работа. это можно сделать и простым сообщением, в принципе. тем более, если факт его новой работы будет записан в атрибуте объекта.
другое дело, что вряд ли все так просто, что достаточно будет одной задачи. скорее всего должны инициироваться более длинные цепочки, каждая из которых должна дойти до конца, пройдя все нужные этапы, двигаясь вперед-назад (с доработками и перепроверками/пересогласованиями). и процессов по объекту может быть куча, и в атрибуты каждый чих просто замучаешься записывать, а потом еще и анализировать это..
и вот тут уже воркфлоу пригодится
стандартный контроль исполнения полезен, когда нужно детально посмотреть на какой то конкретный процесс. наблюдать за кучей процессов через него будет нереально.
а вот в какой то общей справке (не в контроле исполнения)по всем таким процессам показать текущих исполнителей этих процессов - это более удобно.
скорее всего будет какой то комбинированный способ контроля - и по атрибутам, и по данным процессов. например, хранить конкретных текущих исполнителей и даты старта задач у них в виде атрибутов вряд ли целесообразно - эта инфа есть в таблицах воркфлоу.
общее число процессов по конкретному объекту и число завершенных можно хранить в атрибутах объекта, обновляя их по мере запуска/завершения процессов. а можно вытаскивать из тех же таблиц (хотя это вроде сложнее).
объект в итоге все равно пригодится и будет играть роль связующего звена между всеми процессами, запущенными по этому объекту (по таблицам можно быстро собрать все задачи и переменные по картам, в которые вложен конкретный объект)
про ходы и камни сложно быстро рассказать.. могу только сказать то, что сделано у нас.
1. есть отчет, в который попадают объекты с атрибутами, для каждого объекта показываются текущие исполнители и дата старта задачи у них. по нему видно, какие объекты еще не дошли до конца (не обросли нужными атрибутами), при этом видно, по каким из них запущены процессы и в каком состоянии они находятся
2. есть самодельный контроль исполнения, который показывает все текущие процессы для текущего объекта, даже если они не вложенные
3. есть подсистема хранения основных данных о завершенных процессах. по сути это данные из таблиц воркфлоу, но они остаются доступными после удаления карт процессов
кстати, вспомнил, что есть пара запросов, которые анализируют значения переменных в процессах (это пока только запросы, а не отчеты для юзеров), так что вытащить переменные тоже реально.
вот как то так...

спасибо огромное! вроде для старта понятно на 51%
ну и такой вопрос
1. можно ли узнать id основного процесса
2. можно ли узнать id процессов родителей и или детей процесса с известным id
3. и как обратиться к переменным процесса зная его id

если будет время конечно, и возможность...
не покажешь примеры запросов для пунктов 2 и 3?

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

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

примеры запросов для этих пунктов?

Александр писал(а):2. можно ли узнать id процессов родителей и или детей процесса с известным id
3. и как обратиться к переменным процесса зная его id

ага, попробую на досуге, где то были наброски.
по п.1 - это ИД карты, можно посмотреть в окне свойств запущенной карты (не шаблона!)
п.2 можно раскопать из стандартного отчета Контроль исполнения - профайлером
вроде у процесса есть отдельное поле - ИД родительского процесса, но я не знаю точно, как оно называется и заполняется

да для этих пунктов))
Заранее спасибо

этот запрос вытаскивает ИД, описание и значение переменной "template_id" из всех шаблонов ("is_template = 't')
а этот запрос возвращает карту с ИД 100058785800001 и ее карты-потомки
а этот мега-запрос - инфу по картам, в которые вложен объект с ИД = 100002331100001. запрос работает и используется, хотя я уже не уверен, что он неизбыточный и оптимальный

нужны комментарии
шаблон - это шаблон (Т) а карта (М) - это запущенный шаблон?
т.е. чтобы в первом запросе обратиться к текущему значению переменной запущенной карты (M) просто добавляем в were id карты?
...
where is_template = 'M'
and id = 00000000

только слушай - не нашел где вязать id запущенной карты

да, все так (хотя я предпочитаю думать, что карта запускается по шаблону, при этом шаблон копируется и становится картой )
про запрос с 'M' - да, вроде так.
ИД карты - это ее ИД из окна свойств карты. на пустом месте открытой карты тыкаешь правой кнопкой - Свойства - поле ID, в виде 100058785800001
только свойства на пустом месте, а не на задаче или переходе