Contract
1. Services, egne (udgående)
Navn: navn på egen service, eksempelvis: BrugsenhedAjourfoer |
Formål: Formålet med servicen beskrives kort, eksempelvis: Formålet med servicen er at oprette en den Brugsenhed som beskriver en Ejerlejlighed |
Understøttede processer: Der beskrives kort hvilke processer servicen skal understøtte, eksempelvis: Understøtter proces- sen med udarbejdelse af teknisk dokumentation for Ejerlejligheder i Matriklen |
Liste over operationer/metoder: Komplet liste af de operationer servicen indeholder, eksempelvis: - OpretBrugsenhed - RetBrugsenhed - SletBrugsenhed - VisBrugsenhed |
Service informationsmodel: En komplet liste af hvilke begreber fra begrebsmodellen, der anvendes i servicen, som input- og outputparametre: - BBR Sag - Brugsenhed - Bygning - Teknisk anlæg |
Service Level Agreement (SLA): Udfyldes med krav og forventninger til SLA parametre, eks: - Svartider: o liste operationer < 3 sekunder o opret/opdater operationer < 1 sekund o læs operationer < 0,5 sekund - Oppetid: o Mandag – fredag, 7.00 – 19.00: 99 % o Øvrig: 96 % - Support tilgængelighed: o Mandag – fredag, 9.00 – 15.00 |
Alle tilhørende serviceoperationer skal beskrives i følgende skabelon:
Navn: Navn på serviceoperation, eksempelvis: OpretBrugsenhed |
Formål: Forretningsmæssig beskrivelse af operations formål, eksempelvis: Opretter en Brugsenhed til- knyttet en Ejerlejlighed i Matriklen og med tilknytning af de Enheder, Bygninger og Tekniske anlæg, som Brugsenheden omfatter. |
Fil:Skabeloner Services-Hændelser 20140305.docx
Input parametre: En komplet liste af mulige input parametre, eksempelvis: - Ejerlejlighed - Enheder - Bygninger - Tekniske anlæg |
Output parametre: En komplet liste af mulige output parametre, eksempelvis: Liste indeholdende: - Brugsenhed |
Returkoder: Komplet liste over mulige returkoder, eksempelvis: - OK - Ejer findes ikke |
Præbetingelser: Beskrivelse af eventuelle forretningsmæssige forudsætninger for at operationen kan fungerer korrekt, eksempelvis have en præbetingelse, der siger at ”Enheder, Bygninger og Tekniske an- læg skal eksistere”. |
Postbetingelser: Beskrivelse af eventuelle forretningsmæssige konsekvenser af at operationen blev udført uden fejl, eksempelvis ”Ny Brugsenhed oprettet” |
Sikkerhed: En beskrivelse af hvilket sikkerhedsrolle(r) der kræves for at anvende operationen, eksempelvis: - BBR_UPDATE_LSP Sikkerhedsrollen styrer, at det kun er landinspektører med den korrekte rolle, der får mulighed for at vedligeholde Brugsenheder ud fra Ejerlejligheder. |
2. Services, andres (indgående)
Navn: Navn på serviceoperation, eksempelvis: EjerskabSoegViaEjer |
Formål: Forretningsmæssig beskrivelse af operations formål, eksempelvis: Finder de ejendomme som helt eller delvis ejes af den angivne ejer. |
Input parametre: En liste af ønskelige input parametre, eksempelvis: - Ejer Ejer er enten et CPR, eller et CVR nummer. |
Output parametre: En minimums liste af mulige output parametre, eksempelvis: Liste indeholdende: - Aktuelt ejerskab |
Returkoder: Eventuelle ønsker til returkoder, eksempelvis: - OK - Ejer ikke udfyldt med validt indhold Da operationen udstilles af Ejerfortegnelsen, kan den kun validere at inputparameteren er ud- fyldt med validt indhold, men ikke om ejeren faktisk er en eksisterende Person eller Virksom- hed. |
Præbetingelser: Beskrivelse af eventuelle forretningsmæssige forudsætninger for at operationen kan fungerer korrekt. En søge operation vil typisk ikke have præbetingelser, men en UPDATE af et BFE vil eksempelvis have en præbetingelse, der siger at ”BFE skal eksistere”. |
Postbetingelser: Beskrivelse af eventuelle forretningsmæssige konsekvenser af at operationen blev udført uden fejl. Igen er en søge operation et dårligt eksempel, da den ikke ændrer på data. Et eksempel på en postbetingelse kunne være CREATE BFE, hvor postbetingelsen så kunne være noget i stil med ”Ny BFE oprettet med et adgangspunkt” |
Sikkerhed: Kan kun udfyldes af det system, der udstiller serviceoperationen. |
Service Level Agreement (SLA): Udfyldes, hvis anvendersystemet har særlige krav til svartider, oppetid, support og lignende. |
3. Services, sammensatte
Navn: navn på egen sammensat service, eksempelvis: EjendomEjerNavnAdresse | ||||
Formål: Formålet med servicen beskrives kort, eksempelvis: Formålet med servicen er at fremsøge en specifik ejendoms ejer, samt ejers navn og adresse. | ||||
Understøttede processer: Der beskrives kort hvilke processer servicen skal understøtte, eksempelvis: Understøtter proces- sen med at fremsøge ejer og ejers adresse på en specifik ejendom i forbindelse med udsendelse af BBR-Meddelelse | ||||
Liste over operationer/metoder: Komplet liste af de operationer servicen indeholder, eksempelvis: - HentEjerNavnAdresseViaBFE | ||||
Sikkerhedshåndtering: En beskrivelse af hvordan servicen skal håndtere fejl, der skyldes at anvenderen ikke har ret- tigheder (sikkerhedsroller) til at anvende alle underliggende services. Eksempel: Anvenderen har kun READ_PUBLIC i nedenstående eksempel. - Skal servicen melde fejl, uden at returnere noget data? - Skal servicen returnere det data, anvenderen gerne må få, dvs. VirksomhedNavn og Adresse? - Hvis data returneres delvist, skal anvenderen så gøres opmærksom på de manglende rettigheder? | ||||
Kildesy- stem: | *Service og service- operation: | Informati- onsmodel, input: | Informati- onsmodel, output: | Sikkerhed: |
Navn på kildesy- stemet | Navn på kildesyste- mets service og ser- viceoperation | Input para- metre | Output pa- rametre | Angivelse af hvilke sik- kerhedsroller de forskel- lige operationer kræver. |
Ejerfor- tegnelse | EjerSoeg -> Soeg- ViaBFE | BFE | AktueltEjer- skab | EJER_READ_OWNER |
CPR | PersonSoeg -> SoegVi- aCPR | AktueltEjer- skab (CPR) | Person | CPR_READ_NAME |
CVR | VirksomhedSoeg -> SoegViaCVR | AktueltEjer- skab (CVR) | Virksomhed- Navn | READ_PUBLIC |
DAR | AdresseSoeg -> Soeg- ViaAdgangspunkt | Adgangspunkt | Adresse | READ_PUBLIC |
* De services og serviceoperationer der angives i de sammensatte services, skal eksistere i forvejen, eller være blevet kravspecificeret overfor kildesystemerne senest samtidigt med den sammensatte service.
4. Hændelser
Hændelse | |
*forretningshændelse | |
*objekttype(r) | |
Stedbestemmelse | |
sikkerhedsrolle(r) | |
Forretningsdata |
* Felter der skal udfyldes for indgående hændelser
Feltnavn | Betydning |
forretningshændelse | Den forretningshændelse som beskeden meddeler. Den kan være forretningsrettet, i den generelle betydning af for- retningshændelse, eller snævrere udtrykke en bestemt slags opda- tering af grunddata. Dette fastsættes af den ansvarlige myndighed ud fra muligheder og behov. Navn på forretningshændelse. |
objekttype | Unik identifikation af hovedobjektets type. Navn på den modelentitet der modellerer hovedobjektet. |
stedbestemmelse | Et geografisk sted (eller steder), som hændelsen vedrører. Geoobjekt evt. som ”multigeometri”. |
sikkerhedsrolle | Det sikkerhedsniveau, der kræves for adgang til hændelsen. Hvis der medsendes data i hændelsen, der kræver et særligt sik- kerhedsniveau, skal dette angives særskilt. |
Forretningsdata | Det forretningsmæssige data, der sendes sammen med hændelsen. Det vil sige data, der alternativt kan fremsøges via identifikationen fra ”objekttype”. |
For yderligere beskrivelse, se venligst ”EDA referencearkitektur ver 0.4”. Ovenstående felt ”forretningsdata”, er beskrevet som ”Private egenskaber”.