BPM stiilis integreerimine

Tere, Habr!

Meie ettevõte keskendub ERP-taseme tarkvaralahenduste väljatöötamisele, kusjuures suurem osa neist lahendustest põhineb suurte äriloogika ja dokumendihaldusega tehingusüsteemidel, nagu näiteks elektroonilised dokumendihaldussüsteemid. Meie toodete kaasaegsed versioonid põhinevad JavaEE tehnoloogiatel, kuid me katsetame ka aktiivselt mikroteenustega. Üks suurimaid väljakutseid sellistes lahendustes on erinevate alamsüsteemide integreerimine, mis kuuluvad seotud domeenidesse. Integreerimisülesanded on meile alati peavalu valmistanud, olenemata meie kasutatavatest arhitektuuristiilidest, tehnoloogiakomplektidest ja raamistikutest, kuid viimastel aegadel on selliste probleemide lahendamisel nähtavad edusammud.

Pakutavas artiklis räägin NPO "Krista" kogemustest ja arhitektuurilistest uurimistest antud valdkonnas. Samuti vaatleme näidet lihtsast lahendusest integreerimisülesandele rakendusprogrammeera perspektiivist ja selgitame välja, mis peitub selle lihtsuse taga.

Vastutusest loobumine

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

Mis seos on BPM-il?

Sellele küsimusele vastamiseks tuleb natuke süveneda meie lahenduste rakendusprobleemide iseloomu. Enamiku meie tüüpilise tehingusüsteemi äri loogikast moodustab andmete sisestamine andmebaasi kasutajaliideste kaudu, nende andmete käsitsi ja automatiseeritud kontrollimine, nende suunamine teatud töövoo kaudu, avaldamine teise süsteemi / analüütilisse baasi / arhiivi, aruannete koostamine. Seega on süsteemi peamine funktsioon tellijate jaoks nende siseäri protsesside automatiseerimine.

Kasutusmugavuse huvides kasutame suhtlemisel mõistet „dokument“ kui teatud andmekogumi abstraktsiooni, mis on seotud ühise võtmega, millele saab „kinni siduda“ teatud töövoo.
Aga kuidas on lood integreerimisloogikaga? Integreerimise ülesanne tekib süsteemi arhitektuurist, mis on jagatud osadeks, mitte tellija soovil, vaid hoopis teiste tegurite mõjul:

• Conway seaduse mõjul;
• varasemate toodete jaoks väljatöödeldud alam-süsteemide taaskasutamise tulemusena;
• arhitekti otsuse tulemusena, lähtudes mittefunktsionaalsetest nõudmistest.

On suur kiusatus eraldada integreerimisloogika põhitegevuse äri loogikast, et mitte reostada äri loogikat integreerimisartefaktidega ja vabastada arendaja vajadusest süüvida süsteemi arhitektuuri eripäradesse. Sellel lähenemisel on mitmeid eeliseid, kuid praktika näitab selle ebaefektiivsust:

• integreerimisprobleemide lahendamine viib tavaliselt kõige lihtsamate lahendusteni, nagu sünkroonilised kutsed, kuna põhitegevuse teostuses on laienduspunktide arv piiratud (sünkroonse integreerimise puudustest – veidi allpool);
• integreerimisartefaktid jõuavad ikkagi põhitegevuse äri loogikasse, kui on vajalik tagasiside teisest alam-süsteemist;
• rakenduse arendaja ignoreerib integreerimist ja võib seda kergesti rikkuda, muutes töövoogu;
• süsteem lakkab olemast terviklik kasutaja vaatepunktist, muutuvad nähtavaks "õmblused" alamsüsteemide vahel, tekivad liigsed kasutaja toimingud, mis käivitavad andmete edastamise ühelt alamsüsteemilt teisele.

Teine lähenemine on integreerivate interaktsioonide käsitlemine kui lahutamatu osa põhiettevõtte loogikast ja töökäigust. Selleks, et rakenduste arendajate kvalifikatsiooninõuded ei tõuseks kosmosesse, tuleks uusi integratsiooni interaktsioone luua lihtsalt ja sujuvalt, võimaldades minimaalset valiku tegemise võimalust. Selle saavutamine on keerulisem, kui tundub: tööriist peab olema piisavalt võimas, et pakkuda kasutajale vajalikku valikut ja samas mitte võimaldada "ennast jalga tulistada". On palju küsimusi, millele insener peab vastama integreetimise ülesannete kontekstis, kuid mille üle rakenduste arendaja oma igapäevases töös mõtlema ei peaks: tehingu piirid, järjepidevus, aatomlikkus, turvalisus, skaleerimine, koormuse ja ressursside jaotus, marsruutimine, maršaldamine, konteksti levitamine ja vahetamine jne. Tuleb pakkuda rakenduste arendajatele piisavalt lihtsaid lahenduste malle, mis sisaldavad juba vastuseid kõikidele sarnastele küsimustele. Need mallid peavad olema piisavalt turvalised: äriloogika muutub väga sageli, mis suurendab vigade tekkimise riski, vigade hind peab jääma piisavalt madalaks.

Aga ikkagi, mis kasu on BPM-ist? On ju olemas palju võimalusi töövoo rakendamiseks...
Tõepoolest, meie lahendustes on väga populaarne teine äri protsesside rakendamine – deklaratiivse ülemineku diagrammi määratlemine ja äriloogika käitlejate ühendamine üleminekute ajal. Selle käigus on olek, mis määratleb "dokumentide" praeguse positsiooni äri protsessis, ise "dokumentide" atribuut.

Nii näeb välja protsess projekti alguses

Sellise rakenduse populaarsus tuleneb suhtelisest lihtsusest ja lineaarsete äri protsesside loomise kiirusest. Kuid pideva tarkvarasüsteemide keerukuse suurenemisega laieneb ja keerukamaks muutub ka automatiseeritud äri protsessi osa. Mõnikord on vajalik dekompositsioon, protsesside osade taaskasutamine ning protsesside hargnemine, et iga haru saaks samaaegselt täidetud. Sellistes tingimustes muutub tööriist ebamugavaks ja olekudiagramm kaotab informatiivsuse (integratsioonimanipulatsioonid ei kajastu diagrammil üldse).

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

Väljapääs sellest olukorrast oli mootori integreerimine jBPM mõnedesse toodetesse, millel on kõige keerukamad äri-protsessid. Lühiajaliselt oli see lahendus teatud edu saavutanud: tekkis võimalus keerukate äri-protsesside rakendamiseks, säilitades samal ajal piisavalt informatiivse ja ajakohase diagrammi BPMN2 vormingus. BPMN2.

Väike osa keerukast äri-protsessist

Pikaajaliselt ei täitnud lahendus ootusi: visuaalsete tööriistade kaudu äri-protsesside loomise kõrge töömaht ei võimaldanud saavutada rahuldavaid tootlikkuse näitajaid, ja ise tööriist muutus arendajate seas üheks kõige vähem armastatuks. Mootori struktuuri kohta oli samuti kriitikat, mis viis paljude "täienduste" ja "toetuste" tekkimiseni.

jBPM-i kasutamise peamine positiivne aspekt on arusaam oma äritegevuse protsessi püsiva oleku olemasolu kasudest ja kahjustustest. Samuti nägime, et protsessipõhise lähenemise kasutamine võimaldab rakendada keerulisi integratsiooniprotokolle erinevate rakenduste vahel, kasutades asünkroonseid suhtlusi signaalide ja sõnumite kaudu. Püsiva oleku olemasolu mängib selles olulist rolli.

Ütlematagi on selge, protsessipõhine lähenemine BPM-stiilis võimaldab meil lahendada laia valikut üha keerulisemate äritegevuse automatiseerimise ülesandeid, harmooniliselt integreerida neid protsesse ja säilitada võimalus visualiseerida teostatud protsessi sobivas nootatsioonis.

Sünkroonsete kõnede puudused kui integratsioonimustrid

Sünkroonne integreerimine tähendab lihtsamat blokeerivat väljakutset. Üks alamsüsteem töötab serveripoolena ja pakub vajalikku meetodit API-s. Teine alamsüsteem töötab kliendipoolena ja kutsub vajalikul hetkel üles ootama vastust. Sõltuvalt süsteemi arhitektuurist võivad kliendi- ja serveripoolsed osad paikneda kas ühes rakenduses ja protsessis või eraldi. Teisel juhul tuleb kasutada mõnda RPC rakendust ning tagada parameetrite ja väljakutse tulemuse marshelinge.

Sellisel integreerimismustril on üsna suur puuduste kogum, kuid seda kasutatakse praktikas laialdaselt tänu selle lihtsusele. Teostamise kiirus on veenev ja sunnib seda korduvalt kasutama «ägedate» tähtaegade tingimustes, kirjutades lahenduse tehnilisse võlga. Samuti juhtub, et kogenematud arendajad rakendavad seda teadmata, lihtsalt ei mõista negatiivseid tagajärgi.

Peale kõige ilmsämiseid alamsüsteemide ühenduvuse suurendamist on ka vähem ilmseid probleeme, mis on seotud tehingute "tükeldamise" ja "venitamisega". Kui ärilogika teeb mingeid muudatusi, siis ei saa tehinguteta hakkama, ja tehingud, omakorda, blokeerivad rakenduse teatud ressursse, mis neid muudatusi mõjutavad. See tähendab, et seni, kuni üks alamsüsteem ootab vastust teiselt, ei suuda see tehingut lõpetada ja blokeeringuid eemaldada. See suurendab märkimisväärselt erinevate efektide tekkimise riski:

• süsteemi reageerimisvõime kaob, kasutajad ootavad pikka aega vastuseid päringutele;
• server lõpetab täielikult vastamise kasutajate päringutele, kuna niidi bassein on ülevoolanud: enamik niite on "seisakusse" sattunud tehingu tõttu blokeeritud ressursside tõttu;
• algavad deadlock'id: nende tekkimise tõenäosus sõltub tugevasti tehingute kestusest, tehingusse kaasatud ärilogikast ja blokeeringutest;
• ilmuvad tehingu ajaületusvead;
• Server "fülleb" OutOfMemory, kui ülesanne nõuab suurte andmemahtude töötlemist ja muutmist, ning sünkrontootmisprotsesside olemasolu teeb väga keeruliseks töötlemise jagamise kergemateks tehinguteks.

Arhitektuurilisest vaatest toob blokeerivate kõnede kasutamine integratsioonis kaasa kontrollimise kaotsimineku üksikute alamsüsteemide kvaliteedi üle: ei ole võimalik tagada ühe alamsüsteemi kvaliteedi sihttasemeid eraldi teise alamsüsteemi kvaliteedi näitajatest. Kui alamsüsteeme arendavad erinevad meeskonnad, on see suur probleem.

Asjad muutuvad veelgi huvitavamaks, kui integreeritavad alamsüsteemid asuvad erinevates rakendustes ja on vaja teha sünkroneeritud muudatusi mõlemalt poolt. Kuidas tagada nende muudatuste tehinguline järjepidevus?

Kui muudatused tehakse eraldi tehingutena, tuleb tagada tõrgete ja kompensatsioonide usaldusväärne töötlemine, mis tühistab täielikult sünkrontootmisprotsesside peamise eelise – lihtsuse.

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

«Saga» kui lahendus tehingute probleemile

Mikroteenuste kasvava populaarsuse tõttu on see muutumas järjest nõutumaks Saga Muster.

See muster lahendab eespool mainitud pikaajaliste tehingute probleeme ning laiendab süsteemi oleku haldamise võimalusi äriloogika poolt: ebaõnnestunud tehingu korral võib kompensatsioon mitte tagasi pöörata süsteemi algsesse seisundisse, vaid tagada alternatiivse andmete töötlemise marsruudi. See võimaldab ka korduvatel katsedel andmete töötlemise samme, millel on positiivne lõpp, mitte uuesti sooritada.

Intrigeeriv on see, et monoliitsetes süsteemides on see muster samuti asjakohane, kui tegemist on halvasti seotud alamsüsteemide integreerimisega ja täheldatakse negatiivseid efekte, mis tulenevad pikaajalistest tehingutest ja vastavatest ressursside lukustustest.

Meie BPM-stiilis äritavade kohaselt on "Saga" rakendamine äärmiselt lihtne: üksikute "Saga" samme saab määratleda tegevustena äriprotsessis ning äriprotsessi püsiv olek määrab ka "Saga" sisemise oleku. See tähendab, et me ei vaja mingeid täiendavaid koordineerimismehhanisme. Ainult sõnumiteenuse pakkujat, millel on "at least once" garantii, on vaja transpordiks.

Kuid ka sellise lahenduse puhul on oma "hind":

• äri loogika muutub keerulisemaks: tuleb arvestada kompensatsioonide töötlemisega;
• tuleb loobuda täiendavast järjepidevusest, mis võib olla eriti tundlik monoliitsete süsteemide puhul;
• veidi keerulisemaks muutub arhitektuur, tekib täiendav vajadus sõnumiteenuse pakkuja järgi;
• vajalikud on täiendavad monitooringu ja haldamise vahendid (kuigi see on tegelikult isegi hea: süsteemi teeninduse kvaliteet paraneb).

Monoliitsüsteemide puhul pole "SAGA" kasutamise mõttekus nii ilmne. Mikroteenuste ja teiste SOA puhul, kus tõenäoliselt on juba olemas vahendaja ning täielik järjepidevus on ohverdatud juba projekti alguses, võib selle malliga töötamise kasu märkimisväärselt ületada puudusi, eriti kui olemas on mugav API äriloogika tasemel.

Äriloogika kapseldamine mikroteenustes

Kui me hakkasime mikroteenustega katsetama, tekkis mõistlik küsimus: kuhu asetada domeeni äriloogika seoses teenustega, mis tagavad domeeni andmete säilimise?

Vaadates erinevate BPMS-ide arhitektuuri, võib tunduda mõistlik eraldada äriloogika persisteerimisest: luua kihte platvormipõhiseid ja domeenist sõltumatuid mikroteenuseid, mis kujundavad keskkonna ja konteineri domeeni äriloogika täitmiseks, ning domeeni andmete persisteerimise korraldada eraldi kihiga lihtsate ja kergete mikroteenuste kaudu. Sel juhul teostavad äriprotsessid persisteerimiskihiga teenuste orkestreerimist.

Selle lähenemise suur eelis on see, et platvormi funktsionaalsust saab pidevalt laiendada ning ainsana suureneb selle tõttu vastava platvormi mikroteenuste kiht. Iga domeeni äriprotsessidel on kohe võimalus kasutada platvormi uut funktsionaalsust, nii kui see on uuendatud.

Täpsem analüüs tõi esile selle lähenemise olulised puudused:

• Platvormiteenus, mis tõlgendab äri loogikat paljude domeenide jaoks, kannab endas suuri riske kui ainus tõrkepunkt. Sage äri loogika muutmine suurendab vigade tekkimise ohtu, mis võivad viia süsteemis laienevate katkemisteni;
• Jõudluse probleemid: äri loogika töötleb oma andmeid kitsaste ja aeglaste liidesega;
  • Andmeid tuleb korduvalt marshaldada ja edastada läbi võrgu kihi;
  • Domeeniteenus annab sageli rohkem andmeid, kui äri loogika töötlemiseks vajalik, kuna välise API teenuse tasemel puuduvad piisavad parameetrite määramise võimalused;
  • Mitu sõltumatut äriüksuse osa võivad uuesti küsida samu andmeid töötlemiseks (seda probleemi saab leevendada sessioonikomponentide lisamisega, mis salvestavad andmeid, kuid see teeb arhitektuuri keerulisemaks ning tekitab andmete ajakohasuse ja vahemälu tühistamise probleeme);
• Tehingu probleemid:
  • Äriprotsessid, millel on püsiv olek, mille salvestamise eest vastutab platvormiteenus, ei ühti domeeniandmetega, ja selle probleemi lihtsaid lahendusi ei paista;
  • Domeeniandmete lukustamise viimine tehingust välja: kui domeeni äriüksusele on vajalik andmete muutmine, tuleb eelnevalt kontrollida, kas andmed on õiged, vältides samal ajal võimalust, et töödeldavaid andmeid muudetakse konkurentsitena. Väline andmelukustus võib aidata probleemi lahendada, kuid sellisel lahendusel on täiendavad riskid ning see vähendab süsteemi üldist usaldusväärsust;
• Täiendavad keerukused uuendamisel: mõnel juhul tuleb säilitamise ja äri loogika teenuseid uuendada sünkroonselt või range järjestuse kohaselt.

Lõppkokkuvõttes tuli tagasipöörduda juurte juurde: kapseldada domeenide andmed ja domeeni äriloogika ühte mikroteenusesse. Selline lähenemine muudab mikroteenuse tajumise tervikliku komponendina süsteemis lihtsamaks ja ei tekita ülaltoodud probleeme. Selle saavutamine ei ole samuti tasuta:

• on vajalik API standardiseerimine äriloogikaga suhtlemiseks (eriti kasutajate tegevuste tagamiseks äriprotsessides) ja platvormiteenuste API-de jaoks; vajatakse tähelepanelikku lähenemist API muutustele, otse ja tagasipidi ühilduvusele;
• on vajalik täiendavate runtime-raamatukogude lisamine äriloogika funktsioneerimise tagamiseks igas sellises mikroteenuses, mis tekitab uued nõudmised nendele raamatukogudele: kerge kaal ja minimaalne sõltuvuste hulk;
• Äriloogika arendajad peavad jälgima teekide versioone: kui mõnda mikroteenust pikka aega ei ole täiustatud, siis on tõenäoliselt seal vananenud teekide versioon. See võib muutuda üllatavaks takistuseks uue funktsiooni lisamisel ja võib nõuda vana äriloogika üleminekut teenuse uutele teekide versioonidele, kui versioonide vahel oli ühilduvusprobleeme.

Sellises arhitektuuris on olemas ka platvormiteenuste kiht, kuid see kiht ei moodusta enam konteinerit domeeni äriloogika täitmiseks, vaid ainult selle keskkonna, pakkudes abifunktsioone. Selline kiht on vajalik mitte ainult domeenipõhiste mikroteenuste kerguse säilitamiseks, vaid ka haldamise tsentraliseerimiseks.

Näiteks genereerivad kasutajate tegevusi äri protsessides ülesanded. Siiski, töötades ülesannetega, peab kasutaja nägema ülesandeid kõigist domeenidest üldnimekirjas, seega peab olema vastav platvormi teenus ülesannete registreerimiseks, mis on puhastatud domeeni äri loogikast. Äri loogika kapseldamise säilitamine sellises kontekstis on piisavalt keeruline ning see on veel üks kompromiss antud arhitektuuris.

Äri protsesside integreerimine rakendusarendaja pilgu läbi

Nagu juba varem öeldud, peab rakendusarendaja olema eraldatud tehnilistest ja inseneritehnilistest aspektidest mitme rakenduse vahelise suhtluse rakendamisel, et saaks loota hea arendustoodangule.

Proovime lahendada piisavalt keerulise integreerimisülesande, mis on spetsiaalselt kirjutatud artikli jaoks. See on "mänguline" ülesanne, kus osaleb kolm rakendust, millest igaühel on oma domeeninimi: "app1", "app2", "app3".

Iga rakenduses käivitatakse äri protsessid, mis hakkavad „palli mängima” kaudu integreerimisbusse. Pallina esindavad sõnumid nimega „Ball”.

Mängureeglid:

• esimene mängija – algataja. Ta kutsub teisi mängijaid mängu, alustab mängu ja võib selle igal hetkel lõpetada;
• teised mängijad kuulutavad oma osaluse mängus, „tutvuvad” üksteisega ja esimese mängijaga;
• palli vastu võtnud mängija valib teise osaleva mängija ja edastab talle palli. Hoitakse arvestust edastuste koguarvu üle;
• igal mängijal on „energia”, mis väheneb iga palli edastamisega selle mängija poolt. Kui energia on otsas, kukub mängija mängust välja, kuulutades oma lahkumise;
• kui mängijast jääb üksi, kuulutab ta kohe lahkumist;
• kui kõik mängijad on mängust välja langenud, kuulutab esimene mängija mängu lõppenuks. Kui ta on varem mängust väljunud, jälgib ta mängu lõpetamist.

Selle ülesande lahendamiseks kasutan meie DSL-i äri protsesside jaoks, mis võimaldab loogikat kompaktsemalt Kotlinis kirjeldada, minimaalse boilerplate'iga.

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

klass AlgneMängija

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 klass protsessi eksemplarist: kapseldab selle sisemist olekut
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 deklaratsioon: luuakse üks kord, kasutatakse kõigi
// 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

    // Tegevuste kuulutamine, millest äri-protsess koosneb
    val sendNewGameSignal = signal("NewGame")
    val sendStopGameSignal = signal("StopGame")
    val startTask = humanTask("Start") {
        taskOperation {
            processCondition { players.size > 0 }
            confirmation { "${players.size} mängijat on ühendatud. Alustame?" }
        }
    }
    val stopTask = humanTask("Stop") {
        taskOperation {}
    }
    val waitPlayerJoin = signalWait("PlayerJoin") { signal ->
        players.add(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... liitus mängijaga ${signal.data} ...")
    }
    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 ehitame protsessi graafiku kuulutatud 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 tegevusele täiendavad töötlajad logimiseks
    sendNewGameSignal.onExit { println("Alustame mängu!") }
    sendStopGameSignal.onExit { println("Lõpp!") }
    sendPlayerOut.onExit { println("$playerName: 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 ettevõtte loogika täitmisele suudab antud kood esitada äriprotsessi objekti mudeli, mida saab visualiseerida diagrammina. Visualiseerijat me veel ellu ei viinud, seega pidime veidi aega kulutama joonistamisele (siin olen ma BPMN-i nomenklatuuri veidi 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ängija käitumist: järgmise mängija valimine toimub ringikaupa algoritmi alusel, mitte juhuslikult.

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}")
}

Muu käitumine mängijal ei erine eelmisest, seega diagramm ei muutu.

Nüüd on vajalik test, et kõik see hankida. TTuletan vaid testikoodi, et mitte artiklit üle koormata boilerplate'iga (tegelikult kasutasin testimisümbrust, mis loodi varem teiste äriprotsesside integreerimise 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 on vaja natuke oodata, kuni mängijad "tuttavaks" saavad.
    // Ootamine sleep'i kaudu - halb lahendus, aga kõige lihtsam. 
    // Ärge tehke seda 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

Võti lock://app1/process/InitialPlayer on blokeeritud
Mängime!
Võti lock://app1/process/InitialPlayer on vabastatud
Mängija2: Olen kohal!
Mängija3: Olen kohal!
Mängija4: Olen kohal!
Mängija5: Olen kohal!
... 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 lahkunud!
Samm 89: Mängija3 >>> Mängija4
... mängija Mängija2 on välja ...
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 lahkunud!
... mängija Mängija4 on välja ...
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 lahkunud!
... mängija Mängija5 on välja ...
Samm 122: Mängija3 >>> Mängija5
Samm 123: Mängija5 >>> Mängija1
Mängija5: Olen lahkunud!
Samm 124: Mängija1 >>> Mängija3
... mängija Mängija5 on välja ...
Samm 125: Mängija3 >>> Mängija1
Samm 126: Mängija1 >>> Mängija3
Mängija1: Olen lahkunud!
... mängija Mängija1 on välja ...
Samm 127: Mängija3 >>> Mängija3
Mängija3: Olen lahkunud!
Samm 128: Mängija3 >>> Mängija3
... mängija Mängija3 on välja ...
Mängija3: Olen lahkunud!
Lõpp!
Samm 129: Mängija3 >>> Mängija3
Mängija3: Olen lahkunud!

Kogu sellest on võimalik teha mitu olulist järeldust:

• vajalike tööriistade olemasolul saavad rakendusarendajad luua rakenduste vahelisi integreerimistegevusi, katkestamata äriloogikat;
• integreerimiste ülesande keerukust (complexity), mis nõuab insenerioskusi, on võimalik peita raamistikku, kui see on algselt arhitektuuri sisse ehitatud. Ülesande raskust (difficulty) ei saa peita, seega keerulise ülesande lahendus koodis näeb vastavalt välja;
• Integratsiooni loogika väljatöötamisel on oluline arvestada eventual consistency ja kõigi integreerimise osaliste oleku muutuste mitte-lineaarsete omadustega. See sunnib loogikat keeruliseks muutma, et see ei sõltuks väliste sündmuste ajalisest järjekorrast. Meie näites peab mängija osalema mängus alles pärast seda, kui ta on väljakuulutamisest teatanud: teised mängijad jätkavad palli edastamist, kuni teave tema lahkumisest jõuab ja töödeldakse kõigi osaliste poolt. See loogika ei tulene mängureeglitest ja on kompromiss valitud arhitektuuri raames.

Järgmine samm on arutada meie lahenduse erinevaid nüansse, kompromisse ja muid aspekte.

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

Kõik integreeritud rakendused töötavad ühise integratsiooniviidikuga, mis on esitatud kui väline vahendaja, üks BPMQueue järjekord — sõnumite jaoks ja üks BPMTopic teema — signaalide (sündmuste) jaoks. Kõik sõnumid ühe järjekorra kaudu suunamine on endas juba kompromiss. Ärilogika tasandil on nüüd võimalik luua nii palju uusi sõnumitüüpe, ilma et oleks vaja süsteemi struktuuri muuta. See on suur lihtsustamine, kuid sellega kaasnevad teatud riskid, mis meie tüüpiliste ülesannete kontekstis ei tundu liiga märkimisväärsed.

Siin on siiski üks nüanss: iga rakendus filtreerib oma sõnumid järjekorrast juba sissepääsu juures oma domeeninime järgi. Domeen võib olla märgitud ka signaalides, kui on vaja piirata signaali „nähavust“ ainult ühele rakendusele. See peaks suurendama viidiku läbilaskevõimet, kuid nüüd peab ärilooming opereerima domeeninimede järgi: sõnumite adresseerimine on kohustuslik, signaalide puhul soovitatav.

Integreerimisviidiku töökindluse tagamine

Töökindlus sõltub mitmest aspektist:

• valitud sõnumivahetaja on arhitektuuri kriitiliselt oluline komponent ja üksik tõrkekoht: see peab olema piisavalt tõrketaluv. Tuleb kasutada ainult ajaliselt tõestatud lahendusi, millel on hea tugi ja suur kogukond;
• on vajalik tagada sõnumivahetaja kõrge kättesaadavus, milleks peab see olema füüsiliselt eraldatud integreeritavatest rakendustest (rakenduste, kus on äriloogika, kõrge kättesaadavuse tagamine on oluliselt keerulisem ja kallim);
• sõnumivahetaja peab tagama „vähemalt kord” kohaletoimetamise garantii. See on hädavajalik nõue integreerimisbusse usaldusväärseks tööks. „Täpselt kord” garanteerimisel ei ole vajadust: äriprotsessid ei ole tavaliselt tundlikud sõnumite või sündmuste korduvate kohaletoimetamiste suhtes, ja erisoovides, kus see on oluline, on lihtsam lisada äriloogikasse täiendav kontroll kui pidevalt kasutada piisavalt „kalleid” garantiisid;
• sõnumite ja signaalide saatmine tuleb hõlmata äriprotsesside ja domeeniandmete oleku muutmisega seotud terviktransaktsiooni. Soovitatav variant on kasutada mustrit Tegevus Outbox, kuid see nõuab andmebaasis täiendavat tabelit ja edastajat. JEE-rakendustes saab seda aspekti lihtsustada kohaliku JTA halduriga, kuid valitud vahendajaga ühendamine peab suudma töötada XA;
• sissetulevate sõnumite ja sündmuste töötlejad peavad samuti töötama äriprotsessi oleku muutmise tehinguga: kui selline tehing tühistatakse, peab ka sõnumi vastuvõtt tühistama;
• sõnumid, mida ei õnnestunud vigade tõttu edastada, tuleb koguda eraldi salvestusse DLQ (Dead Letter Queue). Selleks oleme loonud eraldi platvormi mikroteenuse, mis salvestab sellised sõnumid oma salvestusse, indekseerib need atribuutide järgi (kiireks grupeerimiseks ja otsimiseks) ning pakub API-d vaatamiseks, uuesti saatmiseks sihtkohta, sõnumite kustutamiseks. Süsteemi administraatorid saavad seda teenust kasutada oma veebi liidese kaudu;
• Brokeri seadetes tuleb kohandada korduste arvu ja viivitust edastuste vahel, et vähendada tõenäosust, et sõnumid satuvad DLQ-sse (optimaalsete parameetrite arvutamine on peaaegu võimatu, kuid neid on võimalik katsetades kohandada);
• DLQ ladustamist tuleb pidevalt jälgida ning jälgimisse süsteem peab teavitama süsteemi administraatoreid, et nad saaks kiirelt reageerida, kui tekivad mitte-edastatud sõnumid. See aitab vähendada tekkiva rikke või äri loogika vea 'kahjustuse ala';
• Integreerimispink peab olema ajutise rakenduse puudumise suhtes leige: tellimused teemale peavad olema vastupidavad ning rakenduse domeeninimi peab olema unikaalne, et rakenduse puudumise ajal ei prooviks keegi teine selle teema sõnumeid järjekorrast töödelda.

Äriloogika juhtimise kindlustamine

Ühele ja samale äritsükli eksemplarile võib korraga saabuda mitu sõnumit ja sündmust, mille töötlemine käivitub paralleelselt. Samal ajal peab rakenduse arendajale olema kõik lihtne ja tõrkevaba.

Protsessi äri loogika töötleb igat välissündmust, mis mõjutab seda äritsüklit, eraldi. Sellised sündmused võivad olla:

• äritsükli eksemplari käivitamine;
• kasutaja tegevus, mis on seotud äritsükli sees oleva tegevusega;
• sõnumi või signaali saamine, millele äritsükli eksemplar on allakirjutanud;
• äritsükli eksemplari seadistatud taimeri aktiveerimine;
• juhtiv mõju API kaudu (näiteks protsessi hädapärane katkestamine).

Iga selline sündmus võib muuta äritegevuse protsessi eksemplari olekut: mõned tegevused võivad lõppeda ja teised alata, võib muutuda püsivate omaduste väärtus. Iga tegevuse lõpetamine võib aktiveerida ühe või mitu järgmist tegevust. Need omakorda võivad peatuda teiste sündmuste ootamisel või, kui neid ei vajata täiendavaid andmeid, võivad nad lõpetada samas tehingus. Enne tehingu lõpetamist salvestatakse äritegevuse protsessi uus olek andmebaasi, kus see ootab järgmise välist sündmust.

Äritegevuse protsessi püsivad andmed, mis on salvestatud relatsioonilisse andmebaasi, on väga mugav sümbioosi töötlemise punkt, kui kasutada SELECT FOR UPDATE. Kui ühel tehingul õnnestub saada äritegevuse protsessi olek andmebaasist selle muutmiseks, ei saa ükski teine tehing sama olekut samal ajal teisele muutmiseks saada, ja pärast esimesena lõpetatud tehingut saab teine garanteeritult juba muudetud oleku.

Kasutades andmebaasi serveri poolseid pessimistlikke lukustusi, täidame kõik vajalikud nõuded ACID, samal ajal säilitades rakenduse äriõiguse skaleeritavuse, suurendades käimasolevate instantside arvu.

Kuid pessimistlikud lukustused ähvardavad meid surnud lõksudega, seega tuleks SELECT FOR UPDATE ikkagi mõistlikult ajutiselt piirata, et vältida surnud lõkse äärmuslikes äriõiguse juhtumites.

Veel üks probleem on äriprotsessi käivitamise sünkroniseerimine. Kuni äriprotsessi instants ei ole olemas, pole ka selle olekut andmebaasis, seega ei sobi kirjeldatud meetod. Kui on vajalik tagada äriprotsessi instantsi unikaalsus teatud ulatuses, siis on vajalik mingi sünkroniseerimisobjekt, mis on seotud protsessiklassi ja vastava ulatusega. Selle probleemi lahendamiseks kasutame teistsugust lukustamismehhanismi, mis võimaldab lukustada suvalist ressurssi, määratletud URI formaadis võti, välise teenuse kaudu.

Meie näidetes sisaldab äriprotsess InitialPlayer kuulutust

uniqueConstraint = UniqueConstraints.singleton

Seetõttu logis on sõnumid vastava võtme lukustamise ja vabastamise kohta. Teiste äriuudiste jaoks selliseid sõnumeid ei ole: uniqueConstraint ei ole määratud.

Äriprotsesside probleemid püsiva olekuga

Mõnikord aitab püsiva olekuga toimetamine, kuid samas võib see arenduses ka väga segada.
Probleemid algavad siis, kui on vaja muuta äri loogikat ja/või äri protsessi mudelit. Mitte iga selline muudatus ei osutu vanade äri protsesside seisukohaga ühilduvaks. Kui andmebaasis on palju 'elavaid' eksemplare, siis ühilduvate muudatuste tegemine võib tekitada palju ebameeldivusi, millega oleme sageli silmitsi seisnud jBPM-i kasutamisel.

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

1. luua uue äri protsessi tüübi, et mitte teha vanadesse ühilduvaid muudatusi ja kasutada seda uute eksemplaride käivitamisel vanade asemel. Vanad eksemplarid jätkavad 'vana' järgi töötamist;
2. migreerida äri protsesside püsivat olekut äri loogika ajakohastamisel.

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

• äri loogika dubleerimine paljudes äriprotsesside mudelites, äri loogika mahu suurenemine;
• tihti on vajalik kohene üleminek uuele äriloogikale (integratsioonülesannete puhul – peaaegu alati);
• arendaja ei tea, millal on võimalik eemaldada aegunud mudelid.

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

• andmebaasis säilitatakse äriprotsessi püsiv olek arusaadavas ja kergesti töödeldavas vormis: JSON-formaadis reas. See võimaldab migratsioone nii rakenduse sees kui ka väljaspool. Äärmuslikul juhul saab ka käsitsi kohandada (eriti kasulik arendamise ja tõrkeotsingu ajal);
• integreeritud äri loogika ei kasuta äriprotsesside nimesid, et igal ajal saaks asendada ühe osaleva protsessi rakenduse uue, uue nimega (näiteks „InitialPlayerV2”). Side toimub sõnumite ja signaalide nimede kaudu;
• protsessi mudelil on versiooni number, mida me suurendame, kui teeme sellesse mudelisse ühilduvaid muudatusi, ning see number salvestatakse koos protsessi eksemplari olekuga;
• protsessi püsiv olek loetakse algselt andmebaasist mugavasse objekti mudelisse, millega migreerimisprotseduur saab töötada, kui mudeli versiooni number on muutunud;
• migreerimisprotseduur paikneb äri- loogika lähedal ja kutsutakse välja "lõdvalt" iga äri- protsessi eksemplari jaoks protsessi taastamise hetkel andmebaasist;
• kui on vaja kõigi protsessi eksemplaride olek kiiresti ja sünkroonselt migreerida, rakendatakse klassikalisi lahendusi andmebaasi migreerimiseks, kuid seal tuleb töötada JSON-iga.

Kas on vaja veel ühte äriprotsesside raamistikku?

Artiklis toodud lahendused on aidanud meil oluliselt lihtsustada igapäevaelu, laiendada rakenduste arendamise valdkonda ja muuta äri loogika eraldamise ideed mikroteenusteks atraktiivsemaks. Selle saavutamiseks on tehtud palju tööd, loodud väga "kergekaaluline" raamistik äri protsesside jaoks ning teeninduskomponendid märkidaud probleemide lahendamiseks laias rakenduste valdkonnas. Meil on soov nende tulemusi jagada, tuua üldkomponendid avatud ligipääsu alla vabaks litsentsiks. See nõuab teatud pingutusi ja aega. Arusaam selliste lahenduste nõudlusest võiks olla meile täiendav stiimul. Pakutud artiklis on raamistikule endale väga vähe tähelepanu pööratud, kuid mõningaid võimalusi on näha toodud näidetes. Kui me siiski avaldame oma raamistikku, pühendame sellele eraldi artikli. Samuti oleksime tänulikud, kui jätaksite väikese tagasiside, vastates küsimusele:

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

kas on veel vaja ühte raamistikku äri protsesside jaoks?

• 18,8%jah, oleme ammu otsinud midagi sellist

• 12,5%huvitav teada saada rohkem teie rakenduse kohta, see võib osutuda kasulikuks

• 6,2%kasutame üht olemasolevat raamistikku, kuid kaalume vahetamist

• 18,8%kasutame üht olemasolevat raamistikku, kõik sobib

• 18,8%saame hakkama ilma raamistikuta

• 25,0%kirjutame ise

Hääletas 16 kasutajat. 7 kasutajat jäi erapooletuks.

Allikas: habr.com