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

STAR Projektleder (PL)

Forretningsanalytiker (FA)

STAR Release

Epic status

Eksterne snitflader

Knud de Place (STAR)

Rolf Marcher Arndt

2019-4

0.1

Hovedspor_LAB

KSS(t.o),

A-Kasse(t.o),

Ydelsessystem(t.o),

KY/KMD-aktiv(t.o),

e-Dagpenge(t.o)

key	po	fa	ux	sme	eksterne snitflader	interne snitflader	status	labels

Loading...

Refresh

DS-911 - 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.
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å 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:

summary	varslingstype	varslingsnote	eksterne snitflader	interne snitflader	project	description

Loading...

Refresh

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-4 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

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

DFDGs brug af den eksisterende ServiceReceipt er ikke konsistent, hvilket betyder, at serviceaftagere ikke altid kan udlede hvilken MessageIdentifier, der returneres fra DFDG.

For at tydeligøre dette, implementeres de to nye returtyper CreatedResponseType og EmptyResponseType, der fremadrettet benyttes som returtyper på skriveoperationer i Webservices, der udstilles af DFDG, Jobnet og Vitas. Gældende for begge returtyper er, at EventDate udgår.

4.2.1 CreatedResponseType

Element	Type	Detaljer	Forekomst	Beskrivelse
CreatedResponse	CreatedResponseType		1	Kvittering som indeholder den unikke identifikation for den oprettede entitet
- CreatedItemIdentifier	guid Base: string	Pattern: [\da-fA-F]{8}-[\da-fA-F]{4}-[\da-fA-F]{4}-[\da-fA-F]{4}-[\da-fA-F]{12}	1	Unik identifikation for den oprettede entitet

4.2.2 EmptyResponseType

Element	Type	Detaljer	Forekomst	Beskrivelse
EmptyResponse	EmptyResponseType		1	Tom kvittering

Der ændres ikke på eksisterende servicesnitfalder, da de to returtyper benyttes fremadrettet.

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.

865.9 Teknisk Gæld 2019-4