In de vorige aflevering van onze Monopoly serie, hebben we een begin gemaakt met de screen flow waarmee je je beurt uitvoert als speler.

We hebben het werpen van de dobbelstenen en het verplaatsen van de speler naar een nieuwe positie gebouwd en de regels voor dubbele worpen toegepast in de flow.

Nu is het tijd om te kijken naar de vervolgstappen. Wat moet er gebeuren wanneer de speler aankomt op een nieuw veld?

De volgende scenario’s zijn mogelijk:

1. De speler komt op een belasting vakje en moet geld betalen aan de bank
2. De speler passeert of belandt op Start en moet geld krijgen van de bank
3. De speler komt op Kans of Algemeen Fonds terecht en de regel op de bovenste kaart van de stapel is op hem van toepassing
4. De speler komt op een straat, station of nutsbedrijf terecht dat nog te koop is en mag beslissen om die Asset te kopen
5. De speler komt op een straat, station of nutsbedrijf dat al in het bezit van een andere speler is en moet huur betalen

Voor de eerste twee ligt de oplossing voor de hand. Deze vakjes hebben elk één Position Rule. De Rule die daarmee aan de Position gekoppeld is, kan gebruikt worden om de actie uit te voeren die bij die Rule hoort.

Om het overzichtelijk te houden wil ik waar mogelijk deelprocessen isoleren en daarvoor op zichzelf staande subflows ontwerpen.

Wanneer er een web aan subflows ontstaat, is het nuttig om dat te documenteren, zodat je snel kunt zien welke flow wanneer wordt gebruikt.

Laten we onze subflows gaan bouwen voor het uitvoeren van een Position Rule.

Screenflow voor uitvoeren Position Rule

Omdat we ook binnen dit deelproces informatie aan de speler willen tonen op het scherm, ontwerpen we deze flow als een Screenflow.

Deze flow zal alleen maar als Subflow worden gebruikt, dus we kunnen zelf duidelijke namen bepalen voor onze input variabelen.

Voor het uitvoeren van een Rule hebben we nodig:

• De Rule record variabele
  • Naam: inputRule
  • Type: record
  • Object: Rule__c
  • Available for input: aangevinkt
• De Player record variabele
  • Naam: inputPlayer
  • Type: record
  • Object: Player__c
  • Available for input: aangevinkt

Er zijn 4 typen regels:

• Move Number of Steps
• Move to Position
• Pay Money
• Receive Money

Hoewel ik in de vorige editie heb gezegd dat ik beslissingen met meerdere uitkomsten altijd wil vermijden, wil ik in dit geval toch een tak voor elk type Rule hebben.

Ik verwacht dat het hier niet tot veel onduidelijkheid zal leiden. Ook wil ik de lezer van de flow veel scrollen besparen door de 4 scenario’s niet in serie onder elkaar te zetten. Omdat Rules zelf al data zijn die de werking van de automatisering sturen, wil ik daar niet nog weer een metadata laag van regels die bepalen hoe om te gaan met Rules bovenop zetten. Dan maak ik het onnodig complex.

Laten we elk van deze 4 routes nu gaan invullen.

Move Number of Steps

Wanneer een kaart een aantal stappen vooruit of achteruit vanaf de huidige Position voorschrijft, moeten we de position bij dat Index nummer ophalen, de Position van de inputPlayer updaten en het de speler in een scherm laten weten.

Bij het bepalen van de Index van de Position waar de Speler naartoe moet, moeten we weer rekening houden met de mogelijkheid dat de speler voorbij Start gaat.

Er is alleen een kans kaart die de speler 3 plaatsen achteruit laat gaan en geen van de 3 eerste vakjes is Kans, dus we hoeven voor de uitvoering van deze Rule geen rekening te houden met wel of niet via Start reizen.

In het pad voor Move number of steps zullen we dus het volgende plaatsen:

• Get Records element om de Position op te halen waar de Player naartoe moet
• Update Records element om de Position van de Player te wijzigen
• Screen element om de speler te laten zien wat de Regel is die wordt uitgevoerd en wat het effect is dat die heeft

Null Check

Een goede gewoonte is om een Null check in te bouwen na elk Get Records element in een flow. Controleer even of de query wel een resultaat heeft opgeleverd, voor je die hier opgehaalde record variabele verder gaat gebruiken in je flow.

Dat doe je met een Decision element. De test in het element is <get records element> is Null false. Is het antwoord daarop true dan is er dus wél een record gevonden en kun je die verder gebruiken. Is de uitkomst echter false, dan moet je daar de flow afbreken met liefst een heldere foutmelding voor de gebruiker, omdat je zonder die record niet de rest van de flow optimaal kunt uitvoeren.

Move to Position

In het geval dat de Rule letterlijk voorschrijft, via de Position lookup naar welke Position de Player verplaatst moet worden, is geen Get Records element nodig.

Wat we wel nog even moeten checken, áls de speler via Start mag reizen (dat geeft de Rule ook aan), óf de speler inderdaad langs Start gaat op weg naar de voorgeschreven Position.

We plaatsen die Decision als eerste element in dit pad.

De speler zou via Start reizen als hun huidige positie op het bord ná de Destination van de Rule ligt en dus een hogere waarde voor Index__c heeft. We hoeven daar alleen maar op de controleren als de speler van de Rule via Start zou mogen reizen. Daarom ziet de Decision er als volgt uit.

Als de speler via Start is gereisd, moet naast het updaten van de Position van de Player ook de Cash Balance van de Player verhoogd worden met 20.000.

Hierna updaten we de Position op de Player record

Tot slot tonen we de speler het scherm met de Rule die wordt uitgevoerd. Als de speler hierbij langs Start komt, wordt ook het tweede Display text element zichtbaar.

Pay Money

Wanneer de speler moet betalen, bepaalt de Rule het bedrag en de ontvangende partij. Het bedrag moet dus van de Cash Balance van de Player worden afgetrokken en moet daar bij de tegenpartij bij worden opgeteld. Omdat beide records van hetzelfde object zijn, voeg ik ze samen aan een Record Collection variabele toe en update ik de beide records in één Update Records element.

Voor het scherm bij deze route kopiëren we eerst het scherm van een van de twee eerder gemaakte paden en passen de kopie aan.

Receive Money

Wat er moet gebeuren bij dit pad, lijkt grotendeels op wat we moeten doen bij Pay Money, dus we kopiëren eerst alle elementen van dat pad en gaan ze dan een voor een aanpassen.

1. Klik eerst op Select Elements
2. Klik de 3 elementen aan die we willen kopiëren
3. Klik op het klembord icoon om ze alledrie te kopiëren

Klik op de + onder het Receive Money pad en klik op Paste 3 Elements.

Bij het Assignment element passen we het label, de API name en de eerste twee operators aan, omdat het geld nu niet van de actieve Player naar de tegenpartij gaat, maar in de omgekeerde richting.

Bij het Update Records element, hoeven we alleen het label en de API name aan te passen. Vooral omdat dat “Copy 1 of” niet mooi is, want functioneel is het niet eens echt nodig.

In het Screen element passen we ook het label en de API naam aan van het scherm zelf en van het Display Text element en we passen een paar woorden in de tekst aan plus het custom label van de Finish knop.

Afronden

Onze subflow om het effect van een Rule te verwerken en de speler te laten zien wat er gebeurt is klaar. We slaan hem op en activeren de flow.

Ik gebruik weer mijn vaste voorvoegsel om in een oogopslag te zien wat voor type flow het is en noem deze flow SCR – Execute Rule. Je kunt overigens het beste de flow tijdens het bouwen regelmatig tussentijds opslaan.

• Record Triggered Flows: RTF
• Autolaunched Flows: ALF
• Platform Event Triggered Flows: ETF
• Scheduled Flows: SCH
• Screen Flows: SCR

Nu is het nog nodig om deze subflow op te nemen in de hoofdflow, zodat na het arriveren op een nieuwe Position de Rule die daarbij hoort ook uitgevoerd kan worden. Dat gaan we in het volgende deel doen. Daarbij gaan we ook meteen in op hoe het werkt als de Position een Kans of Algemeen Fonds vakje is waarbij de Rule die uitgevoerd moet worden eigenlijk de bovenste kaart van een stapel is.

In de delen daarna zullen we aan de slag gaan met Assets kopen van de bank en huur betalen.