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

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

KSS'er og a-kasser skal implementere jobannoncer med samme muligheder som JobKon kan i dag, idet jobannoncer udfases fra JobKon. JobKon anvender i dag JobAD webservicen til indberette, vedligeholde og søge jobannoncer. JobAD er tilgængelig for eksterne aftagere, men de særlige roller, som JobKon anvender til udvidede jobannoncer , bliver ikke validerede tilstrækkeligt af JobAD til at de kan åbnes for KSS'er og a-kasser. Denne epic handler om at gøre JobAD webservicen tilstrækkelig robust til at de eksisterende roller kan anvendes af KSS'er og a-kasser.

Dette dokument beskriver migration fra JobKon til KSS'er og a-kasser:

Note: STAR (landssupporten) kan ikke længere lave visse jobannoncetyper for virksomheder, når Jobkon udfases. LSS udbygges med funktionalitet til jobannoncer for STAR (landssupporten).

980.2.1 JobAD tillader at KSS'er og a-kasse systemer kan oprette samme typer jobannoncer, som Jobkon kan i dag

Jobkons eksisterende roller i JobAD åbnes for at KSS'er og a-kasser kan anvende rollen. Det omfatter følgende roller:

1: Jobcenter

5: UnemplymentFond

Jf. /wiki/spaces/CITY/pages/77468540 (internt link).

Systemforvalter skal kunne oprette brugerkonti til hhv. KSS og a-kasser baseret på disse roller. Systemforvalter opretter i dag brugerkonti for eksterne virksomheder og det er samme proces, der skal gennemføres, blot en andre roller. JobADs sikkerhedsmodel med userid/password anvendes forsat. 

KSS og a-kasser kan allerede nu (2021-2) anvende disse roller i testmiljøerne efter aftale med SF. Snitfladen er eksisterende, men der vil blive implementeret ekstra valideringer jf. 980.2.2. Dokumentation:

JobAdService (Version 3, 2021-2)

980.2.2 JobAD validerer indhold i jobannoncer, som i dag kun kan oprettes af Jobkon

JobAD har i dag ikke komplet validering af de jobannoncetyper, som kun kan oprettes af Jobkon. JobADs validering skal udbygges, da der fremadrettet ikke er tale om en intern applikation.

980.2.3 Der er lavet dokumentation til KSS og a-kasser vedrørende udvidede muligheder for jobannoncer i forhold til øvrige systemers anvendelse af JobAD

KSS'ernes og a-kassernes muligheder dokumenteres på en underside til den generelle anvendelse af JobAD. Den generelle anvendelse af JobAD er dokumenteret her:

JobAdService

Den supplerende dokumentation skal beskrive hvordan de ekstra muligheder i JobAD for hhv. KSS'er og a-kasser kan og skal anvendes.

980.2.9 JGM's gamle database "Jobannoncer" er slettet (FB 166745)

Teknisk gæld fjernes.

980.2.10 LastModified Date i søgekriterie og resultat (ønske fra KMD)

Fra Kenneth Midtgaard ved tilsagn på epic 980.3: 

"17.02.2021: Vi benytter endnu ikke denne service. men planlægger at gøre det efter at nedestående er blevet opfyldt.

Vi har et stor behov for at SearchParameters udvides med:
LastModifiedFrom
LastModifiedTo
Og at SearchResult udvides med:
LastModifiedDate.

Begge ændringer vil minimere resourcetrækket på servicen. Pt. er man nødt til at både udsøge alt og derefter kalde de enkelte annoncer for at se om de er ændret siden man senest læste på dem."

Løsningsforslag: 

Tilføje en ny søgemetode til JobAD version 3. Dermed bliver det ikke nødvendigt at varsle en ny version af JobAD til de mange eksterne aftagere.Opdatering 2021-06-11 (Bjarne Hansen):

Denne er ikke relevant, da det under implementering blev konstateret, at funktionalitet allerede findes. De eksisterende “Created” felter ved søgning er IKKE oprettelsestidspunkt, men tidspunkt for seneste opdatering af jobannoncen. Det er en fejl i den eksisterende navngivning af felter i JobAD, som ikke kan rettes i version 3. Den misvisende navngivning skyldes formentlig, at tidspunktet for publicerede jobannoncer repræsenterer hvornår jobannoncen blev publiceret på Jobnet med det aktuelle indhold. Vi beskriver derfor dette i dokumentationen af felterne. Dvs: 

SearchParameters

SearchResult

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

• skal der køres konvertering

• Skal der køres databasescripts for opdatering af tabeller i databasen

Efter idriftsættelse:

Arkitektur- og implementeringsnoter 

Det er afklaret med STARs arkitekter, at JobAD forsætter med den nuværende sikkerhedsmodel, samt at KSS'er og a-kasser skal anvende JobADs sikkerhedsmodel ved integration, selv om den er forskellig fra STAR's sikkerhedsmodel, som KSS'er og a-kasser normalt anvender.

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.