Waarom zou je overwegen om over te stappen naar Camunda 8?
Welke technische en functionele aspecten moet je in overweging nemen?
Hoe pak je de migratie aan op het gebied van modellen, formulieren, applicatiecode en historische data?
Ontdek in deze blog hoe deze nieuwe versie van Camunda de manier waarop je bedrijfsprocessen beheert, kan transformeren.
De migratie naar Camunda 8
Waarom niet meteen migreren naar Camunda 8?
Hoe migreer je van Camunda 7 naar Camunda 8?
Modellen
Formulieren
Applicatiecode
(Historische) data
Wat als je later pas wilt overstappen naar Camunda 8?
Conclusies
De migratie naar Camunda 8
De overgang van Camunda 7 naar 8 brengt enkele belangrijke conceptuele veranderingen met zich mee, waardoor het migratieproces complexer kan worden. In deze blog duiken we dieper in op de redenen voor migratie, de uitdagingen die je kunt tegenkomen, en geven we een gedetailleerde blik op het migratieproces zelf.
Er zijn enkele conceptuele veranderingen die de migratie van Camunda 7 naar 8 enigszins kunnen compliceren, zoals:
- Camunda 8 is een stand-alone oplossing en staat niet toe dat je de engine integreert zoals bij Camunda 7.
- In Camunda 7 kan je verschillende datatypes opslaan, waaronder geserialiseerde Java-objecten. Camunda 8 daarentegen ondersteunt enkel primitieve datatypes en JSON-opslag.
- Camunda 7 maakt gebruik van JUEL als expressie-taal, terwijl Camunda 8 FEEL gebruikt.
Waarom zou je overwegen om zo snel mogelijk over te stappen naar Camunda 8? Als je aan de start staat van een nieuw project, is het sterk aan te raden om meteen te kiezen voor Camunda 8. Begin je nu met Camunda 7, dan moet je in principe vanaf het begin rekening houden met de werking en principes van Camunda 8, aangezien je binnenkort toch de overstap zult moeten maken.
Het wordt in het algemeen aangeraden om bestaande projecten, die momenteel gebruikmaken van Camunda 7, zo snel mogelijk migreren naar Camunda 8. Deze aanbeveling is gebaseerd op het feit dat Camunda 8 in de toekomst de meeste innovaties en updates zal krijgen. Daarom is het raadzaam om de overstap te maken.
Waarom niet meteen migreren naar Camunda 8?
Er zijn natuurlijk geldige redenen om niet onmiddellijk over te stappen:
- Vanuit een technisch oogpunt: Sommige functies zijn nog niet beschikbaar in Camunda 8, zoals enkele BPMN-elementen. Voor de meeste gevallen is er een work-around beschikbaar, maar in sommige gevallen is het eenvoudiger om even geduldig te wachten tot de functie in Camunda 8 beschikbaar is.
- Vanuit een functioneel oogpunt: Na een investering in Camunda 7 en je omgeving optimaal functioneert, kan het een grote, nieuwe investering zijn om over te stappen naar Camunda 8. Camunda 7 zal actief worden onderhouden en ontwikkeld tot April 2027, waarna ook nog steeds uitgebreide ondersteuning beschikbaar zal zijn.
Hoe migreer je van Camunda 7 naar Camunda 8?
Als we het even op een meer overkoepelend niveau bekijken, welke componenten zijn er dan betrokken bij een migratie?
- Modellen, zoals BPMN en DMN
- Formulieren
- Applicatiecode, die de API gebruikt
- (Historische) data
Modellen
Het gaat nog steeds over BPMN en DMN, maar er zijn een paar verschillende extensies. Er is een converter beschikbaar om hierbij te helpen (https://github.com/camunda-community-hub/camunda-7-to-8-migration/tree/main/backend-diagram-converter).
Eén van de meest significante veranderingen is het niet meer ondersteunen van CMMN modellen in Camunda 8. Het is dus niet meer mogelijk om deze modellen te maken, te migreren of uit te voeren, waardoor de migratie complexer wordt.
Een deel van het model is de expression language, en deze verandert bij een overstap van Camunda 7 naar 8. In Camunda 7 was dit JUEL, Camunda 8 daarentegen gebruikt FEEL.
Zowel JUEL (Java Unified Expression Language) en FEEL (Friendly Enough Expression Language) zijn expressie-taal standaarden, maar ze hebben verschillende toepassingen en doelen. JUEL is ontworpen om te gebruiken in Java-gebaseerde technologieën en frameworks. Het is een op Java-gebaseerde expressie-taal die wordt gebruikt om dynamische expressies in Java-applicaties te evalueren. FEEL is ontworpen als expressie-taal die leesbaar is voor niet-technische gebruikers. Het is bedoeld voor het modelleren van beslissingslogica in begrijpelijke taal, waardoor zakelijke analisten en belanghebbenden betrokken kunnen worden bij het definiëren van regels en logica.
Met de overgang van JUEL naar FEEL moet de expressie-taal van je modellen dus ook worden aangepast. Dat kan complexer zijn wanneer bijvoorbeeld de JUEL-expressie verwijst naar Java of een Spring bean. Vermits dit niet mogelijk is met FEEL, moet het model worden aangepast.
Er is ook impact op de service-taak. Een service-taak in Camunda 7 kan verschillende implementaties hebben, namelijk:
- Extern
- Java-klasse
- Expression
- Delegate expression
- Connector
Voor een service-taak in Camunda 8 moet je de taskDefinition definiëren die een jobworker specificeert, of een connector gebruiken die vanaf nul kan worden opgebouwd, of één van de connectors gebruiken die door Camunda worden geleverd. Deze verandering in de implementatie van service tasks van Camunda 7 naar 8 heeft niet alleen betrekking op de diversiteit van beschikbare implementaties, maar heeft ook directe impact op de complexiteit van de migratie. Het is van cruciaal belang om zorgvuldig de verschillen te begrijpen en de benodigde aanpassingen te maken om een soepele en succesvolle overgang naar Camunda 8 te waarborgen.
Formulieren
Er zijn verschillende soorten formulieren in Camunda, elk met een verschillende migratieaanpak:
- Als je de formulieren zelf hebt gebouwd, moet je de nieuwe API gebruiken.
- Als je Camunda-formulieren hebt gebruikt, worden ze ondersteund in zowel Camunda 7 als Camunda 8.
- Andere formulier technieken van Camunda 7 worden niet ondersteund in Camunda 8.
Het is dus belangrijk om even te bekijken hoe je jouw formulieren binnen Camunda 7 hebt opgebouwd voor je de overstap maakt naar Camunda 8.
Applicatiecode
Camunda 8 gebruikt een andere API dan Camunda 7, waarbij er verschillende API's voor verschillende zaken zijn. In de toekomst kan er een client zijn die op al deze API's insluit, zodat de ontwikkelaarservaring beter wordt. Het veranderen van de library en het bijwerken van de dependencies, zou de ontwikkelaar sneller inzicht moeten geven in wat er moet worden aangepast.
Wat betreft de service-taken zijn er in Camunda 8 geen Java-klassen, expressions of delegate expressions beschikbaar. Hierdoor is er wat herwerking nodig van de code die deze service-taken implementeert. Er is een community-extensie om bestaande code te hergebruiken en aan te passen aan Camunda 8. Dit werkt voor eenvoudige of typische gevallen en moet met zorg worden gebruikt (https://github.com/camunda-community-hub/camunda-7-to-8-migration/tree/main/camunda-7-adapter).
In Camunda 7 kan de applicatiecode worden geïntegreerd in de engine, wat de mogelijkheid biedt om code binnen de engine uit te voeren en toegang te krijgen tot de internal state. In Camunda 8 kan dit echter niet. Hier is er een duidelijkere scheiding zijn tussen de bedrijfslogica en de engine, wat potentieel uitdagend kan zijn bij het herzien van hoe jouw applicatiecode in Camunda 8 integreert met de engine.
Als er veel veranderingen in de gehele toepassing nodig zijn, is het misschien een goed idee om de architectuur van de volledige toepassing opnieuw te beoordelen. Hoewel dit de migratie-inspanning kan vergroten, biedt dit een uitgelezen kans om de architectuur opnieuw te evalueren.
(Historische) data
Wat gebeurt er met jouw data in een Camunda 7-productiesysteem? Voor de runtime-gegevens is er geen migratiescript beschikbaar, waardoor het niet eenvoudig is om data te migreren. Er bestaat echter wel een procedure om gegevens uit Camunda 7 te lezen en een nieuw procesinstantie te starten in de juiste staat in Camunda 8 (https://github.com/camunda-community-hub/camunda-7-to-8-migration/tree/main/process-instance-migration).
Historische data kan niet simpelweg gemigreerd worden van Camunda 7 naar Camunda 8. Als je wilt dat jouw historische gegevens worden gebruikt voor bedrijfsanalyses, kun je Camunda Optimize gebruiken voor zowel Camunda 7 als Camunda 8. Je kunt gegevens exporteren vanuit Camunda 7 naar Optimize en vervolgens gegevens vanuit Camunda 8 in dezelfde Optimize-instantie pushen.
Vanuit operationeel oogpunt blijven de historische data nog steeds in de database staan, maar wanneer je overschakelt naar Camunda 8 en Camunda 7 uitschakelt, zal het niet van grote waarde meer zijn.
Wat als je later pas wilt overstappen naar Camunda 8?
Als het momenteel niet mogelijk is om te migreren, maar toch al wijzigen moet aanbrengen in jouw Camunda 7-configuratie, is het een goed idee om alvast rekening te houden met Camunda 8. Overweeg hierbij bijvoorbeeld:
- Integreer de applicatiecode niet direct in de engine
- Vermijd JUEL-expressies die verwijzen naar een Java-klasse,
- Beperk de toegankelijkheid van de Camunda API
- Maak gebruik van primitieve variabelen of JSON
- Geef de voorkeur aan het gebruik van Camunda-formulieren
- Vermijd het gebruik van CMMN
- ...
Conclusies
Camunda 8 hanteert een volledig andere architecturale benadering voor het uitvoeren van processen. Het heeft meer “separation of concern”, omdat de business logica niet direct integreerbaar is in de engine.
Indien jouw Camunda 7 project dus sterk is geïntegreerd in de engine en veel service-taken gebruikt met verwijzingen naar Java-klassen, of als het gebruik maakt van delegate expressions, zal de migratie aanzienlijk complexer worden. Dit geldt niet zozeer voor het migreren van de modellen zelf, maar wel voor de onderliggende applicatiecode.
De overstap biedt echter de mogelijkheid om kritisch naar de toegepaste architectuur te kijken. Waar kan deze verbeterd worden? Of hoe kan je de applicatiecode flexibeler maken voor toekomstige wijzigingen.
Zelfs als Camunda 7 nog lang zal worden ondersteund (tot April 2027), is het een goed idee om nu al na te denken over de migratie. Zelfs als de migratie niet onmiddellijk gepland staat, zijn er tal van "best practices" die meteen kunnen worden geïmplementeerd op de huidige Camunda 7-projecten. Dit maakt het project gemakkelijker te onderhouden en zal de onvermijdelijke migratie vergemakkelijken.
Heb je nog vragen over dit artikel? Aarzel niet om ons even te contacteren.