Batchverwerking zal ook de eindgebruikers ten goede komen

Misschien is elke ERP-implementatie brengt de noodzaak met zich mee om operaties in batchmodus te plannen en uit te voeren.. Een voorbeeld is het regelmatig boeken van goederen of factureren van gedane verkopen. Batchverwerking wordt echter ook gebruikt door eindgebruikers om eenmalige bewerkingen uit te voeren die veel rekenkracht vergen - bijvoorbeeld het maken van een rapport of het uitvoeren van een afsluiting aan het einde van een boekjaar.

Microsoft Dynamics AX ondersteunt batchverwerking sinds de eerste versies. Met elke nieuwe release komen altijd een aantal belangrijke veranderingen - terwijl Axapta 3.0 batch jobs verwerkte met behulp van een speciale client, introduceerde AX 2009 het concept van server-side processing. AX 2012 bracht vervolgens nog een aanzienlijke prestatieverbetering door de batchverwerking te verplaatsen naar het .NET framework.

Bij Blue Dynamic hebben we uitgebreide ervaring met het uitvoeren van batch jobs op verschillende omgevingen voor verschillende klanten. In de volgende tekst willen wij enkele tips delen in de vorm van vijf waardevolle kennis en ervaringdie we daarbij hebben opgedaan. In het volgende zullen wij verwijzen naar het Blue Dynamic Batch-pakket met de toepassingsaanpassingen die wij hebben ontwikkeld om de problemen in verband met batchoperaties op te lossen.

Tip 0: Van een beetje theorie gaat niemand dood?

Elke batchjob bestaat uit een kop (Batch Job) en één of meer rijen.

Of dit is nog geen tip. Maar om het schrijven te vergemakkelijken, moet je een beetje duidelijk zijn over de terminologie. Elke batchjob bestaat uit een kop (Batchjob) en één of meer rijen (Batchjob). De Tsjechische vertaling is hier niet helemaal gelukkig, de betekenis van de woorden taak en opdracht in gewoon Tsjechisch is vrijwel identiek.
De Engelse teksten zijn in dit opzicht beknopter - koppen heten Batch-taken en rijen heten Batch-taken - en daarom zal ik me in de volgende tekst houden aan de Engelse terminologie, taalkundige conservatieven zullen het me vergeven.

Het is belangrijk te weten waarvoor Batch-taken en Batch-taken dienen en hoe ze toegankelijk zijn. Microsoft Dynamics AX. Batchjobs bepalen het gedrag van de batch als geheel - huidige status, verwerkingsschema inclusief herhalingen, datum en tijd van de volgende run. Batch-taken daarentegen vertegenwoordigen specifieke stappen in batch-verwerking - bepalen welke acties moeten worden uitgevoerd en met welke parameters (bijvoorbeeld invoerfilters worden hier gedefinieerd). Tussen de afzonderlijke stappen kunnen dan afhankelijkheden worden gedefinieerd om de juiste volgorde van verwerking te bepalen of om parallelle verwerking mogelijk te maken.

Tip 1: Een goede naamgeving als basis

Als we opereren in Dynamics AX-oplossing vijf batches, dan doen hun namen er niet zoveel toe, we kunnen gemakkelijk een overzicht houden van welke batches er in het systeem lopen. Na verloop van tijd wordt de situatie echter meestal gecompliceerd. Sommige partijen moeten alleen overdag draaien, andere alleen 's nachts.. Sommige batches willen wij om de paar minuten uitvoeren in de modus "alleen wijzigingen verwerken" en dan eenmaal per dag in de modus "alles verwerken" voor de veiligheid (een goed voorbeeld is bv. de overdracht van retailmastergegevens van het hoofdkantoor naar individuele winkels). Sommige batches zijn zo tijdrovend dat we besluiten het systeem enigszins te ontlasten en telkens slechts een deel van de gegevens te verwerken. (b.v. bij het zoeken naar duplicaten in een lijst van miljoenen klanten, begin met degenen waarvan de achternaam begint met de letter A). En zo zullen we vroeg of laat merken dat de lijst van actieve partijen verschillende schermen oplevert.

Daarom is het verstandig om vanaf het begin een systeem in de verwarring te brengen. Wij vinden het nuttig om namen met verschillende voorvoegsels te gebruiken om partijen te benoemen. Deze kunnen verschillende niveaus hebben. Als voorbeeld geven wij namen op twee niveaus:

Of hij overdag (D) of 's nachts (N) draait
Om welk gebied (welke module) gaat het - bv. logistiek (LOG), financiën (FIN), administratie (ADM), enz.

De batch kan dan bijvoorbeeld N-FIN-Update balances voor dimensieset Ucet worden genoemd.

De voordelen van dit systeem liggen voor de hand - bij het sorteren op naam krijgen we thematisch verwante partijen bij elkaar. Bovendien, gemakkelijk onderscheid maken tussen batches die goed gepland en ingesteld zijn en batches die ad hoc door een normale gebruiker worden getriggerd. Ten slotte geeft de naam van de partij informatie over de inhoud en het tijdschema.

Tip 2: Beheerder op vakantie

Laten we zeggen dat we een Batchtaak hebben met dertig Batch-taken, die elk een of andere complexe filterset hebben. Bovendien worden complexe afhankelijkheden gedefinieerd tussen elke Batch-opdracht. Na enige tijd komt er een verzoek om nog een Batch-taak toe te voegen. De beheerder Peter, die de oorspronkelijke Batch job definieerde, is op vakantie, dus heeft Pavel de leiding over de oplossing. Gaandeweg ontdekt hij dat hij moet zijn ingelogd als beheerder om de taak te voltooien en dat de header-status Withold moet zijn (de Engelse vertaling van Collision is volledig uit de realiteit). Uiteindelijk komt hij er echter achter dat hij de taak toch niet kan volbrengen. - wanneer u een nieuw record aanmaakt in Batch-taken, krijgt u een vrij onopvallende foutmelding Kan geen record aanmaken in Batch-taken (Batch). De bijbehorende AOS-validatie is mislukt. Met hetzelfde, als hij alleen afhankelijkheden tussen bestaande Batch-taken wilde veranderen. En wat nu?

de eigenaar van het voordeel, d.w.z. de persoon die de oorspronkelijke definitie van het voordeel heeft gecreëerd
systeembeheerder
geen van beide

Het eerste en het derde geval zijn twee uitersten. De eigenaar van het voordeel kan naar believen over zijn voordeel beschikken. Anderzijds kan een gewone gebruiker zonder administratieve rechten niets doen met andermans batch. Het tweede geval is interessant - een beheerder die niet de auteur van de partij is. Hij of zij kan gegevens over de uitvoering van de batch zelf wijzigen - bijvoorbeeld de uitvoering opschorten of inplannen volgens een nieuw schema. Hij of zij kan de batch echter niet inhoudelijk wijzigen - hij of zij kan geen nieuwe Batch-taken aanmaken, parameters (bijv. invoerfilters) van bestaande Batch-taakrecords wijzigen, of de actie zelf (d.w.z. de klassenaam) wijzigen. De reden voor deze beperkingen is om controle van wijzigingen mogelijk te maken - Het kan niet zo zijn dat Paul namens Peter wijzigingen aanbrengt in de batch-instellingen die leiden tot ongewenst gedrag.. Pavel heeft nu dus twee opties - ofwel Peter halen, ofwel zijn eigen definitie van een Batch-taak vanuit het niets creëren.

Om de beginselen van de controle niet te verstoren en tegelijkertijd de beheerder Peter in staat te stellen op vakantie te gaan, hebben wij in het pakket ontwikkeld Blauwe Dynamische Partij nieuwe functionaliteit. In plaats van de veldwaarde "Aangemaakt door" gebruiken we voor controledoeleinden een nieuw veld "Batch Job Owner". De waarde ervan is dezelfde als de waarde in het veld Aangemaakt nadat de batch is aangemaakt, maar kan worden gewijzigd met de functie "Eigendom nemen".

Nadat hij eigenaar is geworden, kan Pavel de nodige wijzigingen aanbrengen, uiteraard in zijn eigen naam. De waarde "Eigenaar van batchtaak" wordt ook weggeschreven naar de batchverwerkingsgeschiedenis, zodat we gemakkelijk kunnen achterhalen wanneer de verandering van eigenaar heeft plaatsgevonden.

Tip 3: Waarvoor voordeelgroepen wel en niet dienen

Laten we beginnen met waar batchgroepen niet goed voor zijn - ze zijn niet goed voor het organiseren van werk met individuele Batch-taken. De reden is eenvoudig - een batchgroep is een vlag op een Batch taakrecord, niet een Batch taak. Als de behoefte ontstaat om Batch-taken beter te organiseren, moet u orde aanbrengen in de naamgeving van batches, zie Tip 1.

Waar zijn voordeelgroepen goed voor? Het belangrijkste doel is om verschillende Batch-taken op verschillende AOS-servers te kunnen verwerken. In installaties waar slechts één AOS-server batchopdrachten verwerkt, is een enkele batchgroep voldoende (hiervoor wordt automatisch een naamloze groep aangemaakt na de installatie van AX). Er zijn echter situaties waarin het opsplitsen van opdrachten in afzonderlijke AOS'en nuttig kan zijn. Voorbeelden hiervan zijn batches die rekenkracht vereisen of batches die een speciale bron vereisen die slechts op enkele AOS-servers beschikbaar is.

Bij Blue Dynamic hebben we nagedacht over hoe groepen nog beter van dienst kunnen zijn. Een van de problemen die wij vaak tegenkomen bij het uitvoeren van batches is de negatieve interactie tussen twee of meer batches die tegelijkertijd lopen. Bijvoorbeeld, soms komen de retail batches "Post Inventory" en "Post Statement" samen. De "Post Inventaris" batch is gepland om elke 10 minuten te draaien, terwijl de "Post Afschrift" batch gepland is om één keer per dag te draaien na het sluiten van de kassa's. De partij "Postvoorraad" loopt echter "leeg" nadat de kassa's zijn gesloten - het is logisch dat er geen nieuwe transacties binnenkomen. Dus als we de "Post voorraad" batch kunnen instellen om slechts tot een bepaald uur te lopen en dan de volgende ochtend opnieuw, kunnen we zo'n botsing gemakkelijk vermijden en ons de moeilijke taak besparen om uit te zoeken hoe de twee batches elkaar beïnvloeden en hoe we ze kunnen opheffen om rekening te houden met de parallelle loop.

Het bovenstaande probleem kan in standaard AX alleen worden opgelost door meerdere applicatieservers te gebruiken. Maak twee batchgroepen - DAG en NACHT. Zet de "Post Inventaris" batch in de DEN groep en de "Post Afschrift" batch in de NOC groep. Stel de eerste AOS in om van 8:00 tot 22:00 uur te lopen en alleen de DAG-batchgroep te verwerken. De tweede AOS wordt dan ingesteld om van 22:15 tot 7:45 uur te lopen (waardoor een marge van 15 minuten overblijft voor langer lopende batches) en alleen de NOC-batchgroep te verwerken.

Maar wat te doen als het gebruik van een andere AOS-server niet mogelijk is? Wij lossen het probleem op door de optie toe te voegen om de planning op te geven op het niveau van de partijgroep.

Batchgroep in Dynamics AX 2012 Blue Dynamic

Na deze wijziging, die deel uitmaakt van de Blue Dynamic Batch, kunnen we volstaan met één AOS-server en toch geen conflict hebben.

Tip 4: Wanneer batches "zichzelf gaan voortplanten" en een "naamloze" batchgroep

In deze tip gaan we terug naar onze "Post a statement" batch van de vorige tip. De klant exploiteert een netwerk van winkels en gebruikt de module AX Retail. Hij verkoopt overdag en registreert de verkoop in de kassa. s Avonds sluit de kassa en worden de gegevens overgebracht naar AX. In AX wordt dan een rapport aangemaakt dat moet worden gepost. Omdat we alles automatisch willen laten verlopen, wordt de taak om het rekeningoverzicht te posten ingepland als een nachttaak. Dus net na het plannen hebben we een Batchjob genaamd "Post Statement", die een Batchjob heeft met dezelfde naam en met de batchgroep NIGHT. Maar nadat deze batch is verwerkt, verschijnen er plotseling nieuwe Batch-opdrachten die er eerder niet waren. Wat zijn ze?

Sommige batchtaken zijn zo geschreven dat zij het totale werk in kleinere eenheden verdelen en deze eenheden worden dan parallel verwerkt in meerdere batchtaken. Tussen deze dynamische Batch-taken kunnen ook afhankelijkheden worden gedefinieerd - zo kan bijvoorbeeld aan het eind een laatste Batch-taak worden opgenomen die zorgt voor opruimactiviteiten die pas kunnen plaatsvinden als alle Batch-taken zijn beëindigd.
Er is één lastig ding verbonden aan deze mooie functionaliteit. Dynamisch aangemaakte Batch-taken hebben mogelijk niet dezelfde batch-groep als de oorspronkelijke Batch-taakHet exacte gedrag wordt bepaald door de programmeur tijdens de ontwikkeling van de batch. Waar dit toe kan leiden is duidelijk - als aan dynamisch aangemaakte Batch-taken een groep is toegewezen, waarvan de uitvoering is opgeschort, dan zullen zij nooit worden gestart en blijft de batch als geheel "hangen" in de status Verwerken.

Deze situatie wordt geïllustreerd in het volgende scherm - aan de laatste drie Batch-taken is een naamloze batch-groep toegewezen. Als de verwerking van de naamloze batchgroep wordt opgeschort, wordt de boeking van het rapport nooit voltooid.

Batch-taken en hun weergave in Dynamics AX 2012

Dit is eigenlijk een typisch geval - dynamisch aangemaakte Batch-taken hebben waarschijnlijk dezelfde batch-groep als de hoofd Batch-taak of een lege. Aangezien de interne logica van het aanmaken van dynamische Batch-taken niet altijd kan worden beïnvloed, lijkt het een goed idee om de verwerking van een batchgroep zonder naam niet te beperken. Dit is ook om een andere reden belangrijk - eenmalige batches die door ad hoc eindgebruikers worden uitgevoerd, zullen heel vaak gewoon een batchgroep hebben zonder naam, omdat deze minder ervaren gebruikers vaak zullen vergeten de batchgroep te specificeren.

Tip 5: Hoe krijg je een goede nachtrust?

Batches lopen vaak in de nachtelijke uren, waarvan de succesvolle voltooiing afhangt van de goede werking van het bedrijf de volgende dag. - Het kan bijvoorbeeld een masterplan zijn dat bestelvoorstellen en winkelaanvulling genereert, of een batch die werk voorbereidt voor picking vanuit het centrale magazijn.

In het algemeen zijn dit relatief ingewikkelde taken, waarbij veel obstakels op de loer liggen, die niet altijd tot een goede afloop leiden. Bovendien zijn dit partijen die veel tijd in beslag nemen, zodat er misschien niet genoeg tijd is om ze de volgende ochtend te herstellen. Daarom is het van groot belang snel te reageren op de problemen die met deze partijen gepaard gaan.

Dit zijn over het algemeen relatief ingewikkelde taken die geen tijd mogen kosten. Het is belangrijk om snel te reageren op batchgerelateerde problemen.

Standaard AX biedt in dit verband het gebruik van waarschuwingen. Het is mogelijk AX voor elke partij een waarschuwing te laten aanmaken als een van de gebeurtenissen zich voordoet:

de partij is naar behoren voltooid
de partij eindigt met een fout
de uitkering komt te vervallen

De beheerder kan de waarschuwingen bekijken in de AX-toepassing of ze laten e-mailen naar een vooraf bepaald adres.

De alarmfunctie is ongetwijfeld nuttig, maar niet voldoende om een rustige slaap te garanderen. Het probleem doet zich voor wanneer de batch helemaal niet begint te verwerken, of er ongewoon lang over doet. Een veel voorkomende oorzaak van langere duur kan negatieve interactie zijn met een andere computationeel complexe taak.

Vaak is AX niet het enige systeem in het bedrijf dat bijdraagt tot het succes van de volgende dag. Bedrijven hebben vaak aparte CRM, e-shop, kassasystemen, enz. In dergelijke gevallen neemt de complexiteit van de bewaking van het gehele ecosysteem toe en is het raadzaam de infrastructuur vanaf één centrale locatie te gaan bewaken. Dan lijkt aletry een niet-systeemgebonden oplossing en is het noodzakelijk om in plaats daarvan AX-batches te koppelen aan centrale bewaking.

Blue Dynamic heeft Check MK met succes gebruikt in combinatie met dosisbewaking. We hebben scripts ontwikkeld waarmee kritische batches kunnen worden gecontroleerd op hun voortgang - of de verwerking op tijd is begonnen, wat de voortgang is en of ze binnen de voorgeschreven tijd klaar zullen zijn - en waarmee op kritieke situaties kan worden gereageerd door een SMS-bericht naar de supporttelefoon te sturen. Wij werken momenteel aan veralgemening en de mogelijkheid om monitoringgerelateerde parameters rechtstreeks in de AX-omgeving in te voeren.