Встроенные бины
|
Этот раздел перенесён из документации 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