gust777Garya, могли бы посоветовать литературу, которая могла бы помочь при разработки приложения в BPMsuite кроме непосредственно мануалов этих систем?Литература на русском языке мне, к сожалению, не известна. Информация есть в интернете (например, на сайтах www.bpms.ru и www.mainthing.ru). Можно также пройти платные курсы на www.bpmntraining.ru
gust777А то я многие термины не понимаю, распаралеливание и прочее.Спрашивайте, постараюсь ответить. :)
Самое главное и первое в этой терминологии, что нужно понимать - это отличие "шаблона БП" от "экземпляра БП". Шаблон БП - это нарисованная схема (некоторая ее конкретная редакция). Шаблон может иметь название, например, "обработка заказов клиентов". А "экземпляр БП" - это уже конкретный заказ, который обрабатывается по данной схеме. По одной схеме может одновременно обрабатываться множество разных заказов, но каждый из них является отдельным экземпляром БП.
Экземпляр процесса
создается при каждом старте этого процесса. Стартовать его можно по разному - по событию автоматически или вручную сотрудником, которому предоставлено право его стартовать через WEB-портал. Если процесс стартует вручную, то при старте процесса открывается заранее настроенная WEB-форма, которую инициатор заполняет некими начальными параметрами поступившего заказа.
В процессе обработки заказа управление передается от одного шага процесса к другому по линиям потока управления. Наиболее удобно представить, что по схеме (шаблону) БП двигается "фишка" или "токен". Каждый процесс стартует образованием в точке "Start"
одного нового токена, который начинает двигаться по схеме процесса. Далее он может размножиться на несколько токенов (при распараллеливании), пойти по одним веткам или другим в зависимости от некоторых условий, пройти по нескольку раз через некоторые участки схемы (если в схеме присутствуют циклы). Но каждый токен, даже если их несколько движется одновременно, привязан к конкретному шаблону БП, к версии этого шаблона и к экземпляру процесса. Логикой БП может быть, например, определено "пристреливание" всех токенов одного экземпляра БП при достижении одним из них некоторых критических точек.
По поводу распараллеливания... Представьте, что вы имеете некий процесс согласования договора, в котором бумажный документ "проект договора"
последовательно проходит через несколько подразделений с прикрепленным к нему листом согласования. Его согласовывает служба безопасности, юристы, финансисты(экономисты), бухгалтерия. Пока документ пройдет все подразделения и ляжет на подпись гендиру, проходит слишком много времени. Такой процесс можно "распараллелить". Это стандартный прием для систем автоматизации документооборота и BPMS. Если согласование осуществляется в электронной форме, а не в бумажной, его проще реализовать. Проект договора поступает
одновременно во все подразделения (а не последовательно в одно за другим). Если никто не внес в документ никаких правок и все его согласовали, то на подпись гендиру он поступает сразу после того, как в одной точке сойдутся согласования всех этих подразделений. Если правки были, то логикой процесса может быть определено, что делать дальше. Может, например, сам автор правки определять, требуется ли ознакомить с его правкой других участников и кого именно. Либо в точке схождения потоков из разных подразделений некое ответственное лицо производит объединение всех правок, после чего скорректированный документ отправляется на повторное согласование всеми подразделениями, но уже без обязательного перечитывания всего текста, поскольку в его тексте правки и их авторы выделены (например, цветом). Когда работа над документом производится параллельно несколькими согласующими подразделениями, общий срок согласования договора может сократиться в несколько раз. Такой прием и называют "распараллеливанием" потока управления, когда одно управляющее воздействие, "токен" (маркер экземпляра бизнес-процесса) размножается на несколько "токенов", и эти несколько токенов движутся одновременно по разным веткам схемы БП. Впоследствии они опять могут слиться в один поток, или дойти до завершающей фазы каждый своим путем.
Обычное распараллеливание, приводящее к превращению одного токена в несколько токенов внутри одного экземпляра процесса производится развилкой (gate) вида "И", либо развилкой "включающее или". Такие развилки и предназначены для размножения токенов (распараллеливания), а также для соединения нескольких токенов одного экземпляра процесса в один токен. Для направления единственного токена по одному из нескольких путей используется развилка "исключающее или".
Другой метод размножения токенов - использование подпроцесса, распараллеливаемого по сущностям. В параметрах такого подпроцесса указывается коллекция сущностей, по которым необходимо распараллелить процесс, и для каждой сущности создается собственный экземпляр подпроцесса. Детали описаны в нижней части
этой страницы .
Если подпроцесс "встроен" в процесс, то токены, движущиеся внутри подпроцесса, промаркированы ID экземпляра родительского процесса. Если в родительском процессе одним из токенов будет достигнут конец процесса, требующий "пристреливания" остальных токенов этого же экземпляра, то токены подпроцесса будут пристрелены тоже. Если подпроцесс является "автономным", то при входе в него создаются идентификаторы нового экземпляра, и токены подпроцесса считаются не принадлежащими экземпляру родительского процесса. В этом случае они могут продолжать жить своей жизнью после того как экземпляр родительского процесса уже завершился.
