BPM-stiilis integreerimine

Tere, Habr!

Meie ettevõte on spetsialiseerunud ERP-taseme tarkvaralahenduste arendamisele, mille suur osa koosneb suurtest tehingusüsteemidest, kus on palju äriloogikat ja dokumendihaldust nagu EDD. Meie tooteid toetavad kaasaegsed JavaEE tehnoloogiad, kuid katsetame aktiivselt ka mikroteenuseid. Üks suurimaid probleemkohti sellistes lahendustes on erinevate all süsteemide integreerimine, mis kuuluvad üksteisega seotud domeenidesse. Integreerimise ülesanded on alati valmistanud meile suurt peavalu, olenemata kasutatud arhitektuuristiilidest, tehnoloogiakogumitest ja raamistikest, kuid viimasel ajal on selliste probleemide lahendamisel toimunud edusamme.

Pakutavas artiklis tutvustan NPO "Krista" kokemusi ja arhitektuurilisi väljakutseid mainitud valdkonnas. Samuti vaatame, kuidas lahendada lihtsat integreerimisteemat rakendus arendaja vaatenurgast ja saame teada, mis selle lihtsuse taga peitub.

Märkus

Artiklis kirjeldatud arhitektuuri- ja tehnilised lahendused põhinevad minu isiklikul kogemusel konkreetsete ülesannete kontekstis. Need lahendused ei pretendeeri universaalsusele ja võivad osutuda ebasobivateks teistes kasutustingimustes.

Kuidas siin BPMiga seondub?

Sellele küsimusele vastamiseks tuleb pisut süveneda meie lahenduste rakenduslike ülesannete spetsiifikat. Suur osa äriloogikast meie tüüpilises tehingusüsteemis hõlmab andmete sisestamist Andmebaasi kasutajaliideste kaudu, nende andmete käsitsi ja automatiseeritud kontrollimist, nende läbiviimist mingisuguste töövoogude kaudu, nende avaldamist teise süsteemi / analüüsibaasi / arhiivi, aruannete koostamist. Seega on süsteemi võtme funktsioon klientide jaoks nende sise äri protsesside automatiseerimine.

Meie mugavuse huvides kasutame kommunikatsioonis mõistet "dokument" kui mingit abstraktsiooni andmekogumist, mis on seotud ühise võtmega, millele saab "siduda" teatud töövoo.
Kuid mis siis integratsiooniloogikaga? Lõppude lõpuks esindab integreerimise ülesanne süsteemi arhitektuuri, mis on jagatud osadeks mitte kliendi nõudmiste järgi, vaid mõjutatud täiesti muudest teguritest:

• Conway seaduse mõjul;
• korduvkasutuse tulemusena, varasemalt teistele toodetele välja töötatud alamsüsteemide;
• arhitekti otsusel, lähtudes mittefunktsionaalsetest nõuetest.

On suur kiusatus eraldada integreerimisloogika peamise töövoo äri loogikast, et mitte saastada äri loogikat integreerimisartefaktide poolt ning vabastada arendaja vajadusest süveneda süsteemi arhitektuuri eripäradesse. Sellel lähenemisel on mitmeid eeliseid, kuid praktika näitab selle ebaefektiivsust:

• integreerimisprobleemide lahendamine jookseb tavaliselt kõige lihtsamateni, milleks on sünkroonsed kutsed, tulenevalt peamise töövoo piiratud laienduspunktidest (sünkroonse integreerimise puudustest – veidi allpool);
• integreerimisartefaktid tungivad ikkagi peamisse äri loogikasse, kui on vajalik tagasiside teisest alamsüsteemist;
• arendaja ignoreerib integreerimist ja võib selle kergesti rikkuda, muutes töövoogu;
• süsteem lõpetab kasutaja silmis ühtsena eksisteerimise, alamsüsteemide vahel on märgatavad "õmblused", millega kaasnevad liigsed kasutaja toimingud, mis algatavad andmete edastamise ühest alamsüsteemist teise.

Teine lähenemine on vaadata integreerimise koostoimeid kui lahutamatut osa peamisest äriloogikast ja töövoost. Et rakendusarendajate kvalifikatsiooninõuded ei tõuseks taevasse, peaks uute integreerimisvõimaluste loomine toimuma kergelt ja vabalt, minimaalsete lahenduste valimise võimalustega. Seda on keerulisem saavutada, kui tundub: tööriist peab olema piisavalt võimas, et anda kasutajale vajalik hulk rakendamise võimalusi, kuid samas ei luba endale „ennast jalga tulistada“. On palju küsimusi, millele insener peab vastama integreerimise ülesannete kontekstis, kuid mille üle ei pea rakendusarendaja igapäevases töös mõtlema: tehingute piirid, järjepidevus, atomaarne olemus, turvalisus, skaleerimine, koormuste ja ressursside jaotamine, marsruutimine, marsaldamine, kontekstide levitamine ja vahetamine jne. Tuleb pakkuda rakendusarendajatele piisavalt lihtsaid lahenduste malli, kuhu on juba peidetud vastused kõikidele sellistele küsimustele. Need mallid peavad olema piisavalt turvalised: äriloogika muutub väga sageli, mis suurendab vigade toimumise riske, vigade hind peab jääma piisavalt madalaks.

Aga mis on BPMi seos sellega? Ju on palju erinevaid töövoo rakendamise võimalusi…
Tõepoolest, meie lahendustes on väga populaarne teine äri­protsesside rakendamise versioon – läbi deklaratiivse olekute ülemineku diagrammi määratlemise ja äriloogika töötlejate ühendamise üleminekutele. Sellega määrab olek, mis määrab „dokumendi” praeguse positsiooni äri­protsessis, ise „dokumendi” atribuudi.

Nii näeb protsess välja projekti alguses

Selle rakenduse populaarsus tuleneb suhtelisest lihtsusest ja kiirusest, millega saab luua lineaarseid äriprotsesse. Kuid programmide süsteemide pideva keerukuse kasvades muutub automatiseeritud osa äriprotsessist mahukamaks ja keerukamaks. Tekkib vajadus dekompositsiooni, protsessi osade uuesti kasutamise ning protsesside harude jagamise järele, et iga haru saaks täidetud samaaegselt. Sellega seoses muutub tööriist ebamugavaks ning olekute diagramm kaotab oma informatiivsuse (integreerimisseosed ei kajastu üldse diagrammil).

Nii näeb protsess välja pärast mitmeid iteratsioone nõudmiste täpsustamiseks

Väljapääs sellest olukorrast oli mootorite integreerimine jBPM teatud toodetesse, kus on kõige keerukamad äriprotsessid. Lühiajalises perspektiivis oli see lahendus teatud edu saavutanud: tekkis võimalus keerukate äriprotsesside elluviimiseks, säilitades samal ajal piisavalt informatiivse ja ajakohase diagrammi BPMN2 tähistuses. Väike osa keerukast äriprotsessist.

Pikaajalises perspektiivis ei õigustanud lahendus ootusi: äriprotsesside loomise kõrge töömahukus visuaalsete tööriistade kaudu ei võimaldanud saavutada vastuvõetavaid tootlikkuse näitajaid ning see tööriist sai üheks kõige vähem armastatuks arendajate seas. Ka mootorite sisemise struktuuri kohta oli kriitikat, mis viis mitmesuguste "plekkide" ja "toega" tekkimiseni.

jBPM rakendamise peamine positiivne aspekt oli teadlikkus oma püsiva seisundi olemasolu kasust ja kahjust äriprotsessi eksemplaris. Samuti nägime võimalust kasutada protsessipõhist lähenemist keerukate integreerimisprotokollide elluviimiseks erinevate rakenduste vahel, rakendades asünkroonseid suhtlusi märkide ja sõnumite kaudu. Püsiva seisundi olemasolu mängib selles olulist rolli.

Käesoleva teabe põhjal võib järeldada:

protsessipõhine lähenemine BPM-i stiilis võimaldab meil lahendada laia valikut ülesandeid, et automatiseerida pidevalt keerukamaid äriprotsesse, harmooniliselt integreerida nendesse protsessidesse integratsioonitegevusi ning säilitada võimalus visuaalselt esitada ellu viidud protsessi sobivas sümboolikas. protsessipõhine lähenemine BPM stiilis võimaldab meil lahendada laia valikut keerukate ärioperatsioonide automatiseerimise ülesandeid, harmooniliselt integreerida neid protsesse integreerimisaktiivsustega ning säilitada võimaluse visualiseerida teostatud protsessi sobivas notationis.

Sünkroonsed kutsed kui integratsioonimuster

Sünkroonne integreerimine tähistab lihtsaimat blokeerivat kutset. Üks alam süsteem tegutseb serveripoolena ja pakub vajaliku meetodi API-d. Teine alam süsteem tegutseb kliendipoolena ning teeb kutse õigele hetkele oodates tulemusi. Sõltuvalt süsteemi arhitektuurist võivad kliendi ja serveri pooled asuda kas ühes rakenduses ja protsessis või erinevates. Teisel juhul on vajalik rakendada teatud RPC teostust ja tagada kutse parameetrite ja tulemuste marshalimine.

Sellel integratsioonimustril on piisavalt suur puuduste kogum, kuid seda kasutatakse praktikas väga laialdaselt oma lihtsuse tõttu. Teostuse kiirus on ahvatlev ja sunnib seda jälle ja jälle rakendama „põletavate” tähtaegade korral, kirjutades lahenduse tehnilisse võlga. Kuid on ka juhtumeid, kui kogenematud arendajad rakendavad seda alateadlikult, lihtsalt ei mõistes negatiivseid tagajärgi.

Peale kõige ilmsemate alamsüsteemide sidususe suurenemise on ka vähem ilmsed probleemid „venitamise” ja „lõhkumise” tehingutega. Tõepoolest, kui äriloogika teeb mingisuguseid muudatusi, siis ei saa tehingutest mööda hiilida, ja tehingud omakorda blokeerivad teatud rakenduse ressursse, mis on nende muudatustega seotud. See tähendab, et kuni üks alam süsteem ei saa teisest vastust, ei saa ta tehingut lõpetada ja blokeeringut eemaldada. See suurendab oluliselt erinevate efektide tekkimise riski:

• süsteemi reageerimine kaob, kasutajad ootavad pikka aega vastuseid päringutele;
• server lõpetab täielikult vastamise kasutajate päringutele, kuna voolu bassein on ületäidetud: enamus voole on „seiskunud” tehingu tõttu blokeeritud ressursil;
• ilmnevad deadlockid: nende ilmumise tõenäosus sõltub tugevalt tehingute kestusest, tehingusse kaasatud äriloogika hulgast ja blokeeringutest;
• ilmnevad tehingu ajaülekande vead;
• server „kukub” OutOfMemory tõttu, kui ülesanne nõuab suurte andmemahtude töötlemist ja muutmist, ning sünkroonsete integreerimiste olemasolu raskendab oluliselt töötlemise jagamist „kergematele” tehingutele.

Arhitektuuri seisukohalt toob blokeerivate väljakutsete kasutamine integreerimisel kaasa üksikute alam-süsteemide kvaliteedi juhtimise kaotamise: on võimatu tagada ühe alam-süsteemi kvaliteedi sihttasemeid, kui need ei ole seotud teiste alam-süsteemide kvaliteedi näitajatega. Kui alam-süsteeme arendavad erinevad meeskonnad, on see suur probleem.

Asjad muutuvad veelgi huvitavamaks, kui integreeritavad alam-süsteemid asuvad erinevates rakendustes ja peab üheaegselt tegema muudatusi mõlemalt poolt. Kuidas tagada nende muudatuste tehingulisus?

Kui muudatusi tehakse eraldi tehingutena, tuleb tagada usaldusväärne erandite töötlemine ja kompensatsioon, mis kaotab täielikult sünkroonsete integratsioonide põhieelise – lihtsuse.

Pähe tulevad ka jaotatud tehingud, kuid me ei kasuta neid oma lahendustes: usaldusväärsuse tagamine on keeruline.

„Saga” kui lahendus tehingute probleemile

Mikroteenuste populaarsuse suurenemisega kasvab ka Saga Muster.

See muster lahendab hästi eespool mainitud pikaajaliste tehingute probleemid, samuti laiendab süsteemi oleku haldamise võimalusi äri loogika poolt: ebaõnnestunud tehingu järelkompensatsioon ei pea süsteemi algseisundisse tagasi viima, vaid võib tagada alternatiivse andmete töötlemise marsruudi. See võimaldab ka edukalt lõpetatud andmete töötlemise samme mitte korrata, kui protsessi püüda viia „head” lõpule.

Huvitav on see, et monoliitsetes süsteemides on see muster samuti aktuaalne, kui tegemist on nõrgalt seotud alam-süsteemide integreerimisega ning pikaajaliste tehingute ja vastavate ressursside blokeeringute negatiivsed mõjud on tõeliselt tuntavad.

Seoses meie BPM-tüüpi äriprotsessidega on „Sagate” rakendamine väga lihtne: eraldi „Saga” etapid võivad olla määratud tegevustena äriprotsessis ning äriprotsessi püsiv olek määrab muu hulgas „Saga” sisemise oleku. See tähendab, et meil ei ole vaja täiendavat koordineerimismehhanismi. Vajalik on vaid sõnumi vaheline broker, millel on „at least once” garantiide tugi transpordina.

Kuid isegi sellel lahendusel on oma „hind”:

• äri loogika muutub keerulisemaks: tuleb töötada hüvitistega;
• on vajalik loobuda täielikust järjepidevusest, mis võib olla eriti tundlik monoliitsetes süsteemides;
• arhitektuur muutub veidi keerulisemaks, tekib täiendav vajadus sõnumite brokera järele;
• vajalikud lisamonitorimise ja haldamise vahendid (kuigi üldiselt on see isegi hea: teenuse kvaliteet paranee).

Monoliitsete süsteemide puhul ei ole «Saga» kasutamise õigustus nii ilmne. Mikroteenuste ja teiste SOA-de puhul, kus tõenäoliselt on juba olemas broker ning täielik järjepidevus on ohverdatud projekti alguses, võib selle mustri kasutamisest saadav kasu oluliselt ületada puudusi, eriti kui olemas on mugav API äri loogika tasandil.

Äri loogika kapseldamine mikroteenustes

Kui me hakkasime katsetama mikroteenustega, tekkis õigustatud küsimus: kuhu paigutada domeeni äri loogika seoses teenusega, mis tagab domeeni andmete püsimise?

Vaadates erinevate BPMS-ide arhitektuuri, võib tunduda mõistlik eraldada äri loogika püsimisest: luua platvormi ja domeeni sõltumatute mikroteenuste kiht, mis moodustab keskkonna ja konteineri domeeni äri loogika täitmiseks, ning korraldada domeeni andmete püsimine eraldi väga lihtsa ja kerge mikroteenuste kihina. Sellisel juhul teevad äri protsessid teenuste orkestrimise püsimise kihile.

Sellel lähenemisel on väga suur eelis: platvormi funktsionaalsust saab lõputult kasvatada, ja «pakseneb» sellest ainult vastav platvormi mikroteenuste kiht. Äri protsessid mis tahes domeenist saavad kohe kasutada platvormi uut funktsionaalsust, niipea kui see on uuendatud.

Rohkem detailsed analüüsid näitasid sellise lähenemise olulisi puudusi:

• platvormi teenus, mis täidab äri loogikat paljude domeenide järele, kannab endas suuri riske kui ainus rikke punkt. Äri loogika sagedased muutused suurendavad vigade tekkimise riski, mis võivad põhjustada süsteemi üle katkestusi;
• jõudlusprobleemid: äri loogika töötab oma andmetega läbi kitsaste ja aeglaste liideste:
  • andmed marsalitakse ja edastatakse veel kord läbi võrgu stacki;
  • domeeniteenused annavad sageli rohkem andmeid, kui äriloogika töötlemiseks vajalik, kuna välise API teenuse päringute parameetrite võimalused on piiratud;
  • mitmed sõltumatud äriloogika osad võivad samaid andmeid töötlemiseks korduvalt küsida (seda probleemi saab leevendada lisades seansikomponente, mis кешируют andmeid, kuid see keerukalt keerab arhitektuuri ja loob andmete aktuaalsuse ja vahemälu kehtetuks muutumise probleeme);
• tehingute probleemid:
  • äriprotsessid püsiva olekuga, mille salvestamise eest vastutab platvormiteenus, on kooskõlastamatud domeeniandmetega, ja lihtsaid lahendusi sellele probleemile ei paista;
  • domeeniandmete lukustamise väljaviimine tehingust: kui domeeni äriloogika vajab muudatusi, tuleb enne kontrollida aktuaalsete andmete kehtivust, et välistada samaaegne muutmine töödeldud andmete. Väliseks andmete lukustamiseks lahendus võib aidata probleemi lahendada, kuid see lahendus toob endaga kaasa täiendavaid riske ja vähendab süsteemi üldist usaldusväärsust;
• täiendavad keerukused uuendamisel: mõningatel juhtudel tuleb säilitamise ja äriloogika teenuseid sünkroonselt või rangelt järjestikku uuendada.

Lõpuks tuli tagasi algusesse: kapseldada domeeniandmed ja domeeni äriloogika ühte mikrosüsteemi. See lähenemine lihtsustab mikrosüsteemi tajumist süsteemi tervikliku koostisosana ja ei tekita eespool mainitud probleeme. See ei ole samuti tasuta:

• vajatakse API standardiseerimist äriloogikaga suhtlemiseks (eriti kasutajate tegevuste tagamiseks äriprotsesside raames) ja platvormiteenuste API-d; on vajalik tähelepanelikum suhtumine API muutmise, otse- ja tagasipöördumise ühilduvusse;
• vajatakse täiendavate runtime-teekide lisamist äri loogika toetamiseks igas sellises mikrosüsteemis, mis toob kaasa uued nõuded nendele teekidele: kerge kaal ja minimaalsete üleminevate sõltuvuste olemasolu;
• Ärimeetodite arendajad peavad jälgima raamatute versioone: kui mõnda mikroteenust ei ole pikka aega arendatud, siis on tõenäoliselt sellel raamatute vanem versioon. See võib muutuda ootamatuks takistuseks uue funktsiooni lisamisel ja võib nõuda vanade äriideede migreerimist teenuse uutele raamatute versioonidele, kui versioonide vahel on olnud ühilduvuse muutusi.

Selles arhitektuuris on ka platvormiteenuste kiht, kuid see kiht ei moodusta domeeni äriideede täitmise konteinerit, vaid vaid selle keskkonna, pakkudes abifunktsioone. Selline kiht on vajalik mitte ainult domeeni mikroteenuste kerguse säilitamiseks, vaid ka juhtimise tsentraliseerimiseks.

Näiteks kasutaja tegevused äri protsessides genereerivad ülesandeid. Kuid töötades ülesannetega, peab kasutaja nägema ülesandeid kõigist domeenidest üldloendis, seega peab olema vastav platvormiteenus ülesannete registreerimiseks, mis on puhastatud domeeni äriideedest. Äriideede kapseldamise säilitamine sellises kontekstis on üsna keeruline ja see on veel üks kompromiss selle arhitektuuri puhul.

Äriprotsesside integreerimine rakenduse arendaja silmade läbi

Nagu eelnevalt mainitud, peab rakenduse arendaja olema abstraktne tehniliste ja inseneritehniliste detailide suhtes, et loota heale arendustootlikkusele.

Proovime lahendada üsna keerulise integreerimisteema, mis on spetsiaalselt välja mõeldud artikli jaoks. See on 'mänguline' ülesanne, kus osalevad kolm rakendust, millest igaühel on oma domeeninimi: 'app1', 'app2', 'app3'.

Iga rakenduse sees käivitatakse äri protsessid, mis hakkavad 'palliga mängima' integreerimisbusse kaudu. Palli rollis on sõnumid nimega 'Ball'.

Mängureeglid:

• esimene mängija – algataja. Ta kutsub teisi mängijaid mängu, alustab mängu ja võib seda igal ajal lõpetada;
• teised mängijad kuulutavad oma osalemisest mängus, 'tutvuvad' üksteisega ja esimese mängijaga;
• palli vastu võtnud mängija valib teise osaleva mängija ja annab talle palli edasi. Peetakse arvestust üldiste edastuste arvu üle;
• iga mängijal on "energia", mis väheneb iga kord, kui see mängija palli edasi annab. Kui energia otsa saab, loobub mängija mängust, tehes selle teatavaks;
• kui mängija jääb üksi, teatab ta kohe loobumisest;
• kui kõik mängijad on mängust eemaldunud, teatab esimene mängija mängu lõpetamisest. Kui ta lahkus varem, peab ta mängu jälgima, et seda lõpetada.

Selle ülesande lahendamiseks kasutan meie äriprotsesside DSL-i, mis võimaldab loogikat Kotlinis kompaktse ja minimaalse boilerplate'iga kirjeldada.

rakenduses app1 töötab esimese mängija äri protsess (kes on mängu algataja):

class 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()

// See klassi protsessi eksemplar: kapseldab selle siseolekud
class InitialPlayer : ProcessImpl(initialPlayerModel) {
    var playerName: String by persistent("Player1")
    var energy: Int by persistent(30)
    var players: PlayersList by persistent(PlayersList())
    var shotCounter: Int = 0
}

// See on protsessi mudeli deklareerimine: loomine toimub üks kord, kasutatakse kõikide
// vastava klassi protsessi eksemplaride poolt
val initialPlayerModel = processModel(name = "InitialPlayer",
                                                     version = 1) {

    // Reeglite kohaselt on esimene mängija mängu algataja ja peab olema ainus
    uniqueConstraint = UniqueConstraints.singleton

    // Deklareerime tegevused, millest koosneb äri-protsess
    val sendNewGameSignal = signal("NewGame")
    val sendStopGameSignal = signal("StopGame")
    val startTask = humanTask("Start") {
        taskOperation {
            processCondition { players.size > 0 }
            confirmation { "Liitus ${players.size} mängijat. Alustame?" }
        }
    }
    val stopTask = humanTask("Stop") {
        taskOperation {}
    }
    val waitPlayerJoin = signalWait("PlayerJoin") { signal ->
        players.add(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... mängija ${signal.data} liitus ...")
    }
    val waitPlayerOut = signalWait("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... mängija ${signal.data} on väljas ...")
    }
    val sendPlayerOut = signal("PlayerOut") {
        signalData = { playerName }
    }
    val sendHandshake = messageSend("Handshake") {
        messageData = { playerName }
        activation = {
            receiverDomain = process.players.last().domain
            receiverProcessInstanceId = process.players.last().id
        }
    }
    val throwStartBall = messageSend("Ball") {
        messageData = { 1 }
        activation = { selectNextPlayer() }
    }
    val throwBall = messageSend("Ball") {
        messageData = { shotCounter + 1 }
        activation = { selectNextPlayer() }
        onEntry { energy -= 1 }
    }
    val waitBall = messageWaitData("Ball") {
        shotCounter = it
    }

    // Nüüd konstrueerime protsessi graafi deklareeritud tegevustest
    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)
    }

    // Lisame tegevustele täiendavad töötlejad logimiseks
    sendNewGameSignal.onExit { println("Alustame mängu!") }
    sendStopGameSignal.onExit { println("Paus!") }
    sendPlayerOut.onExit { println("$playerName: Ma olen väljas!") }
}

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

Lisaks ärilogika täitmisele suudab antud kood genereerida äriprotsessi objekti mudeli, mida saab visualiseerida diagrammina. Visualiseerijat me veel ei ole rakendanud, seetõttu tuli natuke aega joonistamisega tegeleda (siin olen BPMN süntaksit osaliselt lihtsustanud, et parandada diagrammi ühtsust antud koodiga):

Rakendus app2 sisaldab teise mängija äriprotsessi:

class 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()

class RandomPlayer : ProcessImpl(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(name = "RandomPlayer", 
                                                   version = 1) {

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

Diagramm:

Rakenduses app3 muudame mängijat veidi teistsuguseks: järgmise mängija juhusliku valimise asemel järgib ta round-robin algoritmi:

class 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()

class RoundRobinPlayer : ProcessImpl(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(
        name = "RoundRobinPlayer", 
        version = 1) {

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

Muudes osades ei erine mängija käitumine eelmisest, seega diagramm ei muutu.

Nüüd on vaja testi, et seda kõike käivitada. Toome välja ainult testi koodi, et mitte artiklit boorimänguga üle koormata (tegelikult kasutasin ma testikeskkonda, mille olin varem loonud teiste äritegevuste integratsiooni testimiseks):

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");
    // Nüüd tuleb natuke oodata, kuni mängijad "tuttavaks" saavad.
    // Ootamine sleep'i kaudu on halb lahendus, aga kõige lihtsam. 
    // Ärge tehke niimoodi tõsistes testides!
    Thread.sleep(1000);
    // Käivitame mängu, sulgedes kasutaja tegevuse
    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 playerParams(String name, int energy) {
    Map params = new HashMap();
    params.put("playerName", name);
    params.put("energy", energy);
    return params;
}

Käivitame testi, vaatame logi:

konsooli väljund

Lukku võtme lock://app1/process/InitialPlayer on võetud.
Mängime!
Lukku võtme lock://app1/process/InitialPlayer on eemaldatud.
Mängija2: Olen siin!
Mängija3: Olen siin!
Mängija4: Olen siin!
Mängija5: Olen siin!
... liitu mängijaga Mängija2 ...
... liitu mängijaga Mängija4 ...
... liitu mängijaga Mängija3 ...
... liitu mängijaga Mängija5 ...
Samm 1: Mängija1 >>> Mängija3
Samm 2: Mängija3 >>> Mängija5
Samm 3: Mängija5 >>> Mängija3
Samm 4: Mängija3 >>> Mängija4
Samm 5: Mängija4 >>> Mängija3
Samm 6: Mängija3 >>> Mängija4
Samm 7: Mängija4 >>> Mängija5
Samm 8: Mängija5 >>> Mängija2
Samm 9: Mängija2 >>> Mängija5
Samm 10: Mängija5 >>> Mängija4
Samm 11: Mängija4 >>> Mängija2
Samm 12: Mängija2 >>> Mängija4
Samm 13: Mängija4 >>> Mängija1
Samm 14: Mängija1 >>> Mängija4
Samm 15: Mängija4 >>> Mängija3
Samm 16: Mängija3 >>> Mängija1
Samm 17: Mängija1 >>> Mängija2
Samm 18: Mängija2 >>> Mängija3
Samm 19: Mängija3 >>> Mängija1
Samm 20: Mängija1 >>> Mängija5
Samm 21: Mängija5 >>> Mängija1
Samm 22: Mängija1 >>> Mängija2
Samm 23: Mängija2 >>> Mängija4
Samm 24: Mängija4 >>> Mängija5
Samm 25: Mängija5 >>> Mängija3
Samm 26: Mängija3 >>> Mängija4
Samm 27: Mängija4 >>> Mängija2
Samm 28: Mängija2 >>> Mängija5
Samm 29: Mängija5 >>> Mängija2
Samm 30: Mängija2 >>> Mängija1
Samm 31: Mängija1 >>> Mängija3
Samm 32: Mängija3 >>> Mängija4
Samm 33: Mängija4 >>> Mängija1
Samm 34: Mängija1 >>> Mängija3
Samm 35: Mängija3 >>> Mängija4
Samm 36: Mängija4 >>> Mängija3
Samm 37: Mängija3 >>> Mängija2
Samm 38: Mängija2 >>> Mängija5
Samm 39: Mängija5 >>> Mängija4
Samm 40: Mängija4 >>> Mängija5
Samm 41: Mängija5 >>> Mängija1
Samm 42: Mängija1 >>> Mängija5
Samm 43: Mängija5 >>> Mängija3
Samm 44: Mängija3 >>> Mängija5
Samm 45: Mängija5 >>> Mängija2
Samm 46: Mängija2 >>> Mängija3
Samm 47: Mängija3 >>> Mängija2
Samm 48: Mängija2 >>> Mängija5
Samm 49: Mängija5 >>> Mängija4
Samm 50: Mängija4 >>> Mängija2
Samm 51: Mängija2 >>> Mängija5
Samm 52: Mängija5 >>> Mängija1
Samm 53: Mängija1 >>> Mängija5
Samm 54: Mängija5 >>> Mängija3
Samm 55: Mängija3 >>> Mängija5
Samm 56: Mängija5 >>> Mängija2
Samm 57: Mängija2 >>> Mängija1
Samm 58: Mängija1 >>> Mängija4
Samm 59: Mängija4 >>> Mängija1
Samm 60: Mängija1 >>> Mängija4
Samm 61: Mängija4 >>> Mängija3
Samm 62: Mängija3 >>> Mängija2
Samm 63: Mängija2 >>> Mängija5
Samm 64: Mängija5 >>> Mängija4
Samm 65: Mängija4 >>> Mängija5
Samm 66: Mängija5 >>> Mängija1
Samm 67: Mängija1 >>> Mängija5
Samm 68: Mängija5 >>> Mängija3
Samm 69: Mängija3 >>> Mängija4
Samm 70: Mängija4 >>> Mängija2
Samm 71: Mängija2 >>> Mängija5
Samm 72: Mängija5 >>> Mängija2
Samm 73: Mängija2 >>> Mängija1
Samm 74: Mängija1 >>> Mängija4
Samm 75: Mängija4 >>> Mängija1
Samm 76: Mängija1 >>> Mängija2
Samm 77: Mängija2 >>> Mängija5
Samm 78: Mängija5 >>> Mängija4
Samm 79: Mängija4 >>> Mängija3
Samm 80: Mängija3 >>> Mängija1
Samm 81: Mängija1 >>> Mängija5
Samm 82: Mängija5 >>> Mängija1
Samm 83: Mängija1 >>> Mängija4
Samm 84: Mängija4 >>> Mängija5
Samm 85: Mängija5 >>> Mängija3
Samm 86: Mängija3 >>> Mängija5
Samm 87: Mängija5 >>> Mängija2
Samm 88: Mängija2 >>> Mängija3
Mängija2: Olen väljas!
Samm 89: Mängija3 >>> Mängija4
... mängija Mängija2 on väljas ...
Samm 90: Mängija4 >>> Mängija1
Samm 91: Mängija1 >>> Mängija3
Samm 92: Mängija3 >>> Mängija1
Samm 93: Mängija1 >>> Mängija4
Samm 94: Mängija4 >>> Mängija3
Samm 95: Mängija3 >>> Mängija5
Samm 96: Mängija5 >>> Mängija1
Samm 97: Mängija1 >>> Mängija5
Samm 98: Mängija5 >>> Mängija3
Samm 99: Mängija3 >>> Mängija5
Samm 100: Mängija5 >>> Mängija4
Samm 101: Mängija4 >>> Mängija5
Mängija4: Olen väljas!
... mängija Mängija4 on väljas ...
Samm 102: Mängija5 >>> Mängija1
Samm 103: Mängija1 >>> Mängija3
Samm 104: Mängija3 >>> Mängija1
Samm 105: Mängija1 >>> Mängija3
Samm 106: Mängija3 >>> Mängija5
Samm 107: Mängija5 >>> Mängija3
Samm 108: Mängija3 >>> Mängija1
Samm 109: Mängija1 >>> Mängija3
Samm 110: Mängija3 >>> Mängija5
Samm 111: Mängija5 >>> Mängija1
Samm 112: Mängija1 >>> Mängija3
Samm 113: Mängija3 >>> Mängija5
Samm 114: Mängija5 >>> Mängija3
Samm 115: Mängija3 >>> Mängija1
Samm 116: Mängija1 >>> Mängija3
Samm 117: Mängija3 >>> Mängija5
Samm 118: Mängija5 >>> Mängija1
Samm 119: Mängija1 >>> Mängija3
Samm 120: Mängija3 >>> Mängija5
Samm 121: Mängija5 >>> Mängija3
Mängija5: Olen väljas!
... mängija Mängija5 on väljas ...
Samm 122: Mängija3 >>> Mängija5
Samm 123: Mängija5 >>> Mängija1
Mängija5: Olen väljas!
Samm 124: Mängija1 >>> Mängija3
... mängija Mängija5 on väljas ...
Samm 125: Mängija3 >>> Mängija1
Samm 126: Mängija1 >>> Mängija3
Mängija1: Olen väljas!
... mängija Mängija1 on väljas ...
Samm 127: Mängija3 >>> Mängija3
Mängija3: Olen väljas!
Samm 128: Mängija3 >>> Mängija3
... mängija Mängija3 on väljas ...
Mängija3: Olen väljas!
Peatada!
Samm 129: Mängija3 >>> Mängija3
Mängija3: Olen väljas!

Kõigest sellest võib teha mitu olulist järeldust:

• vajadusel vajalikud tööriistad, saavad rakenduse arendajad luua rakenduste vahel integreerivaid suhtlusi ilma äriloogikast lahkumata;
• integreerimise ülesande keerukust, mis nõuab insenerioskusi, saab varjata raamistiku sees, kui see algselt on arhitektuuri sisse ehitatud. Ülesande raskust ei saa varjata, seetõttu näeb keerulise ülesande lahendamine koodis vastavalt välja;
• integreerimisloogika arendamisel tuleb arvesse võtta lõpuks järjepidevust ja kõigi osaliste oleku muutuste mitte-lineaarset käitumist. See sunnib loogikat keerukamaks muutma, et see ei oleks tundlik välistest sündmustest tuleneva esinemisjärjepidevuse suhtes. Meie näites peab mängija hakkama mängus osalema alles pärast seda, kui ta on teatanud mängust lahkumisest: teised mängijad jätkavad palli edastamist, kuni teave tema lahkumisest jõuab ja töödeldakse kõikide osaliste poolt. See loogika ei tulene mängureeglitest ja on kompromisslahendus valitud arhitektuuri raames.

Järgmisena räägime meie lahenduse erinevatest nüanssidest, kompromissidest ja muudest aspektidest.

Kõik sõnumid – ühes järjekorras

Kõik integreeritavad rakendused töötavad ühe integreerimisbusina, mis esindab end välise vahendajana, ühe järjekorra BPMQueue – sõnumite jaoks ja ühe teema BPMTopic – signaalide (sündmuste) jaoks. Kõik sõnumid, mis läbivad ühe järjekorra, on iseenesest kompromiss. Äri-, loogika tasemel on nüüd võimalik täiesti uut tüüpi sõnumeid sissetuua, ilma et peaks muudatusi süsteemi struktuuris tegema. See on märkimisväärne lihtsustamine, kuid sellega kaasnevad teatud riskid, mis meie tüüpiliste ülesannete kontekstis tunduvad meile mitte nii olulised.

Siiski on siin üks nüanss: iga rakendus filtreerib „oma” sõnumid järjekorrast juba sisendiperioodil, oma domeeninime järgi. Domeen võib olla määratud ka signaalides, kui on vaja piirata signaali „näkku” ainult ühe rakendusega. See peaks tõstma busside läbilaskevõimet, kuid äriloogika peab nüüd opereerima domeeninimedega: sõnumite adresseerimisel – kohustuslik, signaalide puhul – soovituslik.

Integreerimisbussi usaldusväärsuse tagamine

Usaldusväärsus koosneb mitmest aspektist:

• valitud sõnumi vahendaja – kriitilise tähtsusega komponent arhitektuuris ja ainus rikkepunkt: see peab olema piisavalt riketekindel. Tuleb kasutada ainult ajaga tõestatud lahendusi, millel on hea tugi ja suur kogukond;
• on oluline tagada sõnumi vahendaja kõrge saadavus, mistõttu peab see olema füüsiliselt eraldatud integreeritud rakendustest (rakenduste kõrge saadavuse tagamine, millel on äriloogika, on märgatavalt keerulisem ja kallim);
• vahendaja peab tagama „at least once” kohaletoimetamise garantii. See on kohustuslik nõue integreerimisbussi usaldusväärseks toimimiseks. „Exactly once” taseme garantiide kasutamine ei ole vajalik: äri protsessid ei ole tavaliselt väga tundlikud sõnumite või sündmuste korduva saabumise suhtes, ja erijuhudes, kus see on oluline, on lihtsam lisada täiendav kontroll äriloogikasse, kui pidevalt kasutada piisavalt „kalleid” garantiisid;
• sõnumite ja signaalide edastamine tuleb kaasata äriprotsesside ja domeendataandete oleku muutmisega seotud üldisesse tehingusse. Eelistatav variant on kasutada mustrit Transactional Outbox, kuid see nõuab andmebaasis lisalaudade olemasolu ja edastajat. JEE-rakendustes saab seda hetke lihtsustada kohaliku JTA halduriga, kuid valitud vahendajaga ühendamine peab suutma töötada XA;
• sisse tulevate sõnumite ja sündmuste töötlejad peavad samuti töötama äriprotsessi oleku muutmise tehinguga: kui selline tehing tühistatakse, tuleb ka sõnumi vastuvõtt tühistada;
• sõnumid, mida ei õnnestunud kohaletoimetada vigade tõttu, tuleb koguda eraldi salvestusse DLQ (Dead Letter Queue). Meie jaoks lõime eraldi platvormi mikroteenuse, mis salvestab sellised sõnumid oma andmehoidlasse, indekseerib need atribuudi alusel (kiire grupeerimise ja otsingu jaoks) ning pakub API-d nende vaatamiseks, uuesti saatmiseks sihtkohta ja sõnumite kustutamiseks. Süsteemi administraatorid saavad seda teenust kasutada oma veebiliidese kaudu;
• brokeeri seadistustes tuleb kohandada edastamise korduste arvu ja viivitusi edastamise vahel, et vähendada sõnumite jõudmise tõenäosust DLQ-sse (optimaalsete parameetrite arvutamine on praktiliselt võimatu, kuid neid saab kohandada empiiriliselt ja kohandada nende kasutuse ajal);
• DLQ andmehoidlat peab pidevalt jälgima ja jälgimisseade peab teavitama süsteemi administraatoreid, et reageerida võimalikult kiiresti, kui ebaõnnestunud sõnumeid ilmneb. See vähendab tekkinud tõrke või äriloogika vea „mõjupiirkonda“;
• integreerimisbuss peaks olema ajutiste rakenduste puudumise suhtes tundetu: tellimused teema suhtes peavad olema püsivad ja rakenduse domeeninimi peab olema ainulaadne, et rakenduse puudumise ajal ei prooviks keegi teine tema sõnumeid järjekorrast töödelda.

Äriloogika vooluahelate tagamine

Sama äriprotsessi eksemplar võib saada korraga mitu sõnumit ja sündmust, mille töötlemine käivitub paralleelselt. Samal ajal peab rakenduse arendaja jaoks olema kõik lihtne ja vooluahelateohutu.

Äriprotsessi äriloogika töötleb iga välist sündmust, mis mõjutab seda äriprotsessi, eraldi. Sellised sündmused võivad olla:

• äriprotsessi eksemplari käivitamine;
• kasutaja tegevus, mis on seotud tegevusega äriprotsessis;
• sõnumi või signaali saabumine, millele äriprotsessi eksemplar on tellitud;
• äriprotsessi eksemplaril seadistatud taimeri aktiveerimine;
• kontrolliv mõju API kaudu (näiteks protsessi erakorraline katkestamine).

Iga selline sündmus võib muuta äriprotsessi instantsi olekut: mõned tegevused võivad lõppeda ja teised alata, püsivaatluste väärtused võivad muutuda. Mis tahes tegevuse lõpetamine võib aktiveerida ühe või mitu järgmist tegevust. Need võivad omakorda peatuda teiste sündmuste ootel või, kui nad ei vaja täiendavaid andmeid, võivad nad lõppeda samas tehingus. Enne tehingu sulgemist salvestatakse uus äriprotsessi olek andmebaasi, kus see ootab järgmise välist sündmuse toimumist.

Äriprotsessi püsivad andmed, salvestatud relatsioonilisse andmebaasi, on väga mugav töötlemise sünkroonimise punkt, kui kasutada SELECT FOR UPDATE. Kui ühe tehingu jooksul suudab äriprotsessi olekut andmebaasist muuta, siis ei saa ühtegi teist tehingut samal ajal saadud olekut teise muutmise jaoks saada, ja pärast esimese tehingu lõpetamist garanteeritakse, et teine saab juba muudetud oleku.

Kasutades pessimistic lukustusi andmebaasi poolel, täidame kõik vajalikud nõuded ACID, samuti säilitame rakenduse äriloogika skaleeritavuse, suurendades käimasolevate instantside arvu.

Kuid pessimistic lukustused ähvardavad meid deadlock'idega, seega tuleks SELECT FOR UPDATE siiski piirata mõistliku ajutise katkestusega, et vältida deadlock'e mõnedes äriloogika äärmuslikes juhtumites.

Veel üks probleem on äriprotsessi käivitamise sünkroniseerimine. Seni, kuni ei ole äriprotsessi instantsi, ei ole ka selle olekut andmebaasis, seega ei sobi kirjeldatud meetod. Kui on vaja tagada äriprotsessi instantsi unikaalsus teatud ulatuses, on vajalik mõni sünkroniseerimise objekt, mis on seotud protsessi klassi ja vastava ulatusega. Selle probleemi lahendamiseks kasutame teistsugust lukustuste mehhanismi, mis võimaldab lukustada mis tahes ressursi, mille võti on määratud URI formaadis, läbi välishoiu.

Meie näidetes äriprotsess InitialPlayer sisaldab välja kuulutamist

uniqueConstraint = UniqueConstraints.singleton

Seetõttu logis on teadetetekstid vastava võtme lukustamise ja vabastamise kohta. Muude äriprotsesside puhul selliseid teadeteteke ei ole: uniqueConstraint ei ole määratud.

Äriprotsesside probleemid püsiva olekuga

Mõnikord on püsiva oleku olemasolu mitte ainult abiks, vaid see segab ka arendust.
Probleemid algavad siis, kui on vaja teha muudatusi äriloogikas ja/või äriprotsessi mudelis. Mitte iga selline muudatus ei osutu ühilduvaks vana äriprotsessi olekuga. Kui andmebaasis on palju "elu" eksemplare, võib kokku sobimatute muudatuste tegemine põhjustada palju ebamugavusi, millega oleme sageli kokku puutunud jBPM-i kasutamisel.

Sõltuvalt muudatuste sügavusest saab tegutseda kahel viisil:

1. luua uus äriprotsessi tüüp, et mitte teha sooja muudatust vanas ja kasutada seda uue käivitamisel vanade asemel. Vanad eksemplarid jätkavad "vana" järgi töötamist;
2. migratsioon püsivat olekut äriprotsesside uuendamisel äriloogikas.

Esimene tee on lihtsam, kuid sellel on oma piirangud ja puudused, näiteks:

• äriloogika dubleerimine paljudes äriprotsessi mudelites, äri loogika mahu suurenemine;
• tihti on vajalik kiire üleminek uuele äriloogikale (integreerimise ülesannete puhul – peaaegu alati);
• arendaja ei tea, millal võib vanad mudelid eemaldada.

Praktikas kasutame mõlemat lähenemist, kuid oleme teinud mitmeid otsuseid, et endale elu lihtsustada:

• andmebaasis säilitatakse äriprotsessi püsiv olek kergesti loetavas ja kergesti töödeldavas vormis: JSON-formaadis rea siseselt. See võimaldab teostada migreerimisi nii rakenduse sees kui ka väljaspool. Äärmuslikel juhtudel saab ka käsitsi kohandada (eriti kasulik arenduse ja silumise ajal);
• integreerimise äriloogika ei kasuta äriprotsesside nimetusi, et igal hetkel saaks asendada ühe osaleva protsessi realiseerimise uuega, uue nimega (näiteks "InitialPlayerV2"). Sidumine toimub teadete ja signaalide nimede kaudu;
• Protsessi mudelil on versiooninumber, mida suurendame, kui teeme sellesse mudelisse ühilduvaid muudatusi, ja see number salvestatakse koos protsessieksemplari olekuga;
• Protsessi püsiv olek loetakse alguses andmebaasist mugavasse objektimudelisse, millega migreerimisprotseduur saab töötada, kui mudeli versiooninumber on muutunud;
• Migreerimisprotseduur asub lähedal äriloogikale ja kutsutakse esile «laisk» igas äriprotsessi eksemplaris selle taastamisel andmebaasist;
• Kui tuleb kiiresti ja sünkroonselt migreerida kõikide protsessi eksemplaride olek, rakendatakse traditsioonilisemaid lahendusi andmebaasi migreerimiseks, kuid seal tuleb töötada JSON-iga.

Kas on vaja veel ühte äriprotsesside raamistikku?

Artiklis kirjeldatud lahendused on andnud meile võimaluse oma elu märgatavalt lihtsustada, laiendada küsimuste ringi, mida saab käsitleda rakenduslikul tasemel, ning muuta äriloogika eraldamise ideed mikroteenustesse atraktiivsemaks. Selleks on tehtud palju tööd, loodud väga „kerge” raamistik äriprotsesside jaoks, samuti teenindavad komponendid nimetatud probleemide lahendamiseks laias rakenduslike ülesannete ringis. Meil on soov jagada neid tulemusi, viia üldkomponentide arendus avatud juurde pääsuga vabade litsentsidega. Selleks on vajalikud teatud pingutused ja aeg. Arusaamine selliste lahenduste nõudmisest võiks olla meie jaoks täiendav stiimul. Soovitatud artiklis on väga vähe tähelepanu pööratud raamistikule endale, kuid mõned selle omadused on nähtavad esitatud näidetest. Kui me siiski oma raamistikku avaldame, siis pühendame sellele eraldi artikli. Seniks oleme tänulikud, kui jätate lühikese tagasiside, vastates küsimusele:

Ainult registreeritud kasutajad saavad küsitluses osaleda. Logige sisse, palun.

Kas on vaja veel ühte äriprotsesside raamistikku?

• 18,8%Jah, oleme kaua otsinud midagi sellist3

• 12,5%On huvitav rohkem teada teie rakendusest, võib-olla läheb vaja2

• 6,2%Kasutame ühte olemasolevat raamistikku, aga kaalume vahetamist1

• 18,8%Kasutame ühte olemasolevat raamistikku, kõik on hea3

• 18,8%Saame ilma raamistikuta hakkama3

• 25,0%Kirjutame oma4

Hääletas 16 kasutajat. Jäid neutraalseks 7 kasutajat.

Allikas: habr.com