Вообще конечно стандарт правее, но в данном конкретном случае стандарт довольно мутный.

По существу, как правильно замечено, все зависит от того, как эти два транзишена образовались. Если при помощи XOR или каким-то иным exclusive способом (например event), то можно завести их потом в одну задачу. Если же они породились при помощи parallel split, то Брюс Силвер, например, категорически рекомендует своидит их потом опять-таки при помощи явного parallel merge. Воткнуть их в задачу стандарт не запрещает, но к чему это приведет одному богу известно - каждый вендор вправе интерпретировать это как попало.

Хороший тюториал по bpmn: diveintobpm.org .

skolА явное прописывание join-ов оно конечно бест-практисес, но и неявный случай как-то отрабатывать надо.... Еще раз: надо явно прописывать для параллельного исполнения, не обязательно (не надо) - для последовательного, т.е. всех вариантов exclusive branching.

skolЭт я тут движок колхозю, который схемы из TIBCO BS (xpdl2) сможет выполнять Не понял - их же iProcess, какой левый со стороны или свой пишете? Собственный их движок совершенно замшелым мне показался. Если только не пишете свой, то рисуйте схемы так, чтобы не было неоднозначности. Зачем искать приключения на собственную (_|_) К тому же если даже движок поймет вас правильно, этого мало - надо чтобы и люди (аналитики) понимали правильно.

skoliProcess не впечатлил... как впрочем и другие решения, у каждого свои +/-. А как впечатление от aqualogic?

skolbtw: интересно как организованна работа с данными процесса у других. например как вот это будет отрабатываться: process2uh2.gif здесь процесс может порождать несколько заявок Схема просто кошмарная, что автор хотел получить в результате совершенно не понятно. На выходе из первого шага процесс распараллеливается, потом распараллеливается еще раз, при этом параллельные потоки нигде не синхронизуются... ужос!

skolЭнжин свой пишу, пока проблем особых нету ;) Неужели не нашли более благодарного занятия?

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

skolА синхронизируются они как-раз по правилу implicit XORJoin на [подготовить заявку] Нет, никакой синхронизации тут быть не должно: каждый поток пройдет этот шаг и пойдет дальше, в один они не сольются. Еще раз: синхронизация параллельных потоков выполняется через явный parallel merge, добавьте его в схему.

skolСуть вобщем-то такая: есть список позиций, заявленных покупателями, нужно его обрабатывать периодически и отправлять заявки поставщикам. В заявку попадает только часть списка (фильтры определяют товары/поставщиков, которые эти товар поставляют), соответственно заявок может быть несколько, дальше они уже живут своей жизнью, по своим процессам. Здесь есть один нюанс: после [подготовить заявку] цепочка работает с заявкой (по идее заявка - данные/переменная процесса?), и в процессе может параллельно обрабатываться несколько заявок. Как такое разруливается в системах, которые вы знаете? Или такое просто не допустимо в них? Знакомая тема, я о подобных вещах рассказывал буквально два дня назад на конференции по BPM. Не пытайтесь управиться одним процессом, здесь их два: заявка покупателя и заявка поставщикам. Экземпляры процесса заявки поставщикам удовлетворяют позиции из заявки покупателя; когда все позиции удовлетворены, процесс заявки клиента автоматически переходит на следующий шаг. Это можно сказать паттерн, мы даже демку со схожим процессом раздавали на конференции.

skolесть системы, где можно нормально на схемах прописывать оркестровку? А какие проблемы? Может быть Вы имели в виду хореографию? (Оркестровка - это последовательность передачи управления в рамках одного процесса, хореография - координация разных процессов посредством обмена сообщениями.)

skolДык зряплата идет, проблема интересная, почему-бы и нет. ;) Полно чего можно делать одновременно и интересного, и имеющего коммерческие перспективы. Лучше прирастить какую-то полезную фичу к существующему уже движку, чем ваять "такой же, но свой" с очевидно нулевой востребованностью.

skol АБНет, никакой синхронизации тут быть не должно: каждый поток пройдет этот шаг и пойдет дальше, в один они не сольются. Еще раз: синхронизация параллельных потоков выполняется через явный parallel merge, добавьте его в схему.
А в стандарте то место, куда я указывал не посмотрели? А какой вообще смысл изучать версию 1.0 BPMN? Тем более что туториал у Вас по версии 1.1. Стандарт 1.1 на странице 109 говорит: "Parallel Gatways are used for synchronizing parallel flow". Цитата, которую Вы привели, говорит об альтернативных потоках, а на схеме у Вас параллельные.

skol АБЗнакомая тема, я о подобных вещах рассказывал буквально два дня назад на конференции по BPM. Не пытайтесь управиться одним процессом, здесь их два: заявка покупателя и заявка поставщикам. Экземпляры процесса заявки поставщикам удовлетворяют позиции из заявки покупателя; когда все позиции удовлетворены, процесс заявки клиента автоматически переходит на следующий шаг. Это можно сказать паттерн, мы даже демку со схожим процессом раздавали на конференции.
А материалов конференции нету где-нить? Ждите, через несколько дней будут на osp.ru и вероятно на bpms.ru.

skolНо дело не в этом. Я не пытаюсь управиться одним процессом. У нас есть процесс обработки потребностей клиентов - он не завязан на конкретную заявку, а работает с совокупностью потребностей и запускается допустим раз в неделю... в пятницу... вечером :) И заявки поставщикам никак напрямую не связанны с заявками клиентам. Это не заказы, это запросы на возможность поставки (и от клиентов и от поставщиков). Воля ваша, процессов может быть сколько угодно, но процесс, связанный с клиентской заявкой, обязан быть по-любому. Я Вам дам ссылку на упомянутую демку - на самом деле очень похоже на ваш случай. После того как посмотрите, можно будет продолжить обсуждение.

skol АБА какие проблемы? Может быть Вы имели в виду хореографию? (Оркестровка - это последовательность передачи управления в рамках одного процесса, хореография - координация разных процессов посредством обмена сообщениями.)
мм.. ну у брюса это Orchestration ;) Естественно я имел ввиду координацию разных процессов Какой все-таки подлец двуличный этот Брюс. Мне он буквально следующее говорил: "Orchestration - flow of control represented by sequence flow... Choreography - communication between pools represented by message flows..." А Вас выходит уверял в прямо противоположном :)

skol АБ Полно чего можно делать одновременно и интересного, и имеющего коммерческие перспективы. Лучше прирастить какую-то полезную фичу к существующему уже движку, чем ваять "такой же, но свой" с очевидно нулевой востребованностью.

Ну сам движек написать не так уж и сложно (не кидайте в меня сразу памидорами ;) ) а вот обвязка - в первую очередь построение и исполнение форм не устраивает совсем...
На текущий момент bpms рассматривается как интегрированная часть кис. А далее видно будет Опять-таки, посмотрите в материалах конференции был отдельный доклад о быстрой разработке пользовательского интерфейса (J2EE/AJAX) к шагам процессов в BPMS.

skolНо возвращаясь к сути вопроса: так могут или нет какие-нибудь системы нормально хореографию прописывать? Боюсь что это пока на уровне искусства. И пока что aqualogic мне нравится больше всех из тех пяти систем что я активно юзал. В том числе именно благодаря присутствию четкой хореографии. Хотя с формальным соответствием стандарту BPMN у них не очень, но меня это особо не напрягает. Лучше так, чем как у тибки - стандарту соответствует, но не работает нихрена.

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

1106 в МинфинеАБ, это правильная ссылка * * * или где-то еще будет нечто материальное? Более материальное - презентации . Подойдет?

skolАбыдна :( Хореография, помоему, наиболее нуждается в визуальном, доступном для понимания представлении. Мы же все-таки ориентируемся на то, что определять это должен аналитик (человек от бизнеса) Тут пока все не очень хорошо и с точки зрения функциональности существующих BPMS, и с точки зрения стандартов. См. на эту тему недавнюю заметку на bpms.ru . Несколько снижает остроту проблемы :) то, что аналитические возможности среднего аналитика так и так ограничены синхронным исполнением единственного процесса, и хореография слишком сложна для его понимания. Почитайте там же статью " Семь заблуждений из области исполнения бизнес-процессов ".

skolВот этапа превращения прототипа в промышленную систему хотелось бы избежать. Т.е. получить прототип, пригодный для промышленного использования. Это возможно только в специальных случаях. Например, эргономика пользовательского интерфейса не критична для сложных бизнес-процессов с низкой интенсивностью. Грубо говоря, если экземпляр процесса стартует раз в неделю, но длится по полгода и в нем под сотню шагов и сложная внутренняя логика, то не очень важно насколько хороши в нем экраны пользовательского интерфейса к шагам процесса. В большинстве же случаев для промышленной эксплуатации требуются интерфейсы более качественные, чем те, которые можно "намышковать". Если пользователь выполняет задание в рамках процесса, одновременно беседуя по телефону с клиентом, то экран должен быть "вылизан" так, чтобы вся информация, которая может понадобиться в ходе разговора, была на расстоянии максимум одного клика, а желательно - вообще упакована в один экран.