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

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.

Afklaring med A-kasser

• Håndtering at eksisterende krav til jobsøgning. F.eks. konvertering eller WSRM fra fra 2021-1. Det er Mark der har rejst problemstillingenDet er Mark der har rejst problemstillingen.
  • Der konverteres lokalt dvs. i DFDG og i a-kassen. Der sendes ikke WSRM 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 registrerer 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 Taxonomy.EscoStarService (2021-1).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 Taxonomy.EscoStarService (2021-1).GetDiscoAms08ConceptUriMappings (GET /v1/EscoStar/occupations/discoAms08ConceptUriMappings)

Begge konverteringer bruger dermed det samme konverteringsgrundlag i form af Taxonomy.EscoStarService (2021-1).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ætter 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ærdiggjordt.

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.

JobSearchDefinitionService (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 kun bruges i testmiljøer. Version må først bruget i produktionssammenhæng fra 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 i forbindelse med forretningsafklaringen vedr. Faggruppe og Niveau kan ske ændringer eks. at felterne udgår.

PersonStatusService (Version 20)

Internt: Det skal afklares med STAR om service udgår, hvis ikke gøres TradeForJobSearch collection tom.

Alternativt gøres objektet LatestJobSearchDefinitionInfo tomt.

WsrmMessageService (Version 10)

GetJobSearchDefinitionEventVersion1

Beholdes uændret.

Beskeden indeholder ikke stillingsbetegnelser.

CodeListService (Version 5)

GetTaxonomiOccupation

Udgår til fordel for GetOccupations.

Taxonomy.EscoStarService (Version 1)

GetOccupations (GET /v1/EscoStar/occupations)

Ny metode til at hente ESCO STAR stillingsbetengelser, 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. 

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.

>>>>>>>>

Overvej for hvert acceptkriterie hvilke systemer der berøres af ændringen:

• DFDG
  • Services
  • WSRMer
  • Kodelister
  • PersonStatusService (PSS)
  • PersonHistoryService (PHS)
  • LSS (Landssupportsystem) og herunder Registerudtræk (hvis STAR har dataejerskab og der er lavet PHS på domænet)
• Jobnet
• VITAS
• JobKon
• JobAG
• BI integrationsplatform
• Alle områder
  • Nye batchjobs
    • 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.
• Kommunalt sagsbehandlingssystem
• A-kasse sagsbehandlingssystem
• Kommunalt bookingsystem
  • JobcenterPlanner (JCP)
  • WorkForcePlanner (WFP)
• Kommunalt ydelsessystem

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.