5 cruciale tips voor je eerste Bizagi-project

Bizagi is voor veel bedrijven een kostenefficiënte manier om hun processen te digitaliseren en bestaande systemen met elkaar te laten spreken. Daarom zou je Bizagi een rapid development tool kunnen noemen, waarbij je snel volledig werkende prototypes neer kunt zetten. Vlieg het echter niet te iteratief en exploratief aan.

Het gevaar zit erin dat ontwikkelaars in die sfeer van prototyping wat kort door de bocht gaan in het ontwerp. Waar je bij andere programma’s nog een gecontroleerde refactoring op het niveau van de code kunt doen, zul je er in Bizagi Studio heel veel clicks voor over moeten hebben om hetzelfde te bereiken. Bepaalde componenten, zoals de namen van entiteiten, zijn überhaupt nooit meer aanpasbaar. Daarom geven we je vijf cruciale tips voor je eerste Bizagi-project, gebaseerd op de documentatie van Bizagi en eigen inzichten:


1. Gebruik prefixes voor entiteiten en attributen


Bij de aanmaak van entiteiten stelt Bizagi de naam van de entiteit gelijk aan de display name. We raden aan om de naam van elke master entity echter te starten met ‘M_’, elke parametric entity met ‘P_’ en elke stakeholder entity met ‘S_’. Zo zul je op databaseniveau de tabellen ook makkelijk terugvinden tussen de tabellen van Bizagi zelf. Wanneer je een nieuw project start, raden we je dan ook aan om via de expert view éérst je eerste master entity te maken. Als je de standaardflow volgt, zal Bizagi een master entity met de procesnaam aanmaken en ontbreekt het prefix ‘M_’ al meteen. Verder raden we het enkelvoud aan voor alle entiteiten.


Als een master entity of parametric entity slechts geldig is voor één proces, kun je een tweede prefix toevoegen dat naar dat proces verwijst. Zo kan men bij volgende processen goed inschatten of men een tabel mag hergebruiken. Noem een tabel niet zomaar ‘P_Procedure’ terwijl het slechts om één soort procedure gaat, of stel hem algemener op zodat hij later kan worden hergebruikt.


Bij de aanmaak van attributen raden we aan een prefix te gebruiken dat overeenkomt met het type van het attribuut. Het sorteert enorm handig en brengt duidelijkheid in expressies:

  • ‘b’ voor booleaans (bijvoorbeeld bApproved)

  • ‘c’ voor geldwaardes met als suffix de munteenheid (bijvoorbeeld cPriceEUR)

  • ‘d’ voor datums, zo kun je het woord date weglaten (bijvoorbeeld dApproved)

  • ‘i’ voor gehele getallen

  • ‘s’ voor strings

  • ‘u’ voor bestanden

  • ‘f’ voor kommagetallen

  • ‘km’ voor een gekoppelde master entity (bijvoorbeeld kmCustomer)

  • ‘kp’ voor een gekoppelde parametric entity (bijvoorbeeld kpStatus)

  • ‘x’ voor collecties met hier wel de meervoudsvorm van de gekoppelde master entity (bijvoorbeeld xApprovals, xItems)

2. Maak het Engels leidend en hou vertalingen altijd bij de bron


Hoewel het doelpubliek van de applicatie misschien niet eens Engelstalig is, raden we je aan alle names en display names in het Engels te schrijven. Stel een tabel op met alle vertalingen die je nodig zult hebben, zodat het invoeren van attributen in het datamodel snel kan gaan en je zeker weet dat elk attribuut reeds vertaald is. Doe dit op voorhand tijdens de analyse.


Afgezien van UI controls die niet aan een attribuut van je datamodel gekoppeld zijn (bijvoorbeeld een extra label, een knop, een groupkader…), mogen vertalingen nooit binnen een formulier gebeuren, maar altijd op het ‘Edit attributes’-scherm van het datamodel. Weet dat je vanuit een formulier ook snel naar het datamodel kunt doorklikken.


3. Geef expressies altijd een naam, zelfs al heb je haast


Expressies die je opstelt binnen een formulier, bijvoorbeeld om de zichtbaarheid, aanpasbaarheid of het verplicht moeten invullen van een element in te stellen, stel je vaak redelijk snel in. We raden je evenwel aan om 'herbruikbaar' aan te duiden, zodat je zelf een naam kunt kiezen, want geef toe ‘boolexp0123’ zegt weinig. Kies een naam die het 'hoe' benadrukt, eerder dan het 'wat'. Zo is ‘ifUserIsCaseCreator’ een veel geschiktere naam dan ‘setEditabilityOfFieldX’.


4. Stel standaard een business key in voor parametric entities

Wij voegen standaard een attribuut met naam ‘sCode’ en display name ‘Code’ toe aan elke parametric entity, waarna we via de advanced properties van de entiteit dat attribuut als business key selecteren. Dit veld is uitermate geschikt om bijvoorbeeld de 3-lettercodes van landen of munteenheden te bevatten, zodat je er in een expressie snel naar kunt verwijzen. Refereer nooit naar een ander veld in de code, en als je aanpassingen via het work portal toestaat, zet het Code-veld op read-only via een custom edit form (ook bij de advanced properties in te stellen).


5. Bedenk voor je aan je project begint al een tracing syntax en pas dit rigoureus toe binnen elke expressie


CHelper.trace is tijdens het ontwikkelen de methode om inzicht te krijgen in expressies waarbinnen iets fout loopt. Bizagi laat je vrij naar welk bestand je dit wegschrijft, en wat de inhoud van de trace zal zijn. Je kan op die manier dynamisch een logbestand per proces laten genereren door gebruik te maken van Me.Case.ProcessDefinition.Name. Verder neem je standaard het beste de ingelogde gebruiker en het dossiernummer mee in de log, via Me.Case.WorkingCredential.FullName en Me.Task.DisplayName. Definieer telkens een variabele met de naam van de huidige expressie. Weet ook dat je ‘enters’ kan afdwingen via Environment.NewLine om tot een uitgebreide en leesbare log te komen. Je kunt er ook voor kiezen om het dossiernummer naar de bestandsnaam weg te schrijven, zodat je alle traces voor hetzelfde dossier bij elkaar houdt. Vooraf dus even over nadenken.

BE IN THE KNOW. GET X-RAY.

X-RAY is our e-zine bringing you the latest insights and use cases in the fields of human-centered automation, cognitive computing, AI, and other game-changing technologies. Read out latest edition here.