Vi er i gang med at samle afvikling af alle batchjobs i STAR City under Stonebranch:

Som STAR ønsker jeg at konsolidere, ensrette og samle alle batchjobs for STAR's IT portefølje under en platform: Stonebranch, således at batchjobs bliver nemmere at vedligeholde, afvikle og ikke mindst overvåge.

Forudsætninger for implementereing af et batchjob i Stonebranch

Følgende forudsætninger skal være på plads inden implementering i Stonebranch foretages.

Release

• Nye batchjobs bør kun releases med Major Release.

Server

• STAR City Stonebranch batchjobs afvikles på 1 af de tre batchservere, der alle har en Stonebranch agent kørende. I produktion: starjobapp2AA (Jobnet), starfdgapp2AA (DFDG), starvitweb2AC (Vitas)

Fejl og logning

• Jobbet skal returnere en fejlkode, hvis det fejler, og ellers med en ok-kode - Windows exit koder er beskrevet her. Vi arbejder pt. med disse situationer, som skal have de angivne exit koder:

  • Success = Ingen fejl logget - Exit kode 0

  • Fejl, flere subscenarier - Exit kode 100-300:

    • Fejl ved opstart: Ingen exit kode, da StoneBranch selv håndterer dette.

    • Delvis succes - Exit kode 100 (Eksempel: 1 ud af 10 databehandlinger fejler)

    • Alt fejler - Exit kode 200 (Eksempel: 10 ud af 10 databehandlinger fejler)

• Fejl skal logges på Standard Error, så Stonebranch kan samle fejlinformation op i Output fanen

• Jobbet skal logge enten via STAR Foundation eller i Windows Eventlog. Dette for at loggen kan opsamles og lagres via KMD værktøjet Logpoint

• Jobbet kan rapportere til BatchLogService, så kørsler kan overvåges i LSS

  • Se også https://starwiki.atlassian.net/wiki/spaces/CITY/pages/25460933

• Hvis jobbet fejler skal det i loggen fremgå:

  • Hvad fejlen består i?

  • Hvilke borgere der er påvirket af fejlen - såfremt der er borgere, der er påvirket (f.eks. hvis der skal datagenoprettes på den pågældende borger)?

Genkørsel

• Jobbet skal kunne genkøres

• Hvis batch jobbet er forhindret i at køre i sin normale periodisering pga. eksempelvis nedbrud, skal batch jobbet være robust, så det ikke fejler pga. dette.

  1. Det må ikke stoppe helt

  2. Det må ikke give misvisende resultater, eksempelvis ved at undlade at tage højde for data i den periode, der har været nedbrud.

Kørselstid og timeout

• Køretid for jobbet skal overvejes. Hvis det er omfattende: overvej om det skal køres i bidder (hvis det for eksempel skal behandle store datamængder).

• Timeout værdier skal overvejes. Er de fornuftige/realistiske i forhold til de requests jobbet består af. Vi vil gerne undgå at jobbet fejler efter en “for lavt sat” timeout, som så kræver en manuel genkørsel. 30 sekunder er standard, hvilket altså ikke er fornuftigt i alle tilfælde.

• Database indexes for optimering af køretid skal overvejes.

Navngivning

• Navngivning af batchjob skal være beskrivende for jobbets funktion, max 50 karakterer og være pre-fixet med system-indikation (Vitas/DFDG/Jobnet osv).

Batchjobs der behandler personrelaterede data

Når du udvikler batchjobs, der behandler personrelaterede data, er det vigtigt at sikre korrekt logning og håndtering af data på vegne af personen der arbejdes på baggrund af. For at opnå dette, skal alle batchjobs, der arbejder med persondata, nedarve fra den generiske klasse BatchJobFeatureBase<T> hvor at <T> er typen af data batchjobbet behandler (f.eks. en frist). Denne struktur sikrer, at alle nødvendige steps udføres korrekt, såsom at sætte CPR og publicere eventuelle events per entitet der behandles, og standardiseret logning. Implementeringen af klassen sikrer at:

• hvert element af personrelaterede data behandles med logik implementeret i den abstrakte metode: OnExecuteItem(T item)

• hvert element af personrelaterede data behandles i en transaktion – selve implementeringen af batchjobbet skal således ikke håndtere transaktioner

• events publiceres efter udførelse af hvert element af personrelaterede data – selve implementering af batchjobbet skal således ikke håndtere publicering af events

Sådan opretter du et batchjob i Stonebranch

Se beskrivelse på denne side: Oprettelse af batchjob i Stonebranch

Se også

OBS: Vær opmærksom på forudsætningerne for implementering i Stonebranch, beskrevet ovenfor.

Verificering af nye/omlagte batchjobs

Følgende skal verificeres:

• Kører jobbet med success, som scheduleret

• Stemmer Stonebranch status overens med Batchlog/Eventlog (samt evt. log i LSS, hvis jobbet også logger der)

Nedlæggelse af batchjobs

Ved nedlæggelse af batchjobs, herunder ved flytning af batchjobs fra DFDG (classic) til nye forretningsdomæner:

• Udv. team skal sørge for at fjerne det gamle batchjobs trigger fra koden

• Jobbet skal disables i Stonebranch xml filerne

• Der skal oprettes sag til SF med bestilling af nedlægges af batchjob

Dokumentation og information til SF

Batchjobbet skal dokumenteres på wiki under det system det vedrører, således at udviklere har information til fejlsøgning.

Herudover skal SF have information til overvågning og action på fejl.

Se detaljer her.