Het formulier is succesvol verzonden.
Meer informatie vindt u in uw mailbox.
In de digitale wereld van vandaag vereisen gestroomlijnde en efficiënte bedrijfsprocessen een concurrentievoordeel. Automatisering is een belangrijke oplossing om dit te bereiken. Volgens Statista is de markt voor business process management (BPM) wordt verwacht om tegen 2025 een omvang van 14,4 miljard dollar te bereiken. De stijgende populariteit van en vraag naar BPM tools zoals Camunda, bekend om zijn flexibiliteit en schaalbaarheid, getuigen van deze trend. Omdat bedrijven op zoek zijn naar betrouwbare tools om hun activiteiten te optimaliseren, komt Camunda naar voren als een voorloper die de weg vrijmaakt voor innovatieve, fouttolerante automatiseringsoplossingen in de industrie.
Eenvoudig gezegd is Camunda een open-source platform voor workflow- en beslissingsautomatisering dat zakelijke gebruikers en softwareontwikkelaars samenbrengt. Met zijn robuuste set tools en functies biedt Camunda manieren om BPMN (Business Process Model and Notation) workflows te ontwerpen, implementeren en optimaliseren, waardoor bedrijfsactiviteiten soepeler en transparanter worden.
Drie belangrijke spelers hebben het landschap van business process management opnieuw vormgegeven: Camunda, Spring Boot en BPMN. Elk van hen heeft zijn eigen niche gecreëerd en biedt unieke functionaliteiten voor verschillende facetten van procesmanagement. Wanneer ze echter worden gecombineerd, vormen ze een ongeëvenaarde krachtpatser die in staat is een revolutie teweeg te brengen in de bedrijfsvoering van digitale ondernemingen.
Camunda: Dit is niet zomaar een tool in de uitgebreide BPM-toolbox; het is een uitblinker. Camunda is een robuust open-source platform dat gespecialiseerd is in workflow- en beslissingsautomatisering. De primaire doelstelling? De werelden van bedrijfsstrategen en softwareontwikkelaars naadloos met elkaar laten versmelten. Hierdoor zorgt het ervoor dat de conceptualisatie, het ontwerp en de implementatie van bedrijfsprocessen efficiënt, transparant en samenhangend zijn.
Spring Boot: Spring Boot neemt de kracht van het Veerframework en verheft ze. Door het aanbieden van een gestroomlijnde methode om standalone Java te bouwen, is het de go-to geworden voor ontwikkelaars die standaardcode willen minimaliseren en rechtstreeks in het hart van projectspecifieke functionaliteiten willen duiken. Zijn kracht ligt in zijn flexibiliteit en zijn convention-over-configuration benadering, die het idee van slimme standaardwaarden verdedigt. Deze aanpak stelt ontwikkelaars in staat om sneller schaalbare applicaties te bouwen, waardoor tijdige levering en consistente prestaties worden gewaarborgd.
BPMN: Als we BPMN zouden moeten personifiëren, zou het de welsprekende taalkundige van de bedrijfswereld zijn. Als wereldwijd erkende standaard biedt BPMN een visuele woordenschat voor het opstellen van bedrijfsprocessen, waardoor ze gemakkelijk te begrijpen zijn voor een breed scala aan belanghebbenden. Deze universele taal zorgt ervoor dat de technische nuances van een proces kunnen worden ontcijferd door zowel de technisch onderlegde programmeur als de bedrijfsstrateeg.
De synergie van Camunda's automatiseringsmogelijkheden, Spring Boot's ontwikkelgemak en BPMN's gestandaardiseerde notatie biedt bedrijven een dynamische drie-eenheid. Samen zorgen ze ervoor dat BPM-schema's veranderen van louter theoretische constructies op papier in bruikbare implementaties in de praktijk. Het einddoel? Bedrijfsprocessen cultiveren die wendbaar en veerkrachtig zijn en perfect afgestemd zijn op de evoluerende eisen van het hedendaagse digitale ondernemingslandschap.
Voor degenen die niet bekend zijn met BPMN is het cruciaal om de essentiële componenten te begrijpen. Deze componenten vormen de basis van elk BPMN-diagram.
Deze geven aan dat er iets gebeurt tijdens een proces. Gebeurtenissen kunnen een stroom starten, onderbreken of beëindigen en worden vaak weergegeven als cirkels.
Gateways zorgen voor de besluitvorming binnen het proces. Op basis van de voorwaarden sturen ze de stroom van het proces, meestal afgebeeld als diamanten.
Activiteiten vertegenwoordigen werk dat wordt gedaan. Ze kunnen taken of subprocessen zijn en worden weergegeven als afgeronde rechthoeken.
Deze elementen, waaronder sequentiestromen, berichtenstromen en associaties, illustreren de volgorde van processen en de berichtenstroom.
Deze categoriseren BPMN-elementen op rol (bijv. manager, accountant) of systeem (bijv. een ERP-systeem).
Deze bieden aanvullende informatie over het proces. Veel voorkomende artefacten zijn dataobjecten, groepen en annotaties.
Zoals elke technologische oplossing brengt Camunda een mix van voordelen en uitdagingen met zich mee. Hier volgt een uitgebreide blik op de voor- en nadelen.
Camunda is ontworpen om ontwikkelaars en analisten dezelfde taal te laten spreken, maar vaak komt de realiteit tussenbeide.
Microservices falen, gebruikers voeren verkeerde gegevens in, er kan van alles gebeuren. In dit geval wordt het mooie analytische schema verfraaid met verschillende foutafhandelaars, loggers en alternatieve paden. De analist ontwerpt een mooi, beknopt en begrijpelijk schema. Het heeft een paar afgevaardigden en biedt logische paden voor de processtroom onder verschillende omstandigheden. Zo ziet een voorlopig schema eruit wanneer het in handen komt van een ontwikkelaar:
Er zijn echter nadelen. Zo'n schema kan een korte taakbeschrijving bevatten, zoals "controleer de klant", wat verschillende stappen impliceert, besluitvorming gebaseerd op elk resultaat, en het samenvoegen van de afgeleide beslissingen in een enkel resultaat, mogelijk met de daaropvolgende overdracht van dit resultaat naar externe systemen.
Het is duidelijk dat op dit punt foutverwerkers, loggers en technische service-elementen op het schema of in de code verschijnen. Op deze manier wordt één "analytische" taak in de Java-implementatie omvangrijk en complex, of neemt het aantal stappen in het schema toe, elk vergezeld van handlers en alternatieve paden. Het resultaat is dat het schema snel ingewikkeld wordt, moeilijk te ondersteunen en aan te passen is, en het toevoegen van nieuwe functionaliteit kan betekenen dat een groot deel van zowel het schema als de gedelegeerde code geherstructureerd moet worden. In essentie bevat het een enorm aantal identieke elementen.
Hier zie je hoe het vorige schema eruit zou kunnen zien in een echte implementatie:
Het schema is duidelijk uitgebreid en omslachtiger geworden. Maar er zijn voordelen: alle taken zijn atomair geworden en er zijn takken van gedrag ontstaan in het geval van fouten.
Als we proberen het schema en de bedrijfslogica van de Java-code te scheiden en in te kapselen, kunnen we het volgende doen:
Om het gemakkelijker te maken om met het product te werken, is het beter om het schema in atomaire taken te ontleden, het totale volume van schema-elementen te verminderen, het aantal service-handlers te verminderen, het volume van de Java-code van elke delegate te verminderen en universele delegates te hergebruiken, door indien nodig onmiddellijk refactoring uit te voeren. Dit alles impliceert automatisch het schrijven van unit tests voor alle delegates en de hoofdpaden van het proces.
Als je goed naar de procesapplicatie kijkt en de knooppunten analyseert, zie je veel repetitieve functies: query's naar externe systemen, logging, foutafhandeling, callbacks versturen, enz. Met andere woorden, je moet de procesapplicatie kritisch beoordelen en objecten ervan identificeren die gemakkelijk kunnen worden ingekapseld... Maar waarin? In Java-code? Nee, dat zou onlogisch zijn, want in dit geval zou het schema nauw verbonden zijn met zijn Java implementatie. In deze situatie is het zinvol om procespools te overwegen.
Een procespool is een schema van een apart proces dat zijn eigen context heeft. Het is opmerkelijk dat het handig is om atomaire stukjes functionaliteit van het hoofdproces in zulke pools te stoppen, evenals alle herhalende momenten: het versturen van meldingen, verzoeken naar externe systemen, enz.
Er kunnen veel procespools zijn en het zou logisch zijn om ze thematisch te groeperen. Bijvoorbeeld query's naar een bepaalde microservice, alarmering, het versturen van verschillende notificaties. Interactie tussen zulke pools kan eenvoudig worden opgezet met Camunda messaging. Elke keer dat zo'n pool wordt aangeroepen in de Camunda engine, wordt een bepaald bericht doorgegeven met een conditionele header en het bovenliggende procesnummer voor het retourneren van een antwoord, evenals een set noodzakelijke gegevens voor de werking van deze specifieke kleine pool.
Hier zien we hoe het hoofdproces (onderaan) een bericht stuurt waarop de starter van een andere pool is geabonneerd. Wanneer de gebeurtenis plaatsvindt, start de tweede pool een nieuwe instantie van het proces, doet een verzoek en stuurt een antwoord terug naar het hoofdproces, waarna het succesvol afrondt. Gedurende deze tijd wacht het hoofdproces op het antwoord van de externe pool waarnaar het een verzoek stuurde. Als het bericht arriveert, gaat het proces verder. Als er geen antwoord komt binnen het gespecificeerde tijdsinterval, begrijpt het proces dat de externe berekening niet beschikbaar is of is mislukt en wordt het proces beëindigd.
Wat dit biedt:
Met deze verdeling is het proces altijd in een strikt enkele toestand: het antwoord kwam, of het proces wachtte en eindigde. Voor bedrijven maakt het uit hoe het proces precies eindigde: of het een fout was of niet. Maar dit zal een juiste conclusie zijn, geen incident. Dit is belangrijk omdat een proces dat niet vastzit in een incident geen middelen "verbruikt" en fouten gemakkelijk kunnen worden gelogd, statistieken verzameld, waarschuwingen ingesteld en geanalyseerd.
Hier kunnen we zien dat in de externe pool meerdere taken tegelijkertijd worden aangeroepen. Laten we dieper op dit punt ingaan.
Camunda maakt het mogelijk om takken van procesberekeningen gelijktijdig uit te voeren. Voor dit doel is er een speciale gateway genaamd de Parallel Gateway, waarmee de stroom kan worden opgedeeld in parallellen of om meerdere parallelle berekeningen samen te voegen in één stroom. Het is duidelijk dat om de stroom van een proces te versnellen, het voordelig zou zijn om bepaalde taken te delegeren aan parallelle threads. Als de logica onafhankelijk is, kan deze parallel worden uitgevoerd, bijvoorbeeld door gelijktijdig verzoeken te doen aan externe systemen en te wachten op antwoorden van allemaal tegelijk:
Elke keer bij zo'n gateway zijn er overheadkosten verbonden aan het aanmaken van nieuwe threads voor het verdelen van taken en het samenvoegen van de resultaten. Men kan verschillende vergrendelingsuitzonderingen tegenkomen, en natuurlijk is het niet altijd nodig of gerechtvaardigd om altijd op deze manier te handelen, vooral zonder te testen, maar de voordelen zijn duidelijk.
Bij sequentiële uitvoering is de totale uitvoeringstijd gelijk aan de som van de uitvoeringstijden van elke bewerking. Bij parallelle uitvoering daarentegen is dit gelijk aan de uitvoeringstijd van de langste bewerking. Gezien de omstandigheden van niet-onmiddellijke reacties van externe bronnen, pogingen en mislukkingen, is dit verschil verre van onbeduidend. Een ander onbetwistbaar voordeel is de vorm van "vrije pogingen", d.w.z. terwijl het langste verzoek wordt uitgevoerd, hebben de andere taken hypothetisch gezien de mogelijkheid om meerdere keren te falen en te proberen hun acties opnieuw uit te voeren zonder de totale taakuitvoeringstijd te beïnvloeden.
Failliet? Het gebeurt. De out-of-the-box versie van Camunda heeft de mogelijkheid om een mislukte transactie opnieuw te proberen. Met "transactie" bedoelen we Camunda's interne mechanisme voor het uitvoeren van gedelegeerde code. Het begin van een transactie kan bijvoorbeeld de "async before" of "async after" marker zijn op een taak in de modeler. Wanneer de engine deze markering tegenkomt, wordt de informatie vastgelegd in de database en wordt een nieuwe asynchrone thread gestart. Dit is belangrijk. Om dieper te graven, met "transactie" bedoelen we het uitvoeringsgedeelte tussen de aanroepen van de .complete() methode in TaskService, gevolgd door het vastleggen van informatie in de database. Deze transacties zijn, net als andere, atomair.
Als er een technische uitzondering optreedt, d.w.z. een niet-zakelijke fout, bijvoorbeeld delen door nul en een null-controle vergeten, voert de transactie een rollback uit en probeert opnieuw te beginnen. Standaard doet het dit drie keer achter elkaar zonder pauzes. Een poging tot opnieuw proberen begint als er een reguliere uitzondering optreedt, die in de BPMN-wereld een technische uitzondering wordt genoemd en geen BpmnError. Een optredende BpmnError stopt het proces zonder dat er nieuwe pogingen worden ondernomen. Stel je voor hoe dit de veerkracht van het proces vergroot.
Het is zinvol om deze functie te maximaliseren. Daarom worden op elke delegate die een extern systeem aanvraagt, deze markeringen gezet, die het aantal retries en de pauze daartussen specificeren, en in de code van de delegate wordt logica gescheiden voor wanneer het proces beëindigd moet worden en wanneer niet. Het geeft volledige controle over de exception handling en retry mechanismen. Als gevolg hiervan probeert het proces de mislukte taak meerdere keren opnieuw uit te voeren en pas na een reeks mislukkingen produceert het een fout.
De grootste uitdaging is misschien wel de afhandeling van technische uitzonderingen en BPMN-gerelateerde fouten, evenals het ontwerpen van de logica van hun afhandeling voor een continue stroom van het proces. We hebben al enkele fouten besproken met betrekking tot het afhandelen van reacties van externe bronnen toen we het hadden over het verdelen in procespools. We willen je eraan herinneren dat de eigenlijke aanroep werd ingekapseld in een afzonderlijk miniproces en dat het hoofdproces ofwel een antwoord ontving en verder ging, ofwel, vanwege een time-out, de route "Ik heb geen antwoord ontvangen" volgde.
Laten we nu eens kijken naar dat hele kleine proces:
Zie je het frame? Het is een subproces. Het bevat specifieke taken en vangt fouten op die door interne taken worden gegooid. Bovendien kan de job executor op zulke frames een taak aanmaken voor de timer, die de uitvoeringstijd voor alles binnen het subproces instelt.
Hoe werkt het? De uitvoeringsstroom bereikt het subproces, creëert parallelle timerverwerking en wacht ofwel op de voltooiing van wat erin zit of, als de timer eerst afloopt, volgt het de timerroute. Als er tijdens het proces een uitzondering wordt gegooid, die het subproces frame opvangt, zal het proces zijn uitvoering stoppen op de huidige tak en de fouttak volgen.
Het is ook duidelijk dat er een optie is om antwoorddispatches te maken voor kritieke verzoeken. Merk op dat het vastleggen van fouten alleen werkt voor BpmnError met een specifieke code. Daarom is het technisch gezien essentieel om elke uitzondering op te vangen en een BpmnError te gooien met de vereiste code, die werkt voor het ErrorBoundaryEvent.
Foutafhandeling in het hoofdproces werkt op dezelfde manier. Van verschillende taken worden logische eenheden uitgekozen die in een subprocesframe kunnen worden geplaatst, met een luisteraar ingesteld voor een specifieke foutcode. Maar hier zijn twee nuances. De eerste is dat het maken van meerdere identieke takken met foutafhandeling, die alleen verschillen in code, onhandig is. Als de strategie voor foutafhandeling verandert of bijvoorbeeld logging, dan zouden veel delegates op het schema opnieuw ontworpen moeten worden, wat niet wenselijk is. Daarom zou men kunnen overwegen om te kijken naar event-gebaseerde subprocessen.
In de kern is dit een afzonderlijk subproces van de procespool, dat alleen start wanneer een bepaalde gebeurtenis waarop het geabonneerd is, optreedt. Als je bijvoorbeeld zo'n subproces abonneert op de gebeurtenis BpmnError met een code, bijvoorbeeld MyCustomBusinessError, dan wordt de handler geactiveerd wanneer deze gebeurtenis optreedt en na voltooiing wordt het proces correct beëindigd. Ja, het eindigde niet met succes, maar het eindigde correct. In deze subprocessen kun je ook verschillende afhandelingslogica voor dezelfde gebeurtenis implementeren, afhankelijk van externe voorwaarden, bijvoorbeeld optioneel een melding geven over een applicatiefout wanneer het proces een voorwaardelijk punt passeert.
De tweede nuance is veel ingewikkelder. In het echte leven is de levenscyclus van elk proces waarschijnlijk verdeeld in twee bedrijfsfasen: vóór leadgeneratie en erna. Als er een fout optreedt voordat de gegevens zijn geformatteerd tot een lead, kan het proces waarschijnlijk gewoon worden beëindigd met een melding over de ondervonden moeilijkheden. Zodra de lead is gegenereerd, is dit niet meer mogelijk.
We raden ook niet aan om processen te beëindigen als er tijdens het proces wettelijke verplichtingen ontstaan, bijvoorbeeld als er een contract wordt getekend. Hoe gaan we om met dergelijke fouten? Sommige technische fouten, zoals fouten die te maken hebben met het niet beschikbaar zijn van externe services, worden afgehandeld door automatische pogingen binnen een vooraf afgesproken time-out. Maar wat als het proces crasht, de pogingen voorbij zijn, maar de hypothetische externe microservice nog steeds niet beschikbaar is?
We komen nu bij het concept van handmatige resolutie of, ook bekend als, compensaties.
Hoe werkt het? Eventuele fouten worden opgevangen, delegates krijgen de kans om opnieuw te proberen indien nodig, en als ze nog steeds geen geluk hebben, gaat het proces in een foutstatus, maar met de juiste code, bijvoorbeeld COMPENSATION_ERROR. Deze code wordt opgevangen door een ander event-gebaseerd subproces, dat verwerkt, logt, meldt en, wat belangrijk is, niet onverwacht kan falen. Alleen waar het ontworpen is om dat te doen, gooit het een niet-vangbare technische uitzondering en crasht het in een incident.
Waarom op deze manier? Voor monitoring kun je EXCAMAD gebruiken - een extern beheerpaneel voor Camunda, een analogie van Cockpit, met krachtige functies. Processen bij incidenten worden rood gemarkeerd. Deze processen kunnen vanaf het gewenste punt worden aangepast of opnieuw worden gestart. U kunt bijvoorbeeld de benodigde variabele waarde in de context plaatsen en het proces herstarten vanaf het punt direct na het problematische punt. Dit is handig, eenvoudig en maakt handmatige probleemoplossing met minimale inspanning mogelijk.
Camunda staat bekend om zijn open-source platform en gebruiksvriendelijke interface en heeft talloze bedrijven in staat gesteld hun workflows te optimaliseren. Laten we een paar voorbeelden uit de praktijk bekijken.
Münchener Hypothekenbank eG, een onafhankelijke vastgoedbank ging over op het gebruik van de Camunda workflow engine om interne processen te verbeteren en te automatiseren, met name postverwerking en coördinatie tussen afdelingen voor het aanvragen van leningen. Voorheen was hun systeem rigide, niet flexibel en leidde het tot complexiteit waardoor het aantal fouten toenam.
In hun overgang naar een op Java gebaseerde microservicearchitectuur kozen ze Camunda op basis van interne aanbevelingen en werkten ze nauw samen met WDW Consulting Group. Sommige voordelen die ze onmiddellijk uit Camunda haalden, waren kant-en-klare functies, terwijl andere meer ontwikkeling vereisten. Deze overgang resulteerde in een gecentraliseerde takenlijst die door alle medewerkers wordt gebruikt en bood flexibiliteit om individuele processen te behouden zonder andere te beïnvloeden.
Het meest opvallende resultaat is een aanzienlijke verbetering in de verwerkingssnelheid van leningaanvragen. Dit komt zowel het personeel als de eindklanten ten goede. Als bewijs van het succes zijn andere afdelingen nu op zoek naar Camunda en de bank heeft zelfs meer ontwikkelaars aangenomen om de implementatie verder te ondersteunen.
SV Informatica, een dochteronderneming van SV SparkassenVersicherung, is gespecialiseerd in op maat gemaakte IT-oplossingen voor verzekeringsmaatschappijen. Ze namen Camunda op om verschillende processen over afdelingen heen te automatiseren, wat leidde tot opmerkelijke tijdbesparingen en verbeterde reactietijden voor klanten. Het bedrijf adopteerde Camunda in 2018 als oplossing voor hun zoektocht naar een effectieve tool voor het modelleren van bedrijfsprocessen, met een focus op het verbeteren van processen en het verbeteren van de samenwerking tussen IT en andere afdelingen.
Sinds de implementatie heeft Camunda taken geautomatiseerd zoals het annuleren van polissen van autoverzekeringen en het aanvragen van polisdocumenten. Een opmerkelijke prestatie was de 80% geautomatiseerde verwerking van online stormschademeldingen. Dit bleek vooral waardevol tijdens de overstromingen en stormen van 2021 in Duitsland. Tools zoals Camunda Optimize en Camunda Cockpit vergemakkelijken het bewaken en optimaliseren van processen.
In 2020 zal de SV Groep, dat actief is in Duitsland, Zwitserland en Oostenrijk, lanceerde een disruptief digitaal platform genaamd 'likeMagic' met hulp van Camunda. Dit platform zorgde voor een naadloze gastervaring, van boeken tot uitchecken, met als resultaat onder andere een 95% self-check-in/out rate en een 9 uit 10 gasttevredenheidsscore. De innovatie verminderde de behoefte aan personeel en integreerde platforms zoals Airbnb naadloos. SV Group zag het potentieel en bood 'likeMagic' aan andere horeca-aanbieders aan. Tegen 2023 zijn ze gegroeid van 2 naar meer dan 30 klanten in de DACH-regio, met plannen voor een breder Europees bereik en met als doel 15.000 kamers tegen het einde van het jaar.
Het transformerende potentieel van Camunda ligt niet alleen in de kernfunctionaliteiten, maar ook in het vermogen om bedrijfsactiviteiten op een fundamenteel niveau te herdefiniëren. In combinatie met Spring Boot opent het de deur naar naadloze integraties en verbeterde schaalbaarheid. Om het volledige potentieel van Camunda te kunnen benutten, is het van het grootste belang om de moeren en bouten van BPMN te begrijpen. Naarmate bedrijven evolueren in dit digitale tijdperk, onderscheiden tools zoals Camunda zich door het aanbieden van dynamische oplossingen die kunnen pivoteren en zich kunnen aanpassen aan steeds veranderende behoeften. Het gaat niet alleen om het automatiseren van processen, maar ook om het innoveren van workflows, het verbeteren van de efficiëntie en het behalen van tastbare resultaten die het verschil maken. Omarm de kracht van Camunda en laat uw bedrijf zweven naar nieuwe horizonten.
Beoordeel dit artikel:
4.8/5 (45 beoordelingen)
Gerelateerde inhoud
Na ontvangst en verwerking van uw aanvraag, nemen wij binnenkort contact met u op om uw projectbehoeften in detail te beschrijven en een NDA te ondertekenen om de vertrouwelijkheid van informatie te garanderen.
Na het bestuderen van de vereisten, stellen onze analisten en ontwikkelaars een projectvoorstel met de omvang van de werkzaamheden, teamgrootte, tijd en kosten schattingen.
Wij regelen een ontmoeting met u om het aanbod te bespreken en tot een overeenkomst.
We tekenen een contract en beginnen zo snel mogelijk aan uw project te werken.
Gerelateerde inhoud
© 2007-2024 Innowise. Alle rechten voorbehouden.
Innowise Sp. z o.o Ul. Rondo Ignacego Daszyńskiego, 2B-22P, 00-843 Warschau, Polen
Bedankt.
Uw bericht is verzonden.
Wij verwerken uw aanvraag en nemen zo spoedig mogelijk contact met u op.
Bedankt.
Uw bericht is verzonden.
We verwerken je aanvraag en nemen zo snel mogelijk contact met je op.