Дамы и господа камунданты,

Из одной системы, которую я не могу менять, приходят данные для перенной процесса типа xml.

Иногда приходит нормальный XML:

<FJoeBiden>
  <LetsGoBrandon></LetsGoBrandon>
  <LetsGoBrandon></LetsGoBrandon>
</FJoeBiden>

а иногда безголовый:

<LetsGoBrandon></LetsGoBrandon>
<LetsGoBrandon></LetsGoBrandon>

Во втором случае SPIN выбрасывает исключение:

[Fatal Error] :1:33: The markup in the document following the root element must be well-formed.

org.xml.sax.SAXParseException; lineNumber: 1; columnNumber: 33; The markup 
in the document following the root element must be well-formed.

    at com.sun.org.apache.xerces.internal.parsers.DOMParser.parse(DOMParser.java:262)

Заказчик требует, чтобы Камунда могла работать с безголовым XML.

На StackOverflow ( https://stackoverflow.com/q/69679736/399457 ) сказали, что в случае с безголовым XML надо обернуть его соотв. тегом. Как я полагаю, вот так: https://github.com/dptij/camunda-spin/pull/1/files . В худшем случае надо будет собрать собственную версию Camunda SPIN и использовать ее в pom.xml всех движков.

Есть еще вариант расширить Camunda SPIN штатными средствами, как описано на

https://docs.camunda.org/manual/7.16/reference/spin/extending-spin/

Есть какие-то более простые способы сделать так, чтобы Камунда не ругалась на невалидный XML (<LetsGoBrandon></LetsGoBrandon><LetsGoBrandon></LetsGoBrandon>) в процессуальных переменных типа xml?

Самый простой вариант:
Заверните любой xml внутрь служебного элемента
Ну типа "<extraouter>"+inboundxml+"</extraouter>"
А потом разбирайтесь как оно там внутри устроено

На худой конец XSLT, чтобы привести все к одному виду

Спасибо.

Спасибо.

@dpisarenko а чем закончилась история с multi engine на разных инстансах? Что в camunda ответили?

Сказали, что это не баг, а feature request и чинить не будут.

Проблему решили

а) добавлением события в BPMN ("предметный процесс завершен") и
б) изменением способа логирования событий.

По пункту б): Есть обработчик исторических событий (не тот, который Spring Eventing) и в нем можно отследить, что токен добрался до события "предметный процесс завершен".

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

Вроде все работает.

А чем обычный send message не устроил? Или listener? Зачем через историю это делать?

Через listener на start и endevent пушили бы нужные данные?

В моменты 1 и 2 надо отправлять в стороннюю систему идентификатор вызванного подпроцесса. При этом подпроцесс разрабатывается не нами и о сторонней системе ничего не знает.

Если повесить listener на любой объект ДО вызова подпроцесса, то нужной информации (идентификатор вызванного подпроцесса) в нем не будет, т. к. на этот момент подпроцесс еще не будет запущен.

Ну листенер можно повесить в момент деплоя процесса, при парсинге  bpmn файла 😉

Ну это почти как вешать листенер на стрелку :)

Почему?

Слишком неочевидно и нестандартно. Во всяком случае для организации заказчика.

Ладно, это конечно же дело заказчика, но как по мне, не страннее всех прочих решений)

А что мешает в подпроцесс добавить отправку?

Не поможет-процесс еще не появился