Главное не результат, главное процесс

BPM-блог Анатолия Белайчука

Стартовый сигнал BPMN

Небольшое дополнение к предыдущей заметке “Применение для сигнала BPMN“.

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

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

Во-первых, сигнал позволяет инициировать не один, а несколько процессов.

Во-вторых, у схемы с сигналом есть концептуальное преимущество:

  • Пусть определенный сигнал, инициированный процессом А, вызывает старт процесса Б.
  • Теперь вспомним, что BPM - это не просто управление бизнес-процессами, а управление процессами, меняющимися во времени, и предположим, что мы решили назначить обработчиком сигнала процесс В вместо процесса Б.
  • В схеме с сообщением получатель указан в процессе А, т.е. чтобы заменить обработчик, нам придется изменить схему А. При этом возникнет проблема: что делать с уже запущенными экземплярами А?
  • В схеме с сигналами мы просто инсталлируем процесс В и деинсталлируем Б. Менять схему А не требуется, проблем с запущенными экземплярами А не возникает.

Таким образом, сигнал позволяет реализовать позднее связывание: обработчик можно назначать и переназначать не на этапе разработки, а на этапе исполнения.

13.09.10 | Статьи | , , ,    

Комментарии (3)

  1. David French 13.09.10 23:05

    It allows the ultimate “late binding” of not having to design the world process … only the bit you are in control of at the moment. When you come to an event that you know will be useful to another bit of the enterprise … Signal … then when a use is found in another bit of process design you do not have to redo the process design work again. Of course, you will need a way to hunt down these useful signals and some standardisation of how they will look in your enterprise.
    Yes, I know that the end-end process is sacrosanct but the real world is better with some compartmentalising … a bit like the IT world of programming.

  2. Anatoly Belychook 14.09.10 14:31

    Dave

    Regarding end-to-end processes: it’d be too simple if they could be implemented by a single-threaded diagram. It’s an extremly vulgar view.

    I’m going to get back to this topic because for me it’s the coolest thing in BPM and BPMN.

    Anatoly

  3. Scott 04.10.10 22:25

    Interesting writeup. This is, incidentally, how one BPM product always treated events (since 2004/5) - e.g. late binding of them to process starts and Intermediate messages across any number of instances. Its a very useful abstraction.

Комментирование закрыто

Copyright © 2008-2024 Анатолий Белайчук. Спасибо Wordpress и Yahoo.  Контент  Комментарии