Indholdsfortegnelse

1. Indledning

I forbindelse med at CPR moderniserer GCTP Services er der en række områder hvor GCTP Services generelt afviger fra de tidligere services, herunder funktionaliteter som udgår. Disse afvigelser er en del af version 2 af GCTP protokollen (<Gctp v="2.0">).

2. Afvigelser

2.1. GCTP / XML

GCTP er er en proprietær XML lignende protokol, der tidligere har kunne håndtere ikke valid XML. Dette er ikke tilfældet længere. Al GCTP der sendes ind til GCTP services SKAL være valid XML der kan parses af XML parsere. Det samme gælder output. Al output fra GCTP Services vil være valid XML.

2.2. Konstaterende myndighed

Tidligere ville myndighedsfelter i services ofte være låst efter man har initieret servicen, typisk med den indberettende myndighed, på vegne af eller land.

Dette er ikke længere tilfældet. Myndighedsfeltet i en indberetning vil fremadrettet altid være åbent og man kan indsende en vilkårlig af systemet kendt myndighed. Dette betegnes som den konstaterende myndighed, dvs. den myndighed der har konstateret de data der indberettes

Ofte vil det være selvsamme myndighed der er tilknyttet brugeren, der er logget ind, men det kan også være en anden myndighed. F.eks. er man logget ind som en kommune, men har behov for at indberette, at det er land der har konstateret data.

Derfor vil myndighedsfelter ved indberetninger altid være forudfyldt med den indberettende myndighed, svarende til brugerens myndighed. Hvis der er tale om rettelse til eksisterende data vil der stå den myndighed der har indberettet de data der rettes i.

Det er ikke alle myndigheder der kan anvendes som konstaterende myndighed og da dette er forskelligt fra service til service, er dette dokumenteret som en del af servicedokumentationen på den individuelle service.

2.3. Udfasning af på vegne af og land

Under initiering har man før kunne angive hhv. på vegne af og land, hvilket så blev ført med over i selve indberetningen. Dette udfases, da man i stedet arbejder men en konstaterende myndighed. Der er i de fleste services ét specifikt felt hvor man angiver denne konstaterende myndighed

I stedet for at anvende på vegne af eller land, angiver man således i selve myndighedsfeltet på indberetningen hvilken myndighed der har konstateret data, og i det tilfælde det havde været på vegne af eller land, så er det den myndighed man angiver.

Man kan stadig godt udfylde feltet på vegne af eller land, men de moderniserede services vil afvise initiering med disse felter.

I CPRWeb vil felterne løbende bliver fjernet fra initieringsskærmbilledet.

2.4. Verificeret felter

I udvalgte services er det muligt at angive, at data der indberettes, er verificeret. Disse vil altid være åbent for ændring, og vil altid være markeret som standard.

Hvis der redigeres i eksisterende data, vil den bære den markering der måtte være i det eksisterende data.

Dette er forskelligt fra tidligere, hvor det var forskelligt fra service til service om feltet var låst eller ej, og hvor vidt der blev forudfyldt.

2.5. Advarsler ved vent

En person kan have indberetningsdata liggende i en kladde, som afventer endelig godkendelse, eller bare en dato for offentliggørelse. Hvis en person har data i dette kladdesystemet, også kaldet Vent, vil der komme en advarsel, når man forsøger at validere eller gemme en indberetning på denne person.

Dette er som tidligere bare en advarsel, og man kan gemme data alligevel, hvis man gemmer igen efter at have fået advarslen.

Dette er forskelligt fra tidligere, hvor det ikke var alle indberetninger, der kom med denne advarsel.

Hensigten med advarslen er, at personen potentielt kan have data liggende i kladdesystemet, som vil overskrive de data man ellers indberetter.

2.6. Tabeller i GCTP Services

En række GCTP Services understøtter indberetning af data i tabeller, hvor der således kan være flere rækker. I den gamle version af GCTP er der ikke et entydig krav om, at man som anvender identificerer hver række med en nøgle. Dette er et KRAV ved anvendelse af tabeller i den moderniserede GCTP Services.

Nøgler skal altid udfyldes, skal være unikke i GCTP kaldet, og der skal anvendes de nøgler som en GCTP service evt. har udstedet under initiering.

En række i GCTP før modernisering kunne f.eks. se ud som herunder, hvor man ønsker at lave en ny registrering af notatlinie 1 i Kommunale notater

I den moderniserede GCTP skal k-attributten være udfyldt med en unik nøgle, herunder med værdien k="NOTAT1_NOEGLE"

2.7. GCTP Character Encoding

Der understøttes kun ISO-8859-1 encoding.

2.8. GCTP Sekundære Services

Sekundære services er udgået af version 2 af GCTP protollen. Services der tidligere har fungeret med sekundære services håndteres fremadrettet med komposit services, hvor de tidligere sekundære services er indlejret i hovedservicen, såfremt deres data er påkrævet for servicens funktionalitet. For sekundære services der ikke er påkrævet, skal disse services i stedet anvendes og kaldes for sig selv, som selvstændige services.

2.9. Forsimplinger af services

En række services har tidligere kunne indberette data fra flere domæner samtidig. F.eks. en flytning hvor man tidligere har kunne indberette supplerende adresse, kommunale forhold, kommunale notater, flyttepåbud og beskyttelser sammen med den egentlige flytning.

Dette udfases og services forsimples til at indeholde så få ekstra domæner som muligt. F.eks. vil en flytning fremadrettet kun kunne anvendes til at flytte personen. Har man behov for at registrere beskyttelse, skal man derfor anvende beskyttelsesservicen til det formål.

Der er enkelte services hvor disse ekstra domæner stadig vil være til stede, dog i mindre omfang. F.eks. vil en Indrejse kræve mere end bare oplysninger om indrejsen.

Det vil fremgå af den enkelte servicedokumentation hvad der understøttes.

2.10. Dokumentation

Dokumentation forefindes kun på dansk.