Denne epic er anden del af etablering af webservicebeskeder for del et se 1005.20.1 Webservicebeskeder (Tidl. WSRM) - STAR infrastruktur til afsendelse og modtagelse - Intern STAR @2023-2 for del tre se 1005.20.3 Webservicebeskeder (Tidl. WSRM) - Drift af på udvalgte afsendelser og modtagelser med serviceaftager @2023-4

Versionshistorik af betydning for eksterne (v0.1, v0.3, v0.5 og v1.0)

Anvendes ved ændringer, der har betydning for eksterne.

Interne links (indhold i links ikke relevant for eksterne)

https://starwiki.atlassian.net/browse/MOD-2509 Samle og krav epic.

https://starwiki.atlassian.net/browse/MOD-7416 Implementerings epic

https://starwiki.atlassian.net/browse/DS-14977 

Husk BI epic

Indholdsfortegnelse

Afgrænsning af epic

Pakke EXBESKED-1 i DFDG moderniserings og forretnings roadmap for serviceaftagere

Oversigt over berørte webservices 

Manuel oversigt som er synlig for eksterne

Links i listen virker kun med STAR Jira konto og kan derfor ikke tilgås af eksterne. Links under Summary indeholder ikke andre oplysninger relevant for eksterne end hvad der fremgår i tabellen.

Automatisk oversigt

Ikke synlig for eksterne, men indeholder ikke andre oplysninger end kopieret til den manuelle oversigt ovenfor.

Beskrivelse af epic

Baggrund

Som en del af DFDG's udfasning af end of life teknologier og STAR's moderniseringsprogram sker der i forhold til afsendelse af webservicebeskeder, som på sigt erstatter WSRM beskeder følgende:

• Etablering og test af infrastruktur til afsendelse og modtagelse af webservicebeskeder
  Release 2023-1 - Epic 1005.20.1 Webservicebeskeder (Tidl. WSRM) - STAR infrastruktur til afsendelse og modtagelse - Intern STAR @2023-2

• Pilotimplementering hos serviceaftager af ny webservicebesked model således model serviceaftager kan modtage og behandle webservicebeskeder inkl. abonnementsmodel
  Release 2023-2 - Denne epic

• Release 2023-3 - Epic https://starwiki.atlassian.net/wiki/spaces/ISB/pages/3978723382/1005.20.3+Webservicebeskeder+Tidl.+WSRM+-+Drift+af+p+udvalgte+afsendelser+og+modtagelser+med+serviceaftager+2023-4

Regler

Det er ingen indberetningsregler i denne epic, da der alene er tale om afsendelse af webservicebeskeder.

Forventet påvirkning af jobcenter-, a-kasse- eller ydelsessystemer

Her beskriver PO overordnet, hvordan epic'en forventes at påvirke aftagerne. Særligt vigtigt, at dette fremgår, hvis det ikke fremgår i en overliggende ISB, hvortil der evt. kan henvises.

Serviceaftager skal overgå til ny REST snitflade, men kan i en overgangsperiode (indtil 202X-X) forblive på eksisterende SOAP service således, at serviceaftager mere frit kan tilrettelægge deres IT udvikling.

Perioden kan dog ændres, hvis der efterfølgende kommer forretningsændringer til servicen. En sådan efterfølgende ændring af perioden, vil fremgå i epic med de nye forretningsændringer.

1005.20.2.1 - Som STAR vil jeg have etableret udvalgte webservicebeskeder til forretningsområdet Webservicebeskeder i forretningsdomænet (silo) Eksternkommunikation inkl. at det lever op til de principper, der er fastsat

Løsningsmodel

• Færdiggørelse/justering af database der indeholder de webservicebeskeder, der skal afsendes og er blevet afsendt efter input fra eksterne og erfaringer fra 2023-2

• Færdigimplementer model for hvordan er domæner skal rejse et event, der skal udløst en webservicebesked

• Etableres eventreciever det modtager event og gemmer data til afsendelse til de med de eksterne aftalte webservicebeskeder for pilot

• Færdiggørelse/justering af push funktionalitet

• Tilpas evt. ændringer til skemavalidering af beskeden

1005.20.2.2 - Som STAR vil jeg have sat de udvalgte webservicebeskeder og modtagere op i DFDG's model for styring af afsendelse af webservicebeskeder til forretningsområdet Webservicebeskeder i forretningsdomænet (silo) Eksternkommunikation inkl. at datamodellen er fuldt implementeret til at dække alle krav (Dvs bygger videre på det der blev etableret i 2023-2

Løsningsmodel

• Færdiggørelse/justering abonnement/styringsdatabase i Eksternkommunikation, der indeholder de abonnement/styringsdata der bestemmer webservicebesked afsendelsen (evt. kun de relevante data for vi kan udfører denne epic)

• Sæt abonnementdata op for de ekstern aftager der er med i pilot 

  • STAR kan gøre det

  • Serviceaftage kan gøre det via snitflader

• Der etableres/justeres push funktionalitet se også 1005.20.1.1 så man kan push i forhold til abonnement hos serviceaftageren 

Overordnet beskrivelse af løsningmodel: Beskrivelse af Webservicebeskeder.

EksternKommunikation.AbonnementService (2023-3)

GetBeskedtyper (GET /v1/beskedtype)

Denne metode henter alle beskedtyper

CreateAbonnement (POST /v1/abonnement)

Denne metode anvendes til at oprette et abonnement for en given beskedtype.

UpdateAbonnement (PUT /v1/abonnement/{abonnementIdentifier})

Denne metode anvendes til at opdatere et eksisterende abonnement.

GetAbonnementer (GET /v1/abonnement)

Denne metode anvendes til at hente en liste over eksisterende abonnementer

Anvend overstående link på EksternKommunikation.AbonnementService (2023-3) for beskrivelse og forretningsregle samt fejlkode.

EksternKommunikation.AbonnementService (2023-3)

Interne STAR metoder

CreateBeskedtype (POST /v1/beskedtype)

Denne metode opretter en beskedtype til webservicebesked. Beskedtypen er en forudsætning for det kan laves regler og abonnement.

UpdateBeskedtype(PUT /v1/beskedtype/{beskedtypeId})

Denne metode opdater en beskedtype til webservicebesked.

1005.20.2.3 - Som STAR vil jeg have at eksterne serviceaftager etablerer et/flere endpoints, hvor STAR kan sende webservicebeskeder udstillet fra forretningsdomænet (silo) Eksternkommunikation til

Løsningsmodel

• Der etableres en række serviceaftager endpoint i samarbejde med de eksterne sytemere som detalger i pilot

• Der etableres den nødvindige sikkerhed (certifikater) se også 1005.20.2.8 

• Der skal sættes et abonnement plus en test-tilslutningsaftale op til endpoints

Tjekliste: Tjekliste for eksterne ifht. webservicebeskeder

Eksempel på generisk besked metadata: Noter til webservicebeskeder#Metadata-eksempel

Se beskrivelse af beskeden her: Noter til webservicebeskeder#Teknisk-indhold

Se beskrivelse af blokkeringsregler her: Noter til webservicebeskeder#Genfremsendelsespolitik-for-fejlende-webservicebeskeder

1005.20.2.4 - Som STAR vil jeg have implementeret tværgående test (Cross Domain Test), der via det tværgående testrammeværk tester at besked kan modtage og verificere de given Webservicebesked.

(Internt STAR accept kriterium)

Vi bygger videre på testen fra 2023-2

Løsningsmodel (internt STAR acc.kr.)

• Udvidelse til tværgående test (Cross Domain Test) så den omfatter de nye webservicebeskeder

Kodeliste med WSB beskedtype id [UDV]

Indeholder navn og id på WSB og i relation til tværgående test (Cross Domain Test) der vil CV (Id 30000) være tilgængelig i 2023-3 test og blive anvendt som den første. Det er muligt at DFDG sent i 2023-3 vil have flere WSB tilgængelig i 2023-3 afhængig af fremdrift i DFDG udviklingsspor hen over sommerferie og frem til 2023-3 lukker. Hvilke der er tale om vil fremgå af de relevante epic f.eks 1005.17.5.Krav til jobsøgning og 1005.20.4 Nuph.

1005.20.2.5 - Som STAR vil jeg have at webservicebeskeder løsningen er robust og understøtter genfremsendelse af fejlet webservicebeskeder

Løsningsmodel 

• Færdiggørelse/justering model som kontrollerer, at webhooket returnerer http status kode 2xx. Hvis ikke gensendes beskeden med en konfigurerbar vente-algoritme.

• Genafsendelse skal aldrig stoppe

• Serviceaftager kan modtage og stoppe aftagelsen og genoptage / behandle fejlede beskeder 

Noter til webservicebeskeder#Reliability

1005.20.2.6 - Som STAR vil jeg have at webservicebeskeder løsningen er robust og understøtter fremsendelse af allerede fremsendte on demand fra aftager

Løsningsmodel

• Der etableres/færdiggøres en servicesnitflade hvor man for en given person kan får gensendt allerede afsendte webservicebeskerer for en given periode (max 6 md tilbage)

• Serviceaftager integrere og afprøver snitfalde

Se detaljer om genfremsendelse her: Noter til webservicebeskeder#Genfremsendelsespolitik-for-fejlende-webservicebeskeder

EksternKommunikation.WebservicebeskedService

GetBeskeder (GET /v1/beskedtyper {XXX filter})

Denne metode læser afsendte webservicebeskeder.

GensendWebservicebeskeder (PUT /v1/Webservicebesked/action/Gensend)

Denne metode giver serviceaftager mulighed for at genudsende webservicebeskerder for en given borger eller beskedtype hvis beskeder ikke er koblet til en borger.

Anvend overstående link på EksternKommunikation.BeskedService (2023-3) for beskrivelse og forretningsregle samt fejlkode.

1005.20.2.7 - Som STAR vil jeg have at webservicebeskeder løsningen understøtter logning

(Internt STAR accept kriterium)

Løsningsmodel (internt STAR acc.kr.)

• Der etableres/færdiggøres logning af alle pushbeskeder inkl. at de er modtaget (behandler) af aftager

• Hver genafsendelse skal logges

• Logningen skal i denne iteration ske via star.foundations log4net da EksternKommunikation hostes hos Kyndryl
  Der ligges en plan for overgang til SIT)

1005.20.2.8 - Som STAR vil jeg have at DFDG udstiller et klient cerifikat som bruges ved afsendelse

Løsningsmodel

• Serviceaftager skal kunne håndterer sikkerheden (opsætning af certifikat og MTLS)

Tjekliste: Tjekliste for eksterne ifht. webservicebeskeder

Obs: Omkring fornyelse af certifikat er dette en en del af denne pilot men vil blive adresseret i forbindelse med 2023-4

1005.20.2.9 - Som STAR vil jeg have at eksisterende WSRM afsendelse er uforandret.

Løsningsmodel

• Da dette er en pilot på at etablere den nye webservicebesked løsning sammen med serviceaftagerne berøres de eksisterende WSRM beskeder ikke. Dette emne håndteres i senere epic

WsrmMessageService (Version 10) og WsrmMessageService (Version 11, 2023-1)

Berøres ikke og kan anvendes uændret.

1005.20.2.10 - Som STAR vil jeg have at dokumentation for denne enabler lever op til STAR's principper på releasetidspunktet

(Internt STAR accept kriterium)

Vi bygger videre på impl. fra 2023-2

Løsningsmodel (internt STAR acc.kr.)

• Wiki er opdateret og afspejler løsningen

• Dokumentationen skal skrives så der skal omskrives så lidt som muligt når den endelige løsning er etableret

1005.20.2.11 - Som STAR vil jeg have, at data er omfattet af dataløft og annonysering mod testmiljøer 

(Internt STAR accept kriterium)

Vi bygger videre på impl. fra 2023-2

Løsningsmodel (internt STAR acc.kr.)

• Data i eksternekommunikation vedr. webservicebeskeder skal slettes ved dataløft dog ikke abonnementer

1005.20.2.12 - Landssupport/LSS får en ny side der brug den nye REST-servicen i til at hente webservicebeskeder, i stedt forWsrmMessageValidationService (2021-1) fra DFDG classic

(Internt STAR accept kriterium)

Løsningsmodel (internt STAR acc.kr.)

• Der laves en snitflade til at hente webservicebeskeder på en borger svarende til WsrmMessageValidationService (2021-1)

• Parallelt med den eksisterende WSRN side på LSS etableres en tilsvarende side der vise data fra webservicebeskeder

1005.20.2.13 - Udstiller kodelisterne for Eksternkommunikation webservicebeskeder

Løsningsmodel (internt STAR acc.kr.)

• Følgende kodeliste er tiltænkt

  • Stasus for afsendelse (ikke sendt endnu, blokeret, kvitteret, fejlet)

  • Ændringstype i forhold til pushbesked (webservicebeskeder (CRUD)

  • Identifokationstype i forhold til besked (Cpr-nr, virksomhed, Esco STAR, VITAS m.f.) 

  • Systemer (eksisternede DFDG kodeliste)

  • Myndigheder (eksisternede DFDG kodeliste)

  • Evt. flere

• Bemærk "Beskedertype" er ikke en traditionel kodeliste med skal til gås via Get metode

Fysiske kodelister vil snarest blevet beskevet 

1005.20.2.14  Der skal implementeres en model f.eks. i LSS, hvor man kan søge på beskeder ud fra CPR, aftager og tidsperiode

(Internt STAR accept kriterium)

Løsningsmodel (internt STAR acc.kr.)

• Der laves en snitflade til at hente webservicebeskeder på en borger i en periode 

• Side på LSS etableres vise data fra webservicebeskeder periodemæssigt og aftagermæssigt

1005.20.2.15 - Etabler servicesnitflader til at sætte abonnement/styringsdata op til afsendelse der kan bruges af SF og serviceaftager

Løsningsmodel

• Der laves en snitflade til at hente og gemme abonnement/styringsdata til serviceaftager og SF. 

• SF skal også kunne sætte abonnementsregler op.

• Det etableres UI til SF

EksternKommunikation.AbonnementService (2023-3)

GetBeskedtyper (GET /v1/beskedtype)

Denne metode henter alle beskedtyper

CreateBeskedtype (POST /v1/beskedtype)

Denne metode opretter en beskedtype til webservicebesked. Beskedtypen er en forudsætning for det kan laves regler og abonnement.

UpdateBeskedtype(PUT /v1/beskedtype/{beskedtypeId})

Denne metode opdater en beskedtype til webservicebesked.

1005.20.2.16 - Etabler webløsning  til at SF kan administrere regler/stategier

(Internt STAR accept kriterium)

Løsningsmodel

• Konkret afgrænsning for hvad SF kan/skal administrer dette

• Model for flytning af opsatte regler og abonnementer mellem miljøer 

• Det etableres UI til SF

1005.20.2.17 - Der skal laves en model for håndtering af sameksistens mellem WSRM og webservicebesked løsningerne

Løsningsmodel 

• Der impl. en model på hvordan sameksistens understøttes mellem WSRM og webservicebeskeder og denne dokumenteres på wiki

Transitionsmodel: Transitionsplan for webservicebeskeder

1005.20.2.18 - Der skal laves en model for hvordan afsendersilo sender til Eksternkommunikation via eventbroker

Løsningsmodel (internt STAR acc.kr.)

• Der impl. en model på hvordan kommunikationen fra en afsende silo via eventbroker til Eksternkommunikation skal ske og denne dokumenteres på wiki

1005.20.2.19 - Star Foundation kodelisten ClientSystemTypeIdentifier udvides med id 61, 62 og 63

Kodelisterne med ClientSystemTypeIdentifier udvides med id 61, 62 og 63 af hensyn til styring af WSB-abonnementer (idet alle aftagere af WSB'er skal findes i kodelisten):

Tjekliste modernisering DFDG:

• DFDG

  • Services 

    • Er pakken af service snittet jf. behov i DFDG, Jobnet, eksterne m.f.

    • Er der behov for at bevare SOAP snitfladen

    • Er dansk navngivning QA'et

    • Er der teknisk gæld eller andet der skal rettes op på (evt. spike til team/arkitekt for at identificerer)

  • Konvertering

    • Initielt load / konvertering og i hvilke siloer

  • WSRM'er
    
    

    • Skal eksisterende WSRM udsendes og hvor længe

    • Skal ny besked etableres nu eller senere

  • Kodelister, er disse flyttet til ejende domæne, er der lavet slavekodelister

  • Eventbroker

    • Er nye beskeder der skal etableres, QA af indehold og navngivning

    • Er det dokumenteret hvilke beskeder, der anvendes, og hvilke forretningsregler der er i den forbindelse

  • StatusService

    • Udfasning i PersonStatusService (PSS) 

    • Udvidelser til domænespecifikke statusservices

    • Udfasning i PersonHistoryService (PHS)

    • Udvidelse til domænespecifikke historik services

  • LSS (Landssupportsystem) og/eller Datakanon og herunder Registerudtræk (hvis STAR har dataejerskab)

  • Datamonitor. ny eller ændret overvågninger

  • Dokumentation

    • QA i forhold til at alle forretningsregler / fejlkode er tilstede

    • Dokumentation følger nye principper

• Nye batchjobs / ændret behandling af events

  • Dokumentation af jobbet til SF (jf. skabelon: xxx link til skabelon) 

• Dataløft

  • Hvis der i Databaser tilføjes eller fjernes kolonner med personfølsomme data (f.eks. person navne, adresser, email, telefonumre etc.), så skal SF informeres så disse data fremadrettet tilføjes eller fjernes fra scrambling.

• Ændringer i forhold til aflevering at Rigsarkivet

• GDPR sletninger m.v.

• Interne afhængigheder indenitfiseret (Jobnet, VITAS, JobAG, BI integrationsplatform andre domæner m.v.)

• Eksterne afhængigheder indenitfiseret (Kommunalt sagsbehandlingssystem, A-kasse sagsbehandlingssystem, Kommunalt bookingsystem (WorkForcePlanner (WFP), M4 Booking, Schultz Booking). Kommunalt ydelsessystem (KY), Kommunalt sygedagpengesystem (KSD), EG kommune informatiom m.fl.)

Særlige krav til test

* Batchjobs

• bør testes både med delta og fuldt load,

• bør hvis der er afhængigheder køres med normalt load fra BI i ét testmiljø i hele testperioden

• bør testes i samarbejde med teams som har afhængigheder

• kørselstid, særligt hvis det er en del af NightlyBatch

Konsekvenser for drift/idriftsættelse

I forbindelse med idriftsættelse:

• Skal der køres et fuldt dataload ved første kørsel af et batchjob - aftal med SF hvornår load skal køres:  

• Skal der køres konvertering:  

• Skal der køres databasescripts for opdatering af tabeller i databasen:  

BI foretager initial load af forsørgelseshistorik i ydelsesudstilling silo. Der er ikke tale om konvertering i denne forbindelse da det er samme loadmodel som i den gamle forsørgelseshistorik på DFDG classic.

Efter idriftsættelse:

N/A

Arkitektur- og implementeringsnoter 

Her beskriver PO/FA om arkitekturen og teknikken bag løsningen, om der f.eks. anvendes:

• Nye dataområder: Nej, flytning til domæne Ydelsesudstilling 

• Nye snitflader: Nej, flytning til domæne Ydelsesudstilling

• Nye komponenter: Nej 

• Nye miljøer: Nej 

• Nye teknologier: Modernisering 

• Nye aftagertyper: Nej 

• Eller afvigelser fra principperne: Nej 

• Eventuelle behov for reduktion af teknisk gæld skal afdækkes: N/A 

Der gives en beskrivelse af hvorledes disse tænkes håndteret/implementeret i løsningen og om dette har været vendt med STAR arkitekten.

Husk GDPR stillingtagen

Ingen personfølsomme data i epics

Illustrationer, skærmdumps m.v. må ikke indeholde cpr.nr., CV. nr., rigtige personnavne på borgere eller deres kontaktoplysninger i form af e-mail, telefonnr., adresse m.v.

• Angiv hvem der har foretaget dette tjek: 

• Angiv dato for tjek: 

Opbevaring af oplysninger i STARs it-systemer

Ved oprettelse af nye dataområder skal der tages stilling til, hvornår formålet med data ophører og dermed fastlægges en slettepolitik.

Ved indførelse af nye data på eksisterende dataområder skal GDPR slettejobs opdateres.

Dette er ikke et nyt dataområde blot en flytning fra DFDG classic og til XXXXX. 

Hvem må tilgå oplysningerne?

Afsnittet må ikke blot slettes, hvis det vurderes ikke relevant. Det skal dokumenteres at man har forhold sig til nedenstående.

Husk det er hensynet til borgeren der tæller højst. Der skal være hjemmel til at sagsbehandler må tilgå oplysninger. Formålet skal være som led i administrationen af beskæftigelsesreglerne eller ydelsesadministration.  

Korrekte sikkerhedsattributter på services

PO skal for hver enkelt servicemetode angive hvilke myndighedstyper, der må kalde de forskellige servicemetoder.

Tilladte organisationer (eksempel - se den fulde liste over myndighedstyper på siden DFDGs sikkerhedsmodel )

A-kasse filtrering

Hvis a-kassen må anvende metoden, må a-kassen så se / hente alle data? Eller skal der foretages filtrering ift. at a-kassen fx kun må se nogle udfaldsrum / kodelisteværdier? Husk at filtreringen skal ramme eventuel visning på Jobnet aht. sagsbehandlerlogin

XXXXX

Sagsbehandlerlogin på Jobnet - tag stilling til adgang!

En sagsbehandler i et jobcenter kan tilgå en borger tilknyttet det konkrete jobcenter.

En sagsbehandler i en a-kasse kan tilgå en borger, som er medlem af a-kassen og KG 1 (tilmeldt og ikke-tilmeldt) eller KG 8 og tilmeldekategori 5 - dimittend.

Begrænsninger kan foretages via (a-kasse-) filtrering, eller ved at afgrænse på action niveau på konkrete sider på Jobnet.

Stillingtagen: Beskriv kort, at der er taget stilling til sagsbehandlerlogin

XXXXX