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

2024-4 IKKE MVP

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

2025-1

Forudsætning for for at nyt Jobnet i Jobsearch kan lave deres implementering af af jobagenter, gemte søgninger og gemte annoncer

Later / teknisk gæld

Denne er den tekniske gælde er der i forbindelse med XCV søgningen er lagt i Jobsearch domænet men det skal bo i Match

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