🥇Интеграция на BPM стил

Hi, Хабр!

Нашата компания е специализирана в разработването на софтуерни решения от клас ERP, в които лъвският дял се заема от транзакционни системи с огромно количество бизнес логика и работен процес в стил EDMS. Съвременните версии на нашите продукти са базирани на JavaEE технологии, но също така активно експериментираме с микроуслуги. Една от най-проблемните области на подобни решения е интегрирането на различни подсистеми, свързани със съседни домейни. Интеграционните задачи винаги са ни създавали огромно главоболие, независимо от архитектурните стилове, технологични стекове и рамки, които използваме, но напоследък има напредък в решаването на подобни проблеми.

В предоставената на вашето внимание статия ще говоря за опита и архитектурните проучвания на НПО Криста в определения район. Ще разгледаме и пример за просто решение на проблем с интеграцията от гледна точка на разработчик на приложения и ще разберем какво се крие зад тази простота.

Опровержение

Описаните в статията архитектурни и технически решения са предложени от мен на база личен опит в контекста на конкретни задачи. Тези решения не претендират за универсалност и може да не са оптимални при други условия на употреба.

Какво общо има BPM с това?

За да отговорим на този въпрос, трябва да се задълбочим малко в спецификата на приложните проблеми на нашите решения. Основната част от бизнес логиката в нашата типична транзакционна система е въвеждане на данни в базата данни чрез потребителски интерфейси, ръчна и автоматична проверка на тези данни, преминаването им през някакъв работен поток, публикуването им в друга система / аналитична база данни / архив, генериране на отчети. По този начин ключовата функция на системата за клиентите е автоматизирането на техните вътрешни бизнес процеси.

За удобство ние използваме термина "документ" в комуникацията като някаква абстракция от набор от данни, обединен от общ ключ, към който може да бъде "прикрепен" определен работен процес.
Но какво да кажем за логиката на интеграцията? В края на краищата задачата за интеграция се генерира от архитектурата на системата, която е „нарязана“ на части НЕ по желание на клиента, а под влияние на напълно различни фактори:

под влиянието на закона на Конуей;
в резултат на повторно използване на подсистеми, разработени преди това за други продукти;
по решение на архитекта, въз основа на нефункционални изисквания.

Има голямо изкушение да се отдели интеграционната логика от бизнес логиката на основния работен процес, за да не се замърсява бизнес логиката с интеграционни артефакти и да се спести на разработчика на приложение необходимостта да се рови в особеностите на архитектурния пейзаж на системата. Този подход има редица предимства, но практиката показва неговата неефективност:

решаването на проблеми с интеграцията обикновено се свежда до най-простите опции под формата на синхронни повиквания поради ограничените точки на разширение в изпълнението на основния работен процес (повече за недостатъците на синхронната интеграция по-долу);
интеграционните артефакти все още проникват в основната бизнес логика, когато се изисква обратна връзка от друга подсистема;
разработчикът на приложението пренебрегва интеграцията и може лесно да я прекъсне, като промени работния процес;
системата престава да бъде едно цяло от гледна точка на потребителя, "шевовете" между подсистемите стават забележими, появяват се излишни потребителски операции, които инициират прехвърлянето на данни от една подсистема към друга.

Друг подход е да се разглеждат интеграционните взаимодействия като неразделна част от основната бизнес логика и работен процес. За да предпазите изискванията за умения на разработчиците на приложения от скок, създаването на нови интеграционни взаимодействия трябва да се извършва лесно и естествено, с минимални възможности за избор на решение. Това е по-трудно, отколкото изглежда: инструментът трябва да е достатъчно мощен, за да предостави на потребителя необходимото разнообразие от възможности за неговото използване и в същото време да не позволи да бъде прострелян в крака. Има много въпроси, на които един инженер трябва да отговори в контекста на задачите за интеграция, но за които разработчикът на приложение не трябва да мисли в ежедневната си работа: граници на транзакциите, последователност, атомарност, сигурност, мащабиране, натоварване и разпределение на ресурсите, маршрутизиране, маршалинг, разпространение и превключване на контексти и т.н. Необходимо е да се предложат на разработчиците на приложения доста прости шаблони за решения, в които отговорите на всички подобни въпроси вече са скрити. Тези модели трябва да са достатъчно сигурни: бизнес логиката се променя много често, което увеличава риска от въвеждане на грешки, цената на грешките трябва да остане на сравнително ниско ниво.

Но все пак, какво общо има BPM с това? Има много опции за внедряване на работен процес ...
Наистина, друга реализация на бизнес процеси е много популярна в нашите решения - чрез декларативна настройка на диаграмата на прехода на състоянието и свързване на манипулатори с бизнес логика към преходите. В същото време състоянието, което определя текущата позиция на "документа" в бизнес процеса, е атрибут на самия "документ".

Ето как изглежда процесът в началото на проекта

Популярността на такова внедряване се дължи на относителната простота и скорост на създаване на линейни бизнес процеси. Въпреки това, тъй като софтуерните системи стават по-сложни, автоматизираната част от бизнес процеса нараства и става по-сложна. Има нужда от декомпозиция, повторно използване на части от процеси, както и разклоняващи процеси, така че всеки клон да се изпълнява паралелно. При такива условия инструментът става неудобен и диаграмата на прехода на състоянието губи своето информационно съдържание (интеграционните взаимодействия изобщо не се отразяват в диаграмата).

Ето как изглежда процесът след няколко повторения на изясняване на изискванията

Изходът от тази ситуация беше интегрирането на двигателя jBPM в някои продукти с най-сложни бизнес процеси. В краткосрочен план това решение имаше известен успех: стана възможно да се внедряват сложни бизнес процеси, като същевременно се поддържа доста информативна и актуална диаграма в нотацията BPMN2.

Малка част от сложен бизнес процес

В дългосрочен план решението не оправда очакванията: високата трудоемкост на създаването на бизнес процеси чрез визуални инструменти не позволи постигането на приемливи показатели за производителност, а самият инструмент стана един от най-нехаресваните сред разработчиците. Имаше и оплаквания относно вътрешната структура на двигателя, което доведе до появата на много „кръпки“ и „патерици“.

Основният положителен аспект от използването на jBPM беше осъзнаването на ползите и вредите от наличието на собствено постоянно състояние за екземпляр на бизнес процес. Видяхме също възможността за използване на процесен подход за прилагане на сложни интеграционни протоколи между различни приложения, използващи асинхронни взаимодействия чрез сигнали и съобщения. Наличието на персистиращо състояние играе решаваща роля в това.

Въз основа на горното можем да заключим: Процесният подход в стила на BPM ни позволява да решаваме широк спектър от задачи за автоматизиране на все по-сложни бизнес процеси, хармонично вписване на интеграционни дейности в тези процеси и запазване на способността за визуално показване на внедрения процес в подходяща нотация.

Недостатъци на синхронните повиквания като интеграционен модел

Синхронната интеграция се отнася до най-простото блокиращо повикване. Една подсистема действа като страна на сървъра и излага API с желания метод. Друга подсистема действа като страна на клиента и в точния момент прави повикване с очакване на резултат. В зависимост от архитектурата на системата, клиентската и сървърната страна могат да бъдат хоствани или в едно и също приложение и процес, или в различни. Във втория случай трябва да приложите някаква реализация на RPC и да осигурите маршалинг на параметрите и резултата от повикването.

Такъв интеграционен модел има доста голям набор от недостатъци, но се използва много широко на практика поради своята простота. Скоростта на внедряване пленява и ви кара да го прилагате отново и отново в условията на "изгарящи" срокове, записвайки решението в технически дълг. Но също така се случва неопитни разработчици да го използват несъзнателно, просто не осъзнавайки негативните последици.

В допълнение към най-очевидното увеличаване на свързаността на подсистемите, има по-малко очевидни проблеми с „разпръскването“ и „разтягането“ на транзакциите. Всъщност, ако бизнес логиката прави някакви промени, тогава транзакциите са незаменими, а транзакциите от своя страна заключват определени ресурси на приложението, засегнати от тези промени. Тоест, докато една подсистема не изчака отговор от друга, тя няма да може да завърши транзакцията и да освободи ключалки. Това значително увеличава риска от различни ефекти:

отзивчивостта на системата се губи, потребителите чакат дълго време за отговори на заявки;
сървърът обикновено спира да отговаря на потребителски заявки поради препълващ пул от нишки: повечето от нишките „стоят“ на ключалката на ресурса, зает от транзакцията;
започват да се появяват задънени блокировки: вероятността за тяхното възникване силно зависи от продължителността на транзакциите, количеството бизнес логика и заключвания, включени в транзакцията;
появяват се грешки при изтичане на времето за изчакване на транзакцията;
сървърът "пада" на OutOfMemory, ако задачата изисква обработка и промяна на големи количества данни, а наличието на синхронни интеграции прави много трудно разделянето на обработката на "по-леки" транзакции.

От архитектурна гледна точка използването на блокиращи повиквания по време на интеграция води до загуба на контрол на качеството на отделните подсистеми: невъзможно е да се постигнат цели за качество за една подсистема изолирано от показателите за качество за друга подсистема. Ако подсистемите се разработват от различни екипи, това е голям проблем.

Нещата стават още по-интересни, ако интегрираните подсистеми са в различни приложения и трябва да се правят синхронни промени и от двете страни. Как да направите тези промени транзакционни?

Ако се правят промени в отделни транзакции, тогава ще трябва да се осигури стабилна обработка на изключения и компенсация и това напълно елиминира основното предимство на синхронните интеграции - простотата.

Разпределените транзакции също идват на ум, но ние не ги използваме в нашите решения: трудно е да се гарантира надеждност.

"Сага" като решение на проблема с транзакциите

С нарастващата популярност на микроуслугите, има нарастващо търсене на Модел на сагата.

Този модел перфектно решава горните проблеми на дългите транзакции и също така разширява възможностите за управление на състоянието на системата от страна на бизнес логиката: компенсацията след неуспешна транзакция може да не върне системата до първоначалното й състояние, но да предостави алтернатива маршрут за обработка на данни. Освен това ви позволява да не повтаряте успешно завършени стъпки за обработка на данни, когато се опитвате да доведете процеса до „добър“ край.

Интересното е, че в монолитните системи този модел е уместен и когато става въпрос за интегриране на слабо свързани подсистеми и има отрицателни ефекти, причинени от дълги транзакции и съответните блокировки на ресурси.

По отношение на нашите бизнес процеси в стил BPM се оказва, че е много лесно да се внедрят Sagas: отделните стъпки на Sagas могат да бъдат зададени като дейности в рамките на бизнес процеса, а постоянното състояние на бизнес процеса определя, между други неща, вътрешното състояние на сагите. Тоест нямаме нужда от допълнителен координационен механизъм. Всичко, от което се нуждаете, е брокер на съобщения с поддръжка за гаранции „поне веднъж“ като транспорт.

Но такова решение има и своя собствена "цена":

бизнес логиката става по-сложна: трябва да изработите компенсация;
ще бъде необходимо да се изостави пълната последователност, която може да бъде особено чувствителна за монолитни системи;
архитектурата става малко по-сложна, има допълнителна нужда от брокер на съобщения;
ще са необходими допълнителни инструменти за наблюдение и администриране (въпреки че като цяло това е дори добре: качеството на системната услуга ще се повиши).

За монолитни системи оправданието за използването на "Sags" не е толкова очевидно. За микроуслуги и други SOA, където най-вероятно вече има брокер и пълната последователност е пожертвана в началото на проекта, ползите от използването на този модел могат значително да надхвърлят недостатъците, особено ако има удобен API в ниво на бизнес логика.

Капсулиране на бизнес логиката в микроуслуги

Когато започнахме да експериментираме с микроуслуги, възникна разумен въпрос: къде да поставим бизнес логиката на домейна във връзка с услугата, която осигурява устойчивост на данните на домейна?

Когато разглеждаме архитектурата на различни BPMS, може да изглежда разумно да отделим бизнес логиката от постоянството: създайте слой от независими от платформата и домейна микроуслуги, които формират средата и контейнера за изпълнение на бизнес логиката на домейна, и подредете постоянството на данните на домейна като отделен слой от много прости и леки микроуслуги. Бизнес процесите в този случай организират услугите на слоя за устойчивост.

Този подход има много голям плюс: можете да увеличите функционалността на платформата колкото искате и само съответният слой от микроуслуги на платформата ще „напълнее“ от това. Бизнес процесите от всеки домейн веднага получават възможността да използват новата функционалност на платформата, веднага след нейното актуализиране.

По-подробно проучване разкри значителни недостатъци на този подход:

услуга на платформа, която изпълнява бизнес логиката на много домейни наведнъж, носи големи рискове като една единствена точка на повреда. Честите промени в бизнес логиката увеличават риска от грешки, водещи до сривове в цялата система;
проблеми с производителността: бизнес логиката работи със своите данни чрез тесен и бавен интерфейс:
- данните отново ще бъдат подредени и изпомпвани през мрежовия стек;
- услугата на домейна често ще връща повече данни, отколкото бизнес логиката изисква за обработка, поради недостатъчни възможности за параметризиране на заявката на нивото на външния API на услугата;
- няколко независими части от бизнес логиката могат многократно да изискват едни и същи данни за обработка (можете да смекчите този проблем, като добавите сесийни компоненти, които кешират данни, но това допълнително усложнява архитектурата и създава проблеми с актуалността на данните и анулирането на кеша);
транзакционни проблеми:
- бизнес процесите с постоянно състояние, съхранявани от услугата на платформата, не са в съответствие с данните на домейна и няма лесни начини за решаване на този проблем;
- преместване на заключването на данните за домейна извън транзакцията: ако бизнес логиката на домейна трябва да направи промени, след като първо проверите коректността на действителните данни, е необходимо да изключите възможността за конкурентна промяна в обработените данни. Външното блокиране на данни може да помогне за решаването на проблема, но такова решение носи допълнителни рискове и намалява цялостната надеждност на системата;
допълнителни усложнения при актуализиране: в някои случаи трябва да актуализирате услугата за постоянство и бизнес логиката синхронно или в строга последователност.

В крайна сметка трябваше да се върна към основите: да капсулирам данните за домейна и бизнес логиката на домейна в една микроуслуга. Този подход опростява възприемането на микроуслугата като неразделен компонент в системата и не поражда горните проблеми. Това също не е безплатно:

Стандартизацията на API е необходима за взаимодействие с бизнес логиката (по-специално, за предоставяне на потребителски дейности като част от бизнес процеси) и услугите на API платформата; изисква се по-внимателно внимание към промените в API, предна и обратна съвместимост;
изисква се добавяне на допълнителни runtime библиотеки, за да се гарантира функционирането на бизнес логиката като част от всяка такава микроуслуга, което поражда нови изисквания към такива библиотеки: лекота и минимум преходни зависимости;
разработчиците на бизнес логика трябва да следят версиите на библиотеките: ако дадена микроуслуга не е финализирана дълго време, тогава най-вероятно ще съдържа остаряла версия на библиотеките. Това може да бъде неочаквано препятствие за добавяне на нова функция и може да изисква старата бизнес логика на такава услуга да бъде мигрирана към нови версии на библиотеките, ако е имало несъвместими промени между версиите.

Слой от платформени услуги също присъства в такава архитектура, но този слой вече не формира контейнер за изпълнение на бизнес логиката на домейна, а само неговата среда, осигурявайки спомагателни функции на "платформа". Такъв слой е необходим не само за поддържане на лекотата на домейн микроуслугите, но и за централизиране на управлението.

Например дейностите на потребителите в бизнес процесите генерират задачи. Въпреки това, когато работите със задачи, потребителят трябва да вижда задачи от всички домейни в общия списък, което означава, че трябва да има подходяща услуга за платформа за регистрация на задачи, изчистена от бизнес логиката на домейна. Поддържането на капсулирането на бизнес логиката в този контекст е доста проблематично и това е друг компромис на тази архитектура.

Интеграция на бизнес процеси през погледа на разработчик на приложения

Както вече беше споменато по-горе, разработчикът на приложение трябва да се абстрахира от техническите и инженерни характеристики на реализацията на взаимодействието на няколко приложения, за да може да разчита на добра производителност на разработката.

Нека се опитаме да разрешим един доста труден интеграционен проблем, специално измислен за статията. Това ще бъде "игра" задача, включваща три приложения, където всяко от тях дефинира име на домейн: "app1", "app2", "app3".

Вътре във всяко приложение се стартират бизнес процеси, които започват да „играят топката“ през интеграционната шина. Съобщенията с име „Топка“ ще действат като топката.

Правила на играта:

първият играч е инициатор. Той кани други играчи в играта, започва играта и може да я прекрати по всяко време;
други играчи заявяват участието си в играта, „запознават се“ помежду си и с първия играч;
след като получи топката, играчът избира друг участващ играч и му подава топката. Отчита се общият брой пропуски;
всеки играч има "енергия", която намалява с всяко подаване на топката от този играч. Когато енергията свърши, играчът се елиминира от играта, обявявайки пенсионирането си;
ако играчът остане сам, той незабавно обявява напускането си;
когато всички играчи са елиминирани, първият играч обявява края на играта. Ако е напуснал играта по-рано, тогава остава да проследи играта, за да я завърши.

За да реша този проблем, ще използвам нашия DSL за бизнес процеси, който ви позволява да опишете логиката в Kotlin компактно, с минимум шаблон.

В приложението app1 бизнес процесът на първия играч (той е и инициаторът на играта) ще работи:

клас InitialPlayer

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.constraint.UniqueConstraints
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.dsl.taskOperation
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList : ArrayList<PlayerInfo>()

// Это класс экземпляра процесса: инкапсулирует его внутреннее состояние
class InitialPlayer : ProcessImpl<InitialPlayer>(initialPlayerModel) {
    var playerName: String by persistent("Player1")
    var energy: Int by persistent(30)
    var players: PlayersList by persistent(PlayersList())
    var shotCounter: Int = 0
}

// Это декларация модели процесса: создается один раз, используется всеми
// экземплярами процесса соответствующего класса
val initialPlayerModel = processModel<InitialPlayer>(name = "InitialPlayer",
                                                     version = 1) {

    // По правилам, первый игрок является инициатором игры и должен быть единственным
    uniqueConstraint = UniqueConstraints.singleton

    // Объявляем активности, из которых состоит бизнес-процесс
    val sendNewGameSignal = signal<String>("NewGame")
    val sendStopGameSignal = signal<String>("StopGame")
    val startTask = humanTask("Start") {
        taskOperation {
            processCondition { players.size > 0 }
            confirmation { "Подключилось ${players.size} игроков. Начинаем?" }
        }
    }
    val stopTask = humanTask("Stop") {
        taskOperation {}
    }
    val waitPlayerJoin = signalWait<String>("PlayerJoin") { signal ->
        players.add(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... join player ${signal.data} ...")
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... player ${signal.data} is out ...")
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val throwStartBall = messageSend<Int>("Ball") {
        messageData = { 1 }
        activation = { selectNextPlayer() }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    // Теперь конструируем граф процесса из объявленных активностей
    startFrom(sendNewGameSignal)
            .fork("mainFork") {
                next(startTask)
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut)
                        .branch("checkPlayers") {
                            ifTrue { players.isEmpty() }
                                    .next(sendStopGameSignal)
                                    .terminate()
                            ifElse().next(waitPlayerOut)
                        }
            }
    startTask.fork("afterStart") {
        next(throwStartBall)
                .branch("mainLoop") {
                    ifTrue { energy < 5 }.next(sendPlayerOut).next(waitBall)
                    ifElse().next(waitBall).next(throwBall).loop()
                }
        next(stopTask).next(sendStopGameSignal)
    }

    // Навешаем на активности дополнительные обработчики для логирования
    sendNewGameSignal.onExit { println("Let's play!") }
    sendStopGameSignal.onExit { println("Stop!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<InitialPlayer, Int>.selectNextPlayer() {
    val player = process.players.random()
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

В допълнение към изпълнението на бизнес логиката, горният код може да създаде обектен модел на бизнес процес, който може да бъде визуализиран като диаграма. Все още не сме внедрили визуализатора, така че трябваше да отделим известно време за чертане (тук леко опростих нотацията на BPMN по отношение на използването на врати, за да подобря съгласуваността на диаграмата с горния код):

app2 ще включва бизнес процес на друг играч:

клас RandomPlayer

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList: ArrayList<PlayerInfo>()

class RandomPlayer : ProcessImpl<RandomPlayer>(randomPlayerModel) {

    var playerName: String by input(persistent = true, 
                                    defaultValue = "RandomPlayer")
    var energy: Int by input(persistent = true, defaultValue = 30)
    var players: PlayersList by persistent(PlayersList())
    var allPlayersOut: Boolean by persistent(false)
    var shotCounter: Int = 0

    val selfPlayer: PlayerInfo
        get() = PlayerInfo(playerName, env.eventDispatcher.domainName, id)
}

val randomPlayerModel = processModel<RandomPlayer>(name = "RandomPlayer", 
                                                   version = 1) {

    val waitNewGameSignal = signalWait<String>("NewGame")
    val waitStopGameSignal = signalWait<String>("StopGame")
    val sendPlayerJoin = signal<String>("PlayerJoin") {
        signalData = { playerName }
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val waitPlayerJoin = signalWaitCustom<String>("PlayerJoin") {
        eventCondition = { signal ->
            signal.sender.processInstanceId != process.id 
                && !process.players.any { signal.sender.processInstanceId == it.id}
        }
        handler = { signal ->
            players.add(PlayerInfo(
                    signal.data!!,
                    signal.sender.domain,
                    signal.sender.processInstanceId))
        }
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        allPlayersOut = players.isEmpty()
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val receiveHandshake = messageWait<String>("Handshake") { message ->
        if (!players.any { message.sender.processInstanceId == it.id}) {
            players.add(PlayerInfo(
                    message.data!!, 
                    message.sender.domain, 
                    message.sender.processInstanceId))
        }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    startFrom(waitNewGameSignal)
            .fork("mainFork") {
                next(sendPlayerJoin)
                        .branch("mainLoop") {
                            ifTrue { energy < 5 || allPlayersOut }
                                    .next(sendPlayerOut)
                                    .next(waitBall)
                            ifElse()
                                    .next(waitBall)
                                    .next(throwBall)
                                    .loop()
                        }
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut).next(waitPlayerOut)
                next(receiveHandshake).next(receiveHandshake)
                next(waitStopGameSignal).terminate()
            }

    sendPlayerJoin.onExit { println("$playerName: I'm here!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<RandomPlayer, Int>.selectNextPlayer() {
    val player = if (process.players.isNotEmpty()) 
        process.players.random() 
    else 
        process.selfPlayer
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

Диаграма:

В приложението app3 ще направим играча с малко по-различно поведение: вместо да избира произволно следващия играч, той ще действа според кръговия алгоритъм:

клас RoundRobinPlayer

import ru.krista.bpm.ProcessInstance
import ru.krista.bpm.runtime.ProcessImpl
import ru.krista.bpm.runtime.dsl.processModel
import ru.krista.bpm.runtime.instance.MessageSendInstance

data class PlayerInfo(val name: String, val domain: String, val id: String)

class PlayersList: ArrayList<PlayerInfo>()

class RoundRobinPlayer : ProcessImpl<RoundRobinPlayer>(roundRobinPlayerModel) {

    var playerName: String by input(persistent = true, 
                                    defaultValue = "RoundRobinPlayer")
    var energy: Int by input(persistent = true, defaultValue = 30)
    var players: PlayersList by persistent(PlayersList())
    var nextPlayerIndex: Int by persistent(-1)
    var allPlayersOut: Boolean by persistent(false)
    var shotCounter: Int = 0

    val selfPlayer: PlayerInfo
        get() = PlayerInfo(playerName, env.eventDispatcher.domainName, id)
}

val roundRobinPlayerModel = processModel<RoundRobinPlayer>(
        name = "RoundRobinPlayer", 
        version = 1) {

    val waitNewGameSignal = signalWait<String>("NewGame")
    val waitStopGameSignal = signalWait<String>("StopGame")
    val sendPlayerJoin = signal<String>("PlayerJoin") {
        signalData = { playerName }
    }
    val sendPlayerOut = signal<String>("PlayerOut") {
        signalData = { playerName }
    }
    val waitPlayerJoin = signalWaitCustom<String>("PlayerJoin") {
        eventCondition = { signal ->
            signal.sender.processInstanceId != process.id 
                && !process.players.any { signal.sender.processInstanceId == it.id}
        }
        handler = { signal ->
            players.add(PlayerInfo(
                    signal.data!!, 
                    signal.sender.domain, 
                    signal.sender.processInstanceId))
        }
    }
    val waitPlayerOut = signalWait<String>("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!, 
                signal.sender.domain, 
                signal.sender.processInstanceId))
        allPlayersOut = players.isEmpty()
    }
    val sendHandshake = messageSend<String>("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val receiveHandshake = messageWait<String>("Handshake") { message ->
        if (!players.any { message.sender.processInstanceId == it.id}) {
            players.add(PlayerInfo(
                    message.data!!, 
                    message.sender.domain, 
                    message.sender.processInstanceId))
        }
    }
    val throwBall = messageSend<Int>("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData<Int>("Ball") {
        shotCounter = it
    }

    startFrom(waitNewGameSignal)
            .fork("mainFork") {
                next(sendPlayerJoin)
                        .branch("mainLoop") {
                            ifTrue { energy < 5 || allPlayersOut }
                                    .next(sendPlayerOut)
                                    .next(waitBall)
                            ifElse()
                                    .next(waitBall)
                                    .next(throwBall)
                                    .loop()
                        }
                next(waitPlayerJoin).next(sendHandshake).next(waitPlayerJoin)
                next(waitPlayerOut).next(waitPlayerOut)
                next(receiveHandshake).next(receiveHandshake)
                next(waitStopGameSignal).terminate()
            }

    sendPlayerJoin.onExit { println("$playerName: I'm here!") }
    sendPlayerOut.onExit { println("$playerName: I'm out!") }
}

private fun MessageSendInstance<RoundRobinPlayer, Int>.selectNextPlayer() {
    var idx = process.nextPlayerIndex + 1
    if (idx >= process.players.size) {
        idx = 0
    }
    process.nextPlayerIndex = idx
    val player = if (process.players.isNotEmpty()) 
        process.players[idx] 
    else 
        process.selfPlayer
    receiverDomain = player.domain
    receiverProcessInstanceId = player.id
    println("Step ${process.shotCounter + 1}: " +
            "${process.playerName} >>> ${player.name}")
}

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

Сега имаме нужда от тест, за да изпълним всичко. Ще дам само кода на самия тест, за да не претрупвам статията с шаблон (всъщност използвах тестовата среда, създадена по-рано, за да тествам интеграцията на други бизнес процеси):

testGame()

@Test
public void testGame() throws InterruptedException {
    String pl2 = startProcess(app2, "RandomPlayer", playerParams("Player2", 20));
    String pl3 = startProcess(app2, "RandomPlayer", playerParams("Player3", 40));
    String pl4 = startProcess(app3, "RoundRobinPlayer", playerParams("Player4", 25));
    String pl5 = startProcess(app3, "RoundRobinPlayer", playerParams("Player5", 35));
    String pl1 = startProcess(app1, "InitialPlayer");
    // Теперь нужно немного подождать, пока игроки "познакомятся" друг с другом.
    // Ждать через sleep - плохое решение, зато самое простое. 
    // Не делайте так в серьезных тестах!
    Thread.sleep(1000);
    // Запускаем игру, закрывая пользовательскую активность
    assertTrue(closeTask(app1, pl1, "Start"));
    app1.getWaiting().waitProcessFinished(pl1);
    app2.getWaiting().waitProcessFinished(pl2);
    app2.getWaiting().waitProcessFinished(pl3);
    app3.getWaiting().waitProcessFinished(pl4);
    app3.getWaiting().waitProcessFinished(pl5);
}

private Map<String, Object> playerParams(String name, int energy) {
    Map<String, Object> params = new HashMap<>();
    params.put("playerName", name);
    params.put("energy", energy);
    return params;
}

Стартирайте теста, погледнете дневника:

конзолен изход

Взята блокировка ключа lock://app1/process/InitialPlayer
Let's play!
Снята блокировка ключа lock://app1/process/InitialPlayer
Player2: I'm here!
Player3: I'm here!
Player4: I'm here!
Player5: I'm here!
... join player Player2 ...
... join player Player4 ...
... join player Player3 ...
... join player Player5 ...
Step 1: Player1 >>> Player3
Step 2: Player3 >>> Player5
Step 3: Player5 >>> Player3
Step 4: Player3 >>> Player4
Step 5: Player4 >>> Player3
Step 6: Player3 >>> Player4
Step 7: Player4 >>> Player5
Step 8: Player5 >>> Player2
Step 9: Player2 >>> Player5
Step 10: Player5 >>> Player4
Step 11: Player4 >>> Player2
Step 12: Player2 >>> Player4
Step 13: Player4 >>> Player1
Step 14: Player1 >>> Player4
Step 15: Player4 >>> Player3
Step 16: Player3 >>> Player1
Step 17: Player1 >>> Player2
Step 18: Player2 >>> Player3
Step 19: Player3 >>> Player1
Step 20: Player1 >>> Player5
Step 21: Player5 >>> Player1
Step 22: Player1 >>> Player2
Step 23: Player2 >>> Player4
Step 24: Player4 >>> Player5
Step 25: Player5 >>> Player3
Step 26: Player3 >>> Player4
Step 27: Player4 >>> Player2
Step 28: Player2 >>> Player5
Step 29: Player5 >>> Player2
Step 30: Player2 >>> Player1
Step 31: Player1 >>> Player3
Step 32: Player3 >>> Player4
Step 33: Player4 >>> Player1
Step 34: Player1 >>> Player3
Step 35: Player3 >>> Player4
Step 36: Player4 >>> Player3
Step 37: Player3 >>> Player2
Step 38: Player2 >>> Player5
Step 39: Player5 >>> Player4
Step 40: Player4 >>> Player5
Step 41: Player5 >>> Player1
Step 42: Player1 >>> Player5
Step 43: Player5 >>> Player3
Step 44: Player3 >>> Player5
Step 45: Player5 >>> Player2
Step 46: Player2 >>> Player3
Step 47: Player3 >>> Player2
Step 48: Player2 >>> Player5
Step 49: Player5 >>> Player4
Step 50: Player4 >>> Player2
Step 51: Player2 >>> Player5
Step 52: Player5 >>> Player1
Step 53: Player1 >>> Player5
Step 54: Player5 >>> Player3
Step 55: Player3 >>> Player5
Step 56: Player5 >>> Player2
Step 57: Player2 >>> Player1
Step 58: Player1 >>> Player4
Step 59: Player4 >>> Player1
Step 60: Player1 >>> Player4
Step 61: Player4 >>> Player3
Step 62: Player3 >>> Player2
Step 63: Player2 >>> Player5
Step 64: Player5 >>> Player4
Step 65: Player4 >>> Player5
Step 66: Player5 >>> Player1
Step 67: Player1 >>> Player5
Step 68: Player5 >>> Player3
Step 69: Player3 >>> Player4
Step 70: Player4 >>> Player2
Step 71: Player2 >>> Player5
Step 72: Player5 >>> Player2
Step 73: Player2 >>> Player1
Step 74: Player1 >>> Player4
Step 75: Player4 >>> Player1
Step 76: Player1 >>> Player2
Step 77: Player2 >>> Player5
Step 78: Player5 >>> Player4
Step 79: Player4 >>> Player3
Step 80: Player3 >>> Player1
Step 81: Player1 >>> Player5
Step 82: Player5 >>> Player1
Step 83: Player1 >>> Player4
Step 84: Player4 >>> Player5
Step 85: Player5 >>> Player3
Step 86: Player3 >>> Player5
Step 87: Player5 >>> Player2
Step 88: Player2 >>> Player3
Player2: I'm out!
Step 89: Player3 >>> Player4
... player Player2 is out ...
Step 90: Player4 >>> Player1
Step 91: Player1 >>> Player3
Step 92: Player3 >>> Player1
Step 93: Player1 >>> Player4
Step 94: Player4 >>> Player3
Step 95: Player3 >>> Player5
Step 96: Player5 >>> Player1
Step 97: Player1 >>> Player5
Step 98: Player5 >>> Player3
Step 99: Player3 >>> Player5
Step 100: Player5 >>> Player4
Step 101: Player4 >>> Player5
Player4: I'm out!
... player Player4 is out ...
Step 102: Player5 >>> Player1
Step 103: Player1 >>> Player3
Step 104: Player3 >>> Player1
Step 105: Player1 >>> Player3
Step 106: Player3 >>> Player5
Step 107: Player5 >>> Player3
Step 108: Player3 >>> Player1
Step 109: Player1 >>> Player3
Step 110: Player3 >>> Player5
Step 111: Player5 >>> Player1
Step 112: Player1 >>> Player3
Step 113: Player3 >>> Player5
Step 114: Player5 >>> Player3
Step 115: Player3 >>> Player1
Step 116: Player1 >>> Player3
Step 117: Player3 >>> Player5
Step 118: Player5 >>> Player1
Step 119: Player1 >>> Player3
Step 120: Player3 >>> Player5
Step 121: Player5 >>> Player3
Player5: I'm out!
... player Player5 is out ...
Step 122: Player3 >>> Player5
Step 123: Player5 >>> Player1
Player5: I'm out!
Step 124: Player1 >>> Player3
... player Player5 is out ...
Step 125: Player3 >>> Player1
Step 126: Player1 >>> Player3
Player1: I'm out!
... player Player1 is out ...
Step 127: Player3 >>> Player3
Player3: I'm out!
Step 128: Player3 >>> Player3
... player Player3 is out ...
Player3: I'm out!
Stop!
Step 129: Player3 >>> Player3
Player3: I'm out!

От всичко това могат да се направят няколко важни извода:

ако необходимите инструменти са налични, разработчиците на приложения могат да създават интеграционни взаимодействия между приложенията, без да се откъсват от бизнес логиката;
сложността (комплексността) на интеграционна задача, която изисква инженерни компетенции, може да бъде скрита вътре в рамката, ако първоначално е заложена в архитектурата на рамката. Трудността на задачата (трудността) не може да бъде скрита, така че решението на трудна задача в кода ще изглежда съответно;
при разработването на интеграционна логика е необходимо да се вземе предвид евентуалната последователност и липсата на линеаризация на промяната на състоянието на всички участници в интеграцията. Това ни принуждава да усложним логиката, за да я направим нечувствителна към реда, в който се случват външните събития. В нашия пример играчът е принуден да участва в играта, след като обяви излизането си от играта: други играчи ще продължат да му подават топката, докато информацията за неговото излизане достигне и бъде обработена от всички участници. Тази логика не следва от правилата на играта и е компромисно решение в рамките на избраната архитектура.

След това нека поговорим за различните тънкости на нашето решение, компромиси и други точки.

Всички съобщения в една опашка

Всички интегрирани приложения работят с една интеграционна шина, която се представя като външен брокер, една BPMQueue за съобщения и една BPMTopic тема за сигнали (събития). Преминаването на всички съобщения през една опашка само по себе си е компромис. На ниво бизнес логика вече можете да въвеждате толкова нови типове съобщения, колкото искате, без да правите промени в структурата на системата. Това е значително опростяване, но носи определени рискове, които в контекста на типичните ни задачи ни се струваха не толкова съществени.

Тук обаче има една тънкост: всяко приложение филтрира "своите" съобщения от опашката на входа, по името на своя домейн. Освен това домейнът може да бъде посочен в сигналите, ако трябва да ограничите "обхвата" на сигнала до едно приложение. Това трябва да увеличи честотната лента на шината, но бизнес логиката вече трябва да работи с имена на домейни: задължително за адресиране на съобщения, желателно за сигнали.

Гарантиране на надеждността на интеграционната шина

Надеждността се състои от няколко неща:

Избраният брокер на съобщения е критичен компонент от архитектурата и единствена точка на повреда: той трябва да бъде достатъчно устойчив на грешки. Трябва да използвате само проверени във времето реализации с добра поддръжка и голяма общност;
необходимо е да се осигури висока наличност на брокера на съобщения, за което той трябва да бъде физически отделен от интегрираните приложения (високата наличност на приложения с приложена бизнес логика е много по-трудна и скъпа за осигуряване);
брокерът е длъжен да предостави "поне веднъж" гаранции за доставка. Това е задължително изискване за надеждна работа на интеграционната шина. Няма нужда от гаранции на ниво „точно веднъж“: бизнес процесите обикновено не са чувствителни към многократното пристигане на съобщения или събития и при специални задачи, където това е важно, е по-лесно да добавите допълнителни проверки към бизнес логиката, отколкото да използвате постоянно доста "скъпи" гаранции;
изпращането на съобщения и сигнали трябва да бъде включено в обща транзакция с промяна в състоянието на бизнес процесите и данните на домейна. Предпочитаният вариант би бил да използвате шаблона Транзакционна изходяща кутия, но ще изисква допълнителна таблица в базата данни и реле. В JEE приложенията това може да бъде опростено чрез използване на локален JTA мениджър, но връзката с избрания брокер трябва да може да работи в режим XA;
манипулаторите на входящи съобщения и събития също трябва да работят с транзакцията за промяна на състоянието на бизнес процеса: ако такава транзакция бъде върната назад, тогава получаването на съобщението също трябва да бъде отменено;
съобщенията, които не могат да бъдат доставени поради грешки, трябва да се съхраняват в отделно хранилище D.L.Q. (Опашка за мъртви писма). За да направим това, създадохме отделна микроуслуга на платформа, която съхранява такива съобщения в своето хранилище, индексира ги по атрибути (за бързо групиране и търсене) и излага API за преглед, повторно изпращане до адреса на местоназначение и изтриване на съобщения. Системните администратори могат да работят с тази услуга чрез своя уеб интерфейс;
в настройките на брокера трябва да коригирате броя на повторните опити за доставка и закъсненията между доставките, за да намалите вероятността съобщенията да попаднат в DLQ (почти невъзможно е да се изчислят оптималните параметри, но можете да действате емпирично и да ги коригирате по време на операция);
хранилището на DLQ трябва да се наблюдава непрекъснато и системата за наблюдение трябва да уведомява системните администратори, така че те да могат да реагират възможно най-бързо, когато възникнат недоставени съобщения. Това ще намали „зоната на повреда“ от повреда или грешка в бизнес логиката;
интеграционната шина трябва да е нечувствителна към временното отсъствие на приложения: абонаментите за теми трябва да са трайни, а името на домейна на приложението трябва да е уникално, така че някой друг да не се опитва да обработи съобщението му от опашката по време на отсъствието на приложението.

Осигуряване на безопасност на нишката на бизнес логиката

Едно и също копие на бизнес процес може да получи няколко съобщения и събития наведнъж, чиято обработка ще започне паралелно. В същото време за разработчика на приложения всичко трябва да е просто и безопасно за нишки.

Бизнес логиката на процеса обработва всяко външно събитие, което засяга този бизнес процес индивидуално. Тези събития могат да бъдат:

стартиране на екземпляр на бизнес процес;
потребителско действие, свързано с дейност в рамките на бизнес процес;
получаване на съобщение или сигнал, за които е абониран екземпляр на бизнес процес;
изтичане на таймера, зададен от екземпляра на бизнес процеса;
контролно действие чрез API (напр. прекъсване на процеса).

Всяко такова събитие може да промени състоянието на екземпляр на бизнес процес: някои дейности могат да приключат и други да започнат, стойностите на постоянните свойства могат да се променят. Затварянето на всяка дейност може да доведе до активирането на една или повече от следните дейности. Те от своя страна могат да спрат да чакат други събития или, ако не се нуждаят от допълнителни данни, могат да завършат същата транзакция. Преди затваряне на транзакцията, новото състояние на бизнес процеса се съхранява в базата данни, където ще изчака следващото външно събитие.

Постоянните данни за бизнес процеси, съхранявани в релационна база данни, са много удобна точка за синхронизиране на обработката, когато използвате ИЗБОР ЗА АКТУАЛИЗИРАНЕ. Ако една транзакция е успяла да получи състоянието на бизнес процеса от базата, за да го промени, тогава никоя друга паралелна транзакция няма да може да получи същото състояние за друга промяна и след приключване на първата транзакция, втората е гарантирано ще получи вече промененото състояние.

Използвайки песимистични ключалки от страна на СУБД, ние изпълняваме всички необходими изисквания ACID, а също така запазват възможността за мащабиране на приложението с бизнес логика чрез увеличаване на броя на работещите екземпляри.

Въпреки това, песимистичните заключвания ни заплашват с блокирания, което означава, че ИЗБЕРЕТЕ ЗА АКТУАЛИЗИРАНЕ все още трябва да бъде ограничено до някакво разумно време за изчакване в случай на блокиране на някои груби случаи в бизнес логиката.

Друг проблем е синхронизирането на стартирането на бизнес процеса. Въпреки че няма екземпляр на бизнес процес, няма и състояние в базата данни, така че описаният метод няма да работи. Ако искате да осигурите уникалността на екземпляр на бизнес процес в конкретен обхват, тогава имате нужда от някакъв вид обект за синхронизация, свързан с класа на процеса и съответния обхват. За да разрешим този проблем, ние използваме различен механизъм за заключване, който ни позволява да заключим произволен ресурс, определен от ключ във формат URI чрез външна услуга.

В нашите примери бизнес процесът InitialPlayer съдържа декларация

uniqueConstraint = UniqueConstraints.singleton

Следователно дневникът съдържа съобщения за вземане и освобождаване на ключалката на съответния ключ. Няма такива съобщения за други бизнес процеси: uniqueConstraint не е зададено.

Проблеми с бизнес процеси с постоянно състояние

Понякога наличието на постоянно състояние не само помага, но и наистина възпрепятства развитието.
Проблемите започват, когато трябва да направите промени в бизнес логиката и / или модела на бизнес процеса. Нито една такава промяна не е съвместима със старото състояние на бизнес процесите. Ако има много "живи" копия в базата данни, тогава извършването на несъвместими промени може да причини много проблеми, които често срещаме, когато използваме jBPM.

В зависимост от дълбочината на промяната можете да действате по два начина:

създайте нов тип бизнес процес, за да не правите несъвместими промени в стария, и го използвайте вместо стария, когато стартирате нови екземпляри. Старите инстанции ще продължат да работят "по стария начин";
мигрирайте постоянното състояние на бизнес процесите при актуализиране на бизнес логиката.

Първият начин е по-прост, но има своите ограничения и недостатъци, например:

дублиране на бизнес логиката в много модели на бизнес процеси, увеличаване на обема на бизнес логиката;
често се изисква мигновен преход към нова бизнес логика (почти винаги по отношение на задачите за интеграция);
разработчикът не знае в кой момент е възможно да изтриете остарелите модели.

На практика използваме и двата подхода, но сме взели редица решения, за да опростим живота си:

в базата данни постоянното състояние на бизнес процеса се съхранява в лесна за четене и лесна за обработка форма: в низ във формат JSON. Това ви позволява да извършвате миграции както вътре в приложението, така и извън него. В екстремни случаи можете също да го настроите с дръжки (особено полезно при разработка по време на отстраняване на грешки);
интеграционната бизнес логика не използва имена на бизнес процеси, така че по всяко време е възможно да се замени изпълнението на един от участващите процеси с нов, с ново име (например „InitialPlayerV2“). Обвързването става чрез имената на съобщенията и сигналите;
моделът на процеса има номер на версия, който увеличаваме, ако направим несъвместими промени в този модел, и този номер се съхранява заедно със състоянието на екземпляра на процеса;
постоянното състояние на процеса се чете първо от базата в удобен обектен модел, с който процедурата за миграция може да работи, ако номерът на версията на модела се е променил;
процедурата за миграция се поставя до бизнес логиката и се нарича "мързелива" за всеки екземпляр на бизнес процеса в момента на възстановяването му от базата данни;
ако трябва да мигрирате състоянието на всички екземпляри на процеси бързо и синхронно, се използват по-класически решения за мигриране на бази данни, но там трябва да работите с JSON.

Имам ли нужда от друга рамка за бизнес процеси?

Решенията, описани в статията, ни позволиха значително да опростим живота си, да разширим обхвата на проблемите, решени на ниво разработка на приложения, и да направим идеята за разделяне на бизнес логиката в микроуслуги по-привлекателна. За това е свършена много работа, създадена е много „лека“ рамка за бизнес процеси, както и сервизни компоненти за решаване на идентифицираните проблеми в контекста на широк спектър от приложни задачи. Имаме желание да споделим тези резултати, да предоставим разработката на общи компоненти в отворен достъп под безплатен лиценз. Това ще изисква известно време и усилия. Разбирането на търсенето на такива решения може да бъде допълнителен стимул за нас. В предложената статия се обръща много малко внимание на възможностите на самата рамка, но някои от тях са видими от представените примери. Ако все пак публикуваме нашата рамка, на нея ще бъде посветена отделна статия. Междувременно ще ви бъдем благодарни, ако оставите малко отзиви, като отговорите на въпроса:

В анкетата могат да участват само регистрирани потребители. Впиши се, Моля те.

Имам ли нужда от друга рамка за бизнес процеси?

18,8%Да, отдавна търся нещо подобно.
12,5%интересно е да научите повече за вашата реализация, може да е полезно2
6,2%използваме една от съществуващите рамки, но обмисляме да я заменим1
18,8%използваме една от съществуващите рамки, всичко подхожда3
18,8%справяне без рамка3
25,0%напишете своя собствена4

16 потребители гласуваха. 7 потребители се въздържаха.

Източник: www.habr.com

Интегриране на BPM стил

Опровержение

Какво общо има BPM с това?

Недостатъци на синхронните повиквания като интеграционен модел

"Сага" като решение на проблема с транзакциите

Капсулиране на бизнес логиката в микроуслуги

Интеграция на бизнес процеси през погледа на разработчик на приложения

Всички съобщения в една опашка

Гарантиране на надеждността на интеграционната шина

Осигуряване на безопасност на нишката на бизнес логиката

Проблеми с бизнес процеси с постоянно състояние

Имам ли нужда от друга рамка за бизнес процеси?

Имам ли нужда от друга рамка за бизнес процеси?

Добавяне на нов коментар

Интегриране на BPM стил

Опровержение

Какво общо има BPM с това?

Недостатъци на синхронните повиквания като интеграционен модел

"Сага" като решение на проблема с транзакциите

Капсулиране на бизнес логиката в микроуслуги

Интеграция на бизнес процеси през погледа на разработчик на приложения

Всички съобщения в една опашка

Гарантиране на надеждността на интеграционната шина

Осигуряване на безопасност на нишката на бизнес логиката

Проблеми с бизнес процеси с постоянно състояние

Имам ли нужда от друга рамка за бизнес процеси?

Имам ли нужда от друга рамка за бизнес процеси?

Добавяне на нов коментар Отказване на отговора

Добавяне на нов коментар