A CSENGŐ

Vannak, akik előtted olvassák ezt a hírt.
Iratkozzon fel a legújabb cikkekért.
Email
Név
Vezetéknév
Hogy szeretnéd olvasni a Harangszót
Nincs spam

Speciális konfiguráció "1C: Adatkonverzió 2.0"

Az 1C:Enterprise platform nyolcadik verziójának megjelenése jelentős lépés az automatizálási rendszerek fejlesztésében. Az 1C:Enterprise 8 platform tervezésekor figyelembe vették az 1C:Enterprise 7.7 platformra épülő megoldások használatának hatalmas tapasztalatait: a platform beépített nyelvét és a tipikus konfigurációkat komolyan átalakították, az adattárolás és hozzáférés felépítését. megváltozott, új iparági megoldások születtek, amelyek realizálják az új platform előnyeit. A korábbi nyelvi konstrukciók használata az új platformon nem megfelelővé vált.

A probléma megoldásának megkönnyítése érdekében (adatátvitel a 7.7-es verzióról a 8-as verzióra), az 1C kiadott egy speciális konfigurációt "Data Conversion 2.0". Azért hozták létre, hogy segítse a szakembereket az adatátvitel különböző problémáinak megoldásában. Az 1C kész szabályokat adott ki az azonos típusú konfigurációkból származó adatok átviteléhez, például az 1C: Accounting 7.7-ből az 1C: Accounting 8-ba, de a nem szabványos vagy módosított szabványos konfigurációk felhasználói, amikor az 1C: Enterprise 8 platformra váltanak. Önnek kell létrehoznia az átviteli szabályok adatait.

Az adatátviteli problémák megoldásának sokféle privát módszerével a megoldandó kérdések köre gyakorlatilag változatlan marad:

Referencia információk szinkronizálása (új létrehozása, frissítése meglévő elemeket könyvtárak, hierarchia törlése, mentése vagy módosítása, adatok elágazása, időszakos részletek értékeinek változástörténetének átvitele);

Dokumentumok és műveletek szinkronizálása (dokumentumok létrehozása, módosítása vagy egyik dokumentumtípus átalakítása másikba, összevonás vagy sokszorosítás);

Elegendő kezdeti feltételek megteremtése a számviteli nyilvántartások vezetéséhez gazdasági aktivitás(maradék áruszállítás stb.).

Az 1C:Enterprise különböző verzióinak és/vagy konfigurációinak adattárolási struktúrái eltérőek, így az adatátvitel nem csak fájlok vagy táblák másolása, hanem azok átalakítása. Ahhoz, hogy az átalakítás egyértelmű és helyes legyen, szükséges az adatátviteli szabályok létrehozása és konfigurálása. A különböző infobázisok közötti adatátviteli szabályok létrehozása és konfigurálása lehetséges, ha ismert az adattárolás szerkezete a forrás- és céladatbázisokban. A konfigurációs metaadat-struktúra leírásának egységesnek kell lennie. A "Data Conversion 2.0" konfiguráció adatátviteli szabályok létrehozására és konfigurálására szolgál a forrás- és célkonfigurációs metaadat-struktúra leírása alapján.

Az információs bázisok közötti adatátvitel folyamata a következő lépésekből áll:

  • 1. Metaadatleíró fájlok létrehozása.
  • 2. Konfigurációk létrehozása az "Adatkonverzió" alatt.
  • 3. Maga az átalakítás létrehozása.
  • 4. Adatkonverziós szabályok következetes megalkotása.
  • 5. Adatfeltöltési szabályok következetes megalkotása.
  • 6. Az adatok egyik konfigurációból a másikba történő ki- és betöltési folyamata.

Mert ennek a speciális konfigurációnak a használata az egyik leghatékonyabb Ebben a pillanatban az ilyen jellegű problémák megoldásának módjai, és ezen túlmenően a személyes tapasztalatok forrása, amely nagyon hasznos oktatási célokra, majd az IS „Server: Rent Calculation” és az „1C: Enterprise Accounting” közötti adatcsere mechanizmusának kidolgozása. " az LLC "LLC" esetében, a "Data Conversion 2.0" konfiguráción alapuló módszer.

Az adatkonverzió 2.0 és 2.1 egy 1C technológiai konfiguráció, amelyet a 8.1-től 8.3-ig terjedő platformverziókon valósítottak meg.

Az eszköz fő feladata az 1C 8 és 7 alkalmazásmegoldások közötti csereszabályok írása.Az adatkonverzió jelenlegi verziója a 3.0.

Az adatkonverzió egy nagyon hasznos konfiguráció, amellyel nem csak az egyik infobázisból a másikba való információátvitel, hanem például egy adatbázison belüli információk konvertálása is megoldható.

A konfiguráció nagyon kényelmesen használható, ha .

Az adatkonverzió minden programozó számára hasznos lesz: a csereszabályok létrehozásához szükséges készségek komoly pluszt jelentenek a szakmai készségekhez.

A konfigurációval való munka megtanulásához a gyakorlati problémák megoldása a legalkalmasabb. Próbáljon meg feladatokat kitalálni magának, például: vigyen át bármilyen információt egyik adatbázisból a másikba, alakítson át egy megvalósítási dokumentumot nyugtadokumentummá, „vezessen” folyó egyenlegek tovább könyvelés az „egyenlegek bevitele” és egyéb feladatok dokumentumban.

Nagyon hasznos lesz megérteni az 1C 8.3 csere "tipikus" szabályait, ahol gyakran találhat érdekes példákat a feladatok végrehajtására.

Az alapok megértéséhez anyagokra lesz szüksége, ezeket az alábbiakban tekintse meg.

Videó utasítás a konvertáláshoz

Az 1C-ben az „1C Data Conversion” konfigurációval történő adatcsere beállításának alapjait lásd a videóban egy példaért:

Anyagok, tankönyvek az 1C Data Conversion 2.0 tanulmányozásához

Nincs túl sok anyag és dokumentáció a neten, igyekeztem összegyűjteni a legfontosabb, érdekesebb anyagokat:

0. Először is Ilya Leontiev ingyenes videotanfolyamát ajánlom, amely elérhető a címen link.

1. Elsősorban a beépített súgó használatát javasolnám a konfigurációban. Nagyon jól van megírva és technikailag jól kivitelezve:

2. A második legfontosabb információforrás a http://www.mykod.info/ oldal (az oldal bezárva volt), amely csak az adatkonverzióra specializálódott. Innen nagyszámú konverziós anyagot tölthet le.

3. Külön szeretném kiemelni a képzési kézikönyv tankönyvét - (szerző - Olga Kuznetsova).

Az adatok migrálása a különböző konfigurációk között nem triviális feladat. Mint mindig, most is több megoldás létezik, de nem mindegyik optimális. Próbáljuk megérteni az adatátvitel árnyalatait, és válasszunk egy univerzális stratégiát az ilyen problémák megoldására.

Az egyik megoldásról a másikra való adatmigráció (ez tisztán az 1C cég termékeiről van szó) tegnap fel sem merült. Az 1C cég jól ismeri azokat a nehézségeket, amelyekkel a fejlesztők szembesülnek az áttelepítések létrehozásakor, ezért igyekszik minden tőle telhetőt eszközzel segíteni.

A platform fejlesztése során a cég számos univerzális eszközt, valamint adatátvitelt egyszerűsítő technológiát vezetett be. Minden szabványos megoldásba be vannak építve, és az azonos konfigurációk közötti migráció problémája általában megoldódott. A győzelmet ismét megerősíti a szabványos megoldások szoros integrációja.

A nem szabványos megoldások közötti migrációval a helyzet némileg bonyolultabb. A technológiák széles skálája lehetővé teszi a fejlesztők számára, hogy önállóan válasszák ki a probléma megoldásának legjobb módját.

Nézzünk meg néhányat közülük:

  • csere szöveges fájlokon keresztül;
  • cseretervek használata;
  • stb.

Mindegyiknek megvannak a maga előnyei és hátrányai. Összefoglalva, a fő hátrány a bőbeszédűség lesz. A migrációs algoritmusok független megvalósítása jelentős időköltséggel, valamint hosszú hibakeresési folyamattal jár. Az ilyen döntések további támogatásáról nem is akarok beszélni.

A karbantartás bonyolultsága és magas költsége arra késztette az 1C vállalatot, hogy univerzális megoldást hozzon létre. Technológia, amely lehetővé teszi, hogy a lehető legnagyobb mértékben leegyszerűsítse a migráció fejlesztését és támogatását. Ennek eredményeként az ötletet egy külön konfiguráció - „Adatkonverzió” - formájában valósították meg.

Adatkonverzió - standard megoldás, önkonfigurálás. Bármely ITS:Prof előfizetéssel rendelkező felhasználó teljesen ingyenesen letöltheti ezt a csomagot a felhasználói támogatási oldalról vagy az ITS lemezről. A telepítés szabványos módon történik - mint az 1C többi szabványos megoldása.

Most egy kicsit a megoldás előnyeiről. Kezdjük a legfontosabbal - a sokoldalúsággal. A megoldás nem szabott bizonyos platformkonfigurációkhoz/verziókhoz. Egyformán jól működik mind a szabványos konfigurációkkal, mind a saját maga által írt konfigurációkkal. A fejlesztők univerzális technológiát és szabványosított megközelítést kapnak az új migrációk létrehozásához. A megoldás sokoldalúsága lehetővé teszi, hogy még az 1C:Enterprise-től eltérő platformokra is készítsen migrációt.

A második merész plusz a vizuális segédeszközök. Az egyszerű migrálások programozás nélkül jönnek létre. Igen, igen, egyetlen kódsor nélkül! Már csak ezért is érdemes időt szánni egyszer a technológia elsajátítására, majd ismételten felhasználni a felbecsülhetetlen értékű készségeket.

A harmadik előny, amit megjegyeznék, az adatterjesztésre vonatkozó korlátozások hiánya. A fejlesztő maga választja ki az adatok vevőkonfigurációba való eljuttatásának módját. Két lehetőség áll rendelkezésre a dobozból: feltöltés xml fájlba és közvetlen kapcsolat az információs bázissal (COM/OLE).

Építészet tanulása

Azt már tudjuk, hogy az adatkonverzió csodákra képes, de még nem világos, hogy mik a technikai előnyei. Az első dolog, amit meg kell tanulni, hogy minden adatmigráció (konverzió) csereszabályokon alapul. Exchange-szabályok - egy normál xml-fájl, amely leírja azt a struktúrát, amelybe az adatokat feltölti az IB-ből. Az adatfeltöltést/letöltést végző szolgáltatás-feldolgozás elemzi a csereszabályokat, és azok alapján végzi el a feltöltést. A letöltés során fordított folyamat történik.

A „KD” konfiguráció egyfajta vizuális konstruktor, amellyel a fejlesztő csereszabályokat hoz létre. Nem tudja, hogyan kell adatokat feltölteni. A CD-elosztó készletben található további külső szolgáltatási feldolgozás felelős ezért. Több is van belőlük (a fájlnévben szereplő XX a platform verziószáma):

  • MDXXExp.epf- a feldolgozás lehetővé teszi az infobase szerkezet leírásának feltöltését egy xml fájlba. A struktúra leírása betöltődik a CD-re további elemzés és csereszabályok létrehozása céljából.
  • V8ExchanXX.epf- a csereszabályoknak megfelelően adatokat tölt fel/letölt az infobázisból. A legtöbb tipikus konfigurációban a feldolgozás készen áll (lásd a „Szerviz” menüpontot). A feldolgozás univerzális, és nem kötődik semmilyen konkrét konfigurációhoz/szabályhoz.

Rendben, most a fentiek alapján határozzuk meg az új konverzió fejlesztésének szakaszait:

  1. Feladat meghatározása. Világosan meg kell érteni, hogy milyen adatokat kell átvinni (mely konfigurációs objektumokból), és ami a legfontosabb, hova kell átvinni.
  2. Konfigurációs struktúrák leírásának elkészítése (Forrás/Receiver) a későbbi CD-re való betöltéshez. A feladat megoldása az MDXXExp.epf szolgáltatásfeldolgozással történik.
  3. Készített szerkezetleírások betöltése IS-be.
  4. Csereszabályok létrehozása CD vizuális eszközeivel.
  5. Feltöltés/letöltés a létrehozott adatkonverziós szabályok szerint V8ExchanXX.epf feldolgozás segítségével.
  6. A csereszabályok hibakeresése (ha szükséges).

A legegyszerűbb átalakítás

A demonstrációhoz két telepített konfigurációra van szükségünk. Úgy döntöttem, megállok a lehetőségnél: „Trade Management” 10. kiadás és egy kis saját írású megoldás. A feladat az adatok átvitele lesz a tipikus UT konfigurációból. A rövidség kedvéért a saját kezűleg írt megoldást „Receiver”-nek, a kereskedelemmenedzsmentet „Forrásnak” nevezzük. Kezdjük a probléma megoldását a "Nómenklatúra" könyvtár elemeinek átvitelével.

Először is vessünk egy pillantást az adatkonverziós sémára, és olvassuk el újra a végrehajtandó műveletek listáját. Ezután elindítjuk a „Forrás” konfigurációt, és megnyitjuk benne az MD82Exp.epf szolgáltatás feldolgozását.

A feldolgozási felület nem ragyog a rengeteg beállítástól. A felhasználónak csak meg kell adnia azokat a metaadat-objektumokat, amelyek nem tartoznak bele a struktúra leírásába. A legtöbb esetben ezeket a beállításokat nem kell módosítani, mert nincs különösebb értelme a mozgások kirakodásának a halmozási regiszterekben (példaként).

Helyesebb a mozgást a dokumentumok fogadóba tartása közben kialakítani. Az átvitel után minden mozgást maga a dokumentum hajt végre. A második érv az alapértelmezett beállítások védelmében a feltöltött fájl méretének csökkentése.

Egyes dokumentumok (különösen a tipikus konfigurációkban) több regiszterben mozgatnak. Ha ezt a gazdaságosságot kiüríti, az eredményül kapott XML-fájl túl nagy lesz. Ez megnehezítheti a későbbi szállítást és a vevőaljzatba való berakodást. Minél nagyobb az adatfájl, annál több RAM szükséges a feldolgozásához. Gyakorlásom során véletlenül illetlenül nagy feltöltési fájlokkal találkoztam. Az ilyen fájlok teljesen elutasították a szabványos eszközökkel történő elemzést.

Tehát hagyjuk az összes alapértelmezett beállítást, és feltöltjük a konfiguráció leírását egy fájlba. Ugyanezt az eljárást megismételjük a második alappal.

Nyissa meg a CD-t, és válassza ki a főmenüből "Könyvtárak" -> "Konfigurációk". A címtár az összes konfiguráció struktúrájának leírását tárolja, amely konverziók létrehozásához használható. A konfiguráció leírását egyszer töltjük be, majd többször is felhasználhatjuk különböző konverziók létrehozására.

A könyvtárablakban nyomja meg a „ Hozzáadás” és a megjelenő ablakban válasszon ki egy fájlt a konfiguráció leírásával. Jelölje be a „Feltöltés új konfigurációba” négyzetet, és kattintson a „Feltöltés végrehajtása” gombra. Hasonló műveleteket hajtunk végre a második konfiguráció felépítésének leírásával.

Most már minden készen áll a csereszabályok létrehozására. A CD főmenüjében válassza a „Referenciák” -> „Konverziók” menüpontot. Új elem hozzáadása. Az új konverzió létrehozására szolgáló ablakban meg kell adnia: a forrás konfigurációját (válassza ki az UT-t) és a vevő konfigurációját (válassza a "Vevő" lehetőséget). Ezután nyissa meg a „Speciális” lapot, és töltse ki a következő mezőket:

  • Exchange szabályok fájlnév – a létrehozott csereszabályok ezen a néven lesznek elmentve. A fájlnév bármikor megváltoztatható, de a legjobb, ha most beállítja. Ezzel időt takaríthat meg a jövőben. A demó szabályait elneveztem: "rules-ut-to-priemnik.xml".
  • name - az átalakítás neve. A név teljesen bármi lehet, én a „Demo. UT a vevőhöz”.

Ez az, kattintson az "OK" gombra. Azonnal megjelenik előttünk egy ablak, amely arra kér bennünket, hogy hozzuk létre az összes szabályt automatikusan. Egy ilyen csábító ajánlat elfogadása azt a parancsot kapja a mesternek, hogy automatikusan elemezze a kiválasztott konfigurációk leírását, és önállóan generálja a csereszabályokat.

Azonnal pontozzuk az "és"-et. A mester nem lesz képes semmi komolyat generálni. Ezt a lehetőséget azonban nem szabad figyelmen kívül hagyni. Ha cserét kell létrehoznia az azonos konfigurációk között, akkor egy varázsló szolgáltatásai nagyon hasznosak lesznek. Példánkban előnyösebb a kézi üzemmód.

Nézzük meg közelebbről az „Exchange szabályok beállításai” ablakot. A kezelőfelület kissé zavarónak tűnhet – sok lap van tele vezérlőkkel. Valójában minden nem olyan nehéz, néhány óra alkalmazás után kezdi megszokni ezt az őrületet.

Ebben a szakaszban két lapra vagyunk kíváncsiak: „Objektumkonverziós szabályok” és „Adatfeltöltési szabályok”. Az elsőnél egyezési szabályokat kell felállítani, pl. Hasonlítsa össze két konfiguráció objektumát. A másodiknál ​​határozza meg a lehetséges objektumokat, amelyek a felhasználó rendelkezésére állnak a kirakodáshoz.

Az „Objektumkonverziós szabályok” lap második felében egy további panel található két lappal: „Tulajdonkonverzió” és „ Értékátalakítás". Az első a kiválasztott objektum tulajdonságait (rekvizitjait) választja ki, a második pedig az előre meghatározott értékekkel (például előre meghatározott szótárelemekkel vagy felsorolási elemekkel) való munkavégzéshez szükséges.

Remek, most hozzunk létre konverziós szabályokat a könyvtárakhoz. Ezt a műveletet kétféleképpen hajthatja végre: használja az objektumszinkronizáló varázslót (kattintson a "" gombra), vagy manuálisan adjon hozzá egyezéseket az egyes objektumokhoz.

A helytakarékosság érdekében az első lehetőséget használjuk. A varázsló ablakában törölje a jelet a „ A dokumentumok” (minket csak a címtárak érdekelnek), és bővítsük ki a csoportot Útmutató könyvek". Gondosan görgetjük a listát, és megnézzük az összehasonlítható könyvtárak neveit.

Az én esetemben három ilyen címtár van: Nómenklatúra, Szervezetek és Raktárak. Van egy Clients könyvtár is, amely ugyanazt a szemantikai terhelést hajtja végre, mint a „ Ügyfelek" konfigurációból " UT". Igaz, a mester kiváló nevük miatt nem tudta őket összehasonlítani.

Ezt a hibát magunk is kijavíthatjuk. Keresse meg az ablakban Objektumleképezések» kézikönyv « Ügyfelek”, és a „Forrás” oszlopban válassza ki a „Counterparts” referenciakönyvet. Ezután jelölje be a "Típus" oszlopban található négyzetet, és kattintson az "OK" gombra.

Az Objektumszinkronizálás varázsló felkéri, hogy automatikusan hozzon létre szabályokat az összes kiválasztott objektum tulajdonságainak konvertálásához. Az ingatlanok névvel lesznek párosítva, és a bemutatónkhoz ez bőven elég lesz, egyetértünk. A következő kérdés a feltöltési szabályok létrehozására vonatkozó javaslat lesz. egyezzünk bele.

A csereszabályzat alapja készen áll. Kiválasztottuk a szinkronizáláshoz szükséges objektumokat, a tulajdonságok konvertálására és a feltöltési szabályokra vonatkozó szabályok automatikusan létrejöttek. Mentsük el a csereszabályokat egy fájlba, majd nyissuk meg az IB „Source”-t (esetemben ez UT), és kezdjük el benne a szolgáltatás feldolgozását. V8Exchan82.epf.

Először is a feldolgozó ablakban válassza ki az általunk létrehozott csereszabályokat. A szabályok betöltésének kérdésére igennel válaszolunk. A feldolgozás elemzi a csereszabályokat, és létrehoz egy azonos nevű fát a kiüríthető objektumokhoz. Ehhez a fához mindenféle szűrőt beállíthatunk, vagy csomópontokat cserélhetünk, amelyek megváltoztatásával adatokat kell kiválasztanunk. Teljesen minden adatot szeretnénk feltölteni, így nincs szükség szűrők telepítésére.

Miután az adatok fájlba feltöltésének folyamata befejeződött, lépjen az IB " Vevő". A feldolgozást is megnyitjuk benne V8Exchan82.epf, ezúttal csak az „Adatok betöltése” fülre lépünk. Válassza ki az adatfájlt, és kattintson a "Feltöltés" gombra. Minden, az adatok átvitele sikeresen megtörtént.

Feladatok a való világból

Az első demó félrevezető lehet. Minden nagyon egyszerűnek és logikusnak tűnik. Valójában ez nem igaz. A valós munkában olyan feladatok merülnek fel, amelyeket csak vizuális eszközökkel (programozás nélkül) nehéz vagy teljesen lehetetlen megoldani.

Hogy ne csalódjak a technikában, elkészítettem néhány valós feladatot. Munka közben biztosan találkozni fogsz velük. Nem tűnnek olyan triviálisnak, és új szemszögből nézik az adatátalakítást. Gondosan fontolja meg a bemutatott példákat, és bátran használja őket kivonatként valós problémák megoldása során.

1. számú feladat. Töltse ki a hiányzó adatokat

Tegyük fel, hogy át kell vinnünk a "" könyvtárat Ügyfelek". A vevőegységnek van ehhez hasonló „Clients” kézikönyve. Adattárolásra teljesen alkalmas, de vannak kellékei " Szervezet”, amely lehetővé teszi a partnerek elkülönítését a szervezethez való tartozás alapján. Alapértelmezés szerint minden partnernek az aktuális szervezethez kell tartoznia (az azonos nevű konstansból szerezhető be).

A problémára többféle megoldás is létezik. Megfontoljuk a kellékek kitöltésének lehetőségét " Szervezet"közvetlenül a bázisban" Vevő”, azaz. az adatok betöltésekor. Az aktuális szervezet konstansban van tárolva, így nincs akadálya ennek az értéknek a megszerzésének. Nyissuk meg az objektumkonverziós szabályt (a továbbiakban: FRP) Ügyfelek” (kattintson duplán az objektumra), és a szabályok beállítási varázslójában lépjen az „Eseménykezelők” részre. A kezelők listájában azt találjuk, hogy Betöltés után”.

Leírjuk az aktuális szervezet lekéréséhez szükséges kódot az attribútumhoz való későbbi hozzárendeléssel. Abban a pillanatban, amikor a „Betöltés után” kezelő aktiválódik, az objektum teljesen formálva lesz, de még nincs beírva az adatbázisba. Senki sem tiltja meg, hogy saját belátásunk szerint változtassuk meg:

Ha NEM Object.ThisGroup Akkor Object.Organization = Constants.CurrentOrganization.Get(); EndIf;

A kellékek kitöltése előtt " Szervezet» ellenőrizni kell az attribútum értékét « Ez a csoport". az útmutatónak" Ügyfelek» a hierarchikus zászló be van állítva, ezért szükséges egy csoport ellenőrzése. Hasonlóképpen minden részlet kitöltése megtörténik. Feltétlenül olvassa el a súgót a kezelő egyéb lehetőségeiről " AfterLoading". Például van köztük egy paraméter " Elutasítás". Ha „True” értéket kap, akkor az objektum nem kerül beírásra az adatbázisba. Így lehetővé válik az objektumok korlátozása az írásra a betöltéskor.

2. számú feladat. Részletek az információs nyilvántartásban

A kézikönyvben" Ügyfelek"UT konfiguráció, vannak részletek" Vevő"és" Szolgáltató". Mindkét kellék "típusú" logikai érték” és a szerződő fél típusának meghatározására szolgálnak. IB-ben" Vevő”, a kézikönyvben „ Ügyfelek"Nincsenek hasonló adatok, de van információs nyilvántartás" Ügyfelek típusai". Hasonló funkciót lát el, és több címkét is képes tárolni egyetlen ügyfélhez. Feladatunk az adatok értékeinek átvitele az információs nyilvántartás különálló nyilvántartásaiba.

Sajnos a vizuális eszközök önmagukban itt sem tudnak megbirkózni. Kezdjük kicsiben, hozzunk létre egy új PCO-t az információs nyilvántartáshoz" Ügyfelek típusai". Ne írjon semmit forrásként. A feltöltési szabályok automatikus létrehozásának elutasítása.

A következő lépés a feltöltési szabályok létrehozása. Lépjen a megfelelő lapra, és kattintson a " Hozzáadás". A feltöltési szabályok hozzáadására szolgáló ablakban töltse ki:

  • mintavételi módszer. Váltás „Önkényes algoritmus”-ra;
  • konverziós szabály. Válassza ki az „Ügyféltípusok” információs nyilvántartást;
  • A szabály kódja (név). Ezt úgy írjuk, hogy „Client fajok feltöltése”;

Most meg kell írnia a kódot a feltöltéshez szükséges adatok kiválasztásához. Itt a paraméter " Adatmintavétel". Ebben elhelyezhetünk egy gyűjteményt egy előkészített adatsorral. Paraméter " Adatmintavétel” tudja elfogadni különféle jelentések- lekérdezés eredménye, kijelölés, értékgyűjtemények stb. Értéktáblázatként inicializáljuk, két oszloppal: kliens és ügyféltípus.

Alul látható az eseménykezelő kódja " Feldolgozás előtt". Inicializálja a "paramétert" Adatmintavétel", majd az adatok kitöltése a könyvtárból" Ügyfelek". Itt érdemes odafigyelni a „ oszlop kitöltésére Ügyfél típusa". Az „UT”-ban „boolean” típusú jellemzőink vannak, a címzettben pedig egy felsorolás.

Jelenleg nem tudjuk őket a kívánt típusra hozni (nem az UT-ban van), ezért egyelőre sztringek formájában hagyjuk. Ezt nem kell megtenned, de azonnal meg akarom mutatni, hogyan kell a forrásban hiányzó típusra leadni.

DataFetch = NewValueTable(); Data Selection.Columns.Add("Kliens"); Data Selection.Columns.Add("ClientType"); DataFrom kiválasztása a könyvtárból = Directories.Contractors.Select(); While Fetching DataFromCatalog.Next() Loop If FetchingDataFromCatalog.ThisGroup then Continue; EndIf; Ha DataFetchFromCatalog.Buyer akkor NewString = DataFetch.Add(); NewString.Client = SamplingDataFromCatalog.Reference; NewString.ClientType = "Vevő"; EndIf; Ha DataFetchFromCatalog.Provider Then NewString = DataFetch.Add(); NewString.Client = SamplingDataFromCatalog.Reference; NewString.ClientType = "Beszállító"; EndIf; EndCycle;

Mentse el az adatfeltöltési szabályt, és térjen vissza a „ Objektumkonverziós szabályok". Tegyük hozzá az információs nyilvántartáshoz „ Ügyfelek típusai” tulajdonság átalakítási szabályok: kliens és ügyféltípus. A forrást üresen hagyjuk, és a „Kirakás előtt” eseménykezelőben ezt írjuk:

//Az "Ügyfél" tulajdonsághoz Value = Source.Client; //A „CustomerType” tulajdonsághoz If Source.Customer = "Buyer" Then Expression = "Enumerations.CustomerTypes.Buyer" ElseIf Source.Customer = "Supplier" Then Expression = "Enumerations.CustomerTypes.Supplier"; EndIf;

A kiírásban az adatok az elvégzett adatkiválasztás alapján kerülnek kitöltésre. Egyszerűen linkként adjuk át az ügyfelet, és a "" paraméterbe írjuk be az ügyfél típusát. Kifejezés". Ennek a paraméternek az adatai a vevőben lesznek értelmezve, és végrehajtásukkor az attribútum a felsorolásból a megfelelő értékkel kerül kitöltésre.

Ennyi, készen vannak a csereszabályok A vizsgált példa elég univerzálisnak bizonyult. Hasonló megközelítést gyakran alkalmaznak a 7.7-es platformon létrehozott konfigurációkból származó adatok átvitelekor. Ennek frappáns példája az időszakos részletek átadása.

3. számú feladat. Táblázatos trükkök

Gyakran vannak olyan feladatok, amelyeknél egy táblázatos rész sorait több sorba kell feladni. Például a kezdeti konfigurációban a szolgáltatások és az áruk egy táblázatos szakaszban vannak nyilvántartva, míg ezeknek az entitásoknak a tárolása el van különítve a vevőben. A probléma ismételten nem oldható meg vizuális eszközökkel. Itt célszerű a második probléma megoldását alapul venni.

Készítünk egy adatfeltöltési szabályt, megadunk egy tetszőleges algoritmust, és a „Feltöltés előtt” kezelőbe írunk egy lekérdezést, hogy a táblázatos részből adatokat kapjunk.

Helytakarékosság érdekében nem adom meg a kérés kódját (mindig hivatkozhat a forráskódra) - nincs benne semmi szokatlan. A kapott mintát átválogatjuk, és a rendezett eredményeket a már ismert paraméterbe helyezzük. Adatmintavétel". Ismét célszerű egy értéktáblázatot gyűjteményként használni:

DataFetch = NewValueTable(); //Itt lesz még egy táblázatos rész Data Selection.Columns.Add("Termékek"); //Itt lesz egy táblázatos rész is Data Selection.Columns.Add("Szolgáltatások"); Data from.Columns.Add("Link") kiválasztása;

4. számú feladat. Adatok átvitele műveletbe

Ha egy szervezet több könyvelési rendszert használ, akkor előbb-utóbb szükség lesz adatmigrációra, az ezt követő könyvelések kialakításával.

A konfigurációban" BP"van egy univerzális dokumentum" Művelet” és ideális több vezeték kialakításához. Itt csak egy probléma van: a dokumentumot ravaszul készítik, és nem olyan egyszerű adatokat átvinni bele.

Az ilyen átalakításra példa a cikk forráskódjában található. A kód mennyisége elég nagynak bizonyult, így nincs értelme közzétenni a cikkhez. Csak annyit mondok, hogy a feltöltés ismét egy tetszőleges algoritmust használ az adatfeltöltési szabályokban.

5. számú feladat. Adatok szinkronizálása több attribútum között

Néhány példával már foglalkoztunk, de eddig nem beszéltünk az objektum-szinkronizálásról a migráció során. Képzeljük el, hogy partnereket kell átadnunk, és néhányuk valószínűleg a fogadó adatbázisban van. Hogyan lehet adatokat továbbítani és elkerülni a duplikációkat? Ebben a tekintetben a CD számos módot kínál az átvitt objektumok szinkronizálására.

Az első egyedi azonosító alapján történik. Sok objektum egyedi azonosítóval rendelkezik, amely garantálja a táblán belüli egyediséget. Például a kézikönyvben " Ügyfelek” nem tartalmazhat két azonos azonosítójú elemet. A CD elvégzi erre a számítást, és az összes létrehozott PSP-nél alapértelmezés szerint azonnal engedélyezve van az azonosító szerinti keresés. A PSP létrehozása során észre kellett volna venni a nagyító ikont az objektum neve mellett.

Az egyedi azonosítóval történő szinkronizálás megbízható módszer, de messze nem mindig megfelelő. Könyvtárak egyesítésekor " Ügyfelek” (több különböző rendszerből) nem sokat segít.

Ilyenkor helyesebb az objektumok több szempont szerinti szinkronizálása. Helyesebb a partnerek keresése TIN, KPP, név alapján, vagy a keresést több szakaszra bontva.

Az adatkonverzió nem korlátozza a fejlesztőt a keresési feltételek meghatározásában. Nézzünk egy absztrakt példát. Tegyük fel, hogy szinkronizálnunk kell a könyvtárakat " Ügyfelek” különböző információs bázisokból. Készítsünk elő egy PCP-t, és az objektum konvertálására vonatkozó szabályok beállításainál jelölje be a „ Folytassa a keresést a keresési mezőkben, ha a vevő objektum nem található azonosító alapján". Ezzel a művelettel azonnal meghatároztunk két keresési feltételt - egyedi azonosító és tetszőleges mezők alapján.

Jogunk van a mezőket magunk választani. Miután feljegyeztük a TIN-t, a KPP-t, a nevet, azonnal megjelölünk több keresési feltételt. Kényelmes? Igen, de ez megint nem elég. És mi van, ha meg akarjuk változtatni a keresési feltételeket? Például először keresünk egy csomó TIN + KPP-t, és ha nem találunk semmit, akkor elkezdünk szerencsét próbálni a névvel.

Teljesen lehetséges egy ilyen algoritmus megvalósítása. Az eseménykezelőben Keresési mezők” akár 10 keresési feltételt is megadhatunk, és mindegyikhez meghatározhatjuk a saját keresési mezők összetételét:

Ha SearchOptionNumber = 1, akkor SearchPropertyNameString = „TIN, KPP”; ElseIfSearchVariantNumber = 2 ThenSearchPropertyNameString = "Név"; EndIf;

Mindig többféle megoldás létezik.

Minden feladatnak több megoldása van, és ez alól a különböző konfigurációk közötti adatátvitel sem kivétel. Minden fejlesztőnek joga van saját megoldási utat választani, de ha állandóan összetett adatmigrációkat kell fejlesztenie, akkor nyomatékosan javaslom, hogy figyeljen a "" konfigurációra. Hagyja, hogy először erőforrásokat (időt) kell befektetnie a képzésbe, de ezek bőven megtérülnek az első többé-kevésbé komoly projektnél.

Véleményem szerint az 1C cég méltatlanul megkerüli az adatkonverzió használatának témáját. A technológia fennállásának teljes ideje alatt egyetlen könyv jelent meg róla: „1C: Enterprise 8. Data conversion: Exchange alkalmazásmegoldások között”. A könyv meglehetősen régi (2008), de még mindig kívánatos, hogy megismerkedjen vele.

A platform ismerete továbbra is szükséges

» egy univerzális eszköz, de ha az 1C:Enterprise 7.7 platformra kifejlesztett konfigurációkból adatmigrációt kíván létrehozni vele, akkor időt kell szánnia a beépített nyelv megismerésére. A nyelv szintaxisa és ideológiája nagyon eltérő, ezért időt kell fordítani a tanulásra. Az elv többi része ugyanaz marad.

Az eseménykezelő mechanizmus az egyik kulcsfontosságú a "Data Conversion 2.0"-t használó adatátalakítási technológiában. Ennek a mechanizmusnak a hozzáértő és ügyes használata lehetővé teszi a fejlesztő számára, hogy gyorsan megoldjon szinte bármilyen adatátalakítási feladatot. A processzortechnológia segítségével könnyen megvalósítható az adatkiválasztás, adatkonverzió különböző típusok, összetett adatkiválasztás, konverziós beállítások és sok más feladat.

Fontolja meg ennek a technológiának az alapelveit. Az univerzális adatcsere-feldolgozás során az adatok ki- és betöltésére szolgáló algoritmusok kulcspontjain az adatcsere-szabályokból vett programkódot lehet végrehajtani, és nem „hardverezve” az adatok ki- és betöltésénél. A "Data Conversion 2.0" konfiguráció lehetőséget biztosít az ilyen programkódok adatcsere-szabályokba való integrálására.

Összességében több mint húsz különböző hely van az adatcsere-algoritmusokban, ahol harmadik féltől származó kódot lehet végrehajtani. Ennek megfelelően a konfiguráció különféle típusú eseménykezelők létrehozását biztosítja.

Az eseménykezelők kódja a csereszabályok objektumaihoz - a könyvtárak elemeihez: konverziók, objektumkonverziós szabályok, tulajdonságkonverziós szabályok, adatfeltöltési szabályok és adattisztítási szabályok - "csatolódik". Természetesen az eseménykezelő kódnak számos követelménynek meg kell felelnie. Különösen a kezelőkódban a konverziós folyamat vezérléséhez speciális változókat - paramétereket kell használnia. Az összes eseménykezelő típus és az elérhető változók teljes leírása megtalálható a megfelelő űrlapokon található kezelők információiban.

FIGYELEM!!!

A Data Conversion 2.0 technológiák lehetővé teszik az adatcserét az 1C:Enterprise 7.7 és 1C:Enterprise 8.0 platformokon megvalósított információs bázisokkal. Az 1C:Enterprise 7.7 platform működésének sajátosságai miatt az ezen a platformon megvalósított infobázisok eseménykezelőivel történő adatcsere-szabályok elkészítése számos funkcióval rendelkezik.

Az 1C:Enterprise 7.7 platformon nem lehet tetszőleges kódot végrehajtani (a V8 Futtatás funkciójával analóg módon). Ha a V7.7 platformhoz eseménykezelőket kell használni, akkor az adatok feltöltéséhez vagy letöltéséhez szükséges feldolgozási szöveget le kell cserélni olyan feldolgozási szövegekre, amelyeket a "Data Conversion 2.0" konfiguráció adja ki.

Ha adatokat kell átvinnie a V7.7-ről a V8-ra, akkor:

Kitöltéskor a szabályfájlon kívül a rendszer előállítja a V77Exp.ert feldolgozására szolgáló modul szövegét eseménykezelőket megvalósító függvényekkel. Ezután a konfigurátorban le kell cserélnünk a szabványos V77Exp.ert modult a "Data Conversion 2.0" által generált újra.

Amikor az 1C:Enterprise 7.7 platformon adatcsere megoldásokat fejleszt, emlékeznie kell erre a fontos "apróságra". Szabályai csak akkor működnek megfelelően, ha módosított feldolgozást használ, amelynek modulszövege az adatcsere-szabályok kirakásakor jött létre. Ez a szabály egy kivétellel rendelkezik - ha nem használ eseménykezelőket, akkor használhatja a szabványos feldolgozást.

Tisztelettel, Vlagyimir Milkin(tanár és fejlesztő).

A CSENGŐ

Vannak, akik előtted olvassák ezt a hírt.
Iratkozzon fel a legújabb cikkekért.
Email
Név
Vezetéknév
Hogy szeretnéd olvasni a Harangszót
Nincs spam