Helios Green aneb nejsprasenejsi aplikace kterou znam

Berte jako podnet k zamysleni jak se da aplikace sprasit.

Jde o ERP, podle chlubeni se dodavatele (LCS) "nejlepsi ceske".

Co me ponouklo toto sem napsat ? Tebas dnesni zkusenost. Vyrobite si uzavetelske pole, to se nejak jmenuje v databazi a samozrejme mu date nejaky nazev ktery uvidi uzivatele. Ovsem ten nazev nesmi obsahovat slovo nazev ani slovo reference (a to ani s diakritikou). WTF ??? Kdyz obsahuje, tak vam tahle uzasna vec misto nej zobrazi ve formularich databazove jmeno, navic neuplne a jako bonus nelze s polem pracovat. Idiota ktery neumi pracovat se stringovou popiskou a nazvem databazoveho pole by bylo zahodno povesit za koule do pruvanu.

Rikate si mozna drobnost ? OK, muzu pokracovat. Dalsi "drobnosti" je, ze temer veskere chybove hlasky jsou v podstate ladicimi vypisy. Pro usera uzasne. Specielne kdyz mu ta hlaska rika, ze ma vyplnit policko XYZ a k tomu mu vypise SQL query ...

Nebo, existuje XML rozhrani, pres ktere muzete se systemem komunikovat z jine aplikace. Rozhrani poslete nejakou zpravu a vrati (nekdy) odpoved. Kupodivu i kdyz vrati ze se nepovedlo, zustane v DB cosi, co neni videt z aplikace protoze tomu neco chybi. Nebo naopak, vrati ze se povedlo, zel v DB neni nic.

Variantne uzivatel cosi dela a vyskoci mu nejake to hlaseni ptajici se na potvrzeni. Jenze to hlaseni vyskoci za oknem ve kterem neco dela => ono je "tuhe" a uzivatel nevi co se deje.

Pripadne se muzete pobavit s "tenkym" klientem, ktery pri rolovani gridu vytizi dvojjadro bez problemu na 80+% a roluje tak 10radku/s (pri tom zatizeni). Schvalne, jak rychle odroluje grid v excelu o 100k radku ? A s jakou zatezi ?

Jako tresnicku pridavam, ze tutez "vec" pouzivaji jakozto helpdesk a jen prihlaseni je tak na 10-15 minut. Pridani prilohy je pak 15-20 operaci ktere musite udelat. Nebo ze aktualizace znamena stahovani prakticky kompletni aplikace (cca 100MB) ... (diff k nim nejspis jeste nedorazil).

Pocitam ze nejsem sam kdo ma zkusenosti s touto hruzou, takze sem klido pripiste svoje zazitky.

Na to lze říci jen: No fuj :)

Bohužel náš trh s ERP i sklady obecně je na tom vážně špatně, doufám že se dostanu k vývoji vlastního jádra, abych využil zkušenosti z Dynamics AX.

Mno skladovej system pouzivame taky. Je tam bug ze dochazi k deadlocku (nekdy). Dodvatel to opravit neumi, protoze nevidi do zdrojaku a vyrobce to opravit nechce, protoze dodavatelske upravy .... ale neni to tak hrozny narozdil od ERPcka.

Ackoli neujsem profesi programator, prijde mi, ze takovou prasarnu bych si nedovolil prezentovat ani jako svoje dilko.

Vesele prihody muzou pokracovat trebas tim, ze erpcko ma jakesi moduly (sklad, mzdy ...) a podle chovani je zrejme, ze ac okenka vypadaji podobne (dalo by se rict i stejne) tak se chovaji ruzne => tam kde vam rekneme v modulu X funguje vyber vsech dokladu ctrl+a, tak v modulu Y se totez dela ctrl+shift+a.

Samozrejme o tom ze by patche vychazely pro jednotlive moduly (abyste si kvuli mzdam nemuseli rozbit sklad) si muzete nechat maximalne zdat.

Dalsi prca jsou obecne nazvy poli. Pole se nejak jmenuje v databazi a to je prakticky jedine na cem se da s nekym dohodnout. Pole pak ma nejaky nazev jako popisku (viz predchizi zabavny post) ale ta se jeste nemusi zobrazit na formulari, na nem muze totiz byt napsano neco uplne jineho.
Takze uzivate si otevre formular a vidi rekneme "Cislo dokladu: xyz", chce hledat => zapne si fitr a hleda cislo dokladu ... nj, jenze ono se to pole jmenuje trebas reference subjektu (jak to ma chudak vedet ?) a v databazi se muze jmenovat jeste nejak uplne jinak. Fakt uzasny.

My jsme nad tímhle "veledílem" jednou implementovali náš MIS a co si tak pamatuju, tak to byl docela zážitek ;D Já naštěstí na tomhle projektu nedělal, zatím mě "postihly" leda záležitosti běžící nad daty z MFG či SAPu :-D Pracovat s Heliosem a komunikovat s LCSkou, tak to pevný nervy! ;D

EDIT: Když jsme u těch výrobců - tak mi kolega říkal, že onehdá hlásil výrobci chybu v MIS Alea... Dala se sice "pracně obechcat", ale taky jednoduše odstranit... Odpověď? "O problému víme, ale nebudem jej řešit"... Ještě, že tuhle "OLAP platformu" u nových projektů už nepoužíváme a jede to teď na jiné technologii :-D

Panove, pokracovani zazitku (skoro by zaslouzilo presun do vtipu). Ad zminene nazvy poli.

"reseni" :
<key name="NotRelationColumns" value="lcs_uda_test_refer,lcs_uda_test_nazev"/>

Toto praskene do konfiguraku, samo nezdokumentovano, jak muzete videt, syntax musel delat kreten, ktery XML nechape ani na urovni MS (kdo to kdy videl by se v XML neco oddelovalo carkama v parametru tagu). Jako bonus to funguje (jako vse od LCS aneb Asseco) tak nejak napul. Policko sice funcni je (nebo aspon tak vypada), ale popiska nikoli (zobrazi se neuplny nazev v DB).

Kua Jezevec neděs mě, mě od konce měsíce čeká implementace MIS ve firmě, kde je jako ERP právě HeG :-D :-D

No.. muzu pokracovat, pouziva se tu EDI a chodi to jako formatovany txt (pevne definovany format). Jednoznacny a jednoduchy pozadavek = zachovat funcionalitu = import txt souboru. Nelze. Potrebuji XML (jak snim umi, viz predchozi).

V jedne firme, kde jsem delal ajtaka, nasadili system Notia. Bezi to na oracle eneterpise server a umi to docela dost veci, navic se to tvari dost pouzitelne. Jako perlicku uvedu, ze ta firma notia porada mistrovstvi v powerballu v CR :)
O heliosu jsem slysel ze je hodne tragicky, navic to bezi jen na wokennim serveru.

Bezva, tak jako bonus ono "reseni" zpusobi, ze se ta jejich aplikace cela zhrouti (nikdo nemuze nic pridat).

Tak jsem opet zde, s dalsim dilem serialu.

LCS (Asseco) provozuje helpdeskovy system ve svem sprasenem systemu. Nejen ze prihlaseni je tak na 5 minut, ale vymysleli v posledni verzi uzasnou featuru. Pokud nema uzivatel pravo na export dat, nema zaroven ani pravo na ctrl + c. No a jelikoz toto pravo samozrejme jako zakaznik nemate (dalo by se tak dostat k libovolnym datum, protoze prava jsou pro ne neco jako UFO pristavajici na Vaclavaku), tak si nevykopirujete ani data, ktera jste sami do systemu zadali. Uzasna vlastnost helpdesku, coz ?

jen poznamka... je to produkt by LCS ne Asseco, LCS byla koupena.... ale je to jen detail (ted je to asseco solutions)

Jedeme dal. Tak si predstavte, mate nejaky seznam (ciselnik) zaznamu a nastavite si, ze nad doklady typy XYZ se ma automaticky doplnit hodnota 123 (z toho seznamu). No a kdyz hodnotu 123 ze seznamu smaznete, tak ten default s naprostym klidem narve do databaze id jiz neexistujiciho zaznamu, coz navrch znamena, ze onen doklad nelze beznym uzivatelskym zpusobem nijak upravovat.
Pekne vam takto vzniknou nekonzistentni data a pri trose stesti to zjistite az po par tydnech/mesicich.

Navazuju na sve predchozi zazitky a pokracuji v osvete pro ty, kteri by se nekdy nahodou dostali do kontaktu s timto bastlem.

30 zaznamu je strasne moc. Neverite ? V roce 2010, TB databazi ... ? Mate 90 zamestnancu? To jste na tom jeste dobre, mzdove listy budete tisknout 3x. Vic nez 30 najednou je proste strasne moc a system vas posle doprdele. Jiste, stejna data ziskate z databaze dotazem bezicim sekundu, ovsem sytemu to trva minuty a tak, misto aby se vyresil adekvatni vykon, nastavi se omezeni na 30.

Mate pocit, ze spravce aplikace tu je od toho, aby vam nastavoval firemni postupy, pripadne administroval opravneni a dalsi aspekty ? Omyl, spravce je tu od toho, aby neustale resil neschopnost dodavatele. Napr ohledne navrhu databaze. Indexy si musi vymyslet sam, ovsem samozrejme, pokud neco prestane fungovat, dodavatel to svede prave na jeho indexy. Ve standardnim stavu trva takova extremne neobvykla vec, jako je pridani firmy na objednavku, bez problemu minutu i dele - podotykam, ze na naprosto nezatizenem SQL serveru. Nu coz, naflakate si tam indexy, zvetsite databazi na dvojnasobek, prikoupite za par M dalsi TB uloziste a zjistite, ze jakekoli ulozeni cehokoli trva 2x dele, protoze update vs indexy ...

Prijde vam normalni, ze system z verze na vezi umi sam udpovodajicim zpusobem osefovat databazi tak, aby vse fungovalo ? No to jste ale nekde jinde. HeG prevedete na novou verzi a zacnete se divit, ze misto Ano/Ne se vam ve formularich objevi 1/0 pripadne A/N ... proste to, co reprezentuje stav v databazi. Pak si samozrejme sami vyzkoumate(dodavatel nevyzkouma nic, jen vam posila nesmyslne odkazy na kdejakou hovadinu), ze je to tim, ze nova verze neumi pracova s typem char, tak si to alespon v uzivatelskych tabulkach prevedete na varchar a zjistite, ze stejny problem je v tabulkach dodavatele. Myslite si, ze to opravi ? Ale kdeze, opet vam posle odkazy na hovadiny, takze vam nezbyva nez to riskout, zmenit datovy typ a modlit se, aby v neblizsich 10ti letech na danou tabulku nesahal (coz se samozrejme nestane, struktura se meni s kazdou aktualizaci).

Myslite si, ze dodavatel, ktery se chlubi na svem webu ze je dodavatelem nejvetsiho ceskeho ERP ma lidi schopne programovat ? Jak naivni. Nejsem programator, ale co je to for tedy vim (narozdil od lidi prgajicich HeG). Myslite si, ze neco tak velkeho se navrhuje a programuje objektove ? :lol: Kdyby to tak bylo, tak by se preci nemohlo stat, ze nad stejnym objektem muzete pouzivat konkretni funcionalitu podle toho, z ktere strany do nej vlezete. Neuveritelne, ale celkem standardni. Prislo by vam normalni, nastavovat konfiguraci poptavek nad necim(pro znale poradacem), co se jmenuje poptavky ? Me take, ne tak vyvojarum HeG. Musite vlezt do dat. Prisilo by vam normalni nastavovat chovani a predvolene nastaveni funkcni nad seznamem funkci ? Nj, to by ste ale nesmeli byt u LCS/Asseco. Jim prijde normalni, ze si funkci pustite, vybleje to na vas tabulku, ktera muze byt pri jine prilezitosti jina, a po jejim vyplneni mackate "tajnou" kombinaci klaves "toto chci ulozit jako default".

Myslite si, ze by "moderni" ERP mel narosto normalne zvladat veci jako nastavovani uzivatelskeho vzhledu pro uzivatele/skupiny uzivatelu adminem ? Na to rovnou zapomente. Uzivatel si muze neco ubastlit a ulozit si to, ovsem pokud potrebujete neco zmenit centralne, tak musite vsem uzivatelum jejich nastaveni smaznout. Neco jako nastavit skupine X neco a Y neco jineho ... :lol: Muzete ovsem obehat vsech svych N uzivatelu a ponastavovat jim to rucne.

Jeste neco k pravum, neco uz sem zminoval, tak rada pro pripadne malo privilegovane uzivatele. Pokud vas neco zajima, staci kdyz v systemu mate pristup k filtrum (i radkovym). Do tech se da uplne vpohode vlozit query. Na webu se tomu rika sql injection a povazuje se to za jednu z nejzasadnejsich chyb jakou muze web mit. A pokud neznate strukturu databaze, nebojte se, system vam rad napovi, staci kdyz si do tzv "velkeho" filtru date vlozit vyraz. Nabidne vam to pekne seznam vsech policek. A co muzete s temer 100% jistotou ziskat ? No protoze na vsech dokladech je policko pachatel, tak pokud ho vidite, jako ze na 99% ano, tak mate pristup k veskerym udajum o zamestnancich - rodna cisla, mzda ...

Wow, ten posledný odstavec je perfektný. Mať niečo takéto vo veľkej spoločnosti, alebo v banke to by bolo peklo. :-)

Mno ... pouziva to dcerinka CEZu I&C Energo ... maji tusim 10k zamestnancu (zajistujou servis pro CEZ) .... nechapu jak stim muzou zit. Sice v tom asi nedela moc lidi zaroven, ale pocitaj jim v tom vejplaty.

Ad vykon, 50lidi zaroven, nedelajicich prakticky nic jinyho nez vytvareni dokladu (objednavky, vydej, prijem ...) sezere 2x4 na procesoru SQLka na 100%. To myslim celkem slusne vypovida o uzasnem navrhu databaze. Nacteni prehledu dokladu pak trva v nekteryh pripadech i 30+s, insert do DB i minutu a vic. Tzv "tenky" klient sezere vpohode dvoujadro na 100%. Zato tzv "aplikacni" server nedela nic (ale pro jistotu se kazdou noc restartuje IIS).

Co se bezpecnosti tejce, proste se spoleha na to, ze uzivatel je dement, kterej nikam nepoleze.

Kdo studoval na ZCU, mohl by referovat o kvalite databaze a ovladaci aplikace STAGu, pomalosti a molochovosti portalu a kravskemu predzapisu, ktery "zvenci" nefungoval a kdyz, tak jen velmi omezene a na fakultach mimo trojuhelnik take dovedene k dokonale nepouzitelnosti (tedy jeste pred dvema lety to tak platilo, ze se zadal pozadavek na misto na prednasce / seminari a za dve minuty to bud bylo, bylo obsazeno nebo doslo k chybe, to vse pak nasledovane celodenni seanci s papirovanim)... Na FAV to bylo jinak, tam se naklusalo do ucebny, povybiralo a za pul hodiny bylo i v indexu.

Citace:

---

Původně odeslal peta303

Kdo studoval na ZCU, mohl by referovat o kvalite databaze a ovladaci aplikace STAGu, pomalosti a molochovosti portalu a kravskemu predzapisu, ktery "zvenci" nefungoval a kdyz, tak jen velmi omezene a na fakultach mimo trojuhelnik take dovedene k dokonale nepouzitelnosti (tedy jeste pred dvema lety to tak platilo, ze se zadal pozadavek na misto na prednasce / seminari a za dve minuty to bud bylo, bylo obsazeno nebo doslo k chybe, to vse pak nasledovane celodenni seanci s papirovanim)... Na FAV to bylo jinak, tam se naklusalo do ucebny, povybiralo a za pul hodiny bylo i v indexu.

---

bajecny STAG zavadeli pred 6 lety ve Zline na UTB. Chyby systemu se omlouvali vyvojem a testovanim. Ja 4 roky po promocich jsem se opet setkal s timto "super systemem" a opet stejne chyby. Takze alespon na UTB se nic nezmenilo.

A mame tu dalsi pokracovani serialu ;). Viz vyse zminovane indexy. Dodavatel se(presne dle ocekavani) ohani tim, ze tam mame svoje indexy a ze je to pomale kvuli nim(inserty samo). Ale kdyz tam ty indexy nebyly, bylo to jeste 100x pomalejsi(na vsem ostatnim, protoze selecty) :D. Minuly tyden se samozrejme jedna nejmenovana odbornice pres databaze (select je pro ni sprosty slovo) vyjadrovala v tom smyslu, ze indexy nicemu nevadej a na namitky, ze to zpomaluje inserty rekla "ale jenom trochu". Mno ono u 120GB databaze to bude asi "trochu vic" ;).

Jinak celkem standard. Sefko dodavatele se svoji ekypou nasliboval, jak vsechno do dnes vyresi :D a dnes se po 15:00 ozval nakej jejich mamlas a ptal se, co ze to vlastne ma resit a plkal, ze sme nerekli co konkretne je pomaly (trace z databaze s odchycenymi 30s query mu je zrejme malo). Je uplne jedno s kym od nich se budeta bavit, pokud je to obchodak/managor, naslibuje vsechno. Pokud je to kdokoli jinej, posle vas doprdele. Jediny co uz od minulyho tejdne resej je, kde najit duvod nefunkcnosti na nasi strane (pro sychr mame HW dimenzovanej min 10x vejs, nez byly jejich pozadavky pro danej pocet useru). Navic pres nekolikere upozorneni ze se bude testit vykon systemu si nerekli co kde mame pozapinat a ted se ohanej tim, ze nemaj logy.

BTW: Pro znalce. Zkuste si predstavit insert, kterej obsahuje cca 5ti az 10ti nasobnej case + takovych 5 subselectu + joiny pres varchar ... taky vam vstavaji vlasy hruzou ? Vase nocni mura ? Ale kdeze, to je tak prumernej stav tohodle zazraku.

Citace:

---

Původně odeslal Jezevec

BTW: Pro znalce. Zkuste si predstavit insert, kterej obsahuje cca 5ti az 10ti nasobnej case + takovych 5 subselectu + joiny pres varchar ... taky vam vstavaji vlasy hruzou ? Vase nocni mura ? Ale kdeze, to je tak prumernej stav tohodle zazraku.

---

Se spatnym navrhem databaze se moc delat neda....leda pridat vic RAMky a pouzit SSD, pripadne nejak hodne dobre udelat indexy + vytunit SQL server (pokud to jde). Ale nekdy to proste uz lip udelat nejde a pak se stane, ze jeden join zabere 6 hodin a clovek s tim proste nic nenadela .8GB RAM+ SSD + MySQL a brzdou je 4GHz CPU core-i3. Ten join pres VARCHAR me ale pobavil :)

Citace:

---

Původně odeslal Jezevec

Mno ... pouziva to dcerinka CEZu I&C Energo ... maji tusim 10k zamestnancu (zajistujou servis pro CEZ) .... nechapu jak stim muzou zit. Sice v tom asi nedela moc lidi zaroven, ale pocitaj jim v tom vejplaty.

---

Nejsme uz dcera CEZu a zamestnancu je cca 1500. Kdyz se pocitaji vyplaty, tak je system naprosto nepouzitelnej a neda se s nim normalne delat.

2wong: kdyz sme byli na navsteve (uz to bude tak 2 roky), tak nam tvrdili, ze vejplaty pocitaj 3 dny v kuse :D. Jinak ze si sem tam nekdo vyrobi objednavku na dily.
2petrik: dve ctyrjadra + 64GB RAM ti prijde malo ? + SAN cx3-10 (FC, SQL ma pro sebe dokupy 18x 15k disk v R10) ?

Jezevec: ano tak nejak to je, proto jsem opravoval pocet zamestnancu... :(

Citace:

---

Původně odeslal Jezevec

2petrik: dve ctyrjadra + 64GB RAM ti prijde malo ? + SAN cx3-10 (FC, SQL ma pro sebe dokupy 18x 15k disk v R10) ?

---

Hm, vsadim se, ze kdyz se zbavite toho SANu a nahradite ho jednim, nebo nejlepe nekolika X25-E/M s dobrym HW RAIDem R10, tak se vykon zmnohonasobi, tedy za predpokladu ze se neco z tech disku vubec taha. SAN ma totiz jeden problem a tim jsou latence. Porovnej latence FC (tedy neco ala ethernet) vs. lokalni SATA/SAS disk/SSD. Navic tech 15k disku vpoli muzes mit treba milion, ale latence budou porad radove horsi nez u jedineho SSD. V jedne firme jsem udelal obyc server s raptorem a 16GB RAM a oracle na tom behal rychleji nez na nejakym brutalnim IBM POWER serveru a to jen kvuli tomu, ze tam bylo nejaky hyper mega ultra SAN pole (celkem za miliony), ktery bylo desne pomaly...

SAN ma podle me smysl u clusteru, kdy to bez nej nejde (jde, viz google :) ), ale pro jeden server existuji lepsi vecicky a vyrabi je napr. firma Fusion-iO :)

http://www.fusionio.com/products/iodriveduo/ tahle hracka uz asi neco zvladne :)

NAND Type Single Level Cell (SLC) Multi Level Cell (MLC)
Write Bandwidth 1.4GB/s (32K packet size) 1.0GB/s (32K packet size)
Read Bandwidth 1.5GB/s (32K packet size) 1.4GB/s (32K packet size)
IOPS* 185,022(4K read packet size)
129,699(75/25 r/w mix 4K packet size) 122,601(4K read packet size)
121,008(75/25 r/w mix 4K packet size)
Access Latency <50µs Read <80µs Read

Mimochodem tohle DUO ma dvojnasobne latence nez "single", ktery ma 26µs, coz je proste mazec. To uz ma bliz k RAMce, nez k diskum.

Dalsi vec je pocet jader a skalovani vykonu. Nezapomenu, jak jsem do onoho obyc serveru s oraclem dal misto 3GHz dualcore 2.9GHz quadcore a vykon sel kam? vykon sel do kytek (4x pomalejsi), protoze vsemocny buh Oracle zvolil nejaky suboptimalni algoritmus nebo co a pomohla az nova verze Oracle serveru... jen mimochodem v te dobe jsem o SQL nemel ani paru, ten Oracle resil jeden dost zkuseny DBA..

Netusim jak je na tom MS SQL vs. skalovani vs. multithreading, ale napr. vim, ze MySQL pro jedno spojeni pouziva jen jedno vlakno, takze jader muzu mit treba deset a je mi to prd platny (proto ho provozuju na OC dualcore).

Tak na tom SANu neni jen SQL samo a vzhledem k velikosti databaze vs velikost dat/indexu se to vpohode vejde prakticky cely do RAMky, ty disky i podle stats vicemene jen zapisujou, cteni je naprosty minimum. Jak sem psal, zatezuje to CPU. A to "by woko" 3x vic nez "zastarala" PB verze. Je proste videt, ze nekdo optimalizoval az zoptimalizoval a zakaznici at se poserou. Druha vec je, ze paac M$, se neda rict, estli dalsi CPU pomuze nebo ne. M$ je na tom obecne tragicky a navic se to jejich SQLko chova tak kokotsky, ze kdyz jedinej user posle "pekny" query, tak sezere vsechny CPU a neprihlasis se ani na konzoli ....

2wong: mati je mzdovka, pocita tusim neco kolem 150 vejplat a vypocet trva mozna minuty na obyc PC, ale dyl IMO ne (schvalne se poptam).

Ze to bezi na MS samozrejme ani nekomentuju, to je kapitola sama pro sebe...

Na co bych se zameril je tuning nastaveni toho SQL serveru. Vubec netusim, zda jde vubec neco nastavovat, MS SQL jse nevidel ani z vlaku, ale vim, ze napr. dobra vs. spatna konfigurace MySQL muze znamena RADOVY rozdil ve vykonu (klidne i nekolik radu). Zasadni vec je napr. mit pokud mozno temporary tables v RAMce, zamezit double-bufferingu FS OS+SQL a pod.

Jestli tam ale ti autori provadeji JOIN pres VARCHAR, tak je zcela evidentni, ze to jsou naprosti SQL amateri a lemplove a v tom pripade pomuze leda tak zazrak... takze uprimnou soustrast a dobrou noc.