1s 8 jak získat jméno předem určeného. Pravidelné a předdefinované prvky. Rozdíl je na straně databáze. Nesprávná specifikace předdefinovaného prvku

Každý zná rozdíl mezi předdefinovanými prvky a běžnými prvky: „Předdefinované prvky se vytvářejí v režimu Konfigurátor a nelze je smazat v režimu 1C:Enterprise.“ V uživatelském režimu můžete pomocí speciální ikony odlišit předdefinovaný prvek od prvků přidaných uživateli (viz následující snímek obrazovky).

V podstatě jsou předdefinované prvky vytvářeny vývojáři, aby k nim navázali algoritmy v různých konfiguračních objektech. Například v konfiguraci „Manufacturing Enterprise Management“ v adresáři „Quality“ přidali vývojáři předdefinovaný prvek „New“.

Tento prvek se používá v mnoha konfiguračních modulech. Takže v dokladu „Příjem zboží a služeb“ při účtování ve všech evidencích, kde je dimenze „Kvalita“, se dosadí hodnota předdefinovaného prvku. Níže je uveden seznam vyplnění tabulky účtování pro rejstřík „Zboží organizací“:

Vlastnosti předdefinovaných prvků a jejich účel jsou tedy poměrně jednoduché. Podívejme se na způsob jejich uložení v databázových tabulkách a jak se liší od běžných prvků.

Rozdíly

V testovací konfiguraci byl vytvořen adresář "Produkty". V něm byla vytvořena skupina "Testovací prvky". Obsah skupiny jste mohli vidět na screenshotu na začátku článku. Pro adresář "Produkty" má databáze SQL odpovídající tabulku "_Reference37" s následující strukturou:

Jak ale zjistíme, zda podrobnosti odpovídají konfiguračnímu stromu a polím v tabulce SQL?

Použijeme standardní globální kontextovou metodu „GetDatabaseStorageStructure()“, která nám vrátí tabulku hodnot s popisem struktury tabulky.

V tabulce hodnot "Pole" vidíme shodu mezi poli tabulky SQL a podrobnostmi o objektu ve stromu metadat. V našem příkladu uvažujeme strukturu adresáře „Produkty“. Všechny adresáře mají standardní atribut "Predefined" typu Boolean, který je pro předdefinované prvky nastaven na hodnotu TRUE:

Na základě tabulky se strukturou adresářového úložiště v databázi můžeme jednoznačně říci, že pole „Předdefinováno“ odpovídá poli „IsMetadata“. Pokud se podíváme na obsah tabulky "_Reference37" v SQL databázi, uvidíme následující:

V položce pro předdefinovaný prvek je hodnota pole "IsMetadata" nastavena na "0x01", což odpovídá příznaku TRUE. Pro normální prvky je hodnota nastavena na "0x00". To je hlavní rozdíl mezi předdefinovanými prvky a běžnými prvky. Všechna ostatní pole jsou uložena v databázi stejným způsobem jako pole v běžných položkách přidaných uživateli.

Předdefinované prvky mohou mít velmi zajímavé využití. S jejich pomocí můžete zabránit smazání/označení skupin prvků ke smazání v adresáři a dalších objektech, kam je lze přidat. Pokud se pokusíme smazat nebo označit pro smazání skupinu "Testovací prvky". pak dostaneme následující chyby:

Předdefinované prvky tak učiní skupinu, ve které jsou umístěny, také "předdefinovanou".

Dokončení

Předdefinované prvky jsou nedílnou součástí většiny konfigurací. Jejich použití zjednodušuje vývoj a činí konstrukci funkčnosti logicky „harmoničtější“ a integrálnější.

Při práci na platformě 1C:Enterprise 8.x je často potřeba vázat se v kódu programu na běžné (nepředdefinované) prvky adresáře. Organizace může mít například pět typů cen, které se používají téměř ve všech mechanismech. Programový přístup ke konkrétní ceně je v tomto případě v lepším případě proveden buď skřípáním kódu v adresáři, nebo v horším případě názvu prvku.

Byl jsem svědkem toho, jak v reportech pro získání požadované ceny byl použit výběr podle typu ceny v požadavku podle jeho názvu (viz následující screenshot).

Pokud navíc odkazujete na název nebo kód prvků adresáře, pak když obdržíte odkaz na prvek, bude vždy provedeno vyhledávání v tabulce adresářů. Navzdory skutečnosti, že standardní systémové detaily jsou indexovány DBMS, jejich vyhledávání může v některých případech vyžadovat značné prostředky. Kromě toho by bylo racionálnější neprovádět vyhledávací dotaz pomocí referenční tabulky, pokud je, řekněme, odkaz na prvek již „známý předem“.

Jako východisko můžete uložit odkaz na každý často používaný prvek adresáře „Typy cen položky“ v samostatných konstantách a získat z nich hodnoty v požadavku. V tomto případě však bude muset vývojář přidat samostatnou konstantu pro každý takový prvek. Situace se výrazně zkomplikuje, pokud takové prvky nebudou pouze v adresáři „Typy cen položky“, ale i v jiných adresářích („Kategorie objektů“, „Kvalita“, „Nomenklatura“ a další). Potom se počet konstant v systému může několikanásobně zvýšit!

Samozřejmě by bylo možné přidat předdefinované prvky do každého z adresářů a přístup k nim by byl mnohem jednodušší. Změna výchozích objektů by však ztížila aktualizaci konfigurace z balíčků dodavatele.

Existuje optimálnější přístup jak z hlediska vývoje struktury metadat konfigurace, tak z hlediska výkonu systému. O tom si dnes povíme.

Univerzální řešení

Podstata univerzálního řešení bude následující: vytvoří se adresář, do kterého bude vývojář přidávat předdefinované prvky. Do vyhledávání byl přidán atribut "Value", jehož typ závisí na hodnotách, pro které bude vytvořena korespondence "Predefined lookup element -> Associated value". Struktura metadat adresáře vypadá takto (viz následující snímek obrazovky).

Chcete-li získat předdefinovaný prvek, nejlepší možností je použít globální metodu "PredefinedValue(<Имя>)" . Úplná cesta k předdefinovanému prvku je předána jako parametr metodě. Syntaxe je podobná funkci dotazovacího jazyka VALUE().

Pro usnadnění vývoje doporučuji funkci pro získání hodnoty spojené s předdefinovaným prvkem umístit do společného modulu. V testovací konfiguraci, dostupné ke stažení přes odkaz na konci článku, byl vytvořen společný modul „Hodnoty předdefinovaných prvků“ s funkcí exportu "GetValue of PredefinedElement(<ИмяПредопределенногоЭлемента>)" . Programový kód funkce obdrží odkaz na předdefinovaný prvek a poté pomocí požadavku obdrží hodnoty atributu „Value“. Následující snímek obrazovky ukazuje kompletní výpis funkcí.

Jak vidíme, funkce generuje požadavek na atribut „Value“ předdefinovaného prvku předávaného jako parametr. Parametr funkce je řetězec s názvem předdefinovaného prvku.
Aby vytvořený mechanismus správně fungoval, musíte propojit předdefinovaný prvek v uživatelském režimu s běžným prvkem adresáře výběrem odpovídajícího prvku v atributu „Value“. Přejděme k otázce dopadu na výkon.

Dopad na výkon

Provedl jsem test rychlosti pro obě možnosti vyhledávání: podle názvu a podle odkazu z předdefinovaného prvku. Vyhledávání probíhalo v adresáři „Produkty“ s 20 000 záznamy. Při provádění testů na databázi souborů byly získány následující výsledky:

Výsledky ukázaly, že pro souborovou verzi práce je použití předdefinovaných prvků k získání často používaných prvků jiných adresářů téměř 4krát pomalejší!

Ve verzi klient-server práce ukazují výsledky testů úplně jiný obrázek. Rychlost získání odkazu na požadovaný prvek se nijak výrazně nesnížila (jeden z testů ukázal 0,002 sekundy pro vyhledávání podle jména a 0,0008 sekundy při práci přes předdefinovaný prvek), ale výrazně se zvýšila spolehlivost programu!

závěry

V případech, kdy je často nutné odkazovat na běžné adresářové prvky, doporučuji nepoužívat vazbu kódem nebo názvem. Tento přístup snižuje spolehlivost a výkon systému.

Během své práce s platformou jsem se nejednou setkal se situacemi, kdy po změně názvu např. adresářového prvku „PriceNomenclature Types“ selhala práce většiny nestandardních sestav.

Čím více algoritmů je připojeno k běžným prvkům adresáře prostřednictvím kódu nebo názvu, tím je systém méně stabilní.

Tento přístup vám navíc umožní neměnit standardní konfigurační objekty, pokud k nim potřebujete přidat předdefinovaný prvek. To v budoucnu poněkud usnadní proces aktualizace konfigurace.

Soubory ke stažení:

1. Nahrání testovací databáze s příklady z článku.

Platí pro platformu verze 1C:Enterprise 8.3.3 a vyšší bez režimu kompatibility s verzí 8.2

1.1. V adresářích, účtových osnovách, schématech charakteristických typů a plánech kalkulačních typů je možné automaticky nebo programově vytvářet předdefinované prvky.

1.2. Ve většině případů se doporučuje vytvářet předdefinované prvky automaticky, protože jsou neustále potřeba a chcete si usnadnit přístup k těmto prvkům z kódu.
Například předem definovaná země Rusko v adresáři Země světa, předdefinovaný profil přístupové skupiny Správce a tak dále.

Pro tohle

• ve vlastnictví adresáře, účtové osnovy, typové tabulky charakteristik nebo plánu typů kalkulací musí být nastaveny Auto(výchozí) a programová volání metody by neměla být povolena SetUpdatePredefinedData tyto objekty přepnout tento režim.
• zabránit uživatelům ve smazání předdefinovaných prvků zakázáním následujících práv ve všech rolích (ve výchozím nastavení zakázáno):
  • InteractiveDeletePredefinedData
  • InteractiveMarkDeletionPredefinedData
  • InteractiveUnflagDeletePredefinedData
  • InteractiveDeleteTaggedPredefinedData

1.3. Výjimkou jsou podřízené uzly RIB, ve kterých se předdefinované prvky nevytvářejí automaticky (a neaktualizují se, když dojde ke změně metadat), ale musí být přeneseny z hlavního uzlu spolu se změnami konfigurace.

kde:

a) konfigurace musí zajistit, aby byla zpráva výměny načtena do podřízeného uzlu RIB před provedením jiného aplikačního kódu, který přistupuje k předdefinovaným prvkům přijatým z hlavního uzlu;

b) v použité logice načítání dat z hlavního uzlu (event handler Při příjmu dat z hlavní, pravidla registrace objektů) je třeba se vyvarovat volání předdefinovaných prvků, protože neexistuje žádná záruka, že již byly načteny z výměnné zprávy;

c) kód obslužných rutin aktualizace IS, který zpracovává předdefinované prvky, by neměl být spouštěn v podřízených uzlech IS:

Při použití Standard Subsystem Library (BSL) verze 2.1.4 a vyšší v konfiguraci subsystému "Výměna dat" jsou odstraněny požadavky (a) a (b).

1.4. U tabulek s předdefinovanými prvky, které nejsou součástí plánu výměny RIB (a na které se neodkazují jiné tabulky, které jsou součástí plánu výměny RIB), se doporučuje nastavit vlastnost Aktualizace předdefinovaných dat ve smyslu Aktualizovat automaticky a také při prvním spuštění podřízeného uzlu RIB nastavte automatickou aktualizaci v datech pomocí volání:

Adresáře. DirectoryName> . SetUpdatePredefinedData(UpdatePredefinedData.UpdateAutomatically) ;

2. V některých případech není nutné předdefinované prvky vytvářet automaticky, pokud jejich přítomnost závisí na nějaké podmínce: povolená funkční možnost, provozní režim programu atd.

Například určité předdefinované typy výpočtů z hlediska typů výpočtů Časové rozlišení závisí na hodnotách funkčních možností Použijte sledování času zaměstnanců v Hodinách, Použijte PieceworkEarning atd.

Pro tohle

• v majetku Aktualizace předdefinovaných dat referenční kniha, účtová osnova, typy charakteristik nebo plán typů výpočtu musí být nastaveny na "Neaktualizovat automaticky"
• poskytněte kód pro vytvoření (a zrušení platnosti) předdefinovaného prvku v závislosti na obchodní logice, například:

• zohlednit v kódu aplikace absenci předem definovaných prvků v informační bezpečnosti. V opačném případě bude při přístupu k neexistujícímu předdefinovanému prvku z kódu nebo těla požadavku vyvolána výjimka:

Při použití v konfiguraci knihovny Standard Subsystem Library (BSS) verze 2.1.4 a vyšší se doporučuje použít funkci PredefinedElement společný modul General PurposeClientServer, který se vrací Nedefinováno pro předdefinované prvky, které v informační bezpečnosti neexistují.

Samotná myšlenka programové práce s předdefinovanými prvky je podle mého názoru velmi správná. Existují prostě nuance, které je třeba vzít v úvahu při práci.

Nejprve musíte sami jasně pochopit, že v konfiguraci jsou předdefinované prvky a v informační bázi (IS) jsou předdefinované prvky. Technicky jsou předdefinované prvky zabezpečení informací nejběžnějšími prvky adresářů, ve kterých atribut „Název předdefinovaných dat“ označuje, kterému předdefinovanému konfiguračnímu prvku odpovídají. Neliší se od běžných prvků. V souladu s tím může být jakýkoli běžný prvek zabezpečení informací vytvořen jako předdefinovaný, jakýkoli předem definovaný prvek může být proveden jako obyčejný. Chcete-li to provést, stačí zadat požadovanou hodnotu do atributu "PredefinedDataName".

Čas od času tato vlastnost obsahuje hodnotu, která není ta, kterou vývojář zamýšlel. V důsledku toho dochází k chybám při provozu 1C. Od kritických, ve kterých je práce v podstatě nemožná, po nekritické, ve kterých je narušena logika algoritmů.

Podmíněně můžeme rozlišovat tři typy chyb:
1. "Předdefinovaný prvek není v datech";

3. Nesprávná specifikace předdefinovaného prvku;

1. "Předdefinovaný prvek není v datech" - o nepřítomnost předem definovaného prvku popsaného v konfiguraci v datech zabezpečení informací.

Toto je nejjednodušší typ chyby k ladění a opravě. Jeho jednoduchost spočívá v tom, že platforma zcela správně hlásí tuto situaci „V datech chybí předdefinovaný prvek“ a je zcela jasné, jak to opravit.

Při přístupu k chybějícímu prvku v kódu "Adresáře. Typy kontaktních informací. E-mail kontaktní osoby" se zobrazí zpráva

Při přístupu k prvku v požadavku „VALUE(Directory.Types of Contact Information.Email of the Contact Person)“ se zobrazí následující zpráva:

K této chybě dochází, pokud je prvek popsán v konfiguraci, ale prvek k němu není přidružen v databázi.

Pro začátek si ujasněme, že tato situace není vždy špatná. Je docela možné použít předdefinovaná data v nějaké programové logice, která pro většinu uživatelů nemusí být použita. V tomto případě, aby nebyl zaneřáděn adresář pro všechny uživatele konfigurace, je logické definovat předdefinované prvky v konfiguraci, ale nevytvářet je ve všech systémech informační bezpečnosti, ale pouze u těch systémů informační bezpečnosti, ve kterých je použita požadovaná konfigurační logika. V tomto případě může programátor zadat vlastnost „Neaktualizovat předdefinovaná data“ pro adresář a vytvářet prvky programově při přístupu k funkcionalitě modulu. Nebo umožnit uživateli nezávisle svázat předdefinované modulové prvky se stávajícími běžnými prvky.

Při práci v režimu RIB se také nepoužívá automatické vytváření předdefinovaných prvků. Protože nové prvky musí být přeneseny z centrální databáze a nevytvářeny v uzlech s různými UID.

Tito. Někdy je chybou odkaz na neodpovídající prvek, nikoli přítomnost takového prvku samotného.

Je nutné analyzovat, proč prvek nebyl vytvořen. Možná by měl být vytvořen, když je spuštěn nějaký programový režim. Například po dokončení výměny v RIB. Nebo byl možná jen omylem smazán.

Pokud logika umožňuje vyplňování předdefinovaných prvků ne automaticky, ale v samostatném režimu, pak před použitím přístupu podle názvu " Adresáře. Typy kontaktních informací. E-mail kontaktní osoby"Aby se předešlo výjimečné situaci, je vhodné zkontrolovat, zda je prvek již v databázi. Pokud prvek chybí, pak o tom uživatele informujte a vysvětlete, jaký režim potřebuje provést, aby prvek naplnil. Pro takovou kontrolu , můžete spustit datový dotaz.

Žádost = Nová žádost; Request.Text = "SELECT | Typy kontaktních informací. Odkaz | FROM | Adresář. Typy kontaktních informací JAK Typy kontaktních informací | KDE | Typy kontaktních informací. Název předdefinovaných dat = "" Email Kontaktní osoba"""; Item Is MissingInData = Query.Execute().Empty();

Pokud se přesto jedná o chybu v databázových datech, pak je nutné se vázat na předem definovaný prvek prvku bezpečnosti informací. Tito. je nutné systému vysvětlit, ke kterému prvku zabezpečení informací má programový kód pod tímto názvem přistupovat. Technicky vzato, vazba jednoduše určuje název předdefinovaného prvku ve vlastnosti "PredefinedDataName" prvku IS. Chcete-li jej nainstalovat, stačí spustit kód:

2. "Předdefinovaný prvek není jedinečný" - h dvojité předdefinované prvky:

Tato situace spočívá v tom, že k jednomu předdefinovanému prvku je připojeno několik prvků zabezpečení informací. V tomto případě při přístupu k předdefinovanému názvu bude prvek vybrán náhodně. Tato situace je vždy špatná. Jeho potíž je v tom, že platforma to žádným způsobem nehlásí. Algoritmy prostě začnou fungovat špatně.

Platforma ohlásí chybu „Předdefinovaný prvek není jedinečný“ pouze při pokusu o úpravu duplicitního prvku.

Dokud nikdo nemusí prvek upravovat, nikdo se o chybě nedozví.

Takové duplikáty lze vytvořit například tehdy, pokud je pro adresář použit RIB a ve vlastnostech pro předdefinovaná data je zadán režim „Aktualizovat automaticky“. V tomto případě se při provádění výměny při aktualizaci konfigurace vytvoří jedna instance předdefinovaných dat. Během výměny bude z centrální databáze přenesena druhá instance předdefinovaných prvků se stejným názvem.

Tyto duplikáty také vzniknou při použití výměnného zpracování mezi konfiguracemi, pokud různé prvky zabezpečení informací odpovídají předdefinovaným prvkům v různých databázích. V tomto případě jedna kopie předdefinovaných dat již v databázi existuje, druhá přijde při načítání dat s jiným UID. Pokud provádíte přenosy dat, musíte se rozhodnout, které databázové prvky jsou považovány za primární, a použít je v podřízené databázi. V podřízené databázi je nutné nahradit použití starých prvků prvky hlavní databáze.

Takové chyby v databázi lze identifikovat pomocí dotazu jako:

SELECT Typy kontaktních informací.Název předdefinovaných dat, QUANTITY(ROZNÉ typy kontaktních informací.Odkaz) AS Počet předdefinovaných Z adresáře.Typy kontaktních informací AS Typy kontaktních informací GROUP BY Typy kontaktních informací.Název předdefinovaných dat S MNOŽSTVÍ (RŮZNÉ typy kontaktů noInformation.Link) > 1

Tento dotaz vrátí seznam předdefinovaných prvků, se kterými je spojen více než jeden prvek zabezpečení informací.

Pokud takové prvky existují, je nutné u jednoho z nich odstranit spojení s předdefinovaným. Tito. Pro systém je nutné jednoznačně určit, na jaký prvek zabezpečení informací se má programový kód při použití tohoto názvu odkazovat. Chcete-li to provést, stačí spustit kód.

3. Nesprávná specifikace předdefinovaného prvku.

Chyba spočívá v tom, že předdefinovaný prvek odpovídá prvku, který není poskytován logikou programu. Diagnostika takových chyb je nejobtížnější. Na rozdíl od prvních dvou typů nelze v konfiguraci automaticky kontrolovat tyto chyby. Lze je identifikovat pouze analýzou logiky práce. V případě pochybností můžete zkontrolovat, zda je použit správný prvek.

Chcete-li to provést, stačí spustit jeden z příkazů.

//Definování prvku zabezpečení informací, který je propojen s požadovaným předdefinovaným oznámením (Directories.Types of Contact Information.Email of the ContactPerson) //Definováním předdefinovaného prvku, ke kterému je připojeno vybrané oznámení (Link to Element.Name of Predefined Data )

Pokud jsou takové chyby identifikovány, je nutné odstranit nesprávné spojení se starým prvkem a přidat spojení s novým prvkem. Operační kód je podobný kódu pro opravu prvních dvou typů chyb.

Stručně o chybách během práce programu nebo v režimu konfigurátoru:

„Předdefinovaný prvek nepatří<Имя справочника>" - při pokusu o zápis předdefinovaného prvku s názvem, který neodpovídá názvu v konfigurátoru, dojde k chybě.

"Nepředdefinované objekty nemohou mít předdefinované záznamy zobrazení subkonto" - při pokusu o zrušení předdefinování prvku předdefinovaného účtového rozvrhu dojde k chybě. Pro odstranění chyb je nutné odstranit příznak „Předdefinováno“ z každého dílčího kontaktního řádku prvku.

"Nepředdefinované objekty nemohou mít předdefinované záznamy hlavních typů výpočtů"- při pokusu o zrušení předdefinování předdefinovaného prvku plánu typů výpočtů dojde k chybě. Chcete-li odstranit chyby, je nutné zrušit zaškrtávací políčko „Předdefinováno“ u každého řádku typu výpočtu úvodního prvku.

"Předdefinované prvky nejsou jedinečné"- při aktualizaci informační báze pro konfigurační verzi bez režimu kompatibility s 8.3.4 se vygeneruje chyba v konfigurátoru. Před aktualizací je nutné zkontrolovat duplicity a odstranit je.

"Název předdefinovaného prvku není jedinečný" - chyba nastane, když je v konfiguraci při aktualizaci na platformu několik předdefinovaných prvků stejného jména8.3.6.2332 a vyšší. Je nutné odstranit duplicity v konfiguraci.

Pro práci s předdefinovanými daty doporučuji zpracovat. Může provádět libovolné akce s předdefinovanými daty a také může zkontrolovat konfiguraci jako celek na přítomnost chyb prvních dvou typů (duplicitní a chybějící prvky) ve všech objektech informační bezpečnosti (adresáře, účtové osnovy, PVC, PVR) .