Sot duam t'ju tregojmë për përdorimin e raporteve dhe përpunimit shtesë, dhe veçanërisht zgjerimet e konfigurimit në modelin e shërbimit. Teknologjitë nuk qëndrojnë ende, mirëmbajtja e bazave të të dhënave 1C në cloud po bëhet një shërbim gjithnjë e më tërheqës. Çfarë duhet të dini në mënyrë që funksionaliteti i nevojshëm për kompaninë tuaj të zbatohet në një bazë të dhënash me qira dhe si duket ky proces nga ana e ofruesit të shërbimit - mund ta mësoni për këtë nën prerje.
Cilat janë raportet dhe përpunimi i jashtëm
Përpunimi 1C është i ndryshëm, por në çdo rast, ato zgjerojnë funksionalitetin e konfigurimit dhe ju lejojnë të merrni akses të shpejtë në informacionin e ruajtur në bazën e të dhënave pa ndryshuar konfigurimin dhe pa e hequr atë nga mbështetja. Ato mund të ndërtohen drejtpërdrejt në konfigurim, të shtohen si një shtesë konfigurimi ose të jenë skedarë të jashtëm. Sipas funksionalitetit të përpunimit, ato ndahen në ato që mund të ndryshojnë të dhënat dhe ato që thjesht analizojnë informacionin dhe shfaqin rezultatin në një formë miqësore për përdoruesit (raporte). Për të mos ndryshuar paraqitjet standarde për printimin e dokumenteve, janë duke u zhvilluar forma të jashtme të printimit. Gjithashtu, përpunimi i jashtëm mund të kryhet sipas një orari të caktuar në serverin e aplikacionit 1C - këto janë detyra të planifikuara.
Disa dhjetëra përpunime janë zhvilluar në Buton, duke lejuar kontabilistët tanë të përdorin "magjinë praktike". Për shembull, për të analizuar korrektësinë e kontabilitetit në Buton, përdoret raporti i jashtëm "Bazat e të dhënave Autoaudit". Tabelat e lexueshme tregojnë një analizë të 120 kritereve për bilancet dhe qarkullimin e llogarive, përputhshmërinë e të dhënave nga deklaratat tatimore dhe informacionin e kontabilitetit, analizën e aktiveve fikse etj.
Një shembull i një formulari të shtypur të jashtëm "marrëveshje kredie" sipas formularit të zhvilluar nga avokatët tanë. Ka raste kur një sipërmarrës merr një kredi pa interes nga kompania e tij si individ, ose anasjelltas, transferon fondet e veta në kompani, atëherë është e mundur të printohet menjëherë kontrata.
Hapet një formular për të plotësuar të dhënat e kërkuara:
Dhe shfaqet forma e shtypur e kontratës:
Përpunimi i planifikuar (detyrat e planifikuara) përdoret, për shembull, për të korrigjuar një ekstrakt. Butoni ka integrime me bankat kryesore dhe robotë të veçantë ngarkojnë deklaratën drejtpërdrejt në 1C. Falë teknologjisë së mësimit të makinerive, përqindja e gabimeve gjatë arkëtimit u ul në 3%. Por si gjithmonë, ka përjashtime, për shembull, klientët që përdorin një skemë agjencie për shitjen e mallrave, në këtë rast rregullat për kryerjen e një deklarate bankare janë individuale. Për të mos riprogramuar robotin për një rast të veçantë, përpara ardhjes së shtesave të konfigurimit, u përdor një detyrë e planifikuar për të korrigjuar deklaratën për robotin një herë në 10 minuta.
Cilat janë shtesat e konfigurimit
Një shtesë është një mini-konfigurim që trashëgon objekte nga konfigurimi kryesor i bazës së të dhënave dhe përmban kod me shtesa ose rregullime në objekte dhe module. Në të njëjtën kohë, konfigurimi kryesor mbetet i mbështetur, nuk ka nevojë të aktivizoni modifikimin, gjë që thjeshton shumë procesin e përmirësimit. Mekanizmi supozon tre lloje përdorimi, të cilat, në fakt, tregohen në fushën "Qëllimi" kur krijoni një shtesë:
Komponenti qendror i teknologjisë është Menaxher i Shërbimit, ruan të gjitha informacionet në lidhje me pajtimtarët, përdoruesit, aplikacionet, bazat e informacionit dhe lidhjet ndërmjet tyre, me ndihmën e tij menaxhohen shtesat e përpunimit të jashtëm dhe konfigurimit.
Të gjithë skedarët me përpunim ngarkohen në një drejtori të veçantë të menaxherit të shërbimit. Por përpara se të ngarkoni një skedar në një drejtori, me fjalë të tjera, "ta botoni atë në një shërbim", ai duhet të përgatitet në një mënyrë të veçantë.
Përgatitja e raporteve të jashtme dhe përpunimi për publikim në modelin e shërbimit
Një raport ose përpunim shtesë krijohet në konfiguruesin "1C: Enterprise 8" si raporte standarde të jashtme dhe përpunohet dhe ruhet në një skedar me shtesën - .epf (për përpunim shtesë) ose .erf (për raporte shtesë). Moduli i objektit duhet të ketë procedura dhe funksione për të përcaktuar parametrat e regjistrimit.
Ju lutemi vini re se parametri i rëndësishëm është "Versioni". Nëse bëni ndryshime në një përpunim që është ngarkuar tashmë në drejtorinë e menaxherit të shërbimit, sigurohuni që të ndryshoni numrin e versionit ose menaxheri i shërbimit do të refuzojë të ngarkojë skedarin. Kur zhvilloni një raport ose përpunoni, duhet të merret parasysh që përdoruesit punojnë në modelin e shërbimit përmes një klienti në internet (një artikull i mirë në blogun 1C). Nëse përpunimi përmban forma, atëherë ata duhet të punojnë në klientin në internet nën të gjithë shfletuesit e uebit që mbështeten nga platforma teknologjike 1C: Enterprise 8.
Sipas standardeve të shërbimit 1cfresh.com, një raport ose përpunim shtesë duhet të jetë plotësisht funksional kur ekzekutohet në modalitetin e sigurt, domethënë duhet të funksionojë pa hyrë në objekte të jashtme për konfigurim.
Duhet të përgatitet një raport ose përpunim shtesë për t'u ngarkuar në shërbim si një çantë dërgese. Seti i dorëzimit është një arkiv (skedar zip) që përmban:
- raport shtesë ose dosje përpunimi;
- xml skedari i manifestit, i cili përmban meta-informacione shtesë të kërkuara nga menaxheri i shërbimit për të publikuar një raport ose proces shtesë në shërbim.
Instalimi i raporteve shtesë dhe përpunimi në modelin e shërbimit
Një tipar dallues i teknologjisë 1C Fresh është se një raport ose përpunim i jashtëm nuk mund të ngarkohet drejtpërdrejt në zonën e të dhënave. Shtimi ndodh vetëm nga administratori i shërbimit nëpërmjet menaxherit të shërbimit. Pasi të përgatitet arkivi zip me skedarin e përpunimit, ai duhet të ngarkohet në drejtorinë e menaxherit të shërbimit dhe të instalohet për një pajtimtar specifik shërbimi. Një pajtimtar shërbimi është një grup përdoruesish të bashkuar sipas disa parimeve. Prandaj, infobazat e disponueshme për një grup të caktuar përdoruesish quhen aplikacione të pajtimtarëve.
Aplikacionet mund të kenë konfigurime të ndryshme 1C (kontabiliteti i ndërmarrjes, menaxhimi i listës së pagave dhe personeli, Menaxhimi i kompanisë sonë, etj.), Të cilat mund të përdoren në modelin e shërbimit. Një raport ose përpunim shtesë mund të instalohet vetëm në aplikacionet e pajtimtarit të specifikuar gjatë shkarkimit të skedarit.
Kështu duket forma e vetive të raportit shtesë me versione. Në lidhjen "Instalo / Uninstall", ne futemi në listën e aplikacioneve dhe zgjedhim bazat e të dhënave të nevojshme.
Pasi të ngarkohet përpunimi dhe të zgjidhet aplikacioni, menaxheri i shërbimit thërret adresën e aplikacionit dhe jep komandën për ta instaluar atë në bazën e informacionit.
Fillojmë përpunimin sipas orarit
Kur punoni me një numër të madh të bazave të të dhënave të kontabilitetit, disa përpunime duhet të kryhen periodikisht. Për shembull, një herë në muaj ose çdo disa minuta. Është gjithashtu e rëndësishme që të automatizohen operacionet manuale dhe rutinë të përdoruesit. Për ta bërë këtë, ne përdorim në mënyrë aktive detyra procedurale.Përpunimi që do të planifikohet nuk ka një formë. E gjithë logjika është shkruar në modulin e objektit dhe duket kështu.
Gjatë përgatitjes së grupit të dorëzimit, ne vendosim orarin. Tani përpunimi ynë do të kryhet çdo orë.
Mësoni më shumë rreth shtesave të konfigurimit
Paralelisht me raportet dhe përpunimin e jashtëm, të cilat duhet të përgatiten dhe administrohen “sipas modës së vjetër”, ne filluam të përdorim në mënyrë aktive mekanizmin e zgjerimeve të konfigurimit. Duke filluar me platformën 1C Enterprise 8.3.10, ky mekanizëm e ka bërë jetën tonë shumë më të lehtë dhe ka bërë të mundur thjeshtimin e përshtatjes së konfigurimeve me veçoritë e Butonit. Për shembull, ne kemi shkruar më lart për operacionet rutinë për korrigjimin e dokumenteve për robotët që lëshoheshin çdo 10 minuta. Tani mund të përdorni shtesën për të ripërcaktuar se si funksionojnë modulet. Kështu, ne mundemi menjëherë, kur regjistrojmë ose postojmë një dokument, të kryejmë veprimet e nevojshme. Kjo është shumë më optimale, sepse radha e punës në bazën e të dhënave nuk është e bllokuar me veprime çdo 10 minuta, dhe më shpejt, pasi ndryshimet bëhen menjëherë.
Përgatitja e një shtesë të re është mjaft e thjeshtë. Le të shohim procesin e krijimit të shtesave me shembuj specifikë.
Sipas përvojës së punës, lider në kërkesat për rregullime është formulari i shtypur TORG-12. Për shembull, duhet të bëjmë një shtesë për aftësinë për të printuar një fletëdorëzimi në një monedhë (si parazgjedhje, ajo mund të gjenerohet vetëm në rubla).
Hapni menunë → Konfigurimi → Zgjerimet e konfigurimit
Krijo një shtesë të re me detyrën "Përshtatje".
Shtesa duket si një pemë e njohur e konfigurimit, por ende pa objekte. Para së gjithash, le të shtojmë një paraqitje të re TORG-12, në të cilën kemi futur kolona me shuma në monedhë.
Meqenëse fatura është printuar nga dokumenti "Shitja e mallrave dhe shërbimeve", le ta shtojmë këtë dokument në zgjerimin tonë nga konfigurimi kryesor dhe të bëjmë ndryshimet që na duhen në modulin e menaxherit. Për ta bërë këtë, në menunë e kontekstit të zbatimit, zgjidhni "Shto në zgjerim".
Tani mund të modifikoni modulin e menaxherit të zbatimit. Ne duhet të shtojmë një formular të ri në listën e printueshme dhe të plotësojmë shumat e monedhës.
Për të ndryshuar procedurat tipike, ne përdorim shënimin &Pas, na duhen gjithashtu disa nga funksionet tona dhe një procedurë.
Le t'i hedhim një vështrim më të afërt shënimeve. Në shtesat, mund të përdorni: &Përpara, &Pas, &Në vend të kësaj (me shumë kujdes). Parimi i funksionimit është i thjeshtë: duam që së pari të ekzekutohen algoritmet tona nga ekstensioni, vendosim shënimin &Përpara dhe në kllapa tregoni emrin e procedurës nga konfigurimi tipik. Nëse moduli tipik funksionon fillimisht, dhe më pas i yni, ne përdorim &Pas.
Shënimet &Përpara dhe &Pas nuk mund të zbatohen për funksionet. Prandaj, nëse duhet të ndryshojmë algoritmin e një funksioni nga konfigurimi kryesor, ne përdorim &Në vend të shënimit.
Shënimi &Në vend të kësaj duhet të përdoret sa më pak që të jetë e mundur, pasi zëvendëson plotësisht ekzekutimin e një procedure dhe funksioni nga konfigurimi kryesor me një procedurë/funksion shtesë. Me këtë metodë përgjimi, procedura / funksioni nga konfigurimi kryesor në përgjithësi do të pushojë së ekzekutuari gjatë instalimit të shtesës, madje edhe përditësimi i versioneve nuk do të ndihmojë.
konkluzioni
Ka shumë mendime të ndryshme rreth përdorimit të shtesave dhe raporteve/përpunimit të jashtëm. Bazuar në përvojën tonë, ne jemi pro zgjerimit me të dyja duart. Kjo është një teknologji moderne dhe më adaptive, ka shumë më tepër veçori dhe publikimi i tyre është shumë herë më i lehtë. Vetëm pjesa e nevojshme e kodit vendoset në shtesë; gjithashtu nuk ka nevojë të përshkruani procedura dhe funksione shtesë për të përcaktuar parametrat e regjistrimit, për të monitoruar versionet dhe për të krijuar një komplet shpërndarjeje.Ju mund të përdorni shtesa të shumta për të njëjtën zonë të të dhënave.
Për specifikat e 1C Fresh në modalitetin e ndarjes së të dhënave (një konfigurim, shumë zona të pavarura), metoda e zgjerimit është një rrugëdalje e shkëlqyer.
Zbatuar në versionin 8.3.9.1818.
Me pak fjalë, tani me ndihmën e shtesave mund të ndryshoni modulet e konfigurimit tipik dhe të shtoni modulet tuaja.
Dhe më në detaje, mund të ndryshoni çdo modul, përveç moduleve të formave të zakonshme:
- Modulet e përgjithshme;
- Modulet e objekteve (moduli i objektit, moduli i menaxherit etj.) për të gjitha llojet e objekteve;
- moduli i sesionit;
- Moduli i aplikacionit të menaxhuar;
- Moduli i lidhjes së jashtme;
- Modulet e komandës;
- Modulet e formularit;
- etj.
Eshtë e panevojshme të thuhet, ju mund të keni modifikuar modulet e formularit të menaxhuar në të kaluarën, por tani ne kemi bërë disa ndryshime në proces.
Përgjimi
Ju mund të përgjoni ndonjë nga metodat e përgjithshme të konfigurimit, duke i inkuadruar ato me tuajat, apo edhe duke i zëvendësuar tërësisht.Trajtuesit e Vet
Ju mund të shtoni mbajtësit tuaj të personalizuar të ngjarjeve të konfigurimit. Nëse, për shembull, ato nuk janë caktuar në një konfigurim tipik.Modulet e veta
Mund të krijoni modulet tuaja të përbashkëta në shtesë.Thirrni
Dhe së fundi, mund të telefononi çdo lloj metode konfigurimi në shtesën tuaj.
Kur huazoni dhe zgjeroni një modul të konfigurimit të përgjithshëm, moduli juaj zgjatues do të jetë në të njëjtën hapësirë emri si moduli gjenerik. Prandaj, ndërsa jeni në një modul shtesë, ju mund të aksesoni drejtpërdrejt çdo variabël dhe metodë të modulit gjenerik.
Nëse jeni në një modul tjetër që ekziston në një shtesë, atëherë variablat tuaja të eksportuara dhe metodat e modulit shtesë do të jenë të disponueshme për ju. Sepse ato i shtohen kontekstit publik të modulit gjenerik.
Metoda e përgjimit të thirrjeve
Detyra e përgjimit të thirrjeve, në shumicën dërrmuese të rasteve, është të rrethojë thirrjen e një metode të përgjithshme me disa veprime para dhe/ose pas. Në të njëjtën kohë, ne nuk përjashtuam mundësinë e mbivendosjes së plotë të thirrjes së një metode tipike dhe e zbatuam një mundësi të tillë.
Ju përshkruani plotësisht nevojën për të përgjuar këtë ose atë metodë tipi në modulin e zgjerimit. Për ta bërë këtë, ne futëm një element të ri strukturor në gjuhën e integruar - shënimin. Me një shënim të vendosur përpara përkufizimit të një metode, ju specifikoni se cilën metodë intercepton procedura/funksioni dhe në çfarë mënyre. Për shembull:
Shënimi &Para("Procedura1") do të thotë se procedura e përgjithshme e quajtur Procedura1 është përgjuar. Emri i shënimit Para do të thotë që procedura juaj e fiksimit Extend_Proc1() do të ekzekutohet së pari dhe më pas do të ekzekutohet Procedura e përgjithshme1().
Annotation & Front
Një shënim me këtë emër do të thotë që përgjuesi juaj do të ekzekutohet përpara se të fillojë ekzekutimi i metodës gjenerike.
Në diagram, modulet e tipit dhe zgjerimit tregohen si drejtkëndësha, dhe shigjeta tregon sekuencën e ekzekutimit të gjuhës së integruar.
Shënim &Pas
Ky shënim do të thotë që përgjuesi juaj do të ekzekutohet pasi të ekzekutohet metoda e tipit.
Shënim dhe në vend të kësaj
Ky shënim thjesht zbaton mundësinë e një mbivendosjeje të plotë të një metode tipike. Kjo do të thotë, metoda e përgjithshme nuk do të ekzekutohet fare. Në vend të kësaj, vetëm përgjuesi juaj do të ekzekutohet.
Ju mund të instaloni një nga kombinimet e mëposhtme të interceptorëve në shtesën tuaj për të njëjtën procedurë të mostrës:
- &Përpara;
- &Pas;
- &Në vend të;
- &Para dhe pas.
Kombinimi i fundit i interceptorëve (&Para dhe &Pas) do të ekzekutohet si më poshtë:
Nëse jeni duke përgjuar një funksion gjenerik dhe jo një procedurë, atëherë mund të përdorni vetëm & në vend të përgjuesit.
Thirrja e një metode të mbivendosur me &Në vend të shënimit
Ka njëfarë padrejtësie. Ju mund ta mbuloni ose kornizoni procedurën. Dhe funksioni - vetëm bllokon plotësisht.
Për të hequr qafe këtë padrejtësi, ne zbatuam një metodë të re në gjuhën e integruar - Vazhdo thirrjen (). Nëse e thërrisni këtë metodë brenda funksionit tuaj të përgjimit, atëherë funksioni që keni anashkaluar do të ekzekutohet, pas së cilës ekzekutimi i kodit do të kthehet në përgjuesin tuaj:
Në gjuhën e integruar, një funksion i tillë përgjues mund të duket si ky:
Pra, funksioni juaj përgjues është i ndarë në dy pjesë. Pjesa që ekzekutohet para ekzekutimit të funksionit tip, dhe pjesa që ekzekutohet pas tipit.
Ju mund të përdorni metodën ContinueCall() jo vetëm kur mbivendosni funksione, por edhe kur mbivendosni procedurat. Në këtë rast, rezultati i aplikimit të tij do të jetë i njëjti në kuptim si kur përdorni një palë interceptues &Para dhe &Pas. I vetmi ndryshim është se në këtë rast pjesa juaj "para" dhe pjesa juaj "pas" do të ekzistojnë brenda të njëjtit kontekst. Në disa situata, kjo mund të jetë e përshtatshme. Në gjuhën e parë, një procedurë e tillë përgjuese mund të duket si kjo:
Cila është më e mirë, &Para, &Pas, apo &Në vend?
Kur anashkaloni metodat e përgjithshme të konfigurimit, është gjithmonë mirë të mbani parasysh dy gjëra:
- Pasi të keni shkruar shtesën tuaj, konfigurimi i paracaktuar do të ndryshojë;
- Qëllimi juaj është të shtoni funksionalitetin tuaj dhe të mos braktisni përgjithmonë atë që është dhe çfarë do të jetë në konfigurimin tipik.
Nga ky këndvështrim, përdorimi i interceptorëve &Para dhe &Pas është më i preferuari. Sepse me to metoda e tipit të përgjuar do të ekzekutohet gjithmonë, pa asnjë kusht. Dhe nëse zhvilluesit e konfigurimit tipik më vonë bëjnë ndryshime në këtë metodë, këto ndryshime patjetër do të funksionojnë kur përdorni shtesën tuaj.
Është gjithashtu krejtësisht e pranueshme të përdoret metoda &Në vend të metodës ContinueCall(). Sidoqoftë, këtu keni mundësinë dhe tundimin për të thirrur metodën gjenerike jo gjithmonë, por në varësi të disa kushteve tuaja. Duhet të jeni të kujdesshëm për këtë dhe mbani mend se në momentin që refuzoni të telefononi një metodë gjenerike, refuzoni të telefononi jo vetëm metodën që është në konfigurim tani, por edhe të gjitha variantet e saj që do të shfaqen në të ardhmen. Dhe në të ardhmen, për shembull, mund të shfaqen ndryshime të rëndësishme dhe të dobishme në të.
Dhe, së fundi, opsioni më "i keq" është mbivendosja e plotë e metodës tipike me interceptorin dhe në vend të kësaj. Në këtë rast, mbajtësi i tipit sigurisht që nuk do të ekzekutohet as tani, as në versionet e ardhshme. Kjo do të thotë, ju merrni përgjegjësinë e plotë për punën e versioneve të ardhshme të konfigurimit, në shtesën tuaj. Sigurisht që ka situata ku një mbulim i tillë i plotë është i nevojshëm, por ne ju nxisim t'i qaseni përdorimit të tij me shumë kujdes dhe kujdes.
Sekuenca e thirrjeve gjatë përgjimit të metodave
Këtu, para se të tregojmë, është e nevojshme të bëjmë një shpjegim të vogël. Një karakteristikë e rëndësishme, mund të thuhet, "ideologjike" e zgjerimeve është autonomia e tyre. Kjo do të thotë, zgjerimet duhet të dizajnohen në atë mënyrë që të mos varen nga njëra-tjetra.
Por kur aplikacioni po funksionon, natyrisht dhe padyshim, ekziston një sekuencë e caktuar e thirrjes së shtesave të lidhura. Kjo sekuencë është e njohur dhe tani do të tregojmë për të. Por ne nuk do t'ju tregojmë për këtë në mënyrë që të krijoni shtesa të ndërvarura bazuar në të, ose shtesa që nënkuptojnë një sekuencë të vetme lidhjeje të koduar. Dhe në mënyrë që të mund të analizoni problemet që lindin dhe të korrigjoni kodin e programit.
Kur lidhni shtesat me një konfigurim tipik, formohet një "byrek me shtresa". Në fund të këtij byreku është konfigurimi i paracaktuar, dhe në krye është shtesa e fundit e kyçur.
Si në konfigurues ashtu edhe në modalitetin 1C:Enterprise, shtesa e fundit e lidhur është e fundit në listë.
Pra, në këtë shembull, Lloji është në fund, Extension2 është në krye dhe Extension1 është në mes. Çdo zgjerim tjetër përgjon (zgjeron) atë që është nën të.
Kur platforma ndeshet me grepa të përcaktuara në shtesa, procesi i ngulitjes shkon nga lart poshtë në atë byrek, sipas shënimeve që kanë grepa. Aq sa mund të shkojë. Pas kësaj, ai kthehet në krye, nëse ka interceptues, dhe kthehet në konfigurimin tipik.
Shembulli 1
Për shembull, nëse e njëjta metodë e tipit kapet (kornizohet) në dy zgjerime, atëherë sekuenca e mbajtësve të thirrjeve do të jetë si më poshtë:
- Hook nga Extension2 do të thirret i pari sepse është në krye. Do të jetë përgjuesi &Përpara sepse ka këtë shënim;
- Hook nga Extension1 do të quhet më pas, sepse ky është tjetri në byrek. Përsëri do të jetë &Para, sepse ka një shënim të tillë;
- Pas kësaj, do të thirret metoda gjenerike sepse nuk ka më interceptorë për të parandaluar ekzekutimin e saj;
- Pastaj, në rend të kundërt të byrekut, do të thirren grepa &Pas nga Extension1 dhe grepa &Pas nga Extension2.
Nga ky shembull, tipari i mëposhtëm mund të kuptohet mirë: nëse një përjashtim i patrajtuar ndodh në njërin nga interceptorët, atëherë i gjithë zinxhiri ndërpritet dhe përjashtimi vazhdon të përhapet.
Shembulli 2
Nëse metoda ContinueCall() përdoret në interceptorët, atëherë zbatohet i njëjti parim "pie".
- Hook nga Extension3 do të thirret së pari sepse është në krye. Do të jetë një përgjues & në vend të kësaj, sepse ka një shënim të tillë;
- Kur përpiqeni të thërrisni një metodë gjenerike, "byrek" i mbetur do të analizohet. Do të analizohet saktësisht në të njëjtën mënyrë siç përshkruhet në shembullin e mëparshëm;
- Si rezultat, ekzekutimi i kodit do të kthehet në &në vend të interceptorit, dhe pas përfundimit të tij, në konfigurimin tipik.
Shembulli 3
Një pikë e rëndësishme për t'u kuptuar është fakti se kur anashkaloni duke përdorur shënimin &Në vend, në fakt, jo vetëm thirrja në metodën kryesore, por edhe përgjuesit më poshtë në "byrek".
Në këtë shembull, vetëm interceptori &Në vend të Extension2 do të ekzekutohet. Sepse e tejkalon metodën gjenerike, domethënë të gjithë "byrekun" që është nën të.
Shembulli 4
Ky është, në fakt, një variacion në temën e shembullit të dytë, por kur ka një shtrirje nën shtrirjen e sipërme, ai gjithashtu "hedh" thirrjen e procedurës standarde poshtë.
Në fakt, ajo vetëm një herë vizualizon faktin se thirrja e një metode gjenerike vlen për të gjithë "byrek" nën ekstension. Kjo është arsyeja pse pas thirrjes së përgjuesit nga Extension2, do të thirret përgjuesi nga Extension1. Sepse në "byrek" e mbetur është ai që anashkalon thirrjen e një metode tipike, në të cilën dëshironi të "arritni" Extension2.
Përgjimi i mbajtësve të ngjarjeve dhe trajtuesve të vet në modulet e objekteve, menaxherët, etj.
Përgjimi i çdo metode në këto module bëhet saktësisht siç përshkruhet në fillim. Megjithatë, nëse procedura e lidhur është një mbajtës ngjarjesh, ka disa veçori. Këto karakteristika janë për shkak të faktit se në këto module të gjithë mbajtësit e ngjarjeve kanë emra të caktuar.
Së pari, emri i ngjarjes specifikohet si emri i metodës së përgjuar. Për shembull, BeforeWrite:
Së dyti, prania e një mbajtësi gjenerik për këtë ngjarje është fakultative. Nëse nuk ka mbajtës të tipit, atëherë do të thirret përgjuesi juaj. Falë kësaj veçorie, ju mund të caktoni mbajtësit tuaj për ato ngjarje që nuk përpunohen në një konfigurim tipik.
Meqenëse mbajtësit e ngjarjeve në modulet e objekteve kanë emra të caktuar dhe lista e shënimeve është e njohur, ne kemi zbatuar një "shërbim" të vogël për ju. Kur krijoni një mbajtës në shtesë, hapet një dialog në të cilin mund të zgjidhni llojin e thirrjes. Pas kësaj, një cung i një procedure përgjuese krijohet në modul.
Përgjimi i mbajtësve të ngjarjeve dhe trajtuesve të personalizuar në modulet e formularit
Përgjimi i çdo metode në këto module kryhet gjithashtu në të njëjtën mënyrë siç përshkruhet në fillim. Sidoqoftë, edhe këtu ka veçori që lidhen me përgjimin e trajtuesve të ngjarjeve. Këto karakteristika lidhen me faktin se në këto module të gjithë mbajtësit e ngjarjeve janë të caktueshëm dhe nuk kanë emra fiks. Siç e dini ndoshta, në mënyrë që platforma të kuptojë se si të trajtojë këtë apo atë ngjarje, në konfigurues, në panelin e vetive, duhet të ketë një lidhje të një procedure specifike me një ngjarje specifike.
Është për këtë arsye, dhe vetëm kur përgjoni mbajtësit e ngjarjeve në një formular, që ju duhet të përdorni paletën e vetive në vend të shënimeve. Edhe pse çdo metodë tjetër moduli që nuk është trajtues ngjarjesh, ju mund të përgjoni duke përdorur shënime.
Nga jashtë, dëgjuesi i ngjarjeve në modulin e formës duket kështu:
Kjo do të thotë, shënimi nuk përdoret, dhe lloji i interceptorit tregohet në paletën e vetive. Kjo bëhet mjaft thjesht. Kur krijoni një mbajtës në shtesë duke klikuar butonin e xhamit zmadhues, hapet një dialog. Kjo ju lejon, përveç kontekstit, të specifikoni llojin e interceptorit (Përpara, Pas ose Në vend të kësaj).
Pas krijimit të një shablloni të procedurës, një ikonë që tregon llojin e përgjimit shfaqet pranë emrit të interceptorit në paletën e vetive.
Nëse anashkaloni mbajtësin e tipit (në vend të), atëherë do të jetë vetëm një pikë.
Nëse po krijoni një goditje para ose pas, ajo do të jetë një pikë pranë shiritit vertikal. Vendndodhja e pikës, para ose pas vizës, tregon llojin e interceptorit. Dhe përveç kësaj, një fushë e dytë (boshe) pranë kësaj ngjarje shfaqet në paletën e vetive. Me të, ju mund të vendosni një përgjues çift, nëse ka nevojë të kornizoni një mbajtës tipik me një çift Para - Pas.
Grupet e ngjarjeve të përcaktuara në këtë mënyrë do të funksionojnë edhe nëse nuk ka mbajtës të paracaktuar për këtë ngjarje. Kjo është mënyra se si ju mund t'i caktoni mbajtësit tuaj për ato ngjarje formash që nuk trajtohen në konfigurimin e paracaktuar.
Duke folur për modulet e formularit, duhet bërë edhe një vërejtje e vogël. Ne ndryshuam pak sjelljen e moduleve që shtrihen nga modulet që ekzistonin më parë. Në mënyrë që ai të përputhet me sjelljen e moduleve të tjera dhe të sigurojë stabilitetin e kodit të programit.
Më parë, të gjitha modulet që zgjeronin modulin e formularit dhe vetë modulin e formularit ishin në të njëjtën hapësirë emrash. Kështu, ishte e mundur të thirreshin nga shtrirja e sipërme jo vetëm metodat e konfigurimit tipik, por edhe metodat e shtesave që shtrihen më poshtë. Tani e kemi mbyllur këtë "zbrazëtirë" dhe metodat e shtesave më poshtë nuk janë më të disponueshme. Tani mund të përdorni vetëm metodat e përfshira në modulin e tipit që po zgjeroni.
Modulet e përgjithshme
Në shtesë, mund të krijoni çdo modul të përbashkët të personalizuar. Ka vetëm dy kufizime:
- Ata nuk duhet të jenë serverë globalë;
- Ata nuk duhet të jenë të privilegjuar.
Kur zgjeroni një modul të përbashkët të konfigurimit të përgjithshëm, ka edhe kufizime të ngjashme:
- Ju nuk mund të huazoni module të serverit global;
- Kodi nga ekstensioni juaj do të ekzekutohet vetëm në modalitetin jo të privilegjuar (përveç nëse lejohet ndryshe në profilin e sigurisë).
Vetë operacioni i huazimit të modulit të serverit global nuk është i ndaluar në pemën e konfigurimit, por do të merrni një gabim gjatë hapit të përditësimit të konfigurimit të bazës së të dhënave dhe përditësimi nuk do të kryhet.
Metodat e serverit nuk zgjerohen gjithmonë
Fakti që zgjerimi juaj është lidhur me sukses me një konfigurim tipik nuk do të thotë që të gjitha grepa që janë në shtesën tuaj do të aplikohen dhe do të fillojnë të ekzekutohen. Këtu ka disa veçori sigurie.
Nëse zgjidhja e aplikuar funksionon në një version skedari ose në një version klient-server pa profile sigurie, atëherë kur lidhni shtesën tuaj:
- Në mënyrën normale të ekzekutimit të gjuhës së integruar, të gjitha metodat e zgjidhjes standarde do të zgjerohen, si klienti ashtu edhe serveri;
- Në modalitetin e sigurt të ekzekutimit të gjuhës 1C: Enterprise, vetëm metodat e klientit dhe trajtuesit e formave të serverit do të zgjerohen. Shtesa nuk do të zbatohet për procedurat/funksionet e tjera të serverit.
Kur zgjidhja e aplikuar funksionon në modalitetin klient-server dhe kur specifikohet një profil specifik sigurie kur shtesa është e lidhur, ose profilet e modalitetit normal dhe të sigurt i caktohen bazës së informacionit, atëherë do të aplikohet pjesa "server" e shtesës. siç specifikohet në profilin përkatës.
Më e thjeshta prej tyre është kutia e kontrollit për të zgjeruar të gjitha modulet në grupin Lejohet me akses të plotë. Ai "me një goditje" lejon zgjerimin e kontekstit të serverit.
Ekziston gjithashtu një cilësim më i saktë duke përdorur fushat E disponueshme për modulet shtesë dhe E padisponueshme për modulet shtesë. Ne supozojmë se do t'i përdorni ato në mënyrën e mëposhtme:
- Nëse nuk keni lejuar akses të plotë në shtesat, atëherë në fushën "Modulet e disponueshme për zgjerim" renditni emrat e atyre moduleve për të cilat shtrirja e kontekstit të serverit është e pranueshme dhe jo e rrezikshme;
- Nëse keni lejuar akses të plotë në shtesat, atëherë në fushën "Modulet e padisponueshme për zgjerim" renditni disa module në të cilat nuk keni nevojë të lejoni akoma zgjerimet e kontekstit të serverit.
Doli të ishte shumë e rëndësishme :)
Ok, le ta bëjmë të dobishme edhe këtë fundjavë.
Pra, sot një temë tjetër e "operacionit të aplikuar 1C":
Mekanizmi zgjatues në platformën 8.3.6
Për çfarë po flasim?
Në platformën 8.3.6, u zbatua një mekanizëm i ri - mekanizëm zgjerimi që lehtëson përshtatjen e zgjidhjes së aplikimit për një klient specifik.
Kur përdorni shtesa konfigurimi finalizohet në një entitet të ri– zgjerimi i konfigurimit:
- Zgjatja, në fakt, është gjithashtu një konfigurim, por me disa kufizime
- Shtesa e përgatitur mund të lidhet me bazën e të dhënave të punës të klientit në modalitetin e përdoruesit
- Gjëja më e rëndësishme - konfigurimi i përfunduar nuk ka nevojë të hiqet nga mbështetja, d.m.th. mbetet standard, i pandryshuar
- Përditësimi i konfigurimit të modifikuar mund të kryhet automatikisht nga përdoruesi
Kështu, klienti si rezultat merr mundësi përmirësimi konfigurimin dhe në të njëjtën kohë përditësim i thjeshtë automatik.
Që të mund ta trajtoni këtë në mënyrë më të detajuar, ne publikojmë disa video të tjera + PDF mbi shtesat.
Pra, le të shkojmë:
Caktimi i shtesave të konfigurimit
Videoja mbulon mekanizmin e ri të zgjerimeve të konfigurimit të prezantuar në platformën 8.3.6. Është menduar për përsosje, përshtatje të zgjidhjeve gjatë zbatimit. Në të njëjtën kohë, klienti merr një përditësim të thjeshtë automatik të konfigurimit dhe aftësinë për të bërë përmirësime.
Objektet që mund të modifikohen në një shtesë
Kjo video diskuton kufizimet ekzistuese të mekanizmit të zgjerimit. Aktualisht, vetëm një numër i kufizuar objektesh mund të përdoren në shtesa.
Puna me shtesa në konfigurues
Kjo video mbulon zhvillimin e shtesave në konfigurues. Shtesa është një konfigurim, megjithëse disi i kufizuar. Puna me shtesën kryhet edhe në pemën e objekteve të meta të dhënave. Shtesa që rezulton mund të ruhet në një skedar në disk.
Huazimi i objekteve
Kjo video shikon huazimin e objekteve bazë të konfigurimit në një shtesë. Ky është mekanizmi kryesor i nevojshëm për të kryer vetë zhvillimin e zgjerimit. Ai gjithashtu flet për pronat e kontrolluara, vlera e të cilave kontrollohet kur lidhet zgjerimi.
Krijimi i objekteve tuaja në zgjerimin e konfigurimit
Kjo video tregon se si mund të krijoni objektet tuaja në shtesë. Lista e objekteve të tilla është ende e kufizuar - këto janë raporte, përpunime dhe nënsisteme. Zhvillimi i objekteve të tilla në shtrirje kryhet në analogji me konfigurimin kryesor.
Puna me shtesa në modalitetin e përdoruesit
Kjo video tregon se si të lidhni shtesën e përgatitur me bazën e punës së klientit. Në këtë rast, lidhja mund të bëhet nga modaliteti i përdoruesit pa hyrë në konfigurues.
Puna me format e menaxhuara në shtesat e konfigurimit
Kjo video ju tregon se si të punoni me format e menaxhuara në shtesë. Vihet re se forma origjinale nuk sinkronizohet automatikisht me shtesën. Shpjegon se si sistemi gjeneron pamjen rezultuese të formularit në prani të një shtrirjeje.
Modulet e menaxhuara të formularit dhe mbajtësit e ngjarjeve në shtesat e konfigurimit
Kjo video ju tregon se si të punoni me mbajtësit e ngjarjeve në "Formularët e shtesave të konfigurimit të menaxhuar".
Është demonstruar rendi i ekzekutimit të mbajtësve të ngjarjeve në konfigurimin kryesor dhe në shtesë.
Problemi kryesor i punës me shtesat është një vlerësim i njëanshëm i numrit të përmirësimeve të ardhshme nga zhvilluesit / zbatuesit. Duke u nisur nga mesazhi "po, kemi vetëm disa butona për të ndryshuar në formular", fillon puna me shtesat. Numri i përmirësimeve po rritet, shtesat vazhdojnë të përdoren bazuar në mesazhin "ne përdorim tashmë shtesa, le të vazhdojmë përmes tyre".
Pastaj lind nevoja për të shtuar entitete të reja në bazën e të dhënave, për të zgjeruar strukturën e atyre ekzistuese. Ose ndryshoni parimin e funksionimit të çdo nënsistemi tipik. Puna me shtesa po bëhet gjithnjë e më e vështirë apo edhe e pamundur. Konfigurimi përfshin aftësinë për të ndryshuar dhe fillon përsosjen "të butë" ose "të vështirë" të një konfigurimi tipik, në varësi të kualifikimeve të zhvilluesve.
Ky është momenti në të cilin mbërrin kopshti zoologjik i teknologjive. Heterogjeniteti, tashmë duke jetuar në sistemin e korporatës, fërkon me gëzim duart, duke kuptuar se ka fituar një bazë kaq të mirë nga qartësia dhe thjeshtësia.
Sigurisht, në këtë pikë, mund të heqësh qafe njërën prej kafshëve në kopshtin zoologjik të teknologjisë dhe të transferosh saktë të gjitha ndryshimet në konfigurim. Në fund të fundit, më tej do t'ju duhet të "kujdeseni" për dy kafshë - si zgjerime ashtu edhe përmirësime në konfigurimin më tipik. Pastroni pas tyre, ushqeni ato, pajtohuni disi me njëri-tjetrin në mënyrë që të mos prishin asgjë në procesin e punës së bashku, shtoni një rresht më shumë në listën e kërkesave për zhvilluesit në vendet e lira të Headhunter.
Epo, kështu duhet bërë. Por heterogjeniteti e di se njerëzit janë dembelë, kanë frikë të prekin atë që funksionon disi, ata gjithmonë "nuk kanë kohë" dhe autoritetet nuk janë në gjendje të vlerësojnë nevojën për rifaktorim në këtë moment kohor, gjë që është kritike për braktisjen e teknologjisë së panevojshme. . Përmirësimet e ndryshimeve të bëra përmes shtesave vazhdojnë të bëhen përmes shtesave. Përmirësimet e bëra në konfigurim - vazhdojnë të bëhen në konfigurim. Armiku kryesor i arkitekturës së softuerit të ndërmarrjes është i ngulitur fort në terrenin e kapur.
Në përgjithësi, është më mirë të mendoni me kujdes përpara se të filloni të përdorni një teknologji shumë të specializuar. Nëse ekziston rreziku që struktura e objekteve të duhet të ndryshohet ose të shtohen objekte të reja të bazës së të dhënave, ka nevojë të fillohet korrigjimi shpesh dhe pa probleme, ka njerëz që kuptojnë se si të ndryshojnë fillimisht konfigurimin pa probleme për përditësimet e mëvonshme, atëherë është më mirë që menjëherë të vendosni të mos prodhoni një kopsht zoologjik. Askush nuk i hoqi modulet e ripërcaktueshme, modifikimin programatik të formave dhe abonimet në ngjarje. Nëse kompania është e vogël dhe është e rëndësishme për punonjësit që konfigurimi të përditësohet me një buton tani dhe gjithmonë në të ardhmen, definitivisht nuk do të ketë ndryshime të mëdha (vërtetë i sigurt?), Atëherë nuk do të ketë kopsht zoologjik me zgjerime.
Dhe sigurisht për shtojcat e vogla, shtesat janë të mira. Ka shembuj të përdorimit të mirë në IP kur shtesat publikohen në vend të një skedari cf me një udhëzim për krahasim-kombinim. Por kjo është përsëri një zonë specifike, dhe për përdorim të përhershëm të përshtatshëm, është më mirë të transferoni funksionalitetin në konfigurim në mënyrë që nisja në modalitetin e ndërmarrjes të mos ngadalësohet.
