Backwards compatibility
Concept
Backwards compatibility betekent dat het bijwerken van configuratie-items lopende procesinstanties niet verstoort en geen waardevolle gegevens in bestaande dossiers vernietigt.
Uitgangspunten
Dossiertypes hebben een lange looptijd, variërend van enkele maanden tot enkele jaren.
Veel procesinstanties hebben eveneens een lange looptijd, variërend van een paar dagen tot een paar weken of maanden. Zelfs na het bijwerken van de workflow of andere configuratie-items moeten deze procesinstanties nog steeds veilig hun weg vinden naar een definitieve beëindiging.
Dossierinformatie blijft in de database lang nadat de bijbehorende procesinstantie is beëindigd. Bestaande gegevens mogen niet ongewild beschadigd of vernietigd raken door updates van configuratie-items.
Doel
In deze sectie leer je hoe de update van configuratie-items lopende procesinstanties en dossiergerelateerde gegevens beïnvloedt. Als analist en/of configurator helpt dit je bij het maken van een risicobeoordeling voor elk van je aanpassingen. Kunnen ze veilig worden gepusht? Of vormen ze een bedreiging voor de integriteit van processen en informatie? En zo ja, wat kun je doen om de schade te voorkomen of te beperken?
Procesdefinitie (workflow en beslissingstabellen)
Workflow updates
Workflows worden gedeployed naar de ingebouwde Camunda workflow engine. Terwijl dit gebeurt, worden ze geversioneerd. Elke procesinstantie luistert naar een specifieke versie van de workflow.
Workflow updates hebben by default geen invloed op lopende procesinstanties. Dit komt omdat elke procesinstantie luistert naar de versie van de workflow zoals die was op het moment dat de procesinstantie opgestart werd.
Je kunt hier twee dingen doen:
Als je niet wilt dat je bijgewerkte workflow invloed heeft op lopende procesinstanties, doe dan niets, want die instanties zullen nog steeds luisteren naar een vorige versie van de workflow.
Als je wel wilt dat je bijgewerkte workflow invloed heeft op lopende procesinstanties, dan moet je die instanties handmatig één voor één of in bulk migreren. Dit kan worden gedaan in Camunda cockpit. Als de nieuwe workflow versie nieuwe informatie vereist die niet aanwezig is in lopende procesinstanties, dan kun je deze informatie eventueel als parameter toevoegen aan je migratiecommando. Op basis van die parameter wordt vervolgens een procesvariabele aangemaakt.
Beslissingstabellen bijwerken
Beslissingstabellen worden gedeployed naar de ingebouwde Camunda workflow engine. Als dit gebeurt, worden ze geversioneerd. Elke business rule task die een beslissingstabel aanroept, luistert naar een specifieke versie van die beslissingstabel.
Door middel van de parameter Binding in de eigenschappen van de business rule task kun je configureren of de business rule task de versie van de beslissingstabel moet aanroepen zoals die was bij opstart van de procesinstantie (stel Binding in op Deployment), of de meest recente versie van de gerelateerde beslissingstabel (stel Binding in op Latest). Het is ook mogelijk om te verwijzen naar een specifieke versie (version of versionTag).
Als Binding is ingesteld op Latest moet je controleren of de update van je beslissingstabel compatibel is met lopende procesinstanties. Als de bijgewerkte tabel bijvoorbeeld een extra input waarde krijgt die niet aanwezig is in de dossiergegevens van lopende procesinstanties, dan zullen deze procesinstanties vastlopen op het moment dat de beslissing genomen moet worden.
Als Binding is ingesteld op Deployment moet je er rekening mee houden dat de update van je beslissingstabel alleen van kracht wordt voor nieuwe procesinstanties. Lopende procesinstanties zullen nog steeds luisteren naar de vorige versie van de beslissingstabel. Net als bij workflows blijft er een mogelijkheid om die instanties handmatig of in bulk te migreren. Dit kan worden gedaan in Camunda cockpit. In het geval dat de nieuwe versie van de beslissingstabel een extra input waarde vereist die niet aanwezig is in de lopende procesinstanties, kun je deze informatie toevoegen als parameter in je migratiecommando. Op basis van die parameter wordt vervolgens een input parameter voor de beslissingstabel aangemaakt.
Called workflows
Binnen het hoofdproces is het mogelijk om via een call activity een andere workflow binnen een (gelinkt) dossiertype aan te roepen. Updates van deze called workflows worden gedeployed naar de ingebouwde Camunda workflow engine. Als dit gebeurt, worden ze geversioneerd. Elke call activity die een dergelijke called workflow aanroept, activeert er een specifieke versie van.
Door middel van de parameter Binding in de eigenschappen van de call activity kun je configureren of de call activity de versie van de called worklflow moet aanroepen zoals die was bij opstart van de procesinstantie (stel Binding in op Deployment), of de meest recente versie van die called workflow (stel Binding in op Latest). Het is ook mogelijk om te verwijzen naar een specifieke versie (version of versionTag).
Als Binding is ingesteld op Latest moet je controleren of de update van de called workflow compatibel is met lopende procesinstanties. Als de workflow bijvoorbeeld een extra input waarde krijgt die niet aanwezig is in de lopende procesinstanties, dan zullen deze procesinstanties vastlopen op het moment dat de called workflow uitgevoerd wordt.
Als Binding is ingesteld op Deployment moet je er rekening mee houden dat de update van de called workflow alleen van kracht wordt voor nieuwe procesinstanties. Lopende procesinstanties zullen nog steeds verwijzen naar de vorige versie van de called workflow. Net als bij update van de main workflow blijft er een mogelijkheid om die instanties handmatig of in bulk te migreren. Dit kan worden gedaan in Camunda cockpit. In het geval dat de nieuwe versie van de called workflow een extra input waarde vereist die niet aanwezig is in de lopende procesinstanties, kun je deze informatie toevoegen als parameter in je migratiecommando.
Dossierdefinitie (dossiertype)
Formulieren bijwerken
Formulieren zijn niet onderhevig aan versiebeheer in Skryv.
Een bijwerking van formulieren heeft onmiddellijk invloed op de gegevensstructuur in de database voor zowel bestaande als toekomstige dossierinformatie.
Houd rekening met de volgende regels:
Verander nooit de key van een bestaand formulierveld.
Verander nooit het type van een bestaand formulierveld (bijvoorbeeld getal > tekst). Een getal waarde kan bijvoorbeeld gebruikt worden in berekeningen. Zodra je de waarde van een getal verandert in een tekst waarde, zullen deze berekeningen niet correct worden uitgevoerd.
Als je een formulierveld verwijdert, betekent dit dat de bijbehorende bestaande dossiergegevens niet meer worden weergegeven en niet meer beschikbaar zijn na het bijwerken. Doe dit nooit als die informatie cruciaal is voor de logica in je workflow of als die ergens in een expressie wordt gebruikt. Want in dat geval kunnen lopende en/of nieuw aangemaakte procesinstanties vastlopen. Let ook goed op als die informatie wordt gebruikt in andere configuratie-items:
Binnen een ander formulier of binnen een formulierveld: het risico bestaat dat die gelinkte velden ook onbruikbaar worden.
Binnen een communicatietemplate: documenten of e-mails worden weergegeven met een NULL waarde op de plek waar je de waarde van het formulierveld zou verwachten.
Binnen een beslissingstabel: de business rule task die de beslissing uitvoert, zal een fout retourneren, omdat de gegevens er gewoon niet zijn. Als gevolg daarvan zullen procesinstanties vastlopen.
Je kunt veilig een nieuw formulierveld toevoegen, maar weet dat bestaande dossiers een NULL waarde voor dat specifieke veld zullen vertonen. Zorg ervoor dat je unieke keys gebruikt (gebruik bijvoorbeeld ook geen key die je in het verleden hebt aangemaakt, maar een tijdje geleden hebt verwijderd).
Communicatietemplate bijwerken
Communicatietemplates worden niet geversioneerd in Skryv.
Een update van een communicatietemplate heeft geen invloed op communicaties (e-mails of documenten) die al gegenereerd zijn. Ze hebben alleen invloed op communicatie die na de update wordt gegenereerd of geregenereerd(*).
(*) Binnen een onvoltooide gebruikerstaak in de backoffice kun je de communicatie regenereren als er een bijgewerkte versie van de communicatietemplate is gedeployed.
Handmatig versiebeheer van formulieren of communicatietemplates
Houd er rekening mee dat dit workarounds zijn. Maak er slechts spaarzaam gebruik van, omdat ze extra complexiteit toevoegen die moeilijk te beheren is over de volledige levenscyclus van het dossiertype.
Formulieren en communicatietemplates zijn niet geversioneerd in Skryv. Het is echter mogelijk om zelf enkele aspecten van versiebeheer toe te voegen. Om dat te doen, kun je aan het begin van elke procesinstantie een versienummer bepalen en dat vastleggen in een procesvariabele.
Vervolgens gebruik je die variabele in je formulier om te bepalen of een formulierveld zichtbaar of verborgen moet zijn. Hetzelfde geldt voor communicatietemplates waar je met behulp van hulpfuncties inhoud voorwaardelijk kunt zichtbaar maken of verbergen. Dit kan beter zijn dan simpelweg een formulierveld toevoegen of verwijderen.
Je kunt ook expliciete kopieën maken van je formulieren of communicatietemplates. Vervolgens bepaalt een exclusive gateway in de workflow welk pad genomen moet worden op basis van het versienummer dat is opgeslagen in de procesvariabele. Elk pad leidt naar een andere kopie van het formulier of de communicatietemplate.
Conclusie
Bijwerken van configuraties is mogelijk. Meer nog, deze flexibiliteit is een van de key functies van Skryv. Maar hou er rekening mee dat aan iedere update steeds een zeker risico kleeft. Verreweg het grootste risico wordt gevormd door het verwijderen of wijzigen van een bestaand formulierveld, omdat dit veel schade kan aanrichten, vooral als dat formulierveld op meerdere plekken wordt aangesproken binnen de workflow of zelfs binnen andere configuratie-items.