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

VIR-1870 - Getting issue details... STATUS

DS-7480 - Getting issue details... STATUS

BI-1643 - 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):

Automatisk oversigt (vi arbejder på løsning på at gøre den synlig)

Beskrivelse af epic

Denne epic implementerer forbedringer, som reducerer kompatibilitetsproblemer mellem VITAS, KSS'er og DFDG ActivityService. På møde mellem STAR, KMD og Schultz d. 24. februar 2022 blev følgende forbedringer aftalt:

• VITAS begrænser fritekstfelter til 2.000 tegn ved oprettelse af nye sager. Eksisterende sager har uændrede feltlængder, som kan være op til 4.000 tegn (FB 232258, FB 171457 m.fl.).

• VITAS må ikke returnere NULL i ActivityStatusCauseTypeIdentifier ved nye sager. ActivityStatusCauseTypeIdentifier udbygges med nye koder, som repræsenterer, 1) at bevillingen er lukket inden den er blevet godkendt, 2) bevilling er udløbet planmæssigt (FB 220307).

• VITAS forhindrer permanent fleksjob for selvstændige (FB 217619).

Forbedringerne er et led i den løbende tilpasning af VITAS til ActivityService, så KSS'ernes opgave med at mappe fra VITAS til ActivityService forenkles. Figuren herunder illustrerer samspil mellem VITAS, KSS'er og ActivityService, samt formål med data i VITAS hhv. ActivityService.

Mange (måske de fleste?) tekster på bevillinger udarbejdes af sagsbehandlere på jobcentrene med henblik på at samme tekster kan anvendes både i dialog med virksomhed (VITAS) og i dialog med borgeren (ActivityService / Min plan). 

Ikke omfattede forbedringer

Epic'en adresserer ikke følgende sager i integrationen mellem VITAS, KSS'er og DFDG ActivityService, som fortsat er åbne:

971.30.1 ActivityStatusCauseTypeIdentifier har koder til ikke-igangsat og normalt udløb

ActivityStatusCauseTypeIdentifier har i dag fortrinsvis koder for afslutning af en bevilling af særlige årsager og disse er ikke tilstrækkelige til at repræsentere alle de tilstandsskifter, hvor VITAS sender WSRM'er til KSS. KSS ønsker altid - for de ordninger, som anvender ActivityStatusCauseTypeIdentifier - at modtage en værdi i ActivityStatusCauseTypeIdentifier og ønsker ikke at modtage NULL. ActivityStatusCauseTypeIdentifier skal derfor udbygges med nye værdier, som understøtter alle de tilstandsskifter, hvor VITAS sender WSRM'er.

VITAS har overordnet set 3 faser i en bevilling jf. nedenstående figur.

ActivityStatusCauseTypeIdentifier får følgende nye koder:

Observation til senere overvejelse sammen med KSS

VITAS bør ved evt. renovation udstille nye, eksternt rettet hændelser (ikke status) til KSS'erne fx med tilhørende eksterne tilstande:

971.30.2 VITAS fritekstfelter er begrænset til 2.000 tegn ved nyoprettelse

VITAS anvender i dag oftest feltlængder på 4.000 tegn ved fritekstfelter. Det betyder, at virksomheder og sagsbehandlere kan indtaste tekster, der ikke kan lagres i ActivityService, som har følgende maksimale feltlængder:

MyPlanService

• Core-elementet

• CauseRemark: 1-2000 tegn

• ReasonForActivity: 1-2400 tegn

• ActivityDescription: 1-2000 tegn

VITAS skal fremover kun tillade feltlængder på max. 2.000 tegn ved nyoprettelse af sager (ansøgninger, bevillinger ...). VITAS ændrer ikke på eksisterende data, som fortsat kan være op til 4.000 tegn. VITAS implementerer derfor længdebegrænsningen ved frontend validering, mens backend valideringen stadig anvender 4.000 tegn. 

KSS vil opleve, at WSRM'er og webservices er uændrede og tillader fortsat længder på op til 4.000 tegn. KSS vil opleve at WSRM'er og webservicekald ved nye sager i praksis altid har længder på max. 2.000 tegn, mens  WSRM'er og webservicekald ved ældre sager kan returnere feltlængder på op til 4.000 tegn. KSS håndterer for lange tekster i forhold til ActivityService ved ældre sager. Dette princip er aftalt med KSS på mødet 24. februar 2022.

KSS kan evt. trunkere for lange data på ældre sager og henvise til VITAS, fx "... Teksten er beskåret, men findes komplet i VITAS, som sagsbehandleren har adgang til". Borgeren har ikke adgang til VITAS.

971.30.3 VITAS tillader ikke permanent fleksjob for selvstændige

VITAS validerer at selvstændige ikke kan få permanent fleksjob, dvs. følgende kombination er ikke tilladt: FlexjobDurationIdentifierType type=2 og EmployedInOwnCompany=true

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 

Mapning til ActivityService implementeres i en særskilt komponent i VITAS således at kendskab til ActivityService ikke spredes til hele VITAS applikationen. Derved vil det også blive lettere at omlægge til eventbroker på et senere tidspunkt, når / hvis en sådan implementeres hos STAR.

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.