Sekvens Better Job Queue
Eksternt styret jobkø.
Opsætning som en almindelig jobkø i BC, men afviklet og styret uden for BC, så du har større frihed, kan køre på tværs af selskaber - og kan få markant bedre monitorering.
Ingen jobs dør ubemærket
Et job, der ikke melder tilbage inden for sin timeout-grænse, bliver opdaget og startet igen eller meldt ind som fejl på e-mail eller i Teams, så I ikke først hører om det, når data mangler.
På tværs af selskaber
Jobbene fra alle jeres selskaber og miljøer står samlet i én portal, som I logger ind på med jeres Microsoft-konto. I skal ikke ind i hvert regnskab for at se, om natten gik godt.
Sat op i BC, som I plejer
Tidsplan og retry-politik redigeres i Business Central. I skal ikke lære et nyt værktøj for at oprette et job.
Hele kørselshistorikken
Hver kørsel bliver logget. Også de jobs, som er startet manuelt eller automatisk fra portalen.
SÅDAN HÆNGER DET SAMMEN
Fire dele, fra opsætningen i Business Central til alarmen, når noget går galt.
I Business Central
Opsætningen
Alle jobs oprettes i Business Central helt som normalt og peger på det objekt, der skal køres, f.eks. en codeunit. Her opsættes tidsplan, maks. køretid og retry-politik også.
- Tidsplan pr. job, f.eks. hvert femte minut
- Maks. køretid, før jobbet regnes for at være gået i stå
- Retry-politik pr. job eller slet ingen automatisk genstart
Den smarte del
Jobbet afvikles også uden for BC
En komponent uden for BC starter jobbet efter den tidsplan, I har opsat i BC, og altid i det miljø og regnskab, jobbet hører hjemme. Går en kørsel galt, opdager Better Job Queue det - også når BC ikke selv melder noget.
- Kan køre jobs på tværs af flere selskaber og miljøer
- Et job kan køres igen med det samme fra portalen
- Jobkøen i BC bliver startet og stoppet udefra via API’er
Job Health
Timeout-grænse
For hvert job kan du opsætte en grænse for, hvor længe jobbet må forblive tavst. Giver jobbet ikke lyd fra sig inden for grænsen, bliver det automatisk genstartet eller meldt ind som fejl med en alarm.
- Job health pr. job vises uden for BC
- Sidste vellykkede og næste planlagte kørsel vises for hvert job
- Åbne alarmer samles ét sted
- Alarmer kan sendes på e-mail og i Teams
Historik
Kørselshistorikken udvides
Alle kørsler bliver logget, både de planlagte og dem, der er startet manuelt.
- Status, oprindelse og antal forsøg
- Starttidspunkt og varighed
- Fejlbeskeder, når en kørsel går galt
ABONNEMENT
Prismodel.
| Start | Medium | Pro | |
|---|---|---|---|
| Pr. måned | 279 kr. | 499 kr. | 799 kr. |
| Årlig faktura | 3.348 kr. | 5.988 kr. | 9.588 kr. |
| BC-selskaber | 1 | 3 | Ubegrænset |
Prisen afhænger af, hvor mange BC-selskaber I har. Sandbox-miljøer tæller (naturligvis) ikke med. Vi fakturerer årligt forud, og alle priser er ekskl. moms.
Det kan lade sig gøre at finde apps til Business Central, som sender en mail, når en jobkøpost fejler, og nogle af dem kan også genstarte et job. Men disse jobs kører i det samme BC-miljø, som de holder øje med - og hvis hele jobkøen står stille, står overvågningen ofte stille samtidigt.
Better Job Queue ligger derfor uden for BC og opdager også de jobs, der aldrig kom i gang, eller som er faldet i søvn.
I praksis
Jobkøen ser fin ud. Ingen alarm. Men jobbet har været failed i 2 uger.
Det store problem med almindelige jobkøer i BC er, at de kan gå ned i stilhed, så man først opdager det, når man skulle have brugt data, mails skulle være sendt eller lign.
En jobkøpost i Business Central larmer ikke, når den fejler. Den prøver igen så mange gange, som den er sat op til, og så får den status Fejl og bliver stående i fejl. Ifølge Microsofts dokumentation og BC’s måde at virke på, skal posten derefter genstartes manuelt. På godt dansk er det bare træls.
Værre er de jobkøposter, som aldrig når at fejle. De bliver hængende i status “I gang”, og ingen får besked om noget. Integrationen til webshoppen har så ikke kørt i nogle dage, lagertal er ikke hentet fra eksterne leverandører - og man opdager det først, når fejlen er sket.
Microsoft tilbyder notifikationer og telemetri, som sendes til Application Insights. Telemetrien kræver en Azure-ressource og forespørgsler i KQL. Begge dele kan - hvis det er rigtigt opsat - fortælle jer, at noget er gået galt.
Men ingen af delene kan starte jobbet igen.
Det gør Sekvens Better Job Queue anderledes og bedre. Ved at separere jobkø og BC kan Better Job Queue vise, om jobs rent faktisk har kørt, om de har fået timeout, eller om de er failed. Det hele bliver samlet op, og en automatisk genstart kan sættes op. Derudover er der mulighed for at melde en alarm til IT / ERP-support.
Få overblik over jeres jobkø.
Fortæl os lidt om jeres udfordringer med jeres håndtering af Job Queues - og så siger vi, om vi kan hjælpe jer videre.