Behandlingsrutine og bakgrunnsoppgaver 1s 8.3. Bakgrunnsoppgaver: funksjoner, muligheter, innstillinger. Opprette metadata for en rutineoppgave

Når du jobber i 1C, er det mange rutineoperasjoner som må startes eller dannes i henhold til en tidsplan for å utføre en eller annen handling, for eksempel: legge ut dokumenter eller laste inn data til 1C fra et nettsted.

Jeg la nylig ut en artikkel: Det er på tide å automatisere dette:

Rutine- og bakgrunnsoppgaver

Jobbmotoren er designet for å utføre enhver applikasjon eller funksjonalitet på en tidsplan eller asynkront.

Oppgavemekanismen løser følgende oppgaver:

• Evne til å definere regulatoriske prosedyrer på systemkonfigurasjonsstadiet;
• Utførelse av spesifiserte handlinger i henhold til tidsplan;
• Å ringe en gitt prosedyre eller funksjon asynkront, dvs. uten å vente på at den er ferdig;
• Spore fremdriften til en spesifikk oppgave og oppnå fullføringsstatus (en verdi som indikerer om den var vellykket eller ikke);
• Innhente en liste over aktuelle oppgaver;
• Evne til å vente på at en eller flere oppgaver skal fullføres;
• Jobbledelse (mulighet for kansellering, sperring av utførelse etc.).

Jobbmekanismen består av følgende komponenter:

• Metadata av rutineoppgaver;
• Vanlige oppgaver;
• Bakgrunnsjobber;
• Oppgaveplanlegger.

Bakgrunnsjobber og er designet for å utføre applikasjonsoppgaver asynkront. Bakgrunnsoppgaver implementeres ved hjelp av det innebygde språket.

Planlagte oppgaver og er designet for å utføre applikasjonsoppgaver etter en tidsplan. Rutineoppgaver lagres i informasjonsbasen og lages basert på metadata definert i konfigurasjonen. Metadata for en reguleringsoppgave inneholder informasjon som navn, metode, bruk osv.

En rutineoppgave har en tidsplan som bestemmer på hvilke tidspunkter metoden knyttet til rutineoppgaven må utføres. Tidsplanen er som regel spesifisert i informasjonsbasen, men kan også spesifiseres på konfigurasjonsstadiet (for eksempel for forhåndsdefinerte rutineoppgaver).

Oppgaveplanleggeren brukes til å planlegge utførelsen av rutineoppgaver. For hver planlagte jobb sjekker planleggeren med jevne mellomrom om gjeldende dato og klokkeslett samsvarer med tidsplanen for den planlagte jobben. Hvis det stemmer, tilordner planleggeren den oppgaven til utførelse. For å gjøre dette, for denne planlagte oppgaven, oppretter planleggeren en bakgrunnsoppgave, som utfører selve behandlingen.

Jeg tror det er nok med beskrivelsen - la oss komme ned til implementeringen:

Opprette en rutineoppgave

Metodenavn– banen til prosedyren som vil bli utført i en bakgrunnsjobb i henhold til en gitt tidsplan. Prosedyren skal være i en felles modul. Det anbefales å ikke bruke standard vanlige moduler, men å lage dine egne. Ikke glem at bakgrunnsjobber kjører på serveren!

Bruk– tegn på bruk av en rutineoppgave.

Forhåndsbestemt– indikerer om rutineoppgaven er forhåndsbestemt.

Hvis du vil at rutineoppgaven skal fungere umiddelbart etter at den er plassert i databasen, spesifiser attributtet Forhåndsbestemt. Ellers må du bruke "Job Console"-behandlingen eller utløse oppgaven for å kjøre programmatisk.

Antall nye forsøk når en jobb avsluttes unormalt– hvor mange ganger bakgrunnsjobben ble startet på nytt hvis den ble utført med en feil.

Forsøk på nytt når jobben avsluttes unormalt– hvor ofte bakgrunnsjobben vil bli startet på nytt hvis den ble fullført med en feil.

Sette opp en tidsplan

Rute fullføre oppgaven:

Hver time, bare én dag	RepeatDays Period = 0, RepeatDays Period = 3600
Hver dag en gang om dagen	RepeatDays Period = 1, RepeatDays Period = 0
En dag, en gang	PeriodRepeatDays = 0
Annenhver dag en gang om dagen	PeriodRepeatDays = 2
Hver time fra 01.00 til 07.00 hver dag	PeriodRepeatDays = 1RepeatPeriodI løpet av dagen = 3600StartTime = 01.00 Sluttid = 07.00
Hver lørdag og søndag kl 09.00	RepeatDays Period = 1 WeekDays = 6, 7StartTime = 09.00
Hver dag i en uke, hopp over en uke	PeriodRepeatDays = 1PeriodeUker = 2
Klokken 01.00 en gang	Starttid = 01.00
Siste dag i hver måned kl 9:00.	PeriodRepeatDays = 1DayInMonth = -1StartTime = 09.00
Femte dag i hver måned kl. 9:00	PeriodRepeatDays = 1DayInMonth = 5StartTime = 09.00
Andre onsdag i hver måned kl. 9.00	PeriodRepeatDays = 1DayWeekMonth = 2DaysWeek = 3 Starttid = 09.00

Funksjoner for å utføre bakgrunnsjobber i fil- og klient-servervarianter

Mekanismene for å utføre bakgrunnsjobber i fil- og klient-serverversjonene er forskjellige.

I filversjon du må lage en dedikert klientprosess som vil utføre bakgrunnsjobber. For å gjøre dette må klientprosessen med jevne mellomrom kalle opp den globale kontekstfunksjonen ExecuteJobProcessing. Bare én klientprosess per infobase skal behandle bakgrunnsjobber (og følgelig kalle denne funksjonen). Hvis en klientprosess ikke er opprettet for å behandle bakgrunnsjobber, vil feilen "Job Manager er ikke aktiv" vises når du programmerer tilgang til jobbmotoren. Det anbefales ikke å bruke en klientprosess som behandler bakgrunnsjobber for andre funksjoner.

Når bakgrunnsjobber for klientprosessbehandling er startet, er andre klientprosesser i stand til å programmere tilgang til bakgrunnsjobbmotoren, dvs. kan kjøre og administrere bakgrunnsjobber.

I klient-serverversjon For å utføre bakgrunnsjobber brukes en oppgaveplanlegger, som er fysisk plassert i klyngebehandlingen. For alle bakgrunnsjobber i kø får planleggeren den minst belastede arbeidsprosessen og bruker den til å kjøre den tilsvarende bakgrunnsjobben. Arbeidsprosessen utfører jobben og varsler planleggeren om utførelsesresultatene.

I klient-serverversjonen er det mulig å blokkere utførelse av rutineoppgaver. Utførelsen av rutineoppgaver er blokkert i følgende tilfeller:

• Det er installert en eksplisitt blokkering av rutineoppgaver på informasjonsbasen. Låsen kan stilles inn via klyngekonsollen;
• Det er en tilkoblingsblokk på infobasen. Låsen kan stilles inn via klyngekonsollen;
• SetExclusiveMode()-metoden med True-parameteren ble kalt fra det innebygde språket;
• I noen andre tilfeller (for eksempel ved oppdatering av databasekonfigurasjonen).

Behandling av lansering og visning av planlagte oppgaver du kan laste ned her.

Spørsmålet vi stiller i tittelen på artikkelen er relevant for mange systemadministratorer som jobber med dette produktet. Så langt som mulig prøver vi å snakke om parametrene som påvirker 1C-ytelsen og avlive populære myter. I dag, ved å bruke eksempelet fra en nylig sak, ønsker vi å fortelle deg om et annet aspekt som kan påvirke produktiviteten alvorlig - rutineoppgaver.

La oss starte med en ekte sak. For ikke lenge siden kontaktet en av våre kunder oss med en klage på 1C "bremsene" til en av hans ansatte. Symptomene var at Trade Management 10-konfigurasjonen etter en viss tid begynte å avta kraftig, eller rett og slett, frøs en stund.

En mer detaljert analyse av situasjonen avslørte at dette bare skjer med én ansatt, og på en hvilken som helst arbeidsplass har det skjedd i lang tid, men hvis tidligere "bremsene" varte omtrent et sekund, kan de nå, etter oppdateringen, varer i opptil 15-20 sekunder, noe som gjør arbeidet ekstremt ubehagelig.

I prinsippet er de første dataene allerede tilstrekkelige til å trekke de første konklusjonene. La oss liste dem opp igjen:

• "Bremser" forekommer konstant, med en viss frekvens
• Brekker farten bare for én bruker
• «Sakter farten» på enhver arbeidsplass

For å bekrefte gjetningene våre, la oss se på Regnskapsinnstillinger:

Faktisk er "problem"-brukeren oppført som en bruker for å utføre rutineoppgaver. Det viste seg at det en gang i tiden kjørte en RIB-autoutvekslingsoppgave på vegne av denne brukeren. Det gjenstår å se hva som var årsaken til den episodiske "bremsingen". Dette er også enkelt å gjøre:

Og her er "begivenhetens helt" - oppgaven med å oppdatere fulltekstsøkeindeksen, som ble lansert en gang hvert 2,5 minutt. I dette tilfellet ble problemet fullstendig løst ved å deaktivere utførelsen av rutineoppgaver under denne brukeren, men dette er ikke alltid mulig eller tilrådelig, så nedenfor vil vi se på hvordan du kan administrere rutineoppgaver og hvordan du sørger for at de ikke gjør det ha en negativ innvirkning på ytelsen.

Vanlig søknad

I konfigurasjoner basert på en vanlig applikasjon finnes det ikke ett enkelt verktøy for å administrere rutineoppgaver. Dette skyldes i stor grad det faktum at selve konseptet med rutineoppgaver på tidspunktet for deres første utvikling var ganske dårlig utviklet.

Mange rutineoppgaver administreres gjennom å sette opp delsystemene knyttet til dem. For eksempel bør innstillingene for regulatoriske oppgaver knyttet til datautveksling ses etter i utvekslingsinnstillingene knyttet til Unified State Automated Information System i alkoholhandelsinnstillingene osv.

Ved første øyekast er alt ganske logisk, men mangelen på et enkelt verktøy gjør det vanskelig å kontrollere de konfigurerte rutineoppgavene og optimaliteten til innstillingene deres. Det er bra hvis det er en eller to oppgaver, men hvis det er flere av dem eller, som i vårt tilfelle, er det mistanke om en av de planlagte oppgavene, men du aner ikke hvem som har konfigurert hva i denne databasen.

I dette tilfellet bør du bruke ekstern behandling ConsoleTasks (JobsConsole), som er inkludert i settet med standardbehandling på ITS-disken. Behandling gir ett enkelt grensesnitt for alle jobber og lar dem konfigureres sentralt, samt kontrollere jobbene som kjører for øyeblikket.

Denne listen bør studeres nøye, alle unødvendige oppgaver bør deaktiveres, og tidsplanen for de som er nødvendige bør bringes i tråd med umiddelbare behov og sunn fornuft. For eksempel, i vårt tilfelle, er det ikke nødvendig å behandle EGAIS-svar en gang hvert 30. sekund (denne innstillingen ble gjort for testing) og i driftsmodus vil det være ganske nok å gjøre dette, for eksempel en gang hver halvtime.

Administrert applikasjon

I konfigurasjoner basert på en administrert applikasjon tildeles rutineoppgaver en mer betydelig rolle med deres hjelp, ulike oppgaver kan utføres for å vedlikeholde informasjonsgrunnlaget og holde det oppdatert, men samtidig er det rutineoppgaver de fleste; blir ofte årsaken til "bremser".

Det er et eget punkt i menyen for å administrere rutineoppgaver Administrasjon - Support og vedlikehold.

Det kan umiddelbart bemerkes at antallet oppgaver har økt betydelig (for eksempel tok vi den samme konfigurasjonen - Retail), og riktig konfigurasjon kan forbedre ytelsen til informasjonsbasen betydelig. Standardinnstillingene er laget av 1C basert på behovene til et gjennomsnittlig sfærisk selskap i et vakuum og er ikke engang i nærheten av optimalt.

Først og fremst deaktiverer vi det som åpenbart er unødvendig, det du ikke jobber med. Deretter optimerer vi tidsplanen for sjeldent brukte funksjoner, for eksempel oppdatering av bankklassifisereren i Retail, samt sjekk av motparter, kan utføres en gang i uken i ikke-arbeidstid eller på slutten (begynnelsen) av arbeidsdagen.

Spesiell oppmerksomhet bør rettes mot alt relatert til søkeindeksen. Fulltekstsøk er absolutt en praktisk ting, men å jobbe med indeksen er en veldig, veldig ressurskrevende oppgave. Derfor bør du ikke gå til det ekstreme og forlate det, men du bør seriøst revurdere og justere parametrene.

La oss begynne med tekstutvinning, lar denne operasjonen deg søke i innholdet i vedlagte filer, så hvis du ikke bruker dem, ikke søker gjennom dem, eller du bare har bilder der, så kan denne operasjonen deaktiveres i alle fall, og utføre den en gang hver 85 sekunder er helt klart overkill.

PPD-indeksoppdatering- en av de mest ressurskrevende operasjonene, utført en gang per minutt som standard.

La oss nå tenke på hvor ofte informasjonen du oftest søker etter blir lagt til eller oppdatert i databasen? Åpenbart ikke hvert minutt, så det vil være ganske nok å oppdatere indeksen mye sjeldnere: en gang i timen, en gang om dagen, eller til og med en gang i uken.

Det samme gjelder for sammenslåing av PPD-indeksen Hvis du oppdaterer indeksen en gang om dagen, bør du konfigurere sammenslåingen til å kjøre en gang i uken, og velge det minst forstyrrende tidspunktet for å starte jobben.

Disse enkle operasjonene vil tillate deg, uten mye skade på funksjonaliteten til konfigurasjonen, å heve komforten ved å jobbe med den til et nytt nivå ved å nekte å ofte utføre ganske ressurskrevende operasjoner. Bare ikke gå til ytterligheter; bedøm klokt hvor mye du trenger visse evner og hvor ofte du bør utføre oppgaver relatert til dem.

• Tagger:

Vennligst aktiver JavaScript for å se

Plattformer: 1C:Enterprise 8.3, 1C:Enterprise 8.2, 1C:Enterprise 8.1
Konfigurasjoner: Alle konfigurasjoner

2012-11-13
53989

I dokumenthåndtering er det oppgaver som krever periodisk utførelse - for eksempel på den tjuende, eller daglig. Som regel lager bedrifter bestemte regler spesielt for dette formålet, som angir når og hvordan den nødvendige oppgaven skal utføres, og hvem som skal kontrollere prosessen. Slike oppgaver utføres forskriftsmessig og kalles regulert.

Ganske ofte følges overvåkingsforskrifter innen IT. Denne metoden er veldig kjent for administratorer, siden det for dette formålet er spesielle programmer som brukes til å periodisk sjekke funksjonaliteten til nettverksinfrastrukturen og serverne. De varsler administratoren om oppdagede problemer via SMS eller e-post.

Et lignende system fungerer for webansvarlige, og nettstedets tilgjengelighet sjekkes innen 24 timer. Ved å bruke mekanismen "Rutineoppgaver" i 1C utføres overvåkingsoppgaver, samt periodiske oppgaver som utføres i henhold til en tidsplan i automatisk modus i 1C. La oss se nærmere på dette emnet.

Planlagte oppgaver 1C

1C-objektet, kalt "Rutineoppgaver", gjør det mulig å behandle informasjon ikke etter at et problem oppstår, men i henhold til en tidsplan. I konfiguratoren er en rutineoppgave en måte å sette innstillinger og sette en tidsplan på. I tillegg er det mulig å endre tidsplanen i etterkant i 1C Enterprise-modus.

Når du bruker en fildatabase, blir ikke jobber automatisk utført. For å starte prosessen, må du starte en 1C-sesjon i 1C Enterprise-modus og begynne å utføre en rutineoppgave i den.

Alle standardkonfigurasjoner har en brukerinnstilling som lar deg spesifisere at når 1C kjører, vil rutineoppgaver utføres automatisk.

Bruk av klient-server-versjonen av 1C gjør det mulig å automatisk utføre oppgaver på serveren. På det planlagte tidspunktet startes en bakgrunnsjobb som utfører de nødvendige handlingene. For parallell databehandling på serveren kan en bakgrunnsjobb opprettes fra programteksten ved å bruke 1C-språket, uten å bruke en planlagt 1C-jobb. Handlingen til en planlagt oppgave kan deaktiveres midlertidig ved å bruke 1C-serveradministrasjonskonsollen.

Legger til en planlagt oppgave

Rutineoppgaver ligger i - Konfigurator - Generelt - Rutineoppgaver. Legg til en ny "oppgave" og oppgi et navn. Deretter må du gå til "Oppgaver"-egenskapene. Og velg Metodenavn. Her må du spesifisere en behandlerfunksjon, akkurat som det skjer i et arrangementsabonnement. Denne funksjonen vil være plassert i den generelle modulen og merket med en "bird" Server i egenskapene. Dette betyr at den nødvendige modulen må legges til på forhånd.

Navnet på oppgaven i egenskapene til en planlagt oppgave lar deg definere navnet, som da vises i oppgavebehandlingsverktøyene. Rutineoppgaveegenskaper-funksjonen er en nøkkel som lar deg gruppere flere forskjellige rutineoppgaver. I dette tilfellet kan bare én oppgave med samme nøkkelverdi startes om gangen. Her kan verdien være vilkårlig, men den må fylles ut, siden en tom verdi ikke tas i betraktning av systemet.

I Regnskapsutgave 2.0, som er en standardkonfigurasjon, er rutineoppgaver som: «Rekalkulering av totaler» og «Oppdatering av konfigurasjonen» forhåndsdefinert, men som for eksempel «Utsatte bevegelser» og «Datautveksling» er ikke forhåndsdefinert.

Prøv på nytt ved unormal oppsigelse - starter den gjeldende jobben på nytt. Designet for å utføre en lansering som ikke var vellykket første gang. Her er det angitt hvor mange ganger du kan starte på nytt og etter hvilken tid som har gått etter en unormal avslutning.

Overvåkings- og styringsverktøy for rutineoppgaver 1C

Standardbehandlingen "Task Console", som finnes på ITS-diskene, er ansvarlig for å administrere en rutineoppgave. Denne behandlingen er en universell ekstern standardbehandling 1C. Som regel er den ikke inkludert i konfigurasjonen, men kjøpes separat.

Med dens hjelp kan du utføre følgende handlinger:

Slå på og av en planlagt oppgave;

Tilordne og endre tidsplaner;

Angi brukernavnet som rutineoppgaven skal utføres med;

Se utførte oppgaver (når og med hvilket resultat), samt oppgavefeil;

Rutineoppgaver og kopier av databaser

Når du bruker server 1C, kan følgende øyeblikk oppstå:

For å programmere må du lage en kopi av arbeidsdatabasen;

Behovet for å jobbe i kopier av databasen (testing);

Av en eller annen grunn ble den planlagte oppgaven ikke inkludert i testdatabasen.

Hvis en av disse situasjonene oppsto under utførelsen av oppgaver av en rutineoppgave som bare er knyttet til databasen deres, har ikke dette negative konsekvenser. Men ofte kan en rutineoppgave lagre filer eller andre data, sende e-poster og gjennomføre utvekslinger. I dette tilfellet kan det oppstå forvirring mellom resultatene av "jobben" og kopiene. For å forhindre at dette skjer, må du deaktivere "oppgaver" i serveradministrasjonskonsollen.

Fullførte og ikke fullførte reguleringsoppgaver

Ved opprettelse av rutineoppgaver er det viktig å sjekke om oppgaven kan utføres som en rutineoppgave. Det er viktig å vite at servermodulen ikke gjør mange ting som er mulig på klienten. Videre, en oppgave som omhandler noe som er utenfor databasen - en viktig rolle i dette spilles av rettighetene til Windows-brukeren som oppgaven utføres under.

Den siste faktoren er spesielt viktig, siden hvis modulen ikke kjøres på serveren, kan oppgaven i prinsippet ikke fullføres. For å sjekke, må du kjøre én oppgave og evaluere resultatet.

Jobbmekanisme

Jobbmotoren er designet for å utføre enhver applikasjon eller funksjonalitet på en tidsplan eller asynkront.

Oppgavemekanismen løser følgende oppgaver:

• Evne til å definere regulatoriske prosedyrer på systemkonfigurasjonsstadiet;
• Utførelse av spesifiserte handlinger i henhold til tidsplan;
• Å ringe en gitt prosedyre eller funksjon asynkront, dvs. uten å vente på at den er ferdig;
• Spore fremdriften til en spesifikk oppgave og oppnå fullføringsstatus (en verdi som indikerer om den var vellykket eller ikke);
• Innhente en liste over aktuelle oppgaver;
• Evne til å vente på at en eller flere oppgaver skal fullføres;
• Jobbledelse (mulighet for kansellering, sperring av utførelse etc.).

Jobbmekanismen består av følgende komponenter:

• Metadata av rutineoppgaver;
• Vanlige oppgaver;
• Bakgrunnsjobber;
• Oppgaveplanlegger.

Bakgrunnsjobber er designet for å utføre applikasjonsoppgaver asynkront. Bakgrunnsoppgaver implementeres ved hjelp av det innebygde språket.

Planlagte oppgaver - designet for å utføre påførte oppgaver etter en tidsplan. Rutineoppgaver lagres i informasjonsbasen og lages basert på metadata definert i konfigurasjonen. Metadata for en reguleringsoppgave inneholder informasjon som navn, metode, bruk osv.

En rutineoppgave har en tidsplan som bestemmer på hvilke tidspunkter metoden knyttet til rutineoppgaven må utføres. Tidsplanen er som regel spesifisert i informasjonsbasen, men kan også spesifiseres på konfigurasjonsstadiet (for eksempel for forhåndsdefinerte rutineoppgaver).

Oppgaveplanleggeren brukes til å planlegge utførelsen av rutineoppgaver. For hver planlagte jobb sjekker planleggeren med jevne mellomrom om gjeldende dato og klokkeslett samsvarer med tidsplanen for den planlagte jobben. Hvis det stemmer, tilordner planleggeren den oppgaven til utførelse. For å gjøre dette, for denne planlagte oppgaven, oppretter planleggeren en bakgrunnsoppgave, som utfører selve behandlingen.

Bakgrunnsjobber

Bakgrunnsjobber er praktiske å bruke for å utføre komplekse beregninger når resultatet av beregningen kan ta lang tid å få. Jobbmotoren har midler til å utføre slike beregninger asynkront.

Tilknyttet en bakgrunnsjobb er en metode som kalles når bakgrunnsjobben kjører. En bakgrunnsjobbmetode kan være en hvilken som helst prosedyre eller funksjon av en ikke-global felles modul som kan kalles på serveren. Bakgrunnsjobbparametere kan være alle verdier som tillates sendt til serveren. Parametrene til en bakgrunnsjobb må samsvare nøyaktig med parameterne til prosedyren eller funksjonen den kaller. Hvis bakgrunnsjobbens metode er en funksjon, ignoreres returverdien.

En bakgrunnsjobb kan ha en nøkkel - hvilken som helst søknadsverdi. Nøkkelen introduserer en begrensning på lansering av bakgrunnsjobber - bare én bakgrunnsjobb kan utføres per tidsenhet med en spesifikk nøkkelverdi og et gitt bakgrunnsjobbmetodenavn (metodenavnet består av modulnavnet og navnet på prosedyren eller funksjon). Nøkkelen lar deg gruppere bakgrunnsjobber som har de samme metodene i henhold til en spesifikk applikasjonskarakteristikk, slik at ikke mer enn én bakgrunnsjobb utføres i én gruppe.

Bakgrunnsjobber opprettes og administreres programmatisk fra hvilken som helst tilkobling. Enhver bruker har lov til å lage en bakgrunnsjobb. Dessuten utføres den på vegne av brukeren som opprettet den. En bruker med administrative rettigheter eller brukeren som opprettet disse bakgrunnsjobbene har lov til å motta oppgaver, samt vente på at de er fullført, fra enhver tilkobling.

En bakgrunnsjobb er et rent sesjonsobjekt og tilhører ikke noen brukerøkt. For hver oppgave opprettes en spesiell systemøkt som kjører på vegne av brukeren som ringte. Bakgrunnsjobber har ikke vedvarende tilstand.

En bakgrunnsjobb kan skape andre bakgrunnsjobber. I klient-serverversjonen lar dette deg parallellisere komplekse beregninger på tvers av klyngearbeidsprosesser, noe som kan fremskynde beregningsprosessen som helhet betydelig. Parallellisering implementeres ved å skape flere barnebakgrunnsjobber og vente på at hver av dem skal fullføres i hovedbakgrunnsjobben.

Bakgrunnsjobber som fullføres eller mislykkes, lagres i 24 timer og slettes deretter. Hvis antallet fullførte bakgrunnsjobber overstiger 1000, slettes også de eldste bakgrunnsjobbene.

Planlagte oppgaver

Planlagte oppgaver brukes når det er nødvendig å utføre visse periodiske eller engangshandlinger i henhold til en tidsplan.

Planlagte oppgaver lagres i informasjonsbasen og lages basert på metadataene til rutineoppgaven som er definert i konfigurasjonen. Metadata spesifiserer slike parametere for en rutineoppgave som: kalt metode, navn, nøkkel, mulighet for bruk, tegn på forhåndsbestemmelse osv. Når du oppretter en rutineoppgave, kan du i tillegg spesifisere tidsplanen (kan spesifiseres i metadataene), verdier ​av metodeparametrene, navnet på brukeren som utfører rutineoppgaver på vegne, etc.

Oppretting og administrasjon av planlagte oppgaver utføres programmatisk fra enhver tilkobling og er kun tillatt for brukere med administrative rettigheter.

Note. Når du arbeider i filversjonen, er det mulig å opprette og redigere rutineoppgaver uten å starte oppgaveplanleggeren.

Tilknyttet en rutineoppgave er en metode som kalles når rutineoppgaven utføres. Rutineoppgavemetoden kan være en hvilken som helst prosedyre eller funksjon av en ikke-global felles modul som kan kalles på serveren. Parametrene til en rutineoppgave kan være alle verdier som er tillatt å overføre til serveren. Parametrene til en rutineoppgave må samsvare nøyaktig med parameterne til prosedyren eller funksjonen den kaller. Hvis rutineoppgavemetoden er en funksjon, ignoreres returverdien.

En rutineoppgave kan ha en nøkkel - hvilken som helst applikasjonsverdi. Nøkkelen introduserer en begrensning på lanseringen av planlagte oppgaver, fordi per tidsenhet, blant rutineoppgaver knyttet til det samme metadataobjektet, kan bare én rutineoppgave med en bestemt nøkkelverdi utføres. Nøkkelen lar deg gruppere rutineoppgaver knyttet til det samme metadataobjektet i henhold til en spesifikk applikasjonskarakteristikk, slik at det ikke utføres mer enn én rutineoppgave innenfor én gruppe.

Under konfigurasjonen kan du definere forhåndsdefinerte rutineoppgaver. Forhåndsdefinerte rutineoppgaver er ikke forskjellig fra vanlige rutineoppgaver, bortsett fra at de ikke eksplisitt kan opprettes eller slettes. Hvis i metadataene til den planlagte oppgaven er den satt tegn på en forhåndsbestemt rutineoppgave, så når du oppdaterer konfigurasjonen i infobasen, vil det automatisk opprettes en forhåndsdefinert rutineoppgave. Hvis det forhåndsbestemte flagget slettes, vil den forhåndsdefinerte rutineoppgaven automatisk slettes ved oppdatering av konfigurasjonen i infobasen. Startverdiene til egenskapene til en forhåndsdefinert planlagt oppgave (for eksempel en tidsplan) er satt i metadataene. I fremtiden, når applikasjonen kjører, kan de endres. Forhåndsdefinerte rutineoppgaver har ingen parametere.

Rutineoppgaveplanen bestemmer når rutineoppgaven skal kjøres. Tidsplanen lar deg angi: dato og klokkeslett for starten og slutten av oppgaven, utførelsesperioden, ukedagene og månedene som den planlagte oppgaven skal utføres innen, osv. (se beskrivelsen av det bygget -på språk).

Eksempler på rutinemessige oppgaveplaner:

Hver time, bare én dag	RepeatDays Period = 0, RepeatDays Period = 3600
Hver dag en gang om dagen	RepeatDays Period = 1, RepeatDays Period = 0
En dag, en gang	PeriodRepeatDays = 0
Annenhver dag en gang om dagen	PeriodRepeatDays = 2
Hver time fra 01.00 til 07.00 hver dag	PeriodRepeatDays = 1 Gjenta periodeI løpet av dagen = 3600 Starttid = 01.00 Sluttid = 07.00
Hver lørdag og søndag kl 09.00	PeriodRepeatDays = 1 Ukedager = 6, 7 Starttid = 09.00
Hver dag i en uke, hopp over en uke	PeriodRepeatDays = 1 PeriodeUker = 2
Klokken 01.00 en gang	Starttid = 01.00
Siste dag i hver måned kl 9:00.	PeriodRepeatDays = 1 DagInMåned = -1 Starttid = 09.00
Femte dag i hver måned kl. 9:00	PeriodRepeatDays = 1 DagInMåned = 5 Starttid = 09.00
Andre onsdag i hver måned kl. 9.00	PeriodRepeatDays = 1 DagUkeI Måned = 2 Ukedager = 3 Starttid = 09.00

Du kan sjekke om en oppgave kjører for en gitt dato (RequiredExecution-metoden til ScheduleTasks-objektet). Planlagte oppgaver utføres alltid under navnet til en bestemt bruker. Hvis brukeren av den planlagte oppgaven ikke er spesifisert, skjer kjøringen på vegne av standardbrukeren som har administrative rettigheter.

Rutineoppgaver utføres ved hjelp av bakgrunnsoppgaver. Når planleggeren bestemmer at en planlagt oppgave skal startes, opprettes det automatisk en bakgrunnsjobb basert på denne planlagte oppgaven, som utfører all videre behandling. Hvis denne rutineoppgaven allerede kjører, vil den ikke kjøres igjen, uavhengig av tidsplanen.

Planlagte oppgaver kan startes på nytt. Dette gjelder spesielt når rutineoppgavemetoden må garanteres å bli utført. En rutineoppgave startes på nytt når den avsluttes unormalt, eller når arbeidsprosessen (i klient-serverversjonen) eller klientprosessen (i filversjonen) som rutineoppgaven ble utført på, avsluttes unormalt. I den planlagte oppgaven kan du angi hvor mange ganger den må startes på nytt, samt intervallet mellom omstart. Når du implementerer den omstartbare rutineoppgavemetoden, må du ta i betraktning at når den startes på nytt, vil utførelsen starte fra begynnelsen, og ikke fortsette fra øyeblikket av unormal avslutning.

Det er viktig å huske det Sluttid vil ikke nødvendigvis fullføre bakgrunnsjobben på det angitte tidspunktet. Noen utsagn:

* En bakgrunnsjobb kan ignorere den automatiske kanselleringen hvis den ikke sitter fast, men fortsetter å kjøre fordi ikke alle plattformoperasjoner kan kanselleres. Hvis den sykliske koden til det innebygde språket utføres, kan jobben kanselleres, ellers ikke. Alt avhenger av hva jobben gjør.

* Sluttid - grensen som en oppgave kan starte i stedet for slutt?

Mekanismene for å utføre bakgrunnsjobber i fil- og klient-serverversjonene er forskjellige.

• I filversjonen må du opprette en dedikert klientprosess som vil utføre bakgrunnsjobber. For å gjøre dette må klientprosessen med jevne mellomrom kalle opp den globale kontekstfunksjonen ExecuteJobProcessing. Bare én klientprosess per infobase skal behandle bakgrunnsjobber (og følgelig kalle denne funksjonen). Hvis en klientprosess ikke er opprettet for å behandle bakgrunnsjobber, vil feilen "Job Manager er ikke aktiv" vises når du programmerer tilgang til jobbmotoren. Det anbefales ikke å bruke en klientprosess som behandler bakgrunnsjobber for andre funksjoner.

Når bakgrunnsjobber for klientprosessbehandling er startet, er andre klientprosesser i stand til å programmere tilgang til bakgrunnsjobbmotoren, dvs. kan kjøre og administrere bakgrunnsjobber.

I klient-serverversjonen brukes en oppgaveplanlegger for å utføre bakgrunnsjobber, som er fysisk plassert i klyngebehandlingen. For alle bakgrunnsjobber i kø får planleggeren den minst belastede arbeidsprosessen og bruker den til å kjøre den tilsvarende bakgrunnsjobben. Arbeidsprosessen utfører jobben og varsler planleggeren om utførelsesresultatene.

I klient-serverversjonen er det mulig å blokkere utførelse av rutineoppgaver. Utførelsen av rutineoppgaver er blokkert i følgende tilfeller:

• Det er installert en eksplisitt blokkering av rutineoppgaver på informasjonsbasen. Låsen kan stilles inn via klyngekonsollen;
• Det er en tilkoblingsblokk på infobasen. Låsen kan stilles inn via klyngekonsollen;
• SetExclusiveMode()-metoden med True-parameteren ble kalt fra det innebygde språket;
• I noen andre tilfeller (for eksempel ved oppdatering av databasekonfigurasjonen).

Opprette metadata for en rutineoppgave

Før du programmatisk oppretter en rutineoppgave i infobasen, må du opprette et metadataobjekt for den.

For å lage et metadataobjekt for en rutineoppgave i konfigurasjonstreet i grenen "Generelt" for grenen "Rutineoppgaver", utfør kommandoen "Legg til" og fyll inn følgende egenskaper for rutineoppgaven i egenskapspaletten:

Metodenavn - angi navnet på rutineoppgavemetoden.

Nøkkel - spesifiser en vilkårlig strengverdi som skal brukes som nøkkelen til den planlagte oppgaven.

Tidsplan - angir tidsplanen for rutineoppgaven. For å opprette en tidsplan, klikk på "Åpne"-koblingen og angi de nødvendige verdiene i tidsplanskjemaet som åpnes.

På fanen "Generelt" er start- og sluttdatoene for oppgaven og repetisjonsmodusen angitt.

På "Daglig"-fanen er den daglige tidsplanen for oppgaven angitt.

Spesifiser tidsplanen:

• starttid og sluttid for oppgaven;
• oppgavegjennomføringstid, hvoretter den vil bli tvangsavbrutt;
• oppgave repetisjon periode;
• varighet av pause mellom repetisjoner;
• utførelsesvarighet.

Det er tillatt å spesifisere en vilkårlig kombinasjon av betingelser.

På "Ukentlig"-fanen er den ukentlige tidsplanen for oppgaven angitt.

Merk av i avmerkingsboksene for ukedagene der oppgaven skal utføres. Hvis du vil gjenta oppgaven, spesifiser gjentakelsesintervallet i uker. For eksempel utføres oppgaven om 2 uker, gjentakelsesverdien er 2.

På fanen "Månedlig" er den månedlige planen for oppgaven angitt.

Merk av i avmerkingsboksene for månedene oppgaven skal utføres. Om nødvendig kan du spesifisere en spesifikk dag (måned eller uke) for utførelse fra begynnelsen av måneden/uken eller slutten.

Bruk - hvis angitt, vil oppgaven bli utført i henhold til tidsplanen.

Forhåndsdefinert - hvis angitt, er oppgaven en forhåndsdefinert oppgave.

Antall gjenforsøk ved unormal avslutning - angir antall gjenforsøk ved unormal avslutning.

Forsøksintervall ved unormal avslutning - spesifiserer gjenforsøksintervallet ved unormal avslutning. Eksempler

Opprette en bakgrunnsjobb "Fulltekstsøkeindeksoppdatering":

BackgroundTasks.Run("UpdatingFullTextSearchIndex");

Opprette en rutineoppgave "Gjenoppretting av sekvenser":

Schedule = Ny ScheduleTask; Schedule.PeriodRepeatDays = 1; Schedule.RepeatPeriodDuringDay = 0;

Task = RoutineTasks.CreateRoutineTask("Gjenopprette sekvenser"); Job.Schedule = Tidsplan; Oppgave.Skriv();

Jobbkonsoll

Behandler med ITS, administrerer rutineoppgaver:

Jobber med rutineoppgaver

Jobbobjekter

Jobbobjekter refereres ikke til, men lagres i databasen i en spesiell lagring.

Hvis "Forhåndsdefinert"-flagget er aktivert i metadataene, opprettes et slikt objekt automatisk når 1C:Enterprise startes og eksisterer alltid i nøyaktig én instans. Et slikt objekt kan ikke slettes.

Hvis "Forhåndsdefinert"-flagget ikke er satt, blir objekter for en slik oppgave opprettet og slettet programmatisk, og spesifiserer tidsplanen og parameterne.

Få en liste over oppgaver

Listen over oppgaver kan fås ved hjelp av metoden Få RutineTasks global jobbleder Rutineoppgaver

ScheduledJobs Manager

Få ScheduledJobs (GetScheduledJobs)

Syntaks:

Få rutineoppgaver(<Отбор>)

Parametere:

<Отбор>(valgfri)

Type: Struktur. Struktur som definerer utvalget. Strukturverdier kan være: UniqueIdentifier, Key, Metadata, Predefined, Usage, Name. Hvis valg ikke er spesifisert, innhentes alle rutineoppgaver.

Hvis du filtrerer etter metadata, kan du som metadataverdi spesifisere enten metadataobjektet til rutineoppgaven eller navnet.

Returverdi:

Type: Array.

Beskrivelse:

Mottar en rekke rutineoppgaver for et gitt utvalg. Å motta planlagte oppgaver er kun mulig for administratoren.

Tilgjengelighet:

Rutine = RutineTasks.GetRoutineTasks(Utvalg);

For hver rutine av rutinesyklus NewLine = Liste over rutineoppgaver.Add();

NewRow.Metadata = Regular.Metadata.View();<>NewLine.Name = Regular.Name;

NewString.Key = Regular.Key;

NewLine.Schedule = Schedule.Schedule;

NewLine.User = Regular.UserName;

NewString.Predefined = Vanlig.Forhåndsdefinert;

NewString.Use = Regular.Use;

NewString.Identifier = Regular.UniqueIdentifier;

LastTask = Regular.LastTask;

Hvis LastTask

Undefined Then NewRow.Running = LastTask.Start; NewRow.State = LastTask.State;

endIf; EndCycle;

Opprettelse

Beskrivelse:

Laget av Create RoutineTask-metoden for lederen av rutineoppgaver:

Tilgjengelighet:

RoutineTask = RutineTasks.CreateRoutineTask(MetadataSelection);

RegularTask.Name = Navn; RegularTask.Key = Nøkkel; RegularTask.Use = Bruk; RoutineTask.UserName = UsersSelection; RutineTask.Number ofRepetitionsAtEmergencyCompletion =AntallRepetisjonerAtEmergencyCompletion; ScheduledTask.RepeatIntervalAtEmergencyCompletion = Prøv på nyttIntervalAtEmergencyCompletion; ScheduleTask.Schedule = Tidsplan; RegularTask.Record();

TaskObject = RoutineTasks.CreateRoutineTask("ExchangeExchange");

TaskObject.Name = Navn; JobObject.Use = Sant;

Oppgaveobjektet har et "Parameters"-felt der metodeparameterne er spesifisert:

ScheduledTask.Delete();

Få et jobbobjekt

• liste via GetRoutineTasks-metoden:

Rutine = RutineTasks.GetRoutineTasks(Utvalg);

• via FindByUniqueIdentifier for oppgavebehandlingsmetoden:

Task = ScheduledTasks.FindByUniqueIdentifier(UID);

– Laster inn bankklassifisereren
Denne rutineoppgaven laster ned klassifiseringen av russiske banker fra RBC-nettstedet. Det vanlige arbeidet holder denne klassifiseringen oppdatert. Og når vi legger til en annen brukskonto, er det større sjanse for at banken den er åpnet i blir funnet av oss i BIC-klassifisereren.

Denne rutineoppgaven laster inn valutakurser for gjeldende dato. Hvis programmet utfører valutatransaksjoner, er det fornuftig å la denne oppgaven være aktivert slik at du ikke trenger å begynne å laste inn valutakurser manuelt hver gang.

– Fylle ut data for å begrense tilgangen

Denne rutineoppgaven utfører sekvensiell utfylling og oppdatering av dataene som er nødvendige for driften av "Access Control"-delsystemet i modusen for å begrense tilgangen på postnivå.

Når tilgangsbegrensningsmodus på rekordnivå er aktivert, fyller settene
tilgangsverdier. Fylling utføres i deler ved hver start til alt er
tilgangsverdisett vil ikke fylles ut.

Når du deaktiverer tilgangsbegrensningsmodus på rekordnivå, slettes sett med tilgangsverdier (tidligere fylt ut) når objekter overskrives, i stedet for alle på en gang.
Uavhengig av tilgangsbegrensningsmodus på postnivå, oppdaterer den cache-detaljene. Etter å ha fullført alle oppdateringer og fyllinger, deaktiverer bruken av den planlagte oppgaven.

Oppgaven er offisiell. Du trenger ikke å aktivere den manuelt.

– Tekstuttrekk

Brukes til raskt å søke etter data i vedlagte filer knyttet til en database. Hvis du bruker søk i vedlagte filer, er det fornuftig.

– Meldinger på tvers av arbeidsflytkontoer

Reguleringsoppgave for automatisk utveksling med tilsynsmyndigheter. Benyttes ved innsending av regulert rapportering direkte fra 1C.

– Oppdatering av enheter

Den planlagte oppgaven oppdaterer aggregater. Hva slags dyr er dette?

Ved å bruke aggregater kan du få betydelig raskere generering av rapporter om akkumuleringsregistre i tilfeller hvor antall poster i registeret er hundretusener, millioner eller mer.

Nøkkelfrasen her er "antall oppføringer i registeret er hundretusener, millioner eller mer," det vil si at for små registre, inkludert aggregater, ikke gir mening.

Aggregater lar deg lage forhåndsberegnet data for å generere rapporter som ligner summen av akkumuleringsregistre. Sistnevnte beregnes automatisk av plattformen (forutsatt at bruk av totaler for registeret er aktivert) i motsetning til aggregater. Men hvorfor trengs aggregater hvis resultatene utfører en lignende oppgave?

For det første beregnes totaler etter måned og dette kan ikke endres, mens aggregater kan beregnes etter dag, måned, kvartal, halvår og år.

For det andre kan seksjonene av aggregater være vilkårlige (en hvilken som helst sammensetning av målinger av akkumuleringsregisteret), i motsetning til totalene, som beregnes basert på hele registerets sammensetning.

– Oppdatering av veiledermonitordata

Rutineoppgaven fører til at dataene i informasjonsregisteret «Executive Monitor Data» oppdateres for alle organisasjoner. Hvis lederens monitor faktisk brukes, er oppgaven fornuftig.

– Oppdatere regnskapsføreroppgaver

Rutineoppgaven oppdaterer og fyller ut regnskapsførerens oppgaver (datoer for innsending av ulike erklæringer, rapporter osv.).

– PPD-indeksoppdatering

Oppdaterer søkeindeksen i full tekst. Hvis du bruker fulltekstsøk, gir oppgaven mening. Den slås på automatisk hvis fulltekstsøk er aktivert i databaseinnstillingene.

– Oppdatere informasjon om rapporteringsanvisninger

Vi snakker om veibeskrivelser: til trygdefondet, til den føderale skattetjenesten, til pensjonsfondet. Kort sagt, noe relatert, igjen, til innsending av elektronisk rapportering fra 1C.

– Behandling av abonnentsøknader for tilkobling av elektronisk signatur i tjenestemodellen

En slags serviceoppgave som behandler søknaden din om tilkobling av elektronisk signatur, dersom du bruker 1C i tjenestemodellen. Generelt bør du definitivt ikke aktivere det selv.

– Forsinketg

Jobben administrerer utførelsen av utsatte oppdateringsbehandlere. Ikke aktiver det selv.

– Sende abonnentrapporter

Sende regulerte rapporter fra tjenesteabonnenter til regulatoriske myndigheter gjennom SOS «Kaluga-Astral»-rapporteringstjeneste. Ikke aktiver det selv.

– Rydd opp i utdaterte versjoner av gjenstander

Kun for offisiell bruk.

– Ombygging av enheter

Ombygging av enheter for sirkulerende akkumuleringsregistre. Ikke aktiver det selv.

– Omberegning av gjeldende verdier av relative datoer for forbud mot endringer

Beregner og oppdaterer gjeldende relative verdier
forbudsdatoer fra gjeldende sesjonsdato. Ikke aktiver det selv.

– Planlegging av tekstuttak i tjenestemodellen

Definerer en liste over dataområder der tekstuttrekking er nødvendig, og planlegger utføringen for dem ved hjelp av en jobbkø. Offisiell.

– Motta resultatene av sending av rapporter

Motta resultatene av sending av rapporter fra tjenesteabonnenter til regulatoriske myndigheter fra SOS "Kaluga-Astral"-rapporteringstjenesten. Offisiell.

– Kontroll av motparter

For tjenestemodellen oppdaterer den statusen til motpartene (er alt OK med deres detaljer). For lokal modus, oppdaterer stater og poster som mangler skatteidentifikasjonsnummer og sjekkpunkt.

– Sammenslåing av PPD-indeksen

Utfører en sammenslåing av fulltekstsøkeindekser. Arbeidet med oppgaven er igjen knyttet til fulltekstsøk (hvor er søk uten indeks).

– Fjerne irrelevant synkroniseringsinformasjon

Utfører sletting av synkroniseringsinformasjon som ikke ble slettet på grunn av programfeil. Filer med en publiseringsdato på mer enn 24 timer kan slettes.

– Sletting av merkede programobjekter

Fjerner merkede objekter fra en planlagt oppgave.

– Innstilling av perioden for beregnede totaler

En serviceoppgave som fastsetter perioden med beregnede resultater. Resultatene ble skrevet ovenfor.