Forvaltningssynkronisering
Forvaltningssynkronisering er en betaversjon som fortsatt er under utvikling. Funksjonalitet og oppførsel kan endres.
Vær forsiktig hvis du bruker løsningen på produksjonsdata. Synkroniseringen skriver endringer direkte til både AGOL og det sentrale datasettet. Ta backup før du synkroniserer, og test gjerne med en kopi av dataene først.
Oversikt
Forvaltningssynkronisering holder data i ArcGIS Online (AGOL) synkronisert med et sentralt forvaltningssystem — i dag NGIS (bl.a. Sentral FKB). Endringer gjort i AGOL sendes automatisk til det sentrale datasettet, og endringer i det sentrale datasettet sendes tilbake til AGOL-tjenesten. Slik kan organisasjonen redigere i kjente ArcGIS-verktøy, mens forvaltningssystemet forblir fasit.
Synkadmin er web-appen der du administrerer synkroniseringen: du oppretter koblinger mellom AGOL-tjenester og sentrale datasett, kjører og planlegger synkroniseringer, og følger med på status.
- Brukergruppe: GIS-administratorer som setter opp og overvåker synkronisering mellom AGOL og forvaltningssystemet.
- Krever: ArcGIS Online-bruker i organisasjonen, og tilgang til organisasjonens Synkadmin-instans (f.eks.
synkadmin.<kunde>.kommunegis.no).
Innlogging
Synkadmin bruker ArcGIS Online-innlogging. Når du åpner appen, sendes du til ArcGIS Online for å logge inn, og deretter tilbake til appen. Navnet ditt vises øverst til høyre, og Logg ut avslutter økten.
Innloggingen gir appen et AGOL-token som også brukes mot synkroniseringsløsningen. Hvis tokenet utløper mens appen er åpen, begynner kallene å feile med meldingen «API-et avviste tokenet (401/403)» — da er løsningen å logge ut og inn igjen (eller laste siden på nytt). Se Status og feilsøking for detaljer.
Hovedvisningene
| Visning | Hva du gjør der |
|---|---|
| Koblinger | Oppretter og forvalter synkroniseringskoblinger mellom AGOL-tjenester og forvaltningssystemet, kjører manuell synk og setter opp tidsstyrt synk. |
| Datasett | Søker opp datasett i forvaltningssystemet, inspiserer skjemaet, forhåndsviser objekter i kartet og provisjonerer nye AGOL feature-tjenester. |
| Status | Ser helse, synkroniseringskøen og tidsstyrt synk per kobling. |
| Innstillinger | API-tilkobling. |
Komme i gang
- Logg inn med ArcGIS Online-brukeren din.
- Gå til Datasett og søk opp datasettet du skal synkronisere.
- Har du ingen AGOL-tjeneste fra før: trykk Provisjoner AGOL-tjeneste — da opprettes en feature-tjeneste fra datasettets skjema, og en kobling kan registreres automatisk. Har du en eksisterende tjeneste: gå til Koblinger og trykk Opprett kobling.
- Gå gjennom mapping-steget i veiviseren og kontroller at objekttyper og felter er riktig koblet — se Bruke Synkadmin.
- Velg Synkroniseringsretning for koblingen: kun AGOL → Sentral, kun Sentral → AGOL eller begge veier. Se Retningssperre.
- Skal objekter som allerede finnes i AGOL, over til det sentrale datasettet, kjører du Initial last. En ny kobling synkroniserer ellers bare endringer gjort etter at den ble opprettet. Se Startpunkt og initial last.
- Kjør en manuell synk i ønsket retning og kontroller resultatet i dataene.
- Sett opp Tidsstyrt synk slik at synkroniseringen går automatisk.
- Følg med på Status. Der ser du køen og om noe krever oppfølging.
Slik virker synkroniseringen
Kobling
En kobling knytter ett AGOL feature-service til ett sentralt datasett i forvaltningssystemet. Tjenesten har ett sublag per objekttype og geometritype (Punkt / Linje / Flate), og koblingen inneholder en feltmapping som beskriver hvilke AGOL-felter som svarer til hvilke felter i det sentrale datasettet — inkludert oversettelse av kodeverdier (domener).
Nøkkelen som knytter objektene sammen på tvers av systemene, er feltet identifikasjon.lokalId. Hvert koblet lag må ha dette feltet mappet — uten det kan ikke løsningen vite hvilket AGOL-objekt som svarer til hvilket sentralt objekt.
Hver kombinasjon av objekttype og geometri har sitt eget AGOL-lag. Har en objekttype flere geometrivarianter, for eksempel Hendelse som både punkt og flate, kobles hver variant til hvert sitt lag med samme geometritype. To varianter kan ikke dele lag, og et punktlag kan ikke kobles til en flatevariant. Løsningen avviser en mapping som bryter denne regelen.
Det spiller ingen rolle om AGOL-tjenesten ble provisjonert av løsningen eller fantes fra før — alle koblinger fungerer likt.
Retninger
Synkroniseringen går i to retninger, og hver kjøring gjelder én retning:
- AGOL → Sentral — endringer gjort i AGOL-tjenesten skrives til det sentrale datasettet.
- Sentral → AGOL — endringer i det sentrale datasettet skrives til AGOL-tjenesten.
Hver kjøring og hver tidsplan gjelder én retning. Hvilke retninger som er lov for en kobling, bestemmes av koblingens retningssperre.
Retningssperre
Hver kobling har en retningssperre som du må velge når koblingen opprettes. Det finnes ingen standardverdi.
| Valg | Betydning | Typisk bruk |
|---|---|---|
| Kun AGOL → Sentral | Endringer sendes til det sentrale datasettet, men aldri tilbake til AGOL. | AGOL er originalen, og det sentrale datasettet dekker et større område enn AGOL-tjenesten, for eksempel et fylke. |
| Kun Sentral → AGOL | Det sentrale datasettet er kilden, og AGOL-tjenesten er en kopi. Endringer i AGOL sendes ikke videre. | Data forvaltes i forvaltningssystemet, og AGOL-tjenesten skal bare speile dem. |
| Begge veier | Toveis forvaltning med konfliktdeteksjon. | Organisasjonen redigerer både i AGOL og i forvaltningssystemet. |
Sperren gjelder alle måter å starte synkronisering på: manuell synk, Synk alle aktiverte, tidsplaner og webhook-varsler. Synk i en sperret retning blir avvist eller hoppet over.
Sperren hindrer et konkret uhell: at en kjøring fra Sentral til AGOL henter objekter fra et fylkesdatasett inn i en kommunal AGOL-tjeneste som er originalen. Sperren er et vern mot feil, ikke en tilgangskontroll. Den som kan redigere koblingen, kan også endre sperren.
Koblinger som fantes før retningssperren ble innført, står på Begge veier.
Den første kjøringen i den nye retningen starter fra null og henter hele datasettet fra kilden. Åpner du for Sentral → AGOL og det sentrale datasettet er et fylkesdatasett, havner også objekter utenfor ditt område i AGOL-tjenesten. Synkadmin ber deg bekrefte endringen. Ta backup før du bytter.
Startpunkt og initial last
En ny kobling begynner å lytte på endringer i AGOL fra det øyeblikket den opprettes. Objekter som allerede finnes i AGOL-tjenesten, sendes ikke til det sentrale datasettet av seg selv. Det gjelder selv om første synkronisering skjer lenge etter opprettelsen, for eksempel fordi koblingen var deaktivert.
Dette er bevisst: ofte finnes dataene allerede i det sentrale datasettet, og da skal de ikke sendes på nytt.
Skal eksisterende AGOL-objekter over til det sentrale datasettet, bestiller du en initial last fra koblingens detaljvisning (se Bruke Synkadmin). Initial last:
- henter alle objekter i de mappede lagene, side for side
- oppdaterer objekter som allerede finnes i det sentrale datasettet, i stedet for å lage duplikater
- fortsetter der den slapp hvis noe feiler underveis
- tar med endringer som gjøres i AGOL mens lasten pågår; disse spilles av etterpå
- sender ikke objekter som sist ble redigert av synkroniseringens egen servicebruker (se Ekko-beskyttelse)
Når lasten er ferdig, går koblingen over til vanlig synkronisering av endringer.
Initial last finnes bare for retningen AGOL → Sentral, og bare når retningssperren tillater den. For Sentral → AGOL starter første kjøring fra null og henter hele det sentrale datasettet.
Synk-køen og sjekkpunktet
Alt som utløser en synkronisering — manuell synk fra Synkadmin, initial last, tidsstyrt synk eller et webhook-varsel fra AGOL — legger en forespørsel i den samme synk-køen. En worker plukker forespørslene fra køen én om gangen og gjennomfører synkroniseringen.
Et viktig prinsipp: utløseren er bare et signal. Selve endringene hentes alltid direkte fra kildesystemet, basert på et sjekkpunkt som husker hvor forrige kjøring slapp. Det gjør løsningen robust: går et varsel tapt, tas alle endringene igjen ved neste kjøring. Og sjekkpunktet flyttes aldri forbi en endring som feilet — ingenting hoppes stille over; feilede endringer forsøkes på nytt ved neste kjøring.
Ekko-beskyttelse
Når løsningen skriver en endring til AGOL, må ikke den samme endringen «sprette» tilbake til det sentrale datasettet ved neste kjøring (og omvendt). Dette håndteres automatisk:
- Endringer i AGOL som er gjort av synkroniseringens egen servicebruker, filtreres bort før de sendes til det sentrale datasettet.
- Endringer fra det sentrale datasettet som løsningen allerede kjenner versjonen av, filtreres bort før de skrives til AGOL.
Du trenger ikke gjøre noe for at dette skal virke — men det forklarer hvorfor synkroniserte endringer ikke dukker opp som «nye» endringer i motsatt retning.
Konfliktdeteksjon
En konflikt oppstår når det samme objektet er endret i begge systemer siden forrige synkronisering. Løsningen oppdager dette ved å sammenligne mottakersystemets tilstand med det som var kjent fra forrige kjøring:
- Skal en endring skrives til det sentrale datasettet, sjekkes objektets versjons-ID i NGIS — er den en annen enn sist, har noen endret objektet sentralt.
- Skal en endring skrives til AGOL, sjekkes objektets siste redigeringstidspunkt — er det nyere enn det løsningen selv skrev sist, har noen endret objektet i AGOL.
Standardoppførselen er å logge konflikten og fortsette — endringen skrives, og konflikten registreres per objekt i companion-tabellen (feltet conflictStatus), slik at den kan følges opp. Når konflikten er løst i kildesystemet, nullstilles statusen automatisk ved neste vellykkede synkronisering.
Konfliktdeteksjonen mot AGOL forutsetter at tjenesten har editor tracking med både editor- og redigeringsdato-felt. Mangler dette, viser Synkadmin advarselen «mangler — konfliktdeteksjonen er blind» på koblingen: synkroniseringen virker, men konflikter i AGOL kan ikke oppdages.
Companion-tabellen
For hver kobling opprettes automatisk en egen tabell i AGOL med navnet <kobling-id>_synkstatus — companion-tabellen. Den holder synkroniseringsmetadata per objekt: identitet (lokalId), synk-status, tidspunkt for siste synk, eventuell feilmelding og konfliktstatus.
Poenget med en egen tabell er at fagdatalaget holdes rent — selve feature-tjenesten inneholder bare fagdata, ingen tekniske synk-felter.
Krav til AGOL-tjenesten
For at synkroniseringen skal virke, må feature-tjenesten i AGOL ha:
- ChangeTracking aktivert — det er slik løsningen finner endringer i AGOL. Merk at ChangeTracking og Sync-funksjonen (offline-synk) ikke kan være aktivert samtidig på samme tjeneste.
- Editor tracking aktivert, med både editor-felt og redigeringsdato-felt — brukes til ekko-filtrering og konfliktdeteksjon.
Tjenester som provisjoneres fra Synkadmin, settes opp riktig automatisk. For eksisterende tjenester sjekker veiviseren dette når du oppretter koblingen, og lister det som eventuelt må rettes.
Synlighet for provisjonerte tjenester
Tjenester som provisjoneres fra Synkadmin, opprettes og eies av synkbrukeren, den faste AGOL-brukeren synkroniseringsløsningen kjører som. Uten videre er de derfor bare synlige for synkbrukeren, ikke for deg som er logget inn i Synkadmin.
ArcGIS Online kan ikke dele et element med én enkelt bruker, bare med grupper. Løsningen deler derfor hver nye tjeneste, og companion-tabellen, med gruppen SynkAdminShareGroup, så sant gruppen finnes og synkbrukeren er medlem av den. Alle som er medlem av gruppen, ser tjenesten i AGOL.
- Opprett en gruppe i ArcGIS Online med tittelen SynkAdminShareGroup. Tittelen må stemme nøyaktig. En vanlig gruppe er nok; den skal ikke være en gruppe med delt oppdatering.
- Legg til synkbrukeren som medlem.
- Legg til de Synkadmin-brukerne som skal se de provisjonerte tjenestene.
Ikke gi gruppen nytt navn. Da stopper delingen uten at du får beskjed.
Finnes ikke gruppen, virker provisjoneringen som før, men tjenesten blir bare synlig for synkbrukeren. Delingen skjer når tjenesten opprettes. Tjenester som ble provisjonert før gruppen fantes, deles ikke i ettertid; de må eventuelt deles manuelt i AGOL.