A 8.3.6.1977 verzióban implementálva.

Alapvetően új alkalmazkodási mechanizmust valósítottunk meg alkalmazott megoldások egy adott fogyasztó számára - a kiterjesztési mechanizmus.

Miért jók a kiterjesztések?

A bővítmények más stratégiát kínálnak a tipikus konfigurációk megváltoztatására, mint a meglévő. Ennek felhasználásával új stratégia nagyban megkönnyíti a karbantartást tipikus megoldások hogy alkalmazkodni szeretne egy adott megvalósítás, egy adott ügyfél igényeihez.

Hogyan néz ki most ez a folyamat? Van egy tipikus konfiguráció. A szállító teljes mértékben támogatja. Ez azt jelenti, hogy nem tudod megváltoztatni. A gyártó rendszeresen kiadja a konfiguráció új (továbbfejlesztett) verzióit. Ilyen helyzetben frissítés régi verzió az új verzió konfigurálása teljesen automatikusan történik. Kényelmes, és nem igényel különleges készségeket vagy ismereteket az ügyféltől.

De gyakran az ügyfél hozzá akar adni valamit vagy megváltoztatni valamit egy tipikus konfigurációban "saját magának". Ehhez a támogatási mód megváltozik, a konfiguráció eltávolításra kerül a teljes támogatásból. A végrehajtást végző partner, vagy az ügyfél saját informatikusai elvégzik a szükséges változtatásokat. Ettől kezdve lehetetlenné válik egy tipikus konfiguráció teljesen automatikus frissítése a szállító által kiadott új verzióra.

Most egy szakemberre van szükség a konfiguráció frissítéséhez. Ezenkívül, ha az ügyfél kérésére végrehajtott módosítások jelentősek voltak, akkor jelentős időbefektetésre lehet szükség a konfiguráció frissítését végző szakembertől. És gyakran szükség lehet a tipikus konfiguráció és a végrehajtott módosítások nagyon jó ismeretére.

A kiterjesztések által javasolt stratégia a következő. Ha módosítani szeretné a tipikus konfigurációt, akkor ne érintse meg magát a konfigurációt. Minden módosítás, amelyet a bővítményben hajt végre, ami valójában szintén konfiguráció.

1C: Vállalati módban egyszerűen csatlakoztathatja a bővítményt a szabványos konfigurációhoz. A platform automatikusan, 1C: Enterprise módban egyesíti a bővítményt egy tipikus konfigurációval. Ennek eredményeként az ügyfél a kívánságainak megfelelően módosított szabványos megoldással dolgozik.

Amikor a szállító kiadja a tipikus konfiguráció új verzióját, automatikus frissítésre kerül sor, mert a tipikus konfiguráció támogatási módja nem változott. Továbbra is teljes mértékben támogatta a szállító. És amikor elindít egy frissített alkalmazásmegoldást, a platform automatikusan egyesíti a módosított szabványos konfigurációt a bővítménnyel. És az ügyfél tovább dolgozik egy módosított, kívánsága szerinti szabványos megoldással.

Mikor érdemes bővítményeket használni?

A hosszabbító mechanizmus sokoldalúság miatt csábító. Ezért fontos, hogy pontosan megértsük, milyen feladatokra szánják.

Először is, a kiterjesztések pótolhatatlanok, ha az alkalmazásmegoldás adatmegosztási módban működik. Például a szolgáltatási modellben. Az egyik előfizető további pár jelentést szeretne kapni. Míg a többi előfizető a változatlan tipikus konfigurációval szeretne dolgozni.

Akkor ennek az előfizetőnek fejleszthet egy bővítményt, amelyben minden kívánságát megvalósíthatja. Az előfizető összekapcsolja ezt a bővítményt, és a módosított konfigurációval dolgozik. Míg a többi előfizető esetében nem lesz változás. Mivel minden bővítmény össze van kötve, és az aktuális elválasztó értékek összefüggésében fut.

Egy másik helyzet egy tipikus konfiguráció befejezése egy adott ügyfél számára a megvalósítás során. Vagy a tipikus konfiguráció módosításai, amelyeket az ügyfél informatikusai végeznek el maguk. Ha mindezeket a fejlesztéseket a bővítményben hajtják végre, akkor a tipikus konfiguráció maradéktalanul támogatott marad, ami nagyban leegyszerűsíti a további karbantartást.

Csábító a kiterjesztések használata kereskedelmi alkalmazások létrehozásához, de nem szabad. Először is azért, mert a bővítményeket nem ilyen feladatokra tervezték. Másodszor, mivel más platformmechanizmusok, például a szállítási és támogatási mechanizmusok nem tudnak semmit a kiterjesztésekről.

Ha kicsit belenézünk a kiterjesztések megjelenésének történetébe, akkor természetesen láttuk korábban, és most látjuk, hogy a konfigurációk egyre összetettebbek. Látjuk, hogy további támogatásra van szükség a különböző fejlettségi szinteken: könyvtár, moduláris és ipari stb. Mindezeket a feladatokat elemeztük, és arra a következtetésre jutottunk, hogy a legfontosabb Ebben a pillanatban a konfigurációk alkalmazkodása a felhasználók kívánságaihoz a megvalósítások során.

Erre a feladatra hoztuk létre a kiterjesztési mechanizmust. Természetesen észrevehetők benne a többi felsorolt ​​fejlesztési terület különböző vonásai. De nem ezek a fő célja, és nem zavarhatják meg.

Mit lehet most megváltoztatni a bővítményekkel?

Eddig nem sok minden történt a tervezetten. A mechanizmus természetesen fejlődni fog. De ami már megtörtént, sok esetben hasznos lehet a bevetéseknél. Most:

  • Megváltoztatható kezelt formák tipikus konfigurációban létezik;
  • Hozzáadhat újat alrendszerek... Megváltoztathatja a tipikus konfigurációban elérhető alrendszerek összetételét;
  • Megváltoztatható szerep egy tipikus konfiguráció, a bővítményben létrehozott objektumok hozzáadása hozzájuk;
  • Megváltoztatható parancs felület tipikus konfiguráció (fő szakasz, alrendszerek);
  • Hozzáadhat újat jelentésekés feldolgozás.

A jövőben azt tervezzük, hogy fokozatosan növeljük a bővítmények funkcionalitását, és örömmel vesszük véleményét arról, hogy milyen funkciókra van a legkisebb igény a kisebb módosításokkal rendelkező telepítéseknél.

Hogyan működik a kiterjesztés?

A bővítmény nagyon hasonlít a szokásos konfigurációhoz. Tárgyak fájaként is ábrázolják. A bővítménnyel való munkához ugyanazokat a munkamódszereket kell használni, mint a szokásos konfigurációnál.

A kiterjesztés fontos jellemzője a jelenlét kölcsönzött tárgyakat... Egy tipikus konfiguráció bármely objektumát kölcsönözheti a helyi menü parancs használatával:

A kölcsönzött tárgyakra nem mindig van szükség. Ennek legjobb magyarázata a „mindennapi” példa használatával, ha analógiát vonunk le az étteremben ebéddel.

Az első helyzet az, amikor kölcsönzött tárgyakra van szükség.

Már megszokta, hogy ugyanabban az étteremben étkezik. Mindig steaket és teát rendel. Például azért, mert nagyon jók ebben az étteremben. Vagy más okból. Nem számít. Az egyetlen fontos dolog, hogy megeszed őket, és semmi mást.

Akkor az étterem tipikus információs bázis. Ön egy kiterjesztés. Az étterem menüje bővíthető standard konfiguráció. A steak és a tea kölcsönzött tárgyak. Kölcsönkérted őket (ne feledd, hogy szerepelnek a menüben).

Hogyan kapcsolódik a bővítmény a konfigurációhoz és hogyan működik? Bemegy egy étterembe, és menüt kér. A menüben láthatja, hogy steak és tea van. Vagyis létrehozza a megfelelést a kölcsönzött objektumok és a tipikus konfigurációjú objektumok között. Természetesen a levelezést név szerint állapítja meg :). Hoznak steaket és teát, te pedig megeszed. Vagyis a bővítmény csatlakozik és működik.

Egy héttel később érkezik, de az étterem menüje megváltozott (a standard konfiguráció frissítve). A menüben azonban továbbra is steak és tea található. Pontosan ezekre van szüksége. Hozzák hozzád, te megeszed. Vagyis a bővítmény továbbra is működik a frissített tipikus konfigurációval.

Egy héttel később eljön egy étterembe, és látja, hogy a steak és a tea eltűnt a menüből. Felállsz és elmegy (a mellékállomás hibaüzenete). Mert ezt akartad. És fogalma sincs más ételekről (tárgyakról). A fejlesztő nem tanította meg, hogyan kell helyesen enni a csigákat vagy a homárokat.

Egy másik helyzet az, amikor kölcsönzött tárgyak nélkül is megteheti.

Elmegy egy étterembe, de nem érdekli az adott ételek elérhetősége. Mert úgysem fogod megenni őket. Csak fotózni szeretné őket. És tudod, hogyan kell fényképezni minden ételt. Ezután csak csatlakoztassa a konfigurációt, és azt mondja: vigye magával a menüben található összes harapnivalót (szerezzen be egy dokumentumgyűjteményt a metaadatokból). Újraküldöm őket (fénykép).

Ha ezt a fejlesztők száraz nyelvén írja le, kiderül, hogy kölcsönöznie kell az objektumokat:

  • Amikor szükség van rájuk a vizuális tervezéshez. Például kibont egy űrlapot, és hozzáad egy űrlap kelléket, például KönyvtárPénznemek.Link... Akkor persze kölcsön kéne venni a referenciát Pénznemek, hogy amikor egy tipikus konfigurációhoz csatlakozik, győződjön meg arról, hogy ilyen könyvtár még mindig létezik benne.
  • Amikor szükség van rájuk a kód működéséhez. Például a kiterjesztési kódban a referenciaattribútumra hivatkozik Elnevezéstan - Importőr... Ezután ezt az attribútumot is kölcsön kell venni annak biztosítása érdekében, hogy csatlakozáskor az ilyen attribútum még mindig létezik a referenciakönyvben a szabványos konfigurációban Elnevezéstan.

Bővítő csatlakozás

Bővítményt hoz létre a konfigurátorban. A hibakeresés és tesztelés után elutasíthatja a kiterjesztés * .cfe fájlba mentésével.

Ezt a fájlt átviheti az ügyfélnek. Az ügyfél önállóan tölti fel az adatbázisába 1C: Vállalati módban, a standard funkció használatával Konfigurációs bővítmények kezelése.

A bővítményekkel való munka a beépített nyelvből érhető el, így az alkalmazásmegoldásban létrehozhat saját feldolgozást, amely betölti a bővítményeket. Annak érdekében, hogy mindenki ne játsszon a bővítményekkel, új jogot adtunk hozzá - Konfigurációs bővítmények felügyelete.

Amikor kiterjesztést tölt be egy fájlból, a rendszer elmenti információs bázis... Ezenkívül az ebben a munkamenetben használt elválasztók aktuális értékeivel összefüggésben kerül mentésre.

A munkamenetet újra kell indítani, hogy a bővítmény működjön. Az ülés kezdetén, közvetlenül az esemény hívása előtt SettingSessionParameters, az információs bázisban tárolt és a munkamenet határolóinak aktuális értékeinek megfelelő összes bővítmény csatlakoztatásra kerül.

Ennek eredményeként, ha az adatmegosztási módban dolgozik, a bővítmény csak az adott előfizető felhasználóira lesz alkalmazva. És ha nem használnak adatszétválasztást, akkor a kiterjesztés az információs bázis minden felhasználója számára működik.

Bővítmény csatlakoztatásakor, amint már említettük, ellenőrzik, hogy kölcsönzött objektumok léteznek -e a tipikus konfigurációban. Az objektumok név szerint illeszkednek.

Ezenkívül finomabb szabályozás is lehetséges. Nemcsak az objektumok létezését, hanem azok egyedi tulajdonságainak állapotát is szabályozhatja. Vagyis, ha az étteremre és a steakre gondolsz, akkor fontos lehet számodra, hogy ne csak a valahogy megfőtt steak legyen jelen, hanem pontosan az, hogy itt főzetlenül, "vérrel" főzik.

Visszatérve a kiterjesztésre, alapértelmezés szerint nem szabályozza a kölcsönzött objektumok tulajdonságait. De ha szükséges, bizonyos tulajdonságokat szabályozhatóvá tehet. Például az algoritmus számára fontos, hogy ne csak referencia létezzen Elnevezéstan, hanem azt is, hogy a kód típusa Vonal.

Ezután, ha tipikus konfigurációban a szállító megváltoztatja a hivatkozás kódtípusát Szám, a bővítmény észleli ezt a csatlakozáskor, és hibát jelent.

Érdekes dolog a szabványos konfigurációs objektumok átnevezése. Például eljött egy étterembe, és ahelyett Steakírott Steak... Vagyis a konfigurációhoz való csatlakozáskor a kiterjesztés nem talál benne hivatkozást. Elnevezéstan mert az eladó átnevezte Áruk.

Most ez a helyzet nem jelent problémát az Ön számára. És nem kell "lapátolni" az összes kiterjesztési kódot úgy, hogy ahelyett Elnevezéstanírni Áruk... Működik és. Ezért csak meg kell változtatnia a kölcsönzött objektum nevét Áruk, és a bővítmény többi változtatását a platform maga fogja elvégezni. Vagy minimális segítséggel.

Bővítési munka

Hosszú ideig beszélhet a különböző objektumok kiterjesztésének jellemzőiről, magukról a kiterjesztésekről. De az áttekintő cikk hatóköre korlátozott minket, ezért csak a legfontosabb és leginkább leleplező pontokat érintjük.

A kiterjesztések fő "varázsa" természetesen nem az, hogy hozzáadhat valamit egy tipikus konfigurációhoz, ami nincs ott. És a tény az, hogy a bővítményben megváltoztathatja azt, ami már a szabványos konfigurációban van. Vagyis megváltoztathatja a kölcsönzött objektumok tulajdonságait.

A konfiguráció és a kiterjesztés együttes működése során használt alapkoncepció a következőképpen írható le. Ahol „nem fedik egymást”, a bővítmény kiegészíti a konfigurációt. Azokon a helyeken, ahol "metszik" - a kiterjesztést alkalmazzák.

Ez részletesebben látható a felügyelt űrlapok példáján. Az űrlapot kölcsönözheti a fő konfigurációból, és korlátozások nélkül szerkesztheti a bővítményben. Az űrlap vizuális részéhez és moduljához két különböző egyesítési stratégiát használnak.

Az űrlap vizuális része a kölcsönzéskor rögzítve van a bővítésben. Az 1C: Vállalati módban pedig az űrlap egyes elemeinél a változásokat ehhez az állapothoz képest elemzik a szabványos konfigurációban és a bővítményben.

Ha nem történt változás, vagy csak a tipikus konfigurációban történt, akkor a tipikus konfigurációból származó érték kerül alkalmazásra. Ellenkező esetben a kiterjesztésből származó érték kerül felhasználásra.

Így ha új parancsot adott hozzá az űrlaphoz a kiterjesztésben, akkor azt az űrlap többi parancsával együtt látni fogja. Ha pedig egy létező csoport címsorát módosította, akkor a címsort akkor is látni fogja, ha a szolgáltató megváltoztatja ennek a csoportnak a címét a szabványos konfigurációban.

Az űrlapmoduloknál más megközelítést alkalmaznak. A kölcsönzött űrlaphoz a kiterjesztés minden modulhoz saját modult hoz létre saját kezelőivel. 1C: Vállalati módban mindkét űrlapmodul (egy tipikus konfigurációból és egy bővítményből) egy kontextusban van kombinálva. Ezért minden bővítmény saját előtaggal rendelkezik, amelyet az űrlapmodul minden eseménykezelőjéhez hozzáad. Annak érdekében, hogy ne legyenek egyezések a kezelőkkel a tipikus konfigurációból. Az esemény- és parancskezelőket ezután sorrendben és szinkronban hívják meg. Először a kezelő a bővítményből. Aztán egy tipikus konfigurációból. Megváltoztathatja ezt a sorrendet, vagy teljesen letilthatja a kezelő végrehajtását a szokásos konfigurációból.

Általában, ami azt illeti együtt dolgozni konfigurációk és bővítmények 1C: Enterprise módban, közös névtérben léteznek. Ez nemcsak az egyes modulokra vonatkozik, hanem magukra a metaadatfákra is. Ezért az 1C: Enterprise módban nincs mód annak megállapítására, hogy ez az objektum "natív" egy tipikus konfigurációhoz, vagy kiterjesztésből származik -e.

Ami a többi bővítményben használható objektumot illeti, minden sokkal egyszerűbbnek tűnik számukra.

A bővítményben saját alrendszereket hozhat létre. A kölcsönzött objektumok használatával kibővítheti a meglévő alrendszereket: hozzáadhat hozzájuk olyan objektumokat és alrendszereket, amelyek már a szabványos konfigurációban vannak, vagy amelyeket a bővítményben hozott létre. Nem törölhet valamit a meglévő alrendszerből.

A szerepköröket csak úgy bővítheti ki, ha hozzáadja hozzájuk a bővítményben létrehozott objektumokat. Ön sem távolíthat el semmit a meglévő szerepkörből. Ugyanez vonatkozik a parancsfelületre is.

A bővítés szinte konfiguráció

Az elején azt mondtuk, hogy egy bővítmény úgy néz ki, mint egy szokásos konfiguráció. Ezért befejezésül szeretnék néhány szót mondani arról, hogy a bővítmények hogyan integrálhatók más platformmechanizmusokkal.

A kiterjesztés (mint a szokásos konfiguráció) alapvető konfigurációval és adatbázis -konfigurációval rendelkezik. A konfigurációk összehasonlításának és egyesítésének mechanizmusa a kiterjesztésekkel ugyanúgy működik, mint a szokásos konfigurációkkal.

Letöltheti a kiterjesztést egy fájlba (bár más kiterjesztéssel * .cfe), és betöltheti a fájlból. A kiterjesztések ki- és betölthetők XML -ben.

A globális keresés, lecserélés, az interfészszövegek szerkesztésének mechanizmusai a kiterjesztésekkel is működnek.

Új parancssori paraméterek vannak a bővítmények kezeléséhez, valamint új események a naplóban.

A beépített nyelven a kiterjesztések kezelésének fő objektuma az Bővítménykezelő.

A konfigurációbővítő mechanizmus egy speciális mechanizmus, amelynek célja egy bővíthető konfiguráció módosítása a konfiguráció megváltoztatása nélkül (beleértve a támogatásból való eltávolítás nélkül is).

A konfigurációbővítési mechanizmus mérlegelésekor a következő kifejezéseket kell használni:

  • Bővíthető konfiguráció- a fő infobázis -konfiguráció, amelyhez a bővítményt alkalmazzák, vagy amelyhez a bővítményt fejlesztik.
  • A konfiguráció bővítése- konfigurációs objektumok halmaza, amely bővíthető konfigurációhoz kapcsolódik, és amely kiterjeszthető konfigurációhoz hozzáadott objektumkészletet tartalmaz. A kiterjesztés kiterjeszthető konfigurációs objektumokat és olyan objektumokat is tartalmazhat, amelyek nincsenek jelen a bővíthető konfigurációban.
  • Saját objektum- önálló konfigurációs objektum, amely lehet bővíthető konfigurációban vagy kiterjesztésben (jelentés, feldolgozás vagy alrendszer).
  • Kölcsönzött tárgy- saját objektum hozzáadva a konfigurációs kiterjesztéshez.
  • Bővíthető objektum- saját objektum, amelynek néhány paramétere (tulajdonsága, formája stb.) megváltozott a kölcsönzött objektumban.
  • Bővülő objektum Kölcsönzött objektum, amelyet a kiterjesztett objektumhoz képest módosítottak. A kölcsönzött objektumban csak felügyelt tulajdonságok jelenléte nem teszi a kölcsönzött objektumot kibővíthetővé.
  • A kapott objektum Natív objektum és az összes kiterjesztési objektum egyesítése (ha több kiterjesztés van). Ha a saját objektumhoz nincsenek kiterjesztő objektumok, akkor az lesz a „nincs változás”. Azok. a konfigurációban, amellyel a felhasználó dolgozik - minden objektum eredő, függetlenül a telepített bővítmények jelenlététől és számától.
  • Bővülő tulajdonság- a kölcsönzött objektum tulajdonsága, amely megváltoztatja a kiterjesztett objektum azonos nevű tulajdonságát.
  • Ellenőrzött ingatlan- a kölcsönzött objektum tulajdonsága, amelynek értékét a bővítmény csatlakoztatható a bővíthető konfigurációhoz ellenőrzi. Ha egy bővítmény csatlakoztatásakor (1C: vállalati módban) a megfigyelt tulajdonság értéke a bővítményben nem egyezik meg a kiterjeszthető konfigurációban szereplő ugyanazon tulajdonság értékével, akkor a bővítmény nem lesz engedélyezve.
  • Módosítható tulajdonság- a kölcsönzött objektum tulajdonsága, amelynek értékét a kapott objektumban a kiterjesztésből nyerjük.

Egy kölcsönzött objektumtulajdon nem lehet egyszerre ellenőrizhető és módosítható.

A konfigurációs kiterjesztés fő célja az alkalmazásmegoldás finomítása a megvalósítás során (vagy a "felhőben") az ügyfél igényeinek megfelelően. Ebben az esetben a véglegesített konfigurációt nem kell eltávolítani a támogatásból. Ennek eredményeként a támogatott tipikus alkalmazásmegoldások egyszerű frissítése megmarad, és szükség van a fejlesztések elvégzésére. Egy bővítmény fejlesztésekor meg kell értenie a konfigurációs bővítmény működésének néhány jellemzőjét. Így a bővíthető konfiguráció bármikor megváltoztatható, például egy frissítés eredményeként. Ebben az esetben a bővítmény fejlesztője semmilyen módon nem befolyásolhatja a frissítés lehetőségét vagy lehetetlenségét. Figyelembe kell vennie azt a tényt is, hogy több kiterjesztés is működhet a rendszerben, és minden bővítmény szerzője (általában) nem tudja, hogyan működik egy másik kiterjesztés.

A kiterjesztés a konfigurátorban jön létre, az információs bázisban tárolódik, és fájlba menthető. Nincs szükség a konfigurátorra egy fájlba mentett kiterjesztés hozzáadásához (csatlakoztatásához) egy adott ügyfél alkalmazásmegoldásához. Bővítményt csatlakoztathat egy speciális szabványos funkcióval (Minden funkció - Standard - Konfigurációs bővítmények kezelése). Bővítményt is csatlakoztathat az alkalmazásmegoldás eszköztárával, amely a platform által biztosított programozási felületet használja. Bővítmény csatlakoztatása (interaktív módon vagy a beépített nyelvről) lehetséges nem biztonságos módban, vagy ha a biztonsági profil, amely alatt a munkamenet fut, lehetővé teszi a hozzáférést a csatlakoztatott mellékhez.

A kibontható objektumok lehetnek:

  • Felügyelt űrlapok;
  • Szerepek;
  • Alrendszerek;
  • Az alkalmazott megoldás kezdőlapjának (asztal) beállításai;
  • Közös modulok;
  • Objektum modulok minden típusú objektumhoz;
  • Kezelő modulok minden típusú objektumhoz;
  • Session modul;
  • Felügyelt alkalmazás modul;
  • Külső csatlakozó modul;
  • Parancsmodulok.

A kiterjesztési objektumok lehetnek:

  • Alrendszerek;
  • Feldolgozás;
  • Jelentések;
  • Tulajdonságok, táblázatos szakaszok és táblázatos szakaszok attribútumai kölcsönzött feldolgozásban és jelentésekben;
  • Szerepek;
  • XDTO csomagok;
  • Webes szolgáltatások;
  • HTTP szolgáltatások;
  • WS linkek
  • Általános elrendezések;
  • Általános parancsok;
  • Közös modulok (kivéve a globális szervert és a kiváltságos közös modulokat);
  • Csapatcsoportok;
  • Általános képek;
  • Alakzatok, elrendezések és kölcsönzött objektumparancsok:
  • Cseretervek;
  • Kiválasztási kritérium;
  • Beállítások tárolása;
  • Referenciakönyvek;
  • Dokumentumok;
  • Dokumentum folyóiratok;
  • Felsorolás;
  • Jelentések;
  • Feldolgozás;
  • Információs nyilvántartások;
  • Felhalmozási nyilvántartások;
  • Számviteli nyilvántartások;
  • Számítási regiszterek;
  • Jellegzetes típusok diagramjai;
  • Számlák;
  • Számítási típusú tervek;
  • Üzleti folyamatok;
  • Feladatok;
  • Az asztalokról külső források adat;
  • Külső adatforrás kockák;
  • Dimenziótáblák külső adatforrásokhoz.

Az ellenőrzött ingatlanok közül ki kell emelni:

  • Csereterv összetétele;
  • Előre meghatározott elemek a katalógusokhoz, a jellemző típusok diagramjai, a számlatérképek és a településtípusok diagramjai.

A kiterjesztések használata nem támogatott az alkalmazott megoldások alapvető verzióiban.

Az 1C: Enterprise platform 8.3.6 verziójától kezdve egy mechanizmus jelent meg benne konfigurációs kiterjesztések.

Lehetővé teszi új funkciók hozzáadását és meglévő funkciók felülbírálását a fő (bővíthető) konfiguráció megváltoztatása nélkül. Így rengeteg új lehetőség áll előttünk, amelyek korábban nem voltak elérhetők.

Új lehetőségek

Korlátozások

Természetesen vannak korlátozások is:

  • A bővítményekhez csak korlátozott számú új metaadat adható hozzá. Ezek alrendszerek, szerepek, jelentések, feldolgozás és néhány más.
  • Bizonyos esetekben problémák merülhetnek fel a hibakereséssel.

Használati példa

Vegyünk egy példát arra, hogyan lehet felülbírálni egy általános modul eljárást egy konfigurációs kiterjesztéssel. Vagyis ez az az eset, amikor gyorsan ki kell javítanunk valamilyen hibát anélkül, hogy kiadnánk a kiadást és frissítenénk a fő konfigurációt. Tegyük fel, hogy van egy közös modulunk professia1c_ry_Bővítmények.

És a legegyszerűbb eljárást tartalmazza, amely üzenetet jelenít meg:

Eljárás OutputMessage () Export Message = New MessageUser; Üzenet. Szöveg = "Ez a fő konfiguráció"; Üzenet. Jelenteni() ; Az eljárás vége

Most jelenítsünk meg egy másik üzenetet a kiterjesztés használatával. Mindenekelőtt természetesen magát a bővítményt kell létrehoznunk. A konfigurátor menüben válassza a lehetőséget Konfiguráció - A konfiguráció bővítése


A megnyíló ablakban nyomja meg a gombot Hozzáadásés töltse ki a mezőket kiterjesztési tulajdonságokkal. Mezők Névés Szinonima nincs szükség megjegyzésre. Az előtag lesz a kiterjesztési eljárás neve, amely helyettesíti az eredetit. És a listán Időpont egyeztetés háromból lehetséges lehetőségek(Javítás, Alkalmazkodás, Kiegészítés) válassza Javítás:

Ezután a bővítmények listájában törölje a jelölőnégyzeteket Biztonságos mód, biztonsági profil neveés "Védelem a veszélyes cselekedetek ellen":


Így hoztuk létre a kiterjesztést. De ha dupla kattintással megnyitjuk, látni fogjuk, hogy a metaadat -fa üres. És most hozzá kell adnunk egy közös modult a bővítményhez.

Ehhez a fő konfiguráció metaadatfájában kattintson a jobb gombbal a kívánt általános modulra, és válassza ki az elemet "Hozzáadás a bővítményhez":


És most a bővítményünk így fog kinézni:

De ha megnézzük a közös bővítőmodul kódját, látni fogjuk, hogy üres. A következő lépés pedig egy eljárás hozzáadása hozzá. Menjen újra a fő konfigurációhoz, nyissa meg a közös modul kódját, kattintson a jobb gombbal az eljárásra, válassza ki újra az elemet "Hozzáadás a bővítményhez"és a megnyíló ablakban válassza ki a hívás típusát Hívjon helyette:

Ennek eredményeként a következő kóddal rendelkező eljárás kerül hozzáadásra az általános bővítőmodulhoz:

& Helyett ("DisplayMessage") Eljárás Message_DisplayMessage () // A módszer tartalmának beszúrása. ContinueCall (); Az eljárás vége

Mint látható, az eljárás neve tartalmaz egy előtagot, amelyet a kiterjesztés létrehozásakor adtak meg. Most már csak az eljárás kódját kell módosítanunk a szükség szerint:

& Helyett ("DisplayMessage")Üzenet_DisplayMessage_ () Üzenet = Új üzenet a felhasználónak; Üzenet. Text = "Ez egy kiterjesztés"; Üzenet. Jelenteni() ; Az eljárás vége

És most könnyen meggyőződhet arról, hogy a fő konfigurációs kód helyett a kiterjesztési kódot futtatjuk a következő kód végrehajtásával:

Professia1c_ry_Extensions. DisplayMessage ();

Miután tanulmányozta a program korábbi verzióinak használatában szerzett tapasztalatokat, és figyelembe vette azt a tényt, hogy akármilyen univerzális és átfogó is egy adott megoldás, végül az esetek 90% -ában módosítani kell a végfelhasználó számára. Az 1C program 8. verziójának fejlesztői számos alapvetően új megoldást vezettek be, hogy minimálisra csökkentsék a szabványos konfigurációs mechanizmusok megváltoztatásának szükségességét:

  • Szó szerint a program első verzióiból sok könyvtár elemei képesek további tulajdonságokat és kategóriákat létrehozni a jellemző típusok megfelelő tervének és az információregiszternek megfelelően;
  • További nyomtatott nyomtatványokés a táblázatos szakaszok kitöltésére szolgáló űrlapok, valamint a további jelentések és feldolgozás mostantól a megfelelő könyvtárból hívhatók le;
  • Az objektumok szabványos eljárásainak feldolgozása nem a modul módosításával történik, hanem az eseményekre való feliratkozással;
  • És végül a platform 8.3.6 -os verziójából konfigurációs kiterjesztések jelentek meg az 1C -ben.

Mik az 1C konfigurációs bővítmények, hogyan kell velük dolgozni, használati korlátozások - ez az a kérdéskör, amelyet megpróbálunk feltárni cikkünkben.

Egy kis elmélet

A kiterjesztési mechanizmus bevezetése előtt a tipikus konfigurációk frissítési folyamata nagymértékben függött attól, hogy a konfiguráció támogatott -e vagy módosult. Az utóbbi esetben a fejlesztőnek:

  1. Hasonlítsa össze a tipikus és elérhető metaadat -struktúrát;
  2. Ha jelentős eltérések vannak a standard elemekben, kövesse a helyes frissítést;
  3. Végezze el a megfelelő módosításokat a frissítés után.

Mindez nagyban megnehezítette a frissítési folyamatot, megnövelte a munkaidőt, és gyakran megfosztotta a szervezetet a szabványos modulok frissítésének lehetőségétől drága szoftver.

A bővítő mechanizmus lehetővé teszi számos elemének módosítását anélkül, hogy eltávolítaná a szabványos konfigurációt a támogatásból. Valójában a fejlesztő a tipikus megoldás alapján létrehozza saját konfigurációját, amely a tipikus megoldás héja. Ebben az esetben a szabványos rész frissítési folyamata automatikusan megtörténik, amikor a végfelhasználó elindítja, a platform mindkét megoldást egyesíti a felhasználó számára.

Olyan helyzetek, amelyekben a bővítmények használhatók

Mint minden más eszköz, a kiterjesztési mechanizmusnak számos jellemzője és korlátozása van, amelyek meghatározzák használatuk körét:

  • A bővítmények működhetnek felügyelt űrlapokkal;
  • A mechanizmus támogatja a meglévő alrendszerek módosítását és hozzáadását;
  • A 8.3.8 platform megjelenése előtt a bővítmény csak a meglévő szerepeket tudta megváltoztatni; a frissítés után lehetővé tették újak hozzáadását, korlátozva a hozzáférést még a fő bázis objektumaihoz is;
  • A meglévő mechanizmus lehetővé teszi maguktól módosítsa az alrendszerek parancsfelületét és a fő konfigurációs részt;
  • Ezenkívül ez az eszköztár lehetővé teszi feldolgozás és jelentések hozzáadását anélkül, hogy módosítaná az alap szerkezetét;
  • A platform 8.3.9.718 verziójában a bővítmény és a fő konfiguráció kompatibilitásának diagnosztizálásának mechanizmusát jelentősen átalakították.

A fentiekből kiderül, hogy:

  1. Ha rendszeres nyomtatványokkal dolgozik, a bővítmények funkcionalitása jelentősen korlátozott;
  2. Bár a fő konfiguráció frissítésének folyamatát megkönnyítették, egy adott kiterjesztés (beleértve a sorozatgyártású megoldásokat is) használatának lehetőségét komolyan korlátozhatja mind az eredeti szerkezet megváltoztatása, mind több párhuzamosan használt bővítmény;
  3. Célszerű ezt a mechanizmust alkalmazni olyan esetekben, amikor differenciálásra van szükség megjelenésés a különböző felhasználók által használt funkciók, vagy amikor a támogatott tipikus konfigurációt önmagában finomítják.

Térjünk át a gyakorlásra. Kiindulási alapként a "Fizetés és személyzet menedzsment" 3.1.3.223 verzióját fogjuk használni, a munkát a 8.3.10.2561 platformon kell elvégezni, az üzemmód fájl.

Bővítmény létrehozása

A konfigurátorban lépjen a Konfiguráció-> Konfigurációs bővítmények menübe, és megnyílik egy űrlap (1. ábra).

Itt hozhat létre új bővítményt. Nyomjuk meg a "Hozzáadás" gombot. Itt az új kiterjesztési ablak (2. ábra)

2. ábra

Vegye figyelembe elemeit:

  • Név - más konfigurációs elemekkel ellentétben nem a rendszer szabványai szerint jön létre, azaz számokkal vagy szimbólumokkal kezdődhet, szóközt tartalmazhat;
  • Szinonima - csakúgy, mint más metaadat -elemek, az objektumot reprezentáló kifejezést tartalmazza;
  • Előtag - lehetővé teszi az eseménykezelők azonosítását az űrlapmodulban, mivel a fő konfigurációs űrlapmodul és a kiterjesztési űrlapmodul kombinálva van, amikor a platform közös kontextusban dolgozik (alapértelmezés szerint a bővítmény kerül először feldolgozásra, azaz a kezelők előtag, majd a fő kezelők);
  • Időpont egyeztetés.

A "Cél" mező listája három értékből áll, ezeket a végrehajtás sorrendjében írjuk le:

  1. Javítás - a hozzárendelés kiterjesztései a kölcsönzött objektumokban előforduló kisebb pontatlanságok és hibák kijavítására jönnek létre;
  2. Alkalmazkodás - az alapértelmezett érték, az ilyen típusú bővítmények úgy vannak kialakítva, hogy a tipikus objektumokat egy adott felhasználó igényeihez igazítsák (ha a kiterjesztést a 8.3.9 alatti programverzióban hozták létre, akkor a platformfrissítés után pontosan ez lesz a célja);
  3. Kiegészítés - teljesen új funkcionalitást hoznak a standard megoldásba.

A kiterjesztés elindítása

Ha duplán rákattint a kiterjesztés nevére az 1. ábrán látható ablakban, megnyílik a kiterjesztési ablak (3. ábra)


Mint látható, ez egy fa, amely hasonló a fő konfigurációs fához. És itt felmerül egy kérdés, hogy milyen esetekben kell kölcsönözni egy tárgyat?

Csak azokat a tárgyakat (referenciakönyveket, dokumentumokat, kellékeket stb.) Kell kölcsönözni, amelyeket az űrlap kiterjesztésében vagy a modul kódjában használnak, és kölcsönzés nélkül, amelyek hibát okozhatnak a a kiterjesztést.

Vagyis ha fejlesztésünk megköveteli a referenciakönyv szükséges "INN" -ét " Egyének", Ha űrlapmodulban fogják használni, akkor kölcsön kell vennünk a fő bázisból. Ebben az esetben minden alkalommal, amikor a kiterjesztést elindítják, ellenőrizni fogják, hogy ez az attribútum jelen van -e a fő konfiguráció referenciakönyvében, és hogy az adattípus megfelel -e a forrásadatbázisban és a kiterjesztésben.

Ha a frissítés után vagy egy új funkció kifejlesztése során következetlenség tapasztalható a bővítmény adattípusai és a konfiguráció között, vagy más hiba lép fel, a rendszer erről tájékoztatja a felhasználót (4. ábra)

A jobb alsó sarokban lévő ablak jelzi nem szabványos helyzet bővítmény csatlakoztatásakor duplán kattintva megnyílik részletes információk... Ebben az esetben egyszerűen megváltoztattuk az INN változó értéktípusát a "String" értékről a "Boolean" értékre a kölcsönzött objektum esetében, de az ellenkező helyzet sokkal gyakoribb - amikor egy szabványos termék frissítése egy a fő bázisváltozó megváltoztatása vagy megszüntetése.

Miután kidolgozta és tesztelte a bővítményt az adatbázis másolatán, feltöltheti azt egy külön fájlba, ehhez kattintson az ablakban (5. ábra) a „Konfiguráció” gombra, válassza a „Mentés fájlba” elemet . A cf kiterjesztéssel rendelkező szokásos konfigurációs fájlokkal ellentétben a konfigurációs bővítmény * .cfe maszkja lesz.

Amint a fenti ábrán látható, az új funkciókat ugyanabból az ablakból vagy a program főablakából töltheti be.

A bővítmény 1C módban való csatlakoztatásához. Enterprise, a felhasználónak engedélyeznie kell a Minden funkció módot, és a programnak rendszergazdai jogosultságokkal kell bejelentkeznie.

A revízió csatlakoztatásának útvonala a következő: Minden funkció-> Normál-> Konfigurációs bővítmények kezelése. A megnyíló ablak a 6. ábrán látható

6. ábra

A "Hozzáadás" gombra kattintva megnyílik egy fájlkiválasztó párbeszédpanel, amelyben ki kell választania a feltöltésünket. Ha a feldolgozás jelölőnégyzet be van jelölve (7. ábra), és a kiterjesztés hibát tartalmaz, a funkció kapcsolata megszakad, és a program kivételt jelent.

7. ábra

Annak érdekében, hogy funkcionalitásunk a sikeres kiegészítés után is működjön, a programot újra kell indítani.

Tárgykölcsönzés és modulgyújtási sorrend

A kezelők végrehajtási sorrendjének nyomon követése érdekében lehetővé tesszük a konfigurációnk megváltoztatását és kiegészítését új kezelés, amelynek funkcionalitása csak egy dologból fog állni - jelenteni fogja, hogy a fő konfigurációból indult, a 8. ábra kódjából.

8. ábra

Adjuk hozzá ezt a feldolgozást a kiterjesztéshez.

Ezért:

  • A jobb egérgombbal aktiválja a feldolgozó űrlap helyi menüjét (9. ábra);

9. ábra

  • Válassza ki a „Hozzáadás a bővítményhez” elemet;
  • A további konfigurációs fában mind a feldolgozás, mind az űrlap másolata megjelenik;
  • Miután megnyitottuk az űrlapot, azt tapasztaljuk, hogy van egy parancs is, amely meghívja az üzenetet, csak nincs hozzárendelve kezelő;
  • A parancsművelet hozzáadása egy párbeszédpanelt hív meg (10. ábra), amelyben a parancsvégrehajtási hely fő irányelvei mellett létezik egy „Hívás típusa” nevű csoport is.

10. ábra

Háromféle felhívásunk van egy meglévő eljárásra;

  • Hívás előtt - a mellékkód végrehajtása a fő konfiguráció végrehajtása előtt kezdődik;
  • Hívás után - a módosított eljárás a második;
  • Ehelyett hívjon - a fő konfigurációból származó eljárás egyáltalán nem lesz végrehajtva.

Hagyja a hívástípust a "Hívás után" pozícióban, és adja hozzá az "Exp1_NotifyAfter (Parancs)" eljárást (11. ábra).

11. ábra

A feldolgozás megkezdésének eredménye két egymást követő mondat lesz (12. ábra), vagyis egy további konfigurációs üzenet jelenik meg a főüzenet után. Ha az "Ehelyett" választottuk volna, egyáltalán nem láttuk volna az első sort.

12. ábra

A 8.3.9.1818 verziótól kezdve a szabványos modulok cseréjének mechanizmusa, valamint a saját modulok hozzáadása a program funkcionalitásába került. És itt a fejlesztők egy nagyon specifikus feladattal szembesültek: hogyan lehet meghatározni, hogy a kölcsönzött eljárásokat és funkciókat milyen sorrendben kell végrehajtani nemcsak a fő konfiguráció, hanem a konfigurációban már csatlakoztatott bővítmények vonatkozásában is.

Jegyzetmotor

Képzeljünk el egy helyzetet, amikor több bővítmény is csatlakozik egy konfigurációhoz, vagyis a konfigurációs ablakban a kiválasztásukhoz tartozó ablak így néz ki (13. ábra)

13. ábra

Minden új bővítmény hozzáadásakor a rendszer önállóan felépíti végrehajtásuk sorrendjét.

A további modulok végrehajtási sorrendjének beállítása nemcsak a modul hozzáadásának idején (később hozzáadva, később végrehajtva), hanem a felülvizsgálat célján is alapul (a "Végrehajtás" mindig az "Adaptációk" előtt lesz).

Ezenkívül a hozzáadott modulok eljárásainak végrehajtási sorrendje a megjegyzések segítségével állítható be:

  • & Before ("ProcedurName");
  • & After ("ProcedurName");
  • & A ("ProcedName") helyett.

Mint látható, készletük hasonló az előző részben bemutatottakhoz, a funkcionalitás is hasonló.

Mivel a kölcsönzött modul és az adományozó modul ugyanabban a névtérben van, ebben az esetben nincs szükség további definíciókra a típusváltozókhoz és metódusokhoz.

A funkciókkal némileg más a helyzet, mint az eljárásokkal. A tény az, hogy egy tipikus eljárás végrehajtását mintegy bővítőkóddal lehet szegélyezni, vagyis néhány műveletet beilleszthet az eljárás kódja elé, néhány algoritmust utána, de ez nem működik a függvényeknél. Ha a fő funkciót a kiterjesztési kód után hajtják végre, akkor a cserefunkció visszatérési értéke nem érkezik meg, ha a megváltozott algoritmus előtt a főfunkció értéke nem érkezik meg, és a & kommentár & & helyett működik.

Ennek az "igazságtalanságnak" kiküszöbölésére létrehozták a ContinueCall () metódust.

Általánosságban elmondható, hogy az "Ehelyett" feliratok használata kissé helytelen, bár néha szükséges. Használatával jelentősen korlátozzuk a jellemző konfigurációkban jelentősen megváltoztatható és javítható funkcionalitást.

Változtatások az objektum modulon

Az esemény -előfizetési mechanizmus nagyban megkönnyítette a fejlesztők munkáját, de volt egy komoly DE.

A használathoz azonban gyakran saját közös modult kellett létrehoznia, amely bizonyos műveletek adatokkal történő feldolgozására vonatkozó eljárásokat tárol. Jelenleg a bővítmények használata lehetővé tette ezen funkciók jelentős felülvizsgálatát.

Tegyük fel, hogy a munka során hozzá kellett adnunk valamilyen feldolgozást egy tipikus "Hiring" dokumentumhoz, amikor azt rögzítették. Korábban az előfizetésekre mentünk, és onnan cselekedtünk, most hozzáadhatjuk ezt a dokumentumot a kiterjesztéshez:

  • A konfigurátorban válassza a "ReceiveNoWork" lehetőséget, és a helyi menüből adja hozzá a kiterjesztésünkhöz (egyébként ez a mechanizmus az Alt + Shift + F2 gyorsbillentyűk kombinációját tartalmazza);
  • A megfelelő kiegészítő kiválasztása után képet kapunk, mint a 14. ábrán;

14. ábra

  • Érdeklődni fogunk a sárga színnel kiemelt "Objektum modul" elem iránt, nyissuk meg a megfelelő jelölőnégyzet aktiválásával (15. ábra);

15. ábra

  • Megkapjuk tiszta lap a programmodul közül figyeljünk a felső panelre, vagy inkább a 16. ábrán látható elemre, a legördülő listában vannak események, amelyek feldolgozhatók ehhez az objektumhoz;

16. ábra

  • Próbáljuk meg megjeleníteni a dokumentum számát az üzenetben rögzítéskor a megfelelő esemény kiválasztásával;
  • Kapunk egy űrlapot a hívás típusának kiválasztásához (17. ábra), határozzuk meg, mikor jelenik meg a szám;

17. ábra

  • Az eljárás kódja a 18. ábrán látható;

18. ábra

Bizonyos esetekben a "Biztonságos mód" jelölőnégyzet miatt a bővítmény hibával kapcsolódik.

Kis bejelentés

A közeljövőben az 1C a 8.3.11 platform kiadását tervezi, amelyben bejelentették saját lehetőségük hozzáadását:

  • Dokumentumok;
  • Referenciakönyvek;
  • Cseretervek;
  • Információs nyilvántartások.

Az attribútumok és táblázatos szakaszok hozzáadásának lehetőségét is megvalósítani kell. A fejlesztők ugyanakkor figyelembe vették a szabványos megoldások megváltoztatásának lehetőségét, ami a bővítmény működésének meghibásodásához vezethet.

A kiterjesztésbe bevitt adatok nem vesznek el sehol, és amíg a kompatibilitási probléma nem oldódik meg, addig a bővítmény által módosított fő konfiguráció hivatkozása nem lesz írható.