Symbol Ügyvitel v1.112 – “Kingston”

A nyári pihenések után, közben kiadásra kerül a Symbol Ügyvitel 1.112-es verziója, amely apró, de ugyanakkor fontos módosításokat tartalmaz. Kényelmi funkciókkal bővítettük a rendszert és körülbelül 10-15%-ot gyorsítottunk/optimalizáltunk az adatbázis kapcsolatokon. Ez nem csak gyorsítást, hanem nagyobb stabilitást is jelent.

A verziók mindegyike olyan városról kapja a nevét, amelyben az ST összetétel szerepel. Ez a verzió egy kis amerikai kisvárosról (24 ezer lakos) kapta a nevét, amely New York állam fővárosa volt 1777-től. A Hudson folyó miatt már régóta kereskedelmi központ, de fontos közúti forgalmat is bonyolít. Emellett – jellemzően az amerikai közlekedési kultúrára – 100km-es közelségben négy repülőtérrel is bír. A kis közösség egyik nevezetessége, hogy minden hónap első szombatján $1-ért megy az Art-busz, amely a művészeti galériákat sorban meglátogatja a Tourist trolley-val (régi típusú városnéző busz).

 

Az alábbi fontos változásokat érdemes kiemelnünk, de itt a  teljes lista:

!Bizonylat dátumok fokozott ellenőrzése
A bizonylat dátumok fokozott ellenőrzése (rendszerbeállítások) nem engedi adott napnál régebbi vagy újabb bizonylat kiállítását. A tolerancia értékek a kelt, teljesítés és fizetési határidőre külön-külön adhatóak meg.

Forgalmi kimutatások; időszakok összehasonlítása
A forgalmi kimutatásokon lehetőség van két dátumidőszak összehasonlítására.

Vevő, szállító és termék másolás
Vevő, szállító és termék másolás során lehetőség van kiválasztani, hogy a forrásadatok közül melyek kerüljenek másolásra.

Bejövő oldal; más szállító bizonylata
Bejövő oldalon is van lehetőség más szállító bizonylatát átvenni forrásbizonylatként.

Szállítói bizonylatok; szállító módosítása
Szállítói bizonylatokon a mentést követően is van lehetőség a szállító módosítására.

Optimalizált adatbázis kapcsolatok
Felhős működésben az adatbázis kapcsolatok újrafelhasználásra kerülnek, emiatt nem jön létre minden alkalommal újabb kapcsolat, ha van még újrafelhasználható példány.

Drag and drop a kimutatásokon
Drag and drop műveletek elérhetőek a kimutatásokon is, ahol az oszlopok függvényében vevő vagy termék kerül a drag and drop vágólapra.

Törölt raktárak megjelenítése
A törölt, rejtett (és projekt-) raktárak legördülő listában való megjelenítése a felhasználói beállításokban állítható, az alábbi módokon lehetséges: 5mp után, második lenyitásra, SHIFT nyomva tartásával.

Telepítő; Office.NET kikapcsolása
A telepítőben az Office.NET 64bit telepítését nem ajánlja fel a rendszer, mert a natív XLSX és XLS 64bit olvasási képesség miatt erre nincs szükség.

Vevő és érdeklődő partnerkapcsolatok a listán
Vevők és érdeklődők listájáról azonnal elérhetőek a partnerkapcsolatok. Helyben tudunk létrehozni újat, vagy listázni a meglévőeket.

Korábbi napi háttérképek
Korábbi napi háttérképek is elérhetőek a főablak jobb-klikkes menüjében.

Méretezhető dialógus ablakok
A méretezhető dialógus ablakok mérete és helyzete is elmentésre kerül.

Weboldalunk megújult

A nyári szabadságolással, pihenéssel, de gondolkodással töltött időszak alatt a Symbol Tech Zrt. új weboldallal jelentkezik.

A mai kor igényeinek megfelelő reszponzív weboldal, az alkalmazott figyelemfelhívó külső mellett sokkal fontosabb, hogy a belső miként újult meg. A Symbol Ügyvitellel nagyon sokat dolgoztunk az elmúlt években. Az így összegyűlt innovációkat eddig weboldalunk nem tudta átadni jelenlegi és jövőbeni ügyfeleinknek, érdeklődőinknek. Az új oldalon kiemelt szerepet kaptak a felhasználói élményt növelő, vezetőknek és üzemeltetőknek szóló tartalmak.

Egy kép többet mond ezer szónál. Tíz kép pedig tízezer szónál. Termékeink a letöltés előtt vizuálisan is “kipróbálhatóak”. Mindenki eldöntheti, hogy ezt a kinézetet kereste-e. Ha igen, akkor itt az idő a DEMO letöltésére, hogy a megnézhesse, ezt a működést kereste-e.

Integráltuk korábban külön blog-rendszerbe ültetett tartalmainkat. Így a céges blog és a fejlesztői blog is a www.symboltech.hu oldalon érhető el. Tudásbázisunk is megújult, az oldalhoz illeszkedő külsővel tartalmazza ugyanazokat az információkat.

 

Kérdése lenne?

Ha a weboldallal vagy termékeinkkel kapcsolatban kérdése, észrevétele lenne, keresse szakértő kollégáinkat!

 

Firebird Collation hiba megoldása (UNICODE_CI) lépésről lépésre

Több ügyfelünk jelezte, hogy a Debian alapú Linux disztribúciók esetén szükség lenne a konkrét megoldási lépésekre. Kollégáink elvégezték a tesztet. Az alábbi módon egy debian-6.0.6-i386-netinst.iso (200MB)-ból telepített, csak alapcsomagokkal rendelkező x86-os számítógépen működésre bírható a Firebird 2.5:

  1. /etc/init.d/firebird stop
  2. Firebird 2.5 source beszerzése és kicsomagolása (későbbiekben source)
  3. apt-get install libncurses5-dev
  4. apt-get install g++
  5. cd source/extern/icu/source
  6. ./configure
  7. make
  8. make install
  9. cd source
  10. ./configure –enable-superserver
  11. make
  12. make install (abban ENTER-rel a szolgáltatás indítása)

A make install intelligensen a régi helyére “teszi” az új bináris állományt, azaz /etc/init.d/firebird restart az általunk fordított verziót kezeli.

Megfürödtünk a Firebird tóban – megúsztuk szárazon

Szeretek adatbázisokról vitatkozni. Szeretek olyanokkal vitatkozni, akik olvasták az “Adatbázis-rendszerek tervezése” könyvet. Valahol a szakma ott kezdődik.

 

Az Ügyfél

Egyik nagy ügyfelünk (a kép nem véletlenül került ide) részére fejlesztett szoftver nagy mennyiségű adatot kezel, precízen, pontosan. 1.45 millió vevőből tud(t)unk gyorsan válogatni. Valami azonban most egy kicsit belassult. Bármilyen terhelés mellett 4.5 mp volt a válaszidő. És egy rendes programozó érzi, ha valami nincs rendjén. A vevőtörzset átszippantottuk és egy teljesen szűz operációs rendszeren is 4.5 mp-re jött ki a lekérdezés. Minden index rendben volt. És a problémát pont ez okozta….

horstfuchs_firebird

 

Az index néha probléma?

Igen. Az index tartalmazott 9.000 valós, nem NULL értéket, ami 1.45 millió vevőre vonatkozóan pont megfelelő eloszlást jelentett (index stat), emiatt a lekérdezésekben a rendszer használta. De nem kellett volna, mert az eredmény csak ennek az indexnek a használata lett. A 9.000 vevő kiszűrése után 1.44 millió vevőn FULL-SCAN-t (!!!) végzett. Fogta a “rekordokat” és merevlemez hozzáférést is indukált. Nem keveset. Van megoldás?

 

Megoldás?

Az indexet eltávolítva a probléma megoldódott. Volna. De ez nem egy index volt, hanem egy foreign key (idegen kulcs) által létrehozott belső index. Nem törölhető. Az index használata PLAN kézzel való megadásával befolyásolható. De nem szeretnék az adatbázis szerver helyett gondolkodni (pedig talán menne, lásd: Adatbázis-rendszerek tervezése). Akkor valahogy el kellene érni, hogy az indexet a rendszer NE használja. Eltelt pár óra, majd még pár… és megszületett a megoldás. Nem írom le a megoldást, de büszke vagyok rá. 

A megoldás pedig beépítésre került az SQLManager-be, minden lekérdezés bizonyos mezőket kihagy az indexből. Automatikusan. A végeredmény egy állandóan 65-70 ms (!!!) alatt lefutó lekérdezés és egy nagyon alacsony terhelés. Örülünk Vincent?

Firebird Collation hiba megoldása (UNICODE_CI)

Egyre több ügyfelünk telepíti a Symbol Ügyvitelt Linux kiszolgálóra és sokan a bulváros OpenSUSE helyett valami “rendeset” választanak, például Gentoo-t vagy Debian-t (vagy ubuntu-t, ami szintén egy Debian). A Linuxok érzékenyek a csomagokra, Debian és barátai végképp.

Általában a libICU (nemzetközi kódkiosztásért felelős csomag) szokott a probléma lenni, amit egy rendszergazda meg tud oldani, de hogyan is? A hiba akkor jelentkezik, amikor a CREATE TABLE lefut(na), a szöveges mezőknél UNICODE_CI collation-t megadva. A Debian nem ismeri az UNICODE_CI-t a hibaüzenet szerint.

6115_debian_splash

Megoldás A

fbintl.conf fájlban a libicu bejegyzéshez hozzá kell írni a gépre telepített libicu verziószámot. Ez “manapság” 49 körül járhat.

Megoldás B

firebird csomagot scratch-ből kell fordítani és a Linux ./configure futtatásakor meg kell adni a –with-system-icu kapcsolót.

Desktop bűvös bája

Nagyon trendi laptop/notebook kombinációval fejleszteni, de cégünk már rég kinőtte azt a méretet, amikor a fejlesztő mozog, ügyfelekhez jár, bemutat, előadást tart. Fejlesztői gépeink szokásos cseréje most kicsit nagyobb változást hoz(ott).

Bármennyire is erős egy notebook, bármennyire fel van tuningolva SSD meghajtókkal, amitől csendes lesz és gyors… az asztali számítógépek teljesítményét nem éri el. Ár/érték arányban biztosan nem. Asztali, desktop számítógépek mellett raktuk le a voksunkat. HP Pro, Intel Core I5/I7 processzorral szerelve, benne végtelen mennyiségű (500GB sok mindenre elég) tárhely. Mindez kiegészítve persze a céges fájlszerverrel optimális fejlesztésre. De van még egy jobb ötletünk…

ssd

A cég vezetése kitalálta, hogy legyen dedikált fejlesztői szerver. Kollégák távoli asztallal (RDP) be tudnak lépni a számítógépeikre, sőt ha azok ki vannak kapcsolva, akkor WakeOnLan-nal fel tudják előtte ébreszteni azokat. De milyen jó lenne egy dedikált szerver! És valóban… Jövőbeni törekvésünk az, hogy egy olyan nagy teljesítményű, könnyen bővíthető (skálázható, például virtuális gépekre  épülő, felhős) számítógépet állítsunk be, amelyen minden fejlesztői tevékenység elvégezhető. Legyen szó webes vagy WinForms fejlesztésről.

Minden fejlesztő ide lépne be, állandóan futna. Minden, a fejlesztéshez szükséges komponens megtalálható lenne rajta. Nem kellene gépenként verziókövetés, biztonsági mentés, stb.

Ez az álom a terveink szerint hamar valóra fog válni.

Symbol Cloud – elmélet

Cégünk az újév környékén elindítja Felhő szolgáltatását, amelyet négy hónapos tervezés előzött meg. Régóta (Symbol Connect) tervezzük és vetjük el a megoldásokat,  hogy a lehető legjobbat találjuk meg.

Megszületett

Kollégáink egy olyan megoldással rukkoltak elő, amely egyrészről az adatbázis rendszer műveleteit “másolja le”, mintha egy adatkiszolgáló proxy lenne, egyben pedig megoldja a sok, kicsi kommunikációs csomagból eredő teljesítmény csökkenést.

Egy Statefull és ConnectionLess megodás mellett döntöttünk, amely a kapcsolat kiépítését nem igényli folyamatosan (mint a weboldalakat kiszolgáló HTTP kérések), de ugyanakkor az adatbázis állapotokat a kiszolgáló oldalon precízen nyilvántartja.

Tárgyak, eszközök, algoritmusok

Nagyon is témába vág, de az eddigiektől eltérő területre tévedtünk. Tárgyi eszköz modulunkat fejlesztjük. Első látásra a legkönnyebben algoritmizálható témának gondoltuk, de a valóságban nem az.

 

Mi is ez valójában?

Tárgyi eszköz a számvitelben azoknak az eszközöknek a gyűjtőneve, amelyek

  1. anyagi formában léteznek (szemben például az immateriális javakkal, amelyek “nem megfoghatóak”)
  2. több, mint egy éven keresztül maradnak a vállalkozás vagyonában.

Az IFRS (közelebbről az IAS 16) meghatározása szerint az olyan eszközöket lehet elismerni tárgyi eszközként, amelyek a jövőben várhatóan jövedelmet generálnak a vállakozás részére és amelyek bekerülési értéke megbízhatóan mérhető. (forrás: Wikipédia)

A tárgyi eszközök életét az Asset Management témában a lehető legjobban kell modellezni. Ha újabb eszköz kerül beépítésre vagy az eszköz (annak egy része) megsérül/selejtezésre kerül, akkor ezt jelezni kell és az algoritmus ezek szerint számol tovább.

Hogy is kell ezt megvalósítani?

Szoftverfejlesztőink elővették régi tanulmányaikat és a fekete-doboz elvet alkalmazták. Bármely tárgyi eszköz (továbbiakban TE) tranzakció saját paraméter halmazzal rendelkezik. Más adatokat kell megadni aktiválásnál és másokat kell megadni selejtezéskor.

E paraméterei alapján a tranzakció egy adatváltoztatást hajt végre függetlenül attól, hogy milyen tranzakciók ölelik körül. Ő végzi a munkáját, áramot ad a fekete-doboznak, az pedig kiköp egy eredményt. És jön a következő fekete-doboz.

Fontos volt a keretrendszert úgy módosítani, hogy a tranzakció bármikor újra végrehajtható legyen! A maradványérték változtatás tranzakció, amely 5M Ft-tal növeli a megfelelő számot nem fog megijedni, ha elé beszúrunk egy beszerzési érték növekedést. A determinisztikus gépek programozási elvét használtuk fel.

 

Öt (5) tábla elég lesz!

Cégünk számviteli szakemberei szerint 5 adatbázis tábla elég lesz az adatok tárolására. Fejlesztőink ezt kétkedve fogadták, igazuk is lett. Amint elkezdtünk dobálózni a számlatükör, könyvelési időszak, leírási mód, IFRS, SzT, TAO szavakkal már 5 táblánál tartottunk. De még egyik sem kezdődött “Asset”-tel. Azok csak ezután jöttek!

Tizennégy (14) Asset kezdetű táblát hoztunk létre, hogy szépen minden a helyén legyen. Megrendelő cégeink nemtárgyi eszköz program“-ot akarnak, hanem egy integrált rendszert, ahol például a TE-k helye időben elkülönül, beállítható, szűrhető, hogy egy adott eszköz, mikor, hol volt fellelhető. Melyik országrészben végezte tervezett vagy terven felüli értékcsökkenési feladatát.

 

Csak adatbázis?

Szerettem volna azt írni, hogy igen, de nem. A TE-n végzett események (amelyek tranzakciókat hoznak magukkal) valamit módosítanak, újra futtathatóak, fekete-doboz elven működnek. De az események egy összetett számviteli szabályrendszer alapján egymással is interakcióba lépnek. Ha másért nem, hogy úgynevezett kontextus hibákat jelezzenek: Aktiválás előtt csak beruházás lehet; Aktiválás után kell lennie értékcsökkenési mód (pl. lineáris) leírásnak, hogy az ÉCS el tudjon kezdődni; Kétszer leállítani nem lehet a TE-t, csak ha közben van újraindítás.

 

Kihívások

Kollégáink számos kihívással találkoztak a feladat megoldása közben és számos kihívás még várat magára, de felkészülten, precízen minden szituációt meg fogunk oldani. Már látjuk az alagút végén a fényt.

Csak ne álmodnánk éjszakánként a nettó alapú degresszív tervezett értékcsökkenéssel, amely IFRS szerint létezik!

Index használata kötelező – nem csak sávváltáskor

Szabadságom derekán benéztem az irodába és azzal fogadtak, hogy a v1.94-es verzió lassú. De mi lehet a probléma, hány ügyfélnél jelentkezett, komoly-e a baj? Tanulságos volt az a 30 perc a fejlesztőknek.

Mik az indexek?

Az adatbázisban tárolt információk nagyon sokan vannak, hasonlóan egy könyvtárhoz. Az adatok/könyvek közti keresésben segítenek az indexek. Például Molnár Ferenc Pál utcai fiúk könyve egy rendes könyvtárban kétszer van indexelve. Az M betűnél, azon belül Molnár Ferencnél is megtalálható, emellett a P betűnél, Pál utcai fiúk jelölés alatt is megtalálható, közvetlenül a “Pakura készítése” és a “Pálinkafőzés” című könyvek között. (Attól most tekintsünk el, hogy a regény címe A betűvel kezdődik, ez annyira általános, hogy az indexekből ki is szokták hagyni).

Indexelni kötelező!

Minden adatbázis kell, hogy tartalmazzon indexeket, amelyek automatikusan jönnek létre vagy a programozó készíti őket, hogy az adatelérés gyorsabb legyen. Például az ABC Kft. tárgy havi számláinak lekérdezésében egy automatikus index (idegen kulcs a vevőre) és egy kézi index (dátum) segít. Indexek nélkül az összes számlát végig kellene nézni, hogy megtaláljuk a megfelelőket (full scan, nagyon rossz stratégia).

Rakjunk mindenre indexet!

Az indexek az adatbázisban tárolt adatok másolatai (minden adat kétszer szerepel), emiatt mindent indexelni nem célszerű. És ez a problémánkat nem is oldja meg! Az indexeket a rendszer csak akkor használja, ha értelme van (lásd lentebb). Intelligensek ezek a rendszerek!

Akkor mi volt a probléma?

Megszüntettünk egy egyedi (unique) indexet, de létrehoztuk helyette a négy (!!!) mezőjére vonatkozó indexeket. Gondoltuk, ezzel készen is vagyunk… De a régi index helyett létrehozott négy új nem ugyanazt a hatást váltotta ki. A négy indexből a rendszer csak kettőt használt (query plan), a többinek annyira kicsi volt az értékkészlete, hogy az adatbázis kezelő figyelem kívül hagyta őket.

Értékkészlet?

Egy indexszel gyorsított adatmező(k) előfordulási értékei lehetnek nagyon kicsik. A számlák tábla dátum mezője az első héten még csak 5 különböző értéket tartalmaz (ha szombat-vasárnap is állítunk ki számlát, akkor 7-et). Az adatbázis kezelő az ilyen kis variációjú indexekre azt mondja, hogy nincs értelme használni őket. Ha például kiállítunk 3 nap alatt 9000 számlát (ez persze csak egy példa), akkor minden dátumhoz 3000 számla fog tartozni. Az index nem sokat segít nekünk abban, hogy melyik számlák készültek ma, hiszen 3000 értéket fog visszaadni, az összes számla egy harmadát.

Mi lehet a megoldás?

A v1.94-es verzió hibáját azonnal javítottuk, de családommal nyaralás és bevásárlás közben is azon gondolkodtam, hogy akkor milyen indexeket kell létrehozni “úgy általában”. A programozás inkább hasonlít az orvoslásra, mint a marketingre, próbálkozni nem lehet, de mi most mégis ki fogunk választani 2-3 speciálisan előkészített adatbázist, hogy teszteket hajtsunk végre rajta.

Minden bizonnyal a megoldás az lesz, hogy a leggyakoribb lekérdezések (a Symbol Ügyvitelbe beépített  lekérdezésfordító ebben segíteni fog nekünk) esetén létrehozunk olyan “furcsa” indexeket, amelyek nem logikusak, de nagy értékkészletük miatt az adatbázis kezelő mégis használni fogja őket.

 

 

Eközben nyugaton…

Tengerentúli példákkal jönni sikkes, nem is szeretem, de mégis hadd álljon itt egy amerikai példa. Ott jellemzőbbek a saját fejlesztőcsapattal rendelkező cégek (nálunk a bankoknak/pénzintézeteknek sincs ilyen, egy kivételt ismerek a Concorde Értékpapír Zrt-t, amelynek van egy saját, profi csapata), ahol a DBA (adatbázis adminisztrátor) feladata, hogy a lassú lekérdezéseket (1mp helyett 90-120mp) optimalizálja és indexekkel támogassa. Nekünk, dobozos szoftver szállítóknak ezt helyi rendszergazda nélkül kell tudnunk megoldani. Eddig sikerrel!

 

Ritkán működő 413-as HTTP hiba

A HTTP szabvány szerint a HTTP hibakódoknak működniük kellene (https://www.w3.org/Protocols/rfc2616/rfc2616-sec10.html). Sok esetben – főleg tárhely szolgáltatónál működtetett PHP kiszolgálón – nem működik minden hibaüzenet. Ilyen hibaüzenet a 413-as hiba is. Ez akkor jelentkezik (jelentkezne), ha a beállított, fogadható adatmennyiségnél többet akarunk ráerőltetni, feltölteni a szerverre.

A hiba az esetek 90%-ban elfedésre kerül, azaz a válasz üzenetben nem érkezik semmi, a böngésző egy üres ablakot jelenít meg. Helyette a 413-as hibát kellene visszaadnia. Így sajnos azok az eszközök, amelyek webrendszeren küldenek adatot, nem értesülnek arról, hogy hiba történt.

WebSyX-ünkben is megvalósítottunk egy hibakezelő réteget, amely az elfedett 413-as hibát megkerüli és precízen kezeli. Amennyiben a hibakezelést bekapcsoljuk, úgy a POST adatfelküldésnél választ kell adni a feltöltésre. A WebSyX esetében ez egy OK szó kell, hogy legyen. Amennyiben nem kapunk választ (a csomag a nagy méret miatt elveszett) úgy hibának érzékeljük. Amennyiben az OK-tól eltérő választ ad vissza a szerver, úgy azt a szöveget is hibaüzenetként kezeljük. Ezzel egyéb, szerver oldalon bekövetkező hibákat is jelezni tudunk (MySQL error, PHP error, out of disk space, stb.)

WebSyX-ünk új változata letölthető a

https://syx.symboltech.hu/tanusitott-syx-beepulok/websyx-webaruhaz-kapcsolat/ linkről.