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

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)

BI-1653 - Getting issue details... STATUS

DS-7526 - Getting issue details... STATUS

JOB-6586 - Getting issue details... STATUS

JOB-1000 - Getting issue details... STATUS  

Indholdsfortegnelse

Afgrænsning af epic

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 af tabellen.

Automatisk oversigt

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

Beskrivelse af epic

Baggrund

Denne epic er afledt at de STAR ønsker, der er til:

1. At nye stillingsbetegnelser - inkl. load fra EU - kan loades ind i ESCO STAR og vedligeholdes derfra og der får effekt rundt i hele systemet uden yderlige udviklingsopgaver
2. At forretningen (i VOA) løbende og hurtigt kan foretage ændringer, der med det samme kommer i produktion uden det udløser afledte udviklingsopgaver i STAR eller hos KSS/a-kasser
3. At der foretaget teknisk oprydning og der ikke er efterladt teknisk gæld efter DiscoAMS i de enkelte systemer.

Problemstillingen denne epic vil løse er:

• At i forbindelse med borgers automatiske find job agenter anvender de oprindelige beskæftigelsesområder (hierarki) bliver disse ikke vedligeholdt i forbindelse med ændringer i ESCO STAR
• At Find job p.t. ikke fungerer korrekt inkl. for nye ESCO STAR stillingsbetegnelser

Begge dele er, jf. Landssupporten, vigtige, at få adresseret for at:

• Undgå gentagne henvendelser fra borgere. Den type af henvendelser har tidligere givet anledning til presseomtale, da det er central funktionalitet i borgeres mulighed for at finde relevante jobannoncer
• Borgers selvbetjeningsmuligheder mht. match mellem virksomhed og borger fungerer optimalt

Problemstillingen har allerede været til stede i forbindelse med release 2021-3 og blev der løst med en række håndholdte scripts fra BI. Dette vil også være muligt i en overgangsperiode, men dels er dette udenfor STAR/VOA's kontrol i modsætning resten af ESCO STAR, dels vil det løbende medføre afledede manuelle udviklingsopgaver i STAR City ved alle ændringer til ESCO STAR. Dette er ikke hensigtsmæssigt, da ESCO STAR netop er designet således, at forretningen (VOA) kan vedligeholde uden afledede udviklingsopgaver.

Som positiv siddeeffekt vil STAR få mulighed for at koble / lave flere alternative hierarkier f.eks. en kopi af Danmarks Statistiks hierarki til analyseformål

Regler

N/A

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

Ingen. KSS og a-kasser kan forblive på version 1 af ESCOSTAR servicen.

Overordnet løsningsmodel

Problem: I dag ligger hierarkiet med beskæftigelsesområder kun i Jobnet. Denne beslutning var som konsekvens af, at de centrale funktioner omkring Find Job og Jobagenter ikke umiddelbart kunne flyttes til ESCO STAR hierarkiet fordi

• Det blev vurderet fra Jobnet, at ESCO STAR hierarkiet ikke var så brugervenligt som beskæftigelsesområder og et skift ville forringe borgerens match med virksomheder
• Det ville være en større udviklingsopgave at omlægge helt til ESCO STAR, og denne blev derfor nedprioriteret pga. af ovenstående og økonomi
• Det var en forretningsmæssig udfordring med at antal ledig jobs ikke kan summeres op igennem ESCO STAR hierarkiet uden yderlig forretningsmæssig afklaring / beslutning 

Konsekvens: Konsekvensen af denne beslutning at koblingen mellem beskæftigelsesområder og ESCO STAR ikke kan vedligeholdes og beskæftigelsesområder blev "efterladt" i Jobnet.

Løsning: 

1. Hierarkiet for beskæftigelsesområder inkl. koblingen til ESCO STAR flyttes til Taxonomy silo og Taxonomy overtage dataejerskabet inkl. at data flyttes
   Dette gøres på baggrund af at:
   1. Beskæftigelsesområder vil kunne vedligeholdes fra STAR taxonomy admin tool inkl. kobling til ESCO STAR
   2. Taxonomy silo forretningsmæssig er det sted, hvor beskæftigelsesområder bør bo
   3. Det er mest simpelt at vedligeholde datas tætte kobling til ESCO STAR, der også ejes af Taxonomy silo. Dvs. vi følger vores fremadrettede arkitekturmodel
   4. STAR får en mere fleksibel model til at lave "custom" hierarkier
   5. Beskæftigelsesområder vil være tilgængelige for andre end Jobnet - internt og eksternt
2. Taxonomy udstiller service og metode til at hente et "custom" hierarki i første omgang beskæftigelsesområder
   Dette gøres så Jobnet (og andre) kan få adgang til data. Bemærk VOA får data fra BI på normal vis
3. Jobnet hente beskæftigelsesområder fra Taxonomy og lægger den i deres egen eksisterende datastruktur 
   Dette gøres for at Jobnet data løbende bliver opdateret automatisk med ændringer til ESCO STAR, Bemærk der kan være noget teknisk gæld i Jobnet som ikke p.t. er identificeret
4. Vedligeholdelse
   1. Taxonomy udstiller service og metode til at oprette og vedligeholde "custom" hierarkier i første omgang beskæftigelsesområder 
      Dette gøres så der er adgang til at vedligeholde data
   2. Admin tool udvides med skærmbillede(r), der kan vise custom hierarkier og tilknytning til ESCO STAR stillingsbetegnelser
      Dette gøres for at så kan VOA selv vedligeholde

Løsningen er opdelt i disse 4 trin for, at STAR udviklingsmæssigt kan tage et skridt af gangen og få værdi ud af det enkelte trin. Det er dog først ved trin 4, at udviklingsopgaver i STAR City helt undgås i forbindelse med VOA's ESCO STAR vedligeholdelse.

Acc.kr. 976.26.1 Som STAR vil jeg have, at Taxonomy overtager ejerskabet af beskæftigelsesområder inkl. kobling til ESCO STAR, hot jobs

Internt STAR Acceptkriterie.

Løsningsmodel

• Der oprettes tabeller i Taxonomy til at indeholde STAR "custom" hierarkier:
  • En med stamdata om hierarkier,
  • en til selve hierarkiet og
  • en til relationen til ESCO STAR
• Data flyttes ned i tabeller (konvertering fra Jobnet tabel til Taxonomy. Der er ikke medtaget en datavask, der nok også er noget af.
• Datavask så koblingen mellem beskæftigelsesområder er opdateret (kræver input fra STAR/VOA)
• Bemærk at selve Hierarkistamdata er der ikke metoder til at oprette og opdatere. Dette gøres via scripts, da det A) forventes det vil være en sjælden operation og B) det altid alligevel vil ske i forbindelse med en release og en ny kodelisteværdi til det nye hierarki  

Tabeller (husk QA med seneste ændringsønsker fra Jobnet)

• Hierarkistamdata
  • HierarkiID
  • Type, kodeliste id med typen af hierarkiet - her "Beskæftigelsesområder", i kodelisten vil der også være en kort beskrivelse af hierarkiets anvendelse
  • Om hierarkiet må opdateres i admin tool eller kun ses (ikke nødvendig endnu)
• Hierarki
  • Id på element
  • HierarkiID (FK)
  • Titel på element
  • Parent (Null hvis top)
  • Element aktivt eller ej alternative
    • Startdato
    • Slutdato
  • Collection af labels f.eks. hot jobs
• Relation til ESCO STAR
  • Id på element (FK)
  • ConceptURIDA (FK)

Acc.kr. 976.26.2 Som STAR vil jeg have, at Taxonomy udstiller beskæftigelsesområder inkl. kobling til ESCO STAR på snitflade

Internt STAR Acceptkriterie.

Løsningsmodel

Metoder til at 

• Hente hierarki inkl. relationer

Obs Hierarki stamdata laves samtidig med kodelisten laves og det er i en release.

Taxonomy.SpecialEscoStarHierarkiService (2022-3)

Service til at hente og vedligeholde alternative hierarkier ovenpå ESCO STAR.

GetEscoStarHierarki GET /v1​/AlternativEscoStarHierarki​/hierarki​/{hierarkiType,hierarkielementId}

Henter et hierarki eller specifik hierarki element. Findes data ikke på de angivne parametre, returneres null.

Taxonomy.CodeLists

/wiki/spaces/GI/pages/3630956545

Ny kodeliste med typen af hierarki.

Acc.kr. 976.26.3 Som STAR vil jeg have, at Jobnet henter beskæftigelsesområder inkl. kobling til ESCO STAR fra Taxonomy

Internt STAR Acceptkriterie.

Løsningsmodel

Jobnet kander hent metode og ligger data i sig egen eksisterende datamodel en gang dagligt før jobagenterne kører.

Custom erhvervsområder-hieraki fra Taxonomy skal være afspejlet 1-1 i Find Job på jobnet én gang dagligt

Acc.kr. 976.26.4 Som STAR vil jeg have mulighed for, at se - og evt. vedligeholde - beskæftigelsesområder inkl. kobling til ESCO STAR fra admin tool

Løsningsmodel

Der etableres metoder til at 

• Oprettet et element inkl evt. releation til ESCO STAR
• Opdater et element inkl evt. releation til ESCO STAR

Admin toolet udvides med, at man kan 

• Vælge det hierarki man vil se (på typen)
• Få vist hierarkiet og man kan navigere i det
• Man kan rette en node inkl. 
  • Navn/beskrivelse
  • Kobling til ESCO STAR
  • Flytte til anden parent node
  • Inaktive/aktive

QA hvis der er nye data fra Jobnet vi skal have med

Obs Hierarki stamdata laves samtidig med kodelisten laves og det er i en release.

Taxonomy.SpecialEscoStarHierarkiService (2022-3)

CreateHierarkiElement (POST /v1/AlternativEscoStarHierarki​/hierarki​element)

Oprette et element i hierarkiet

UpdateHierarkiElement (PUT /v1/AlternativEscoStarHierarki​/hierarki​element/{hierarkielementelementId})

Opdatere et element i hierarkiet inkl. mulighed for at inaktiver.

Acc.kr. 976.26.5 Som STAR skal de engelske stillingsbetegnelser til WiDK med, når man flytter Erhvervsområderne, da engelske stillinger hænger på samme fysiske tabel i Jobnet. 

Internt STAR Acceptkriterie. Løses bl.a. i Custom erhvervsområder-hieraki fra Taxonomy skal være afspejlet 1-1 i Find Job på jobnet én gang dagligt

Løsningsmodel

• DFDG udvider DB model og Snitflade GetOccupations (GET /v2/EscoStar/occupations)
• BI loader engelske navne
• Jobnet henter på den alm. GetOccupations (GET /v2/EscoStar/occupations)
• Admintool kan vedligeholde engelske navne

/wiki/spaces/GI/pages/3631251457/wiki/spaces/GI/pages/3631251457/wiki/spaces/GI/pages/3631251457/wiki/spaces/GI/pages/3631251457

GetOccupation (GET /v2/EscoStar/occupations/{conceptUri}) og GetOccupations (GET /v2/EscoStar/occupations)

Ny liste (preferredLabelForeignDto) med ikke danske navne for stillingsbetegnelsen p.t. en engelske udgave.

Create preferredLabelForeign (POST /v2/EscoStar/occupation/preferredLabelForeign)

Opretter en udenlandsk label på en specifik STAR ESCO stillingsbetegnelse.

Forretningsregler:

• Det er kun muligt at lave det samme sprog en gang på en ESCO STAR stillingsbetegnelse.

UpdatepreferredLabelForeign (PUT /v2/EscoStar/occupation/preferredLabelForeign)

Opdater en udenlandsk label på en specifik STAR ESCO stillingsbetegnelse.

Forretningsregler:

• Det er kun muligt at opdatere navnet på et sprog, der eksisterer en ESCO STAR stillingsbetegnelse.

DeletepreferredLabelForeign (DELETE /v2/EscoStar/occupation/preferredLabelForeign)

Slettet en udenlandsk label på en specifik STAR ESCO stillingsbetegnelse.

Forretningsregler:

• Det er kun muligt at fjerne et sprog, der eksisterer en ESCO STAR stillingsbetegnelse.

Acc.kr. 976.26.6 Som STAR skal markering/tag omkring hot job og stilsvarende på stillingsbetegnelse, når man flytter Erhvervsområderne, da hot job hænger på samme fysiske tabel i Jobnet. 

Custom erhvervsområder-hieraki fra Taxonomy skal være afspejlet 1-1 i Find Job på jobnet én gang dagligt

Løsningsmodel

• STAR laver en ny version af Taxonomy.EscoStarService til internt brug
• Til hver stillingsbetegnelse laves en tag liste baseret på en kodeliste
• Det er muligt at oprette og slette tags, nå en tag slettes vil den kun findes i historiktabel
• Der sendes ikke WSRM på tag ændringer, da data er interne STAR data 
• Jobnet henter på den alm. GetOccupations (GET /v2/EscoStar/occupations)

/wiki/spaces/GI/pages/3631251580

Bevares uændret, a-kasse og KSS behøver ikke at foretage ændringer i forhold til deres implementering.

/wiki/spaces/GI/pages/3631251457/wiki/spaces/GI/pages/3631251457/wiki/spaces/GI/pages/3631251457/wiki/spaces/GI/pages/3631251457

Udvides med en liste af tag på stillingsbetegnelse. Disse er til  STARs interne brug. A-kasse og KSS må gerne anvende version 2, men der er intet krav herom fra STAR. 

Andre metoder end de nævnte bevares uændret.

GetOccupation (GET /v2/EscoStar/occupations/{conceptUri}) og GetOccupations (GET /v2/EscoStar/occupations)

Ny liste (tagDaDto) med tags for stillingsbetegnelsen p.t. hot job.

CreateTag (POST /v1/EscoStar/occupation/tag)

Opretter et tag på en specifik STAR ESCO stillingsbetegnelse.

Forretningsregler:

• Det er kun muligt at lave det samme tag en gang på en ESCO STAR stillingsbetegnelse.

Deletetag (DELETE /v1/EscoStar/occupation/tag)

Slettet et tag på en specifik STAR ESCO stillingsbetegnelse.

Forretningsregler:

• Det er kun muligt at fjerne et tag, der eksisterer en ESCO STAR stillingsbetegnelse.

Taxonomy.CodeLists

/wiki/spaces/GI/pages/3631251570

Ny kodeliste med tags på de enkelte stillingsbetegnelser

Bemærk disse tags anvendes p.t. internt af STAR.

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:  

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:  Ja
• Nye komponenter: Ja  
• 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:  Dette afhjælper eksisterende teknisk gæld

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

Opbevaring af oplysninger i STARs it-systemer

Dette er ikke personhenførbar oplysninger der berøres i denne epic.

Hvem må tilgå oplysningerne?

Dette oplysninger er til internt brug men der er intet der forhindre at eksterne må tilgå disse oplysninger der er alene et forretningsmæssigt valg i STAR

Korrekte sikkerhedsattributter på services

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

A-kasse filtrering

N/A

Sagsbehandlerlogin på Jobnet - tag stilling til adgang!

N/A