Kõik teavad, mis vahe on eelmääratletud elementide ja tavaliste elementide vahel: "Eelmääratletud elemendid luuakse konfiguraatorirežiimis ja neid ei saa režiimis 1C: Enterprise kustutada." Kasutajarežiimis saate eriikooni abil eristada eelmääratletud elemente kasutajate lisatud elementidest (vt järgmist ekraanipilti).

Põhimõtteliselt loovad arendajad etteantud elemendid, et siduda nendega erinevates konfiguratsiooniobjektides algoritme. Näiteks kataloogi "Kvaliteet" konfiguratsioonis "Manufacturing Enterprise Management" lisasid arendajad eelnevalt määratletud elemendi "Uus".

Seda elementi kasutatakse paljudes konfiguratsioonimoodulites. Seega asendatakse dokumendis “Kaubade ja teenuste vastuvõtt” kõigisse registritesse, kus on dimensioon “Kvaliteet”, eelmääratletud elemendi väärtus. Allpool on loetelu "Organisatsioonide kaupade" registri postitabeli täitmisest:

// TOOTED REGISTRI JÄRGI TootedOrganisatsioonid. MoveSet = Liigub. TootedOrganisatsioonid; Kui Kviitungi tüüp = Ülekanded. Kauba vastuvõtu liigid. Siis lattu // Hankige väärtuste tabel, mis vastab registri kirjekomplekti struktuurile. MotionTable = MotionSet. Unload() ; // Täida liikumistabel.Üldine otstarve. LoadValueTable(tootetabel, liikumistabel) ; // Puuduvad väljad. Liikumise tabel. FillValues(Organisatsioon, "Organisatsioon") ; Liikumise tabel. FillValues ​​(määratlemata, "Komisjoni agent"); Liikumise tabel. FillValues(Kataloogid. Kvaliteet. Uus, "Kvaliteet" ) ; // Täitke kvaliteet eelmääratletud elemendist

Seega on etteantud elementide omadused ja nende otstarve üsna lihtsad. Vaatame, kuidas neid andmebaasi tabelites hoitakse ja kuidas need tavaelementidest erinevad.

Erinevused

Testkonfiguratsioonis loodi kataloog "Tooted". Selles on loodud rühm "Testielemendid". Grupi sisu oli näha artikli alguses oleval ekraanipildil. Kataloogi "Products" jaoks on SQL-andmebaasis vastav tabel "_Reference37" järgmise struktuuriga:

Kuidas aga teha kindlaks, kas üksikasjad vastavad konfiguratsioonipuule ja SQL-tabeli väljadele?

Kasutame standardset globaalset kontekstimeetodit “GetDatabaseStorageStructure()”, mis tagastab meile väärtuste tabeli koos tabelistruktuuri kirjeldusega.

Väärtuste tabelis "Väljad" näeme vastavust SQL-tabeli väljade ja metaandmete puu objektide andmete vahel. Meie näites käsitleme kataloogi "Tooted" struktuuri. Kõigil kataloogidel on standardne Boole'i ​​tüüpi atribuut "Predefined", mis on eelmääratletud elementide jaoks seatud väärtusele TRUE:

Andmebaasis oleva kataloogi salvestusstruktuuriga tabeli põhjal saame kindlalt väita, et väli “Predefined” vastab väljale “IsMetadata”. Kui vaatame SQL-i andmebaasis tabeli "_Reference37" sisu, näeme järgmist:

Eelmääratletud elemendi kirjes on välja "IsMetadata" väärtuseks seatud "0x01", mis vastab lipule TRUE. Tavaliste elementide puhul on väärtuseks seatud "0x00". See on peamine erinevus eelmääratletud elementide ja tavaliste elementide vahel. Kõik muud väljad salvestatakse andmebaasi samamoodi nagu kasutajate lisatud tavaliste üksuste väljad.

Eelmääratletud elementidel võib olla väga huvitav kasutusala. Nende abiga saate vältida elementide rühmade kustutamist/kustutamiseks märgistamist kataloogis ja muudes objektides, kuhu neid saab lisada. Kui proovime kustutada või kustutamiseks märkida rühma "Testielemendid". siis saame järgmised vead:

Seega muudavad eelmääratletud elemendid rühma, kuhu need paigutatakse, ka "eelmääratletuks".

Lõpetamine

Eelmääratletud elemendid on enamiku konfiguratsioonide lahutamatu osa. Nende kasutamine lihtsustab arendamist ja muudab funktsionaalsuse ülesehituse loogiliselt “harmoonilisemaks” ja terviklikumaks.

Eelmääratletud elementidega programmitöö idee on minu arvates väga õige. Seal on lihtsalt nüansid, millega tuleb töötamisel arvestada.

Esiteks peate ise selgelt aru saama, et konfiguratsioonis on etteantud elemendid ja teabebaasis (IS) on eelmääratletud elemendid. Tehniliselt on eelmääratletud infoturbeelemendid kataloogide levinumad elemendid, milles atribuut “Eelmääratletud andmete nimi” näitab, millisele eelmääratletud konfiguratsioonielemendile need vastavad. Need ei erine tavalistest elementidest. Sellest lähtuvalt saab iga tavalise infoturbe elemendi muuta eelmääratletuks, iga eelmääratletud elemendi saab muuta tavaliseks. Selleks sisestage lihtsalt soovitud väärtus atribuudis "PredefinedDataName".

Aeg-ajalt sisaldab see atribuut väärtust, mis pole see, mida arendaja kavatses. Selle tulemusena tekivad 1C töös vead. Alates kriitilisest, milles töötamine on põhimõtteliselt võimatu, kuni mittekriitiliseni, mille puhul on algoritmide loogika häiritud.

Tinglikult saame eristada kolme tüüpi vigu:
1. "Eelmääratletud elementi pole andmetes";

3. Eelmääratletud elemendi vale spetsifikatsioon;

1. "Eelmääratletud elementi pole andmetes" - o infoturbeandmetes konfiguratsioonis kirjeldatud eelmääratletud elemendi puudumine.

Seda tüüpi viga on kõige lihtsam siluda ja parandada. Selle lihtsus seisneb selles, et platvorm teatab sellest olukorrast üsna õigesti "Andmetes puudub eelmääratletud element" ja on üsna selge, kuidas seda parandada.

Kui sisenete koodis puuduvale elemendile "Kataloogid.Kontaktandmete tüübid.Kontaktisiku e-post" kuvatakse teade

Päringu "VALUE(Directory.Types of Contact Information.Email of the Contact Person)" elemendile juurde pääsedes kuvatakse järgmine teade:

See tõrge ilmneb juhul, kui elementi on konfiguratsioonis kirjeldatud, kuid element ei ole sellega andmebaasis seotud.

Alustuseks selgitame, et see olukord ei ole alati vale. On täiesti võimalik kasutada eelmääratletud andmeid mingis programmiloogikas, mida enamik kasutajaid ei pruugi kasutada. Sel juhul on loogiline, et mitte segada kataloogi kõigi konfiguratsiooni kasutajate jaoks, on loogiline määratleda konfiguratsioonis etteantud elemendid, kuid mitte luua neid kõigis infoturbesüsteemides, vaid ainult nende infoturbesüsteemide jaoks, milles kasutatakse vajalikku konfiguratsiooniloogikat. Sel juhul saab programmeerija määrata kataloogi atribuudi “Ära värskenda eelmääratletud andmeid” ja luua elemente programmiliselt mooduli funktsionaalsusele juurdepääsul. Või lubage kasutajal iseseisvalt siduda eelnevalt määratletud mooduli elemente olemasolevate tavaliste elementidega.

Samuti ei kasutata RIB-režiimis töötamisel etteantud elementide automaatset loomist. Kuna uued elemendid tuleb üle kanda keskandmebaasist, mitte luua erinevate UID-dega sõlmedes.

Need. Mõnikord on viga viide sobimatule elemendile, mitte sellise elemendi enda olemasolu.

On vaja analüüsida, miks elementi ei loodud. Võib-olla tuleks see luua mõne programmirežiimi käivitamisel. Näiteks pärast vahetuse lõpetamist RIB-is. Või äkki kustutati see lihtsalt kogemata.

Kui loogika näeb ette eelmääratletud elementide täitmise mitte automaatselt, vaid eraldi režiimis, siis enne nimelise juurdepääsu kasutamist " Kataloogid.Kontaktandmete tüübid.Kontaktisiku e-post"Erandolukorra vältimiseks on soovitatav kontrollida, et element oleks juba andmebaasis. Kui element on puudu, siis teavitage sellest kasutajat ja selgitage, millist režiimi ta elemendi täitmiseks tegema peab. Selliseks kontrolliks , saate käitada andmepäringu.

Taotlus = uus taotlus; Request.Text = "SELECT | Kontaktteabe tüübid. Link | FROM | Kataloog. Kontaktandmete tüübid KUIDAS Kontaktteabe tüübid | KUS | Kontaktteabe tüübid. Eelmääratletud andmete nimi = "" EmailContactPerson"""; Üksus MissingInData = Query.Execute().Empty();

Kui tegemist on ikkagi veaga andmebaasi andmetes, siis tuleb siduda infoturbeelemendi eelmääratletud elemendiga. Need. süsteemile tuleb selgitada, millisele infoturbeelemendile peaks programmikood selle nimega ligi pääsema. Tehniliselt on sidumine lihtsalt atribuudis " eelmääratletud elemendi nime määramineEeldefineeritudDataName" IS-elemendist. Selle installimiseks käivitage lihtsalt kood:

2. "Eelmääratletud element ei ole unikaalne" - h topelt eelmääratletud elemendid:

Selline olukord seisneb selles, et ühele etteantud elemendile on lisatud mitu infoturbe elementi. Sel juhul valitakse eelmääratletud nimele juurdepääsul element juhuslikult. See olukord on alati vale. Selle raskus seisneb selles, et platvorm ei teata sellest mingil viisil. Algoritmid hakkavad lihtsalt valesti töötama.

Platvorm teatab veast "Eelmääratletud element pole unikaalne" ainult siis, kui proovite redigeerida duplikaatelementi.

Seni, kuni keegi ei pea elementi redigeerima, ei saa keegi veast teada.

Selliseid duplikaate saab luua näiteks siis, kui kataloogi jaoks kasutatakse RIB-i ja eelmääratletud andmete atribuutides on määratud režiim “Uuenda automaatselt”. Sel juhul luuakse vahetuse sooritamisel konfiguratsiooni värskendamisel üks eelmääratletud andmete eksemplar. Sama nimega eelmääratletud elementide teine ​​eksemplar kantakse keskandmebaasist üle vahetuse käigus.

Samuti tekivad need duplikaadid konfiguratsioonidevahelise vahetustöötluse kasutamisel, kui erinevad infoturbeelemendid vastavad eelnevalt määratletud elementidele erinevates andmebaasides. Sel juhul on üks koopia etteantud andmetest juba andmebaasis, teine ​​tuleb teise UID-ga andmete laadimisel. Kui teostate andmeedastusi, peate otsustama, milliseid andmebaasielemente peetakse esmasteks ja kasutama neid alluvas andmebaasis. Alamandmebaasis on vaja asendada vanade elementide kasutamine põhiandmebaasi elementidega.

Selliseid andmebaasi vigu saab tuvastada järgmiste päringutega:

SELECT Kontaktteabe tüübid. Eelmääratletud andmete nimi, KOGUS (ERINEV tüüpi kontaktteave. Viide) AS Eelmääratletud andmete arv FROM Kataloogist. Kontaktteabe tüübid AS Kontaktteabe tüübid GROUP BY Kontaktteabe tüübid. Eelmääratletud andmete nimi, MIS ON KOGUS (ERINEVAD taktiteabe tüübid.Link) > 1

See päring tagastab eelmääratletud elementide loendi, millega on seotud rohkem kui üks teabeturbe element.

Kui sellised elemendid on olemas, tuleb ühe neist ühendus eelnevalt määratletud elemendiga eemaldada. Need. Süsteemi jaoks on vaja üheselt määrata, millisele infoturbeelemendile peaks programmikood selle nime kasutamisel viitama. Selleks käivitage kood.

3. Eelmääratletud elemendi vale spetsifikatsioon.

Viga seisneb selles, et eelmääratletud element vastab elemendile, mida programmiloogika ei paku. Selliseid vigu on kõige raskem diagnoosida. Erinevalt kahest esimesest tüübist ei saa konfiguratsiooni nende vigade suhtes automaatselt kontrollida. Neid saab tuvastada ainult töö loogikat analüüsides. Kahtluse korral saate kontrollida, kas kasutatakse õiget elementi.

Selleks käivitage lihtsalt üks käskudest.

//Teabeturbe elemendi määratlemine, mis on lingitud soovitud eelmääratletud teavitusega (kataloogid. Kontaktandmete tüübid.Kontaktisiku e-post) //Eelmääratletud elemendi määratlemine, millele valitud teavitus on lisatud (Link To Element. Name of Predefined Andmed)

Selliste vigade tuvastamisel on vaja eemaldada vale ühendus vana elemendiga ja lisada ühendus uue elemendiga. Toimingukood sarnaneb kahte esimest tüüpi vigade parandamise koodiga.

Noh, lühidalt vigadest programmitöö ajal või konfiguraatori režiimis:

"Eelmääratletud element ei kuulu<Имя справочника>" - tekib viga, kui proovite kirjutada eelmääratletud elementi nimega, mis ei ühti konfiguraatoris oleva nimega.

"Eelmääratlemata objektidel ei saa olla eelmääratletud alamkontovaate kirjeid" - eelmääratletud kontoplaani elemendi eelmääratlemata muutmisel ilmneb tõrge. Vigade kõrvaldamiseks on vaja igalt elemendi alamkontakti realt eemaldada lipp “Eelmääratletud”.

"Eelmääratlemata objektidel ei saa olla juhtivate arvutustüüpide eelmääratletud kirjeid"- tekib tõrge, kui püütakse arvutustüüpide plaani eelmääratletud elementi eelmääratlemata muuta. Vigade kõrvaldamiseks on vaja eemaldada elemendi juhtiva arvutustüübi iga rea ​​märkeruut „Eelmääratletud“.

"Eelmääratletud elemendid ei ole ainulaadsed"- ühilduvusrežiimita konfiguratsiooniväljaande teabebaasi värskendamisel versiooniga 8.3.4 genereeritakse konfiguraatoris tõrge. Enne värskendamist on vaja duplikaate kontrollida ja need kõrvaldada.

"Eelmääratletud elemendi nimi ei ole kordumatu" - tõrge ilmneb siis, kui platvormile värskendamisel on konfiguratsioonis mitu sama nimega eelmääratletud elementi8.3.6.2332 ja uuemad. Konfiguratsioonis on vaja duplikaadid kõrvaldada.

Eelmääratletud andmetega töötamiseks soovitan neid töödelda. See suudab eelmääratletud andmetega sooritada mis tahes toiminguid ja kontrollida ka konfiguratsiooni tervikuna kahe esimese tüübi (dubleeritud ja puuduvate elementide) vigade olemasolu kõigis infoturbeobjektides (kataloogid, kontoplaanid, PVC, PVR) .

Head päeva.

Täna räägime platvormi 8.3 uuendusest eelmääratletud elementide osas.

Sissejuhatus

Lubage mul teile meelde tuletada, et praktikas tahtsin väga sageli vaadata kataloogielementi, et teada saada selle eelmääratletud nime. Näiteks lõite kaks eelmääratletud vastaspoolt ja nimetasite neile IPSidorov ja OOOMeteor. Ja nad õmblesid neile külge loogika.

Kui kõik oli silutud ja välja töötatud, selgus, et ülesanne oli püstitatud vastupidiselt ja OÜ jaoks oli vaja üksikettevõtja loogikat, üksikettevõtja jaoks aga OÜ loogikat. "Pole probleemi," ütleme ja ettevõtterežiimis nimetame elemendid ümber. Lõppude lõpuks on koodi sissesaamine palju keerulisem. Möödub aasta ja teile antakse uus ülesanne: seadistada IP Sidorovi jaoks rohkem loogikat. Lähed konfiguraatorisse, kirjutad loogika, hakkad kontrollima ja miski ei tööta, sest... IPSidorovi konfiguraatoris ja ettevõttes - OOOMeteor. Aju on katki ja ma tahan selle reha hävitada. Lihtsaim ja ilmsem asi on eelmääratletud elemendi nime kuvamine loendi kujul. Siin on konks: seda meetodit kasutades saate 8.2-s ainult eelmääratletud nime nime. Kuid meetodil on oma ebamugavused, seda ei saa taotluses hankida. Need. Esimene ebamugavus seisneb selles, et saada kataloogi viitest eelmääratletud nimi.

Teine ebamugavus on see, kui meil on kataloogielement juba olemas ja me peame selle eelnevalt määratlema. Loome etteantud elemendi ja saame kataloogi kaks elementi. Üks on eelmääratletud, teine ​​on töökorras, millele viidatakse kõigis meie dokumentides. Kindlasti aitab linkide väljavahetamine, aga kui andmebaas on suur, siis on see keeruline.

Nüüd asja juurde

Esimene on see, et kataloogil on nüüd atribuut "Eelmääratletud andmete värskendamine".

Mida see valdkond meile annab? Kui on seatud "Ära uuenda automaatselt", siis eelmääratletud elemendi lisamisel me seda kataloogis kohe ei näe. Need. metaandmetel pole andmetega mingit pistmist. Ja kui te seda kataloogis ei loo, põhjustab kataloogihalduri kaudu sellele nime järgi juurdepääsemine süntaksivea.

Väga huvitav, aga miks? Kuidas saame kataloogis elemendi luua? Saate selle luua nii, nagu soovite, või linkida olemasolevaga. Nüüd on kataloogis atribuut "Eelmääratletud andmete nimi". Loome kataloogielemendi programmiliselt nagu tavaliselt läbi “Directories.Contractors.CreateElement()” ja täidame selle atribuudi “PredefinedDataName”, mis on võrdne eelmääratletud elemendi nimega. Või kui element on juba olemas, saame selle objekti ja täidame uuesti välja "Eelmääratletud andmete nimi". Kõik.

Ja lõpuks natuke siirupit

See uus atribuut pole saadaval ainult lugemiseks ja kirjutamiseks, vaid see on saadaval ka päringutes. Nii saate sellele päringutes tingimusi seada, määrata, kas see on eelmääratletud või mitte.

Tänan tähelepanu eest.

Meie neljandas õppetükis jätkame programmiga tutvumist. Täna tutvume praktiliste näidetega jahierarhilised kataloogid ja õppida ka eelmääratletud elementide loomist.

Kursuse 4 õppetunni aeg:

00:19 Muudatused Töötajate kataloogis pärast kursuse 3. õppetunni kodutöö täitmist
00:35 Üksikasjade järjekorra muutmine kataloogides
02:54 Kataloogi nomenklatuuri loomine
03:40 Hierarhilise kataloogi loomine ja seadistamine
05:10 Teenuste ja toodete rühmade loomine nomenklatuuri kataloogis
06:05 Nomenklatuuri kataloogi täitmine
07:14 3 võimalust kataloogiüksuse teise rühma ülekandmiseks
08:21 Laodude kataloogi loomine
09:19 Eelmääratletud kataloogielementide loomine
11:25 Laodude kataloogi täitmine
12:20 Sooritage 4. õppetunni materjali test

Hierarhiline kataloog– kataloog, mille elemente on võimalik hierarhiliselt paigutada. Näiteks Nomenklatuuri kataloogis saab luua rühmi: Tooted, Teenused jne, milles paiknevad nendesse rühmadesse kuuluvad elemendid. Lisaks võivad kataloogirühmad sisaldada teisi rühmi, luues seeläbi mitmetasandilise hierarhilise struktuuri.

Lisaks toetavad kataloogid ka teist tüüpi hierarhiat, milles kataloogielemendid ei seostu mitte rühmade, vaid sama kataloogi muude elementidega. Seda tüüpi hierarhia ( elementide hierarhia) saab kasutada näiteks jaotiste kataloogi loomisel, kus üks jaotus (jaotus on antud juhul kataloogi element, mitte rühm) võib sisaldada mitut muud jaotust. Seda tüüpi hierarhiat kasutatakse üsna harva.

Kataloogi vormid– kataloogi visuaalne esitus. Sõltuvalt sellest, milliseid konkreetseid toiminguid me oma kataloogiga teha tahame, peame kuvama kataloogi "erinevates vaadetes". Niisiis redigeerisime kursuse 4. õppetükis detailide järjekorda loendi ja kataloogielemendi kujul.

Süsteem loob (genereerib) blankette automaatselt, kuid vajadusel saab arendaja blankette iseseisvalt “joonistada”.

Kataloogide jaoks on kokku 5 vormi (vormitüüpi):

• elemendi kuju– kataloogielemendi loomiseks või redigeerimiseks;
• rühma kuju- kataloogirühma loomiseks või redigeerimiseks;
• nimekirja vorm– kataloogielementide loendi kuvamiseks;
• valiku vorm- kasutatakse selle kataloogi ühe elemendi valimiseks teatud vormis väljal. Näiteks selleks, et valida ladu dokumendi Kauba kättesaamine kataloogist Laod konkreetne ladu;
• rühma valiku vorm– kasutatakse selle kataloogi ühe rühma valimiseks teatud kujul väljal.

Eelmääratletud kataloogielemendid– kataloogielemendid, mille arendaja on loonud konfiguraatorirežiimis ja millele pääseb juurde sisseehitatud 1c keelest nime kaudu.

Tavaliste ja eelmääratletud kataloogielementide vahel on põhimõtteline erinevus. Tavalised elemendid ei ole konfiguratsioonis konstantsed. Kasutaja töö käigus saab neid luua, redigeerida ja kustutada ning seetõttu ei tohiks neile ühegi algoritmi täitmisel loota (elemendi koodi ja nime saab kasutaja ise muuta).Eelmääratletud elemendid on seevastu püsivad. Isegi kui kasutaja nimetab sellise elemendi töö ajal ümber, pääseb sellele juurde sisseehitatud 1c keelest. See saavutatakse, kui eelmääratletud elemendil on rekvisiidid Nimi, mis pole kasutajale saadaval. Tavalistel kataloogielementidel selliseid atribuute pole.

Tähtis!

Tehniliselt on kasutajal võimalus eelmääratletud kataloogielementi kustutada, kuid reeglina keelatakse kasutajatel eelmääratletud kataloogielemente kustutada.

Kodutöö kursuse 4. tunniks

Kursuse neljanda tunni kodutööd on Teile kättesaadavad kohe peale teoreetilise testi edukat lahendamist.

1C:Enterprise 8.x platvormil töötades on sageli vajadus programmi koodis siduda tavaliste (mitte eelmääratletud) kataloogielementidega. Näiteks võib organisatsioonil olla viit tüüpi hindu, mida kasutatakse peaaegu kõigis mehhanismides. Programmiline ligipääs konkreetsele hinnale toimub sel juhul parimal juhul kas kataloogis oleva koodi järgi või halvimal juhul elemendi nime järgi.

Olin tunnistajaks, kuidas aruannetes kasutati nõutud hinna saamiseks valiku hinnatüübi järgi päringus selle nime järgi (vt järgmist ekraanipilti).

Lisaks, kui lingite kataloogielementide nimele või koodile, siis elemendi lingi saamisel tehakse alati otsing kataloogitabelis. Vaatamata asjaolule, et DBMS indekseerib standardseid süsteemi üksikasju, võib nende otsimine mõnel juhul võtta märkimisväärseid ressursse. Lisaks oleks ratsionaalsem viitetabelit kasutades otsingupäringut mitte sooritada, kui oletame, et elemendi link on juba “ette teada”.

Väljapääsuna saate salvestada kataloogi “Kaubahinna tüübid” iga sageli kasutatava elemendi lingi eraldi konstantidesse ja hankida nendest päringus olevaid väärtusi. Kuid sel juhul peab arendaja lisama iga sellise elemendi jaoks eraldi konstandi. Olukord muutub oluliselt keerulisemaks, kui sellised elemendid pole mitte ainult kataloogis “Kaubahinnatüübid”, vaid ka teistes kataloogides (“Objektikategooriad”, “Kvaliteet”, “Nomenklatuur” jt). Siis võib konstantide arv süsteemis mitu korda suureneda!

Loomulikult oleks igasse kataloogi võimalik lisada eelmääratletud elemente ja neile ligipääs muutuks palju lihtsamaks. Vaikeobjektide muutmine muudaks aga tarnija pakettidest konfiguratsiooni värskendamise keerulisemaks.

Nii konfiguratsiooni metaandmete struktuuri arendamise kui ka süsteemi jõudluse osas on optimaalsem lähenemine. Sellest me täna räägime.

Universaalne lahendus

Universaalse lahenduse olemus on järgmine: luuakse kataloog, kuhu arendaja lisab eelnevalt määratletud elemendid. Otsingule on lisatud atribuut "Väärtus", mille tüüp sõltub väärtustest, mille jaoks luuakse vastavus "Eelmääratletud otsinguelement -> Seotud väärtus". Kataloogi metaandmete struktuur näeb välja selline (vt järgmist ekraanipilti).

Eelmääratletud elemendi saamiseks on parim võimalus kasutada globaalset meetodit "PredefinedValue(<Имя>)" . Eelmääratletud elemendi täielik tee edastatakse meetodi parameetrina. Süntaks on sarnane päringukeele funktsiooniga VALUE().

Arendamise hõlbustamiseks soovitan eelmääratletud elemendiga seotud väärtuse saamise funktsiooni paigutada ühisesse moodulisse. Testkonfiguratsioonis, mis on allalaadimiseks saadaval artikli lõpus oleva lingi kaudu, loodi ühine moodul "Eelmääratletud elementide väärtused" koos ekspordifunktsiooniga "GetValue of PredefinedElement(<ИмяПредопределенногоЭлемента>)" . Funktsiooni programmikood saab viite eelmääratletud elemendile ja seejärel päringu abil atribuudi "Väärtus" väärtused. Järgmine ekraanipilt näitab täielikku funktsioonide loendit.

Nagu näeme, genereerib funktsioon päringu parameetrina edastatud eelmääratletud elemendi atribuudi "Väärtus" jaoks. Funktsiooni parameeter on string eelmääratletud elemendi nimega.
Loodud mehhanismi korrektseks toimimiseks peate kasutajarežiimis eelmääratletud elemendi siduma tavalise kataloogielemendiga, valides atribuudis "Väärtus" vastava elemendi. Liigume edasi jõudlusele avaldatava mõju küsimuse juurde.

Mõju jõudlusele

Tegin kiirustesti mõlema otsinguvõimaluse jaoks: nime ja lingi järgi eelmääratletud elemendist. Otsing toimus kataloogis "Tooted" 20 000 kirjega. Failide andmebaasi testimisel saadi järgmised tulemused:

Tulemused näitasid, et töö failiversiooni puhul on eelmääratletud elementide kasutamine teiste kataloogide sageli kasutatavate elementide hankimiseks peaaegu 4 korda aeglasem!

Töö klient-server versioonis näitavad testi tulemused hoopis teistsugust pilti. Soovitud elemendile lingi saamise kiirus pole oluliselt langenud (üks test näitas nime järgi otsimisel 0,002 sekundit ja etteantud elemendi läbitöötamisel 0,0008 sekundit), kuid programmi töökindlus on oluliselt tõusnud!

järeldused

Juhtudel, kui sageli on vaja linkida tavaliste kataloogielementidega, soovitan koodi või nime järgi sidumist mitte kasutada. Selline lähenemine vähendab süsteemi töökindlust ja jõudlust.

Platvormiga töötamise ajal olen korduvalt kokku puutunud olukordadega, kus pärast nime muutmist, näiteks kataloogielemendi “Hinnanomenklatuuri tüübid”, enamiku mittestandardsete aruannete töö ebaõnnestus.

Mida rohkem algoritme on tavaliste kataloogielementidega koodi või nime kaudu ühendatud, seda vähem stabiilne on süsteem.

Lisaks võimaldab see lähenemine mitte muuta standardseid konfiguratsiooniobjekte, kui peate neile eelmääratletud elemendi lisama. See muudab konfiguratsiooni värskendamise protsessi tulevikus pisut lihtsamaks.

Allalaaditavad failid:

1. Artiklist pärit näidetega testandmebaasi üleslaadimine.