Маршрутизация событий в процессах

Выбор корректного BPMN события

Стартовые события. Для запуска нового процесса может быть использовано несколько стартовых BPMN. Рассмотрим случаи использования различных стартовых событий:

1. None Event – в процессе одно стартовое событие или условие для запуска экземпляра процесса не указано.
2. Message Event – используется в случае, когда необходимо различать несколько стартовых событий.
3. Timer Event – автоматический запуск процесса контролируется таймером.
4. Signal Event – необходимо запустить сразу несколько инстансов (редко используется).
5. Conditional Event – запускает событие при выполнении определенного условия.

Рассмотрим следующий процесс в качестве примера:

1. None start event показывает типичную отправную точку процесса. Еще раз отмечу, что только одно подобное стартовое событие может существовать в процессе.
2. Это message start event начнет процесс при получении определенного сообщения извне.
3. В процессе может быть несколько message start event. В данном примере оба message start event оказались исключительными случаями, в подобных ситуациях лучше использовать вместо none start события message start event.

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

1. Message Event - используется, когда направляем сообщение конкретному и уникальному экземпляру процесса.
2. Receive Task – очень похож на message event, но используется для того, чтобы дополнительно использовать boundary events.
3. Timer Event – используется, когда хотим заставить инстанс процесса ожидать некоторое время.
4. Signal Event – используется, когда направляем сигнал всем инстансам процесса, ожидающим его.
5. Conditional Event – как только определенное условие выполнено, процесс продолжается.

Рассмотрим пример:

1. Процесс не сдвинется с этой точки до тех пор пока не будет получено сообщение.
2. До тех пор пока токен находится на активности “Order fulfillment”, процесс может принять сообщение “Order canceled”.

Использование методов API Camunda для маршрутизации событий в процессах

Запуск процесса по ключу. Если в процессе одно стартовое событие, то достаточно сослаться на определение этого процесса по идентификатору в BPMN XML файле. Это наиболее часто встречающийся случай.

processEngine.getRuntimeService().startProcessInstanceByKey("invoice"); 

@Inject
private ProcessEngine processEngine; 

public ProcessEngine getEngineProgramatically() {
   return BpmPlatform.getDefaultProcessEngine(); 
}

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

    
    processEngine.getRuntimeService()
      .createMessageCorrelation("message_invoiceReceived") 
      .setVariable("invoiceId", "123456") 
      .correlate();

1. message_invoiceReceived – имя сообщения, определенное в BPMN-модели процесса
2. ("invoiceId", "123456") – то, что передается инстансу вместе с сообщением

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

Запуск определенной версии процесса по идентификатору. По умолчанию Process Engine всегда стартует самую новую версию процесса. Запуск определенной версии процесса возможен по ссылке на ID (primary key) этой версии процесса из process engine database.

    
    ProcessDefinition processDefinition = processEngine().getRepositoryService()
        .createProcessDefinitionQuery()
        .processDefinitionKey("invoice")
        .processDefinitionVersion(17)
        .singleResult();
    processEngine().getRuntimeService()
        .startProcessInstanceById(processDefinition.getId());

Корреляция сообщений к уже запущенным инстансам процессов.

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

    
runtimeService
  .createMessageCorrelation("myMessage") 
  .processInstanceBusinessKey(myMessage.getOrderId().toString()) 
  .processInstanceVariableEquals("customerId", myMessage.getCustomerId()) 
  .correlate();

1. myMessage – имя сообщения, которое ждет процесс
2. processInstanceBusinessKey(myMessage.getOrderId().toString) - если процесс содержит orderId сообщения в качестве своего бизнес ключа
3. и если переменная процесса “customerId” также соответствует ожиданиям.

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

Маршрутизация сигналов. Корреляция с конкретным экземпляром процесса при использовании сигнала - невозможна. Механизм сигналов предназначен для информирования сразу нескольких экземпляром процесса, которые подписаны на конкретное событие сигнала:

    runtimeService
  	.createSignalEvent("mySignal") 
  	.setVariables(variables) // pass variables (optional)
  	.send();