925.1 - Diverse DFDG og LSS fejlrettelser i 2019-1
Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning
(Skabelon af dato 09/02-2018)

Indholdsfortegnelse
1 Ændringslog
1.1 Versionsnummering
2 Afgrænsning af epic
3 Oversigt over berørte web services
4 Beskrivelse af epic
4.1 Sager relateret til DFDG flytte-batchjob (CPR-flytning)
4.1.1 Manuscript 126762 - Uønsket overlevering af PersonCategory fra fraflyttet jobcenter
4.1.2 Manuscript 128141 – Slettes det gamle jobcenters indkaldelser til samtaler, hvis jobcenter i ny kommune ændrer JC tilknytning før CPR-flytning?
4.2 DFDGs fristbatchjob
4.2.1 Manuscript 127548 - Fristbatchjob tager ikke højde for manuel ændring af JC-tilhørsforhold
4.2.2 Manuscript 122650 To WarningRegistrationWSRM'er på afmeldt borger
4.3 925.1.2 - DFDG Nightly batch skal igen køre indenfor rammen af "nattetid"
4.3.1 Løsningsmodel
4.3.2 Startimplementering på Kontaktgruppe, Tilmeldinger og Personkategori
4.3.3 Sikring af at batchjob ikke kan køre med fejlagtigt eller mangelfuldt sat flagbestand
4.3.4 Test af løsningen
4.3.5 Idriftsættelsesaktiviteter hos D&S udviklere
5 Særlige krav til test
6 Kendte udeståender fra udviklingsfasen
7 User stories
8 Bilag
8.1 Bilag 1 – FB xxxx – Redaktionelle ændringer til xxxxx
8.2 Bilag 2 – FB xxxx – Redaktionelle ændringer til xxxxx

Ændringslog

Ændringslog: Se bilag til epic 925.1 (regneark på dokumentationsarkivet – 925.1 Manuscript bilag 2019-1.

Versionsnummering

Efter sædvanlig praksis kan denne epic med Manuscript-fejlrettelser ikke være i version 1.0 til fabriksprøve eller til start på ekstern integrationstest eller kundetest, da Manuscript-sager for de patches, der følger efter 2018-4, skal indsættes i epic indtil sidste patch før 2019-1. Epic vil derfor først komme i v 1.0 tæt på 2019-1.

Afgrænsning af epic

Oversigt over berørte web services

Beskrivelse af epic

Konkrete FB-sager der kandiderer til løsning – eller som er løst til 2018-4 fremgår af bilag til epic 925.1 (regneark på dokumentationsarkivet – 925.1 Manuscript bilag 2019-1.

Sager relateret til DFDG flytte-batchjob (CPR-flytning)

Overordnet er problemet at DFDG ved modtagelse af en flyttemeddelelse fra CPRregisteret sammenligner jobcenter for den angivne nye adresse med aktuelt jobcenter i DFDG, og konstaterer at der ikke skal sættes gang i flytteflow til nyt jobcenter hvis det viser sig at borger tilsyneladende er flyttet indenfor samme kommune.
For at tage højde for at der skal laves flytteflow når nyt jobcenter har trukket borgeren til sig inden CPR flytningen, ændrer vi nu, så DFDG ved CPR-notits om flytning undersøger om der er sket et jobcenterskift til ny kommune inden for den seneste uge, og i så fald sætte flytteflow i gang.
Flytteflow er beskrevet på wiki: Borger flytter til ny kommune

Manuscript 126762 - Uønsket overlevering af PersonCategory fra fraflyttet jobcenter

Ved cpr-flytning til en ny kommunen ønskes det, at visitering nulstilles til "ikke-visiteret".
Hvis jobcenter i den nye kommune har trukket borger (ændret jobcentertilknytning til den nye kommune) skal borger kun sættes til ikke-visiteret, hvis det nye jobcenter endnu ikke har registreret en ny visitering.
Det skal gælde for kontanthjælps-, uddannelseshjælps- og integrationsydelses kontaktgrupperne.
Fraværene i nedenstående liste er ulovlige i kombination med visitationkategori (PersonCategory) Ikke Visiteret. Hvis borger har et af disse fravær vil PersonCategory derfor ikke blive nulstillet.

• 2 'MidlertidigtArbejde'
• 12 'SygdomHelbredForvaerresVedArbejde'
• 18 'FritagelseForRådighedUnderDeltagelseITilbud'
• 22 'SaerligOevrige'
• 41 'OpfoelgningUdenKontakt'
• 59 'TillaegForDanskkundskaber'

Manuscript 128141 – Slettes det gamle jobcenters indkaldelser til samtaler, hvis jobcenter i ny kommune ændrer JC tilknytning før CPR-flytning?

Ved CPR-flytning:
Aflyses det gamle jobcenters indkaldelser til samtaler, hvis jobcenter i ny kommune ændrer JC tilknytning før CPR-flytning er registreret?
Hvis ikke, så skal det gamle jobcenters indkaldelser til samtaler aflyses, når CPR-flytning til den nye kommune registreres.
Som hidtil skal henvisningssamtaler ikke aflyses ved CPR-flytning

DFDGs fristbatchjob

Manuscript 127548 - Fristbatchjob tager ikke højde for manuel ændring af JC-tilhørsforhold

DFDG må ikke lukke frister ifm borgerens CPR-flytning, når der er tale om, at jobcentertilknytningen allerede er ændret manuelt.
Det bør kun ske, hvis DFDG-batchjobbet ændrer jobcentertilknytning, eller ved lukning af en frist udstedt af borgerens tidligere jobcenter.

Manuscript 122650 To WarningRegistrationWSRM'er på afmeldt borger

Det er konstateret at der ved afmelding pga. manglende overholdelse af frist til selvbooking i Jobcenter afsendes 2 ens GetWarning WSRM'er til Jobcentret.
Løsningen bliver at fjerne den ekstra indlagte afsendelse, som er det sted i DFDG hvor der afsendes til både a-kasse og jobcenter - hvorfor a-kassens GetWarning WSRM ved afmelding pga. manglende selvbook udgår og ikke længere vil blive afsendt.
A-kassen vil fortsat modtage GetCancelUnemploymentEnrollment med afmeldeårsagen, og vil derigennem kunne identificere hændelsen.

925.1.2 - DFDG Nightly batch skal igen køre indenfor rammen af "nattetid"

Målet er, at Nightly batch er færdig med at køre inden kl 7 om morgenen 99% af alle dage udenfor releaseaktiviteter.
Manuscript-sag relateret til dette: MS-127525 - NightlyBatch - fortsat lange kørselstider efter patchrettelser

Løsningsmodel

De analyser, der er blevet foretaget i forbindelse med Manuscript 127525 har vist, at DFDGs database bruger mange kræfter og tid på at fremsøge borgeres seneste tilstande i forbindelse med afvikling af batchjob. Tilstandene, som batchjob typisk bruger kræfter og tid på at fremsøge, er borgeres aktuelle kontaktgruppe, borgeres aktuelle tilmelding, borgeres aktuelle personkategorisering samt borgeres seneste juridiske plan, hvilket i dag fremsøges på en ineffektiv måde.
For at gøre de forespørgsler (SQL queries), der skal finde borgeres seneste tilstande, langt mere effektive, skal der indføres et flag på en række tabeller. Dette flag skal angive, om data i den givne række er borgerens aktuelle tilstand, eksempelvis borgeren aktuelle/seneste kontaktgruppe. Flaget skal vedligeholdes når DFDG skriver til de enkelte tabeller og det skal sikres, at der kun eksisterer en markering for seneste tilstand for en borger i hver enkelt tabel. Samtidig skal der oprettes et index på flaget, som muliggør en hurtig og effektiv fremsøgning af den aktuelle tilstand. Alle forespørgsler, der fremsøger borgeres seneste tilstand i batchjob, ændres til at benytte de nyoprettede flag.
Dette løsningskoncept er som et eksperiment afprøvet på en række tabeller (se Manuscript 127525) og resultatet af dette eksperiment viser, at der er store forbedringer at hente ved batchjobkørsler. En forsigtig vurdering er, at det vil give en tidsforbedring på 50%.

Startimplementering på Kontaktgruppe, Tilmeldinger og Personkategori

Rammerne for denne Epic giver mulighed for at afprøve og implementere konceptet på kontaktgrupper, tilmeldinger og personkategorier. Planer og aktiviteter er ikke omfattet i denne epic, da vi p.t. har en anden stor ændring på vej på dette område, nemlig person ID. Vi vil kende de forbedringer det medfører inden vi laver yderligere tiltag. Ydermere har STAR og DFDG planer om at skille planer og aktiviteter fra hinanden, hvilket ligeledes er grund til at vente med denne epics indsats på plan-forretningsområdet.

Forretningsregler for aktuel/seneste tilstand

Nedenstående tabel viser de forretningsmæssige regler, der angiver om et forretningsobjekt indeholder en borgeres aktuelle/seneste tilstand.

Initiel populering af flag

Der oprettes et flag, som kan angive, om rækken indeholder data for en borgers seneste tilstand. Flaget oprettes og initieres på følgende tabeller:

• tblPersonStausContactGroup – flaget sættes til TRUE på borgeres seneste kontaktgruppe i forhold til reglerne, som er beskrevet i afsnit 4.3.2.1
• tblPersonStatusEnrollment – flaget sættes til TRUE på borgeres seneste tilmelding i forhold til reglerne, som er beskrevet i afsnit 4.3.2.1
• tblPersonStatusCategory – flaget sættes til TRUE på en borgeres aktuelle personkategorisering i forhold til reglerne, som er beskrevet i afsnit 4.3.2.1

Opdatering af flag i daglig drift

DFDGs kodebase tilrettes, således at de oprettede flag sættes og vedligeholdes, når:

• der oprettes nye kontaktgrupper – eventuelle eksisterende markeringer, som på flaget er sat til TRUE på borgerens kontaktgrupper fjernes og flaget sættes til TRUE på den seneste kontaktgruppe i forhold til reglerne, som er beskrevet i afsnit 4.3.2.1
• en borger tilmeldes – eventuelle eksisterende markeringer, som på flaget er sat til TRUE på borgerens tilmeldinger fjernes og flaget sættes til TRUE på den seneste tilmelding i forhold til reglerne, som er beskrevet i afsnit 4.3.2.1
• der laves nye personkategoriseringer – eventuelle eksisterede markeringer, som på flaget er sat til TRUE på borgerens personkategoriseringer fjernes og flaget sættes til TRUE på den aktuelle personkategorisering i forhold til reglerne, som er beskrevet i afsnit 4.3.2.1

Flaget på de enkelte tabeller er et internt DFDG felt og skal ikke publiceres udadtil. I de tilfælde, hvor DFDG skal fjerne en markering på en eksisterende række i en tabel, så skal oplysninger om den registerende myndighed ikke opdateres på rækken medmindre der samtidig er sket andre forretningsmæssige ændringer til denne række. Flaget skal IKKE indgå i historikken af hensyn til mulighed for fejlfinding, da det fordyrer opdateringer, og ikke giver anden viden end opdateringsdatoen, at alle rækker i historik indeholder at flaget har været true.
DFDGs kodebase skal også sikre at en borger ikke kan have to samtidige markeringer på en tabel.

Batchjobudnyttelse af flagene

Alle batchjob i DFDGs kodebase gennemgås og de forespørgsler (SQL queries), der benytter en borgers seneste tilstande i form af seneste kontaktgruppe, senest tilmelding og/eller aktuelle personkategorisering tilrettes, så de nødvendige oplysninger fremsøges ved hjælp af markeringer på de oprettede flag.
For at optimere disse forespørgsler yderligere, skal der oprettes et index på hver tabel, hvor flaget og CPR nummer indgår. Disse index kan med fordel implementeres, så de også inkluderer lidt mere information omkring borgerens tilstand, det drejer sig for de enkelte tabeller om følgende informationer:

• tblPersonStatusContactGroup – typen på kontaktgruppe (ContactGroupTypeIdentifier), startdato for kontaktgruppe (StartDate) og slutdatoen for kontaktgruppen (EndDate), da disse typisk også benyttes i forespørgslerne
• tblPersonStatusEnrollment – klientkategorien på tilmeldingen (ClientCategoryTypeId), tilmeldingsdato (EnrollmentDate) og afmeldingsdato (RemovalDate), da disse typisk også benyttes i forespørgslerne
• tblPersonStatusCategory – typen på personkategorien (PersonCategoryTypeIdentifier) og registreringsdatoen (RegistrationDate)

Sikring af at batchjob ikke kan køre med fejlagtigt eller mangelfuldt sat flagbestand

• og medføre at der må laves datagenopretning efter batchkørsel

  Test af løsningen

  
  

  Idriftsættelsesaktiviteter hos D&S udviklere

  Fagligt indlæg

  Der planlægges afholdt et faglig indlæg for udviklere i Data & Service, hvor løsningskonceptet og implementering af løsningen gennemgås. Det faglige indlæg skal tage udgangspunkt i DFDGs kodebase samt den dokumentation, som bliver skrevet på Wiki.

  Ændringer til Manuscript-sager med datagenopretninger og lignende skal fremover sætte flag

  Fremover skal de implementerede flag vedligeholdes, når Manuscript sager giver anledning til datagenopretninger. Dette princip og den arkitekturmæssige beslutning herfor beskrives på Wiki.

  Særlige krav til test

  Testscenarie	Berørte systemområder	Identificeret af

  Kendte udeståender fra udviklingsfasen

Link til søgeresultat fra FogBugz på epic-nummer:

User stories

User stories er kun til interne brug for STAR's leverandører.

Bilag

Bilag 1 – FB xxxx – Redaktionelle ændringer til xxxxx

Bilag 2 – FB xxxx – Redaktionelle ændringer til xxxxx

Her vises alene et udsnit af kodelisten.