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å /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, og max 50 karakterer.

Sådan opretter du et batchjob i Stonebranch

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

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)

Dokumentation og information til SF

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.

Se detaljer her.