Corrigeer Belang

Casusbeschrijving

In deze casus wordt een correctie verwerkt op een Belang waarbij een verkeerde persoon was gekoppeld als eigenaar aan een WOZ-object. Aangezien correctie een complex proces veronderstellen we dat een domein-expert het te corrigeren Belang heeft geraadpleegd en dus het belangId bekend is. Dit belangId is van het correctie_commando.

Alhoewel de identificatie van de persoon (partijId) geen onderdeel is van de technische sleutel wordt in dit geval geen correctie uitgevoerd op de waarde van de partijId. Dit omdat de partijId, samen met het wozObjectnummer samen de functionele sleutel van het Belang vormen. Het laten vervallen van het oude Belang en het registreren van een nieuw Belang doet in dit geval de aard van de correctie het meeste recht aan.

In het commando waarmee deze wijziging wordt doorgevoerd is dus het belangId opgenomen van het Belang dat komt te vervallen. Daarnaast zijn de gegevens opgenomen waarmee een nieuw Belang kan worden geregistreerd. In dit geval is de Partij die aan het nieuwe Belang is gekoppeld reeds bekend.

De situatie dat er een nieuwe Partij moet worden geregistreerd is in deze casus niet geïmplementeerd, maar die is wel beproefd in de casus Overdracht eigendom en/of beperkt recht.

Notificatie

De verwerking van een notificatie tot commando’s, effecten (verwerkingsstappen? , gevolgen?) en claims is uitgewerkt in onderstaand overzicht. Dit bericht betreft een informatierijke notificatie.

Van notificatiebericht naar commando

Van het binnenkomende notificatiebericht moet worden vastgesteld dat het een valide notificatiebericht zou kunnen zijn en geen onderdeel is van een DDOS-aanval of input bevat die onmogelijk verwerkbaar zou kunnen zijn.

Als het bericht ontvangen is vinden de volgende bewerkingstappen plaats.

Notificatieverwerker ontvangt notificatiebericht voert de volgende stappen uit:

• Controleert op verwerkbaarheid
  • Registreert ontvangstmoment, type en inhoud
  • Valideert of bericht voldoet aan schema
  • Valideert of het bericht semantisch interpreteerbaar is.
• Produceren en registreren van het commando.
  • Zet het bericht om in een commando in een intern verwerkbaar formaat.
  • Legt middels een context-annotatie de relatie tussen het geproduceerde commando en de notificatie.
  • Verzendt commando naar commandohandler.

Noot: De Notificatieverwerker is niet geïmplementeerd in het prototype. Het omzetten van XML naar Json is niet nieuw en er is voor gekozen om deze stap over te slaan. De werkende casus begint dus vanaf het commando.

Command

command_str = """
        {
            "command": {
                "commandId": "56fccbdf-a279-4598-8bd4-58a4077bf67c", 
                "commandType": "corrigeer_belang"
                },
            "data": {
                "belang_vervallen": {
                    "belangId": "51e45c80-7484-49d8-aad4-9be044453bb0",
                    "wozObjectnummer": "e8d5375b-0a30-46b4-ab62-ac6b8ca10bf6",
                    "partijId": "4bec755e-d9de-43fd-8c6b-cca75fd1a41d"
                },
                "belang_toevoegen": {
                    "geldigVanaf":"2025-03-09T11:05:00Z",
                    "partijId": "00e976f3-310e-455d-8d23-dd08774e2c15",
                    "wozObjectnummer": "d6b33e05-a6ea-43d7-b9d0-7380c74e3c39",
                    "aandeel": "70",
                    "soortBelang": "eigenaar",  
                    "aardZakelijkRecht": "606"
                }
            }
        }   
        """

Commando Corrigeer Belang wordt gepersisteerd door claims voor het objecttype “Commando” vast te leggen in het commando-register.

In deze weergave is er voor gekozen om de waarde van de rol content in te korten, anders zou er geen goede weergave te tonen zijn. Daarnaast is het belangrijk te weten dat de waarde van de rol content als Base64 is vastgelegd en die inhoud wordt hier onbewerkt getoond (en is dus niet interpreteerbaar door mensen)

Van commando naar effecten.

Comandohandler corrigeer_belang heeft als doel het commando dat opgesteld te transformeren naar effecten (gevolgen?) die op het WOZ-register impact hebben.

Om deze effecten (gevolgen?) samen stellen vinden de volgende bewerkingsstappen plaats:

1. Commandhandler corrigeer_belang ontvangt commando corrigeer_belang

2. Commandohandler corrigeer_belang interpreteert inhoud van commando corrigeer_belang

   • Inhoud is (semantisch) niet interpreteerbaar -> registreert semantische error (“Commando is niet interpreteerbaar”)
   • Inhoud is (semantisch) interpreteerbaar -> registreert resultaat (“is wel interpreteerbaar”) en verder naar productie commando in de WOZ-context.

3. CommandoHandler corrigeer_belang maakt effecten aan die als verwerkingsstappen die aangeboden kunnen worden aan de register-engine.

   De volgende effecten (gevolgen) worden samengesteld op basis van het commando corrigeer_belang.

   • Het bestaande Belang met het belangId zoals dat is opgenomen in het commando wordt opgezocht en beëindigd.
   • Er wordt een nieuw Belang geregistreerdIndien een Partij nog niet bekend is in het WOZ-Register wordt deze partij geregistreerd (inclusief Partij-identificator indien aangeboden).
   • De nieuwe belangen worden geregistreerd.

4. De effecten (gevolgen) worden geregistreerd. - Het inhoud van ieder effect wordt geregistreerd. - De relatie naar commando corrigeer_belang wordt vastgelegd.

Lineage

Het weergeven van de lineage kan gedaan worden door het commandId op te geven van het commando waarvan de lineage gewenst is en vervolgens “make lineage” uit te voeren.

Hiermee worden alle commands, gevolgen en claims in beeld gebracht die als gevolg van het uitvoeren van een command zijn geregistreerd. (Zie de Readme van de poc-python repository hoe deze moet worden uitgevoerd).

Bij de lineage zijn er drie typen weergave beschikbaar:

• Alleen de rollen en hun waarden. Dit is een compacte weergave die vergelijkbaar is met de weergave van een object met bijbehorende attrubiten en hun waarden.
• Volledige claimexpressies in state-vorm –> Deze weergave is alleen mogelijk als vul_partijen is verwerkt met schema_variant=“structure_state.gql” (regel 27). Deze weergave geeft de complete claims weer waarbij de tekst geformuleerd is in tegenwoordige tijd. Hiermee wordt de “state"van het object en de bijbehorende attributen geformuleerd.
• Volledige claimexpressies in event-vorm –> Deze weergave is alleen mogelijk als vul_partijen is verwerkt met schema_variant=“structure_event.gql” (regel 27). Deze weergave geeft de complete claims weer waarbij de tekst geformuleerd is als iets dat gebeurd is. Hiermee hebben we gezocht naar een event-achtige benadering van atomic claims.

Op basis van deze weergaven hebben we het besluit Claimtype expressies worden in “state” uitgedrukt genomen.

De lineage geeft de context weer tussen command, gevolgen en claims per objecttype. Om de lineage te kunnen weergeven is ieder claim (ook annotaties) voorzien van een context-annotatie die verwijst naar het commando of het gevolg dat geleid heeft tot het vastleggen van deze claim. De context wordt in dit overzicht gerepresenteerd door de lijnen tussen de blokjes. Alle individuele context_annotaties van een gegroepeerd object zijn dus geconsolideerd in 1 verbindings-lijn.

Lineage-roles

In deze weergave worden alleen de claimroles met hun waarden getoond. (Klik op de afbeelding voor grotere weergave op mermaid.live. Daar wordt ook de mogelijkheid geboden om full-screen weer te geven en in te zoomen. )

Lineage-state

In deze weergave worden de volledige claim-expressies in de “state”- variant getoond. (Klik op de afbeelding voor grotere weergave op mermaid.live. Daar wordt ook de mogelijkheid geboden om full-screen weer te geven en in te zoomen. )

Lineage-event

In deze weergave worden de volledige claim-expressies in de “event”- variant getoond. (Klik op de afbeelding voor grotere weergave op mermaid.live. Daar wordt ook de mogelijkheid geboden om full-screen weer te geven en in te zoomen. )

De relevante objecten nadat het commando is verwerkt

Vervallen Belang en nieuw Belang

Let hierbij op dat het reeds bestaande Belang een Expired annotatie heeeft gekregen om aan te geven dat de registratie vervallen is. Er is voor gekozen om niet alle claims individueel van een Expired-annotatie te voorzien, maar alleen op de ExistentiePostulerende claim deze annotatie toe te voegen.

Ook zie je dat het nieuwe belang een validFrom-annotatie heeft die exact hetzelfde geldigheidmoment aangeeft als de validFrom-annotatie van het vervallen Belang.