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 10 Next »

925.1 - Diverse DFDG og LSS fejlrettelser i 2019-1
Beskrivelse af epic af it-understøttelse af Styrelsen for Arbejdsmarked og Rekrutterings forretning

STAR Projektleder (PL)Forretningsanalytikere (FA)STAR ReleaseEpic statusEksterne snitflader
Knud de Place (STAR)

Jesper Brunholm

Ole Sørensen (Arkitekt)

2019-11.0KSS, A-Kasse, Ydelsessystem

DS-109 - Getting issue details... STATUS




Versionsnummerering

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

Afgrænsning



Som systemejer ønsker jeg at rette fejl i DFDG, så serviceaftagerne og i sidste ende sagsbehandlere i kommuner og a-kasser samt borgerne i selvbetjeningsløsninger kan anvende løsninger, der fungerer som forudsat.



Acceptkriterier



Nr.

Beskrivelse

Relevant for Beskriver hvilke af STARs leverandører som skal løse dette acceptkriterie


925.1.1

Fejl i DFDG rettes så services fungerer som oprindeligt forudsat.

DFDG, Jobnet, JobKon, JobAG, Planner, LSS


925.1.2

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

DFDG



Kriterier for tilsagn til serviceaftager i forhold til STARs snitflader

Berørte acceptkriterier








Bemærkninger



Acceptkriterie <nr.>

Acceptkriterie <nr.>

Acceptkriterie <nr.>

Acceptkriterie <nr.>

Acceptkriterie <nr.>

Acceptkriterie <nr.>

Acceptkriterie <nr.>



Serviceaftager indgår i test af de enkelte fejlrettelser i det omfang SF / DFDG-testere vurderer det relevant / nødvendigt.










Serviceaftagere forholder sig til evt. ændringer i CodeListService (hvis FB-sagerne indeholder ændringer hertil)










Der forventes ikke snitfladeændringer ved løsningen af FB-sagerne.

Hvis der mod forventning bliver behov for snitfladeændringer, vil de fremgå særskilt i varslingsdokumentet og i afsnit 3.











Oversigt over berørte web services

Snitflade

Serviceaftager der er berørt








Bemærkninger



DFDG

Jobnet

Plannersystemer

KSS

A-kasse

Ydelsessystem

JobKon

Andet




TransferDataService

X



X






Ikke snitfladeændringer

sag 126762














IllnessRecoveryInformationService

X



X


X




Ingen snitfladeændringer 

sag 93311














IllnessCompositeService

  • CreateIllness
  • UpdateIllness

X



x

x





Ny fejlkode ¤¤¤¤

Sag 131227
















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.

Forretningsobjekt

Regler for aktuel/seneste tilstand

Kontaktgruppe

En borgers seneste kontaktgruppe er kontaktgruppen med den seneste startdato (StartDate) uanset om kontaktgruppen er åben eller blevet lukket (også selv om den er lukket før dags dato)

Tilmelding

En borgers seneste tilmelding er tilmeldingen med den seneste tilmeldedato (EnrollmentDate) uanset om tilmeldingen er igangværende (borger er tilmeldt) eller blevet afmeldt (også selv om afmeldingen er sket før dags dato)

Personkategori

En borgers aktuelle personkategori er personkategorien med den seneste registreringsdato (RegistrationDate)


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.


Andre sager

Manuscript 131227 - Anmeldelsesdato for 'sygdom - sygemelding' må ikke være fremtidig

Der ønskes en validering i
  • IllnessCompositeService.CreateIllness og
  • IllnessCompositeService.UpdateIllness

så NotificationDate ikke kan være fremtidig, dvs. at NotificationDate ikke må ligge efter d.d., men skal være d.d. eller tidligere.

Formål med ændringen:

Undgå at a-kasserne modtager beskeder om "sygdom - sygemelding" (id 11), hvor anmeldelsesdatoen er fremtidig, i det sådanne sager så skal undersøges nærmere ved manuel kontakt mellem a-kasse og jobcenter.

Oversigt over sager der indgår i epic

Indsat dato
Manuscript-sag
Titel 
Område
Manuscript oprettet af
Skal eller kan kundetestes i STAR?
Snitflader til Jobnet
Snitflader til KSS
Snitflader til A-kasser
Snitflader til andre
Bemærkninger
Kandidat til release
Løst til release-tidspunkt
Varslingstask (intern DFDG)
Afsnit 3 om berørte services i epic er opdateret?
03-12-201889779Borger tilmeldt uden en kontaktgruppeTil- og afmeldingSTARx
xx
Eksisterende funktionalitet: Hvis borger er i kontaktgruppe 1,2,3,8,12,26,27 eller 28 og borgerens kontaktgruppe lukkes med en slutdato som ligger på et tidspunkt hvor borger er tilmeldt, vil DFDG returne fejlkode 4919 "The contact group can not be ended due to an active enrollment" (dette gælder både ved oprettelse og opdatering).

Denne sag løses ved at udvide denne liste så valideringen også kommer til at omfatte kontaktgrupperne 14-23.

2019-1

04-12-2018125908LBA'ere i kommuner/jobcentre kan ikke udsøge bruger på rollerAMP-Admin2 - administration af rollerSTARx





2019-1

04-12-2018130373Batchjobbet KC-TASS-MissingAppropriation fejler dagligt med tom fejlBatchjob SF






2019-1

04-12-2018130840Der skal kunne registreres "Særlig øvrige" (ID 22) på aktivitetsparate uddannelseshjælpsmodtagere i KG12Fravær og fritagelserSTARx





2019-1

05-12-2018119539IllnessCompositeService - UpdatIllness - fejl 4981WikiFOAx
xx
Det fremgår nu på wiki, at fejlkode 4981 kan kastes af UpdateIllness
2019-1

05-12-2018119106Fejlkode 5015 mangler på wiki under IllnessCompositeService.UpdateIllnessWikiSTARx
xx
Det fremgår nu på wiki, at fejlkode 5015 kan kastes af UpdateIllness
2019-1

10-12-2018127179Execution Timeout Expired ved JoblogpersonsearchJoblogServiceKMD Facilia


x


2019-1

13-12-2018131974Ensretning af logning af batchjobsDFDG logningDFDG






2019-1

14-12-2018Sygefravær modtages med fremtidige anmeldelsesdatoer

IllnessCompositeService

  • CreateIllness
  • UpdateIllness
FOAx
xx
Ny validering så ameldelsesdato ikke kan være fremtidig
2019-1

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

Id

Navn

Beskrivelse

Startdato

Slutdato













Bilag 2 – FB xxxx – Redaktionelle ændringer til xxxxx

Her vises alene et udsnit af kodelisten.

Id

Navn

Beskrivelse

Startdato

Slutdato






  • No labels