Herschrijven van de POC tekst

docs/PublicatiePlatformen.puml

@@ -15,7 +15,7 @@ frame "Publicatie platformen " {
 }
 
 ' API's (Laag 2)
-frame "Integratie" {
+frame "API's (Laag 2)" {
     database "Search API"  as OI #1abc9c
 }
 
@@ -28,5 +28,4 @@ KoopHulpje -down-> OI : Bevraagd (API)
 Website -down-> OI : Bevraagd (API)
 Themasite -down-> OI : Bevraagd (API)
 Searchsite -down-> OI : Bevraagd (API)
-
 @enduml

docs/partners/POC-check.md

@@ -2,116 +2,133 @@
 
 ## Common Ground Architectuur
 
-Voldoet de oplossing aan de CG architectuur. Zie ook figuur 5 in de PSA.
+### Voldoet de oplossing aan de CG architectuur. Zie ook figuur 5 in de PSA.
 
-- Ja, de architectuur voldoent aan de CG architectuur(het heeft immers status goud). De Gebruikersinterfaces "Authorisatiebeheer" en "Publiceren" bevinden zich op laag 4 (procesinrichting) en laag 5 (interactie). De integratie verloopt via een oplossing op laag 3(connectiviteit), met daaronder de Woo-service op laag 2 (Diensten) en de bronnen op laag 5(databronnen).
+- Ja, de architectuur voldoent aan de CG architectuur (het heeft immers status goud). In princiepe is de OpenWoo.app een implementatie van de [open catalogi architectuur](https://documentatie.opencatalogi.nl/Handleidingen/Architectuur/) aangevuld met een aantal extra componenten en inrichtingen. De aanvullingen staan beschreven in de [OpenWoo](https://openwoo.app/Techniek/Architectuur/) architectuur.
 
-Wordt er een scheiding gemaakt tussen gegevens ontsloten door API's aan de ene kant en applicaties aan de andere kant. Slaat de applicatie zelf nog gegevens op direct in een database? Welke?
+### Wordt er een scheiding gemaakt tussen gegevens ontsloten door API's aan de ene kant en applicaties aan de andere kant. Slaat de applicatie zelf nog gegevens op direct in een database? Welke?
 
-- Ja, er wordt een duidelijke scheiding gemaakt tussen gegevens ontsloten door API's en applicaties. OpenWoo.app is ontworpen volgens de Common Ground principes, waarbij gegevens worden ontsloten via API's. Dit betekent dat de applicatie zelf niet direct gegevens opslaat, maar gebruikmaakt van API's om toegang te krijgen tot de benodigde data. Gegevens worden enkel tijdelijk in een cache-laag opgeslagen.
+- Ja, er wordt een duidelijke scheiding gemaakt tussen gegevens ontsloten door API's en applicaties. OpenWoo.app is ontworpen volgens de Common Ground principes, waarbij gegevens worden ontsloten via API's. Dit betekent dat de applicatie zelf niet direct gegevens opslaat, maar gebruikmaakt van API's om toegang te krijgen tot de benodigde data. Dit geld bijvoorbeeld voor Publicaties en Bestanden. De beheer interface beschikt daarnaast echter over een eigen database voor het opslaan van configuratie zo als rollen, rechten, logging etc. Het is een 
 
-Kun je ook andere applicaties aansluiten op de API's van de oplossing? Bijv. website, portaal of een mobiele app?
+### Kun je ook andere applicaties aansluiten op de API's van de oplossing? Bijv. website, portaal of een mobiele app?
+- Zekers, sterker nog dat is gangbaar. Er zijn op dit moment 5 verschillende Publicatie platformen aangesloten op de Open Catalogi api, waarvan 4 onderdeel zijn van de OpenWoo.app community. in de [OpenWoo](https://openwoo.app/Techniek/Architectuur/) staat een overzicht. Daarnaast maken Koop (via koophulpje), Woogle en een tweetal gemeenten ook direct gebruikt van de de API. Er zijn op dit moment geen mobiele app's die gebruik maken van de API maar er zijn wel organisaties die overwegen om hem in de mijn omgeving op te nemen (voor locaal nieuws).
+
+In een iets bredere context zijn naar koophulje (de sitemapxml adaptor voor koop) ook andere adaptors in verkenning of ontwikkeling die de API weer omslaan naar externe bronnen (voor publiceren uit open catalogi). Voorbeelden hiervan zijn DROP en SDG.
 
-- OpenWoo.app is ontworpen met flexibiliteit en schaalbaarheid in gedachten, waardoor het eenvoudig is om andere applicaties, zoals websites, portalen, en mobiele apps, aan te sluiten op de API's van de oplossing. De centrale Woo-service fungeert als een motorblok dat meerdere bronnen ondersteunt en gestandaardiseerde API's aanbiedt voor gegevensuitwisseling en functionaliteit. Hierdoor kunnen verschillende applicaties uniform en efficiënt gebruik maken van gemeentelijke diensten en gegevens. Er zijn momenteel meerdere website-ontwikkelaars die verschillende websites maken, inclusief portalen.
 
 ## Technologie
 
-Hoe ziet de technologiestack van de oplossing eruit? Taal, frameworks, databases, etc.
+### Hoe ziet de technologiestack van de oplossing eruit? Taal, frameworks, databases, etc.
+
+- Voor de publicatie platformen wisselen technologiestack's per leverancier, Conduction en Acato bouwen statische voorkanten aan de hand van NL Design react framework(bijvoorbeeld de ui van tilburg) en IO  Digital volledige php wordpress plugins.  
+- Op de backend zijn we recentenlijk overgestapt van conductions eigen oude framework (commong gateway) naar nextcloud framework (php+vue). Daar zijn veel redenen voor en die staan uitgelegd op in een [blog](https://documentatie.opencatalogi.nl/Handleidingen/Nextcloud/) maar nextcloud als framework is echt gericht op kubernetes (en bevat dsu onboard integratie voor logging wegschrijven, monitoring, adfs etc). 
+- Op de datalaag wordt er door nextcloud zelf gebruik gemaakt van postgress. Vanuit applicatie oogpunt shrijven we de overige data bij voorkeur weg naar ORC (overige objecten), DRC (de documenten api van ZGW maar bijvoorbeeld ook corsa) + Elastic Search. Wie bieden echter ook de API aan overheden om één of al deze te vervangen door mongodb of alle data in de nexloud postgress op te slaan. Dat is een bewuste keuze, kubernetes blijkt voor veel overheden een drempel en we willen de applicatie ook geschickt houden van organisaties die en traditionele LAMP stack op VM's draaien.
 
-- De technologiestack van OpenWoo.app maakt gebruik van een combinatie van moderne technologieën die zorgen voor flexibiliteit, schaalbaarheid, en efficiëntie. Door het gebruik van PHP wordt een stevige, doch voor developers bekende, basis gelegd voor de webapplicatie. MongoDB en Elasticsearch bieden krachtige oplossingen voor gegevensbeheer en zoekfunctionaliteiten. De API Gateway en RESTful API's zorgen voor gestandaardiseerde en veilige communicatie tussen verschillende applicaties en diensten. Ten slotte biedt Nextcloud een betrouwbare oplossing voor bestandsbeheer en samenwerking.
 
-### Technologiestack van OpenWoo.app
+### Welke bestaande componenten (zoals Elastic of KeyCloak) worden gebruikt?
+OpenWoo.app maakt gebruik van diverse bestaande componenten om een robuuste, veilige en schaalbare oplossing te bieden. Hieronder staan de belangrijkste componenten die in de technologiestack worden gebruikt:
 
-| Component          | Technologie       | Opmerking                                                   |
-|--------------------|-------------------|-------------------------------------------------------------|
-| Taal               | PHP               | Flexibele en breed ondersteunde webontwikkelingstaal        |
-| Database           | MongoDB           | NoSQL database voor gestructureerde en ongestructureerde gegevens |
-| Zoekfunctionaliteit| Elasticsearch     | Voor snelle en efficiënte zoekfunctionaliteiten             |
-| API Management     | API Gateway       | Beheer en routering van API-verzoeken                       |
-| API's              | RESTful API's     | Gestandaardiseerde communicatie tussen applicaties          |
-| Bestandsbeheer     | Nextcloud         | Veilige en schaalbare oplossing voor bestandsbeheer         |
+- DRC, 
+- ORC
+- Elasticsearch
+- FSC/NLX
+- Nextcloud asl basis framework
+- Diverse NL Design React componenten
 
-Welke bestaande componenten (zoals Elastic of KeyCloak) worden gebruikt?
+Hieromheen is het vooral belangrijk om te vermelden dat de keuze voor nextcloud als basis framework voortkomt uit de goede out of the box ondersteuning voor 
+Keycloak, Splunk, Nagios, Apache spark, PRometheus, Loki, Gravana, Harbour, Open Shift en Azure. Dat is belangrijk omdat dit het platform goed schaalbaar en monitorbaar maakt in complexe kubernates omgevingen. 
 
-- OpenWoo.app maakt gebruik van diverse bestaande componenten om een robuuste, veilige en schaalbare oplossing te bieden. Hieronder staan de belangrijkste componenten die in de technologiestack worden gebruikt:
+### Zijn er automatische tests? Welke soort (unit, end-to-end)? Wat is de dekkingsgraad?
 
-- Elasticsearch wordt gebruitk voor geavanceerde zoekfunctionaliteit en datatoegang. Elasticsearch wordt tevens gebruikt voor doorzoekbaarheid en analyse. Daarnaast is Nextcloud vooral gekozen omdat het industriestandaarden zoals Keycloak, Splunk en Nagios ondersteund.
+- We draaiden bijde soorten test, voor end-to-end testing maken we gebruik van [vitest](https://vitest.dev/) en voor unit tests van [php-unit](https://phpunit.de/index.html). De test covaradges wisselt wat rond de xx procent.
 
-Zijn er automatische tests? Welke soort (unit, end-to-end)? Wat is de dekkingsgraad?
+### Zijn er installatiescripts? Is er een Helm chart? Zijn voldoende omgevingsvariabelen ontsloten voor een volledige automatische installatie?
 
-- Er worden momenteel unit tests geschreven in de overgang naar een MVP. Nextcloud vereist dit ook voor plaatsing in de Nextcloud appstore.
+Zeker, goede installeerheid was een drive achter deze stack keuze. Er zijn een aantal installatie routes beschickbaar, voor (kubernetes) productie omgevingen zijn de stapppen redenlijk simpel
+- Installeer Nexcloud (bijvoorbeeld via [Azure](https://azuremarketplace.microsoft.com/en-us/marketplace/apps/nextcloudgmbh1597841818906.nextcloud?tab=overview), [Open Shift](https://catalog.redhat.com/software/container-stacks/detail/65e9dc6f6365ba88288a412c) of [Artifact HUb](https://artifacthub.io/packages/helm/nextcloud/nextcloud) de officieele cloud native foundation marktplaats)
+- Installeer via de nextcloud ui de Open Catalogi app
+- Activeer in de Open Catalogi app de OpenWoo.app metadata bestanden
 
-Zijn er installatiescripts? Is er een Helm chart? Zijn voldoende omgevingsvariabelen ontsloten voor een volledige automatische installatie?
+De herbruikte componenten binnen commonground kennen hun eigen installatie handeleidingen (ORC en DRC). Elastic (en optioneel MongoDB) zijn op Azure en Open Shift standaard als apps beschickbaar.
 
-- Er is een docker-compose voor het draaien in een container. De instructies zijn [hier](https://github.com/ConductionNL/opencatalogi?tab=readme-ov-file#open-catalog) te vinden. Er is een officiele Helm-chart, we kijken ernaar om deze uit te breiden zodat dit inclusief de app is gebeurd.
+Optioneel kan er een losse frontend als container worden geinstalleerd, maar dat is in het van de standaard react container niet nodig. Die kan aan de hand van NL design tokens serverless worden gedraaid vanuit de [github marketplace](https://github.com/marketplace?query=opencatalogi) .
 
-Na installatie zijn er enige vereiste, zoals een API-sleutel voor MongoDB en clusternaam en voor het activeren van Elastic een sleutel en index. We kiezen er expres voor niet omgevingsvariableen niet allemaal mee te geven.
+Voor (locaal) ontwikkleen en demo'en is er een docker-compose voor het draaien in een container. De instructies zijn [hier](https://github.com/ConductionNL/opencatalogi?tab=readme-ov-file#open-catalog) te vinden. Deze word momenteel door Acato getest (so far so good)
+
+Na installatie zijn er enige (optionele) vereiste, zoals een API-sleutel voor MongoDB en clusternaam en voor het activeren van Elastic een sleutel en index of voor productie omgevingen een ORC en DRC. 
 
 ## Bronnen
 
-Welke bronnen kunnen nu worden aangesloten?
+### Welke bronnen kunnen nu worden aangesloten?
 
 - Momenteel de volgende bronnen:
 - (xxllnc) zaaksysteem.nl
 - Elasticsearch
 - ZGW-api bronnen
 - Bronnen met een REST API
 
-Is er een adapter framework of iets anders voor het aansluiten van nieuwe bronnen?
-
-- Ja, zolang bronnen gebruik maken van de ZGW-api's of RESTful API, dan is aansluiting nu al ondersteund.
+### Is er een adapter framework of iets anders voor het aansluiten van nieuwe bronnen?
+Ja momenteel gebruiken we voor dit specifieke stukje van het ecosysteem nog wel de commongateway, dat werkt aardig (Acato heeft daar nu ook de eerste koppelingen mee gemapped) maar willen we eigenlijk ook over trekken naar een nextcloud app voor kubernetes.
 
-Worden bronnen via streaming aangesloten? Of is dat batch (bijv. 's nachts of ieder uur)?
+Voor ZGW, DRC en ORI is er nu al een addaptor voor ondersteuning en Tilburg en Acato zijn aan het afronden op Stuf en Sharepoint.
 
-- Er is een cronjob die elke 10 minuten een synchronisatie met de bronnen uitvoert. Hierdoor hoeft er niet lang gewacht te worden voor de publicaites op de publicatiepagina getoond worden. Dit geeft tevens ook een buffer voor een check of er mogelijk toch iets onjuist is gepubliceerd.
+### Worden bronnen via streaming aangesloten? Of is dat batch (bijv. 's nachts of ieder uur)?
+Bijde, bijvoorkeur gebruiken we een pubsub patroon zo als notificaties bij ZGW. Of een tussenvorm via een data distributie syseem (haal nu deze stuf zaak op). Maar in de praktijk ondersteunen lang niet alle pakketen dit. In die gevalen grijpen we terug op batch verwerking. Hoe vaak die draaien hangt van de bron af en is per bron instelbaar. Dat kan elke uur of iedere nacht. Maar als de bron bijvoorbeeld kan fileren op items die afgelopen x minuten zijn gewijzigd kijken we graag idere 5 tot 10 minuten even (als het antwoord dan leeg is zijn we ook niet exsesief aan het vragen)
 
 ## Zoeken
 
-Hoe verhoudt de zoekindex zich tot de ODRC?
+### Hoe verhoudt de zoekindex zich tot de ODRC?
+Deze is bewust losgekopeld, we hanteren het princiepe dat in de zoekindex alleen openbare informatie mag staan. 
 
-De zoekindex
 
-Slaat Elastic alle gegevens (docs) zelf op?
+## Slaat Elastic alle gegevens (docs) zelf op?
+Dat hang van de configuratie keuzes van de gemeente af, maar bij voorkeur slaan we alleen de metedata van documenten op en halen we het document zelf uit het DRC op het moment dat het word opgevraagd. Er zijn echter casssusen waarin dat vanuit belasting of performance niet wensenlijk is.
 
-- Elastic slaat in principe alles op. Er is een keuze te maken wat je naar Elasticsearch stuurt natuurlijk.
-
-Is de API voor zoeken een Elastic API of specifieke API voor WOO?
-
-- Er bestaat een specifieke API voor OpenWoo.app, die bovenop Elasticsearch gezet is. Wel is het mogelijk Elastic direct te bevragen
+### Is de API voor zoeken een Elastic API of specifieke API voor WOO?
+Het is een specifieke API voor de WOO die binnen de parameters valt van wat Elastic zelf ook kan uitleveren met wat configuraite. Met andere woorden de elastic instantie kan ook direct worden bevraagd. De adaptor er boven op voorziet echter in twee extra functionaliteiten die wij binnen de WOO wensenlijk vinden
+- Federatief zoeken over meerdere elastic search instanties
+- Ophalen documenten door routeren naar b.v. DRC ipv elastic.
 
 ### SaaS
 
-Dimpact wil de oplossing als SaaS-dienst aanbieden aan haar leden. Wat is er nodig om de oplossing als SaaS aan te bieden?
-Hoe ziet een gemeentelijke implementatie eruit? Ervan uitgaande dat alle technische integratie al gedaan is bij installatie.
+### Dimpact wil de oplossing als SaaS-dienst aanbieden aan haar leden. Wat is er nodig om de oplossing als SaaS aan te bieden?
+Een kubernetes of azure omgeving met daarop bij voorkeur een managment tool voor container orchestratie die artifacthub ondersteund (er zijn er een aantal). In dat geval kan er visueel geinstalleerd worden.
 
-- Voor het aanbieden van SaaS voor de leden van Dimpact moet er gedacht worden aan multitenancy om aan de diverse leden en hun speicfieke eisen te voldoen. Hiervoor moeten we met de leden in kwesite in gesprek gaan en uitzoeken of er maatwerk nodig is. Indien dit niet het geval is, dan zou het enkel om configureerwerk gaan en kan het implementatieproces snel verlopen. Ter verduidelijking, de snelste organisaite die we hebben aangesloten duurde 2 weken. Aan de andere kant zijn er een gemeente die het traject zelf uitstrijkt over meerdere maanden. Kortom, om OpenWoo.app als SaaS-dienst aan te bieden, wordt er gebruik gemaakt van een multi-tenant architectuur om afzonderlijke omgevingen voor verschillende gemeenten te beheren. Dit omvat het creëren van tenants, het schalen van resources, integratie met SSO en AD/LDAP systemen, en het bieden van beveiliging, compliance, en ondersteuning. Een gemeentelijke implementatie omvat voorbereiding, technische integratie, configuratie, training, livegang, en nazorg.
+Daarnaast ondersteunen we best een flink aantal monitoring en dashboard tools, het is verstandig om die ook operationeel te hebben (bijvoorbeeld graffana)
 
-## Authenticatie en autorisatie
+### Hoe ziet een gemeentelijke implementatie eruit? Ervan uitgaande dat alle technische integratie al gedaan is bij installatie.
 
-Kan de oplossing worden aangesloten op AD (OIDC)?
+Hiervoor is  een handleiding beschickbaar op https://openwoo.app/Techniek/Productie/ 
 
-- Ja, Nextcloud werkt met LDAP voor het AD, of (onder andere) ADFS voor SSO.
 
-Hoe worden rollen en rechten ingeregeld? Kan de oplossing rollen uit AD gebruiken?
+## Authenticatie en autorisatie
 
-- Dit werkt via [LDAP](https://docs.nextcloud.com/server/latest/admin_manual/configuration_user/user_auth_ldap.html). De oplossing kan dus de rollen uit het AD overnemen.
+### Kan de oplossing worden aangesloten op AD (OIDC)?
+Ja, Nextcloud werkt met LDAP voor het AD, of (onder andere) ADFS voor SSO. Hiervoor zijn meerdere [handleidingen](https://www.schiessle.org/articles/2023/07/04/nextcloud-and-openid-connect/) beschickbaar die bijvoorbeeld ook gebruik maken van Keycloak (er kan ook direct met LDAP op AD worden gekopeld).
 
-Kunnen beide bij installatie worden ingericht via de Helm chart?
+### Hoe worden rollen en rechten ingeregeld? Kan de oplossing rollen uit AD gebruiken?
+Dit werkt via [LDAP](https://docs.nextcloud.com/server/latest/admin_manual/configuration_user/user_auth_ldap.html). De oplossing kan dus de rollen uit het AD overnemen. Het toekenen van specifieke rechten aan rollen (bijvoorbeeld publiceren) gebeurd vervolgens in de applicatie zelf.
 
-- Dit zou kunnendoor gebruik te maken van [Openldap](https://kb.symas.com/using-openldap-with-nextcloud), maar hebben we zelf nog niet eerder gedaan.
+### Kunnen beide bij installatie worden ingericht via de Helm chart?
+Ja, voor zover wij weten zijn alle configuratie opties (dus ook adaptors) zijn via de config optie van de [helm chart](https://artifacthub.io/packages/helm/nextcloud/nextcloud?modal=values) in te stellen. Dat betend dus dat de applicaite (in theorie) volledig werkend kan worden opgesponnen.
 
 ## Standaarden
 
 Welke standaarden worden nu al gebruikt en ondersteund? TMLO, ZGW API's, etc.
 
-- ZGW api
+- ZGW 
 - REST API (OpenAPI)
 - MDTO (voorheen TMLO)
 - JSON-LD
+- [Triple Store](https://en.wikipedia.org/wiki/Triplestore)
+- Geo-JSON
+- NFC/NLX
+
+Zie voor meer standaarden de [Open Catalogi Architectuur](https://documentatie.opencatalogi.nl/Handleidingen/Architectuur/).
 
-Is de ODRC API een standaard API?
+### Is de ODRC API een standaard API?
 
-- Het is een API die volgens de NL API strategie functioneert, met 'reguliere' endpoints en convenience endpoints.
+- Het is een API die volgens de NL API strategie functioneert, met 'reguliere' endpoints en convenience endpoints. We zijn nu in overleg met VNG en KOOP over standaardisatie, we verwachten daarbij maandag 22 juli een eerste besluit vanuit Koop. De VNG heeft 27 Juni reeds aangegeven de API als kandidaat te zien.
 
 ## **Aan te tonen functionaliteiten bij PoC OpenWoo.app**