Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 11 Next »

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


STAR Projektleder (PL)Forretningsanalytiker (FA)STAR ReleaseEpic statusEksterne snitflader

Knud de Place (STAR)

2020-3

0.5


A-Kasse, KSS(t.o)


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

key po fa ux sme eksterne snitflader interne snitflader status labels
Loading...
Refresh

DS-2420 - Getting issue details... STATUS



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.

AcceptkriterierBeskrivelseRelevant for
Nr.

865.12.1Som STAR vil jeg have verificeret at optimering af databasekald der blev implementeret i release 2020-1 havde den ønskede effektDFDG
865.12.2

Metoden UnemploymentFundPaymentService.GetHolidayBenefitsPaymentData (by ID) udgår

DFDG
865.12.3Som 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 snitfladerBerørte acceptkriterierBemæ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 

SnitfladeServiceaftager der er berørtBemærkninger

DFDGJobnetPlannersystemerKSSA-kasseYdelsessystemJobkonJobagSFBIVitas

UnemploymentFundPaymentService (version 2)

  • GetHolidayBenefitsPaymentData (by ID)
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
Loading...
Refresh


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:

NavnAntal kaldAvg CPU msTotal 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:

NavnAntal kaldAvg CPU msTotal CPU %Total IO %
[Plan].[GetActivitiesByJobcenter]9816614,7464146,77716713,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-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

Test scenarieBerø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.





  • No labels