5 min lesing

Automatisering av forretningsprosesser med Camunda: feiltolerant implementering av BPM-ordninger

BPMN

Comunda

Summarize article with AI

In today’s digitally driven world, maintaining a competitive edge requires streamlined and efficient business processes. Automation stands out as a key solution to achieving this. According to Statista, the business process management (BPM) market forventestil å nå en størrelse på 14,4 milliarder amerikanske dollar innen 2025. Den økende populariteten og etterspørselen etter BPM-verktøy som Camunda, kjent for sin fleksibilitet og skalerbarhet, vitner om denne trenden. Etter hvert som bedrifter søker pålitelige verktøy for å optimalisere driften, fremstår Camunda som en forløper som baner vei for innovative, feiltolerante automatiseringsløsninger i bransjen.

Hva er Camunda?

Enkelt forklart er Camunda en åpen kildekode-plattform for arbeidsflyt- og beslutningsautomatisering som bringer forretningsbrukere og programvareutviklere sammen. Camunda tilbyr et robust sett med verktøy og funksjoner som gjør det mulig å designe, implementere og optimalisere BPMN-arbeidsflyter (Business Process Model and Notation), noe som gjør forretningsdriften smidigere og mer transparent.

Camunda, Spring Boot og BPMN: forståelse av konseptene

Tre viktige aktører har endret landskapet for styring av forretningsprosesser: Camunda, Spring Boot og BPMN. Hver av dem har funnet sin egen nisje og tilbyr unike funksjoner som tar for seg ulike aspekter ved prosesshåndtering. Men når de kombineres, blir de til en enestående kraftpakke som er i stand til å revolusjonere den digitale forretningsdriften.

Camunda: This isn’t just another tool in the vast BPM toolbox; it’s a standout. As a robust open-source platform, Camunda specializes in workflow and decision automation. Its primary objective? To seamlessly fuse the worlds of business strategists and software developers. By doing so, it ensures that the conceptualization, design, and implementation of business processes are efficient, transparent, and cohesive.

Spring Boot: Spring Boottar styrken Av Våren rammeverk og løfter dem. Ved å tilby en strømlinjeformet metode for å bygge frittståendeJavahar det blitt farten til for utviklere som ønsker å minimere standardtekst kode og dykke rett inn i hjertet av prosjektspesifikke funksjoner. Kraften ligger i fleksibiliteten og tilnærmingen til konvensjon-over-konfigurasjon, som forkjemper ideen om smarte standardinnstillinger. Denne tilnærmingen lar utviklere bygge skalerbare applikasjoner raskere, noe som sikrer rettidig levering og jevn ytelse.

BPMN: Hvis vi skulle personifisere BPMN, ville det være forretningsverdenens veltalende lingvist. BPMN er en globalt anerkjent standard som gir et visuelt vokabular for utforming av forretningsprosesser, noe som gjør dem lett forståelige for et bredt spekter av interessenter. Dette universelle språket sørger for at de tekniske nyansene i en prosess kan dechiffreres av både den teknisk kyndige koderen og forretningsstrategen, noe som fremmer samarbeidsdialoger og mer informerte beslutninger.

The synergy of Camunda’s automation capabilities, Spring Boot’s development ease, and BPMN’s standardized notation presents businesses with a dynamic trifecta. Together, they ensure that BPM schemes transition from mere theoretical constructs on paper to actionable, real-world implementations. The end goal? To cultivate business processes that are agile, resilient, and perfectly aligned with the evolving demands of the contemporary digital enterprise landscape.

See what related services we offer

Grunnleggende BPMN-komponenter

For de som ikke er kjent med BPMN, er det viktig å forstå de viktigste komponentene. Disse komponentene danner grunnlaget for ethvert BPMN-diagram.

Arrangementer

Disse betegner noe som skjer i løpet av en prosess. Hendelser kan starte, avbryte eller avslutte en flyt, og de representeres ofte som sirkler.

Portaler

Gateways håndterer beslutningstaking i prosessen. Basert på betingelser styrer de flyten i prosessen, vanligvis avbildet som diamanter.

Aktiviteter

Aktiviteter representerer arbeid som utføres. De kan være oppgaver eller delprosesser og vises som avrundede rektangler.

Kobling av objekter

Disse elementene, inkludert sekvensflyt, meldingsflyt og assosiasjoner, illustrerer rekkefølgen på prosesser og meldingsflyt.

Svømmebaner

Disse kategoriserer BPMN-elementer enten etter rolle (f.eks. leder, regnskapsfører) eller system (f.eks. et ERP-system).

Gjenstander

Disse gir tilleggsinformasjon om prosessen. Vanlige artefakter inkluderer dataobjekter, grupper og merknader.

Fordeler og ulemper med Camunda

As with any technological solution, Camunda brings a mix of advantages and challenges. Here’s a comprehensive look into its pros and cons.

Fordeler:

Fleksibel og enkel integrering med Java-applikasjoner gjennom Spring Boot.
Et intuitivt modelleringsgrensesnitt for BPMN 2.0.
Gir detaljerte analyser av prosessmålinger.

Ulemper:

Kan ha en brattere læringskurve for ikke-tekniske brukere.
It’s a strong starting point, but think of it as just the base – while Camunda is a powerful workflow engine, you’ll still need further software development.

Effektivisering av overbelastede BPMN-diagrammer

Tøff virkelighet

Camunda er utviklet for å få utviklere og analytikere til å snakke samme språk, men ofte kommer virkeligheten i veien.

Mikrotjenester svikter, brukere taster inn feil data, alt kan skje. I dette tilfellet begynner det vakre analytiske diagrammet å bli pyntet med ulike feilhåndterere, loggere og alternative veier. Analytikeren utformer et vakkert, kortfattet og forståelig skjema. Det har noen få delegater og viser logiske veier for prosessflyten under ulike omstendigheter. Slik ser et foreløpig skjema ut når det kommer i hendene på en utvikler:

However, there are downsides. Such a scheme might contain a brief task description, like “check the client”, which implies several stages, decision-making based on each outcome, and compiling the derived decisions into a single result, possibly with the subsequent transfer of this result to external systems.

It’s clear that at this point, error handlers, loggers, and technical service elements appear on the diagram or in the code. This way, one “analytical” task in the Java implementation becomes voluminous and complex, or the number of steps on the scheme increases, each being accompanied by handlers and alternative pathways. As a result, the scheme quickly becomes convoluted, difficult for further support and modification, and adding new functionality might entail restructuring a vast area of both the scheme and the delegate code. In essence, it contains a massive number of identical elements.

Here’s how the previous scheme might look in a real deployment:

Det er klart at opplegget er utvidet og blitt mer tungvint. Men det er fordeler: Alle oppgaver har blitt atomiske, og det har oppstått atferdsgrener i tilfelle feil.

Å innse problemet

Hvis vi prøver å skille og innkapsle opplegget og forretningslogikken i Java-koden, kan vi gjøre følgende:

Unngå å duplisere lignende elementer på skjemaet.
Bruk en universell og gjenbrukbar implementering av delegater i Java-koden.
Optimalisere og akselerere prosessflyten.
Simplify the handling of technical errors and establish a process behavior logic when they arise – almost without the involvement of Java code. This will significantly simplify debugging and manual analysis of failed processes that are in an incident.
Drastically reduce the number of processes that “fall” into incidents when technical exceptions arise.
Legge et solid grunnlag for videre utvikling.

For å gjøre det enklere å jobbe med produktet er det bedre å dele opp systemet i atomære oppgaver, redusere det totale volumet av systemelementer, redusere antall tjenestehåndterere, redusere volumet av Java-kode for hver delegat og gjenbruke universelle delegater og utføre øyeblikkelig refaktorering når det er nødvendig. Alt dette innebærer automatisk skriving av enhetstester for alle delegater og hovedveiene i prosessen.

Nedbrytning og forstøvning

If you look closely at the process application and analyze its nodes, you can see many repetitive functions: queries to external systems, logging, error handling, sending callbacks, etc. In other words, one needs to critically assess the process application, identify objects from it that can be easily encapsulated… But into what? Into Java code? No, that would be illogical, because in this case, the scheme would be closely tied to its Java implementation. In this situation, it makes sense to consider process pools.

A process pool is a scheme of a separate process that will have its own context. It is noteworthy that it’s convenient to extract atomic pieces of functionality from the main process into such pools, as well as all repetitive moments: sending notifications, requests to external systems, etc.

Det kan være mange prosesspooler, og det vil være logisk å gruppere dem tematisk. For eksempel spørringer til en bestemt mikrotjeneste, varsling, sending av ulike notifikasjoner. Interaksjon mellom slike pooler kan enkelt settes opp ved hjelp av Camunda messaging. Hver gang en slik pool anropes i Camunda-motoren, sendes en bestemt melding som inneholder en betinget overskrift og det overordnede prosessnummeret for å returnere et svar, samt et sett med nødvendige data for driften av denne spesifikke lille poolen.

Her ser vi hvordan hovedprosessen (nederst) sender en melding som starteren i en annen pool abonnerer på. Når hendelsen inntreffer, starter det andre bassenget en ny instans av prosessen, sender en forespørsel og sender et svar tilbake til hovedprosessen, som deretter fullfører prosessen. I løpet av denne tiden venter hovedprosessen på svarmeldingen fra det eksterne bassenget som den sendte en forespørsel til. Når meldingen kommer, fortsetter prosessen. Hvis det ikke kommer noe svar innen det angitte tidsintervallet, forstår prosessen at den eksterne beregningen ikke er tilgjengelig eller har mislyktes, og avsluttes.

Hva dette tilbyr:

Mulighet for gjenbruk av kode. Hvis du har behov for å kalle den samme koden flere ganger under ulike forhold i løpet av prosessen, kan du ganske enkelt opprette spesifikke meldinger og kalle de tilsvarende atomiske prosesspoolene;
Encapsulation of the software implementation scheme from its business representation. It doesn’t matter how the main scheme will be redesigned, or which paths the process will take. All interactions have already been moved to separate minor processes, which gives complete flexibility: just form a request and wait for a response.
Antallet og sannsynligheten for at hovedprosessen krasjer er betydelig redusert. Før en slik inndeling var prosessen i en usikkerhet på 4 stater:
Svaret har kommet.
The response didn’t come because the external microservice crashed.
The response didn’t come because the main process crashed while sending the request.
The response didn’t come because a timeout was exceeded.

With this division, the process is always in a strictly single state: the response either came, or the process waited and ended. For business, it matters how exactly the process ended: whether it was an error or not. But this will be a proper conclusion, not an incident. This is important because a process not stuck in an incident doesn’t “consume” resources, and errors can be easily logged, statistics gathered, alerts set up, and analyzed.

It no longer matters what happens with the minor processes. They can do whatever they want: crash, run… Only the result is important: the response from the external resource. And even then, not always, because the main process shouldn’t guarantee the functionality of external systems. For instance, there might be no sense in the process waiting for a response from the notification microservice since there could be no response at all.
Kompleksiteten i hovedprosessen reduseres kraftig. Kompleks logikk kan fordeles på separate små pooler, som er enklere å feilsøke. En klientverifisering kan for eksempel se slik ut:

Here, we can see that in the external pool, multiple tasks are called simultaneously. Let’s delve deeper into this point.

Parallellisering av prosessberegninger

Camunda allows for the concurrent execution of branches of process computations. For this purpose, there’s a special gateway called the Parallel Gateway, using which the flow can be divided into parallels or to merge multiple parallel computations into one stream. It’s clear that to accelerate the flow of a process, it would be advantageous to delegate certain tasks to parallel threads. If the logic is independent, it can be executed in parallel, for example, making simultaneous requests to external systems and waiting for responses from all of them at once:

Each time at such a gateway, there will be overhead costs associated with creating new threads for task division and merging the results. One may encounter various locking exceptions, and, of course, it’s not always necessary or justified to always act this way, especially without testing, but the benefits are evident.

With sequential execution, the total execution time equals the sum of the execution times of each operation. In contrast, with parallel execution, it equates to the execution time of the longest operation. Given the conditions of non-instant responses from external sources, retries, and failures, this difference is far from insignificant. Another undeniable advantage is the form of “free retries”, i.e., while the longest request is being executed, the other tasks hypothetically have the opportunity to fail several times and attempt to redo their actions without impacting the overall task execution time.

Unntak og repetisjonsforsøk

Broke? It happens. The out-of-the-box version of Camunda has the capability to retry a failed transaction. By “transaction”, we mean Camunda’s internal mechanism for executing delegate code. The start of a transaction can be, for example, the “async before” or “async after” marker on a task in the modeler. When the engine encounters this marker, it commits its information to the database and starts a new asynchronous thread. This is important. To delve deeper, by “transaction”, we mean the execution section between the calls to the .complete() method in TaskService, followed by recording information to the database. These transactions, like others, are atomic.

Når det oppstår et teknisk unntak, dvs. en feil som ikke er av forretningsmessig art, for eksempel at man dividerer med null og glemmer en nullkontroll, gjør transaksjonen en rollback og prøver å starte på nytt. Som standard gjør den dette tre ganger etter hverandre uten pauser. Et nytt forsøk starter når det oppstår et vanlig unntak, som i BPMN-verdenen kalles et teknisk unntak, ikke en BpmnError. En BpmnError som oppstår, stopper prosessen uten nye forsøk. Forestill deg hvordan dette gjør prosessen mer robust.

It makes sense to maximize this feature. Therefore, on every delegate that requests an external system, these markers are set, specifying the number of retries and the pause between them, and in the delegate code separates logic for when the process should be terminated and when it shouldn’t. It gives full control over the exception handling and retry mechanisms. As a result, the process tries to redo the failed task several times, and only after a series of failures it produces an error.

Perhaps, the biggest challenge is the handling of technical exceptions and BPMN-related errors, as well as designing the logic of their handling for a continuous flow of the process. We’ve already discussed some errors related to handling responses from external sources when talking about dividing into process pools. We’d like to remind you that the very call was encapsulated into a separate mini-process, and the main one either received a response and proceeded further or, due to a timeout, followed the “I didn’t receive a response” route.

Now, let’s look at that very small process:

Do you see the frame? It’s a subprocess. It contains specific tasks and captures errors thrown by internal tasks. Moreover, on such frames, the job executor is capable of creating a job for the timer, which sets the execution time for everything inside the subprocess.

How does it work? The execution flow reaches the subprocess, creates parallel timer processing, and waits either for the completion of what’s inside or, if the timer runs out first, it will follow the timer route. If an exception is thrown during the process, which the subprocess frame captures, the process will stop its execution on the current branch and follow the error branch.

It’s also evident that there’s an option to create response dispatches for critical requests. Note that error capturing works only for BpmnError with a specific code. Therefore, technically, it’s essential to catch any exception and throw a BpmnError with the required code, which works for the ErrorBoundaryEvent.

Error handling in the main process works similarly. From several tasks, logical units are singled out that can be placed in a subprocess frame, with a listener set up for a specific error code. But there are two nuances here. The first is that creating multiple identical branches with error handling, differing only in code, is inconvenient. If the error handling strategy changes or, for example, logging, then many delegates on the scheme would need to be redesigned, which isn’t desirable. Therefore, one might consider looking into event-based subprocesses.

At its core, this is a separate subprocess of the process pool, which starts only when a certain event it’s subscribed to occurs. For instance, if you subscribe such a subprocess to the BpmnError event with a code, say, MyCustomBusinessError, then when this event occurs, the handler will be triggered, and upon its completion, the process will end correctly. Yes, it didn’t end in success, but it ended correctly. In these subprocesses, you can also implement different handling logic for the same event depending on external conditions, for example, optionally notifying about an application error when the process passes a conditional point.

Den andre nyansen er mye mer komplisert. I det virkelige liv er livssyklusen til hver prosess sannsynligvis delt inn i to faser: før og etter leadgenerering. Hvis det oppstår en feil før dataene formateres til et lead, kan prosessen sannsynligvis bare avsluttes med en melding om problemene. Når leadet er generert, er dette ikke lenger mulig.

We also don’t recommend ending processes if legal obligations arise during the process, for instance, if a contract is signed. How do we handle such errors? Some technical errors, like those associated with the unavailability of external services, are handled by automatic retries within a pre-agreed timeout. But what if the process crashed, retries have passed, but the hypothetical external microservice is still down?

Manuell optimalisering

Vi kommer til begrepet manuell oppløsning, også kjent som kompensasjon.

How does it work? Any errors are caught, delegates are given the opportunity to retry if necessary, and if luck still doesn’t favor them, the process goes into an error state, but with the appropriate code, for instance, COMPENSATION_ERROR. This code is caught by another event-based subprocess, which processes, logs, notifies, and importantly, cannot fail unexpectedly. Only where it’s designed to, it throws an uncatchable technical exception and crashes into an incident.

Why do it this way? For monitoring, you can use EXCAMAD – an external admin panel for Camunda, an analogue to Cockpit, with powerful features. It highlights processes in incidents in red. These processes can be modified or restarted from the desired point. For instance, you can place the necessary variable value in the context and restart the process from the point right after the problematic one. This is convenient, straightforward, and allows for manual problem resolution with minimal effort.

Automatisering av forretningsprosesser med Camunda: eksempler fra virkeligheten

Renowned for its open-source platform and user-friendly interface, Camunda has empowered numerous enterprises to optimize their workflows. Let’s explore a few real-life examples.

Bank og finans

Münchener Hypothekenbank eG, en uavhengig eiendomsbank gikk over til å bruke Camundas arbeidsflytmotor for å forbedre og automatisere interne prosesser, spesielt posthåndtering og koordinering av lånesøknader mellom avdelinger. Tidligere var systemet deres rigid, lite fleksibelt og førte til kompleksitet som økte feilprosenten.

I overgangen til en Java-basert mikrotjenestearkitektur valgte de Camunda basert på interne anbefalinger og i tett samarbeid med WDW Consulting Group. Noen av fordelene de fikk umiddelbart fra Camunda, var hyllevarefunksjoner, mens andre krevde mer utvikling. Overgangen resulterte i en sentralisert oppgaveliste som brukes av alle ansatte, og ga fleksibilitet til å opprettholde individuelle prosesser uten å påvirke andre.

Det mest bemerkelsesverdige resultatet har vært en betydelig forbedring av behandlingshastigheten for lånesøknader. Dette kommer både ansatte og sluttkunder til gode. Et bevis på suksessen er at andre avdelinger nå ønsker å ta i bruk Camunda, og banken har til og med ansatt flere utviklere for å støtte implementeringen.

Forsikring

SV Informatik, et datterselskap av SV SparkassenVersicherung, spesialiserer seg på skreddersydde IT-løsninger for forsikringsselskaper. De har tatt i bruk Camunda for å automatisere ulike prosesser på tvers av avdelinger, noe som har ført til betydelige tidsbesparelser og forbedret responstid overfor kundene. Selskapet tok i bruk Camunda i 2018 som en løsning på deres søken etter et effektivt verktøy for modellering av forretningsprosesser, med fokus på å forbedre prosesser og styrke samarbeidet mellom IT og andre avdelinger.

Siden implementeringen har Camunda automatisert oppgaver som oppsigelser av bilforsikringer og forespørsler om forsikringsdokumenter. En bemerkelsesverdig prestasjon var 80%s automatiserte behandling av online stormskaderapporter. Dette viste seg å være spesielt verdifullt under flommen og uværet i Tyskland i 2021. Verktøy som Camunda Optimize og Camunda Cockpit gjør det enklere å overvåke og optimalisere prosessene.

Gjestfrihet

I 2020 bleSV Group, operating in Germany, Switzerland, and Austria, launched a disruptive digital platform called ‘likeMagic’ with Camunda’s assistance. This platform provided a seamless guest experience, from booking to check-out, with outcomes including a 95% self-check-in/out rate and a 9 out of 10 guest happiness score. The innovation reduced staffing needs and integrated platforms like Airbnb seamlessly. Recognizing its potential, SV Group offered ‘likeMagic’ to other hospitality providers. By 2023, they expanded from 2 to over 30 customers in the DACH region, with plans for a broader European reach and targeting 15,000 rooms by year-end.

Avslutning

Camunda’s transformative potential lies not just in its core functionalities but in its ability to redefine business operations at a fundamental level. Combined with Spring Boot, it opens a doorway to seamless integrations and enhanced scalability. Understanding the nuts and bolts of BPMN is paramount to leveraging Camunda’s full potential. As businesses evolve in this digital age, tools like Camunda stand out, offering dynamic solutions that can pivot and adapt to ever-changing needs. It’s not just about automating processes, it’s about innovating workflows, enhancing efficiency, and driving tangible results that make a difference. Embrace the power of Camunda, and let your business soar to new horizons.

Dmitry Nazarevich CTO

Dato: 17. januar 2024

Innholdsfortegnelse

Ranger denne artikkelen:

★★★★★ 4/5

4.8/5 (45 anmeldelser)

Kontakt oss

Bestill en samtale eller fyll ut skjemaet nedenfor, så vil vi kontakte deg så snart vi har behandlet forespørselen din.

Navn

Firma

E-post

Telefon

Melding

Send oss en talemelding

Legg ved dokumenter

Last opp fil

Du kan legge ved én fil opptil 2MB. Gyldige filformater: pdf, jpg, jpeg, png.

Ved å klikke Send, samtykker du til at Innowise behandler dine personopplysninger i henhold til vår Personvernerklæring for å gi deg relevant informasjon. Ved å oppgi telefonnummeret ditt, godtar du at vi kan kontakte deg via talesamtaler, SMS og meldingsapper. Samtale-, meldings- og datakostnader kan påløpe.

Du kan også sende oss forespørselen din
til contact@innowise.com

Hva skjer videre?

Når vi har mottatt og behandlet forespørselen din, vil vi kontakte deg for å diskutere prosjektbehovene dine og signere en NDA for å sikre konfidensialitet.

Etter å ha undersøkt dine ønsker, behov og forventninger, vil teamet vårt utarbeide et prosjektforslag med omfang av arbeid, teamstørrelse, tids- og kostnadsestimater.

Vi vil arrangere et møte med deg for å diskutere tilbudet og fastsette detaljene.

Til slutt vil vi signere en kontrakt og starte arbeidet med prosjektet ditt umiddelbart.