5 min att läsa

Automatisering av affärsprocesser med Camunda: feltolerant implementering av BPM-system

BPMN

Företag

Comunda

Spring Boot

I dagens digitalt drivna värld krävs strömlinjeformade och effektiva affärsprocesser för att behålla en konkurrensfördel. Automation framstår som en viktig lösning för att uppnå detta. Enligt Statista är marknaden för hantering av affärsprocesser (BPM) förväntas att nå en storlek på 14,4 miljarder US-dollar år 2025. Den ökande populariteten och efterfrågan på BPM-verktyg som Camunda, känt för sin flexibilitet och skalbarhet, vittnar om denna trend. När företag söker pålitliga verktyg för att optimera sin verksamhet framstår Camunda som en föregångare som banar väg för innovativa, feltoleranta automatiseringslösningar i branschen.

Vad är Camunda?

Enkelt uttryckt är Camunda en open source-plattform för automatisering av arbetsflöden och beslut som sammanför affärsanvändare och mjukvaruutvecklare. Genom sin robusta uppsättning verktyg och funktioner erbjuder Camunda sätt att designa, implementera och optimera BPMN-arbetsflöden (Business Process Model and Notation), vilket gör affärsverksamheten smidigare och mer transparent.

Camunda, Spring Boot & BPMN: att förstå begreppen

Tre viktiga aktörer har omformat landskapet för hantering av affärsprocesser: Camunda, Spring Boot och BPMN. Var och en har skapat sin egen nisch och erbjuder unika funktioner som hanterar olika aspekter av processhantering. Men när de kombineras förvandlas de till ett oöverträffat kraftpaket som kan revolutionera digitala företagsverksamheter.

Camunda: Detta är inte bara ytterligare ett verktyg i den stora BPM-verktygslådan; det är en höjdare. Camunda är en robust plattform med öppen källkod som är specialiserad på automatisering av arbetsflöden och beslut. Dess primära mål? Att sömlöst sammanfoga affärsstrategernas och mjukvaruutvecklarnas världar. Genom att göra det säkerställer det att konceptualisering, design och implementering av affärsprocesser är effektiva, transparenta och sammanhängande.

Spring Boot: Spring Boot tar styrkan i Fjäderramen och höjer dem. Genom att erbjuda en strömlinjeformad metod för att bygga fristående Java har det blivit go-to För utvecklare som vill minimera standardkod och dyka rakt in i hjärtat av projektspecifika funktioner. Dess kraft ligger i dess flexibilitet och dess konvention-över-konfigurationsmetod, som kämpar för tanken på smarta standardinställningar. Detta tillvägagångssätt gör det möjligt för utvecklare att bygga skalbara applikationer snabbare, vilket garanterar snabb leverans och konsekvent prestanda.

BPMN: Om vi skulle personifiera BPMN skulle det vara affärsvärldens vältaliga lingvist. Som en globalt erkänd standard tillhandahåller BPMN en visuell vokabulär för att utarbeta affärsprocesser, vilket gör dem lättförståeliga för ett brett spektrum av intressenter. Detta universella språk säkerställer att de tekniska nyanserna i en process kan dechiffreras av både den tekniskt kunniga kodaren och affärsstrategen, vilket främjar samarbetsdialoger och mer välgrundat beslutsfattande.

Synergin mellan Camundas automatiseringsmöjligheter, Spring Boots enkla utveckling och BPMN:s standardiserade notation ger företagen en dynamisk trippel. Tillsammans säkerställer de att BPM-system övergår från enbart teoretiska konstruktioner på papper till handlingskraftiga, verkliga implementeringar. Slutmålet? Att odla affärsprocesser som är smidiga, motståndskraftiga och perfekt anpassade till de föränderliga kraven i det moderna digitala företagslandskapet.

Grundläggande komponenter i BPMN

För dem som inte känner till BPMN är det viktigt att förstå dess grundläggande komponenter. Dessa komponenter utgör grunden för alla BPMN-diagram.

Evenemang

Dessa signalerar något som händer under en process. Händelser kan starta, avbryta eller avsluta ett flöde, och de representeras ofta som cirklar.

Portar

Gateways hanterar beslutsfattandet inom processen. Baserat på förhållandena styr de flödet i processen, vanligtvis illustrerat som diamanter.

Verksamhet

Aktiviteter representerar arbete som utförs. De kan vara uppgifter eller delprocesser och visas som rundade rektanglar.

Anslutande objekt

Dessa element, inklusive sekvensflöden, meddelandeflöden och associationer, illustrerar sekvensen av processer och flödet av meddelanden.

Simbanor

Dessa kategoriserar BPMN-element antingen efter roll (t.ex. chef, revisor) eller system (t.ex. ett ERP-system).

Artefakter

Dessa ger ytterligare information om processen. Vanliga artefakter är dataobjekt, grupper och anteckningar.

För- och nackdelar med Camunda

Som med alla tekniska lösningar innebär Camunda en blandning av fördelar och utmaningar. Här är en omfattande genomgång av dess för- och nackdelar.

Proffs:

Flexibel och enkel integration med Java-applikationer genom Spring Boot.
Ett intuitivt modelleringsgränssnitt för BPMN 2.0.
Ger detaljerad analys av processmått.

Kons:

Kan ha en brantare inlärningskurva för icke-tekniska användare.
Det är en stark startpunkt, men tänk på det som bara basen - även om Camunda är en kraftfull arbetsflödesmotor kommer du fortfarande att behöva ytterligare mjukvaruutveckling.

Effektivisering av överbelastade BPMN-diagram

Tuff verklighet

Camunda är utformat för att få utvecklare och analytiker att tala samma språk, men ofta kommer verkligheten emellan.

Mikrotjänster misslyckas, användare matar in felaktiga data, allt kan hända. I det här fallet börjar det vackra analytiska diagrammet utsmyckas med olika felhanterare, loggar och alternativa vägar. Analytikern utformar ett vackert, kortfattat och begripligt schema. Det har ett fåtal delegater och ger logiska vägar för processflödet under olika omständigheter. Så här ser ett provisoriskt schema ut när det hamnar i händerna på en utvecklare:

Det finns dock nackdelar. Ett sådant system kan innehålla en kort uppgiftsbeskrivning, som "kontrollera kunden", vilket innebär flera steg, beslutsfattande baserat på varje resultat och sammanställning av de härledda besluten till ett enda resultat, eventuellt med efterföljande överföring av detta resultat till externa system.

Det är tydligt att felhanterare, loggar och tekniska serviceelement vid denna tidpunkt visas på diagrammet eller i koden. På så sätt blir en "analytisk" uppgift i Java-implementeringen omfattande och komplex, eller så ökar antalet steg i schemat, var och en åtföljd av hanterare och alternativa vägar. Som ett resultat blir systemet snabbt invecklat, svårt att få ytterligare stöd för och modifiera, och att lägga till ny funktionalitet kan innebära att ett stort område av både systemet och delegatkoden måste omstruktureras. I grund och botten innehåller det ett stort antal identiska element.

Så här kan det tidigare systemet se ut i en verklig driftsättning:

Det är uppenbart att systemet har utvidgats och blivit mer omständligt. Men det finns fördelar: alla uppgifter har blivit atomära, och grenar av beteende i händelse av fel har uppstått.

Att inse problemet

Om vi försöker separera och kapsla in schemat och affärslogiken i Java-koden, kan vi göra följande:

Undvik att duplicera liknande element i systemet.
Använd en universell och återanvändbar implementering av delegater i Java-koden.
Optimera och påskynda flödet i processen.
Förenkla hanteringen av tekniska fel och etablera en logik för processbeteende när de uppstår - nästan utan inblandning av Java-kod. Detta kommer att avsevärt förenkla felsökning och manuell analys av misslyckade processer som är i en incident.
Drastiskt minska antalet processer som "hamnar" i incidenter när tekniska undantag uppstår.
Lägga en solid grund för vidare utveckling.

För att göra det enklare att arbeta med produkten är det bättre att dela upp systemet i atomära uppgifter, minska den totala volymen av systemelement, minska antalet servicehandlers, minska volymen av Java-kod för varje delegat och återanvända universella delegater och genomföra omedelbar refactoring när det behövs. Allt detta innebär automatiskt att man måste skriva enhetstester för alla delegater och processens huvudvägar.

Nedbrytning och atomisering

Om man tittar närmare på processapplikationen och analyserar dess noder kan man se många repetitiva funktioner: frågor till externa system, loggning, felhantering, skicka callbacks osv. Med andra ord måste man kritiskt granska processapplikationen och identifiera objekt i den som enkelt kan kapslas in... Men i vad? I Java-kod? Nej, det vore ologiskt, eftersom systemet i så fall skulle vara nära knutet till sin Java-implementering. I den här situationen är det vettigt att överväga processpooler.

En processpool är ett schema för en separat process som kommer att ha sitt eget sammanhang. Det är anmärkningsvärt att det är bekvämt att extrahera atomära bitar av funktionalitet från huvudprocessen till sådana pooler, liksom alla repetitiva moment: skicka meddelanden, förfrågningar till externa system etc.

Det kan finnas många processpooler, och det skulle vara logiskt att gruppera dem tematiskt. Till exempel förfrågningar till en viss mikrotjänst, alerting, skicka olika notifieringar. Interaktion mellan sådana pooler kan enkelt sättas upp med hjälp av Camunda messaging. Varje gång en sådan pool anropas i Camunda-motorn skickas ett visst meddelande som innehåller en villkorlig rubrik och det överordnade processnumret för att returnera ett svar, samt en uppsättning nödvändiga data för driften av denna specifika lilla pool.

Här ser vi hur huvudprocessen (längst ned) skickar ett meddelande som startprocessen i en annan pool prenumererar på. När händelsen inträffar startar den andra poolen en ny instans av processen, gör en förfrågan och skickar ett svar tillbaka till huvudprocessen, varefter den slutförs framgångsrikt. Under denna tid väntar huvudprocessen på svarshändelsen från den externa pool som den skickade en begäran till. När meddelandet anländer fortsätter processen. Om det inte kommer något svar inom det angivna tidsintervallet förstår processen att den externa beräkningen inte är tillgänglig eller har misslyckats, och avslutas.

Vad detta erbjuder:

Möjlighet till återanvändning av kod. Om du behöver anropa samma kod flera gånger under olika förhållanden i hela processen kan du helt enkelt skapa specifika meddelanden och anropa motsvarande atomära processpooler;
Inkapsling av programvarans implementeringsschema från dess affärsrepresentation. Det spelar ingen roll hur huvudschemat kommer att omformas, eller vilka vägar processen kommer att ta. Alla interaktioner har redan flyttats till separata mindre processer, vilket ger fullständig flexibilitet: formulera bara en begäran och vänta på ett svar.
Antalet och sannolikheten för att huvudprocessen kraschar minskar avsevärt. Före en sådan uppdelning var processen i en osäkerhet på 4 stater:
Svaret har kommit.
Svaret kom inte eftersom den externa mikrotjänsten kraschade.
Svaret kom inte eftersom huvudprocessen kraschade när begäran skickades.
Svaret kom inte eftersom en timeout överskreds.

Med denna uppdelning befinner sig processen alltid i ett strikt enskilt tillstånd: antingen kom svaret, eller så väntade processen och avslutades. För företag spelar det roll exakt hur processen avslutades: om det var ett fel eller inte. Men detta kommer att vara en korrekt slutsats, inte en incident. Detta är viktigt eftersom en process som inte fastnar i en incident inte "förbrukar" resurser, och fel kan enkelt loggas, statistik samlas in, varningar skapas och analyseras.

Det spelar inte längre någon roll vad som händer med de mindre processerna. De kan göra vad de vill: krascha, köra... Det är bara resultatet som är viktigt: svaret från den externa resursen. Och inte alltid, eftersom huvudprocessen inte bör garantera att externa system fungerar. Det kan till exempel vara meningslöst att processen väntar på ett svar från mikrotjänsten för aviseringar, eftersom det kan hända att det inte kommer något svar alls.
Komplexiteten i huvudprocessen reduceras kraftigt. Komplex logik kan distribueras mellan separata små pooler, som är lättare att felsöka. Till exempel kan klientverifiering se ut ungefär så här:

Här kan vi se att flera uppgifter anropas samtidigt i den externa poolen. Låt oss gå djupare in på denna punkt.

Parallellisering av processberäkningar

Camunda möjliggör samtidig exekvering av grenar av processberäkningar. För detta ändamål finns det en speciell gateway som kallas Parallel Gateway, med vilken flödet kan delas upp i paralleller eller för att slå samman flera parallella beräkningar till en ström. Det är uppenbart att det skulle vara fördelaktigt att delegera vissa uppgifter till parallella trådar för att påskynda flödet i en process. Om logiken är oberoende kan den exekveras parallellt, till exempel genom att göra samtidiga förfrågningar till externa system och vänta på svar från alla på en gång:

Varje gång vid en sådan gateway kommer det att finnas overheadkostnader i samband med att skapa nya trådar för uppgiftsfördelning och slå samman resultaten. Man kan stöta på olika låsningsundantag, och det är naturligtvis inte alltid nödvändigt eller motiverat att alltid agera på detta sätt, särskilt inte utan testning, men fördelarna är uppenbara.

Vid sekventiell exekvering är den totala exekveringstiden lika med summan av exekveringstiderna för varje operation. Vid parallell exekvering är den däremot lika med exekveringstiden för den längsta operationen. Med tanke på att svar från externa källor inte kommer omedelbart, att försök måste göras om och att fel kan uppstå, är denna skillnad långt ifrån obetydlig. En annan obestridlig fördel är formen av "fria försök", dvs. medan den längsta begäran utförs har de andra uppgifterna hypotetiskt möjlighet att misslyckas flera gånger och försöka göra om sina åtgärder utan att påverka den totala tiden för utförandet av uppgiften.

Undantag och upprepningsförsök

Pank? Det kan hända. Den färdiga versionen av Camunda har förmågan att försöka igen en misslyckad transaktion. Med "transaktion" menar vi Camundas interna mekanism för att exekvera delegatkod. Starten på en transaktion kan till exempel vara "async before" eller "async after" markören på en uppgift i modelleraren. När motorn stöter på denna markör committar den sin information till databasen och startar en ny asynkron tråd. Detta är viktigt. För att gå djupare, med "transaktion" menar vi exekveringsavsnittet mellan anropen till metoden .complete() i TaskService, följt av registrering av information till databasen. Dessa transaktioner, liksom andra, är atomära.

När ett tekniskt undantag uppstår, dvs. ett fel som inte har med verksamheten att göra, t.ex. att man dividerar med noll och glömmer en null-kontroll, gör transaktionen en rollback och försöker börja om från början. Som standard görs detta tre gånger i följd utan några pauser. Ett nytt försök startar när ett vanligt undantag uppstår, vilket i BPMN-världen kallas för ett tekniskt undantag, inte ett BpmnError. Ett uppkommet BpmnError stoppar processen utan några nya försök. Föreställ dig hur detta ökar processens motståndskraft.

Det är vettigt att maximera denna funktion. Därför sätts dessa markörer på varje delegat som begär ett externt system och anger antalet försök och pausen mellan dem, och i delegatkoden separeras logik för när processen ska avslutas och när den inte ska avslutas. Det ger full kontroll över mekanismerna för undantagshantering och omförsök. Som ett resultat försöker processen att göra om den misslyckade uppgiften flera gånger, och först efter en serie misslyckanden producerar den ett fel.

Den kanske största utmaningen är hanteringen av tekniska undantag och BPMN-relaterade fel, samt att utforma logiken för hanteringen av dessa för ett kontinuerligt flöde av processen. Vi har redan diskuterat några fel relaterade till hantering av svar från externa källor när vi talade om att dela upp i processpooler. Vi vill påminna dig om att själva anropet kapslades in i en separat miniprocess, och att huvudprocessen antingen fick ett svar och fortsatte eller, på grund av en timeout, följde rutten "Jag fick inget svar".

Låt oss nu titta på den mycket lilla processen:

Ser du ramen? Det är en underprocess. Den innehåller specifika uppgifter och fångar upp fel som orsakas av interna uppgifter. På sådana ramar kan jobbutföraren dessutom skapa ett jobb för timern, som anger exekveringstiden för allt som finns i underprocessen.

Hur går det till? Exekveringsflödet når subprocessen, skapar parallell timerbearbetning och väntar antingen på att det som finns inuti ska slutföras eller, om timern tar slut först, följer den timervägen. Om ett undantag uppstår under processen, som fångas upp av subprocessens ram, stoppar processen exekveringen på den aktuella grenen och följer felgrenen.

Det är också uppenbart att det finns ett alternativ för att skapa svarsfördelningar för kritiska förfrågningar. Observera att felfångst endast fungerar för BpmnError med en specifik kod. Tekniskt sett är det därför viktigt att fånga alla undantag och kasta en BpmnError med den kod som krävs, vilket fungerar för ErrorBoundaryEvent.

Felhantering i huvudprocessen fungerar på liknande sätt. Från flera uppgifter väljs logiska enheter ut som kan placeras i en subprocessram, med en lyssnare inställd för en specifik felkod. Men det finns två nyanser här. Den första är att det är besvärligt att skapa flera identiska grenar med felhantering, som bara skiljer sig åt i kod. Om strategin för felhantering ändras, t.ex. loggning, skulle många delegater i systemet behöva designas om, vilket inte är önskvärt. Därför kan man överväga att titta på händelsebaserade subprocesser.

I grund och botten är detta en separat underprocess i processpoolen, som endast startar när en viss händelse som den prenumererar på inträffar. Om du till exempel prenumererar på en sådan underprocess till händelsen BpmnError med en kod, säg MyCustomBusinessError, när denna händelse inträffar kommer hanteraren att utlösas, och när den är klar kommer processen att avslutas korrekt. Ja, den slutade inte lyckligt, men den slutade korrekt. I dessa underprocesser kan du också implementera olika hanteringslogik för samma händelse beroende på externa villkor, till exempel att eventuellt meddela om ett programfel när processen passerar en villkorlig punkt.

Den andra nyansen är mycket mer komplicerad. I verkligheten är livscykeln för varje process sannolikt uppdelad i två affärsfaser: före leadgenerering och efter det. Om ett fel uppstår innan data formateras till ett lead kan processen förmodligen bara avslutas med ett meddelande om de svårigheter som uppstått. När leadet har genererats är detta inte längre möjligt.

Vi rekommenderar inte heller att processer avslutas om juridiska skyldigheter uppstår under processen, t.ex. om ett avtal undertecknas. Hur hanterar vi sådana fel? Vissa tekniska fel, t.ex. sådana som beror på att externa tjänster inte är tillgängliga, hanteras genom automatiska omförsök inom en förutbestämd timeout. Men vad händer om processen kraschar, omförsöken har passerat, men den hypotetiska externa mikrotjänsten fortfarande är nere?

Manuell optimering

Vi kommer till begreppet manuell resolution eller, även känt som, kompensation.

Hur går det till? Eventuella fel fångas upp, delegaterna får möjlighet att försöka igen om det behövs, och om turen fortfarande inte är med dem övergår processen till ett feltillstånd, men med lämplig kod, till exempel COMPENSATION_ERROR. Denna kod fångas upp av en annan händelsebaserad underprocess, som bearbetar, loggar, meddelar och, vilket är viktigt, inte kan misslyckas oväntat. Endast där den är utformad för det, utlöser den ett tekniskt undantag som inte kan fångas upp och kraschar in i en incident.

Varför göra på det här sättet? För övervakning kan du använda EXCAMAD - en extern adminpanel för Camunda, en analog till Cockpit, med kraftfulla funktioner. Den markerar processer i incidenter med rött. Dessa processer kan modifieras eller startas om från önskad punkt. Du kan till exempel placera det nödvändiga variabelvärdet i kontexten och starta om processen från punkten direkt efter den problematiska. Detta är bekvämt, enkelt och möjliggör manuell problemlösning med minimal ansträngning.

Automatisering av affärsprocesser med Camunda: exempel från verkligheten

Camunda är känt för sin open source-plattform och sitt användarvänliga gränssnitt och har hjälpt många företag att optimera sina arbetsflöden. Låt oss utforska några exempel från verkligheten.

Bank och finans

Münchener Hypothekenbank eG, en oberoende fastighetsbank, övergick till att använda Camundas arbetsflödesmotor för att förbättra och automatisera interna processer, särskilt posthantering och samordning av låneansökningar mellan avdelningar. Tidigare var deras system stelbent, saknade flexibilitet och ledde till komplexitet som ökade felfrekvensen.

I sin utveckling mot en Java-baserad microservice-arkitektur valde de Camunda baserat på interna rekommendationer och ett nära samarbete med WDW Consulting Group. Vissa fördelar som de fick direkt från Camunda var färdiga funktioner, medan andra behövde mer utveckling. Övergången resulterade i en centraliserad uppgiftslista som används av all personal och gav flexibilitet att behålla enskilda processer utan att påverka andra.

Det mest anmärkningsvärda resultatet har varit en betydande förbättring av behandlingshastigheten för låneansökningar. Detta gynnar både personal och slutkunder. Som ett bevis på framgången vill nu andra avdelningar införa Camunda, och banken har till och med anställt fler utvecklare för att ytterligare stödja implementeringen.

Försäkring

SV Informatik, ett dotterbolag till SV SparkassenVersicherung, specialiserar sig på anpassade IT-lösningar för försäkringsbolag. De införde Camunda för att automatisera olika processer över avdelningar, vilket ledde till betydande tidsbesparingar och förbättrade svarstider för kunderna. Företaget antog Camunda 2018 som en lösning på sin sökning efter ett effektivt verktyg för affärsprocessmodellering, med fokus på att förbättra processer och förbättra samarbetet mellan IT och andra avdelningar.

Sedan implementeringen har Camunda automatiserat uppgifter som uppsägningar av motorfordonsförsäkringar och förfrågningar om försäkringsdokument. En anmärkningsvärd prestation var 80% automatiserad bearbetning av online-rapporter om stormskador. Detta visade sig vara särskilt värdefullt under 2021 års översvämningar och stormar i Tyskland. Verktyg som Camunda Optimize och Camunda Cockpit underlättar processövervakning och optimering.

Gästfrihet

Under 2020 kommer SV Group, med verksamhet i Tyskland, Schweiz och Österrike, lanserade en disruptiv digital plattform kallad "likeMagic" med Camundas hjälp. Denna plattform gav en sömlös gästupplevelse, från bokning till utcheckning, med resultat inklusive en 95% självinchecknings-/utcheckningsfrekvens och en 9 av 10 gästnöjdhetspoäng. Innovationen minskade personalbehovet och integrerade plattformar som Airbnb sömlöst. SV Group insåg potentialen och erbjöd "likeMagic" till andra hotelloperatörer. År 2023 hade de gått från 2 till över 30 kunder i DACH-regionen, med planer på en bredare europeisk räckvidd och ett mål på 15 000 rum vid årets slut.

Avslutning

Camundas transformativa potential ligger inte bara i dess kärnfunktionalitet utan även i dess förmåga att omdefiniera affärsverksamheten på en grundläggande nivå. I kombination med Spring Boot öppnar det en dörr till sömlösa integrationer och förbättrad skalbarhet. Att förstå hur BPMN fungerar är avgörande för att kunna utnyttja Camundas fulla potential. När företag utvecklas i denna digitala tidsålder sticker verktyg som Camunda ut genom att erbjuda dynamiska lösningar som kan svänga och anpassa sig till ständigt föränderliga behov. Det handlar inte bara om att automatisera processer, det handlar om att förnya arbetsflöden, förbättra effektiviteten och driva konkreta resultat som gör skillnad. Ta vara på kraften i Camunda och låt ditt företag sväva mot nya horisonter.

Dmitry Nazarevich CTO

Datum: 17 januari 2024

Innehållsförteckning

Betygsätt den här artikeln:

★★★★★ 4/5

4,8/5 (45 recensioner)

Relaterat innehåll

Blogg

Looker vs Power BI - Revolutionerande industri Liten täckning

Jämförelse mellan Looker och Power BI: avslöjande av BI-verktyget

Blogg

Varför anställa juniora mjukvaruutvecklare för dina projekt

Blogg

Att välja rätt IT nearshoring partner: tips för IT-konsulter i Europa

Blogg

Varför ditt projekt sannolikt kommer att misslyckas utan BA

Varför ditt projekt sannolikt kommer att misslyckas utan en BA-specialist

Blogg

Varför IT-projekt misslyckas

Kontakta oss

Namn

Företag

E-post

Telefon

Meddelande Vänligen inkludera projektinformation, varaktighet, teknologistack, IT-proffs som behövs och annan relevant information

Spela in ett röstmeddelande om ditt projekt för att hjälpa oss att förstå det bättre

Bifoga ytterligare dokument vid behov

Ladda upp filen

Du kan bifoga upp till 1 fil på totalt 2 MB. Giltiga filer: pdf, jpg, jpeg, png

Observera att när du klickar på knappen Skicka kommer Innowise att behandla dina personuppgifter i enlighet med vår Integritetspolicy för att ge dig lämplig information.

Vad händer härnäst?

Efter att ha mottagit och behandlat din begäran kommer vi att återkomma till dig inom kort för att specificera dina projektbehov och underteckna en NDA för att säkerställa konfidentialitet av information.

Efter att ha undersökt kraven utarbetar våra analytiker och utvecklare en projektförslag med arbetets omfattning, lagets storlek, tid och kostnad uppskattningar.

Vi ordnar ett möte med dig för att diskutera erbjudandet och komma överens.

Vi skriver på ett kontrakt och börjar arbeta med ditt projekt så snabbt som möjligt.

Automatisering av affärsprocesser med Camunda: feltolerant implementering av BPM-system

Vad är Camunda?

Camunda, Spring Boot & BPMN: att förstå begreppen