Integration i BPM-stil

Hej, Habr!

Vårt företag specialiserar sig på utveckling av ERP-lösningar, där en stor del består av transaktionssystem med en enorm mängd affärslogik och dokumenthantering liknande EDI. Moderna versioner av våra produkter bygger på JavaEE-teknologier, men vi experimenterar också aktivt med mikrotjänster. En av de mest utmanande aspekterna av sådana lösningar är integrationen av olika delsystem som tillhör angränsande domäner. Integrationsuppgifter har alltid varit en stor huvudvärk för oss, oavsett vilka arkitekturstilar, teknologiska stackar eller ramverk vi använder, men på senare tid har det skett framsteg i att lösa sådana uppgifter.

I den här artikeln kommer jag att berätta om erfarenheter och arkitekturinsikter från NPO "Krista" inom det angivna området. Vi kommer också att titta på ett exempel på en enkel lösning på ett integrationsproblem från en tillämpad utvecklares perspektiv och ta reda på vad som döljer sig bakom denna enkelhet.

Disclaimer

De arkitektoniska och tekniska lösningar som beskrivs i artikeln föreslår jag baserat på personlig erfarenhet i kontexten av specifika uppgifter. Dessa lösningar gör anspråk på att inte vara universella och kan visa sig vara suboptimala under andra användningsvillkor.

Vad har BPM med detta att göra?

För att besvara denna fråga behöver vi dyka lite djupare i specifikationen av tillämpningsuppgifterna för våra lösningar. Huvuddelen av affärslogiken i vårt typiska transaktionssystem handlar om att mata in data i databasen via användargränssnitt, manuell och automatiserad verifiering av dessa data, bearbetning genom en viss arbetsflöde, publicering till ett annat system / analytisk databas / arkiv, och rapportgenerering. Därmed är den nyckelfunktion hos systemet för kunderna att automatisera deras interna affärsprocesser.

För vår bekvämlighet använder vi termen "dokument" i kommunikationen som en viss abstraktion av en datamängd som är sammanlänkad med en gemensam nyckel, till vilken ett visst arbetsflöde kan "kopplas".
Men hur ska vi hantera integrationslogiken? Integrationsuppgiften uppstår ju från systemarkitekturen, som är "uppdelad" i delar INTE på kundens begäran, utan under påverkan av helt andra faktorer:

• under påverkan av Conway-lagen;
• som resultat av återanvändningen av delsystem som tidigare har utvecklats för andra produkter;
• enligt arkitektens beslut med hänsyn till icke-funktionella krav.

Det finns en stor frestelse att separera integrationslogik från affärslogik i huvud-arbetsflödet för att undvika att förorena affärslogiken med integrationsartefakter och frigöra den applikationsutvecklare från behovet av att förstå de arkitektoniska landskapets egenskaper. Sådan metodik har sina fördelar, men praktiken visar att den är ineffektiv:

• lösningen på integrationsfrågor rör sig ofta mot de enklaste alternativen i form av synkrona anrop på grund av begränsningen av expansionspunkterna i implementeringen av det huvudsakliga arbetsflödet (om nackdelarna med synkron integration - senare);
• integrationsartefakter tränger sig fortfarande in i den grundläggande affärslogiken när feedback från ett annat delsystem krävs;
• den applikationsutvecklare ignorerar integrationen och kan lätt bryta den genom att ändra arbetsflödet;
• systemet slutar vara en enhet från användarens synvinkel, "skarvar" mellan delsystemen blir tydliga, och det uppstår överflödiga användaroperationer som initierar dataöverföring från ett delsystem till ett annat.

Ett annat tillvägagångssätt är att betrakta integrationsinteraktioner som en oumbärlig del av den grundläggande affärslogiken och arbetsflödet. För att kraven på kompetens hos tillämpade utvecklare inte ska skjuta i höjden måste skapandet av nya integrationsinteraktioner göras enkelt och okomplicerat, med minimi möjliga valmöjligheter för hur problemet kan lösas. Detta är svårare än det verkar: verktyget måste vara tillräckligt kraftfullt för att ge användaren ett nödvändigt antal alternativ för dess tillämpning, samtidigt som det inte får tillåta att man "skjuter sig själv i foten". Det finns många frågor som ingenjören måste besvara i samband med integrationsuppgifter, men som den tillämpade utvecklaren inte bör behöva tänka på i sitt dagliga arbete: gränser för transaktioner, konsistens, atomaritet, säkerhet, skalbarhet, distribution av belastningar och resurser, routning, marshalling, spridning och växling av kontexter, osv. Det behövs tillräckligt enkla lösningsmallar för tillämpade utvecklare som redan döljer svar på alla sådana frågor. Dessa mallar måste vara tillräckligt säkra: affärslogiken förändras mycket ofta, vilket ökar riskerna för fel, och kostnaden för fel bör förbli på en tillräckligt låg nivå.

Men vad har BPM att göra med detta? Det finns ju många alternativ för att implementera arbetsflöden...
Verkligen, i våra lösningar är en annan implementering av affärsprocesser mycket populär – genom deklarativ specifikation av tillståndsövergångsdiagram och anslutning av hanterare med affärslogik vid övergångarna. I detta sammanhang är tillståndet som definierar det aktuella läget för "dokumentet" i affärsprocessen en attribut av själva "dokumentet".

Så här ser processen ut i starten av projektet

Populariteten av denna implementering beror på den relativa enkelheten och hastigheten att skapa linjära affärsprocesser. Men i takt med att mjukvarusystemen ständigt blir mer komplexa växer och kompliceras den automatiserade delen av affärsprocessen. Det uppstår ett behov av dekomposition, återanvändning av delar av processerna, samt förgrening av processerna så att varje gren körs parallellt. Under sådana förhållanden blir verktyget otympligt, och tillståndsdiagrammet förlorar sin informativitet (integrationsinteraktioner återspeglas överhuvudtaget inte i diagrammet).

Så här ser processen ut efter några iterationer av kravutveckling.

Lösningen på denna situation blev integrationen av motorn jBPM i vissa produkter med de mest komplexa affärsprocesserna. På kort sikt hade denna lösning viss framgång: det blev möjligt att implementera komplexa affärsprocesser medan man bibehöll ett tillräckligt informativt och aktuellt diagram i notationen BPMN2.

En liten del av en komplex affärsprocess.

På lång sikt uppfyllde inte lösningen förväntningarna: den höga arbetsinsatsen för att skapa affärsprocesser genom visuella verktyg gjorde det omöjligt att nå acceptabla produktivitetsnivåer, och själva verktyget blev en av de mest ogillade bland utvecklare. Det fanns också klagomål på den interna strukturen hos motorn, vilket ledde till att det förekom många "patchar" och "krångel".

Den främsta positiva aspekten av att använda jBPM blev insikten om fördelarna och nackdelarna med att ha ett eget persistent tillstånd för ett affärsprocess-exemplar. Vi såg också möjligheten att använda den processbaserade ansatsen för att genomföra komplexa integrationsprotokoll mellan olika applikationer med användning av asynkrona interaktioner via signaler och meddelanden. Närvaron av ett persistent tillstånd spelar en avgörande roll i detta.

Baserat på det som sagts kan man dra slutsatsen: den processbaserade ansatsen i stil med BPM gör det möjligt för oss att lösa ett brett spektrum av uppgifter för att automatisera ständigt mer komplexa affärsprocesser, harmoniskt integrera integrationsaktiviteter i dessa processer och bevara möjligheten till visuell representation av den genomförda processen i en lämplig notation.

Nackdelar med synkrona anrop som integrationsmönster

Under synkron integration förstås en enkel blockerande anrop. En delsystem fungerar som server och tillhandahåller ett API med önskad metod. Den andra delen fungerar som klient och utför anropet vid rätt tidpunkt med förväntan på resultatet. Beroende på systemarkitekturen kan klient- och serversidan placeras antingen i samma applikation och process eller i olika. I det senare fallet krävs en viss implementation av RPC och hantering av parametrar samt resultatet av anropet.

Detta integrationsmönster har ett ganska stort antal nackdelar, men det används mycket praktiskt på grund av sin enkelhet. Implementeringshastigheten är tilltalande och får en att använda det gång på gång under "brinnande" deadlines, vilket skapar teknisk skuld. Men det händer också att oerfarna utvecklare använder det omedvetet, utan att förstå de negativa konsekvenserna.

Förutom den mest uppenbara ökningen av kopplingen mellan delsystemen finns det även mindre uppenbara problem med "kastning" och "utdragning" av transaktioner. Om affärslogiken gör några ändringar kan man inte undvika transaktioner, och transaktioner blockerar i sin tur vissa resurser i applikationen som berörs av dessa ändringar. Det betyder att medan ett delsystem väntar på svar från ett annat, kan det inte slutföra transaktionen och frigöra blockeringar. Detta ökar avsevärt risken för olika effekter:

• systemets responsivitet går förlorad, användarna får vänta länge på svar på sina förfrågningar;
• servern slutar helt att svara på användarförfrågningar på grund av en överfull trådpool: de flesta trådarna är "fast" i resursblockeringen som upptas av transaktionen;
• det börjar uppstå dödlägen: sannolikheten för deras uppkomst beror starkt på varaktigheten av transaktionerna, mängden affärslogik som är involverad i transaktionen och blockeringarna;
• det uppstår timeoutfel i transaktionen;
• servern "kraschar" på OutOfMemory om uppgiften kräver att stora datamängder bearbetas och ändras, och förekomsten av synkrona integrationer gör det mycket svårt att dela upp bearbetningen i mer "lättviktiga" transaktioner.

Ur ett arkitektoniskt perspektiv leder användningen av blockerande anrop vid integration till en förlust av kontroll över kvaliteten i enskilda delsystem: det är omöjligt att säkerställa kvalitetsmålen för ett delsystem oberoende av kvalitetsmålen för ett annat delsystem. Om delsystemen utvecklas av olika team är detta ett stort problem.

Det blir ännu mer intressant om de integrerade delsystemen finns i olika applikationer och synkrona förändringar måste göras från två sidor. Hur säkerställer man transaktionalitet av dessa förändringar?

Om förändringar görs i separata transaktioner kommer man att behöva säkerställa tillförlitlig hantering av undantag och kompensation, vilket helt upphäver den främsta fördelen med synkrona integrationer – enkelheten.

Man tänker också på distribuerade transaktioner, men vi använder dem inte i våra lösningar: det är svårt att säkerställa tillförlitlighet.

Saga som lösning på transaktionsproblem

Med den ökande populariteten av mikrotjänster blir Saga-mönstret.

Detta mönster löser utmärkt de ovan nämnda problemen med långa transaktioner, samt utökar möjligheterna att hantera systemets tillstånd från affärslogikens sida: kompensation efter en misslyckad transaktion kan ge en alternativ väg för databehandling istället för att återställa systemet till sitt ursprungliga tillstånd. Detta gör det också möjligt att inte upprepa framgångsrikt avslutade steg i databehandlingen vid försök att föra processen till ett 'bra' slut.

Intressant nog är detta mönster också relevant i monolitiska system, om det handlar om integration av svagt kopplade delsystem och negativa effekter observeras som orsakas av långa transaktioner och motsvarande resurslåsningar.

Tillämpat på våra affärsprocesser i BPM-stil visar det sig att implementera Saga är mycket enkelt: enskilda steg i Saga kan definieras som aktiviteter inom affärsprocessen, och det persistenta tillståndet för affärsprocessen definierar bland annat det interna tillståndet för Sagan. Det vill säga, vi behöver inget ytterligare koordineringsmekanism. Vi behöver bara en meddelandebroker med stöd för 'at least once'-garantier som transport.

Men även en sådan lösning har sitt 'pris':

• Affärslogiken blir mer komplex: det behövs kompenserande åtgärder;
• Det kommer att krävas avstående från fullständig konsistens, vilket kan vara särskilt känsligt för monolitiska system;
• Arkitekturen blir något mer komplex, och det uppstår ett ytterligare behov av en meddelandebroker;
• Det kommer att behövas ytterligare övervaknings- och administrationsverktyg (även om detta faktiskt är positivt: kvaliteten på systemtjänsten kommer att förbättras).

För monolitiska system är det inte så självklart att använda 'Sagas'. För mikrotjänster och andra SOA, där det troligtvis redan finns en broker och fullständig konsistens har offrats redan från början av projektet, kan nyttan av att använda denna mall kraftigt överväga nackdelarna, särskilt om det finns ett bekvämt API på affärslogiknivå.

Inkaplsering av affärslogik i mikrotjänster

När vi började experimentera med mikrotjänster uppstod den rimliga frågan: var ska den domänspecifika affärslogiken placeras i förhållande till tjänsten som tillhandahåller persistent domändata?

Vid en titt på arkitekturen hos olika BPMS kan det verka rimligt att separera affärslogik från persistens: skapa ett lager av plattforms- och domänoberoende mikrotjänster som formar en miljö och container för exekvering av den domänspecifika affärslogiken, medan persistensen av domändata utformas som ett separat lager av mycket enkla och lättviktiga mikrotjänster. Affärsprocesser kommer i detta fall att orchestrera tjänsterna i persistenslagret.

En sådan ansats har en stor fördel: man kan utöka plattformens funktionalitet hur mycket man vill, och det enda som kommer att bli 'tyngre' är det motsvarande lagret av plattformsmikrotjänster. Affärsprocesser från vilken domän som helst får omedelbart möjlighet att använda den nya funktionaliteten i plattformen, så snart den uppdateras.

En mer detaljerad genomgång avslöjade betydande nackdelar med detta tillvägagångssätt:

• Den plattformstjänst som kör affärslogik för flera domäner utgör en stor risk som en enhetlig felpunkt. Frekventa förändringar av affärslogik ökar risken för fel som kan leda till störningar som sprider sig över hela systemet;
• Prestandaproblem: affärslogiken arbetar med sina data genom ett smalt och långsamt gränssnitt:
  • data kommer att gå igenom nätverksstacken ytterligare en gång;
  • domänservicen kommer ofta att leverera mer data än vad affärslogiken behöver för behandling, på grund av otillräckliga möjligheter för parametrisering av frågor på nivån för den externa API-tjänsten;
  • flera oberoende delar av affärslogiken kan repetera begäran på samma data för behandling (denna problematik kan mildras genom att lägga till sessionskomponenter som cachelagrar data, men detta komplicerar ytterligare arkitekturen och skapar problem med datakonsistens och cacheinvalidation);
• transaktionalitetsproblem:
  • affärsprocesser med ett kvarhållande tillstånd, vars lagring hanteras av plattformstjänsten, kommer att vara i osynk med domändata, och inga enkla lösningar på detta problem förväntas;
  • att flytta låsning av domändata utanför transaktionen: om den domänspecifika affärslogiken behöver göra ändringar efter att ha verifierat aktuella data, måste möjligheten för konkurrerande ändringar av de hanterade uppgifterna uteslutas. Extern datalåsning kan hjälpa till att lösa problemet, men en sådan lösning medför ytterligare risker och minskar det totala systemets tillförlitlighet;
• ytterligare svårigheter med uppdateringar: i vissa fall måste uppdatera persistensservicen och affärslogiken ske synkront eller i strikt sekvens.

Till slut var vi tvungna att gå tillbaka till grunderna: att kapsla in domändata och domänspecifik affärslogik i en mikroservice. Denna metod underlättar uppfattningen av mikroservicen som en helhet inom systemet och genererar inte de ovan nämnda problemen. Detta kommer dock inte utan kostnad:

• det krävs standardisering av API:er för interaktion med affärslogiken (särskilt för att stödja användaraktiviteter inom affärsprocesser) och API:er för plattformstjänster; ett mer noggrant förhållningssätt till förändringar i API:er, direkt och bakåtkompatibilitet krävs;
• det behöver läggas till extra runtime-bibliotek för att säkerställa att affärslogiken fungerar inom varje sådan mikroservice, och detta ger upphov till nya krav för dessa bibliotek: låg vikt och minimala transitberoenden;
• Utvecklare av affärslogik måste hålla koll på versionerna av biblioteken: om en mikrotjänst inte har uppdaterats på länge, finns det en stor sannolikhet att den har en föråldrad version av biblioteken. Detta kan bli en oväntad hinder vid tillägg av nya funktioner och kan kräva att den gamla affärslogiken migreras till nya versioner av biblioteken om det har skett inkompatibla förändringar mellan versionerna.

Lagret av plattformstjänster i en sådan arkitektur finns också, men detta lager skapar inte längre en behållare för att köra den domänspecifika affärslogiken, utan snarare enbart dess omgivning, som erbjuder stödjande "plattform"-funktioner. Ett sådant lager är behövligt för att inte bara bevara lättvikten hos domänmikrotjänsterna, utan också för att centralisera hanteringen.

Till exempel skapar användaraktiviteter i affärsprocesser uppgifter. Men när användaren arbetar med uppgifter måste han eller hon se uppgifter från alla domäner i en gemensam lista, vilket innebär att det måste finnas en motsvarande plattformstjänst för registrering av uppgifter, som är ren från domänspecifik affärslogik. Att behålla inkapseringen av affärslogiken i detta sammanhang är tillräckligt problematiskt, och detta är ytterligare en kompromiss i denna arkitektur.

Integrering av affärsprocesser ur ett applikationsutvecklares perspektiv

Som nämnts tidigare måste applikationsutvecklaren vara abstraherad från de tekniska och ingenjörsmässiga detaljerna i implementeringen av interaktionen mellan flera applikationer för att kunna räkna med god utvecklingsproduktivitet.

Låt oss försöka lösa en ganska svår integrationsuppgift, avsiktligt skapad för denna artikel. Detta kommer att vara en "spel"-uppgift med tre applikationer där var och en av dem definierar ett visst domännamn: "app1", "app2", "app3".

Inom varje applikation startas affärsprocesser som börjar "spela boll" genom en integrationsbuss. I rollen som bollen kommer meddelanden med namnet "Ball" att fungera.

Spelregler:

• den första spelaren – initiativtagaren. Han eller hon bjuder in de andra spelarna till spelet, startar spelet och kan avsluta det när som helst;
• de andra spelarna anmäler sitt deltagande i spelet, och "lär känna" varandra samt den första spelaren;
• när han eller hon tar emot bollen, väljer spelaren en annan deltagande spelare och överför bollen till honom eller henne. Det hålls en räkning på det totala antalet överföringar;
• Varje spelare har "energi" som minskar med varje passning av bollen från den spelaren. När energin tar slut, lämnar spelaren spelet och meddelar sin avsked;
• om spelaren är ensam kvar, meddelar han om sin avsked genast;
• När alla spelare har lämnat, meddelar den första spelaren att spelet är över. Om han har lämnat tidigare, stannar han kvar för att övervaka spelet och avsluta det.

För att lösa denna uppgift kommer jag att använda vår DSL för affärsprocesser, som låter oss beskriva logik i Kotlin på ett kompakt sätt med minimalt med boilerplate.

I appen app1 kommer affärsprocessen för den första spelaren (som också är initiativtagaren till spelet) att köras:

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

// Detta är klass av processinstans: den inkapslar dess interna tillstånd
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
}

// Detta är deklarationen av processmodellen: den skapas en gång, används av alla
// instanser av processens motsvarande klass
val initialPlayerModel = processModel(name = "InitialPlayer",
                                                     version = 1) {

    // Enligt reglerna är den första spelaren initiativtagare av spelet och måste vara den enda
    uniqueConstraint = UniqueConstraints.singleton

    // Vi deklarerar aktiviteterna som affärsprocessen består av
    val sendNewGameSignal = signal("NewGame")
    val sendStopGameSignal = signal("StopGame")
    val startTask = humanTask("Start") {
        taskOperation {
            processCondition { players.size > 0 }
            confirmation { "${players.size} spelare har anslutit. Börjar vi?" }
        }
    }
    val stopTask = humanTask("Stop") {
        taskOperation {}
    }
    val waitPlayerJoin = signalWait("PlayerJoin") { signal ->
        players.add(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... spelare ${signal.data} ansluter ...")
    }
    val waitPlayerOut = signalWait("PlayerOut") { signal ->
        players.remove(PlayerInfo(
                signal.data!!,
                signal.sender.domain,
                signal.sender.processInstanceId))
        println("... spelare ${signal.data} är ute ...")
    }
    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
    }

    // Nu bygger vi processen av de deklarerade aktiviteterna
    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)
    }

    // Vi knyter extra hanterare till aktiviteterna för loggning
    sendNewGameSignal.onExit { println("Låt oss spela!") }
    sendStopGameSignal.onExit { println("Stopp!") }
    sendPlayerOut.onExit { println("$playerName: Jag är ute!") }
}

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

Förutom att utföra affärslogik kan den givna koden generera en objektmodell av affärsprocessen, som kan visualiseras i form av ett diagram. Vi har ännu inte implementerat visualiseringen, så jag fick lägga ner lite tid på att rita (här har jag förenklat BPMN-notationen när det gäller användning av grindar, för att förbättra överensstämmelsen mellan diagrammet och den givna koden):

Applikationen app2 kommer att inkludera affärsprocessen för en annan aktör:

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

Diagram:

I applikationen app3 kommer vi att ge spelaren lite annat beteende: istället för att slumpmässigt välja nästa spelare kommer den att agera enligt round-robin-algoritmen:

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

I övrigt skiljer sig spelarens beteende inte från det tidigare, så diagrammet förändras inte.

Nu behövs ett test för att köra allt detta. Jag kommer bara att ange koden för själva testet, för att inte överbelasta artikeln med boilerplate (i själva verket använde jag testmiljön som skapades tidigare för att testa integrationen av andra affärsprocesser):

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");
    // Nu behöver vi vänta lite så att spelarna "lär känna" varandra.
    // Att vänta med sleep är en dålig lösning, men den är den enklaste.
    // Gör inte så i seriösa tester!
    Thread.sleep(1000);
    // Startar spelet, stänger av användaraktiviteten
    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ör testet, kolla loggen:

konsolutdata

Låsning av nyckel lock://app1/process/InitialPlayer har tagits bort
Låt oss spela!
Låsning av nyckel lock://app1/process/InitialPlayer har tagits bort
Spelare 2: Jag är här!
Spelare 3: Jag är här!
Spelare 4: Jag är här!
Spelare 5: Jag är här!
... gå med spelare Spelare 2 ...
... gå med spelare Spelare 4 ...
... gå med spelare Spelare 3 ...
... gå med spelare Spelare 5 ...
Steg 1: Spelare 1 >>> Spelare 3
Steg 2: Spelare 3 >>> Spelare 5
Steg 3: Spelare 5 >>> Spelare 3
Steg 4: Spelare 3 >>> Spelare 4
Steg 5: Spelare 4 >>> Spelare 3
Steg 6: Spelare 3 >>> Spelare 4
Steg 7: Spelare 4 >>> Spelare 5
Steg 8: Spelare 5 >>> Spelare 2
Steg 9: Spelare 2 >>> Spelare 5
Steg 10: Spelare 5 >>> Spelare 4
Steg 11: Spelare 4 >>> Spelare 2
Steg 12: Spelare 2 >>> Spelare 4
Steg 13: Spelare 4 >>> Spelare 1
Steg 14: Spelare 1 >>> Spelare 4
Steg 15: Spelare 4 >>> Spelare 3
Steg 16: Spelare 3 >>> Spelare 1
Steg 17: Spelare 1 >>> Spelare 2
Steg 18: Spelare 2 >>> Spelare 3
Steg 19: Spelare 3 >>> Spelare 1
Steg 20: Spelare 1 >>> Spelare 5
Steg 21: Spelare 5 >>> Spelare 1
Steg 22: Spelare 1 >>> Spelare 2
Steg 23: Spelare 2 >>> Spelare 4
Steg 24: Spelare 4 >>> Spelare 5
Steg 25: Spelare 5 >>> Spelare 3
Steg 26: Spelare 3 >>> Spelare 4
Steg 27: Spelare 4 >>> Spelare 2
Steg 28: Spelare 2 >>> Spelare 5
Steg 29: Spelare 5 >>> Spelare 2
Steg 30: Spelare 2 >>> Spelare 1
Steg 31: Spelare 1 >>> Spelare 3
Steg 32: Spelare 3 >>> Spelare 4
Steg 33: Spelare 4 >>> Spelare 1
Steg 34: Spelare 1 >>> Spelare 3
Steg 35: Spelare 3 >>> Spelare 4
Steg 36: Spelare 4 >>> Spelare 3
Steg 37: Spelare 3 >>> Spelare 2
Steg 38: Spelare 2 >>> Spelare 5
Steg 39: Spelare 5 >>> Spelare 4
Steg 40: Spelare 4 >>> Spelare 5
Steg 41: Spelare 5 >>> Spelare 1
Steg 42: Spelare 1 >>> Spelare 5
Steg 43: Spelare 5 >>> Spelare 3
Steg 44: Spelare 3 >>> Spelare 5
Steg 45: Spelare 5 >>> Spelare 2
Steg 46: Spelare 2 >>> Spelare 3
Steg 47: Spelare 3 >>> Spelare 2
Steg 48: Spelare 2 >>> Spelare 5
Steg 49: Spelare 5 >>> Spelare 4
Steg 50: Spelare 4 >>> Spelare 2
Steg 51: Spelare 2 >>> Spelare 5
Steg 52: Spelare 5 >>> Spelare 1
Steg 53: Spelare 1 >>> Spelare 5
Steg 54: Spelare 5 >>> Spelare 3
Steg 55: Spelare 3 >>> Spelare 5
Steg 56: Spelare 5 >>> Spelare 2
Steg 57: Spelare 2 >>> Spelare 1
Steg 58: Spelare 1 >>> Spelare 4
Steg 59: Spelare 4 >>> Spelare 1
Steg 60: Spelare 1 >>> Spelare 4
Steg 61: Spelare 4 >>> Spelare 3
Steg 62: Spelare 3 >>> Spelare 2
Steg 63: Spelare 2 >>> Spelare 5
Steg 64: Spelare 5 >>> Spelare 4
Steg 65: Spelare 4 >>> Spelare 5
Steg 66: Spelare 5 >>> Spelare 1
Steg 67: Spelare 1 >>> Spelare 5
Steg 68: Spelare 5 >>> Spelare 3
Steg 69: Spelare 3 >>> Spelare 4
Steg 70: Spelare 4 >>> Spelare 2
Steg 71: Spelare 2 >>> Spelare 5
Steg 72: Spelare 5 >>> Spelare 2
Steg 73: Spelare 2 >>> Spelare 1
Steg 74: Spelare 1 >>> Spelare 4
Steg 75: Spelare 4 >>> Spelare 1
Steg 76: Spelare 1 >>> Spelare 2
Steg 77: Spelare 2 >>> Spelare 5
Steg 78: Spelare 5 >>> Spelare 4
Steg 79: Spelare 4 >>> Spelare 3
Steg 80: Spelare 3 >>> Spelare 1
Steg 81: Spelare 1 >>> Spelare 5
Steg 82: Spelare 5 >>> Spelare 1
Steg 83: Spelare 1 >>> Spelare 4
Steg 84: Spelare 4 >>> Spelare 5
Steg 85: Spelare 5 >>> Spelare 3
Steg 86: Spelare 3 >>> Spelare 5
Steg 87: Spelare 5 >>> Spelare 2
Steg 88: Spelare 2 >>> Spelare 3
Spelare 2: Jag är ute!
Steg 89: Spelare 3 >>> Spelare 4
... spelare Spelare 2 är ute ...
Steg 90: Spelare 4 >>> Spelare 1
Steg 91: Spelare 1 >>> Spelare 3
Steg 92: Spelare 3 >>> Spelare 1
Steg 93: Spelare 1 >>> Spelare 4
Steg 94: Spelare 4 >>> Spelare 3
Steg 95: Spelare 3 >>> Spelare 5
Steg 96: Spelare 5 >>> Spelare 1
Steg 97: Spelare 1 >>> Spelare 5
Steg 98: Spelare 5 >>> Spelare 3
Steg 99: Spelare 3 >>> Spelare 5
Steg 100: Spelare 5 >>> Spelare 4
Steg 101: Spelare 4 >>> Spelare 5
Spelare 4: Jag är ute!
... spelare Spelare 4 är ute ...
Steg 102: Spelare 5 >>> Spelare 1
Steg 103: Spelare 1 >>> Spelare 3
Steg 104: Spelare 3 >>> Spelare 1
Steg 105: Spelare 1 >>> Spelare 3
Steg 106: Spelare 3 >>> Spelare 5
Steg 107: Spelare 5 >>> Spelare 3
Steg 108: Spelare 3 >>> Spelare 1
Steg 109: Spelare 1 >>> Spelare 3
Steg 110: Spelare 3 >>> Spelare 5
Steg 111: Spelare 5 >>> Spelare 1
Steg 112: Spelare 1 >>> Spelare 3
Steg 113: Spelare 3 >>> Spelare 5
Steg 114: Spelare 5 >>> Spelare 3
Steg 115: Spelare 3 >>> Spelare 1
Steg 116: Spelare 1 >>> Spelare 3
Steg 117: Spelare 3 >>> Spelare 5
Steg 118: Spelare 5 >>> Spelare 1
Steg 119: Spelare 1 >>> Spelare 3
Steg 120: Spelare 3 >>> Spelare 5
Steg 121: Spelare 5 >>> Spelare 3
Spelare 5: Jag är ute!
... spelare Spelare 5 är ute ...
Steg 122: Spelare 3 >>> Spelare 5
Steg 123: Spelare 5 >>> Spelare 1
Spelare 5: Jag är ute!
Steg 124: Spelare 1 >>> Spelare 3
... spelare Spelare 5 är ute ...
Steg 125: Spelare 3 >>> Spelare 1
Steg 126: Spelare 1 >>> Spelare 3
Spelare 1: Jag är ute!
... spelare Spelare 1 är ute ...
Steg 127: Spelare 3 >>> Spelare 3
Spelare 3: Jag är ute!
Steg 128: Spelare 3 >>> Spelare 3
... spelare Spelare 3 är ute ...
Spelare 3: Jag är ute!
Stopp!
Steg 129: Spelare 3 >>> Spelare 3
Spelare 3: Jag är ute!

Av detta kan vi dra flera viktiga slutsatser:

• med nödvändiga verktyg kan applikationsutvecklare skapa integrationsinteraktioner mellan applikationer utan att avbryta affärslogiken;
• komplexiteten av integrationsuppgiften, som kräver ingenjörskompetens, kan döljas inom ramen för ett ramverk om det initialt är inbyggt i ramverkets arkitektur. Svårighetsgraden av uppgiften går inte att dölja, så lösningen på en svår uppgift i koden kommer att se ut därefter;
• vid utveckling av integrationslogik är det nödvändigt att ta hänsyn till eventual consistency och avsaknaden av linjärisering av tillståndsförändringar hos alla deltagare i integrationen. Detta tvingar oss att komplicera logiken för att göra den okänslig för ordningen av yttre händelser. I vårt exempel måste spelaren delta i spelet först efter att han har anmält sin avgång från spelet: andra spelare kommer fortsätta att passera bollen till honom, tills informationen om hans avgång når och behandlas av alla deltagare. Denna logik följer inte reglerna för spelet utan är en kompromisslösning inom den valda arkitekturen.

Vi kommer nu att diskutera olika detaljer kring vår lösning, kompromisser och andra aspekter.

Alla meddelanden – i en kö

Alla integrerade applikationer arbetar med en gemensam integrationsbuss, som representeras av en extern mäklare, en kö BPMQueue – för meddelanden och en topic BPMTopic – för signaler (händelser). Att skicka alla meddelanden genom en enda kö är i sig en kompromiss. På affärslogiknivå kan det nu introduceras hur många nya typer av meddelanden som helst utan att behöva ändra systemets struktur. Detta är en betydande förenkling, men det medför vissa risker som i kontexten av våra typiska uppgifter inte verkade särskilt betydande.

Det finns dock en viktig detalj: varje applikation filtrerar bort "sina" meddelanden från kön redan vid ingången, baserat på sitt domännamn. Domänen kan också anges i signalerna om det är nödvändigt att begränsa signalens "synområde" till en enda applikation. Detta bör öka bussens kapacitet, men affärslogiken måste nu hantera domännamn: för adressering av meddelanden - obligatoriskt, för signaler - önskvärt.

Säkerställande av tillförlitligheten för integrationsbussen

Tillförlitlighet består av flera delar:

• den valda meddelandebrokaren - en kritiskt viktig komponent i arkitekturen och en enhetlig felpunkt: den måste vara tillräckligt felresistent. Endast beprövade implementationer ska användas, med bra stöd och ett stort community;
• det är nödvändigt att säkerställa hög tillgänglighet för meddelandebrokaren, för vilket den måste vara fysiskt separat från de integrerade applikationerna (det är betydligt svårare och dyrare att säkerställa hög tillgänglighet för applikationer med affärslogik);
• brokaren måste säkerställa "at least once" leveransgarantier. Detta är ett obligatoriskt krav för att integrationsbussen ska fungera på ett tillförlitligt sätt. Det finns inget behov av garantier på nivån "exactly once": affärsprocesser är vanligtvis inte känsliga för att meddelanden eller händelser återkommer, och i särskilda uppgifter där detta är viktigt, är det enklare att lägga till en extra kontroll i affärslogiken än att ständigt använda tillräckligt "dyra" garantier;
• meddelande- och signalöverföringar bör involveras i den gemensamma transaktionen med förändringar i affärsprocessernas och domänens data. Det föredragna alternativet är att använda mönstret Transactional Outbox, men det kräver en extra tabell i databasen och en retranslator. I JEE-applikationer kan detta förenklas med användning av en lokal JTA-hanterare, men anslutningen till den valda brokaren måste kunna fungera i läget XA;
• behandlare för inkommande meddelanden och händelser måste också fungera med transaktionen för förändring av affärsprocessens status: om en sådan transaktion ångras, bör även mottagandet av meddelandet avbrytas;
• meddelanden som inte kunde levereras på grund av fel ska lagras i ett separat förråd DLQ (Dead Letter Queue). Vi har skapat en separat plattformsmikrotjänst för detta ändamål som lagrar sådana meddelanden i sitt lager, indexerar dem baserat på attribut (för snabb gruppering och sökning) och erbjuder ett API för att visa, återbeställa till destinationsadressen och ta bort meddelanden. Systemadministratörer kan använda denna tjänst genom sitt webbgränssnitt;
• I brokerinställningarna måste antalet leveransförsök och fördröjningarna mellan leveranser justeras för att minska risken för att meddelanden hamnar i DLQ (det är praktiskt taget omöjligt att beräkna optimala parametrar, men man kan agera empiriskt och justera dem under drift);
• DLQ-lagringen måste övervakas kontinuerligt, och övervakningssystemet ska meddela systemadministratörer för att snabbt reagera på eventuella otillförlitliga meddelanden. Detta kommer att minska "skadans omfattning" av det uppkomna felet eller affärslogikfelet;
• Integrationsbussen ska vara okänslig för tillfällig frånvaro av applikationer: prenumerationer på ämnet måste vara hållbara, och applikationens domännamn måste vara unikt så att inga andra försöker behandla dess meddelanden i kön under dess frånvaro.

Säkerställande av trådsäkerhet för affärslogik

En och samma förekomst av affärsprocessen kan snart ta emot flera meddelanden och händelser som kommer att behandlas parallellt. Samtidigt måste allt vara enkelt och trådsäkert för applikationsutvecklaren.

Affärslogiken i processen hanterar varje extern händelse som påverkar denna affärsprocess för sig. Sådana händelser kan vara:

• starta en instans av affärsprocessen;
• åtgärd från användaren som rör aktiviteten inom affärsprocessen;
• mottagande av ett meddelande eller signal som förekomsten av affärsprocessen är prenumererad på;
• utlösning av en timer som ställts in av affärsprocessens instans;
• kontrollerande påverkan via API (t.ex. en nödstopp av processen).

Varje sådant event kan förändra tillståndet för en instans av affärsprocessen: vissa aktiviteter kan avslutas och andra kan påbörjas, de persistenta egenskaperna kan ändras. Avslutningen av vilken aktivitet som helst kan leda till aktiverandet av en eller flera efterföljande aktiviteter. Dessa kan i sin tur stanna kvar och vänta på andra händelser eller, om de inte kräver några ytterligare data, avslutas i samma transaktion. Innan transaktionen avslutas sparas det nya tillståndet för affärsprocessen i databasen, där det kommer att vänta på att den nästa externa händelsen inträffar.

De persistenta affärsprocessdata som sparas i en relationsdatabas är en mycket praktisk synkroniseringspunkt för bearbetning, om man använder SELECT FOR UPDATE. Om en transaktion lyckas hämta tillståndet för affärsprocessen från databasen för att ändra det, kan ingen annan transaktion parallellt hämta samma tillstånd för en annan ändring, och efter att den första transaktionen har avslutats kommer den andra garanterat att få det redan ändrade tillståndet.

Genom att använda pessimiska låsningar på databassidan uppfyller vi alla nödvändiga krav ACID, samtidigt som vi bibehåller möjligheten att skala applikationen med affärslogik genom att öka antalet körande instanser.

Men pessimistiska låsningar riskerar att leda till dödlägen, vilket innebär att SELECT FOR UPDATE ändå borde begränsas med en rimlig timeout för att hantera situationer med dödlägen i tydliga fall i affärslogiken.

Ett annat problem är synkronisering av starten av affärsprocessen. Så länge det inte finns någon instans av affärsprocessen, finns det inte heller något tillstånd i databasen, så den beskrivna metoden är inte tillämplig. Om unikhet för instansen av affärsprocessen i ett visst omfattning behövs, krävs det ett synkroniseringsobjekt kopplat till processklass och motsvarande omfattning. För att lösa detta problem använder vi en annan mekanism för låsning som tillåter att ta lås på en godtycklig resurs, angiven med en nyckel i URI-format, via en extern tjänst.

I våra exempel innehåller affärsprocessen InitialPlayer en deklaration

uniqueConstraint = UniqueConstraints.singleton

Därför finns det meddelanden i loggen om att låsningen av den aktuella nyckeln tas och frigörs. Det finns inga sådana meddelanden för andra affärsprocesser: uniqueConstraint är inte angiven.

Problem med affärsprocesser som har ett persistent tillstånd

Ibland hjälper ett persistent tillstånd inte bara, utan kan även vara mycket besvärligt för utvecklingen.
Problem uppstår när det behövs förändringar i affärslogiken och/eller affärsprocessmodellen. Inte alla sådana ändringar är kompatibla med det gamla tillståndet i affärsprocesserna. Om det finns många 'levande' instanser i databasen kan införandet av inkompatibla ändringar orsaka mycket besvär, som vi ofta stött på vid användning av jBPM.

Beroende på hur djupa ändringarna är, kan man agera på två sätt:

1. skapa en ny typ av affärsprocess för att undvika inkompatibla ändringar i den gamla, och använda den istället för den gamla när nya instanser startas. De gamla instanserna kommer att fortsätta fungera 'som vanligt';
2. migrera det persistenta tillståndet i affärsprocesserna när affärslogiken uppdateras.

Den första vägen är enklare, men har sina begränsningar och nackdelar, till exempel:

• duplicering av affärslogik i många modeller av affärsprocesser, ökad volym av affärslogik;
• det krävs ofta en omedelbar övergång till den nya affärslogiken (i fråga om integrationsuppgifter – nästan alltid);
• utvecklaren vet inte när man kan ta bort föråldrade modeller.

I praktiken använder vi båda tillvägagångssätten, men vi har vidtagit åtgärder för att förenkla vårt arbete:

• i databasen lagras det persistenta tillståndet för affärsprocessen i ett lättläst och bearbetbart format: i JSON-format. Detta möjliggör migrationer både inom och utanför applikationen. I nödfall kan man även justera manuellt (särskilt användbart under utveckling och felsökning);
• integrationsaffärslogiken använder inte namn på affärsprocesser, så att man när som helst kan byta implementeringen av en av de deltagande processerna till en ny, med ett nytt namn (till exempel 'InitialPlayerV2'). Kopplingen sker genom namnen på meddelanden och signaler;
• Processmodellen har ett versionsnummer som vi ökar om vi gör inkompatibla ändringar i denna modell, och detta nummer sparas tillsammans med tillståndet för processinstansen;
• Det persistenta tillståndet för processen läses först från databasen till en bekväm objektmodell som migrationsproceduren kan arbeta med om versionsnumret har ändrats;
• Migrationsproceduren placeras bredvid affärslogiken och anropas "lat" för varje instans av affärsprocessen vid dess återställning från databasen;
• Om det är nödvändigt att migrera tillståndet för alla processinstanser snabbt och synkront, tillämpas mer klassiska lösningar för databas-migrering, men där måste man arbeta med JSON.

Behöver vi en ytterligare ramverk för affärsprocesser?

De lösningar som beskrivs i artikeln har gjort det möjligt för oss att avsevärt förenkla vårt arbete, utöka mängden frågor som kan lösas på applikationsutvecklingsnivå och göra idéerna om att separera affärslogik i mikrotjänster mer attraktiva. Mycket arbete har lagts ner för detta, en mycket "lättviktig" ramverk för affärsprocesser har skapats, liksom hjälpkomponenter för att lösa de angivna problemen i ett brett sammanhang av applikationsuppgifter. Vi har en önskan att dela dessa resultat, få utvecklingen av gemensamma komponenter tillgänglig som öppen källkod under en fri licens. Detta kommer att kräva vissa ansträngningar och tid. Förståelsen för efterfrågan på sådana lösningar skulle kunna bli ett ytterligare incitament för oss. I den föreslagna artikeln ges mycket lite uppmärksamhet åt möjligheterna hos själva ramverket, men några av dem är synliga från de presenterade exemplen. Om vi ändå publicerar vårt ramverk kommer det att ägnas en separat artikel. Tills dess vore vi tacksamma om ni kunde lämna en liten feedback genom att svara på frågan:

Endast registrerade användare kan delta i omröstningen. Logga in, tack.

Behöver vi en ytterligare ramverk för affärsprocesser?

• 18,8%Ja, vi har länge letat efter något liknande.

• 12,5%Intressant att få veta mer om er implementering, kanske blir det användbart.

• 6,2%Vi använder ett av de befintliga ramverken, men överväger att byta.

• 18,8%Vi använder ett av de befintliga ramverken, allt är okej.

• 18,8%Vi klarar oss utan ramverk.

• 25,0%Vi skriver vårt eget.

16 användare har röstat. 7 användare har avstått.

Källa: habr.com