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 jobmål og krav til jobsøgning kan der være nogle tilfælde, hvor DFDG ikke har registreret stillingsbetegnelser i jobmål og 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 stillingsbetegnelser eller ISCO grupper i hierarkiet. Denne specielle ESCO STAR kode vil kun blive sat af STAR, men aftageren skal kunne vise den for sagsbehandlere i Jobcentre og A-kasser.

02.07.2021

*Bemærk STAR har nu set på navngivning og anvendelse af ESCO STAR kode "Stillingen er ikke aktiv længer, vælg en ny" i forbindelse med 2021-3, og navngivningen ændres til ”Stillingsbetegnelsen er udgået”.

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*
  

*02.07.2021

I  august måned kommunikere STAR, via  nedenstående listedata, ud til jobcentre og  A-kasser (og borgere) ift. Jobmål i min plan og /Krav til jobsøgning, så de kan være proaktive ift. ændring af disse stillingsbetegnelser.

For Jobmål i Min plan

En liste over:

• Alle borger der har DiscoAMS niveau 1 og 2 koder i jobmål (goals) i seneste juridisk planversion

• Hvor planen er aktiv (dvs. borger har en åben kontaktgruppe)

For krav til jobsøgning

En liste over:

• Alle borger der har DiscoAMS niveau 1 og 2 koder i krav til jobsøgning (seneste udgave)

• Hvor krav til jobsøgning er aktive (dvs. borger har en åben kontaktgruppe)

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.

I nogle forretningsmæssige situationer anvendes DiscoAMS på niveau 1 og 2 disse er ikke repræsenteret i ESCO STAR. Disse DiscoAMS koder skal mappes til ESCO STAR stillingen "Stillingen er ikke aktiv længer, vælg en ny". Der kan anvendes følgende reglen: "hvis der for en DiscoAMS kode ikke er en mapning til en ESCO STAR kode via mapningstabellen, mappes denne til ESCO STAR dummy stillingsbetegnelsen"  Denne regel kan anvendes da der til alle lovlige DiscoAMS niveau 3 er en mapning til en ESCO STAR kode, det vil fanger alle niveau 1 og 2 samt har den sidegevinst at skulle der være hullet/fejl i data vil disse også blive håndteret.

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.

976.9.7 Visning af Krav til jobsøgning i Jobkon udgår

Da der fra jobcenter og a-kasse fagsystemer skal kunne registreres og indberettes krav til jobsøgning udgår visning på JobKon af Krav til jobsøgning (for at undgå opgradering af ny version af service for at skulle fjerne igen i 2021-4).

>>>>>>>>

979.9.8 Ændrede valideringer på eksisterende version 1 af  Jobnet.PersonAdminService.CreateOrUpdateAccount

Tilmelding på "ikke stilling"

Borger kan blive tilmeldt i Jobnet ved egen hånd på Jobnet.dk eller ved at DFDG kalder jobnet via servicesnitflader. Sidstnævnte sker når sygmeldt borger fx raskmelder sig ud i fremtiden og raskmelding (og dermed tilmelding) sker via batchjob i DFDG. Eller når eksterne systemer kalder DFDG for at få borger tilmeldt. Når det sker, så kalder DFDG Jobnet.PersonAdminService.CreateOrUpdateAccount, hvor ProfessionCollection er påkrævet med forekomst 1. Jobnet har i dag valideringer på denne snitflade som skal løsnes, da DFDG ønsker at kunne tilmelde borger på "Ikke stillingen" (svarende til ConceptUriDA http://data.star.dk/esco/occupation/2320440e-c028-48eb-8b16-a9220w04e8a5), som i taxonomy har EscoSTARstatus 3 (svarende til fravalgt). Jobnet tillader i dag kun tilmelding på stillinger der er aktive i Jobnets Taxonomy cache.   

Det skal rettes til, således at DFDG kan kalde CreateOrUpdateAccount med den inaktive "ikke stilling", altså med med ConceptUriDA http://data.star.dk/esco/occupation/2320440e-c028-48eb-8b16-a9220w04e8a5 der har escoSTARstatus 3. Det er aftalt, at dette kodes restriktivt, således at denne kode er den eneste ConceptUriDA med escoSTARstatus 3 der accepteres. Og det er kun via CreateOrUpdateAccount, at værdien kan sættes. 

På DFDG siden er aftalt, at DFDG sletter alle borgers eksisterende "Jeg søger som som" angivelser, som har andre EscoSTARstausser end 1 (svarende til aktiv), inden de kalder CreateOrUpdateAccount. Dette fordi man fra STARs side ikke ønsker at nyoprette borgere med udgåede stilligner, bortset fra i tilfældet med "ikke stillingen". Sletningen på DFDG siden har den konsekvens, at ændringerne ikke fremgår af borgers "Jeg søger job som" historik i Jobnet eller i LSS, hvor LSS aftager denne information fra Jobnet.PersonAdminService.

Ved borgers logon på Jobnet, vil borger med "ikke stillingen" sat blive mødt af den grønne notifikation om udgåede stillinger. Og de vil i "Jeg søger job som" have en rød markering om "ikke stillingen", fordi den er udgået.

Der er ingen snitflade ændringer. Valideringer rettes på eksisterende version 1.

Risici:

1. Der er ikke længere krav om, at borger skal komme på Jobnet. Så det er ikke sikkert, at borger er opmærksom på, at ved kommende ingen aktive "Jeg søger job som" har.
2. Da borger jo er tilmeldt, risikerer vedkommende vedblivende at have "ikke stillingen" knyttet på sig, og derved ikke at have aktive "Jeg søger job som registreret". Normalt konverteres de inaktive/fravalgte stillinger jo af borger selv, da vedkommende ellers ikke kan blive tilmeldt. Men det er ikke tilfældet her. Ved en evt. sygemelding og efterfølgende raskmelding (på Jobnet) vil vedkommende dog blive tvunget til at ajourføre "Jeg søger job som".

Validering på, at aliasser skal være aktive

EscoSTARprojektet indfører (allerede i 2021-2 r03) dynamik i administrationsmodulet, således at Aliasser kan opdateres og inaktiveres. Det er dog aftalt, at inaktivering først vil ske efter 21-3 er releaset, da Jobnet kode ikke er klar til at håndtere dette før da.

Konsekvensen er, at Jobnet skal lave valideringer på Aliasser på Jobnet.PersonAdminService.CreateOrUpdateAccount, således at kun aktive aliasser accepteres. Ved kald med ikke aktiv alias kastes den eksisterende fejl 25.000, der i den anledning omdøbes:

fra fejltekst "Invalid ConceptUriDa" til "The submitted request contains one or more invalid profession identifiers"

og fra beskrivelse: "The specified ConceptUriDa does not exist" til "One or more professions are invalid".

Der er ingen snitflade ændringer. Og valideringer rettes på eksisterende version 2 af Jobnet.CodeListService.

Jobnets arbejde i relation til 979.9.8 udvikles under 

976.9.9 Borgers oplevelse i jobnet ved udgået alias

Ved udgået alias, skal jobnet overfor borger fremstå, som var det en udgået stilling. Borger har intet belæg for at skelne mellem aliasser og stillinger og da stilling og alias vælges som ét, er det mest logiske for borger at opfatte den sammensatte streng - eksempelvis "Kok (fiskekok)" som en stillingsbetegnelse. For borger skal udgåede aliasser altså trigge den samme funktionalitet som udgåede stillingsbetegnelser, da konsekvensen for borger er den samme: Tilmelding kan ikke ske på et udgået alias.

Derfor skal borger, ved tilknyttet udgået alias i sin "Jeg søger job som" (dvs alias med EscoSTARstatus ulig 1) møde Jobnets notifikation på forsiden:

Og stillingen til hvilken alias er knyttet (herunder eksemplificeret med en vilkårlig stilling) skal indrammes i rødt, med opfordring til at redigere denne.

Ved tilmelding eller straksbooking på et udgået alias, skal borger på Jobnet møde følgende eksisterende fejlmelding:

Endelig skal borger proaktivt, ved raskmelding, når vedkommende har udgåede aliasser i sin "Jeg søger job som" møde følgende:

Jobnets arbejde udføre under 

Bemærk særligt i relation til dette acceptkriterie og straksbooking forholdet beskrevet under "Særlige krav til test".

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.