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

Dette indhold kan ikke ses af eksterne (og er ikke relevant for eksterne)

DS-2420 - Getting issue details... STATUS

1 Indholdsfortegnelse

2 Afgrænsning af epic

3 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.

4. Beskrivelse af epic

4.1 Acc.kr. 865.12.1 - Som STAR vil jeg have verificeret at optimering af databasekald der blev implementeret i release 2020-1

I release 2019-3 blev der udtrukket statistikker fra produktion af stored procedures ressourceforbrug.

I samarbejde med arkitekt blev det valgt at det var følgende stored procedure der skulle optimeres:

Ved release af 2020-3 skal der udføres verificering af at disse optimeringer havde den ønskede effekt, dette gøres ved at der efter release af 2020-1, igen udtrækkes statistikker fra produktion af stored procedures ressourceforbrug.

Nedenstående kan statistikkerne for de tre optimerede stored procedures ses:

4.2 Acc.kr. 865.12.2 - Metoden UnemploymentFundPaymentService.GetHolidayBenefitsPaymentData (by ID) udgår

Metoden UnemploymentFundPaymentService.GetHolidayBenefitsPaymentData (by ID) udgår (slettes), da den ikke har været anvendt af a-kasserne.

4.3 Acc.kr. 865.12.3 - Som STAR vil jeg gerne have at DFDG batchjob kan tåle at de afvikles med op til 3 dages forsinkelse

Som STAR vil jeg gerne have at DFDG batchjob kan tåle at de afvikles med op til 3 dages forsinkelse (i forbindelse med overgang til ny driftsplatform i efteråret 2020).

Justeringer af batchjob under NightlyBatch af hensyn til skift af driftsplatform - lukkeweekend

DS-2782 - Getting issue details... STATUS

• KC-TASS-ProcessFutureEnrollments er rettet, så det tilmelder pr. dags dato hvis tilmeldingsdatoen er dags dato eller op til 3 dage gammel og borgeren ikke er tilmeldt
• KC-TASS-CancelEnrollmentCprChange er rettet, så afmelding ifm. CPR statusskift sker selv hvis removalDate er op til 3 dage gammel.
• KC-TASS-ReenrollWhenIllnessEndsLaterThanToday rettes til at kunne tåle at sygdom er afsluttet for op til 3 dage siden
• KC-TASS-CancelEnrollmentForAbsencetypesThatCancelEnrollment rettes til at afmelde pr. dags dato for fravær, der er afsluttede for op til 3 dage siden, som ikke allerede er afsluttede.
• Performance er vurderet og taget i betragtning ved ændring af batchjobs

Justeringer af batchjob af hensyn til skift af driftsplatform - lukkeweekend

DS-2783 - Getting issue details... STATUS

•  "DFDG-TASS-MyPlanInvalidator", MyPlan.GetValidMyPlansWithExceededRemovalDate rettes så HasAbsence flaget sættes selv hvis EndDate på fravær er op til 3 dage gammelt så MinPlan ikke bliver invalideret utilsigtet.
• "DFDG-JL-SendNoNewEntryDeadlineExceededWSRM", "joblog.SearchCitizensWithEntriesNotUpdatedWithinDeadline" rettes så vi får sent en warningWsrm selv om der går flere dage uden kørsel af nightly batch
• DFDG-TASS-EducationPlanStepDeadlineExceeded er rettet til så den finder borgere hvor deadline er overskredet med op til 3 dage og hvor skiftet til Uden Ydelse ikke er sket
• Batchjobdokumentationen er opdateret centralt med at Nightly batch kan tåle ikke at køre i flere dage
• Performance er vurderet og taget i betragtning ved ændring af batchjobs

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: Nej
• Skal der køres databasescripts for opdatering af tabeller i databasen: Nej

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

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.