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.9.1 | Som STAR vil jeg have verificeret at optimering af databasekald der blev implementeret i release 2019-2 havde den ønskede effekt | DFDG |
| 865.9.2 | Som serviceaftager af servicemetoder, der er baseret på Foundation, ønsker jeg at kunne få tyderligere tydeligere returtyper fra skriveoperationer | DFDG, Jobnet, Vitas |
| Kriterier for tilsagn til serviceaftager i forhold til STARs snitflader | Berørte acceptkriterier | Bemærkninger |
|---|
| 865.9.1 |
|
|
|
|
|
|
|
| 865.9.2 |
|
|
|
|
|
|
|
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 |
|
Førsøg fra Jira nedenstående:
| Jira Legacy |
|---|
| server | System JIRA |
|---|
| columns | summary,varslingstype,varslingsnote,eksterne snitflader,interne snitflader,project,description |
|---|
| maximumIssues | 100 |
|---|
| jqlQuery | issuetype = Varsling AND linkedIssue in (DS-911) ORDER BY summary, Varslingstype, "Eksterne snitflader", "Interne Snitflader", Description |
|---|
| serverId | 479d1618-4a6f-3f88-8ee1-04c6b02c448a |
|---|
|
4 Beskrivelse af epic
4.1 Acc.kr. 865.9.1 - Som STAR vil jeg have verificeret at optimering af databasekald der blev implementeret i release 2019-2
I release 2019-1 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 % |
|---|
| [PersonHistory_GetBookingAppendixRelationHistoryData] | 2563689 | 4,76 | 10,90 | 22,16 |
| [Fleur].[CreateEarlyRetirementPayment] | 73677 | 89,77 | 7,80 | 21,67 |
I release 2019-3 skal der udføres verificering af at disse optimeringer havde den ønskede effekt, dette gøres ved at der efter release af 2019-2 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 % |
|---|
| [PersonHistory_GetBookingAppendixRelationHistoryData] | X | X | X | X |
| [Fleur].[CreateEarlyRetirementPayment] | X | X | X | X |
| [dbo].[KC_GetPersonGroupProject] | X | X | X | X |
Overvej for hvert acceptkriterie hvilke systemer der berøres af ændringen:
- DFDG
- Services
- WsrmMessageService (Version 10): Metoder vil blive fjernet, hvis beskederne ikke længere bliver enqueued fra koden.
- CodeListService (Version 5): Metoder vil blive fjernet, hvis ubrugte kodelister bliver udstillet her.
- WSRM'er
- WSRM' er der ikke længere bliver enqueded: Beskedtyperne fjernes.
- Kodelister
- Kodelister der ikke længere bliver benyttet: Kodelisterne fjernes i koden.
- 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
4.2 Som serviceaftager af servicemetoder, der er baseret på Foundation, ønsker jeg at kunne få tydeligere returtyper fra skriveoperationer
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
- skal der køres konvertering
- Skal der køres databasescripts for opdatering af tabeller i databasen
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, men Nuget package skal opdateres
- 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.