Kas ir notikumu apstrādātājs 1s. Visi pasākumu abonementi. Pasākuma "Ievietojot" abonēšana dokumentu

Šis raksts ir paziņojums par jaunu funkcionalitāti.
Nav ieteicams izmantot šī raksta saturu, lai apgūtu jaunas funkcijas.
Pilns jaunās funkcionalitātes apraksts tiks sniegts attiecīgās versijas dokumentācijā.
Pilns jaunās versijas izmaiņu saraksts ir sniegts failā v8Update.htm.

Ieviests EDT versijā 1.7.0.567.

Programmā 1C:Enterprise Development Tools (EDT) esam ieviesuši jauna rīka prototipu. Šī rīka darba nosaukums ir redaktors Visi pasākumu abonementi. Tas palīdzēs ērti analizēt visu lietojumprogrammas risinājumā esošo notikumu abonementus.

Pasākumu abonementi

Platforma 1C:Enterprise ļauj lietojumprogrammas risinājumā izveidot abonementus uz konfigurācijas objektu notikumiem. Abonēšana ir procedūra, kas tiks izpildīta pēc sākotnējā notikumu apstrādātāja izpildes. Abonēšanas ērtības slēpjas tajā, ka vienu procedūru var “abonēt” notikumam, kas pieder dažādiem konfigurācijas objektiem. Tādējādi, ja ir algoritms, kas jāizpilda gan ierakstot organizāciju, gan ierakstot nodaļu, tas var atrasties abonementā, un tad pat nevajadzēs mainīt šī notikuma apstrādātājus pašos objektos.

Izrādās, ka abonēšana ir ērts un universāls mehānisms. Bet lielos aplikāciju risinājumos pasākumu abonementu skaits var sasniegt vairākus simtus. Kļūst neērti tos analizēt konfigurācijas kokā lineārā sarakstā. Piemēram, lietojumprogrammas risinājumā 1C: uzņēmuma vadība (ERP) vairāk nekā 340 pasākumu abonementi.

EDT atvieglo darbu ar abonementiem, parādot tos panelī Shēma, kad tiek atvērts kāda lietojumprogrammas objekta modulis.

Šis abonementu displejs ir ērts vairākiem uzdevumiem, kas saistīti ar moduļa rediģēšanu. Bet tas joprojām nav piemērots, ja jums ātri jāatrod un jāanalizē visi algoritmi, kas tiek izpildīti abonementos, kad notiek konkrēts notikums.

Visi pasākumu abonementi

Lai atbrīvotos no iepriekš uzskaitītajām neērtībām, esam ieviesuši universālu veidu, kā attēlot abonementus, notikumus, konfigurācijas objektus un procedūras, kurās tiek īstenoti abonēšanas algoritmi.

Rezultātā varat piezvanīt redaktoram Visi pasākumu abonementi visai konfigurācijai vai tikai vienam objektam - atšķirība būs tikai datu sastāvā, kaut kādā veidā filtrēti.

Kreisajā pusē redaktors parāda visus notikumus un katrā pasākumā visus tā abonementus. Atlasot konkrētu abonementu, augšējā labajā stūrī tiek parādīts to konfigurācijas objektu saraksts, kuru notikumiem abonements ir “abonēts”. Un modulis un procedūra, kurā atrodas abonēšanas algoritms, ir parādīti apakšējā labajā stūrī. Veicot dubultklikšķi uz procedūras, varat to atvērt iebūvētajā valodas redaktorā.

Atrodoties redaktorā, varat analizēt ne tikai atsevišķus abonementus, bet arī visus abonementus, kas saistīti ar vienu notikumu. Ja atlasāt notikumu, redaktors parādīs visus moduļus un visas procedūras, kas parakstītas šī notikuma apstrādei.

Ja izsaucat konfigurācijas objekta redaktoru, tiks parādīti tikai šī objekta notikumi un abonementi, un pats objekts avota sarakstā vienmēr tiks iezīmēts sarkanā krāsā. Tādā veidā jūs varat ātri pārbaudīt, piemēram, vai jūsu izvēlētais abonements darbojas visiem konfigurācijas objektiem, kuriem tas ir nepieciešams.

Redaktora izsaukšana, izmantojot konteksta komandu (konfigurācijas objektā), ļauj nekavējoties samazināt redaktorā parādīto abonementu skaitu. Piemēram, varat skatīt abonementus tikai tiem notikumiem, kas tiek apstrādāti objekta modulī vai pārvaldnieka modulī.

Turklāt redaktorā ir universāls filtrs, ar kuru jūs varat jebkurā veidā pielāgot objektu, notikumu un procedūru sastāvu.

Ņemiet vērā, ka ar šo filtru jūs varat atlasīt ne tikai konkrētus objektus, kas ir notikumu avots, bet arī veidu kopas, piemēram, DirectoryObject, DocumentObject un citi. Šādas tipu kopas ietver visus direktorijus vai visus dokumentus, kas atrodas konfigurācijā.

Meklējot pēc virknes, varat ātri atrast tikai tos abonementus, kas attiecas uz jūs interesējošo mehānismu.

Jebkurā laikā varat ātri filtrēt saturu pēc redaktorā parādītā notikuma vai avota. Piemēram, jūs atradāt abonementu Pārbaudiet aprēķina formulu. Tās avots ir aprēķinu veidu plāns Notur.

Izmantojot konteksta komandu aprēķinu veidu plānā, varat ātri redzēt tikai tos abonementus, kas ir saistīti ar tā notikumiem.

Automātiski pievienojot pārtraukuma punktus

Viens no izplatītākajiem veidiem, kā analizēt notikumu abonementus, ir secīgi skatīt visas izsauktās procedūras atkļūdotājs tādā secībā, kādā tās tika izpildītas. Lai to izdarītu, redaktors nodrošina ērtu rīku automātiskai pārtraukuma punktu pievienošanai apstrādātājiem.

Pirmkārt, jūs varat izsaukt šo rīku tieši redaktorā.

Jūs varat atrast un atlasīt jūs interesējošo objektu, atlasīt vienu no tā notikumiem un atzīmēt, piemēram, visus apstrādātājus. Pēc noklikšķināšanas labi pārtraukuma punkti tiks pievienoti katra pārbaudītā apstrādātāja pirmajai izpildāmajai rindai, un visi šie pārtraukuma punkti tiks parādīti panelī Pārtraukuma punkti perspektīvā Atkļūdošana.

Vēl viens veids, kā pievienot pārtraukuma punktus, ir ērts, ja jūs interesējošo objektu vai notikumu jau esat atradis redaktorā. Šajā gadījumā no konteksta izvēlnes varat izsaukt sev piemēroto komandu.

Visbeidzot, trešais veids, ko varat izmantot, ir automātiski pievienot pārtraukuma punktus atkļūdošanas laikā. Šajā gadījumā jums nav jāatver redaktors, jo pievienošanas komanda atrodas tieši panelī Pārtraukuma punkti.

Tātad redaktors Visi pasākumu abonementi ir universāls rīks, kas ļauj izmantot dažādus analīzes scenārijus. Tas noderēs ne tikai izstrādātājiem, kuri labi pārzina aplikācijas risinājumu, bet arī ieviešanas speciālistiem vai IT speciālistiem, kuriem ir jāizprot nepazīstama funkcionalitāte.

Kad lietotājs veic kādas darbības, 1C platforma ģenerē programmas notikumus. Parasti tiek ģenerēts nevis viens notikums, bet visa notikumu ķēde. Programmētāja uzdevums ir pareizi ievietot programmas kodu notikumos, lai sasniegtu gaidīto uzvedību no programmas. Tomēr iesācējam 1C programmētājam to nebūs viegli izdarīt tālāk uzskaitīto iemeslu dēļ.

Notikumus var ģenerēt kontrolētā formā: vietnē ReadingOnServer, OnCreatingOnServer, OnOpening utt.

Notikumi kontrolētā formā tiek ģenerēti klientā un serverī: BeforeRecord, BeforeRecordOnServer.

Notikumi tiek izsaukti dažādos moduļos: ElementForm, ObjectModule, ManagerModule.

Dažus notikumus var izsaukt vairākas reizes, ja sarakstā ir vairāki direktoriju elementi, piemēram: ProcessingGetView.

Pārvaldīto formu var atvērt dažādu lietotāja darbību rezultātā, un notikumu izsaukumu ķēdes atšķirsies. Jebkura no šīm lietotāja darbībām ar direktoriju atvērs kontrolētu formu: jauna elementa izveide, elementa kopēšana, esošā direktorija elementa maiņa.

Notikumus ģenerē arī formas elementi: pievienojot rindu tabulas daļai, rediģējot rindu tabulas daļā, aktivizējot rindu vai lauku, izvēloties uzmeklēšanas vienumu ievades laukā utt.

Lai labāk izprastu aktivizēto notikumu loģiku un secību, varat izmantot šim rakstam pievienoto izstrādi “Notikumu izpēte”. Zinot notikuma izsaukuma kontekstu, notikumu secību un darbības, ko lietotājs veiks, būs vieglāk saprast, kurā notikumu apdarinātājā vislabāk ievietot programmas kodu.

Programmas Event Study lietošanas instrukcija

Programma Event Study parāda notikumus, ko 1C platforma ģenerē interaktīvu lietotāja darbību laikā. Darbības princips ir šāds: lietotājs atver direktoriju, programma parāda notikumu ķēdi. Lietotājs atzīmē direktorija vienumu dzēšanai, un programma parāda notiekošo notikumu secību. Pēc noklusējuma notikumi tiek parādīti ar nelielu 3 sekunžu aizkavi, tas ir nepieciešams, lai nodalītu vienu notikumu ķēdi no citas notikumu ķēdes. Tāpēc interaktīvas darbības jāveic “lēnām”.

Visi notikumi tiek parādīti īpašā logā “Jaunākie notikumi”. Šeit varat iespējot vai atspējot notikumu ierakstīšanu. Pēc noklusējuma notikumu ierakstīšana ir iespējota, pirmo reizi atverot. Iesaku uzreiz, startējot programmu, piespraust logu “Jaunākie notikumi” ekrāna apakšā, lai ērti skatītos notikumus.

Programma pati nevar noteikt, kāda darbība izraisīja notikumu ķēdi; iesaku laukā “Darbības cēlonis” ierakstīt pēdējo darbību nosaukumus, piemēram, “Direkciju saraksta forma ir atvērta”, “Elements direktorijā saraksts ir atzīmēts dzēšanai” utt. Tādējādi būs vieglāk analizēt darbības un notikumus.

Notikumi tiek ierakstīti un parādīti objektiem, kas ievietoti sadaļā "Notikumu izsekošana", ja formā "Pēdējie notikumi" ir iespējota notikumu ierakstīšana.

Visus ierakstītos notikumus var apskatīt, izmantojot “Notikumu atskaiti”, kas atrodas sadaļā “Pakalpojums”.

Lai ātri notīrītu visas ierakstītās darbības un notikumus, sadaļā “Pakalpojums” atlasiet “Notīrīt notikumus un darbības”.

Abonēšana notikumam 1C 8.3 un 8.2 ir konfigurācijas objekts, kas ļauj piešķirt apdarinātāju noteiktam objekta notikumam. Šāds apstrādātājs var tikt piešķirts vairākiem konfigurācijas objektiem vienlaikus, piemēram, visiem dokumentiem vienlaikus.

Apskatīsim šo metadatu objektu tuvāk.

• Instalējot jaunu numuru
• Kopēšanas laikā
• ApstrādeAizpildīšana
• Pirms Ierakstīšanas
• Kad Ieraksts
• Pirms dzēšanas
• ApstrādeVadīšana
• ApstrādeNoņemšanaVeikšana
• ApstrādePārbaudeAizpildīšana

Jūs varat abonēt notikumu tikai uz objekta, nevis uz veidlapas.

Zvanu apstrādātāju secība 1C 8

Notikumu abonēšanas apstrādātāji tiek izsaukti pēc objektu apstrādātāja, t.i. ja notikuma abonementam ir iestatīts notikums “ProcessingProcessing”, vispirms tiks palaists objekta moduļa apdarinātājs un pēc tam abonementa apdarinātājs.

Saņemiet 267 video nodarbības 1C bez maksas:

Ja vienam pasākumam ir vairāki abonementi, tad, spriežot pēc pieredzes, pirmais tiek izsaukts abonements, kurš konfigurācijas kokā atrodas augstāk. Lai gan pati 1C kompānija ziņo, ka šī prioritāte nav noteikta.

Pasākumu abonementu izmantošana 1C

Abonementu izmantošana ir ļoti ērta, piemēram, lai reģistrētu izmaiņas . Vai kāda cita darbība, kas ir vienāda dažādiem konfigurācijas objektiem.

Es bieži izmantoju pasākumu abonementus, lai nemainītu standartu. Tas ir ļoti ērti, piemēram, abonementā varam pielāgot dokumentu kustības vai pievienot kustības jauniem reģistriem, nemainot konfigurāciju.

Pasākuma abonementa iestatīšana

Abonementa iestatīšana ir ļoti vienkārša:

• Avots— datu tipi, kuriem ir instalēts apstrādātājs;
• Pasākums— notikums, kuram ir uzstādīts apdarinātājs;
• Apdarinātājs— norāda procedūru, no kuras tiks atrasts notikumu apstrādātājs.

Izstrādājot vai modificējot lietojumprogrammu risinājumus platformā 1C:Enterprise 8.x, ļoti bieži ir nepieciešams veikt kādu standarta darbību konfigurācijas objektu grupai (piemēram, direktorijiem). Lai netiktu aprakstītas katra objekta modulī veiktās darbības, izstrādātājs var izmantot standarta platformas mehānismu – notikumu abonēšanu.

Pasākumu abonementi ļauj pārtvert konfigurācijas objektu notikumus, piemēram, direktorijus, dokumentus, raksturīgu tipu plānus un citus. Šodien rakstā mēs apskatīsim jautājumu par notikumu abonēšanas apstrādātāju izpildes secību, kā arī analizēsim platformas uzvedību ar vairākiem notikumu abonementiem vienai darbībai (piemēram, ierakstot).

Standarta uzvedība

Ļaujiet mūsu piemērā izmantot noteiktu direktoriju "SimpleDirectory". Tam ir izveidoti notikumu abonementi katram notikumam, kurā izstrādātājs var iejaukties. Notikumu apstrādātāja procedūras atrodas attiecīgajā servera kopējā modulī.

Abonēšanas apstrādātāju izsaukšanas secība ir tāda pati kā platformas standarta darbībā, strādājot ar šo objektu. Tā kā mūsu piemērā mēs apsveram darbu ar direktoriju, es ierosinu apsvērt apdarinātāju izsaukšanas shēmu atkarībā no darbībām ar objektu (skatiet nākamo ekrānuzņēmumu).

Kā redzam, sākotnējā posmā notikumu apstrādātāji tiek izsaukti “ProcessingFill” (lai izveidotu jaunu elementu) vai “On Copying” (lai izveidotu elementu, pamatojoties uz esošu). Abos gadījumos pēc nosaukto apstrādātāju izsaukšanas tiek izpildīta procedūra "OnInstallNewCode", kur izstrādātājs var iestatīt kodā prefiksu vai ignorēt platformas uzvedību, piešķirot jaunu kodu.

Rakstot direktorija elementu, neatkarīgi no tā, vai tas ir jauns vai esošs elements, tiek izsaukti trīs apdarinātāji: “ProcessingFillCheck” (šajā posmā apdarinātājs var pārbaudīt ievadīto datu pareizību un kļūdu gadījumā atteikties rakstīt), “BeforeWrite” (kamēr objekts nav ierakstīts datu bāzē, var pielāgot detaļu vērtības un pārbaudīt jebkādus papildu nosacījumus) un pēc tam “OnRecord” (datubāzē ir veikts ieraksts, bet darījums netiek slēgts , izstrādātājs pēc ierakstīšanas var pārbaudīt datus un, ja nepieciešams, atcelt darījumu).

Notikums "BeforeDelete" notiek tikai tad, ja objekts tiek tieši izdzēsts no informācijas bāzes. Parasti nevienam lietotājam nav atļaujas dzēst tieši, nepārbaudot atsauces integritāti. Dzēšana vienmēr jāveic, izmantojot apstrādi "Atzīmēto objektu dzēšana". Pēdējā gadījumā tiek izsaukts arī apstrādātājs "BeforeDelete".

Tādējādi, ja izveidosim direktorija vienumu un ierakstīsim to informācijas bāzē, platforma norādītajā secībā izsauks šādus notikumu apstrādātājus:

Attiecībā uz citiem konfigurācijas objektiem notikumu abonēšanas mehānisma darbība būs līdzīga, var atšķirties tikai pasākumi un to secība. Plašāku informāciju skatiet sintakses palīgā.

Nedokumentētā puse

Tagad apskatīsim interesantu situāciju. Pieņemsim, ka mūsu direktorijā "SimpleDirectory" ir definēti trīs notikuma "BeforeRecord" abonementi:

Kādā secībā, jūsuprāt, tiks izsaukti šo abonementu apstrādātāji? Nedomāsim. Es sniegšu elementa ierakstīšanas rezultātu, kurā katra abonementa apstrādātājs parāda ziņojumu ar izsauktā abonementa nosaukumu (skatiet nākamo ekrānuzņēmumu).

No ekrānuzņēmuma nav grūti uzminēt, ka notikumu abonēšanas apstrādātāja procedūru izsaukšanas secība atbilst metadatu objektu secībai zarā “Notikumu abonementi”. Šī funkcija nav aprakstīta nevienā atsauces literatūrā par platformu 1C:Enterprise, tāpēc, izmantojot to konfigurācijā, jums jābūt uzmanīgiem, jo ​​nedokumentēti līdzekļi var mainīties dažādās 1C: Enterprise versijas versijās un tajā pašā laikā tās nebūt programmas izmaiņu saraksts.

Atkāpties

Varat jautāt: "Kāpēc vienam konfigurācijas objekta notikumam izveidot vairākus abonementus?" Atbilde ir vienkārša. Ja izstrādē ir iesaistīti vairāki cilvēki, tad iejaukšanās viens otra radītajos mehānismos var novest pie nepareizas programmas darbības. Šādos gadījumos visloģiskāk būtu izveidot katram izstrādātājam atsevišķus pasākumu abonementus atbilstoši veicamajam uzdevumam. Protams, ir iespējams, ka nākotnē tie tiks apvienoti vienā hendlera procedūrā.

Kad lietotājs noklikšķina uz pogas, tiek atvērta vai aizvērta forma, tiek uzrakstīts dokuments, notiek notikums.

Pirms katra dokumenta ierakstīšanas vēlamies pārbaudīt, vai šī informācija ir aizpildīta.

Kā to izdarīt?

1C pasākumu abonementi

1C notikumu abonements ir , tas atrodas sadaļā Vispārīgi/1C notikumu abonementi.

Abonēšana 1C notikumam ļauj piešķirt apdarinātāju, kad notikums notiek vairākiem objektiem (direktorijiem, dokumentiem).

Pievienosim 1C pasākumam jaunu abonementu un iestatīsim nosaukumu.

1C pasākuma abonēšanas rekvizītā Avots - jums ir jāatlasa viens vai vairāki dokumenti, direktoriji - objekti, uz kuriem mēs ievietojam apstrādātāju.

Īpašumā 1C Event abonēšana ir jāatlasa viena no opcijām standarta notikumiem, kas var notikt ar atlasītajiem dokumentiem un direktorijiem.

Mēs vienkāršojam, sakot “dokumenti un uzziņu grāmatas” - patiesībā jūs varat izmantot daudzus 1C objektus. Diemžēl jūs nevarat abonēt 1C veidlapas pasākumus - piemēram, atverot veidlapu, ko daudzi programmētāji nožēlo.

Iespējamo notikumu kopums ir atkarīgs no objekta. Esiet uzmanīgi, jo, atlasot vairākus (vairākus) objektus, notikumu sarakstā būs tikai tie notikumi, kas var būt katrā no atlasītajiem objektiem (tas ir, notikumi, kas ir kopīgi visiem atlasītajiem objektiem).

Pēc tam atliek tikai izveidot apdarinātāja funkciju. Lai to izdarītu, konfigurācijas rekvizītos ir jāatzīmē izvēles rūtiņa Serveris. Noklikšķinot uz pogas “lupa”, tiks izveidota funkcija - apdarinātājs.

Visi! Mēs tikko esam abonējuši visu dokumentu pasākumu 1C BeforeRecording. Tagad, ierakstot jebkuru dokumentu, tiks izpildīta mūsu funkcija, kas ietver pārbaudi.

Lai atteiktos rakstīt dokumentu, ja čeks ir negatīvs, jāiestata funkcijas parametrs