Při vývoji nebo úpravách aplikačních řešení na platformě 1C:Enterprise 8.x je velmi často nutné provést nějakou standardní akci pro skupinu konfiguračních objektů (například adresářů). Aby nedošlo k popisu akcí prováděných v modulu každého objektu, může vývojář použít standardní mechanismus platformy - předplatné událostí.
Odběry událostí vám umožňují zachytit události konfiguračních objektů, jako jsou adresáře, dokumenty, plány charakteristických typů a další. Dnes v článku zvážíme otázku posloupnosti provádění obslužných programů předplatného událostí a také analyzujeme chování platformy s několika předplatnými událostí pro jednu akci (například při nahrávání).
Standardní chování
Nechť náš příklad použije určitý adresář "SimpleDirectory". Pro každou událost má vytvořené předplatné událostí, do kterých může vývojář zasahovat. Procedury obsluhy událostí jsou umístěny v odpovídajícím společném modulu serveru.
Pořadí volání předplatitelských handlerů je stejné jako ve standardním chování platformy při práci s tímto objektem. Protože v našem příkladu uvažujeme o práci s adresářem, navrhuji zvážit schéma pro volání handlerů v závislosti na akcích s objektem (viz další snímek obrazovky).
Jak vidíme, v počáteční fázi jsou volány obslužné rutiny událostí „ProcessingFill“ (pro vytvoření nového prvku) nebo „On Copying“ (pro vytvoření prvku založeného na existujícím). V obou případech se po zavolání jmenovaných handlerů provede procedura „OnInstallNewCode“, kde může vývojář nastavit prefix v kódu nebo přepsat chování platformy při přiřazování nového kódu.
Při zápisu prvku adresáře, ať už nového prvku nebo existujícího, se nazývají tři handlery: „ProcessingFillCheck“ (v této fázi může handler zkontrolovat správnost zadaných dat a v případě chyb odmítnout zápis), „BeforeWrite“ (dokud není objekt zapsán do databáze, můžete upravit hodnoty podrobností a zkontrolovat případné další podmínky) a poté „OnRecord“ (do databáze byl proveden záznam, ale transakce není uzavřena , může vývojář po záznamu zkontrolovat data a v případě potřeby transakci zrušit).
K události "BeforeDelete" dojde pouze v případě, že je objekt přímo odstraněn z infobáze. Žádný uživatel obvykle nemá oprávnění k přímému odstranění bez kontroly referenční integrity. Mazání by mělo být vždy prováděno pomocí zpracování "Smazání označených objektů". V druhém případě je také volána obslužná rutina "BeforeDelete".
Pokud tedy vytvoříme položku adresáře a zapíšeme ji do infobáze, platforma zavolá následující obslužné rutiny událostí v určeném pořadí:
U ostatních konfiguračních objektů bude fungování mechanismu odběru událostí podobné, pouze události a jejich pořadí se mohou lišit. Další podrobnosti najdete v pomocníkovi syntaxe.
Strana bez dokumentů
Nyní se podívejme na zajímavou situaci. Řekněme, že pro náš adresář „SimpleDirectory“ jsou definována tři přihlášení k události „BeforeRecord“:
V jakém pořadí si myslíte, že budou voláni handleři těchto odběrů? Nehádejme. Výsledek nahrávání uvedu element, kde handler pro každý odběr zobrazí zprávu s názvem volaného odběru (viz následující screenshot).
Ze snímku obrazovky není těžké uhodnout, že pořadí volání procedur obsluhy předplatného události odpovídá pořadí objektů metadat ve větvi „Předplatné událostí“. Tato funkce není popsána v žádné referenční literatuře na platformě 1C:Enterprise, takže byste měli být opatrní při jejím používání v konfiguraci, protože nezdokumentované funkce se mohou z verze na verzi 1C:Enterprise změnit a zároveň v ní chybět. seznam změn programu.
Ústraní
Můžete se zeptat: "Proč vytvářet více odběrů pro jednu událost konfiguračního objektu?" Odpověď je jednoduchá. Pokud se na vývoji podílí několik lidí, může vzájemné zasahování do vytvořených mechanismů vést k nesprávnému fungování programu. V takových případech by nejlogičtější věcí bylo vytvořit samostatné odběry událostí pro každého vývojáře v souladu s daným úkolem. Samozřejmě je možné, že v budoucnu budou spojeny do jednoho handlerského postupu.
Tento článek je oznámením nové funkce.
Nedoporučuje se používat obsah tohoto článku k učení nových funkcí.
Úplný popis nové funkce bude uveden v dokumentaci k odpovídající verzi.
Úplný seznam změn v nové verzi je uveden v souboru v8Update.htm.
Implementováno ve verzi EDT 1.7.0.567.
V 1C:Enterprise Development Tools (EDT) jsme implementovali prototyp nového nástroje. Pracovní název tohoto nástroje je editor Všechny odběry událostí. Pomůže vám pohodlně analyzovat předplatné všech událostí, které v aplikačním řešení existují.
Předplatné na akce
Platforma 1C:Enterprise umožňuje vytvářet předplatné událostí konfiguračních objektů v aplikačním řešení. Předplatné je procedura, která bude provedena po provedení původní obsluhy události. Pohodlí předplatného spočívá ve skutečnosti, že jedna procedura může být „přihlášena“ k události patřící k různým konfiguračním objektům. Pokud tedy existuje algoritmus, který je třeba provést jak při záznamu organizace, tak při záznamu oddělení, může být umístěn v předplatném a pak ani nebudete muset měnit handlery pro tuto událost v samotných objektech.
Ukazuje se, že předplatné je pohodlný a univerzální mechanismus. Ale ve velkých aplikačních řešeních může počet předplatných událostí dosáhnout několika stovek. Je nepohodlné je analyzovat v konfiguračním stromu v lineárním seznamu. Například v aplikačním řešení 1C: Řízení podniku (ERP) více než 340 odběrů událostí.
EDT poněkud usnadňuje práci s předplatnými tím, že je zobrazuje na panelu Systém, když je otevřen modul aplikačního objektu.
Toto zobrazení odběrů je vhodné pro řadu úloh souvisejících s úpravou modulu. Ale stále to není vhodné, když potřebujete rychle najít a analyzovat všechny algoritmy, které se spouštějí v předplatných, když nastane určitá událost.
Všechny odběry událostí
Abychom se zbavili výše uvedených nepříjemností, implementovali jsme univerzální způsob reprezentace předplatných, událostí, konfiguračních objektů a procedur, ve kterých jsou implementovány předplatné algoritmy.
V důsledku toho můžete zavolat editorovi Všechny odběry událostí pro celou konfiguraci, nebo jen pro jeden objekt - rozdíl bude pouze ve složení dat, nějakým způsobem filtrovaných.
Na levé straně editor zobrazuje všechny události a u každé události všechny její odběry. Když vyberete konkrétní předplatné, vpravo nahoře se zobrazí seznam konfiguračních objektů, k jejichž událostem je předplatné „předplaceno“. A modul a postup, ve kterém se nachází algoritmus předplatného, jsou zobrazeny vpravo dole. Dvojitým kliknutím na proceduru ji můžete otevřít ve vestavěném jazykovém editoru.
V editoru můžete analyzovat nejen jednotlivé odběry, ale také všechny odběry související s jednou událostí. Pokud vyberete událost, editor zobrazí všechny moduly a všechny procedury podepsané pro zpracování této události.
Pokud zavoláte editor na konfigurační objekt, zobrazí se pouze události a odběry tohoto objektu a samotný objekt bude ve zdrojovém seznamu vždy zvýrazněn červeně. Tímto způsobem můžete například rychle zkontrolovat, že vámi zvolené předplatné funguje pro všechny konfigurační objekty, pro které je potřeba.
Volání editoru pomocí kontextového příkazu (na konfiguračním objektu) umožňuje okamžitě snížit počet odběrů zobrazených v editoru. Můžete například zobrazit odběry pouze pro ty události, které jsou zpracovány v modulu objektu nebo v modulu správce.
Editor navíc obsahuje univerzální filtr, pomocí kterého si složení objektů, událostí a procedur můžete libovolně přizpůsobit.
Všimněte si, že pomocí tohoto filtru můžete vybrat nejen konkrétní objekty, které jsou zdrojem událostí, ale také sady typů jako např DirectoryObject, DocumentObject a další. Takové sady typů zahrnují všechny adresáře nebo všechny dokumenty, které jsou v konfiguraci.
Vyhledáváním podle řetězce můžete rychle najít pouze ta předplatná, která se týkají mechanismu, který vás zajímá.
Obsah můžete kdykoli rychle filtrovat podle události nebo zdroje zobrazeného v editoru. Například jste našli předplatné Zkontrolujte vzorec výpočtu. Jeho zdrojem je plán typů výpočtů Drží.
Pomocí kontextového příkazu v plánu typů výpočtů můžete rychle zobrazit pouze ty odběry, které jsou přidruženy k jeho událostem.
Automatické přidávání bodů přerušení
Jedním z běžných způsobů analýzy odběrů událostí je postupné zobrazení všech volaných procedur v ladicím programu v pořadí, v jakém byly provedeny. K tomu poskytuje editor pohodlný nástroj pro automatické přidávání bodů přerušení do obslužných rutin.
V první řadě si tento nástroj můžete vyvolat přímo v editoru.
Můžete najít a vybrat objekt, který vás zajímá, vybrat jednu z jeho událostí a označit například všechny handlery. Po kliknutí OK body přerušení budou přidány do prvního spustitelného řádku každého zaškrtnutého handleru a všechny tyto body přerušení se objeví v panelu Body zlomu v perspektivě Ladění.
Další způsob, jak přidat body přerušení, je pohodlný, když jste již v editoru našli objekt nebo událost, která vás zajímá. V tomto případě můžete příkaz, který vám vyhovuje, zavolat z kontextové nabídky.
A konečně třetí způsob, který můžete použít, je automatické přidávání bodů přerušení během ladění. V tomto případě nemusíte otevírat editor, protože příkaz add je přímo v panelu Body zlomu.
Takže redaktor Všechny odběry událostí je univerzální nástroj, který vám umožňuje používat různé scénáře analýzy. Bude se hodit nejen vývojářům, kteří dobře znají aplikační řešení, ale také implementačním specialistům nebo IT specialistům, kteří potřebují porozumět neznámé funkcionalitě.
V průběhu řešení různých uživatelských problémů je někdy nutné podrobit již vygenerované pohyby dokumentů (zejména určité sady registrů) nějaké úpravě.
Pro tyto účely je velmi vhodný objekt „Předplatné události“, který umožňuje provádět některé akce při výskytu určité události pro velké množství objektů (například při evidenci platebních dokladů nebo při nastavení nového čísla u adresářů souvisejících s daní účetnictví).
Přihlášení k odběru události je také pohodlné, protože vám umožňuje provádět různé akce, aniž byste měnili standardní mechanismy popsané v různých modulech.
Například vznikl úkol - je nutné zaznamenat určitá data (informace o činnosti společnosti) v platebních dokladech po vytvoření hlavních pohybů dokladu (vygenerovaných v události „Zpracování zpracování“). Úlohu implementujeme pomocí konfigurace „Manufacturing Enterprise Management“, ed. 1.3.
Podívejme se na řešení podrobněji:
Vytvořme nové předplatné události „Zaznamenejte pokyny k platbám“. Předplatné má řadu vlastností, které určují jeho chování:
Zdroj- jedná se o objekt (například dokument nebo seznam dokumentů), pro který budou vyvolány akce. Pro náš případ vybereme Platební příkaz odchozí a Platební příkaz příchozí
Události- samotná akce, po které se náš kód spustí. Podle podmínek problému volíme ZpracováníProvádění
Psovod- údaj o postupu, kterým bude zpracování probíhat. Zvolme pro tyto účely obecný modul Obecný účel.
Po výše uvedených cílech je vytvořena procedura, ve které je nutné umístit kód pro vyplnění údajů o směru (za předpokladu, že takové informace jsou již obsaženy v platbách).
Podívejme se na jeho parametry:
Zdroj- tento objekt typu DirectoryObject nebo DocumentObject, pro který se akce provádí.
Zamítnutí- parametr, který umožňuje za určitých podmínek zrušit zaúčtování dokladu.
Režim- možnosti implementace (operativní nebo neoperativní), které vám umožňují vytvářet algoritmy zpracování různými způsoby.
Zaměřme se na parametr Zdroj. Pro naši úlohu bude typ tohoto parametru - DocumentObject. Pro tento typ je k dispozici kolekce Pohyby, který obsahuje všechny soubory rejstříkových záznamů, pro které je tento dokument zapisovatelem.
Tato kolekce obsahuje sadu záznamů Vypořádání účtů s protistranami, která nás zajímá. Předpokládejme, že v registru byla vytvořena dimenze Směr, kterou potřebujeme z dokumentu vyplnit.
Napíšeme následující kód:
Sady = Zdroj. Pohyby; Výpočty = sady. Vyrovnání s protistranami; Pro každou stránku výpočtů cyklujte stránku. Směr = Zdroj. Směr; EndIf;
Jak vidíme, implementace je po zpracování vcelku jednoduchá, není potřeba provádět žádnou další akci pro záznam sady - přihlášení k události se provádí v rámci transakce události ProcessingProcessing, po jejím dokončení se sada automaticky zapíše; .
Výhody tohoto přístupu: zpracování dat mimo standardní algoritmy, snížení množství práce při vyhledávání a přenosu změn při aktualizaci, větší viditelnost - veškerý kód v jedné proceduře.
Nevýhoda tohoto přístupu: zvýšení času stráveného vedením dokumentů a záznamem prvků adresářů.
Doufám, že tyto informace budou užitečné jak začínajícím programátorům, tak jejich zkušenějším kolegům jako způsob, jak si rozšířit obzory.
Když uživatel provede nějakou akci, platforma 1C generuje programové události. Zpravidla se negeneruje jedna událost, ale celý řetězec událostí. Úkolem programátora je správně umístit kód programu do událostí tak, aby bylo dosaženo očekávaného chování od programu. To však nebude snadné pro začínajícího programátora 1C, a to z důvodů uvedených níže.
Události lze generovat v řízené podobě: On ReadingOnServer, OnCreatingOnServer, OnOpening atd.
Události v řízené podobě jsou generovány na klientovi a na serveru: BeforeRecord, BeforeRecordOnServer.
Události jsou volány v různých modulech: ElementForm, ObjectModule, ManagerModule.
Některé události lze volat vícekrát, pokud je v seznamu několik prvků adresáře, například: ReceivingViewProcessing.
Spravovaný formulář lze otevřít v důsledku různých akcí uživatele a řetězce volání událostí se budou lišit. Libovolná z následujících akcí uživatele s adresářem otevře řízený formulář: vytvoření nového prvku, zkopírování prvku, změna existujícího prvku adresáře.
Události jsou také generovány formulářovými prvky: při přidávání řádku do tabulkové části, při úpravě řádku v tabulkové části, při aktivaci řádku nebo pole, při výběru vyhledávací položky ve vstupním poli atd.
Chcete-li lépe porozumět logice a posloupnosti spouštěných událostí, můžete použít vývoj „Studie událostí“ přiložený k tomuto článku. Když budete znát kontext volání události, posloupnost událostí a akce, které uživatel provede, bude snazší pochopit, do které obslužné rutiny události je nejlepší umístit váš programový kód.
Pokyny pro používání programu Event Study
Program Event Study ukazuje události, které platforma 1C generuje během interaktivních uživatelských akcí. Princip fungování je následující: uživatel otevře adresář, program zobrazí řetězec událostí. Uživatel označí položku adresáře ke smazání a program zobrazí sled událostí, které nastanou. Události se standardně zobrazují s mírným zpožděním 3 sekund, je to nutné k oddělení jednoho řetězce událostí od jiného řetězce událostí. Proto musíte interaktivní akce provádět „ve volném čase“.
Všechny události se zobrazují ve speciálním okně „Nejnovější události“. Zde můžete povolit nebo zakázat nahrávání událostí. Ve výchozím nastavení je nahrávání událostí povoleno při prvním otevření. Doporučuji připnout okno „Nejnovější události“ do spodní části obrazovky ihned po spuštění programu, aby bylo možné události snadno sledovat.
Program sám nedokáže určit, jaká akce způsobila řetězec událostí. Doporučuji vám zadat do pole „Příčina akce“ názvy vašich posledních akcí, například „Formulář seznamu adresářů je otevřený“, „Prvek v adresáři; seznam je označen ke smazání“ atd. To pak usnadní analýzu akcí a událostí.
Události se zaznamenávají a zobrazují pro objekty umístěné v sekci Trasa událostí za předpokladu, že je ve formuláři Nedávné události povoleno nahrávání událostí.
Všechny zaznamenané události lze zobrazit prostřednictvím „Hlášení událostí“, které se nachází v sekci „Servis“.
Chcete-li rychle vymazat všechny zaznamenané akce a události, v části „Služba“ vyberte „Vymazat události a akce“.
Při práci s informační základnou 1C je často nutné propojit nový algoritmus s událostí spojenou se změnou objektu. Ve verzi 7 programu bylo pro spuštění handleru nutné přepsat zdrojový kód programu, což vedlo k problémům při aktualizaci konfigurace.
Po analýze zpětné vazby od uživatelů těchto osm vývojářů implementovalo nový objekt nazvaný „Event Subscription“. V tomto článku se pokusíme odhalit:
- Nastavení předplatného;
- Stvoření;
- Vlastnosti fungování.
Vytvořte nové předplatné
Stejně jako jakýkoli jiný objekt metadat se předplatné události v 1C přidává z konfigurátoru.
Tyto prvky jsou umístěny ve větvi stromu „Obecné“ (obr. 1).
Chcete-li přidat nový obslužný nástroj, musíte:
Obr.3
Abyste předešli problémům s aktualizací, pro vlastní vývoj je nejlepší vytvořit si vlastní společný modul, který bude obsahovat pouze vaše postupy a funkce.
Vlastnosti fungování předplatného
Jednou z hlavních otázek, které vyvstávají pro uživatele, kteří začínají pracovat s objektem „Event Subscription“, je otázka pořadí, ve kterém jsou procedury volány. Často v tom spočívají chyby kvůli skutečnosti, že postup nefunguje nebo funguje jen jednou za čas.
Na příkladu procedury AtWrite() pro libovolný dokument můžete vidět pořadí, ve kterém jsou volány handlery.
Pokud tedy v modulu objektu dokumentu tato procedura existuje a paralelně s ní probíhá zpracování volané z předplatného a zpracování stejné události, bude nejprve zpracován modul dokumentu. Pokud během provádění AtRecord() v modulu dokumentu nabude parametr Rejection z nějakého důvodu hodnotu True, je zaručeno, že předplatné nebude fungovat.
V případě, že existuje několik objektů odběru, které jsou stejné pro jeden zdroj a jednu událost, je velmi obtížné sledovat pořadí provádění. A pokud je během provádění alespoň jednoho handleru vyvolána výjimka, některé procedury zůstanou neprovedené.
Posloupnost zpracování tedy může být specifikována takto:
- Události modulu objektu jsou zpracovány;
- Zpracovávají se předplatná spojená přímo s aktuálním datovým typem;
- Kód vázaný na obecný typ se zpracovává.
Je velmi důležité si pamatovat, že v žádném případě byste do procedur prováděných během nahrávání neměli vkládat kód, který mění data zdrojového objektu, protože to může vést ke zbytečnému zacyklení. Je lepší použít takový kód v procedurách BeforeWrite.
Obslužná rutina události otevřeného formuláře
Rostoucí obliba spravovaných formulářů používaných ve verzi 8 programu a také problémy spojené s aktualizací těchto objektů při ukládání vlastních změn vedly k tomu, že počínaje platformou 8.2.15 se v programu objevila událost FormReceivingProcessing. Zde můžete vložit kód, který mění a nahrazuje standardní formuláře.
Některé funkce tohoto ovladače:
- Událost se nespustí, pokud je v konfiguraci přesně specifikován standardní formulář, který se má otevřít;
- Událost lze implementovat pouze pro spravované formuláře;
- Obecný modul obsahující tento handler musí mít nejen atribut „Server“, ale také obsahovat zaškrtnuté políčko v poli „Call Server“.
Je důležité vzít v úvahu, že toto předplatné není voláno pro konkrétní objekt, ale pro jeho správce, to znamená, že zdrojové pole musí obsahovat toto slovo (obr. 4).
Obr.4
Abych to shrnul výše, rád bych řekl, že „Event Subscription“ je pro vývojáře nesmírně užitečný a nezbytný nástroj, který vývojáři umožňuje dosáhnout jeho vlastních cílů a záměrů bez větších zásahů do konfigurace.
