LINUX.ORG.RU
ФорумAdmin

Запускалка BMPN для скриптовой автоматизации?

 , , ,


3

3

В чём загвоздка: есть груда скриптов, связанных друг с другом событиями. Некоторые скрипты вызывают другие просто так, некоторые ждут, пока что-нибудь не появится (почтовое сообщение, например), некоторые запускаются через интервал времени X после завершения предыдущего. Есть логические ветвления, всё как в обычной BPMN-диаграмме.

Сейчас всё сделано на «кроне», т.е. выполняется по каким-то не всегда понятным законам по расписанию периодически. Как это всё взаимосвязано, какими событиями, какие могут быть ветвления - понятно только из текста скриптов после очень долгого разбора полётов с чтением текста и общением с разработчиками.

Хотелось бы всё это задвинуть на BMPN executor, разбив весь процесс на связанные событиями куски. Например, скрипт шлёт почту удалённой системе - следующий шаг будет сделан только тогда, когда удалённая система ответит почтовым сообщением (вот как-то так оно всё сделано, к сожалению). В этом случае можно и замониторить через REST API, на каком этапе процесс находится, можно легко настроить процесс, а главное - это самодокументированная вещь, поскольку документацию никто писать не любит.

Посмотрел Camunda, у него тотальная привязка скриптов к Groovy/Java, что мне не очень нравится. Посмотрел Bonita - там можно /bin/sh запускать, вроде подходит. Сервер BPM Executor’а должен быть там же, где всё это запускаемое по крону хозяйство.

Ну мало ли вдруг кто уже сталкивался с подобным… Печально конечно, что все BPM-системы написаны на Java - а значит, живут в своём собственном мире и не знают ни про какие STDIN, STDOUT, параметры командной строки и всё прочее. Между тем, нужен в идеале инструмент «поближе к системе», менее абстрактный что ли.

Заранее Гигантское СПАСИБО!

★★★★★

Если это все грамотно сделать, получится вполне себе убийца systemd, останется только подцепить к какому-ниубдь минималистичному иниту

annulen ★★★★★
()
Ответ на: комментарий от annulen

Скрипты не для того немного, они в основном во всякие списки террористов лезут, парсят xml-ки и выплёвывают другие xml-ки… В общем, это система электронного документооборота типа Alfresco+Activiti, только от людей, которые её создавали в режиме ситуационном, когда бизнес приходит и говорит: «АААА!!!! Надо вчера!» Поэтому всё на скриптах в несколько тысяч строк зачастую и по крону.

DRVTiny ★★★★★
() автор топика

Посмотрел Camunda, у него тотальная привязка скриптов к Groovy/Java

Там вроде можно внешние задачи (External tasks) писать хоть на метапроге.

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 1)
Ответ на: комментарий от DRVTiny

Alfresco не система электронного документооборота, а платформа для создания и выполнения бизнес-процессов. То есть, на основе её можно разрабатывать например системы электронного документооборота. Но потребуется сушественный объём программирования, а если обратиться к посторонним разработчикам, то это будет очень дорого, и независимо от цены в российских условиях они впаривают лохам фуфло даже если дорого. Acriviti - это движок (или запускалка) процессов (BPMN 2.0 process engine), используемая в Alfresco, Bonita и на его основе движок в Camunda . Несмотря на сходство, совместимости описаний процессов между Alfresco, Camunda и Bonita нет. Ещё можно добавить российскую платформу CUBA , использующую Activiti на её основе есть и системы документооборота.

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

Partisan ★★★★
()
Ответ на: комментарий от Partisan

облысеют, пока это изучат

Все и не надо. Камунды должно хватить за глаза. Шикарный моделер, вменяемое API, денег опять же не просят.

Nervous ★★★★★
()
Последнее исправление: Nervous (всего исправлений: 1)
Ответ на: комментарий от Partisan

А есть движок исполнения диаграмм, нативно дружащий с fork+exec+wait? Я так понимаю, с этим проблема в асинхронности движка. Но в camunda можно из скрипта отправить message для синхронизации. Первым шагом запускаем скрипт, вторым шагом ждём приход сообщения или срабатывание таймера. Я правильно мыслю или всё намного сложнее?

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от Tanger

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

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от Partisan

Ну, annulen привёл честный случай и как раз в тему: systemd по сути и есть аналог bpm-executor’а, только конфиги у него не BPMN. Но логику старта системы через BPMN описать можно

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от Tanger

Я тоже что-то про jenkins начал думать… Но там же небось сложную логику не сделаешь, только линейную?

Так-то ещё Pentaho ETL может подойти.

DRVTiny ★★★★★
() автор топика
Ответ на: комментарий от DRVTiny

Хотелось бы всё это задвинуть на BMPN executor, разбив весь процесс на связанные событиями куски. Например, скрипт шлёт почту удалённой системе - следующий шаг будет сделан только тогда, когда удалённая система ответит почтовым сообщением (вот как-то так оно всё сделано, к сожалению). В этом случае можно и замониторить через REST API, на каком этапе процесс находится, можно легко настроить процесс, а главное - это самодокументированная вещь, поскольку документацию никто писать не любит.

Посмотрел Camunda, у него тотальная привязка скриптов к Groovy/Java, что мне не очень нравится. Посмотрел Bonita - там можно /bin/sh запускать, вроде подходит. Сервер BPM Executor’а должен быть там же, где всё это запускаемое по крону хозяйство.

ещё Runa/WFE посмотри. по описанию подходит. можно запускать внешние скрипты, писать плагины на Java, на Groovy, отправлять/получать почту/документы, есть переменные типа файл, документ, пользователь, и т.п.

как я понимаю, XML формат для экспорта BPML схемы (XMI или как-то так) позволяет не привязываться к конкретной BPM среде. в одной разработать, в другую экспортировать и запустить. хотя это не точно. нужно проверять возможности каждой BPM отдельно. но оно хотя бы стандартизировано в BPML в отличие от самописных костылей на скриптах.

anonymous
()
Ответ на: комментарий от DRVTiny

Ruote

ещё посмотри Ruote:

ИМХО, главные особенности проекта - это BPM/Workflow DSL плюс возможности полноценного языка программирования (например, можно посмотреть преимущества Rake - Ruby Make). Изначально Ruote - это просто библиотека написанная на Ruby, в которой как сам процесс так и участники и их деятельность определяются на одном языке программирования (работаем в одной парадигме!). И при помощи подручных средств ruote-kit и daemon-kit (ссылки ниже) можно превратить в REST-совместимую машину бизнес-процессов.

anonymous
()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.