Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning
1 Indholdsfortegnelse
2 Afgrænsning af epic
Afgræsning | ||
---|---|---|
Som STAR vil jeg have verificeret at optimering af databasekald der blev implementeret i release 2019-2 havde den ønskede effekt for at kunne opretholde svartider og belastning på servere. | ||
Acceptkriterier | Beskrivelse | Relevant for |
Nr. | ||
865.12.1 | Som STAR vil jeg have verificeret at optimering af databasekald der blev implementeret i release 2020-1 havde den ønskede effekt | DFDG |
865.12.2 | Metoden UnemploymentFundPaymentService.GetHolidayBenefitsPaymentData (by ID) udgår | DFDG |
865.12.3 | 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) | DFDG |
Kriterier for tilsagn til serviceaftager i forhold til STARs snitflader | Berørte acceptkriterier | Bemærkninger | ||||||
---|---|---|---|---|---|---|---|---|
865.12.1 | ||||||||
A-kasser tager ikke metoden UnemploymentFundPaymentService.GetHolidayBenefitsPaymentData (by ID) i brug. da den udfases i 2020-3 | Metoden udgår. Har ikke været anvendt af a-kasserne. | |||||||
3 Oversigt over berørte webservices
Snitflade | Serviceaftager der er berørt | Bemærkninger | ||||||||||
---|---|---|---|---|---|---|---|---|---|---|---|---|
DFDG | Jobnet | Plannersystemer | KSS | A-kasse | Ydelsessystem | Jobkon | Jobag | SF | BI | Vitas | ||
UnemploymentFundPaymentService (version 2)
| X | X | Metoden udgår. Har ikke været anvendt af a-kasserne. | |||||||||
Forsøg fra Jira nedenstående (kan ikke ses eksternt):
summary | varslingstype | varslingsnote | eksterne snitflader | interne snitflader | project | description |
---|
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:
Navn | Antal kald | Avg CPU ms | Total CPU % | Total IO % |
---|---|---|---|---|
[Plan].[GetActivitiesByJobcenter] | 2043 | 1281,0435 | 6,2612 | 7,6548 |
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:
Navn | Antal kald | Avg CPU ms | Total CPU % | Total IO % |
---|---|---|---|---|
[Plan].[GetActivitiesByJobcenter] | 981661 | 4,746414 | 6,777167 | 13,133354 |
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-2782Getting 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-2783Getting 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
Test scenarie | Berørte systemområder (herunder nye batchjobs*) | Identificeret af |
---|---|---|
* 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.