Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning
...
Page Properties | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
...
Versionshistorik af betydning for eksterne (v0.1, v0.3, v0.5 og v1.0)
Anvendes ved ændringer, der har betydning for eksterne.
Dato | Version | Hvem | Hvad er ændret? |
---|---|---|---|
14.10.2022 | 0.1 | Carsten Olsen | Oprettelse |
...
Afgrænsning | |||||||||||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
Som serviceaftager og STAR vil jeg have løftet servicesnifladerne for opdatering og læsning af information om jobcentre/subjobcentre til REST som en del af STAR's moderniseringsprogram for at sikre at DFDG lever op til STARs principper omkring en moderne og vedligeholdelsesvenlig IT-portefølje samt udfaser end of life teknologi. | |||||||||||||||||||
Acceptkriterier | |||||||||||||||||||
Nr. | Beskrivelse | Relevant for | US | ||||||||||||||||
1005.17.11.1 | Som STAR vil jeg have flyttet forretningsområdet med stamoplysninger on jobcentre/subjobcentre til forretningsdomænet (silo) Borgerkommunikation inkl. at det lever op til de principper, der er fastsat | DFDG, BI |
| ||||||||||||||||
1005.17.11.2 | Som serviceaftager og STAR vil jeg have udstillet opdatering og læsning af stamoplysninger om jobcentre/subjobcentre via ny REST snitflade med samme forretningslogik og operationer som den eksisterende SOAP service (JobcenterService) | DFDG, Jobnet, Vitas |
| ||||||||||||||||
1005.17.11.3 | Som serviceaftager vil jeg gerne beholde den eksisterende SOAP service JobcenterService uændret i en overgangsperiode for at sikre en fleksibel overgang til ny snitflade | DFDG, Jobnet, Vitas | |||||||||||||||||
1005.17.11.4 | Som STAR vil jeg have dataleverancer i forhold til VOA tilpasset til det nye forretningsdomæne (silo) | BI | |||||||||||||||||
1005.17.11.5 | Som STAR vil jeg have at dokumentation for såvel servicelag og frontend lever op til STAR's principper på releasetidspunktet | DFDG, Jobnet | |||||||||||||||||
|
|
| |||||||||||||||||
|
|
| |||||||||||||||||
| /wiki/spaces/GI/pages/3690397697 |
| |||||||||||||||||
1005.17.11 .9 | XXXXX modtager XXXXX ved håndtering af XXXXXEvent. | DFDG | |||||||||||||||||
1005.17.11.11 | Død kode i DFDG, i forbindelse med opdatering og læsning af jobcenter/subjobcenter stamdata, fjernes | DFDG | |||||||||||||||||
1005.17.11.12 | Landssupport/LSS er skiftet over til at brug den nye REST-servicen til læsning og opdatering af jobcenter/subjobcenter oplysninger , i stedet for JobcenterService fra DFDG classic | DFDG |
...
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.
(kopiér og indsæt manuelt i tabellen)
Summary | Varslingstype | Varslingsnote | Eksterne Snitflader | Interne Snitflader | Project |
---|
Automatisk oversigt
Ikke synlig for eksterne, men indeholder ikke andre oplysninger end kopieret til den manuelle oversigt ovenfor.
Jira Legacy | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Rigtige link indsættes
Beskrivelse af epic
Baggrund
Her udfylder PO oplysninger om baggrund for epic'en, herunder fx om der ligger politisk aftale eller lovgivning bag. Særligt vigtigt, at dette fremgår, hvis det ikke fremgår i en overliggende ISB, hvortil der evt. kan henvises.
Som en del af DFDG's udfasning af end of life teknologier og STAR's moderniseringsprogram sker der i forhold til forsørgelseshistorik følgende:
I DFDG et skift til REST snitflade - og i denne epic uden samtidige forretningsmæssige ændringer
I Jobnet en overgang til ny REST snitflade samt ny frontend arkitektur (denne opgave er ikke en del af denne epic, men vil blive specificeret i en efterfølgende epic)
Regler
Her udfylder PO oplysninger om eksisterende eller forventede regler om registrering og indberetning.
Det er ingen indberetningsregler i denne epic, da der alene er tale om GET metoder.
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.
Acc.kr. 1005.17.X.1 - Som STAR vil jeg have flytte forretningsområde XXXXX til forretningsdomænet (silo) XXXXX inkl. at det lever op til de principper der er fastsat
Løsningsmodel (internt STAR acc.kr.)
Etablering af database i XXXXX
Acc.kr. 1005.17.X.2 - Som serviceaftager og STAR vil jeg have udstillet XXXXX via ny REST snitflade med samme forretningslogik og operationer som den eksisterende service
Løsningsmodel
Ny REST service og getmetode i XXXXX
Fejlkoder bevares
Der ændres ikke i adgangsforhold til service/metoder
/wiki/spaces/FYS/pages/3919904801
Ny REST service til udstillings af XXXXX .
XXXXX.XXXXX
...
Ny | Ny metode på REST service til at hente liste med (sub)jobcentre | A-kasse, KSS, Plannersystemer | N/A | D+S | |
Borgerkommunikation.JobcenterService.GetJobcenterOplysninger | Ny | Ny metode på REST service til at læse oplysninger om adresse, åbningstider og telefontider på (sub)jobcentre | A-kasse, KSS, Plannersystemer | N/A | D+S |
Borgerkommunikation.JobcenterService.UpdateJobcenterOplysninger | Ny | Ny metode på REST service til at opdatere adresse, åbningstider og telefontider på (sub)jobcentre | KSS | N/A | D+S |
Udgået | SOAP-service / metode udgår i 2023-4. Brug i stedet ny REST-service. | A-kasse, KSS, Plannersystemer | N/A | D+S | |
Udgået | SOAP-service / metode udgår i 2023-4. Brug i stedet ny REST-service. | A-kasse, KSS, Plannersystemer | N/A | D+S | |
Udgået | SOAP-service / metode udgår i 2023-4. Brug i stedet ny REST-service. | KSS | N/A | D+S | |
WsrmMessageService (version 11).GetJobcenterContactInfoVersion1 | Andet | WSRM dannes som hidtil (indtil den afholdes af en moderne Webhooks besked) | KSS | N/A | D+S |
Automatisk oversigt
Ikke synlig for eksterne, men indeholder ikke andre oplysninger end kopieret til den manuelle oversigt ovenfor.
Jira Legacy | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|
|
Rigtige link indsættes
Beskrivelse af epic
Baggrund
Her udfylder PO oplysninger om baggrund for epic'en, herunder fx om der ligger politisk aftale eller lovgivning bag. Særligt vigtigt, at dette fremgår, hvis det ikke fremgår i en overliggende ISB, hvortil der evt. kan henvises.
Som en del af DFDG's udfasning af end of life teknologier og STAR's moderniseringsprogram sker der i forhold til opdatering og læsning af stamoplysninger om jobcentre/subjobcentre følgende:
I DFDG et skift til REST snitflade - og i denne epic uden samtidige forretningsmæssige ændringer
Regler
Her udfylder PO oplysninger om eksisterende eller forventede regler om registrering og indberetning.
Det er ingen indberetningsregler i denne epic, men da jobcentrets adresse, telefonnumre, åbningstider og telefontider udstilles på selvbetjeningsløsninger baseret på de registrerede oplysninger har jobcentrene en væsentlig forretningsmæssig interesse i selv at kunne opdatere oplysningerne.
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 2023-4) 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.
Acc.kr. 1005.17.11.1 - Som STAR vil jeg have flytte forretningsområde opdatering og læsning af stamoplysninger om jobcentre/subjobcentre til forretningsdomænet (silo) Borgerkommunikation inkl. at det lever op til de principper der er fastsat
Løsningsmodel (internt STAR acc.kr.)
Etablering af database i Borgerkommunikation
Acc.kr. 1005.17.11.2 - Som serviceaftager og STAR vil jeg have udstillet metoder til opdatering og læsning af stamoplysninger om jobcentre/subjobcentre via ny REST snitflade med samme forretningslogik og operationer som den eksisterende service
Løsningsmodel
Ny REST service og Update- og Get-metoder i Borgerkommunikation.JobcenterService
Fejlkoder bevares
Der ændres ikke i adgangsforhold til service/metoder
Som hidtil vil DFDG (nu BK) ved opdatering af navn og adresse på det forretningsmæssige hovedjobcenter (xxx01) automatisk opdatere det tekniske hovedjobcenter (xxx00) tilsvarende (da det tekniske hovedjobcenter ikke hidtil har kunnet opdateres ved servicekald)
/wiki/spaces/FYS/pages/3919904801
Ny REST service til opdatering og udstilling af (sub)jobcentrets navn, jobcentrets adresse, telefonnumre, åbningstider og telefontider.
Denne metode benyttes til at gemme ændringer til (sub)jobcenterets adresse, kontaktoplysninger, åbningstider og/eller telefontider.
Opdateres oplysninger for et forretningsmæssigt hoved-subjobcenter (id ender på 01) opdateres også oplysningerne på det tekniske hovedjobcenter (id ender på 00) eksklusiv jobcenter navnet.
Denne metode benyttes til at hente (sub)jobcenterets adresse, kontaktoplysninger, åbningstider, telefontider og introduktionsafsnit, som kan medsendes til eksempelvis dagpengemodtagere.
Denne metode returnerer en liste indeholdende alle jobcentre, med oplysninger om det enkelte jobcenter. Dog kun jobcentre hvor der også er registreret adresseoplysninger.
Acc.kr. 1005.17.11.3 - Som serviceaftager vil jeg gerne beholde den eksisterende SOAP service uændret i en overgangsperiode for at sikre en fleksible overgang til nye snitflade
Løsningsmodel
Eksisterende SOAP-service JobcenterService bevares som kalder mod ny getmetode 1 til 1 internt i DFDG i en overgangsperiode frem til og med 2023-4.
JobcenterService (version 5).UpdateJobcenterInformation <--> Borgerkommunikation.UpdateJobcenterOplysninger
JobcenterService (version 5).GetobcenterInformation <--> Borgerkommunikation.GetJobcenterOplysninger
JobcenterService (version 5).GetJobcenterList <--> Borgerkommunikation.GetJobcenterListe
Acc.kr. 1005.17.
...
11.
...
4 - Som
...
STAR vil jeg
...
Løsningsmodel
Eksisterende SOAP bevares som kalder mod ny getmetode 1 til 1 internt i DFDG i en overgangsperiode frem til og med 2023-4.
XXXXX.XXXXX LINK
...
have dataleverancer i forhold til VOA tilpasset til nye forretningsdomæne (silo)
Løsningsmodel (internt STAR acc.kr.)
Initial load af data / konvertering fra DFDG (Classic) til Borgerkommunikation
Tilpasning af dataleverance fra DFDG/BK til VOA via BI (hvis VOA får disse stamdoplysninger)
Acc.kr. 1005.17.
...
11.
...
5 - Som STAR vil jeg have
...
at dokumentation for såvel servicelag og frontend lever op til STAR's principper på releasetidspunktet
Løsningsmodel (internt STAR acc.kr.)
Initial load af data / Tilpasning af BI load til XXXXX domænet (silo)
Data kommer fra VOAQA af regler fra kode mod dokumenteret regler og fejlkode
Ajourfører dokumentation
Sider der skal rettes og QA er (liste er ikke udtømmende)
Servicesnitflade
Acc.kr. 1005.17.
...
11.
...
6 - Som STAR vil jeg have
...
data er omfattet af dataløft og pseudonymisering mod testmiljøer
Løsningsmodel (internt STAR acc.kr.)
QA Tilpasning af regler fra kode mod dokumenteret regler og fejlkode
Ajourfører dokumentation
Sider der skal rettes og QA er (liste er ikke udtømmende)
Servicesnitflade af for pseudonymisering og aftale hvornår data skal med i dataløft
Systemforvalter til retter pseudonymiseringsflow
Acc.kr. 1005.17.1.9 XXXXX modtager persondata ved håndtering af BorgerstamdataOpdateretEvent.
Løsningsmodel (internt STAR acc.kr.)
XXXXX modtager persondata via ny event receiver
Acc.kr. 1005.17.
...
1.10 Død kode i DFDG, i forbindelse med stamdata om (sub)jobcentre, fjernes
Løsningsmodel (internt STAR acc.kr.)
Tilpasning Fjernelse af regler af for anonymisering og aftale hvornår data skal med i dataløft
Systemforvalter til retter anonymiseringsflow
Acc.kr. 1005.17.X.7 Ydelsesudstilling udstiller kodelisterne ForsoergelseshistorikKategoriCodeList og ForsoergelseshistorikomraadeCodeList i Ydelsesudstilling.CodeListService
Løsningsmodel
DFDG udstille kodelister for XXXXX
XXXXX.XXXXX LINK
...
gammel og død kode i DFDG classic
Acc.kr. 1005.17.1.
...
/wiki/spaces/GI/pages/3690397697
GetVariablePersonStatus
Udstiller ikke mere XXXXX. I stedet returneres en tom liste
Acc.kr. 1005.17.1.9 XXXXX modtager persondata ved håndtering af BorgerstamdataOpdateretEvent.
Løsningsmodel (internt STAR acc.kr.)
XXXXX modtager persondata via ny event receiver
Acc.kr. 1005.17.1.10 Død kode i DFDG, i forbindelse med forsørgelseshistorik, fjernes
Løsningsmodel (internt STAR acc.kr.)
Fjernelse af gammel og død kode i DFDG classic
Acc.kr. 1005.17.1.11 Landssupport/LSS er skiftet over til at bruge den nye REST-servicen i XXXXX, i stedet for XXXXX
Løsningsmodel (internt STAR acc.kr.)
Landssupport/LSS er skiftet til at brug XXXXX ved brug af nyt ClientApi fra XXXXX.
Kode brugt i forbindelse med XXXXX er fjernet fra LSS
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
...
Test scenarie
...
Berørte systemområder (herunder nye batchjobs*)
...
11 Landssupport/LSS er skiftet over til at bruge den nye REST-servicen i Borgerkommunikation, i stedet for JobcenterService
Løsningsmodel (internt STAR acc.kr.)
Landssupport/LSS er skiftet til at brug Borgerkommunikation.JobcenterService ved brug af nyt ClientApi fra Borgerkommunikation til læsning og opdatering af stamdata om (sub)jobcentre
Kode brugt i forbindelse med SOAP-servicen JobcenterService er fjernet fra LSS
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
Test scenarie | Berørte systemområder (herunder nye batchjobs*) | Identificeret af |
---|---|---|
Converter er brugbar ved opdatering af jobcenter stamdata |
| Knud |
WSRM / webservicebesked afsendes til jobcentre ved opdatering af stamdata på (sub)jobcenter - og til alle JC hvis navn på (sub)jobcenter ændres | WsrmMessageService (version 11).GetJobcenterContactInfoVersion1 | Knud |
Ved opdatering af subjobcenter xxx01 (forretningsmæssigt hovedjobcenter) sker automatisk tilsvarende opdatering af det tekniske hovedjobcenter (xxx00) | Knud |
* 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
...
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:
...
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 )
Alle borgere | Egne borgere | Tidligere egne borgere | Gæsteadgang | Anden Aktør - egne borgere | Anden Aktør - gæsteadgang | |
---|---|---|---|---|---|---|
A-kasse | X | |||||
JobCenter | X | X | ||||
Kommune | X | |||||
STAR | X | |||||
AUB | ||||||
UDK | ||||||
STIL |
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
...