Versions Compared

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

  • Webservicesnitflader (SOAP/XML format)
    • Forretningsservices
    • Dataservices (CRUD)
    • Besked-kø (WSRM lignende kø)
  • Dataload/ETL
    • Dataload via staging-database
    • Dataload via filer (XML/CSV)


 

...

 

Figur 1: To niveauer af snitflader. Webservices og dataload/ETL

...

Dataservices er webservices der har fokus på at opdatere/publicere[1] data på forskellige aggregeringsniveauer

...

  1. DFDG skal indeholde alle relevante data om en borgers aktuelle og historiske beskæftigelses-indsatstilstand[2], som skabes i beskæftigelsesindsatsen i kommuner, a-kasser, regioner, stat og af borger via selvbetjening. Med relevant menes data som mere end en af ovenstående aktører har behov for at kunne opdatere.
    1. Inden data placeres i DFDG skal det afklares hvem der har behov for tilgang til data og om data allerede findes et andet sted.
  2. Derudover skal DFDG indeholde nødvendige data for at kunne styre og administrere data.
  3. DFDG baseres på veldefinerede logiske datamodeller, og anvender så vidt muligt allerede definerede entiteter og attributter
  4. Data skal inkludere det fulde revisionsspor med identifikation af, hvilke data der er registreret/slettet af hvem og hvornår.
  5. Dataentiteter kan inkludere felter med sagsbehandlers begrundelse/noter for den enkelte registrering af hensyn til journalpligten og for at undgå dobbeltregistrering i aftagende systemer.
  6. DFDG er og skal ikke være et komplet journalsystem. Generelle dokumenter og notater skal opbevares i de enkelte aftagersystemer.

...

  1. Ved opdateringer skal alle transaktioner og data-elementer tidsstemples (evt. med sekvensnummer), således at aktører kan se og reagere på det korrekte tidsmæssige forløb af opdateringer.

  2. Det er aktørsystemernes ansvar at reagere korrekt, hvis der ved opdatering af DFDG-data under et sagsbehandlingsforløb er sket opdatering af DFDG-data fra anden kilde (”samtidighedsfejl”), og aktørsystemet skal i givet fald gentage læsning af de opdaterede DFDG-data. Ændringer i lokale kopier af DFDG-data må (så vidt muligt) ikke gøres permanente, før ændringen er gennemført i DFDG. Det er det aftagende systems ansvar at sikre at DFDG opdateres korrekt.

  3. Data skal kunne læses samtidigt af flere aktører, og ved opdateringer fra en aktør af flere samtidige dataentitetsinstanser, skal dataintegriteten sikres (f.eks. ved database-transaktionshåndtering[3]).

    1. På sigt arbejdes mod at tilbyde transaktioner på tværs af webservicekald

    2. Komposite services tilbydes de steder hvor der er en forretningsmæssig samtidighed i registreringerne

  4. Data- og forretningsservices, som tilbyder opdatering af data, skal i kvitteringen angive om opdateringen i DFDG lykkedes, eller om der opstod fejl (f.eks. ved kast af SOAP-Fault). Dvs. at aftager får svar med det samme.

  5. Når en forretningshændelse, f.eks. som resultat af kald til en forretningsservice, udløses i DFDG, eller når en data-entitetsinstans opdateres, f.eks. som resultat af en dataservice, udsendes besked om hændelsen til alle relevante aktører via besked-kø med tilstrækkelig data til at modtager kan identificere hændelsen i DFDG og dermed den eller de berørte data-entiteter, herunder hvilken type af opdatering der er foretaget.
    1. Aftagere underrettes via WSRM beskeder
    Som verifikation af konsistensen mellem DFDG og et aktør-system, skal DFDG kunne tilbyde services, der for hele populationer returnerer datostempler for, hvornår den enkelte dataentitet eller grupper af dataentiteter senest er ændret, dennes virkningstid.
    1. Disse udstilles kun hvor der er et forretningsmæssigt behov.
  6. Aktør-systemer og DFDG, skal kunne danne og anvende unikke nøgler, GUID’er, som identificerer de enkelte instanser af data-entiteter og kan deles mellem alle aktører. De unikke nøgler bør dannes af det system, der også er kilde til data, sådan at samme nøgle følger data fra det skabes i et aftagersystem, til det gemmes i DFDG.
    1. I dag er de fleste services i DFDG konstrueret sådan at det er DFDG der danner nøglerne. I en overgang konstrueres services sådan at DFDG fortsat kan danne nøglen, hvis ikke nøglen medsendes af kildesystemet.

...

  1. Dataentiteter skal modellerres under hensyntagen til offentlige krav som Grunddataprogrammets modelregler: http://arkitekturguiden.digitaliser.dk/grunddata-modelregler
  2. Arkitekturguidens krav skal efterleves: http://arkitekturguiden.digitaliser.dk/standarder


[1] Med ’publicere’ menes læseadgang til data. I dag er Read operationen i de fleste CRUD implementeringer samlet i hhv. historik- og status-services.

[2] Som minimum 5 år tilbage i tid.