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.
Følgende forudsætninger skal være på plads inden implementering i Stonebranch foretages.
Nye batchjobs bør kun releases med Major Release.
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)
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å /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)?
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.
Det må ikke stoppe helt
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ø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 af batchjob skal være beskrivende for jobbets funktion, max 50 karakterer og være pre-fixet med system-indikation (Vitas/DFDG/Jobnet osv).
Se beskrivelse på denne side: Oprettelse af batchjob i Stonebranch
OBS: Vær opmærksom på forudsætningerne for implementering i Stonebranch, beskrevet ovenfor.
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)
Batchjobbet skal dokumenteres på /wiki/spaces/CITY/pages/1809154424, således at udviklere har information til fejlsøgning.
Herudover skal SF have information til overvågning og action på fejl.