[Phoenix] DSI migratie SSO

[De Blende Christophe]

Eens we weten welke model veranderingen er gaan zijn, dan lijkt het mij pas zinvol.
________________________________
Van: Heyvaert Geert <geert.heyvaert at vlaanderen.be>
Verzonden: donderdag 19 mei 2022 7:56
Aan: De Blende Christophe <christophe.deblende at vlaanderen.be>; phoenix at list.omgeving.vlaanderen.be <phoenix at list.omgeving.vlaanderen.be>
Onderwerp: Re: DSI migratie SSO

Misschien ook al best Willem betrekken in het overleg? Of te vroeg?


Met vriendelijke groeten,

Geert Heyvaert

Programma Gebiedsontwikkeling en Teamlead Phoenix

Vlaamse Overheid

DEPARTEMENT OMGEVING

Afdeling Strategie, Internationaal, Digitaal en Organisatie (SIDO)

Mobiel +32 476 980 386

e-mail  geert.heyvaert at vlaanderen.be<mailto:geert.heyvaert at vlaanderen.be>

________________________________
Van: Phoenix <phoenix-bounces at list.omgevingvlaanderen.be> namens De Blende Christophe <christophe.deblende at vlaanderen.be>
Verzonden: woensdag 18 mei 2022 23:35
Aan: phoenix at list.omgeving.vlaanderen.be <phoenix at list.omgeving.vlaanderen.be>
Onderwerp: [Phoenix] DSI migratie SSO

Dag Team,

ik heb wat verder zitten kijken naar de SSO migratie voor DSI en dit gaat volgens mij heel veel impact hebben.

  1.  we hebben nu 3 nummers ipv 1 - OVOCode / KBO en NISCode. Wat dus wilt zeggen dat we dit overal moeten gaan toevoegen.
     *   actor tabel,
     *   dossier tabel krijgt nu best referentie naar actor tabel, anders moeten we hier ook die 3 waarden gaan toevoegen, alhoewel we hier misschien weg geraken door NISCode in te vullen, buiten voor 1 geval het gewest ...
     *   payloads waar er aanwezigen of adviesverleners zijn, hier gaan we ook de actorId als referentie moeten bijhouden. Hier hebben we echt een mix van GID/LB en EA.
     *   audit tabellen
  2.  dit wilt ook zeggen dat het dataplatform een grote aanpassing nodig heeft. Denk aan
     *   query voor volledige plannen
     *   extra velden die bij komen die van nul weer ingevuld moeten worden
     *   en misschien nog meer
  3.  integraties met verschillende partij-en worden best nageken
     *   archivering bvb
     *   uitsturen van emails

  1.  migratie van de bestaande data gaat ook niet eenvoudig zijn

Ik denk dat we hier best eens samen zitten om alle aspecten in kaart te brengen. Ik plan iets in voor de vrijdag.

Andreas, misschien kan je oplijsten waar je overal tegen botst. Ik heb ook gezien dat je eigenlijk heir en daar nog oude openam code gebruikt. Dit komt omdat er nog een legacy library is die automagisch binnen getrokken wordt. Komt erop neer dat de class OrganisatieCode eigenlijk niet meer gebruikt mag worden.

Het volgende lijkt mij een begin om dit op te lossen, hier dus mijn brain dump van wat ik tot nu toe tegengekomen ben:

  1.  zorg ervoor dat de toepassing werkt, met een lege databank.
     *   wegwerken van alle openam dependencies
     *   toevoegen van niscode / kbonummer en ovocode aan actor tabel en actor_aud tabel. Organisatiecode kolom deprecaten, maar voorlopig laten staan we gaan die nodig hebben voor de migraties
     *   toevoegen van niscode / kbonummer en ovocode aan revisions tabel. Organisatiecode kolom deprecaten, maar voorlopig laten staan we gaan die nodig hebben voor de migraties
     *   relatie toevoegen van dossier en dossier_aud naar actor, organisatiecode kolom daar deprecaten, maar voorlopig laten staan we gaan die nodig hebben voor migraties
     *   de nieuwe kolommen populeren wanneer nodig, de deprecated kolommen ook, we ondersteunen dus een mix voor wat betreft de data. Belangrijk voor de migratie.
     *   acl's updates moeten anders, op basis van een nieuwe sid (kbonummer eerst dan ovocode als keuze)
     *   dosiseracl en andere acl views weer doen werken
     *   overal waar actor naam getoond moet worden, moet nu via de dossier -> actor link gebeuren
     *   archivering / inspire / ... andere integraties nakijken of ze nu de juiste data krijgen
  2.  eens de changes in orde zijn en werken in ontwikkel. Afspreken met datateam hoe zij liefst de migratie doen. Ik vermoed dat zijn een reload gaan willen. Belangrijk hier is dat we van een lega databank beginnen bij ons. Het doel is om te zien of de connectie met het dataplatform in orde is. Zij zouden dus ook met een lege DWH starten lijkt mij best.
     *   welke views / transformaties voor mercator zij gaan moeten aanpassen is nog niet helemaal duidelijk. Hopelijk valt het daar nog mee.
     *   triples zullen een ander verhaal zijn, daar het model eigenlijk wijzigt.
  3.  migratie voorzien van de bestaande data
     *   actor tabel en actor audit tabellen aanvullen van organisatie code naar kbo/ovo/niscode mix
     *   revision tabel aanvullen
     *   dossier en dossier audit tabel linken aan actor

Greetz
C
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://list.milieuinfo.be/pipermail/phoenix/attachments/20220519/9279f076/attachment.htm>