A 8. ábra szerint szükség van (amint azt alább tárgyaljuk) a hibakeresési eljárás jelentős átdolgozására. Ez tükröződött a 8.3.7.1759-es verzióban. Egyrészt egy univerzális felületet hoztak létre ehhez az eljáráshoz, másrészt ez a változás biztosítja magának a programnak a továbbfejlesztését. Végül is most már nemcsak a konfigurátoron keresztül, hanem a Fejlesztői eszközök segítségével is dolgozhat a hibakereséssel. Nézzük meg, hogyan lehet engedélyezni a hibakeresést az 1C szerveren az új verziótól kezdve.

Az új protokoll használata

A korábbi, a korábbi verziókban megvalósított hibakereső a kliens- és szerveralkalmazásokat TCP/IP protokollal kezelte.

Jelenleg egy ilyen protokoll használata megkezdte az 1C:Enterprise program internethez való hozzáférésének korlátozását, és kényelmetlenséget okozott a mobilalkalmazások működésében.

Ezért a helyi hálózaton kívül található információs adatbázisokhoz való ingyenes hozzáférés érdekében a rugalmas HTTP protokollt alkalmazták.

Új építészet

Korábban a konfigurációs hibakeresés során az alkalmazottnak csatlakoznia kellett az információs bázishoz. Ehhez rendszergazdai jogokat kellett adni neki.

Az új verzióban nem kell közvetlenül csatlakozni az adatbázisokhoz - elég, ha egyszerűen ugyanaz az adatbázis, mint a kliens. És betöltheti fájlból.

Mobil alkalmazások

A HTTP protokoll használatával most már lehetséges a szerveradatok, a kliensadatok és az alkalmazások hibakeresése.

Egyéb változások

Az új verzióval lehetőség van a helyi változók értékeinek megváltoztatására a hibakeresési eljárásban, erre a célra egy új gyorsnézet ablak került bevezetésre.

A számítási mód aszinkronra módosult, így az eredmények megvárása nélkül folytathatja a munkát.

Hibakereső a Fejlesztői eszközökben

Az új eljárással való interakció egy speciálisan kifejlesztett univerzális szoftverfelületen történik. Egyrészt ezt a felületet használja a Configurator. Másrészt az új 1C:Enterprise Development Tools környezetben valósul meg.

Hogy néz ki most

A program megváltoztatása után az eljárás a következő forgatókönyv szerint történik:

Most már nem csak a hibakeresőt és az elemeket érinti, mint korábban. Most egy további elem került be a láncba - a szerver.

Nemcsak hozzáadódik, hanem a hibakereső és az objektumok közötti információcsere fő elemeként is szolgál. Maga a csere pedig sorban sorakozó üzeneteken keresztül történik.

És mivel ez a csere a HTTP protokollon keresztül történik, most már nem számít, hogy az adatok pontosan hol találhatók.

A kiszolgáló hívásai a hibakeresőből és az objektumokból további kapcsolódási kérelmek formájában jönnek létre. Amikor megjelennek, megfelelő válaszokat küldenek nekik.

Hibakeresés engedélyezése különböző forgatókönyvekben

Az alkalmazásfejlesztő számára nem történt változás. A lényeges különbség az, hogy az új mechanizmust engedélyezni kell. Végül is alapértelmezés szerint le van tiltva.

Nézzük meg, mi történik az üzemmód indításakor, ha két forgatókönyv közül választunk.

Fájl szkript

A fájlverzió elején meg kell adnia a konfigurációs beállításokban egy új mechanizmus használatát - „Hibakeresés HTTP protokollon keresztül”.

Ezután a konfigurátor automatikusan helyi szerver használatát javasolja. Ezt a feltételt el kell fogadni, és a programot újra kell indítani Konfigurátor módban.

Ezt követően az újonnan elindított Configurator a következő munkamenet során elmenti az általunk választott új módszert. De ugyanarra az információs bázisra. Ezért egy másik információs bázis elérésekor azt is engedélyezni kell.

Az engedélyezett mechanizmus most automatikusan elindítja a Debugger Servert, amely egy speciális dbgs.exe alkalmazás. Ez megjelenik a Feladatkezelő ablakban.

A ownerPID paraméter értéke megfelel a hozzá kötött alkalmazás azonosítójának.

Amikor elindít egy hibakeresési munkamenetet a Configuratoron keresztül, a szerverkapcsolat automatikusan létrejön. És a kapcsolódó objektumok tükröződni fognak benne.

Ha az 1C programot az új mechanizmus nélkül aktiválták, akkor manuálisan kell engedélyeznie a hibakeresést az 1C szerveren. Csak most kell megadnia a szerver címét:

Lépjen a Szolgáltatás – Beállítások menüpontra

Az elem beállításaiban található:

Lépjen a Kapcsolat - Beállítások menüpontra

Ha egy fájlszkriptet egyszerre több adatbázissal használ, figyelembe kell vennie egy fontos árnyalatot - mindegyik konfigurátor (a HTTP-mechanizmus engedélyezésével) elküldi a saját szerverét:

Ezért, ha több konfigurátor van nyitva, akkor a kliens csatlakoztatásához meg kell adnia a megfelelőt.

Kliens-szerver forgatókönyv

Az 1C szerveren a kliens-szerver forgatókönyv használatával végzett hibakeresés, mint az előző esetben, a mód elindításával kezdődik. Ez az új HTTP-mechanizmus használatát határozza meg. Ez a következőképpen történik:

ragent.exe -debug -http

Amikor elindul, a hibakereső automatikusan elindul mögötte.

A ownerPID paraméter értéke megfelel az 1C fürtkezelő azonosító számának.

A program javaslatot hoz létre a fürt hibakereső kiszolgáló használatára most (és nem helyi szerverre, mint az előző forgatókönyvben). Egyetértünk, és újraindítjuk.

A jövőben minden úgy fog menni, mint egy fájl szkript. Csak a Server Database Configurator elindításakor nem indul el a helyi hibakereső kiszolgáló.

Reméljük, hogy kiadványunk segített kitalálni azt a problémát, hogyan lehet engedélyezni a hibakeresést az 1C szerveren.

Az 1C fejlesztő feladata nem csak a kód írása, hanem a hibák nyomon követése és javítása, optimális parancsvégrehajtási algoritmus felépítése és a munka sebességének optimalizálása, vagyis a hibakeresés. Ezt nehéz megtenni a szervereljárások beépített hibakeresőjének funkcióinak használata nélkül.

Kezdetben a hibakeresési mód le van tiltva az 1C szervereken, így a fejlesztőnek egyszerű manipulációkat kell végeznie a beállításokkal, hogy alaposan ellenőrizni tudja a kódot.

Hibakeresési mód engedélyezése a szerveren az 1C platform 8.2-es és újabb verzióihoz

A hibakeresés engedélyezésének algoritmusa meglehetősen egyszerű. Nem feltételezi az operációs rendszer architektúrájának és az 1C adminisztrációjának alapos ismereteit. Ennek ellenére nagyon óvatosnak kell lenni, mert a hibakeresés közvetlenül a szerveren és rendszergazdai jogokkal történik. Ezért, ha nem rendelkezik alapos ismeretekkel, szigorúan kövesse a cselekvések algoritmusát improvizáció nélkül:

• Állítsa le az 1C:Enterprise Server Agent szolgáltatást a Kiszolgálókezelőn keresztül. Ha a beállítás éles kiszolgálón történik, akkor előre gondoskodnia kell arról, hogy az 1C felhasználók ne legyenek az adatbázisban;
• Indítsa el a rendszerleíró adatbázis-szerkesztőt a „Start” - „Futtatás” vagy a „Win” + „R” billentyűparancsra kattintva. A megnyíló ablakban írja be a „regedit” sort;

• A rendszerleíró adatbázisban meg kell találnia az elemet;

• A paraméterek között keresse meg az „ImagePath” elemet, és módosítsa úgy, hogy a meglévő értékhez hozzáadja a „-debug” szót szóközzel a végén;

• A Kiszolgálókezelőn keresztül indítsa el a leállított szolgáltatást - „1C:Enterprise Server Agent”.

Hibakeresési mód engedélyezése a szerveren az 1C 8.1-es verziójához

Ha engedélyeznie kell a hibakeresési módot a 8.1-es platformon, a műveletek algoritmusa gyakorlatilag változatlan marad. Az egyetlen változás az "ImagePath" elérési út paraméterének helye. A 8.1-es verzióban a szakaszban található.

Az 1C fejlesztői azt tanácsolják, hogy engedélyezzék a hibakeresési módot kizárólag a tesztszervereken, ahol a kódot hibakeresni kell. Ennek az ajánlásnak az az oka, hogy a kiszolgálón a hibakeresés engedélyezése a teljesítményre hatással van. Ha sok felhasználója van, vagy a szerver teljesítménye sok kívánnivalót hagy maga után, óvatosan fogadja meg ezt a tanácsot, hogy a hibakeresésnek ne legyen negatív következménye.

18.10.2016

Hibakeresés 1C szerveren (8.2, 8.3...)

Ha az 1C adatbázis kliens-szerver verzióban fut, akkor a szerveroldali kódhibakeresési mód le van tiltva. Ezért nem lehet lépésről lépésre látni, hogy mi történik egy függvény vagy eljárás végrehajtásakor. A szerveroldali hibakeresés engedélyezéséhez néhány egyszerű lépést kell követnie.

Engedélyezze a hibakeresést az 1C:Enterprise szerveren 8.2, 8.3

Az első dolog, amit meg kell tennie, az 1C:Enterprise szerverszolgáltatás leállítása. Lépjen a "Start - Futtatás" elemre (vagy a "Windows + R" billentyűparancsra), írja be a "services.msc" parancsot (természetesen meg kell nyitnia a Windows szolgáltatások kezelését a rendszergazdától)

A leállítás után nyissa meg a Windows rendszerleíró adatbázis-szerkesztőjét ("Start - Futtatás" (vagy a "Windows + R" billentyűparancs), és írja be a "regedit" kifejezést), és keresse meg a névvel rendelkező ágat. "" vagy "" platform verziótól függően

Érdekel bennünket az "ImagePath" nevű rendszerleíró kulcs. Adja hozzá a "-debug" kifejezést a kulcsérték végéhez. Ez azt jelenti, hogy az 1C szerver oldalon a hibakeresési mód aktiválva van.
Volt: "C:\Program Files\1cv8\8.3.6.2530\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo"
lett: "C:\Program Files\1cv8\8.3.6.2530\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "C:\Program Files\1cv8\srvinfo" -debug

Mentse és indítsa el az 1C szolgáltatást. Minden készen áll! Boldog hibakeresést!

A szervereljárások hibakereséséhez be kell állítani a jelzőket a konfigurátor „Szolgáltatás->Paraméterek” űrlapján:

Hibakeresés az alkalmazáskiszolgálón

Ez le van írva a dokumentációban:

„1C: Enterprise 8.1. Konfiguráció és adminisztráció"

18. fejezet Konfigurációs eszközök

Hibakereső és teljesítménymérés

"Hibakeresési kód a szerveren

A hibakeresési mód telepítéséhez indítsa el az 1C:Enterprise szervert a /Debug parancssori kapcsolóval (ragent.exe /debug)."

A szerverügynök indítókulcsait a könyv ismerteti:

"1C: Enterprise 8.1. Kliens-szerver. A telepítés és a használat jellemzői"

"A kiszolgálóügynök szolgáltatásként való futtatása

Ha egy kiszolgálófürt telepítésekor a központi szerverügynök szolgáltatásként történő elindítását választotta, akkor ez a szolgáltatás automatikusan elindul a telepítési folyamat során, és az operációs rendszer indulásakor is elindul.

Ha a központi szerver ügynök alkalmazásként lett telepítve, akkor lehetőség van a szolgáltatás manuális regisztrálására, majd elindítására.

A szolgáltatás regisztrációja a következő paranccsal történik:

Ragent.exe -instsrvc -usr<пользователь>-pwd<пароль>-kikötő<порт>-hatótávolság<диапазоны>-szeklev<уровень>-debug | -rmsrvc | -start | -állj meg

Instsrvc – a fürtügynök regisztrálása Windows szolgáltatásként. Ha a ragent.exe ezzel a kulccsal elindul, akkor regisztrál a Windows szolgáltatások listájában, és kilép. Nem kompatibilis az -srvc, -rmsrvc kapcsolókkal;

Usr<имя пользователя>

Pwd<пароль пользователя>– annak a Windows-felhasználónak a neve és jelszava, akinek a neve alatt a Ragent.exe programot Windows-szolgáltatásként kell elindítani. Csak az -instsrvc kulccsal együtt használható, ha a ragent.exe fájlt Windows-szolgáltatásként regisztrálja;

Kikötő<порт>– a fürtügynök fő portjának száma. Ezt a portot használja a fürtkonzol a központi szerver eléréséhez. A fürtügynök portja a működő kiszolgáló IP-portjaként is meg van adva;

Hatótávolság<диапазоны>– IP port tartományok a dinamikus kiválasztáshoz. Ezek közül kiválasztásra kerülnek a fürtfolyamatok szervizportjai, ha a megfelelő működő szerver beállításaiból nem lehet kiválasztani azokat. Alapértelmezett: 1560-1591. Példa értékek<диапазоны>: "45:49", "45:67,70:72,77:90";

Seclev<уровень>– a fürtügynök folyamat biztonsági szintje. Meghatározza a ragent.exe folyamattal létrehozott kapcsolatok biztonsági szintjét.<уровень>a következő értékeket veheti fel: 0 (alapértelmezett) a kapcsolatok nem biztonságosak, 1 – biztonságos kapcsolatok csak a felhasználói hitelesítés idejére, 2 – tartósan biztonságos kapcsolatok.;

Rmsrvc – törli a fürtügynök regisztrációját Windows-szolgáltatásként. Ha a Ragent.exe ezzel a kulccsal elindul, akkor törli a regisztrációját a Windows szolgáltatások listájában, és kilép. Nem kompatibilis az -srvc, -daemon, -instsrvc kapcsolókkal.

Start - Indítsa el a Windows szolgáltatásként regisztrált ragent.exe fájlt. Elindítja a korábban Windows-szolgáltatásként regisztrált raggent.exe fájlt, majd kilép;

Leállítás – a ragent.exe leállítása Windows-szolgáltatásként regisztrált és fut. Leállítja a korábban Windows-szolgáltatásként regisztrált és futó raggent.exe fájlt, majd kilép;

Hibakeresés – szerverfürt indítása konfigurációs hibakeresési módban. "

Így ha az 1C:Enterprise szervert szolgáltatásként indították el, és valamilyen oknál fogva hibakeresési módban is szolgáltatásként kell elindítani, először törölnie kell a szolgáltatás regisztrációját (az -rmsrvc kulcsot), majd újra kell regisztrálnia a szolgáltatást a -debug kulcsot.

Nyilvánvaló, hogy hasonló hatást más módon is el lehet érni, például a Windows rendszerleíró adatbázisának közvetlen szerkesztésével. Ehhez valószínűleg olvassa el a Windows dokumentációját.

Csak akkor működik, ha a "-debug" kulcs be van állítva a beállításjegyzékben. Minden más esetben valamiért nem működik.

"ImagePath"=

a következő volt: "F:\Program Files\1cv81\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -d "F:\Program Files\1cv81\server"

állítsa be: "F:\Program Files\1cv81\bin\ragent.exe" -srvc -agent -regport 1541 -port 1540 -range 1560:1591 -debug -d "F:\Program Files\1cv81\server"

Megvalósítva a 8.3.7.1759 verzióban.

Jelentősen átterveztük a hibakeresési mechanizmust. Ennek több oka is volt. Először is lehetőséget akartunk adni a ma elérhető összes alkalmazás hibakeresésére. Másodszor, a korábbi hibakereső architektúra változtatásokat igényelt annak érdekében, hogy lépést tartson a jelenlegi trendekkel és alkalmazkodjon a jövőbeli fejlődéshez. Harmadrészt szükség volt egy univerzális hibakereső felületre, amellyel nemcsak az 1C:Enterprise konfigurátor, hanem a .

Fő előnyei

Hogy el tudja képzelni az általunk végrehajtott változtatások mértékét, röviden felsoroljuk az új mechanizmus fő előnyeit.

HTTP hibakeresés

A korábbi hibakeresési mechanizmus azon a tényen alapult, hogy az 1C:Enterprise konfigurátorban megvalósított hibakereső közvetlenül kommunikált a hibakereső elemekkel (kliens- és szerveralkalmazásokkal). Ez az interakció a TCP/IP protokoll használatával történt.

Az 1C:Enterprise alkalmazások internetes megjelenésével, és különösen a mobilalkalmazások megjelenésével azonban ez a megközelítés korlátok és kényelmetlenség forrásává vált. A TCP/IP protokoll nem mindig teszi lehetővé a hibakereső számára, hogy „elérje” a hibakeresés alatt álló elemeket. Végül is előfordulhat, hogy azon a helyi hálózaton kívül találhatók, amelyben a hibakereső fut.

Ezért az új mechanizmusban a „mindenütt jelenlévő” HTTP protokollt választottuk szállítási protokollnak, amelyet egyébként a kliens alkalmazások is használnak az információs adatbázisokhoz való csatlakozásra.

Modern hibakereső architektúra

A korábbi hibakeresési mechanizmus egyik jellemzője az volt, hogy a konfigurátor segítségével csatlakozni kellett az információs bázishoz. Ennek eredményeként a fejlesztői hibakereső teljes hozzáférést kapott az összes adminisztrációs funkcióhoz.

Az új hibakeresési mechanizmus már nem igényel kapcsolatot a hibakeresés alatt álló információs bázissal. A legfontosabb dolog, amire a hibakeresőnek most szüksége van, ugyanaz a konfiguráció, amely az ügyfelek számára is működik. Megszerzéséhez nem kell csatlakozni a hibakeresés alatt álló infobázishoz. Letöltheti például egy fájlból.

Mobil alkalmazások hibakeresése

A HTTP protokoll használatának köszönhetően lehetővé vált a mobil platform által futtatott alkalmazások hibakeresése. Sőt, bármilyen kontextusban hibakeresést végezhet: kliens, kiszolgáló, valamint háttérfeladatokat.

Most, a hibakeresés során, megváltoztathatja bármely írható változó értékét. A helyi változók gyors megtekintéséhez és módosításához külön ablakot vezettünk be. És a hibakereső által megjelenített kifejezések kiszámítása most aszinkron módban történik.

Hibakeresés a fejlesztői eszközökben

Egy új hibakereső mechanizmus létrehozásakor egy új, univerzális szoftver interfészt valósítottunk meg a vele való interakcióhoz. Ezt az interfészt használja az 1C:Enterprise konfigurátor, és ugyanezt a felületet használja most az új fejlesztői környezet is. Így az összes hibakeresési lehetőség elérhető, ha a -ban dolgozik.

Hibakeresési folyamat architektúrája

Az új hibakereső architektúra így néz ki:

A hibakeresés egy hibakeresőt, hibakereső elemeket és egy új elemet tartalmaz - hibakereső szerver.

Nincs közvetlen információátvitel a hibakereső és a hibakereső elemek között. Minden interakció a hibakereső szerveren keresztül történik. Ez a mechanizmus fő eleme. A hibakereső kiszolgálónak van egy üzenetsora, amelyen keresztül a hibakereső és a hibakereső elemek információkat adnak át egymásnak.

Maga a hibakereső és a hibakereső elemek is HTTP-n keresztül kommunikálnak a hibakereső szerverrel. Így most már nem számít, hol találhatók ezek a hibakereső elemek.

A hibakereső szerverrel való interakciót a hibakereső és a hibakereső elemek kezdeményezik. Ebből a célból további kapcsolatokat szerveznek. Fő céljuk, hogy megtudják, megjelentek-e számukra információk a hibakereső szerveren. És ha megjelenik, szerezze be ezt az információt.

Így az interakció egyoldalú. Az információk folyamatosan átvitelre kerülnek a hibakereső szerverről a hibakeresőre és a hibakereső objektumokra.

Információs bázisok azonosítása

Az előző mechanizmusban egy kapcsolati karakterláncot használtak az információs bázisok azonosítására. Ez a megoldás bizonyos esetekben nehézségeket okozott a hibakereső elemek és a konfigurátor egyeztetésében. Mert egyrészt megkülönböztette a kis- és nagybetűket, másrészt bizonyos kontextusok hibakeresésekor a platform automatikusan generálta a kapcsolati karakterláncot. És nem mindig esett egybe azzal, amit az infobázis csatlakoztatásakor megadott a konfigurátorban. Az ilyen helyzetek megtalálása és kijavítása megnehezítette a hibakeresési folyamatot.

Az új mechanizmusban megszabadultunk a kapcsolódási karakterlánctól. Most használjuk infobázis azonosítója. A fájl információs bázisában egy ilyen azonosító az ügyfélkapcsolat első létesítésekor jön létre. A szerver információs bázisában a fürtben lévő infobázis regisztrációs azonosítót használják ilyen azonosítóként.

Egy szép plusz pont itt az, hogy a régi hibakeresési mechanizmust egyelőre megtartottuk a platformon (a jövőben kizárható). És használhatja, ha akarja, vagy ha szükséges. Tehát módosítottuk a régi mechanizmust, és most az is az infobase azonosítót használja, és nem a kapcsolati karakterláncot.

Tipikus hibakeresési forgatókönyvek

Az alkalmazásfejlesztő szemszögéből a tipikus hibakeresési forgatókönyvek nem változtak. Az egyetlen lényeges különbség az, hogy az új hibakereső mechanizmust engedélyezni kell. Mert alapból le van tiltva.

Ettől függetlenül érdemes megismerkedni azzal, hogy mi történik most, amikor a hibakeresést futtatja. Mert hasznos lehet néhány nem szabványos munkahelyzetben.

Fájl opció

Mielőtt elkezdené a hibakeresést a fájl verziójában, jeleznie kell a konfigurátor beállításaiban, hogy az új hibakeresési mechanizmust szeretné használni - " HTTP hibakeresés».

Ebben az esetben a konfigurátor automatikusan felkéri Önt egy helyi hibakereső kiszolgáló használatára. El kell fogadnia ezt, és újra kell indítania a konfigurátort.

A beállított hibakeresési módszer mentésre kerül a konfigurátori munkamenetek között, de az információs bázisok kontextusában kerül tárolásra. Ezért egy másik információs bázishoz újra engedélyeznie kell.

Most, amikor elindítja a konfigurátort, vagy amikor újraindítja, a platform automatikusan elindítja a hibakereső kiszolgálót. Ez egy külön dbgs.exe alkalmazás. A feladatkezelőben láthatod.

A ownerPID paraméter adja meg a hibakereső kiszolgálót birtokló alkalmazás azonosítóját. Ebben az esetben ez az 1C:Enterprise konfigurátor.

Most, ha elindít egy 1C:Enterprise hibakereső munkamenetet a konfigurátorból, az automatikusan csatlakozik a hibakereső szerverhez, és a konfigurátorban látni fogja a csatlakoztatott hibakereső elemeket.

Ha az 1C:Enterprise munkamenetet hibakeresés nélkül indították el, akkor, mint korábban, csatlakoztathatja a hibakeresőhöz. Csak most kell megadnia a hibakereső szerver címét:

Ezt a címet a hibakeresési elemek beállításainál találja meg:

Van egy szokatlan pont az egyszerre több fájladatbázissal végzett munka során. A fájlverzióban minden konfigurátor, amelynél engedélyezve van a http hibakeresés, elindítja a saját másolatát a hibakereső szerverről különböző portokon:

Ezért ha több konfigurátor van nyitva egyszerre, akkor az ügyfélalkalmazás és a hibakereső csatlakoztatásához ki kell választania a megfelelőt.

Kliens-szerver opció

Mielőtt elkezdené a hibakeresést a kliens-szerver verzióban, a korábbiakhoz hasonlóan el kell indítania az 1C:Enterprise szervert hibakeresési módban, de meg kell adnia, hogy az új HTTP-mechanizmust használja a hibakereséshez. Például így:

ragent.exe -debug -http

Ha a szervert így indítjuk el, a hibakereső szerver is elindul.

A ownerPID paraméter az 1C:Enterprise fürtkezelő azonosítóját jelzi.

Most a konfigurátor beállításaiban, mint a fájladatbázis esetében, jeleznie kell, hogy az új hibakeresési mechanizmust szeretné használni - " HTTP hibakeresés».

Ebben az esetben a konfigurátor automatikusan felkéri, hogy a fürt hibakereső kiszolgálóját használja, és ne a helyi kiszolgálót. El kell fogadnia ezt, és újra kell indítania a konfigurátort.

Hibakeresési elemek csatlakoztatása

Amikor elindítja a hibakeresési munkameneteket a konfigurátorból, az alkalmazások automatikusan csatlakoznak a hibakereső elemekhez (mind az ügyfél, mind a szerver) a hibakereső kiszolgálóhoz.

Ugyanakkor, mint korábban, lehetősége van beállítani a konfigurátort úgy, hogy automatikusan csatlakoztassa a hibakereső elemeket, függetlenül azok indítási módjától. Most ezek a lehetőségek sokkal gazdagabbak lettek.

Először is, a platform mostantól az összes lehetséges hibakereső elem közül választhat.

Másodszor pedig megjelent egy másik, finomabb beállítási mód. Ez az előre elkészített kijelölések használata.

Ezeket a kijelöléseket mind a hibakeresési elemek csatlakoztatásakor, mind az elérhető hibakeresési elemek megtekintéséhez használhatja.

A kiválasztásban magukon a hibakereső elemeken kívül megadhatja azokat a felhasználókat, akiknek a munkamenetei érdeklik Önt, és ha adatszétválasztást használnak, jelezze az információs bázis azon területét, amelyen hibakeresés történik.

Változók, objektumtulajdonságok módosítása és kifejezések aszinkron kiértékelése

Az új hibakereső mechanizmus lehetővé teszi a változó értékek módosítását hibakeresés közben. A korábbi mechanizmusban nem volt ilyen lehetőség.

A legáltalánosabb feladatnak tűnő helyi változók kényelmes megtekintésére és megváltoztatására bevezettük a „ Lokális változók».

Külsőleg nagyon hasonlít az Ön által megszokott „Eredménytáblához”. De először is, ez az ablak már automatikusan meg van töltve az összes helyi változóval, másodszor pedig megváltoztathatja a változók értékeit.

A primitív típusok értékeit közvetlenül a cellában módosíthatja " Jelentése»:

Más értékek megváltoztatásához használhatja a kifejezés beviteli ablakát:

Jó bónusz, hogy a kontextuális eszköztipp teljes mértékben működik ebben az ablakban.

Pontosan ugyanígy módosíthatja bármely (nem csak helyi) változó és írható tulajdonság értékeit. A kifejezésszámítási ablakban (amelyet a Shift+F9 parancs hív meg) megváltoztathatja a változók értékeit mind az „Érték” cellában, mind egy külön párbeszédpanelen.

Egyébként maga a kifejezésszámítás most aszinkron módon történik. Ez azt jelenti, hogy a konfigurátor megrendeli a hibakereső elem kiszámítását. És egy ideig ez a számítás várható a szerveren. Ha a számítás befejeződött, az eredmények azonnal elküldésre kerülnek a konfigurátornak. Ha a számítást hosszú ideig végzik, akkor ezeknek a számításoknak az eredménye aszinkron módon később érkezik meg a konfigurátorhoz. Ez a megközelítés lehetővé teszi, hogy ne várjon hosszas számításokra a konfigurátorban, és folytassa a munkát.