Als developer wil ik dat de PublicCode api word gevuld met twee bronnen

[rubenvdlinde]

Als: Developer Wil ik: Dat OpenCatalogi twee bronnen inleest Zodat: Ik voorbeeld data heb om het weergeven en zoeken aspect te kunnen testen

We hebben het dan over de API van

• https://github.com/OpenCatalogi/.github/issues/39
• https://github.com/OpenCatalogi/.github/issues/40

Deze kan door middel van een cronjob worden gevuld met gegevens uit developer.overheid en de componentencatalogus meer details daarover staan uitgewerkt onder -> https://github.com/OpenCatalogi/.github/discussions/10

De makkelijkste route voor nu is

• Een sync opzetten vanuit de dev omgeving naar (https://developer.overheid.nl/api/repositories?page=1&rowsPerPage=10000 en https://componentencatalogus.commonground.nl/api/components/?rowsPerPage=10000)

Taken:

• [x] #193
• [x] #194
• [x] #195

Acceptatiecriteria

• [x] Als developer kan ik een sync activeren om de gegevens van de componenten catalogus en developer.overheid in te laden BE: ?
• [x] Als gebruiker zie ik de gegevens van developer.overheid en de componentencatalogus terug op OpenCatalogi.nl BE: ?

[lencodes]

@bbrands02 dit issue bevat enkel backend werk en daarom assign ik 'm aan jou.

[rubenvdlinde]

Op dit moment is synchroniseren onderdeel van de object core (ofwel en entityentity), hoewel het valide is dat synchroniseren van data een kern functionaliteit van de Gateway is is deze aanpak in de praktijk te regide.

In het development overleg van 25-06-2022 is de optie besproken om van synchroniseren een plugin te maken, maar de uitkomst daarvan is dat we het echt zien als onderdeel van de core. Een plugin is daarmee niet logisch.

Voorgestelde oplossingen richting is nu om de synchronisatie service de herschrijven. Daarbij moeten een paar aspecten uit elkaar worden getrokken

1. Een object moet een of meerdere externe broertjes kunnen hebben, aka dit object is teven opgenomen in bron x onder id ….
2. Dit broertje leggen we vast in een koppelobject wat de relatie beschrijft en de gegevens bevat die we nodig hebben voor de synchronisatie.
3. Verdere synchronisatie gebeurd aan de hand van het koppel object
4. Dat betekend dat de vraag voor het inlezen van objecten in princiepe los gezien kan worden. Met andere woorden je leest een bak aan objecten (from somwhere) maakt een koppeling aan en zou in theorie vervolgens kunnen syncen aan de hand van de koppeling.

Oke dus sync actie 1. Lees een externe bron in en haal objecten op aan de hand van configuratie. Hierbij dienen we aan de volgende aspecten te denken qua configuratie

• EAV object dat gesynchronyseer word
• Bron waar tegen word gesynchronyseerd (hou er rekening mee dat we in sources nu alleen nog API’s hebben maar daar ook FTP en Databases aan gaan voegen)
• Locatie binnen de bron (voor api’s denken we dan aan endpoint, voor (s)ftp aan folder en voor databases aan tabel.
• Dan specifieke configuratie per bron soort, voor api is dat
• • Locatie van de objecten array (root, results etc)
• • Locatie van total count
• • Naam van de id binnen de externe objecten
• • Naam van dateChanged binnen de externeApi
• • Standaard aantal results
• • Query methode voor bladeren (limit or pages)
• • syncFromList (Boolean, defealt true. Bepaald of er de list op het algemene endoint kunnen gebruiken of dat we een individuele get per object doen)
• • Welke kant is leidend EAV of source?
• • Wat doen we als een object NIET bestaat EAV zijde? (aanmaken in EAV, negeren, vernietigen source zijde)
• • Wat doen we als een object WEL bestaat EAV zijde? (bijwerken in EAV, aanvullen in EAV, negeren, )
• • Wat doen we als een object NIET bestaat source zijder (aanmaken in source, negeren, vernietigen in EAV)
• • Wat doen we als een object WEL bestaat source zijder (aanmaken in source, negeren, vernietigen in EAV)
• Specifieke config voor db en ftp negeren we nog even
• Dit zou genoeg informatie moeten zijn om een get call te doen op de externe API en door de objecten heen de cyclen
• Per object de bl conform configuratie uit te voeren
• Voor iedere sync een sync object aan te maken, het sync object zou moeten bevatten
• • Id
• • Entitiy (ofwel object eav zijde)
• • Action (bij welke action hoort de sync)
• • sourceId (de identifier van het object in de externe bron)
• • hash (de hash van het object)
• • lastChecked
• • lastSynced
• • dateCreated
• • dateUpdated
• De hash van het externe object opslaan is een trucje, door het object elke keer als we het ophalen te vertalen naar JSON en deze JSON te hashen kunnen we kijken of het object verander is sinds de laatste keer dat we gesynced hebben.
• Dat impliceerd dus dat we de hash on record alleen aanpassen als we een sync hebben uitgevoerd (en dus niet na ieder check)

[rubenvdlinde]

Om dit te kunnen testen is er wel nog een aanvullende functionaliteit nodig op de gateway api en dat is het kunnen afvuren van events door middel van een api. Hierbij moeten we er op letten dat:

• We dit beperken tot gateway eigen events
• Er een start object meegegeven moet kunnen worden
• Evens geen resultaten opleveren anders dan een eindobject en is afgevuurd. Sterker nog event zullen doorgaans asynchroon zijn.

[rubenvdlinde]

Sum theorie zou de onderliggen BL hiervoor moeten wroden geleverd door https://conduction.atlassian.net/browse/GW-1107 en https://github.com/ConductionNL/commonground-gateway/tree/feature/GW-1107/gateway-events maar die code lijkt off, heb ik een vraag over uitstaan bij @rjzondervan.

[rubenvdlinde]

Mapping

Componenten Catalogus -> Publiccode "name" -> name "description": -> description.shortDiscription "layerType": -> nl.commonground.layerType "organisationName": legal.repoOwner "contact": maintenance.contacts, "owner": maintenance.contacts, "status" -> developmentStatus "repositoryUrl" -> url, "reuseType":nl.commonground.installationType,

[RonaldvCortenberghe]

done