Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning

Interne links (indhold ikke relevant for eksterne)

Indholdsfortegnelse

Afgrænsning af epic

Intern STAR kommentar: Acceptkriterie 976.11.4, 976.11.5 og 976.11.7 er på tværs af flere epic og skal løsningsmæssigt samtænkes.  

Bemærk der er ikke ændring i forbindelse med Joblog og denne del er derfor taget ud.

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. Indhold er kopieret til den manuelle oversigt ovenfor.

Beskrivelse af epic

Beskrivelse til KSS og a-kasser

Kommentar til servicesændringer

Særtilfælde vedrørende Krav til Jobsøgning og ESCO STAR

I forbindelsen med krav til jobsøgning kan der være nogle tilfælde, hvor DFDG ikke har registreret stillingsbetegnelser i krav for en borger. I et sådan tilfælde vil DFDG  i konverteringen sætte en fiktiv ESCO STAR kode "Stillingen er ikke aktiv længer, vælg en ny". Denne ESCO STAR stillingsbetegnelse er ikke aktiv og ikke knyttet til andre stillingsbetengelser eller ISCO grupper i hierarkiet. Denne specielle ESCO STAR kode vil kun blive sat af STAR, men aftageren skal kunne vise den for sagsbehandler. 

Bemærk STAR ser på navngivning og anvendes af ESCO STAR kode "Stillingen er ikke aktiv længer, vælg en ny" i forbindelse med 2021-3

976.9.1 Som STAR/A-kasse/Jobcenter vil jeg have datamodel udvidet og data konverteret fra DISCOAMS til ESCO-STAR ud fra konverteringmapning

Database inkl. konvertering omlægges efter model beskrevet under ESCO STAR datamodel og snitflade principper.

Håndtering af eksisterende krav til jobsøgning data. 

• Der konverteres lokalt dvs. i DFDG og lokalt i a-kassen (og i KSS). Der sendes ikke WSRM fra DFDG på disse konverteringer
• Der findes krav, der er registreret fra DiscoAMS niveau 1 og 2. Disse udgår og a-kassen skal derfor selv være opmærksom på, at jobkonsulenterne bliver opmærksom på de skal ind og registrere nye krav
  STAR beskriver her hvordan en DiscoAMS kode på niveau 1 og 2 kan identificeres
  

Konvertering af lokal kopi af Krav til jobsøgning hos KSS og a-kasse

I forbindelse med konvertering af data i egne fagsystemer hos KSS og a-kasser, følges den samme konverteringsmodel på alle dataområder.

Da STAR ikke har kendskab til implementering og hvorvidt der er data i de lokale fagssystemer, der behøver at blive konverteret, sker identifikationen at et sådan behov hos KSS og a-kasser selv og  konverteringen sker separat i de forskellige systemer, dog koordineret igennem STAR systemforvaltning. 

Konverteringen skal sker på følgende måde:

• I DFDG's data vha. af et internt DFDG konverteringsscript lavet af BI, der i forbindelse med releasen konverterer alle DiscoAMS stillingsbetegnelser til ESCO STAR stillingsbetegnelser. Konverteringen gælde både aktuelle data og alle historiske data. Der sendes ikke WSRM på disse konverteringer fra DFDG. DFDG's konvertering baserer sig på mapningen der fåes i /wiki/spaces/GI/pages/2352480306.GetDiscoAms08ConceptUriMappings (GET /v1/EscoStar/occupations/discoAms08ConceptUriMappings)
• I eget lokalt fagsystem hos KSS eller a-kasse sker konverteringen efter egen model og grundlaget for konverteringen fås ved hjælp af service og metoden /wiki/spaces/GI/pages/2352480306.GetDiscoAms08ConceptUriMappings (GET /v1/EscoStar/occupations/discoAms08ConceptUriMappings)

Begge konverteringer bruger dermed det samme konverteringsgrundlag i form af /wiki/spaces/GI/pages/2352480306.GetDiscoAms08ConceptUriMappings (GET /v1/EscoStar/occupations/discoAms08ConceptUriMappings), der er den autoritative kilde til mapning fra DiscoAMS til ESCO STAR. Konverteringen koordineres i forhold til produktion til at sker på release aften.

I forhold til udvikling og test er det op til KSS og a-kasse, hvornår der laves konvertering i eget test fagsystem. Dog med forudsætning om at en konvertering sker i forbindelse med at servicesversionen, der anvender ESCO STAR samtidigt tages i brug, i denne epic JobSearchDefinitionService (Version 3).

I DFDG sker konverteringen i forhold til testmiljøer i forbindelse med udviklingen af de nye versioner af servicesnitflader. Der vil derfor være testdata til rådighed på de nye serviceversioner umiddelbart i forlængelse at bliver færdiggjort.

Til inspiration for KSS og a-kasse benytte DFDG modellen "Løsningsmodel for at tilføje ESCO STAR til DFDG database model og snitflader" i forbindelse med datamodel og konvertering.

976.9.2 Som STAR og eksterne service aftager vil jeg have en ny version af JobSearchDefinitionService, der understøtter ESCO-STAR i stedet for DISCOAMS bl.a. for at jeg kan komme hurtigt i gang med min afledte udvikling

Felter i eksisterende serviceversion omlægges efter model beskrevet under:  ESCO STAR datamodel og snitflade principper.

Forretningsmæssig afklaring for alle metoder

• Det skal afklares med STAR, hvordan niveau og fagområde skal håndteres f.eks. hvilke niveauer i i ESCO STAR der må anvendes.

/wiki/spaces/GI/pages/2176680402(Version 1 og 2)

Version 1 og 2 udgår i 2021-3.

Hvis DFDG etablerer version 3 tidligere end 2021-3 (f.eks. i 2021-2) må version 3 indtil release 2021-3 kun bruges i testmiljøer. Version 3 må først bruges i produktionssammenhæng fra release 2021-3.

JobSearchDefinitionService (Version 3)

For metoderne:

• DeleteJobSearchDefinition
• GetJobSearchDefinition
• GetJobSearchDefinitions

gælder følgende:

• DiscoAMS08 felter udfases
• ConceptUriDa og AliasIdentifier indsættes 
• Fejlkode navne opdateres 
• Feltlængden for OtherExpectationsForJobSearch øges til 5000 tegn

se JobSearchDefinitionService (Version 3) 

Vær opmærksom på, at der i forbindelse med forretningsafklaringen vedr. Faggruppe og Niveau kan ske ændringer eks. at felterne udgår.

/wiki/spaces/GI/pages/2767913133

TradeForJobSearch collection gøres tom.

Alternativt gøres objektet LatestJobSearchDefinitionInfo tomt.

/wiki/spaces/GI/pages/2767683645

GetJobSearchDefinitionEventVersion1

Beholdes uændret.

Beskeden indeholder ikke stillingsbetegnelser.

/wiki/spaces/GI/pages/2767913079

GetTaxonomiOccupation

Udgår til fordel for GetOccupations.

/wiki/spaces/GI/pages/2352185416

GetOccupations (GET /v1/EscoStar/occupations)

Ny metode til at hente ESCO STAR stillingsbetegnelser, erstatter CodeListService (Version 5).GetTaxonomiOccupation

976.9.3 Som borger og STAR vil jeg have brugergrænseflader (Jobnet) understøtter ESCO-STAR i stedet for DISCOAMS

Intern STAR acceptkriterium. 
Jobnets GUI relaterede opgaver er løst i 976.14 Min plan mål, inkl udkast til Min plan, VITAS m.v.

976.9.4 Som VOA og BI vil jeg have tilpasset min dataleverance til at inkluderer ESCO-STAR

Intern STAR acceptkriterium.

Leverance til VOA tilpasses således at ESCO STAR stillingsbetegnelser medtages.

976.9.5 Som STAR vil jeg have LSS understøtter ESCO-STAR i stedet for DISCOAMS

Intern STAR acceptkriterium.

Kollektion i LSS der omhandler Krav til jobsøgning opdateres til at kalde den nye version af servicen.

NB. Oprettelse af Nyt krav til Jobsøgning vil ikke ændre serviceversion før release af 2020-2.

>>>>>>>>

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 Nej
• Skal der køres konvertering: Ja
  BI laver en konverteruing fra DiscoAMS til ESCO STAR og konverteringen følger de tidligere modeller fra 2021-2. 
• Skal der køres databasescripts for opdatering af tabeller i databasen Ja

Efter idriftsættelse:

Arkitektur- og implementeringsnoter 

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

• Nye dataområder Nej
• Nye snitflader Nej
• Nye komponenter Nej
• Nye miljøer Nej
• Nye teknologier Nej
• 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.