Semantisk søk for Modum kommune
Anbefaling
BCW kan bygge og drifte et selvstendig søke-API mens Modum beholder nettstedet, publiseringsflyten og hostingen i SiteVision. Den anbefalte løsningen består av en liten SiteVision-connector, en ekstern tjeneste for synkronisering og indeksering og en tilpasset søke-WebApp på Modums eksisterende /sok-side. Søketjenesten bør kombinere semantisk gjenfinning med nøkkelordssøk og returnere vanlige lenker og nyttige utdrag.
Dette støttes teknisk av SiteVisions dokumenterte utvidelsesmuligheter. Integrasjonen er ennå ikke verifisert mot Modums CMS med autentisert tilgang. En anonym forespørsel til Modums /rest-api/doc returnerte HTTP 403 den 10. september 2026. Den faktiske API-konfigurasjonen, versjonen, rettighetene og innholdsdekningen må derfor fortsatt undersøkes med en autorisert konto. HTTP 403 fastslår ikke at API-et er deaktivert.1
De sentrale implementeringsvalgene er:
| Valg | Anbefalt løsning |
|---|---|
| Hvor søket kjøres | REST API og søkeindeks driftet av BCW |
| Hva Modum beholder | SiteVision CMS, hosting, URL-er og redaksjonell arbeidsflyt |
| Hvordan innhold hentes | SiteVision-API-er via en avgrenset RESTApp-connector; uttrekk av publisert innhold samt metadata og innlesing av filer |
| Hvordan endringer mottas | RESTApp-events, en leveringsmekanisme med varig lagring og planlagt avstemming |
| Hvordan resultatene vises | En WebApp som erstatter resultatmodulen på /sok og bevarer lenker med query |
| Rangering | Hybrid semantisk gjenfinning og nøkkelordssøk; evalueres mot norske innbyggeroppgaver |
| Første omfang | Godkjente offentlige sider, artikler og dokumenter; eksterne systemer etter særskilt avtale |
| Innebygd alternativ | Test SiteVisions aiAssistant.querySemanticIndex før man forplikter seg til de fulle driftskostnadene ved en selvstendig indeks |
Første versjon bør levere søkeresultater. Generering av svar er en separat produktbeslutning og er ikke nødvendig for å levere semantisk søk.
Funn fra testing av dagens søk
Dette er utforskende observasjoner fra det offentlige nettstedet på desktop den 10. september 2026, med Modums søkeskjemaer. Treffantallet ble kontrollert etter at hvert søk var ferdig. Observasjonene beskriver dette utvalget, ikke en samlet suksessrate eller en benchmark av SiteVision-plattformens muligheter.
| Søk | Oppgitt antall treff | Observert resultat og betydning |
|---|---|---|
barnehage | 197 | «Barnehage» kom først. Deretter fulgte enkeltbarnehager. Søknadssiden kom etter de ti første resultatene. |
hvordan søker jeg barnehageplass | 3 | «Barnehage» kom først, etterfulgt av to PDF-er. Det nøyaktige spørsmålet finnes i utdraget fra det første resultatet, så dette dokumenterer ikke semantisk forståelse. |
jeg trenger hjelp til å betale husleia | 0 | Innbyggerens beskrivelse av et behov ga ingen resultater. |
bostøtte | 5 | «Bostøtte» kom først. Dette viser at en relevant side om bostøtte finnes, selv om det foregående søket ga null treff. |
barnehge | 0 | Ingen rettelse ble vist da resultatene for denne skrivefeilen var ferdig lastet. |
søppeltømming | 0 | Ingen resultater for det testede begrepet. |
når blir søpla hentet | 0 | Ingen resultater for spørsmålet i dagligtale. Det er ikke verifisert om den nødvendige informasjonen om henting faktisk finnes i SiteVision. |
renovasjon | 82 | En PDF med planbestemmelser kom først; vintervedlikehold av veier kom som nummer to. Flere av de neste resultatene var plandokumenter. |
bygge garasje | 19 | «Slik søker du» kom først, etterfulgt av plandokumenter. Dette er nyttig nøkkelordsatferd som en erstatning bør bevare. |
building permit | 0 | Det engelske søket fant ikke det norske innholdet om byggesaker. |
legevakt | 56 | «Vakttelefoner» kom først. Effektiv navigasjon for denne typen tjenestesøk bør bevares. |
Søkene kan gjentas på Modums søkeside. Nyttige sammenligninger er nøkkelordet bostøtte, spørsmålet om hjelp til husleie, skrivefeilen og det engelske søket.
Andre observasjoner:
- Skjemaet på forsiden sender til
/sok?query=...; en global søkedialog i toppfeltet gir en annen inngang. Begge må fungere konsekvent med den nye løsningen. - Resultatene omfatter nettsider, PDF, DOCX og eldre DOC-filer. En indeks med bare nettsider ville redusere dagens dekning.
- Noen utdrag inneholder redaktørnavn, organisasjonsopplysninger og annen tekst fra bunnfeltet. Andre fremhever gjentatte lenker til lover eller skjemaer. Rensing av det søkbare innholdet er en vesentlig del av forbedringen.
- Flere dokumentresultater har generiske eller inkonsekvente titler. Ett resultat het for eksempel «ÅRSMELDING OG REGNSKAP 2011», mens lenken sluttet med
årsmelding_2017.pdf. Det trengs regler for dokumenttitler og en redaksjonell gjennomgang; en annen rangeringsmodell reparerer ikke metadata i kilden. - Paginering fungerte: side 2 for
barnehageviste et annet resultatsett, mens det oppgitte totalantallet fortsatt var 197. Første side inneholdt 20 resultater. - Søkeforslag ble observert som en liste med sidetitler for
barnehage. Forslagene er en egen integrasjonsflate, atskilt fra innsending av det endelige søket. - Noen offentlige dokumentutdrag inneholder tomme skjemafelt og formuleringer om konfidensialitet. Dette er i seg selv ikke dokumentasjon på at personopplysninger er eksponert. Modum bør avklare hvilke tomme maler og eldre versjoner som skal inngå i den nye indeksen.
Det ble ikke utført lasttest, full tilgjengelighetsrevisjon, testing på mobil eller testing av innhold med autentisert tilgang. Vurderingene av rangering er kvalitative. Funnene begrunner en relevansevaluering; de beviser ikke at en bestemt embedding-modell vil forbedre alle søk.
Hvordan Modums nåværende søk er koblet sammen
Den offentlige sidens markup identifiserer resultatsiden som 4.2b2ef61194d8525c6b1202 og søkemodulen som 12.2b2ef61194d8525c6b49d6. Dette er observerte implementasjons-ID-er, ikke kontrakter BCW bør bygge sitt langsiktige API rundt.
Det nåværende søkeskjemaet oppgir denne URL-en for asynkrone resultater:
/4.2b2ef61194d8525c6b1202/12.2b2ef61194d8525c6b49d6.htm
?state=ajaxQuery&isRenderingAjaxResult=true&query=...
Det oppgir også denne URL-en for autocomplete:
/4.2b2ef61194d8525c6b1202/12.2b2ef61194d8525c6b49d6.json
?state=autoComplete
En lesende forespørsel til det oppgitte resultatendepunktet returnerte HTTP 200 med HTML, inkludert det samme treffantallet for barnehage. Dette er et endepunkt for modulrendering, ikke Model REST API. SiteVisions dokumentasjon for Search-maler beskriver de tilsvarende begrepene for resultater, søk, autocomplete og paginering.2
Det er derfor ikke tilstrekkelig å peke den eksisterende HTML-lasteren mot et nytt JSON-basert søke-API. BCW må håndtere rendering av resultater og paginering, eller bygge og vedlikeholde en kompatibilitetsadapter for den gamle HTML-kontrakten. En WebApp er den tydeligere, støttede integrasjonen.
Den anbefalte endringen er å beholde /sok og parameteren query, erstatte resultatmodulen der og oppdatere eller erstatte forslagene i søkeskjemaene på forsiden og i toppfeltet. Eksisterende lenker til /sok?query=... kan fortsette å fungere. Det er ikke nødvendig å flytte hele Modums nettsted eller endre SiteVisions interne søkemotor.
SiteVisions API-familier
«Public API» betyr ikke et ubegrenset offentlig HTTP-endepunkt. SiteVision bruker begrepet om sine støttede programmeringsgrensesnitt inne i SiteVision-runtime.3
| API-familie | Hva den tilbyr | Rolle i den foreslåtte løsningen |
|---|---|---|
| Public API: JCR Model | Lesetilgang til et tre av noder og egenskaper, underlagt SiteVisions rettigheter | Finne sider, arkiver, mapper, filer, metadata og stabile kilde-ID-er |
| Public API: Utilities | Hjelpefunksjoner for datatilgang, rendering, rettighetskontroll, søk, HTTP-kall og andre plattformoperasjoner | Implementere connectoren uten å være avhengig av interne funksjoner som ikke er støttet |
| Model REST API | HTTP-tilgang til operasjoner på modellen; aktiveres separat per nettsted | Ekstern opplisting, egenskaper, headless-innhold og lesing fra søkeindeks |
| RESTApps | Tilpassede HTTP-ruter og event handlers som kjøres i SiteVision | Avgrenset eksport-API, synkroniseringsevents og valgfri søkeproxy |
| WebApps | Tilpassede moduler med funksjonalitet i nettleseren og på serveren | Vise BCWs søkeresultater i det eksisterende nettstedet |
| Utviklerverktøy | Oppretting av appskjelett, typer, pakking, signering, opplasting og aktivering | Utvikle og deploye connectoren og søkegrensesnittet |
JCR-modellen implementerer skrivebeskyttet level-1-funksjonalitet; utility-API-ene tilbyr andre støttede operasjoner. BCWs indekseringsintegrasjon trenger lesetilgang til innhold, ikke rett til å redigere eller publisere sider. SiteVision anbefaler utility-funksjonene for robust tilgang til noder og egenskaper fremfor direkte JCR-operasjoner som kan kaste exceptions.4
URL-formatet for Model REST er:
https://<site>/rest-api/1/1/<node-id>/<operation>
Den første 1 er API-versjonen, og den andre velger online-/publisert modell. Modellversjon 0 eksponerer redigerings-/offline-visningen. Bruk node-ID-er fremfor navnebaserte stier. Installasjonens autentiserte /rest-api/doc er den autoritative kilden for den installerte versjonen; de offentlige endepunktsidene beskriver nyeste versjon.1
RESTApps bruker et annet URL-mønster:
https://<site>/rest-api/<addon-name>/<route>
Addon-navnet inngår i URL-en. Velg et stabilt navn og håndter fremtidige API-versjoner eksplisitt.5
Tilgang og autentisering
Modum må aktivere og begrense Model REST API dersom BCW skal kalle det eksternt. Dokumentasjonen krever en innlogget bruker med rettigheten DEVELOPER. RESTApps har egne innstillinger for «Permit call», HTTP-metoder og cross-origin-begrensninger. En tilpasset RESTApp kan kalle det innebygde Model REST API internt selv om API-et ikke er eksponert eksternt.167
Bruk en dedikert integrasjonsidentitet, et avgrenset innholdsomfang og innloggingsopplysninger som oppbevares på serveren. Modums faktiske autentiseringsmetode må bekreftes. SiteVision støtter konfigurerbare innloggingsfiltre, inkludert BASIC, men dokumentasjonen som ble gjennomgått, fastslår ikke en universell løsning for innkommende bearer tokens eller OAuth client credentials på tvers av alle kundeinstallasjoner.8
SDK-ets OAuth2-hjelpere handler hovedsakelig om å hente og bruke tokens når SiteVision kaller en annen tjeneste. De må ikke tolkes som dokumentasjon på at BCW automatisk kan autentisere mot Modums CMS med OAuth2.9
Hold deployment-credentials, credentials for innholdslesing og det offentlige søkegrensesnittet atskilt. En offentlig søkeapplikasjon kan ikke skjule en API-hemmelighet sikkert i nettleserens JavaScript. CORS kontrollerer nettleserens origin; det er ikke autentisering.
Innholdsuttrekk og fullstendighet
Kartlegging av kilden
Start fra godkjente rotnoder i sidetreet og fillagrene. Gå gjennom mapper og arkiver i tillegg til sider; ellers kan artikler eller dypt nestet innhold bli oversett. Filer kan ligge i det globale lageret eller i en sides lokale lager. ResourceLocatorUtil har hjelpefunksjoner for begge.10
| Innebygd operasjon | Relevant oppførsel | Anbefalt bruk |
|---|---|---|
nodes | Undernoder; støtter includes, excludes, utvalgte properties, skip og limit | Avgrenset gjennomgang av treet, inkludert containere |
properties | Utvalgte egenskaper for en node | Titler, kanoniske URL-er, datoer, locale og godkjente metadata |
contentnodes | Headless-innhold for støttede moduler på en side | Strukturerte overskrifter, tekst, lenker og mediereferanser |
headless | Kombinerer egenskaper, undernoder og innholdsnoder | Praktisk sideeksport når alle tre er nyttige |
search | Rettighetsfiltrerte Solr-resultater; utvalgte felt, sortering, offset og limit | Sammenligning av innholdsoversikt, lagret tekst og gjenfinning som fallback |
Disse operasjonene er dokumentert hver for seg. nodes og headless har svært høye standardgrenser for antall undernoder, så connectoren bør alltid angi en eksplisitt, avgrenset batch-størrelse. headless garanterer ikke en rekursiv eksport av hele nettstedet: includeContent og includeLinkedContent er som standard false for undernoder.11121314
Søkeendepunktet begrenser hvert svar til 1–500 treff i dokumenterte versjoner fra 2022.10.2. Det tilbyr offset-basert paginering, ikke en dokumentert, varig synkroniseringscursor. Det returnerer bare treff den som kaller API-et, kan lese. Dette er ikke det samme som «offentlig» når brukeren har utvidede rettigheter.15
Foretrukket uttrekk av sideinnhold
Tre aktuelle metoder bør testes mot de samme representative sidene:
- Uttrekk av indekserbart innhold gjennom en RESTApp. Fra SiteVision 2026.03.1 kan
IndexableContentExtractorreturnere online-sideinnhold som HTML, tekst eller Markdown. Dette er særlig relevant for innlesing til søk fordi metoden retter seg mot indekserbart, rendret innhold.16 - Headless-innhold.
contentnodesogheadlesstilbyr strukturert innhold med tekstformatene ren tekst, JSON eller Markdown. Markdown er dokumentert fra 2025.07.1. JSON bevarer strukturelementer som overskrifter, lenker og tabeller.1314 - Kontrollert uttrekk fra rendrede sider eller lagret indekstekst. Brukes som fallback når headless-dekningen er ufullstendig, med eksplisitt fjerning av navigasjon og irrelevant felles tekst. Standardindeksens
summaryer lagret tekst;content.analyzeder et analysert søkefelt. Ikke anta at et utdrag fra brukergrensesnittet, eller ethvert felt kalt «summary», er hele artikkelteksten i renset form.17
Extractor-builderen aksepterer publiserte noder av typene sv:page, sv:article og sv:sitePage. Den krever READ-rettighet, avviser siden som kjører koden, og bruker som standard gjeldende bruker ved rendering. Struktursider og andre nodetyper trenger egen, testet håndtering. Online-innhold og innhold tilgjengelig anonymt er to forskjellige vilkår: innhold som rendres som redaktør eller indekseringsbruker, kan avvike fra det en anonym besøkende ser.18
Bruk en eksplisitt uttrekksmetode for offentlig tilgjengelig innhold. Hent for eksempel den ferdig rendrede hovedteksten uten autentisering, eller sørg for at connectorens renderingskontekst tilsvarer anonym tilgang. Bruk hasAnonymousReadPermission(node) i tillegg til kontroller av publisering og omfang; en vellykket lesing med tjenestekonto betyr ikke at innholdet er offentlig.19
Hva headless-eksport kan overse
Det dokumenterte innholdsnode-svaret omfatter standardmoduler med headless-støtte og WebApps som implementerer headless-output. En tilpasset WebApp trenger headless.js for å eksponere disse dataene. Ugyldig output kan føre til at hele dens headless-bidrag utelates. Det finnes også et dokumentert tilfelle der svært gamle, uendrede Text-portlets utelates.1320
«API-et returnerte JSON uten feil» er derfor ingen fullstendighetstest. Sammenlign tekstuttrekk med synlig innhold i trekkspillseksjoner, tabeller, lenkede layouter, gjenbrukbare elementer, innebygde komponenter, tjenestekort og tilpassede WebApps. En hovedinnholdsblokk kan trenge en egen adapter i connectoren. Unngå å duplisere lenket fellesinnhold på hver side.
SiteVision dokumenterer også <!--sv-no-index-->-ekskluderinger i rendret innhold. Respekter bevisste unntak fra indeksering, og avklar hvordan hver uttrekksmetode håndterer dem. Headless-uttrekk må ikke utilsiktet gjeninnføre innhold som bevisst er utelatt fra søk.21
Dokumenter og eksterne tjenester
Filnoder eksponerer URL-er, metadata, endringsdatoer, lengde og informasjon om nedlastingsbeskyttelse. Binærinnholdet kan hentes separat. En fil er ikke en publiserbar side, så det ville være feil å bruke en sidespesifikk regel som published=true på alle nodetyper.22
Last ned godkjente filer og trekk ut innholdet i BCWs worker-miljø. Inkluder støtte for PDF, DOCX og DOC i omfanget; legg bare til OCR for skannede PDF-er der innholdsgjennomgangen viser behov. Bevar referanser til dokument og sidetall, oppdag tomme uttrekk, avstem dupliserte versjoner og bruk filens gjeldende nedlastings-URL. Gjør det synlig for driftsansvarlige hvilke filer som kan inkluderes, og hvilke uttrekk som feiler.
«Alle dataene» må bety alt godkjent søkbart innhold, med en målbar innholdsoversikt. Det må ikke stilltiende inkludere redaktørkommentarer, brukerkontoer, innsendte skjemasvar, upublisert materiale eller tilgangsbegrensede dokumenter. Bruk en allowlist for egenskaper fremfor å be om og lagre alle egenskaper.
Modums forside lenker til eksterne systemer for kart, offentlig journal, innmelding av feil og andre oppgaver. SiteVision kan eksponere lenkene det lagrer; det kan ikke automatisk eksportere de underliggende opplysningene i disse systemene. Avtal om hver ekstern destinasjon skal være en redaksjonelt valgt søkesnarvei, en separat synkronisert kilde eller utenfor omfanget. Spørsmålet om søppelhenting er en nyttig test av denne avgrensningen.23
Holde indeksen synkronisert
Event-drevne oppdateringer og avstemming
RESTApps kan reagere på events for publisering, struktur, papirkurv, binærinnhold og timere. Følgende event-dekning er relevant:24
| Event | BCWs handling |
|---|---|
sv:publishing:publish | Hent gjeldende online-representasjon på nytt og utfør upsert dersom innholdet kan inkluderes |
sv:publishing:unpublish | Fjern dokumentet og dets chunks fra søk; bekreft gjeldende tilstand |
sv:structure:move | Kontroller inklusjonsvilkår, URL, hierarki og berørte undernoder på nytt |
sv:trashcan:add | Fjern det slettede elementet og eventuelle berørte undernoder fra søk |
sv:trashcan:restore | Kontroller gjeldende publiseringsstatus og tilgang før ny indeksering |
sv:binary:create | Vurder den nye filen mot godkjent omfang |
sv:binary:update:* | Hent endret innhold, metadata, navn, tagger eller valgt versjon på nytt |
sv:folder:update:metadata | Vurder arvet klassifisering på nytt der det er relevant |
| Timer-events | Behandle en retry-/outbox-mekanisme eller starte avgrenset avstemming |
Events er asynkrone og kjøres i OFFLINE-modellen som brukeren som utløste dem. Tidsstempelet er ikke garantert å være likt innholdets publiseringstidspunkt. Dokumentasjonen har motstridende opplysninger om lokalitet i clusteret; utform løsningen som om handlers kan kjøres på en hvilken som helst clusternode. Ikke stol på prosesslokal tilstand.2425
Behandle et event som en beskjed om å kontrollere kildens tilstand, fremfor som den autoritative innholdsrevisjonen. Event handlers bør lagre en liten endringsmelding varig og returnere raskt. Send ID-er og endringsinformasjon til BCW; la workers håndtere nedlasting, uttrekk, embeddings og indeksering.
Ikke les innhold med vanlig RestApi inne i en event handler og anta at innholdet er publisert. RestApi bruker gjeldende kjøreversjon. Fra 2024.04.2 gir VersionedRestApi, hentet gjennom RestApiFactory.getOnlineRestApi(), en eksplisitt online-versjon med node-ID-er. Dette er det dokumenterte alternativet når en offline-handler må lese online-data.726
Dokumentasjonen som ble gjennomgått, fastslo ingen ende-til-ende-garanti for varig, ordnet webhook-levering nøyaktig én gang (exactly-once). Retries, idempotens og periodisk avstemming er BCWs ansvar å implementere. Det ble heller ikke identifisert et fullstendig event for endringer i siderettigheter i den dokumenterte event-listen. Endringer i tilgang, arvede regler, indekseringsregler og tilpassede moduler krever en avstemmingsstrategi og tester mot den aktuelle installasjonen.
Anbefalt synkroniseringsalgoritme
Dette er et foreslått BCW-design, ikke en innebygd SiteVision-kontrakt for en change feed.
- Opprett et manifest over kilde-ID-er under godkjente rotnoder, og begynn å registrere endringer før førstegangsimporten.
- Gå gjennom innholdsoversikten i avgrensede batcher. Hent gjeldende online-egenskaper, vilkår for offentlig tilgjengelighet, renset hovedtekst og vedleggsreferanser.
- Lagre kilde-ID separat fra URL-en. Beregn en hash av normalisert innhold og versjonene av uttrekksmetoden og modellen.
- Beregn nye embeddings bare for endret innhold. Erstatt alle chunks for et dokument atomisk, slik at gamle seksjoner ikke kan bli liggende igjen etter en oppdatering.
- Behandle registrerte endringer etter førstegangsimporten; gjentatt levering må til slutt gi samme effekt som én levering.
- Kjør inkrementelle gjennomganger med et overlappende tidsvindu. Ved bruk av Solr-indeksen må det tas høyde for indekseringsforsinkelse og brukes deterministisk sortering med ID som sekundær sorteringsnøkkel der dette støttes.
- Fullfør periodiske, komplette manifester og sammenlign ID-er, URL-er, hasher og inklusjonsvilkår. Fjern poster fra søk når de mangler i en vellykket fullført innholdsoversikt. En avbrutt gjennomgang eller autentiseringsfeil må aldri tolkes som massesletting.
- Avstem på nytt etter deployment av en connector, endring av uttrekksregler, endring av tilgangsregler eller gjenoppretting av en SiteVision-backup.
Avpublisering og tilbakekalling av tilgang bør ha en rask mekanisme for fjerning fra søk, uavhengig av embedding-jobber. Ved strenge krav bør man bruke en kort gyldighetsperiode for inklusjonsstatus eller en kontroll av gjeldende tilgang gjennom en gateway mot det offentlige grensesnittet. Bakgrunnssynkronisering alene kan ikke love null eksponering av utdatert innhold under et driftsavbrudd. Avtal maksimal tillatt forsinkelse og fail-closed-oppførsel med Modum.
Events kan dupliseres eller ankomme i feil rekkefølge. Kontroller alltid gjeldende kildetilstand før innhold gjøres søkbart. Et forsinket publiseringsevent må ikke gjenopprette et element som senere er avpublisert. Flytting og sletting av overordnede noder må også utløse kontroll av undernoder, lenker, brødsmuler og relevante lokale filer.
SiteVisions egne indekser er eventually consistent: indekseringsdokumentasjonen sier at oppdateringer vanligvis slår gjennom innen ett minutt, men at det kan ta lengre tid under belastning. Et søk som kjøres umiddelbart etter publisering, er derfor upålitelig som eneste måte å oppdage endringer på.21
Køer, timere og transportgrenser
SiteVisions data stores er aktuelle for små mengder connector-tilstand og outbox-poster, forutsatt at samtidig levering og feiloppførsel valideres. De støtter data i cluster, men er ikke dokumentert som en transaksjonell meldingsmegler. Poster har grenser på 50 egenskaper på toppnivå, nøkler på 100 tegn og egenskapsverdier på 5 000 tegn; interne ID-er og tidsstempler kan endres ved eksport/import. Bruk egne felt for event-identitet.27
Timerintervallene er 5, 15 og 30 minutter, hver time og daglig. De kjøres som Anonymous med mindre noe annet konfigureres eksplisitt. En handler som kjører lenger enn intervallet sitt, kan føre til at timer-events går tapt. Hold uttrekk og embedding-arbeid utenfor disse handlerne.24
Utgående Requester-kall deler en begrenset connection pool. Dokumentasjonen beskriver typiske verdier på 100 forbindelser og fem sekunders timeout, men dette er ingen garantert SLA for installasjonen. Send avgrensede meldinger til en rask mottaker og lagre leveringsfeil varig. Unngå lange, synkrone modellkall fra CMS-event handlers eller sideforespørsler.28
Cache API er flyktig og begrenset til 600 sekunder og 10 000 tegn per oppføring. Det kan ikke erstatte en varig kø, et eksportmanifest eller en søkedatabase.29
Alternativer med bare polling eller crawler
Hvis Modum ikke kan installere en RESTApp, kan BCW begynne med polling via Model REST. Dette krever full avstemming av innholdsoversikten for å oppdage slettinger og rettighetsendringer; tidsstempler alene er ikke nok. Innholdet vil være mindre oppdatert, og belastningen på kilden kan bli høyere.
SiteVision støtter også sitemaps og varsling av eksterne søkemotorer. Den dokumenterte sitemap-adressen er /sitemapindex.xml; både denne og /sitemap.xml returnerte HTTP 404 under gjennomgangen. Dette fastslår bare at disse offentlige URL-ene var utilgjengelige. Sitemaps kan omfatte filer, men er ikke en fullstendig synkroniseringsfeed som tar hensyn til rettigheter.30
Innstillingene for ekstern varsling dokumenterer tjenesteadresse, innloggingsopplysninger og varslingsfrekvens, men hjelpesiden som ble gjennomgått, er gammel og fastslår ikke payload, leveringsgarantier eller hvordan sletting håndteres. Behandle dette som en mulighet som må avklares med SiteVision, fremfor som en ferdig webhook-spesifikasjon.31
BCWs søke-API og design for gjenfinning
Endepunktnavnene og svaret nedenfor er en foreslått kontrakt. De er ikke deployede tjenester eller eksisterende SiteVision-endepunkter.
| Grensesnitt | Eksempel | Tilgang |
|---|---|---|
| Søk | GET /v1/search?query=...&limit=10&cursor=... | Godkjent offentlig korpus eller autentisert SiteVision-gateway |
| Forslag | GET /v1/suggest?query=...&limit=5 | Samme offentlige korpus |
| Endringsmottaker | POST /v1/integrations/sitevision/events | Bare autentisert connector |
| Synkroniseringsstatus | GET /v1/admin/sync/status | Driftsansvarlige hos BCW/Modum |
| Styring av avstemming | POST /v1/admin/sync/reconcile | Autoriserte driftsansvarlige |
{
"query": "hvordan søker jeg barnehageplass",
"items": [
{
"id": "modum:sitevision:<source-node-id>",
"title": "Søke/endre/si opp plass i barnehage og SFO",
"url": "https://www.modum.kommune.no/tjenester/barnehage/soke-endre-si-opp-plass-i-barnehage-og-sfo",
"snippet": "<excerpt from the current approved source>",
"type": "page",
"language": "nb",
"breadcrumbs": ["Tjenester", "Barnehage"]
}
],
"nextCursor": null,
"total": {"value": 1, "relation": "gte"},
"mode": "hybrid",
"requestId": "<request-id>"
}
Eksemplet viser svarstrukturen og ønsket resultattype; det er ikke et målt svar fra semantisk søk. Kilde-node-ID og språkmapping må komme fra den faktiske eksporten. Hold kildens locale og normalisert språk atskilt, fordi det offentlige nettstedet i dag oppgir språket sitt som no.
Bruk total.relation til å skille eksakte totalantall fra nedre grenser. Semantisk top-k-gjenfinning gir ikke naturlig et eksakt totalantall treff. Ikke etterlign dagens tilsynelatende eksakte antall med mindre backend faktisk beregner det. Knytt en cursor til søket, filtrene, rangeringsversjonen og et øyeblikksbilde av resultatene, eller definer eksplisitt hvordan den utløper.
Hver dokumentpost bør bevare tenant-/nettsteds-ID, kilde-node-ID og type, kanonisk URL, tittel, locale, seksjonshierarki, relevante filmetadata, publiserings-/endringsinformasjon, inklusjonsstatus, innholdshash, uttrekksversjon, embedding-modellversjon, siste vellykkede synkronisering og kildesporbarhet. Lagre chunks under dokumentet med referanser til overskrift og dokumentside.
Anbefalt sekvens for gjenfinning:
- Normaliser whitespace og Unicode uten å ødelegge norske tegn, egennavn, tall eller identifikatorer.
- Bruk faste filtre for tenant, offentlig tilgjengelighet og godkjent omfang.
- Hent semantiske og leksikalske kandidater, inkludert eksakte treff på titler og navn samt toleranse for skrivefeil der det er relevant.
- Slå sammen rangeringene, fjern duplikater på dokumentnivå og utfør eventuelt reranking av et avgrenset kandidatsett.
- Prioriter den autoritative, oppdaterte tjenestesiden når hensikten er å finne frem til en tjeneste, samtidig som relevante planer, forskrifter og historiske dokumenter bevares for dokumentspesifikke søk.
- Returner et utdrag fra seksjonen som traff, med kildelenke og dokumentmetadata. Ikke finn på et svar.
Denne hybride tilnærmingen er en anbefaling som må evalueres. Den bevarer søk på eksakte navn og identifikatorer, samtidig som den adresserer ordforrådsgapene som ble observert i testingen. Velg embedding-modell ved hjelp av eksempler fra Modum på bokmål, nynorsk og søk på tvers av språk, fremfor å anta at merkelappen «flerspråklig» garanterer tilstrekkelig kvalitet.
La chunks følge overskrifter og meningsfulle seksjoner; bevar tabellkontekst. Registrer modellversjoner slik at et senere modellbytte kan bygge en ny indeks ved siden av den gamle og bytte atomisk. Lagre kildeinnhold separat fra embeddings, slik at en modellmigrering ikke krever rekonstruksjon av innholdshistorikken.
Definer maksimal søkelengde, tillatte filtre, timeouts, rate limits, cache-oppførsel og eksplisitte feilsvar. Valider klientparametere fremfor å videresende vilkårlig Solr-syntaks, URL-er eller indeksnavn. Sikre tenant-isolasjon i tjenesten, selv om første kunde er Modum. Forslag må følge de samme inklusjonsreglene som søkeresultatene.
Ved feil i vektorsøket bør løsningen kunne falle tilbake på leksikalsk gjenfinning. Et API-avbrudd bør gi en tydelig tilstand som det er mulig å komme videre fra, eller den bevarte SiteVision-reserveløsningen. Null treff, delvis redusert tjeneste og en mislykket forespørsel må kunne skilles fra hverandre.
Integrere resultatene i SiteVision
Anbefalt WebApp
Bygg en WebApp 2 med TypeScript og SiteVisions støttede verktøy. Den bør akseptere eksisterende query-parameter, rendre søkeskjemaet og resultatene og oppdatere URL-en når søket eller resultatsiden endres. SiteVisions client router og requester støtter dette mønsteret.3233
Bruk avgrensede stiler og Modums eksisterende designtokens. SiteVision tilbyr CSS Modules og Envision-integrasjon og anbefaler å dele React-instansen som plattformen stiller til rådighet. Verifiser faktisk støttet React-versjon og renderingsmodus fremfor å kopiere en versjon fra et gammelt eksempel.34
To forespørselsveier er mulige:
| Mønster | Fordeler | Kostnader og begrensninger |
|---|---|---|
| Nettleser → BCW API | Enkel transport for offentlig søk; ingen ekstra forespørsel via CMS-et | Offentlig endepunkt trenger misbruksvern; konfigurer CORS og Modums CSP; nettleseren inneholder ingen hemmelighet |
| Nettleser → SiteVision WebApp/RESTApp → BCW API | Same-origin-kall fra nettleseren; BCW-credentials blir på serveren; enklere serverrendret førstesvar | Ekstra ledd og bruk av SiteVisions connection pool; trenger stram timeout og en god fallback |
Start med en enkel same-origin-gateway hvis Modum ønsker autentisering mot BCWs API eller krever en nyttig serverrendret førsteside. Et direkte offentlig API er også gyldig for et rent offentlig korpus. Test gatewayen under forventet trafikk, og bruk kort, bevisst caching fremfor å legge en treg avhengighet til hver siderendering.
WebAppen må håndtere innsending og valg av forslag med tastatur, fokus, formidling av treffantall til hjelpemidler, meningsfulle lenker, tilstander for lasting/feil/null treff, nettleserens tilbake-/fremoverknapper, innlasting via direktelenker og mobillayouter. Behold nyttig navigasjon dersom JavaScript eller API-et feiler. Dette er foreslåtte akseptansekriterier, ikke en påstand om at det eksisterende nettstedet er fullstendig revidert.
Andre støttede løsninger
Custom Search-maler: nyttige for visuelle endringer i SiteVisions egne resultater, men de mottar et SiteVision-SearchResult og modulspesifikk tilstand. De dokumenterer ingen generell konfigurasjonsbryter for å bruke en vilkårlig ekstern JSON-søketjeneste. Å erstatte skriptene og resultatkontrakten innebærer tilpasset integrasjonsarbeid.2
Intranett-søkeintegrasjon: SiteVision dokumenterer en RESTApp-/search-adapter som tar imot query, skip og max og returnerer items, hasMore og effectiveCount. Dette legger til en integrasjonsfane i intranettets søkemodul. Det er et alternativ hvis denne modulen faktisk velges for prosjektet, ikke dokumentasjon på at Modums offentlige Search-modul har samme utvidelsespunkt.35
Proxy-modul: kan integrere eksternt produsert HTML med begrensninger knyttet til omskriving. Dette er et eldre alternativ med HTML-/JavaScript-begrensninger og er ikke den foretrukne måten å vise resultater fra et nytt JSON-API på.36
Search Enterprise/custom indexes og SiteVision Crawler: disse henter eksternt innhold inn i SiteVisions indekser. Det er motsatt retning av å eksportere Modum-innhold til BCWs indeks. De kan være nyttige i en innebygd løsning, men er ikke automatisk påkrevd for en erstatning hostet av BCW.37
MCP Server: relevant for fremtidig tilgang for assistenter og verktøy. Det er ikke nødvendig for den etterspurte REST-søkeintegrasjonen og erstatter ikke en varig synkroniseringsprosess.38
Alternativ med innebygd semantisk søk
SiteVision har allerede funksjonalitet for semantiske indekser. AI Assistant SDK dokumenterer querySemanticIndex(assistant, {query, maxHits}), som returnerer innholdschunks som treffer søket, og kan kalles uten en autentisert gjeldende bruker. SDK-et krever riktig lisens og en Assistant-/kunnskapskonfigurasjon. Scores er dokumentert fra 2025.10.1.39
BCW kan pakke inn denne funksjonen i en RESTApp og vise resultatlenkene i en tilpasset WebApp uten å bygge en egen embedding-pipeline. Interne resultater gir node-ID-er og tekst; adapteren må slå opp titler og URL-er, gruppere flere chunks fra samme dokument og verifisere oppførselen ved offentlig tilgang. Den dokumenterte metoden tilbyr ikke den samme komplette søkekontrakten som en egen søkemotor: paginering, eksakte totalantall, omfattende filtre og rangeringskontroll må undersøkes eller implementeres i tillegg.
SiteVisions egen cookbook beskriver også innlegging av ekstern tekst i en semantisk kunnskapsbase, med kildeidentitet og tilgangsinformasjon. Dette åpner for en bredere innebygd løsning. Cookbookens lenke til dokumentasjonen for SemanticIndex-endepunktet returnerte en feil under gjennomgangen, så den fullstendige, gjeldende HTTP-kontrakten ble ikke verifisert.40
| Tilnærming | BCWs ansvar | Viktigste fordel | Hovedbegrensning |
|---|---|---|---|
| Selvstendig BCW-søk | Eksportpipeline, embeddings, korpus, API, rangering og UI | Maksimal kontroll og gjenbruk på tvers av CMS-plattformer | BCW har ansvar for korrekt synkronisering og løpende drift |
| Semantisk adapter med SiteVisions innebygde funksjoner | Adapter og UI; eventuelt en BCW-fasade | Mindre duplisering av infrastruktur for innhold | Lisens, innebygd gjenfinningskontrakt, plattformavhengighet og mindre kontroll |
| Forbedre eksisterende leksikalsk søk | Konfigurasjon og utvalgte maler/moduler | Mindre omfang; bevarer eksisterende søkefunksjonalitet | Dokumenterer ikke tilsvarende semantisk funksjonalitet |
Den selvstendige tilnærmingen anbefales når BCWs eget REST API, modellkontroll, observability eller en plattform for flere kunder er krav. Hvis det umiddelbare forretningsmålet bare er bedre søk på dette ene nettstedet, bør en liten prototype med innebygde funksjoner sammenlignes med den selvstendige prototypen på samme relevanssett før man bestemmer seg.
Eksisterende Searcher-API-er støtter parsere, feltvekting, filtre, stavekontroll, utheving, rettighetsstrategier og søkeovervåking. Norske stoppord er dokumentert. Feilene som ble observert hos Modum, beskriver derfor dagens konfigurasjon og innhold; de beviser ikke at SiteVision mangler relevante funksjoner for søkeforbedring.41
Deployment, forutsetninger og driftsansvar
WebApps og RESTApps i produksjon krever et SiteVision-signert sertifikat som nettstedet stoler på. Utvikleren må tilhøre et team for å administrere sertifikater. Den publiserte arbeidsflyten omfatter signering, oppsett av sertifikattillit, opplasting og aktivering av versjonen. Publisering i Marketplace er ikke nødvendig for å deploye en kundespesifikk app.42
Bruk versjonerte deployments og et testnettsted. SiteVision støtter flere versjoner under en addon og valg av aktiv versjon. Unngå å overskrive en aktiv produksjonsapp: beskyttelsen for bundlede apper behandles ved deployment, og den nye kjørbare versjonen er utilgjengelig til denne behandlingen er fullført.543
Connectorens konfigurerbare verdier bør omfatte kilderøtter, godkjente innholdstyper, adressen til BCWs mottaker, synkroniseringsinnstillinger og funksjonsbrytere. Hold credentials i serverkonfigurasjon eller en godkjent mekanisme for hemmeligheter, og serialiser dem aldri inn i WebAppens klienttilstand. requirePrivileged må deklareres og konfigureres hvis kode må kjøres som tjenestebruker; dette er ikke en grunn til å gi den offentlige resultatvisningen omfattende CMS-rettigheter.44
SiteVisions serversideskripting kjører i en sandbox. Ikke anta at dette er et generelt Node.js-hostingmiljø for vilkårlige filparsere, databasedrivere eller modellinferens. Hold beregningstung innlesing i BCWs miljø og bruk støttede plattform-API-er i connectoren.45
| Nødvendig fra Modum / deres SiteVision-partner | Hvorfor det er viktig |
|---|---|
| Installert versjon/build og hostingoppsett | Verifisere nyere uttrekks-API-er og installasjonens grenser |
| Autorisert utviklertilgang for lesing og testmiljø | Undersøke den faktiske modellen og teste innholdsdekning |
| API-eksponering og autentiseringskonfigurasjon | Velge direkte Model REST eller avgrenset eksport via RESTApp |
| Mulighet til å installere og aktivere addons og godkjenne BCWs signeringssertifikat | Deploye connectoren og WebAppen |
| Konfigurasjon for dagens søkemodul og maler | Bevare innganger, forslag og mulighet for tilbakeføring |
| Innholdsoversikt og ekskluderinger | Definere offentlige sider/filer og grenser mot eksterne kilder |
| Eksisterende synonymer, prioriterte treff og søkerapporter | Bevare redaksjonelle prioriteringer og etablere evalueringssettet |
| Forventninger til publisering og tilbakekalling av tilgang | Definere krav til oppdatering og fjerning fra søk |
| Forventet søketrafikk og tilgjengelighetskrav | Dimensjonere API-et og teste SiteVision-gatewayen |
| Avtaler om hosting, lagringstid og behandling | Avgjøre hvor innhold, søkelogger og embeddings kan lagres |
Hvis en custom index inneholder nyttige synonymer eller prioriterte resultater, kan SiteVisions synonyms- og elevations-endepunkter lese disse konfigurasjonene med dokumentert lisens og rettigheter. Tilgjengeligheten hos Modum er ikke verifisert.46
BCW bør drifte API-et, indeksen, workers, feilkøer, backuper, varsler, modellversjoner og deployment-pipeline. Modum bør eie innholdsgodkjenningen og relevansvurderingene for sine tjenester. Avtal hvem som håndterer problemer i kildedata og mislykkede dokumentuttrekk.
Overvåk synkroniseringsforsinkelse, eldste ventende event, mislykket lesing fra kilden, uttrekksdekning, manglende kilde-ID-er, fjerning fra søk på grunn av rettigheter, antall indekserte dokumenter/chunks, søk med null treff, latenstidspersentiler og hyppighet av fallback. Søketekst kan inneholde personopplysninger; begrens lagringstid og logging og etabler en dokumentert policy. SiteVisions egen logging-dokumentasjon advarer også mot logging av personopplysninger.47
Proof of concept og utrulling
1. Etablere tilgang og kildekontrakten
Bekreft forutsetningene for installasjonen ovenfor. Undersøk et representativt utvalg på 30–50 sider og dokumenter på tvers av tjenester, nyheter, arkivinnhold, lenkede layouter og tilpassede moduler. Sammenlign synlig hovedtekst, headless-eksport og uttrekk av indekserbart innhold der dette støttes. Lag et manifest med inkluderte, ekskluderte, mislykkede og ikke-støttede poster.
Ferdigkriterium: teamet kan forklare hvor hver utvalgte sides søkbare tekst kommer fra, og demonstrere at utkast og privat innhold er utelatt.
2. Bygge en avgrenset synkroniseringsløsning
Installer en connector i testmiljøet og les utvalget inn i en ekstern indeks. Test publisering, republisering, utkastendringer uten publisering, planlagt avpublisering, flytting, sletting til papirkurv, gjenoppretting, erstatning av filer, valg av filversjon, tilgangsbegrensning og en arvet tilgangsendring. Simuler duplisert levering, et tapt event, omstart av connectoren, midlertidig autentiseringsfeil og et driftsavbrudd hos BCW.
Ferdigkriterium: hver testede endring ender i riktig sluttilstand; fjerning overstyrer en eldre oppdatering i køen; en mislykket gjennomgang kan ikke slette korpuset; avstemming fanger opp tapte endringer.
3. Evaluere gjenfinning
Lag et vurdert sett med minst 50–100 innbyggeroppgaver sammen med Modum. Inkluder de observerte søkene, alternative formuleringer, vanlige feil, eksakte dokumenttitler, navn, tjenesteidentifikatorer, bokmål/nynorsk og engelske søk dersom søk på tvers av språk inngår i omfanget. Registrer hvilke sider som bør rangeres høyt, og hvilke svar som krever en ekstern tjeneste.
Sammenlign dagens søk, en leksikalsk baseline, hybridprototypen og eventuelt adapteren for innebygd semantisk søk. Mål nyttige resultater blant de tre eller fem første treffene, rangeringskvalitet, oppførsel ved null treff, duplikater og latenstid. Ikke sett likhetstegn mellom «returnerer noe» og «finner riktig tjeneste».
Ferdigkriterium: avtalte relevansforbedringer uten vesentlig tilbakegang på viktige eksakte søk eller upassende prioritering av gamle dokumenter.
4. Integrere og lansere
Erstatt resultatkomponenten i testmiljøet og koble til alle innganger og forslag. Test tilgjengelighet, mobiloppførsel, nettleserhistorikk, bokmerkede søke-URL-er, paginering, tomme søk, lange søk, API-feil og fallback. Verifiser sertifikattillit i miljøet, versjonsaktivering og tilbakeføring.
Utvid til hele det godkjente korpuset, avstem antall og uttrekksdekning, og kjør trafikktester i produksjonsskala mot avtalte mål. Aktiver det nye søket med en reverserbar konfigurasjonsbryter. Behold den gamle modulen/versjonen eller en forberedt reserveside til den nye tjenesten har bestått den avtalte observasjonsperioden.
Et fornuftig første mål å diskutere er søkerespons under ett sekund ved avtalt trafikk og oppdateringer som slår gjennom innen noen få minutter under normal drift. Dette er foreslåtte produktmål, ikke målt ytelse eller garantier fra SiteVision. Tilbakekalling av tilgang trenger en egen, strengere policy dersom det kreves.
Et pålitelig fastpristilbud for implementeringen kan ikke utledes fra det offentlige nettstedet alene. Kostnadsdriverne er dokumentmengde og kvalitet, modulspesifikt uttrekksarbeid, tilgangshåndtering, eksterne kilder, trafikk, relevanstilpasning og driftskrav. Estimer etter arbeidet med kildekontrakten; skill mellom førstegangsinnlesing, løpende modell-/API-bruk, hosting, support og eventuelle SiteVision-lisenskostnader.
Dokumentasjonsdekning og uavklarte punkter
Utviklernettstedets sitemap inneholdt 410 sider under /docs/, og alle ble hentet for katalogisering og relevansvurdering. Undersøkelsen gjennomgikk de vesentlige delene av Public API/JCR, innholdsnodetyper, Model REST-endepunkter, WebApps, RESTApps, events, søk/indeksering, lagring, sikkerhet, deployment og innebygd KI, og fulgte deretter relevante referanser til Javadoc, hjelpesider, release notes og cookbook.
Den tilhørende dokumentasjonsoversikten skiller den brede katalogen fra referanser som ble undersøkt for denne rapporten. Henting og relevansvurdering er ikke en påstand om at hver metode i hver Javadoc-klasse, alle historiske release notes eller alle uvedkommende plattformfunksjoner ble lest linje for linje. Rapporten dekker integrasjonsveiene og de vesentlige begrensningene som ble funnet; den kan ikke garantere dekning av «all potensielt relevant dokumentasjon» på et åpent dokumentasjonsnettsted i stadig endring eller erstatte installasjonens beskyttede API-dokumentasjon.
De viktigste uavklarte punktene er:
| Punkt | Observasjon og nødvendig avklaring |
|---|---|
| Modums API-tilgjengelighet | /rest-api/doc returnerte 403 anonymt. Undersøk etter autorisert innlogging. |
| Tilgjengelighet av innholdsextractor | Public API oppgir støtte fra 2026.03.1. Verifiser Modums versjon og renderingsdekning. |
| Fullstendighet i headless-eksport | Avhenger av modulstøtte og gyldig headless-output. Sammenlign eksport med synlige sider. |
| Garantier for event-levering | Garantier for varig replay, rekkefølge og retries ble ikke fastslått. Test og implementer avstemming. |
| Oppdagelse av tilgangsendringer | Intet fullstendig side-ACL-event ble identifisert. Avtal avstemming og håndtering av tilbakekalling. |
| Lisens og søkesemantikk for innebygd semantisk søk | Funksjonen er dokumentert; Modums rettigheter og egnethet for produksjon er ikke verifisert. |
| HTTP-endepunkt for innebygd semantisk søk | Cookbook-lenken var utilgjengelig. Skaff installasjonsspesifikk dokumentasjon. |
| Sitemap-tilgjengelighet | Dokumentert offentlig adresse returnerte 404. Kontroller nettstedsinnstillingene hvis crawler velges. |
| Søkeinnhold utenfor SiteVision | Lenkede systemer krever egne kildeavtaler eller redaksjonelt valgte lenker. |
| Endringer og inkonsistens i dokumentasjonen | Noen veiledninger inneholder gamle eksempler eller motstridende detaljer. Bruk versjonsspesifikke API-referanser og tester i testmiljø. |
Neste konkrete steg er en tilgangs- og uttrekksøvelse i testmiljøet. Den vil avklare om en avgrenset RESTApp med den nyere extractoren for indekserbart innhold kan levere hele det godkjente korpuset, og avklare gjenstående arbeid og deployment-avhengigheter før BCW forplikter seg til en produksjonsimplementering.
Kilder
Alle kilder er SiteVisions offisielle dokumentasjon eller Modums offentlige nettsted, undersøkt 10. september 2026 med mindre annet er oppgitt. Datoer i URL-stier gjenspeiler ofte dokumentets opprinnelige publisering og ikke siste oppdatering.
Footnotes
-
SiteVision, Model REST API. Modum, installasjonens API-dokumentasjon, HTTP 403 observert ved anonym tilgang. ↩ ↩2 ↩3
-
SiteVision, Search custom template and Search field custom template. Modum, dagens søk, skjemamarkup og oppgitt HTML-endepunkt undersøkt. ↩ ↩2
-
SiteVision, Public API and Utilities API. ↩
-
SiteVision, JCR Model API. ↩
-
SiteVision, Getting started with RESTApps. ↩ ↩2
-
SiteVision, RESTApp security, RESTApp addon management, og REST API settings panel. ↩
-
SiteVision, RestApi Javadoc. ↩ ↩2
-
SiteVision, Login configuration. ↩
-
SiteVision, OAuth2 SDK. ↩
-
SiteVision, ResourceLocatorUtil and node types. ↩
-
SiteVision, Nodes endpoint. ↩
-
SiteVision, Properties endpoint. ↩
-
SiteVision, ContentNodes endpoint. ↩ ↩2 ↩3
-
SiteVision, Headless endpoint. ↩ ↩2
-
SiteVision, Search endpoint. ↩
-
SiteVision, IndexableContentExtractor. ↩
-
SiteVision, Standard Index. ↩
-
SiteVision, IndexableContentExtractorBuilder. ↩
-
SiteVision, PermissionUtil. ↩
-
SiteVision, WebApp headless.js. ↩
-
SiteVision, System Event Options. ↩ ↩2 ↩3
-
SiteVision, RESTApp events. ↩
-
SiteVision, VersionedRestApi. ↩
-
SiteVision, Data Storage, Key-value Data Store, og Collection Data Store. ↩
-
SiteVision, Requester guide and Requester Javadoc. ↩
-
SiteVision, Search settings panel. Modum, dokumentert sitemap-adresse, HTTP 404 observert. ↩
-
SiteVision, Add search engine notification, side datert 28. februar 2019. ↩
-
SiteVision, WebApps, Getting started, og TypeScript. ↩
-
SiteVision, Client router and Client requester. ↩
-
SiteVision, Styling, React, og Client-side rendering. ↩
-
SiteVision, Intranet search integrations. ↩
-
SiteVision, Proxy guidelines and restrictions. ↩
-
SiteVision, Custom Index, Index External Data, og SiteVision Crawler. ↩
-
SiteVision, MCP Server. ↩
-
SiteVision, AI Assistant SDK. ↩
-
SiteVision, Integrating external sources into a Knowledge base, juli 2026; Working with AI Assistants, oppdatert april 2026. ↩
-
SiteVision, Certificates and signing and RESTApp signing. ↩
-
SiteVision, RESTApp deployment and Coming from RESTApps 1. ↩
-
SiteVision, RESTApp manifest, privileged SDK, og RESTApp configuration. ↩
-
SiteVision, Sandboxing in scripts. ↩
-
SiteVision, Synonyms endpoint and Elevations endpoint. ↩