Советы по миграции — перемещение проектов из JBoss BRMS 5 в JBoss BPM Suite 6

Для правильной работы текущего продукта необходимо придерживаться необходимой структуры вашего git-репозитория. Чтобы проект был доступен в замечательных графических интерфейсах продуктов, необходимо создать пустой проект в пользовательском интерфейсе с файлами-заполнителями для процессов, правил и всего, что вам нужно. Тогда  нужно просто запустить  git-клон этого проекта в вашей любимой IDE, чтобы начать миграцию вашего проекта.

После того, как вы клонировали проект, вы можете добавить свои активы в проект в правильных местах на основе файлов-заполнителей. Например, я создал пустой  файл customer.bpmn2  и добавил свой  customereval.bpmn2 файл прямо рядом с ним. Затем я удалил старый файл-заполнитель и поместил все это в хранилище. Пользовательский интерфейс продукта автоматически фиксирует изменения, и мой актив процесса появился для использования в конструкторе.

Файлы правил импортируются таким же образом без происшествий, за исключением того, что вам необходимо убедиться, что имя вашего пакета соответствует структуре вашего нового проекта. Продукт имеет пользовательский интерфейс, предназначенный для более ориентированного на бизнес пользователя, поэтому можно ожидать, что старое наименование пакета демонстрационной версии оценки клиента org.jbpm.customer.evaluation  будет более упрощенным. Нашим оказалось простое имя пакета customer.evaluation,  поэтому мы исправили это в нашем файле правил, и все было хорошо.

Модель для нашего проекта состоит из двух классов Java, или POJO,  Request  и  Person . Их необходимо было импортировать в правильное место, чтобы их мог идентифицировать компонент моделирования, и они не будут отображаться до тех пор, пока имя пакета не будет исправлено, как описано выше.

Существует фундаментальное изменение в том, как вы получаете доступ к ресурсам ваших проектов, поэтому, как только у вас появятся правила, процессы и модель ваших проектов в продукте, это будет доступно в основном через репозиторий maven, построенный в виде простого  jar- файла. Ниже мы рассмотрим эти детали в разделе  Maven .

Это означает, что вы можете разделить свой проект на проект кода, который использует ваши правила, события и процессы и сами фактические артефакты. Они будут содержаться в проекте, который развертывает  jar,  который вы используете в коде своего приложения. Ваши модульные тесты будут находиться в вашем проекте кода приложения и использовать сгенерированные  зависимости jar .

API

Основной API продуктов был полностью переработан. Вы должны перенести все, что вы сделали, чтобы взаимодействовать с ядром правил, событий и процессов.

В итоге.

На данный момент вы можете использовать предоставленную обратную совместимость, найденную в  Knowledge-api.jar,  предоставленную только для проектов, которые хотят покататься на старых волнах. В настоящее время его можно найти в  deployable-generic.zip,  но это может измениться, когда продукт приближается к состоянию общей доступности (GA).

Что касается другой половины кодовой базы вашего предприятия, то в модульных тестах использовался  jbpm-test.jar нужно будет рефакторинг. Этот jar-файл не обеспечивает обратной совместимости, и нам пришлось переписать наши существующие модульные тесты. Хорошей новостью является то, что код упрощен, что делает ваши модульные тесты более понятными и понятными.

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

RestAPI также изменился. Потребуется некоторая работа по перестройке пользовательских пользовательских интерфейсов, которые вы, возможно, создали. RestAPI предоставляет вам доступ к следующим областям:

• работы
• Хранилища
• Организационные единицы
• проектов
• Экземпляры процесса, с или без переменных (начало, переменные, детали, отмена, сигнал)
• Рабочие элементы (завершить, отменить)
• История для просмотра экземпляра процесса завершена
• Комплексный интерфейс задач

Вы можете найти документацию по этому  вопросу на портале для клиентов .

JCR для GIT инструментов

Существует инструмент сообщества для переноса существующих репозиториев JCR в формат репозитория GIT. В это время проверять было нечего, но это происходит в процессе продуктизации.

Будет ли это молоток, который заставит все ваши миграции выглядеть как гвоздь, ожидающий удара?

Следите за новостями, так как они еще не включены в ранние бета-версии.

Maven детали

Продукты JBoss BRMS & BPM Suite поддерживают репозиторий maven, который вы можете добавить в свой проект для доступа к правилам, событиям и зависимостям проекта процесса. Просто добавьте следующее в ваш pom-файл проекта, и вы будете готовы найти зависимости:

   guvnor-m2-repo
   Guvnor M2 Repo
   http://localhost:8080/business-central/maven2/

В качестве примера, предположим, что мы правильно определили наш проект оценки клиента с помощью GAV (GroupID, ArtifactId, Version), затем мы можем добавить зависимость для jar версии 1.0 следующим образом:

      customer
      evaluation
      1.0

Наконец, самый важный совет здесь — никогда не клонировать свой репозиторий из файловой системы, а всегда использовать работающий продукт git URI. Ссылаясь на наш работающий пример демонстрации оценки клиента, вы могли бы клонировать его вне продукта с помощью CLI или вашей любимой IDE, открыв проект в разделе:

# Never use the filesystem directly as it is not monitored by the product,
# so this is a bad practice: 
#
#    git clone file://{path-to-repo}/.niogit/customer.git
#
# This is the best practice, for example using git from a shell:
#
$ git clone git://localhost/customer

Cloning into 'customer'...
remote: Counting objects: 562, done
remote: Finding sources: 100% (562/562)
remote: Getting sizes: 100% (435/435)
remote: Compressing objects:  89% (388/432)
remote: Total 562 (delta 24), reused 72 (delta 21)
Receiving objects: 100% (562/562), 59.21 KiB, done.
Resolving deltas: 100% (198/198), done.

Обновления задач

Продукт JBoss BRMS 5 предоставил сервер задач, который был соединен с основным ядром с помощью, чаще всего, системы обмена сообщениями, предоставляемой HornetQ.

Новый продукт JBoss BPM Suite будет обеспечивать только поддержку сервера задач, работающего локально, поэтому больше не нужно настраивать обмен сообщениями. Чтобы помочь вам сократить разрыв до тех пор, пока вы не сможете перенести это в свою текущую архитектуру, есть вспомогательный или служебный метод  LocalHTWorkItemHandler.  Его можно найти в исходном коде (отдельная загрузка), если вы хотите продолжить исследование в
jbpm-human-task / jbpm-human-task-workitems / src / main / java / org / jbpm / services / task / wih / util /LocalHTWorkItemHandlerUtil.java

Кроме того, API-интерфейс TaskService является частью общедоступного API, поэтому при переносе необходимо учитывать только несколько вещей:

• изменения пакета приведут к небольшому рефакторингу вашего импорта
• некоторые изменения API вызовут рефакторинг методов

Демо оценка клиента

Поскольку большинство заказчиков создали пользовательские интерфейсы и активно взаимодействуют с компонентом неавтоматизированных задач, ожидайте, что вам придется потрудиться, чтобы перенести эту область вашей архитектуры, если вы используете задачи в своих процессах.

Миграция на практике

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

Здесь мы хотели бы представить результаты и указать на результаты проекта  (в процессе) демонстрации оценки перенесенного клиента .

Модульные тесты

Мы начали с модульных тестов и обновили   файл pom.xml, указав на внутренний производственный репозиторий maven, и включили в него только зависимости для  знаний-api,  а также  jar-тест jbpm  . Этот фрагмент кода показывает только общие записи для необходимых jar-файлов, исключая точную версию, заданную в качестве свойства для текущего выпуска. Вы также заметите, что мы пропускаем запись репозитория, которая будет установлена ​​в репозиторий maven, в котором хранятся зависимости продукта.

   org.jbpm
   jbpm-test
   ${bpm-suite-version}
   test

   org.drools
   knowledge-api
   ${bpm-suite-version}
   compile

Результаты миграционного юнит-теста.

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

Это включает в себя запись, позволяющую в конечном итоге получить  jar- компиляцию размещенных в продукте артефактов, см. Встроенные комментарии в   файле pom.xml .

Первоначальная настройка использовалась для включения базы  знаний и  StatefulKnowledgeSession.

Это было сведено к настройке стратегии сеанса и  RuntimeEngine.

# The createRuntimeManager() method and getRuntimeEngine() method are 
# both part of the provided testing harness found in JbpmJUnitBaseTestCase
# class that you can extend all unit tests off of.
#
createRuntimeManager(Strategy.SINGLETON, resources);
RuntimeEngine runtime = getRuntimeEngine(ProcessInstanceIdContext.get());

Там, где старые модульные тесты должны были манипулировать сессиями, теперь у нас есть упрощенный пример для каждого модульного теста.

@Test
public void underagedCustomerEvaluationTest() {
	// setup of a Person and Request.
	Person underagedEval = getUnderagedCustomer();
	Request richEval = getRichCustomer();

	// Map to be passed to the startProcess.
	Map params = new HashMap();
	params.put("person", underagedEval);
	params.put("request", richEval);

	// Fire it up!
	System.out.println("=========================================");
	System.out.println("= Starting Process Underaged Test Case. =");
	System.out.println("=========================================");

	KieSession ksession = runtime.getKieSession();
	ksession.insert(underagedEval);
	ProcessInstance pi = ksession.startProcess("org.jbpm.customer-evaluation", params);
	ksession.fireAllRules();

	// Finished.
	assertProcessInstanceCompleted(pi.getId(), ksession);
	assertNodeTriggered(pi.getId(), "Underaged");
	ksession.dispose();

	System.out.println("======================================");
	System.out.println("= Ended Process Underaged Test Case. =");
	System.out.println("======================================");
}

Вы найдете полностью перенесенный модульный тест в проекте  src / test / java / CustomerEvaluationTest.java  и можете запустить его как тест JUnit.

От IDE к UI

Последним шагом будет импорт существующего правила, двух классов Java, составляющих нашу модель предметной области, и процесса BPMN2.

Дизайнер с импортированным процессом.

Чтобы достичь этого, мы запустили наш пакет JBoss BPM Suite и создали новый репозиторий и проект. Затем мы создали пустые файлы-заполнители для процесса и правила.

Вернувшись в IDE, мы клонировали проект с помощью  git clone git: // localhost / customer  и приступили к поиску именно тех файлов, которые мы вставили. Затем мы удалили их и добавили наши существующие файлы правил и процессов. После их возвращения в проект они появились в проводнике проекта пользовательского интерфейса. Они нуждались только в корректировке упаковки, так как она изменилась, когда мы создавали наш проект, от длинного имени пакета до просто  customer.evaluation .

Импортирование модели было такой же историей, сначала создав пустую модель через модельера форм. 
компонент, а затем заменить файл с нашими двумя объектами Java. Как только пакеты были настроены в соответствии с определением проекта, они появились в пользовательском интерфейсе.

Form Modeller с импортированной моделью.

Модельер форм создает объекты с аннотациями, а наши объекты в настоящее время их не имеют. Это вызывает некоторые проблемы, когда мы пытаемся запустить процесс (который строит и развертывает). JBoss BPM Suite пытается сгенерировать форму пользовательской задачи для отправки начальных переменных процесса, но, поскольку они являются объектами, а не строковыми полями, которые нам предоставляются, это не удается.

Выводы

Это первые годы появления продуктов JBoss BRMS & BPM Suite, поэтому ранний взгляд на возможности миграции — это только ранний взгляд. Это не полное руководство по миграции, а краткое изложение областей, которые будут затронуты, и того, что вы можете ожидать на основе небольшого примера приложения.

Проблемы, связанные с аннотациями в нашей модели, связанные с импортом модели, путями упаковки, похоже, заслуживают дальнейшего изучения. Об этом следует позаботиться, как только будет предоставлена ​​окончательная документация по продукту.

Обратите внимание, что  проект / демонстрация клиента-оценки предназначен для импорта в вашу JBoss Developer Studio и взаимодействия с работающим проектом в BPM Suite. В настоящее время эта работа еще не завершена, поэтому следите за обновлениями прогресса по мере приближения окончательного выпуска продукта.

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