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

Здраво, хебрејски!

Нашата компанија е специјализирана за развој на софтверски решенија од класата ERP, чиј лавовски дел е окупиран од трансакциски системи со огромна деловна логика и проток на документи a la EDMS. Тековните верзии на нашите производи се засноваат на JavaEE технологии, но ние исто така активно експериментираме со микросервисите. Една од најпроблематичните области на ваквите решенија е интеграцијата на различни потсистеми кои припаѓаат на соседните домени. Проблемите со интеграцијата отсекогаш ни задаваа огромна главоболка, без оглед на архитектонските стилови, технолошките стекови и рамки што ги користиме, но неодамна има напредок во решавањето на ваквите проблеми.

Во написот што ви го предлагам ќе зборувам за искуството и архитектонските истражувања кои НПО „Криста“ ги има во одредената област. Ќе погледнеме и пример за едноставно решение за проблем со интеграција од гледна точка на развивач на апликации и ќе откриеме што се крие зад оваа едноставност.

Одрекување од одговорност

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

Каква врска има BPM со тоа?

За да одговориме на ова прашање, треба да навлеземе малку подлабоко во спецификите на применетите проблеми на нашите решенија. Главниот дел од деловната логика во нашиот типичен трансакциски систем е внесување податоци во базата на податоци преку кориснички интерфејси, рачна и автоматска проверка на овие податоци, нивно спроведување преку одреден работен тек, објавување на друг систем / аналитичка база на податоци / архива, генерирање извештаи . Така, клучната функција на системот за клиентите е автоматизација на нивните внатрешни деловни процеси.

За погодност, го користиме терминот „документ“ во комуникацијата како некаква апстракција на збир на податоци обединети со заеднички клуч со кој може да се „поврзе одреден работен тек“.
Но, што е со логиката за интеграција? На крајот на краиштата, задачата за интеграција е генерирана од архитектурата на системот, која е „пресечена“ на делови НЕ по барање на клиентот, туку под влијание на сосема различни фактори:

• предмет на законот на Конвеј;
• како резултат на повторна употреба на потсистеми претходно развиени за други производи;
• по дискреција на архитектот, врз основа на нефункционални барања.

Постои големо искушение да се одвои логиката за интегрирање од деловната логика на главниот тек на работа, за да не се загади деловната логика со артефакти за интегрирање и да се ослободи развивачот на апликацијата од потребата да навлегува во спецификите на архитектонскиот пејзаж на системот. Овој пристап има голем број на предности, но практиката ја покажува неговата неефективност:

• решавањето на проблемите со интеграцијата обично се враќа на наједноставните опции во форма на синхрони повици поради ограничените точки на проширување во спроведувањето на главниот работен тек (недостатоците на синхроната интеграција се дискутирани подолу);
• артефактите за интеграција сè уште продираат во основната деловна логика кога е потребна повратна информација од друг потсистем;
• развивачот на апликацијата ја игнорира интеграцијата и лесно може да ја прекине со менување на работниот тек;
• системот престанува да биде единствена целина од гледна точка на корисникот, „шевовите“ меѓу потсистемите стануваат забележливи и се појавуваат непотребни кориснички операции, што иницира пренос на податоци од еден потсистем во друг.

Друг пристап е да се разгледаат интеграциските интеракции како составен дел од основната деловна логика и работниот тек. За да се спречи вртоглаво зголемување на квалификациите на развивачите на апликации, создавањето нови интеракции за интеграција треба да биде лесно и без напор, со минимална можност да се избере решение. Ова е потешко да се направи отколку што изгледа: алатката мора да биде доволно моќна за да му ја обезбеди на корисникот потребната разновидност на опции за нејзина употреба, без да му дозволи „да си пука во нога“. Има многу прашања на кои инженерот мора да одговори во контекст на задачите за интеграција, но за кои развивачот на апликации не треба да размислува во неговата секојдневна работа: граници на трансакциите, конзистентност, атомичност, безбедност, скалирање, оптоварување и дистрибуција на ресурси, рутирање, маршалирање, дистрибуција и префрлување контексти, итн. Неопходно е да им се понудат на развивачите на апликации прилично едноставни шаблони за решенија во кои одговорите на сите такви прашања се веќе скриени. Овие шаблони мора да бидат прилично безбедни: деловната логика се менува многу често, што го зголемува ризикот од воведување грешки, цената на грешките мора да остане на прилично ниско ниво.

Но, каква врска има BPM со тоа? Постојат многу опции за спроведување на работниот тек...
Навистина, друга имплементација на деловните процеси е многу популарна во нашите решенија - преку декларативното дефинирање на дијаграмот на транзиција на состојби и поврзувањето на управувачите со деловната логика за транзиции. Во овој случај, состојбата што ја одредува моменталната позиција на „документот“ во деловниот процес е атрибут на самиот „документ“.

Вака изгледа процесот на почетокот на проектот

Популарноста на оваа имплементација се должи на релативната едноставност и брзина на создавање линеарни деловни процеси. Меѓутоа, како што софтверските системи постојано стануваат посложени, автоматизираниот дел од деловниот процес расте и станува покомплексен. Има потреба од разградување, повторна употреба на делови од процеси, како и процеси на разгранување така што секоја гранка се извршува паралелно. Во такви услови, алатката станува незгодна, а дијаграмот за транзиција на состојбата ја губи својата информациска содржина (интеграционите интеракции воопшто не се рефлектираат на дијаграмот).

Вака изгледа процесот по неколку повторувања на појаснување на барањата.

Излезот од оваа ситуација беше интеграцијата на моторот jBPM во некои производи со најсложени деловни процеси. На краток рок, ова решение имаше одреден успех: стана можно да се имплементираат сложени деловни процеси додека се одржува прилично информативен и релевантен дијаграм во ознаката BPMN2.

Мал дел од сложен деловен процес

На долг рок, решението не ги оправда очекувањата: високиот трудоинтензитет на креирање деловни процеси преку визуелни алатки не дозволуваше да се постигнат прифатливи индикатори за продуктивност, а самата алатка стана една од најнедопаднатите меѓу програмерите. Имаше поплаки и за внатрешната структура на моторот, што доведе до појава на многу „закрпи“ и „патерици“.

Главниот позитивен аспект на користењето на jBPM беше свесноста за придобивките и штетите од постоењето на постојана состојба на примерот на деловниот процес. Ја видовме и можноста за користење процесен пристап за имплементација на сложени протоколи за интеграција помеѓу различни апликации користејќи асинхрони интеракции преку сигнали и пораки. Присуството на постојана состојба игра клучна улога во ова.

Врз основа на горенаведеното, можеме да заклучиме: Процесниот пристап во стилот BPM ни овозможува да решиме широк опсег на задачи за да ги автоматизираме сè покомплексните деловни процеси, хармонично да ги вклопиме активностите за интеграција во овие процеси и да ја одржиме способноста за визуелно прикажување на имплементираниот процес во соодветна нотација.

Недостатоци на синхроните повици како шема за интеграција

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

Овој модел на интеграција има прилично голем сет на недостатоци, но тој е многу широко користен во пракса поради неговата едноставност. Брзината на имплементација плени и ве принудува да ја користите повторно и повторно во услови на притискање на рокови, запишувајќи го решението како технички долг. Но, се случува и неискусните програмери да го користат несвесно, едноставно не сфаќајќи ги негативните последици.

Покрај најочигледното зголемување на поврзаноста на потсистемите, има и помалку очигледни проблеми со „растечките“ и „растечките“ трансакции. Навистина, ако деловната логика направи некои промени, тогаш трансакциите не можат да се избегнат, а трансакциите, пак, блокираат одредени ресурси на апликацијата засегнати од овие промени. Односно, додека еден потсистем не чека одговор од другиот, нема да може да ја заврши трансакцијата и да ги отстрани бравите. Ова значително го зголемува ризикот од различни ефекти:

• Одговорноста на системот е изгубена, корисниците чекаат долго време за одговори на прашањата;
• серверот генерално престанува да одговара на барањата на корисниците поради пренатрупаниот базен на нишки: поголемиот дел од нишките се заклучени на ресурс окупиран од трансакција;
• Почнуваат да се појавуваат ќор-сокак: веројатноста за нивно појавување силно зависи од времетраењето на трансакциите, износот на деловната логика и бравите вклучени во трансакцијата;
• се појавуваат грешки за истекот на трансакцијата;
• серверот „не успева“ со OutOfMemory ако задачата бара обработка и менување на големи количини на податоци, а присуството на синхрони интеграции го отежнува делењето на обработката на „полесни“ трансакции.

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

Работите стануваат уште поинтересни ако потсистемите што се интегрираат се во различни апликации и треба да направите синхрони промени на двете страни. Како да се обезбеди трансакционалност на овие промени?

Ако се направат промени во посебни трансакции, тогаш ќе треба да обезбедите сигурно справување со исклучоци и компензација, а тоа целосно ја елиминира главната придобивка од синхроните интеграции - едноставноста.

Дистрибуираните трансакции исто така доаѓаат на ум, но ние не ги користиме во нашите решенија: тешко е да се обезбеди сигурност.

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

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

Овој модел совршено ги решава горенаведените проблеми на долгите трансакции, а исто така ги проширува можностите за управување со состојбата на системот од страната на деловната логика: компензацијата по неуспешната трансакција може да не го врати системот во првобитната состојба, туку да обезбеди алтернативен пат за обработка на податоци. Ова исто така ви овозможува да избегнете повторување на успешно завршените чекори за обработка на податоци кога се обидувате да го доведете процесот до „добар“ крај.

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

Во однос на нашите деловни процеси во стилот на BPM, излегува дека е многу лесно да се имплементираат „Sagas“: поединечните чекори на „Saga“ може да се наведат како активности во рамките на деловниот процес, а постојаната состојба на деловниот процес исто така ја одредува внатрешната состојба на „Сагата“. Односно, не бараме никаков дополнителен механизам за координација. Сè што ви треба е брокер за пораки што поддржува „барем еднаш“ гаранции како транспорт.

Но, ова решение има и своја „цена“:

• деловната логика станува посложена: треба да се разработи компензацијата;
• ќе биде неопходно да се напушти целосната конзистентност, што може да биде особено чувствително за монолитни системи;
• Архитектурата станува малку посложена и се појавува дополнителна потреба од брокер за пораки;
• ќе бидат потребни дополнителни алатки за следење и администрација (иако генерално ова е добро: квалитетот на системската услуга ќе се зголеми).

За монолитни системи, оправдувањето за користење на "Sag" не е толку очигледно. За микроуслуги и други SOA, каде што најверојатно веќе има посредник, а целосната конзистентност е жртвувана на почетокот на проектот, придобивките од користењето на оваа шема може значително да ги надминат недостатоците, особено ако постои удобен API во деловната логика ниво.

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

Кога почнавме да експериментираме со микросервисите, се појави разумно прашање: каде да се постави деловната логика на доменот во однос на услугата која обезбедува опстојување на податоците на доменот?

Кога се гледа архитектурата на различни BPMS, може да изгледа разумно да се оддели деловната логика од постојаната: да се создаде слој од платформа и микросервиси независни од домен кои формираат средина и контејнер за извршување на деловната логика на доменот и дизајнирање на постојаноста на податоците на доменот како посебен слој од многу едноставни и лесни микросервиси. Деловните процеси во овој случај вршат оркестрација на услугите на слојот на упорност.

Овој пристап има многу голема предност: можете да ја зголемите функционалноста на платформата колку што сакате, а само соодветниот слој на микросервиси на платформата ќе стане „дебел“ од ова. Деловните процеси од кој било домен веднаш можат да ја користат новата функционалност на платформата веднаш штом ќе се ажурира.

Подетална студија откри значителни недостатоци на овој пристап:

• услуга на платформа која ја извршува деловната логика на многу домени одеднаш носи големи ризици како единствена точка на неуспех. Честите промени во деловната логика го зголемуваат ризикот од грешки што доведуваат до неуспеси низ целиот систем;
• проблеми со перформансите: деловната логика работи со нејзините податоци преку тесен и бавен интерфејс:
  • податоците уште еднаш ќе бидат маршалирани и испумпани низ мрежниот оџак;
  • услугата на доменот честопати обезбедува повеќе податоци отколку што е потребно за обработка на деловната логика поради недоволните можности за параметризирање на барањата на ниво на надворешниот API на услугата;
  • неколку независни делови од деловната логика можат постојано да ги бараат истите податоци за обработка (овој проблем може да се ублажи со додавање на компоненти за сесија кои кешираат податоци, но ова дополнително ја комплицира архитектурата и создава проблеми со релевантноста на податоците и неважење на кешот);
• проблеми со трансакцијата:
  • деловните процеси со постојана состојба, кои се складирани од услуга на платформа, не се во согласност со податоците на доменот и нема лесни начини за решавање на овој проблем;
  • поставување на блокирање на податоци на доменот надвор од трансакцијата: ако деловната логика на доменот треба да направи промени откако прво ќе ја провери исправноста на тековните податоци, неопходно е да се исклучи можноста за конкурентна промена во обработените податоци. Блокирањето на надворешните податоци може да помогне во решавањето на проблемот, но таквото решение носи дополнителни ризици и ја намалува севкупната доверливост на системот;
• дополнителни тешкотии при ажурирањето: во некои случаи, услугата за упорност и деловната логика треба да се ажурираат синхроно или во строга низа.

На крајот, моравме да се вратиме на основите: да ги енкапсулираме податоците на доменот и деловната логика на доменот во една микросервис. Овој пристап ја поедноставува перцепцијата на микросервисот како интегрална компонента на системот и не предизвикува горенаведените проблеми. Ова исто така не се дава бесплатно:

• Потребна е стандардизација на API за интеракција со деловната логика (особено, за да се обезбедат кориснички активности како дел од деловните процеси) и услугите на платформата API; бара повнимателно внимание на промените на API, компатибилноста напред и назад;
• неопходно е да се додадат дополнителни библиотеки за време на работа за да се обезбеди функционирање на деловната логика како дел од секој таков микросервис, а тоа доведува до нови барања за таквите библиотеки: леснотија и минимум транзитивни зависности;
• Програмерите на деловната логика треба да ги следат верзиите на библиотеката: ако микросервисот не е финализиран долго време, тогаш најверојатно ќе содржи застарена верзија на библиотеките. Ова може да биде неочекувана пречка за додавање нова функција и може да бара мигрирање на старата деловна логика на таквата услуга на нови верзии на библиотеки доколку има некомпатибилни промени помеѓу верзии.

Слој на платформски услуги е исто така присутен во таква архитектура, но овој слој повеќе не формира контејнер за извршување на деловната логика на доменот, туку само неговата околина, обезбедувајќи помошни функции на „платформа“. Таков слој е потребен не само за одржување на лесната природа на микросервисите на доменот, туку и за централизирање на управувањето.

На пример, корисничките активности во деловните процеси генерираат задачи. Меѓутоа, кога работи со задачи, корисникот мора да ги види задачите од сите домени во општата листа, што значи дека мора да има соодветна услуга за регистрација на задачи на платформата, исчистена од деловната логика на доменот. Одржувањето на енкапсулација на деловната логика во таков контекст е доста проблематично, а ова е уште еден компромис на оваа архитектура.

Интеграција на деловните процеси низ очите на развивачот на апликации

Како што споменавме погоре, развивачот на апликации мора да биде апстрахиран од техничките и инженерските карактеристики на спроведувањето на интеракцијата на неколку апликации за да може да се смета на добра развојна продуктивност.

Ајде да се обидеме да решиме прилично тежок проблем за интеграција, специјално измислен за статијата. Ова ќе биде задача „игра“ која вклучува три апликации, каде што секоја од нив дефинира одредено име на домен: „app1“, „app2“, „app3“.

Внатре во секоја апликација се лансираат деловни процеси кои почнуваат да „играат со топка“ преку автобусот за интеграција. Пораките со името „Бол“ ќе делуваат како топка.

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

• првиот играч е иницијатор. Тој ги поканува другите играчи на играта, ја започнува играта и може да ја заврши во секое време;
• другите играчи го изјавуваат своето учество во играта, се „запознаваат“ едни со други и првиот играч;
• по добивањето на топката, играчот избира друг играч учесник и му ја додава топката. Се брои вкупниот број на преноси;
• Секој играч има „енергија“ која се намалува со секое додавање на топката од тој играч. Кога ќе истече енергијата, играчот ја напушта играта, објавувајќи отказ;
• ако играчот остане сам, тој веднаш го најавува своето заминување;
• Кога сите играчи ќе бидат елиминирани, првиот играч ја прогласува играта за завршена. Ако ја напушти играта предвреме, останува да ја следи играта за да ја заврши.

За да го решам овој проблем, ќе го користам нашиот DSL за деловни процеси, што ни овозможува компактно да ја опишеме логиката во Котлин, со минимум котел.

Деловниот процес на првиот играч (познат како иницијатор на играта) ќе работи во апликацијата 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 ќе направиме играч со малку поинакво однесување: наместо по случаен избор на следниот играч, тој ќе дејствува според кружниот алгоритам:

класа RoundRobin Player

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;
• ракувачите на дојдовни пораки и настани мора да работат и со трансакција што ја менува состојбата на деловниот процес: ако таквата трансакција се врати назад, тогаш приемот на пораката мора да се откаже;
• пораките што не можеа да се испорачаат поради грешки мора да се складираат во посебно складирање Д.Л.К. (Редот за мртви букви). За таа цел, создадовме посебна платформа микросервис што ги складира таквите пораки во складиштето, ги индексира по атрибути (за брзо групирање и пребарување) и изложува API за гледање, повторно испраќање до дестинацијата адреса и бришење пораки. Системските администратори можат да работат со оваа услуга преку нивниот веб-интерфејс;
• во поставките на брокерот, треба да го прилагодите бројот на повторувања за испорака и одложувања помеѓу испораките за да ја намалите веројатноста пораките да влезат во DLQ (речиси е невозможно да се пресметаат оптималните параметри, но можете да дејствувате емпириски и да ги прилагодите за време на работата );
• Продавницата на DLQ мора постојано да се следи, а системот за следење мора да ги предупреди системските администратори за да можат да одговорат што е можно побрзо кога ќе се појават неиспорачани пораки. Ова ќе ја намали „погодената област“ на неуспех или грешка во деловната логика;
• автобусот за интеграција мора да биде нечувствителен на привремено отсуство на апликации: претплатите на темата мора да бидат трајни, а името на доменот на апликацијата мора да биде единствено така што додека апликацијата е отсутна, некој друг нема да се обиде да ги обработи нејзините пораки од редица.

Обезбедување на безбедноста на конецот на деловната логика

Истиот пример на деловен процес може да прими неколку пораки и настани одеднаш, чија обработка ќе започне паралелно. Во исто време, за развивач на апликации, сè треба да биде едноставно и безбедно за нишки.

Деловната логика на еден процес го обработува секој надворешен настан кој влијае на тој деловен процес поединечно. Таквите настани може да бидат:

• лансирање на пример на деловен процес;
• корисничко дејство поврзано со активност во рамките на деловниот процес;
• прием на порака или сигнал на кој е претплатен пример на деловен процес;
• активирање на тајмер поставен од пример на деловен процес;
• контролно дејство преку API (на пример, прекин на процесот).

Секој таков настан може да ја промени состојбата на примерот на деловниот процес: некои активности може да завршат, а други да започнат, а вредностите на постојаните својства може да се променат. Затворањето на која било активност може да резултира со активирање на една или повеќе од следните активности. Тие, пак, можат да престанат да чекаат други настани или, доколку не им требаат дополнителни податоци, можат да ја завршат истата трансакција. Пред да се затвори трансакцијата, новата состојба на деловниот процес се зачувува во базата на податоци, каде што ќе чека да се случи следниот надворешен настан.

Постојаните податоци за деловниот процес складирани во релациона база на податоци се многу погодна точка за синхронизирање на обработката ако користите ИЗБИРАЈ ЗА АЖУРИРАЊЕ. Ако една трансакција успеала да ја добие состојбата на деловниот процес од основата за нејзино менување, тогаш ниту една друга трансакција паралелно нема да може да ја добие истата состојба за друга промена, а по завршувањето на првата трансакција, втората е гарантирано ќе ја добие веќе изменетата состојба.

Користејќи песимистички брави на страната на DBMS, ги исполнуваме сите потребни барања Киселина, а исто така ја задржуваат способноста да ја скалирате апликацијата со деловна логика со зголемување на бројот на инстанци кои работат.

Сепак, песимистичките брави ни се закануваат со ќор-сокак, што значи дека ИЗБЕРЕТЕ ЗА АЖУРИРАЊЕ сепак треба да се ограничи на одреден разумен тајмаут во случај да се појават ќор-сокак на некои екстремни случаи во деловната логика.

Друг проблем е синхронизацијата на почетокот на деловниот процес. Иако не постои пример на деловен процес, нема состојба во базата на податоци, така што опишаниот метод нема да работи. Ако треба да ја осигурате уникатноста на примерот на деловниот процес во одреден опсег, тогаш ќе ви треба некој вид објект за синхронизација поврзан со класата на процес и соодветниот опсег. За да го решиме овој проблем, користиме различен механизам за заклучување што ни овозможува да преземеме заклучување на произволен ресурс наведен со клуч во формат URI преку надворешна услуга.

Во нашите примери, деловниот процес InitialPlayer содржи декларација

uniqueConstraint = UniqueConstraints.singleton

Затоа, дневникот содржи пораки за преземање и отпуштање на заклучувањето на соодветниот клуч. Нема такви пораки за други деловни процеси: uniqueConstraint не е поставен.

Проблеми на деловните процеси со постојана состојба

Понекогаш имањето постојана состојба не само што помага, туку и навистина го попречува развојот.
Проблемите започнуваат кога треба да се направат промени во деловната логика и/или моделот на деловниот процес. Не секоја таква промена е компатибилна со старата состојба на деловните процеси. Ако има многу живи примероци во базата на податоци, тогаш правењето некомпатибилни промени може да предизвика многу проблеми, со кои често се среќаваме кога користиме jBPM.

Во зависност од длабочината на промените, можете да дејствувате на два начина:

1. креирајте нов тип на деловен процес за да не направите некомпатибилни промени на стариот и користете го наместо стариот при стартување на нови примероци. Старите копии ќе продолжат да работат „како порано“;
2. ја мигрираат постојаната состојба на деловните процеси при ажурирање на деловната логика.

Првиот начин е поедноставен, но има свои ограничувања и недостатоци, на пример:

• дуплирање на деловната логика во многу модели на деловни процеси, зголемувајќи го обемот на деловната логика;
• Честопати е потребна итна транзиција кон нова деловна логика (во однос на задачите за интеграција - речиси секогаш);
• развивачот не знае во кој момент може да се избришат застарените модели.

Во пракса ги користиме двата пристапи, но донесовме голем број одлуки за да ни го олесниме животот:

• Во базата на податоци, постојаната состојба на деловниот процес се чува во лесно читлива и лесно обработена форма: во низа со формат 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