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)

BVL-5660 - Getting issue details... STATUS

PLAN-4868 - Getting issue details... STATUS

PLAN-4879 - Getting issue details... STATUS

PLAN-4886 - Getting issue details... STATUS

PLAN-4938 - Getting issue details... STATUS

BI-4980 - 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 i tabellen.

(kopiér og indsæt manuelt i tabellen)

Automatisk oversigt

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

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.

Regler

Her udfylder PO oplysninger om eksisterende eller forventede regler om registrering og indberetning.

Denne epic dækker find job både som service og som front end på Jobnet. I forholde servicedelen der er ikke nye regler. For Frontend se Figmafiler (*kun tilgængelig internt i STAR).

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.

Ingen påvirkning, i dag har eksterne ikke til at anvende søgning på jobannoncer.

Løsningsmodeller

Disse løsningsmodeller omhandler ikke STAR arbejde omkring Ankiro generelt og denns flytning til SIT. Er der konsekvenser fra dette arbejde er disse pt ikke indetificeret og med derfor heller ikke medtage, ej heller sammenfald i tidsplaner. Denne epic skal alene sikre:

1. Jobnet classic Find job kan forsætte uændret eller med de ændringer der ligger i de her beskrevne løsningsmodeller i tilfælde af at STAR vælger at gå med en eller flere af disse

2. Jobannoncer skal med release 2024-4 indekseres til Ankiro fra den nye jobannoncer model der også går i luften fra 2024-4

3. Evt. flytning af data fra Jobnet Classic sker

4. Ny REST service til det nye Jobnets Find job inkl. Jobagenter, gemte søgninger og annoncer i løbet af 2024-4 så Jobsøgningsteamet kan lave forntend

5. Selv Find job på det nye Jobnet (disse opgave er pt kun i Jira)

De 2 to-be løsningsalternativer - Batchjob eller Eventreciver i Match domæne

Temporær løsningsmodel med levetidsforlængelse af eksisterende Jobnet classic batch job

Overordnet og seneste løsningsmodel inkl. releases

2024-4 MVP

Denne del er en forudsætning for at JogAD og JogAG kan releases i 2024-4.

Del 1 - Tilpasning af Ankiro

Forudsætning for del 2 kan afsluttes og del 3 påbegyndes

1. Jobsøgning: Tilpasning af Ankiro med nye og ændret attributter inkl GUID som nøgle, både til Jobnet claasic og WIDK

   1. Forudsætning: Fra virksomhed info om ændringer der påvirker Ankiro

   2. Afklar også hvordan Alias kan/skal håndteres

Del 2 - Data fra nyt jobAnnoncer univers til Match domæne

1. Plan: Event til Jobannoncer fuldt indhold

   1. Forudsætning QA fra Virksomhed

   2. Afklaring: Skal der et flag med om det er en gensend i forhold til fuld synkronisering

2. Plan: Eventrecievers på de data fra andre domæner der skal beriges med

   1. /wiki/spaces/ISB/pages/4223008855

3. Virksomhed og Plan: Eventpublicher på Jobannonceevents,

   1. Impl. i Virksomhed måske lidt eventviden fra Plan

4. Plan: Event reciever i Match der gemmer nødvendige data

   1. Afklaring: Nødvendige data for Ankiroindekseringer

5. Plan: Event reciever i Match feeder Ankiro både til Jobnet classic og WIDK in

   1. Forudsætning Del 1 er lavet

6. BI: Datamonitor på Jobannoncer mellem Virksomhed og Match domæner

   1. Afklaring: BI er ikke klar over de har noget på denne opgave

7. Snitflade i Match til at kunne toggle fjerne fra automatch og fjen ekstern annonce

   1. Plan: Snitflade i Match til at kunne toggle fjerne fra automatch1

   2. Plan: Snitflade i Match til at kunne toggle fjerne fra automatch

   3. a og b er forudsætning for virksomhed og JGM

Del 3 - Tilpas Jobnet classic til ny Ankirosøgning lavet i del 1 (kun meget overordnet beskrevet da Jobsøgning allerede er igang med at lave US)

1. Jobsøgning: Tilpas Jobnet classic find job funktionalitet som den anvender den opdateret SOAP Ankiro service

   1. Forudsætning: Del 1 for implementering og Del 2 for test, måske også en færdiggørelse af udvilking pga der skal være data.

2. Jobsøgning: Tilpas Jobnet classic til at kalde de nye restservice

3. Jobsøgning: Sikre at gemte søgninger og Jobagenter forsat virker (dette antager pt. vil virke)

4. Jobsøgning: Gemte annoncer oprydning

   1. Afklaring: Gemte annoncer vil ikke virke da de jo ikke konverteres, hvad skal ske med disse i Jobnet

Del 4 - “Batch” crawler til eksterne jobannonver

1. Plan - Etabler job der kalder jobannonce crawler fra CareLink og feeder Ankiro både til Jobnet claasic og WIDK

   1. Afklaring omkring hvordan crawler virker i Jobnet classic, hjælp fra Jobsøgning

Del 5 - Luk for Jobnet classic batchjob til Ankiro indeksering (gl. feeder)

1. Jobsøgning: Stop for Jobnet classic batchjob til Ankiro indeksering (gl. feeder)

   1. Forudsætning: Del 1 og måske Del 2 og Del 4

   2. Afklaring: skal gl. kode helt eller delvis fjernes eller er det nok vi stopper batchjob (Bare MVP)

Del 6 - Ankiro konfiguration

1. Plan/Jobsørning: Flyt og tilpas fra Jobnet classic til Match

   1. Afklaring: Hvilket team laver denne opgave

   2. Afklaring: Hvad ligger præcis i opgaven

   3. Afkalring: er denne del MVP til 2024-4

Del 7 - tværgående test / SystemIntegrationstest 2024-4

1. Plan/Jobsørning:

   1. Afklaring: Hvilket team laver denne opgave

   2. Afklaring: Hvad ligger præcis i opgaven

2024-4 IKKE MVP

Denne del er en forudsætning for at nyt Jobnet i Jobsearch kan lave deres implementering af Find job

Del 8 - Ny REST snitflade på Match

1. Plan: Ny REST snitflade på Match

   1. Forudsætning Del 1 er færdig

2025-1 evt. senere hvis dette aftales med Jobsøgnin / PO

Del 9 - Nyt Jobnet frontend for Find Job

1. Jobsøgning: Etablering af den nye frontend på nyt Jobnet

   1. Forudsætning: Del 8 er færdig

Del 10 - Service til gemte jobagenter og gemte søgninger

1. Plan: Servicesnitflader til gemte jobagenter og gemte søgninger

   1. Afklaring: At nyt løsningsdesign er klart

Del 11 - Service til gemte jobannoncer

1. Plan: Servicesnitflader til gemte jobannoncer

Del 12 - Frontend for gemte jobagenter, gemte søgninger og gemte jobannoncer

1. Forudsætning er Del 9 og 10 for at nyt Jobnet i Jobsøgning kan lave deres implementering af af jobagenter, gemte søgninger og gemte annoncer

2. Jobsøgning: Frontend opret gemte jobagenter og gemte søgninger

3. Jobsøgning: Frontend opret gemte jobagenter og gemte søgninger

Del 13 - Metoder til email verifikation og slette jobagenter

1. Plan: Servicesnitflader til email verifikation og slette jobagenter

Del 14 - Frontend for verificer email på jobagenter og slet jobagent

1. Jobsøgning: Side på jobnet som der kan linkes til fra email på at verficerer en email adresse, inkl kald til servicemetode

   1. Forudsætning del 13

Del 15 - Udsendelse af jobagent mails

1. Plan: Lave email skabeloner i DYT inkl link fra nyt jobnet

   1. Forudsætning der er link fra nyt Jobnet etableret

2. Plan: Dan og send mail til borger for verficering når jobagent oprette

   1. Test whitelist

3. Plan: Lav Batchjob til at fortage jobagebtsøgninger og send mail med resultat

Later / teknisk gæld (beskrives ikke ydeliger pt)

Denne er den tekniske gæld der er bl.a. i forbindelse med

• CV søgningen er lagt i Jobsearch domænet men det skal bo i Match

• Generelt udestående er automatch og hvad der skal ske

  • Simpel model er at danne en jobagent på baggrund af borgers “Jeg søger job som“

Acceptkriterier til DFDG / backend omkring jobannoncesøgning i Ankiro.

Acc 1005.18.21.1 Som STAR (Nyt Jobnet) vil jeg have en REST service til at foretage Find job søgninger mod de moderniseret Jobannoncer

Løsningsmodel

1. For søgning m.v. i nyt Jobnet og Jobnet classic

   1. Der etableres ny REST service til søgning mod jobannoncer. Match domænet
      Service kalder vidrer 1 til 1 mod Ankiro SOAP service til jobannoncesøgning

   2. Der etableres ny REST service til søgning til Jobagenter, Gemt jobannoncer og gemt søgning Match domænet

   3. Jobnet classic anvender forsat Ankiro SOAP service til jobannoncesøgning.

Match.JobannoncesoegeService

Service til at søge i Jobannoncer.

PerformFritekstsoegning (POST /v1/CvSoege/action/fritekstsoegning)

Fritekstsoegning (GET /v1/CvSoege/fritekstsoegning)

Acc 1005.18.21.2 Som STAR (Jobnet classic) vil jeg beholde den nuværende SAOP service fra Ankiro, dog sådan at Find job søgningen sker mod de moderniseret Jobannoncer

Løsningsmodel

1. Jobnet classic forsætter med at anvender Ankiros SOAP service uændret

2. Forudsætning vi ikke laver om i indholdet af den eksisterende Ankiro indtil Jobnet classic er udfaset

Vi skal lige verificerer at aliase ikke pt er med, dette er antagelsen men det kan ses i indeksringsbatchjob

Udenstående er hvordan STAR ønske om anvendelse af alias på stillingsbetegnelser skal håndteres

1. Model Nul: Ingen aliaser medtages pt => ingen ændringer til snitflade, ankiro eller indeksering

2. Model CV: Alias medtages sammen med stillingsbetegnelser og der vil kunne søgs på disse efter samme principper som stilllingsbetegnelser => Mindre tilpasning af indekseringsjob, Løsning vil også virke ud af boksen på Jobnet classic

3. Model Specifik alias søg: Der skal søges på alias seperat fra andre søgeparametre =>

   1. Data skal være tilsted på jobannoncer

   2. Ændringer til selve Ankiro søgemodel, der udvides med ekstra søgefelter

   3. Indekseringer af Ankiro skal udvides

   4. Jobnet classic skal tilpasses til ny SOAP søge service fra Anriko

Acc 1005.18.21.3 Som STAR (Nyt Jobnet) vil jeg have en REST service til gemme jobaggenter, Jobannoncer og jobannoncesøgninger

Løsningsmodel

1. Ny servicemetode til at administrere borger Jobagenter

2. Ny servicemetode til at gemme borgeres jobannonce søgninger

3. Ny servicemetode til at gemme borgers udvalgte jobannoncer

4. For konvertering ag eksisterende dat se 1005.18.21.5

Match.BorgersjobagentService (Version 1, 2024-4) [UDV]

Service til borger (Jobnet) der opretter og vedligeholder borgers jobagenter og gemte søgninger på Jobnet

GetJobagent (GET /v1/Jobagent)

GetJobagenter (GET /v1/Jobagent)

GetJobagenterPaaEmail (GET /v1/Jobagent)

CreateJobagent (POST /v1/Jobagent){}

UpdateJobagent (PUT /v1/Jobagent){Jobagentindtifier}/VerificereEmail

UpdateJobagent (PUT /v1/UpdateJobagent{Jobagentindtifier})

DeleteJobagent (DELETE /v1/UpdateJobagent{})

Match.GemtJobannoncesoegningService

Service til at gemme og slette borgeres fortrukning søgninger på jobannoncer.

Match.GemtJobannonceService

Service til at gemme borgeres fortrukning jobannoncer.

Eksisterende funktionalitet i Jobnet classic

Bibeholdes uændret og udfases når Jobnet classic udfases. Bemærk der er ingen kobling mellem data gemt på Jobnet classic og det nye jobnet, da eksisterende data alende findes i Jobnet classic.

Acc 1005.18.21.4 Som STAR vil jeg have omlagt batchjobbet til en ny indeksering af jobannoncer til Ankiro fra den moderniseret Jobannoncemodel

Løsningsmodel (3 modeller i spil)

1. Model 1: Indeksering af Ankiro model Batchjob i Match domæne

   1. Logikken (forretning og design) fra eksisterende batchjob i Jobnet classic genbruges i hovedtræk

   2. Data der ikke fås fra annoncerne, skal der beriges med, inkl. evt. kodelister og event

   3. Forudsætninger: Batchjob skal være klar til produktion med 2024-4

   4. Fordele: Passer bedre med fremtidig arkitektur men har statig en lidt for tæt kolding til Virksomhed

   5. Ulemper: Kan være blivende løsning men eventmodel er mere i tråd med ny arkitektur, Dårlig mulighed for totalreindeksering af Ankiro

2. Model 2: Indeksering af Ankiro model eventbroker via Match domæne

   1. Der skal rejses skal rejse event på Jobannoncer + event skal laves fra Virksomhedsdomænet

   2. Forretningslogik logikken fra eksisterende batchjob i Jobnet classic indtænkes i eventreciever i match

   3. Data der ikke fås fra annoncerne, skal der beriges med, inkl. evt. kodelister og event

   4. Forudsætninger: Eventpublicher og reciever plus logik skal være klar til produktion med 2024-4

   5. Fordele: Passer 100% med fremtidig arkitektur, Bedre mulighed for at lave total reindeksering af Ankiro

   6. Ulemper: Team Virksomhed eller Plan skal lave event og rejse denne og det er ikke i planen pt.

3. Model 3: Indeksering af Ankiro temp model via tilpasning af eksisterende batchjob i Jobnet classic

   1. Forudsætninger: Eventpublicher og reciever plus logik skal være klar til produktion med 2024-4

   2. Fordele: Passer 100% med fremtidig arkitektur, Bedre mulighed for at lave total reindeksering af Ankiro

   3. Ulemper: Ren temporær løsning der skal leve en release eller to, skal senes lave som model 1 eller 2 når Jobnet classic lukker, Timer skal lægges af teanm Jobsearch og den er ikke meget billigere i forhold til model 1 og 2, dvs det ikke bare et hurtigt fiks da vi bl.a. ingen eksperter har på dette område.

4. Afklaringer

   1. Er der behov for at etablere en mulighed for at lave en fyld reindeksering af jobannoncer i Ankiro?? Dette kan ske med CV’er pt.

Konklusion på modelvalg

Udestår!!!!

Det skal afklares med STAR, Jobsearch, Virksomhed og Plan hvilken model vi går med. Dvs enten en ren model 1 eller 2 og om vi skal have en temporær model 3 i spil (det sidste er det virksomhed pt har lagt op til pga. ressourcer)

CO: Forløbing tilbagemelding er at der er generel concept om model 2 er den bedste arkitekturmæssigt

Acc 1005.18.21.5 Som STAR vil jeg have flyttte borgers Jobagenter og gemte søgninger

Løsningsmodel

• Det er ikke mulig at flytte gemte jobannoncer fra lagt ind af virksomheder fra JobAg, da disse slettes vil overgangen til nyt jobannonce model fra virksomhed

  • Hvad med andre gemte annoncer skal de flyttes?

• Skal borgers Jobagenter flyttes fra Jobnet classic???

• Skal gemte søgninger flyttes fra Jobnet classic???

Acc 1005.18.21.6 Som STAR vil jeg have omlagt afsendelse af email fra jobagenet inkl. whitlistning på testmiljøer

Løsningsmodel

• Det skal afklares om der er en mulighed for at sende nå der kommer en ny annonce, forudsætte events på jobannoncer

Acceptkriterier til ny Jobnet frontend for Find job

Acc.kr. 1005.18.22.7 - Det skal sikres, der senere kan benyttes strukturerede kompetencedata i JSJS, automatch og Find Job

Det skal sikres, der senere kan benyttes strukturerede kompetencedata fra JSJS, i automatch-profilen og på Find Job-siden. ESCO-STAR har pt stillingsbetegnelser (occupations), men mangler færdigheder (skills) og kvalifikationer (qualifications). For at inkludere færdigheder og kvalifikationer skal det dels implementeres på Jobnet under JSJS, dels skal de ekstra felter indgå i DFDG jobwish (JobSearch), dels skal disse felter tages med i Søgemotorens automatch søgeprofil, og dels skal det være muligt at bruge de strukturerede data på Find Job siden. MOD-6452 - Getting issue details... STATUS

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

• DFDG

  • Services

  • WSRMer

  • Kodelister

  • PersonStatusService (PSS) / domænespecifikke statusservices

  • PersonHistoryService (PHS) / domænespecifikke historik services

  • LSS (Landssupportsystem) og herunder Registerudtræk (hvis STAR har dataejerskab og der er lavet PHS på domænet)

• Jobnet

• VITAS

• JobKon

• JobAG

• JobSearch

• Ydelsesudstilling

• Taxonomy

• 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

  • WorkForcePlanner (WFP)

  • M4 Booking

  • Schultz Booking

• Kommunalt ydelsessystem (KY)

• Kommunalt sygedagpengesystem (KSD)

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:  

• Nye snitflader:  

• Nye komponenter:  

• Nye miljøer:  

• Nye teknologier:  

• Nye aftagertyper:  

• Eller afvigelser fra principperne:  

• Eventuelle behov for reduktion af teknisk gæld skal afdækkes:  

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

Illustrationer, skærmdumps m.v. må ikke indeholde cpr.nr., CV. nr., rigtige personnavne på borgere eller deres kontaktoplysninger i form af e-mail, telefonnr., adresse m.v.

•  Ja, det er tjekket, at epic ikke indeholder dette.

• Angiv hvem der har foretaget dette tjek: 

• Angiv dato for tjek: 

Opbevaring af oplysninger i STARs it-systemer

Ved oprettelse af nye dataområder skal der tages stilling til, hvornår formålet med data ophører og dermed fastlægges en slettepolitik.

Ved indførelse af nye data på eksisterende dataområder skal GDPR slettejobs opdateres.

Hvem må tilgå oplysningerne?

Afsnittet må ikke blot slettes, hvis det vurderes ikke relevant. Det skal dokumenteres at man har forhold sig til nedenstående.

Husk det er hensynet til borgeren der tæller højst. Der skal være hjemmel til at sagsbehandler må tilgå oplysninger. Formålet skal være som led i administrationen af beskæftigelsesreglerne eller ydelsesadministration.  

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 )

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

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