Встроенные бины

Этот раздел перенесён из документации Camunda 7 и в дальнейшем будет доработан с учётом особенностей OpenBPM Engine

  • ProcessEngine, как и сервисы движка, доступны для внедрения через @Inject ProcessEngine, @Inject RepositoryService и так далее.

  • Конкретный именованный ProcessEngine и его сервисы можно внедрить, добавив квалификатор @ProcessEngineName('someEngine').

  • Текущий экземпляр процесса и задача могут быть внедрены через @Inject ProcessInstance или @Inject Task.

  • Текущий business key можно внедрить через @Inject @BusinessKey String businessKey.

  • Идентификатор текущего экземпляра процесса можно внедрить через @Inject @ProcessInstanceId String pid.

Переменные процесса также доступны для внедрения. OpenBPM Engine CDI поддерживает:

  • типобезопасное внедрение бинов @BusinessProcessScoped с помощью @Inject [additional qualifiers] Type fieldName;

  • нетипобезопасное внедрение других переменных процесса с использованием квалификатора @ProcessVariable(name?):

    ----
    @Inject
    @ProcessVariable
    private Object accountNumber;
    @Inject
    @ProcessVariable("accountNumber")
    private Object account;
    ----

Для обращения к переменным процесса через EL доступны схожие варианты:

  • к бинам @Named @BusinessProcessScoped можно обращаться напрямую;

  • к другим переменным процесса можно обращаться через бин ProcessVariables, используя #{processVariables['accountNumber']}.

Внедрение процессного движка на основе контекстных данных

Хотя к конкретному процессному движку можно обращаться, добавив квалификатор @ProcessEngineName('name') в точке внедрения, это требует заранее знать, какой именно движок будет использоваться. Более гибкий подход состоит в том, чтобы разрешать процессный движок во время выполнения на основе контекстной информации, например данных вошедшего пользователя. В этом случае @Inject можно использовать без аннотации @ProcessEngineName.

Чтобы реализовать разрешение на основе контекстных данных, необходимо расширить producer-бин io.openbpm.bpm.engine.cdi.impl.ProcessEngineServicesProducer. Следующий код реализует контекстное разрешение движка по текущему аутентифицированному пользователю. Какие именно контекстные данные использовать и как к ним обращаться, полностью зависит от вашего приложения.

@Specializes
public class UserAwareEngineServicesProvider extends ProcessEngineServicesProducer {

  // User can be any object containing user information from which the tenant can be determined
  @Inject
  private UserInfo user;

  @Specializes @Produces @RequestScoped
  public ProcessEngine processEngine() {

    // okay, maybe this should involve some more logic ;-)
    String engineForUser = user.getTenant();

    ProcessEngine processEngine =  BpmPlatform.getProcessEngineService().getProcessEngine(engineForUser);
    if(processEngine != null) {
      return processEngine;

    } else {
      return ProcessEngines.getProcessEngine(engineForUser, false);

    }
  }

  @Specializes @Produces @RequestScoped
  public RuntimeService runtimeService() {
    return processEngine().getRuntimeService();
  }

  @Specializes @Produces @RequestScoped
  public TaskService taskService() {
    return processEngine().getTaskService();
  }

  ...
}

Приведённый выше код делает выбор процессного движка на основе tenant текущего пользователя полностью прозрачным. Для каждого запроса извлекается текущий аутентифицированный пользователь и определяется корректный процессный движок. Обратите внимание, что класс UserInfo здесь представляет любой контекстный объект, идентифицирующий текущий tenant. Например, это может быть JAAS principal. Полученный движок можно использовать следующим образом:

@Inject
private RuntimeService runtimeService;

Лицензия и атрибуция

Эта документация была создана на базе материала "Camunda 7 Docs" от Camunda, находится под лицензией Creative Commons Attribution-ShareAlike 3.0 Unported License .

Оригинал документации: https://docs.camunda.org