Linuxový ERP systém abas od amotIQ

26. 11. 2009 | Václav Stodůlka | Různé | 4346×

Firma amotIQ je výhradním distributorem ERP (enterprise resource planning) systému abas v ČR. Serverová část abas běží na Linuxu a amotIQ jej lokalizuje, přizpůsobuje české legislativě a ladí dle konkrétních přání zákazníků.

V dubnu šla na AbcLinuxu.cz výzva, aby se ozvaly firmy, které používají OSS. Prohodili jsme s Robertem Krátkým několik mailů, ve kterých jsem slíbil, že napíšu dva články, a tím tato aktivita na půl roku ustala, až by si jeden myslel, že šla úplně do ztracena. Ale slip(b)y se mají plnit, zvláště pak o Vánocích, takže se můžete začíst do článku o vynikající spolupráci OSS operačního systému a velké komerční aplikace.

Teď tedy to hlavní - odpověď na otázku, jaký OSS ve firmě používáme. Kromě již obvyklých firemních matadorů, jako jsou Firefox, OpenOffice.org nebo (občas) Gimp je naše firma specifická tím, že prodává a implementuje podnikový řídící systém abas ERP, který je produktem německé firmy Abas AG. Ten má jako primární serverovou platformu právě Linux na různých architekturách (x86, x86_64, IA64 a Power), teprve jako sekundární architektura jsou Windows (o detailech níže).

Kdo je amotIQ a co dělá?

amotIQ, s. r. o., je výhradním distributorem ERP systému abas v České a Slovenské republice, má zde okolo třiceti aktivních zákazníků - veskrze výrobní podniky malé (s tržbami do 0,5 mld. Kč/rok) a střední (s tržbami do 2 mld. Kč/rok) velikosti. Kromě svého kmenového produktu - abas ERP - dodává amotIQ také systém pro řízení kvality RQM od výrobce Pickert & Partner nebo produkt Corporate Planner, který by se dal zjednodušeně zařadit mezi MIS (manažerský informační systém), ale jeho záběr je mnohem komplexnější než bývá u MIS obvyklé.

Zákazníky amotIQu pravděpodobně znát nebudete, protože to jsou veskrze „neviditelní“ subdodavatelé, proto uvedu spíše jejich výrobky a odběratele, což už by měla být známější jména. Naši zákazníci vyrábí například titanové ojnice pro Porsche, kované díly pro kamiony Scania nebo součástky pro nápravy Opelu/GM, elektrické a elekronické součásti do světel na kamiony, kompletní stroje pro těžbu dřeva, díly do převodovek snad všech značek (Mercedes, Škoda, Toyota, Honda, ...), ale kromě těchto zvučných jmen máme například i zákazníka, který přeprodává spojovací materiál, nebo výrobce vánočního (a jiného) osvětlení zejména pro supermarkety a města.

Já osobně pracuji v amotIQu jako něco mezi konzultantem a programátorem. Původně jsem nastupoval jako „systémový architekt“, což je prakticky vedoucí programátor, později se ale ukázalo, že jsem použitelný i pro konzultační účely, takže mám práci o něco rozmanitější.

Co je abas ERP?

Marketingový newspeak by řekl asi něco jako „abas ERP je pokročilý, komplexní a integrovaný podnikový řídící systém s integrovaným finančním a nákladovým účetnictvím“. Přeloženo do normálního jazyka to funguje asi tak, že po založení všech základních dat (zákazníci, dodavatelé, díly, pracoviště, ...) a jejich parametrizaci (který díl má mít jakou skladovou zásobu, který zákazník má mít jakou splatnost) nasypete do systému objednávky zákazníků a systém vypočítá, co máte kdy nakoupit, co máte kdy vyrobit a co k tomu potřebujete (materiály, kapacity), co máte kam poslat a co komu zaplatit a vyfakturovat. Pak nákupčí v systému nakupují, výrobáci vyrábí a hlásí, co vyrobili a co spotřebovali, prodejci prodávají a fakturanti (tedy častěji fakturantky) fakturují. Na pozadí toho všeho běží finanční účetnictví a nákladové účetnictví, což je zjednodušeně řečeno účetnictví uvnitř firmy.

My děláme pro systém českou a slovenskou lokalizaci - tj. překlady a programové úpravy pro soulad s českou a slovenskou legislativou. Pak samozřejmě systém nabízíme a prodáváme a děláme do něj zákaznické úpravy specifické pro každou implementaci. Kromě toho všeho vytváříme v systému funkce, které samotný systém nepokrývá a které se hodí pro více zákazníků - například v současné době pracuji na plánování a řízení údržby vlastních strojů (preventivní prohlídky, opravy, ...).

Ukázka vývoje

abas a Linux

Linux je primární platformou pro server abasu. Kromě Linuxu jde provozovat server i na Windows, ale má to několik úskalí. Je třeba zakoupit (kromě Windows serveru) MKS Toolkit (navíc licence toolkitu vyžaduje poplatek i za každého klienta), což je prakticky produkt velmi podobný Cygwinu, jenom placený a komerční. Po zkušenostech nemáme MKS toolkit moc rádi, protože v něm číhají lahůdky jako korn shell nebo prehistorický bash (ani jeden nemá např. použitelnou historii příkazů), jako terminál slouží terminál Windows (zkuste si v cmd copy - paste, opravdu lahůdka) a administrativní zásahy (reorganizace databáze, přegenerování obrazovek, kopie databáze, ...) jsou oproti „nativní“ linuxové verzi asi čtyřikrát pomalejší. Když si připočteme další parádičky Windows (nutnost přihlašovat se na Windows terminal server, např.), vychází z toho, že pokud má někdo z nás provádět něco na Windows instalacích, už předem nám z toho naskakuje husí kůže. Ale nesmíme to říkat moc nahlas, přece jenom jsou Windows oficiálně podporovaná platforma a pro práci v systému samotném nehraje platforma serveru žádnou roli.

Linuxová verze serveru je oproti Windows verzi mnohem více „admin friendly“. Z distribucí je podporovaný, kromě obou hlavních enterprise - tedy RHEL i SLES, ještě Debian. Dříve jsme prodávali k abasu RHEL, ale můžu říct, že ani Red Hat, ani SUSE to nemají lehké. Linux je prostě v povědomí zákazníků „ten systém zdarma“ a pokud za něj mají platit cca 10 000 Kč ročně, je jim to nějak divné. Abychom předešli těmto diskusím, přešli jsme pozvolna pro nové instalace na Debian.

Co se týká klienta abasu, je situace oproti serveru obrácená. Klient je nativní Windows aplikace, ale je oficiálně podporován běh klienta pod Wine. Abas AG dokonce poskytuje optimalizovanou verzi Wine pro spuštění klienta. Abych pravdu řekl, žádný z našich zákazníků Linux na stanicích nepoužívá, linuxového klienta jsme rozbíhali pouze jednou přímo z freeNX instalovaného na serveru abasu. Fungoval.

Čeho si ale na abasu při své každodenní práci cením nejvíce, není jenom „běží pod Linuxem“, ale zejména „linuxový feel“ celého systému. Posuďte sami z několika aspektů:

• abas má dodnes funkční textové (aka „ncurses“) rozhraní. Přihlásíte se na server pomocí ssh a můžete si spustit textového klienta. Pravda, dnes už se nevyužívá a oproti GUI má některá omezení, ale jednoúčelové použití někde ve výrobě je stále možné.

• abas má síťový textový komunikační protokol nazvaný EDP. Session se podobá naříklad komunikaci s SMTP serverem. Já napíšu login a heslo, systém mi odpoví, pak zadám příkaz, systém jej provede a zahlásí „OK“ nebo „chyba“. Pomocí EDP můžete se serverem komunikovat stejně jako přes GUI. Napsal jsem několik programů v Perlu, které to využívaly pro různé interaktivní akce, při kterých je potřeba odezva od systému a na základě ní se pak program nějak zachová.

• Programy abasu jsou uložené na disku v souborech. Jde na to nasadit git, subversion, jdou kopírovat, symlinkovat, upravovat přes ssh a vim, zálohovat, cokoli se dá dělat se souborem.

• Tisky jsou řešeny přes lpr, popřípadě (dnes ve většině případů) se pomocí jasper reports generují PDF soubory, které se podhodí klientu. Každopádně transformace proběhne na serveru.

• Otevřené okno v klientu = proces na serveru vyvolaný přes inetd/xinetd. Dá se na něj dát kill, dá se na něj pustit "strace", automaticky se tak balancuje zátěž na serveru, dá se pomocí toho škálovat do clusteru. Navíc tak jde systém spouštět vzdáleně bez potřeby vzdálené plochy, stačí zkopírovat binárky klienta.

Kolik oken máš, tolikrát jsi procesem

abas ERP je zkrátka pěkným důkazem toho, jak může prorůstat OSS a jeho myšlenky do komerční sféry. Taky je příjemné vidět, že mezi výrobci ERP systémů nejsou jenom ti, kdo Linux nikdy nebudou podporovat už z principu (Microsoft Dynamics), popřípadě kteří jsou na Microsoftu technologicky závislí (QI/Helios, ...), ale že jsou i firmy linuxové řešení aktivně podporující (SAP nebo abas).

       

Komentáře

[Dalibor Smolík]

Zajímavý článek, je vidět, že v oblasti ERP se toho na linuxové platformě hodně odehrálo, jen mě trochu zklamalo, že klient musí být opět Windows, což k rozšíření Linuxu v komerční sféře příliš nepřispěje. Nevím, ale používání wine v takovém typu aplikací asi není to pravé ořechové .. Nicméně určitý pokrok tady je.

[xvasek]

Ono je to těžké - když výrobce ví, že 99% klientů pojede na Windows, tak se těžko začíná s nativním Linuxovým klientem. Na druhou stranu klient abasu je opravdu velmi hloupý - server mu nejprve "nadiktuje" rozložení obrazovky (které pole kam a s jakým popiskem) a pak vzniklou masku naplní daty. Když se v klientu dělá nějaká akce - např. zadání hodnoty do pole - je tato hodnota okamžitě odeslána na server a veškeré zpracování se děje server-side; server pak může například klientovi říct, aby aktualizoval nějaká další pole (v závislosti na zadané hodnotě), nebo aby vypsal nějakou hlášku, otevřel nové okno, whatever. V klientovi tedy opravdu není žádná logika (klient je vlastně jenom grafická obálka nad protokolem) a taková aplikace pod wine provozovat celkem bez problému jde.

U konkurence to bývá často buď tak, že celá logika je vlastně v klientu, který se přímo připojuje k databázovému stroji, nebo se pracuje po transakcích - klient načte objekt z aplikačního serveru v jedné transakci, pak si s ním hraje sám bez komunikace se serverem a když člověk zmáčkne "uložit", tak se to zase v jedné transakci šoupne na server. U takového přístupu bych chápal obavy z použití wine jako zcela oprávněné.

[pasmen]

Takový klient rozhodně není hloupý, ale plně se podřizuje oddělení aplikační a prezentační logiky. Např. SAP taky pracuje v jistém slova smyslu transakčně. Jeho three-tier architektura je celkem vymakaná. Klientská vrstva (prezentační server) v podstatě přes dispatcher pouze komunikuje s aplikačním serverem v dialogových krocích, přičemž každý dialogový krok může obsluhovat jiný proces na aplikačním serveru. Dialogový krok začíná a končí jakýmkoliv vstupem uživatele, nejen uložením. Navíc klient není hloupý, např. pokud uživatel nevyplní povinné pole, dokáže tohle zařídit prezentační logika, aniž by musela obsahovat aplikační server. Transakce (tedy databázová transakce) končí až ve chvíli splnění posledního dialogového kroku, aby v případě, že se něco nepodaří mohl aplikační server provést rollback a data zůstala konzistentní.

[xvasek]

"Hloupým" klientem jsem myslel opak od "tlustého". Jinak ano, SAP funguje technologicky celkem podobně. Holt jsou to systémy, které ví, jak správně na věc.

[Opičák]

No SAP vidím z druhé strany jako uživatel. A je to nechutně klikoidní aplikace. Opravdu na nějaké celodenní pracování to není. 100 zbytečných tahů pro jednu věc. Nezaujal mě ale bohužel ho musím používat.

[MIchal]

Má abas integrované nákladové účto?

[Frantisek]

jestli jsem to spravne cetl, tak autor pise, ze ano. Neco jsem spatne pochopil?

[Michal]

Autor pise ze bezi na pozadi, mne zajima jestly je integrovane - automaticky vypocet rezii atd...

[xvasek]

Nákladové účetnictví samozřejmě integrované je, systém počítá náklady a výnosy středisek sám, různá rozpočítání jdou taky nastavit a dějí se "samy". Nicméně se přiznám, že toto je pro mě už opravdu tenký led, takže bych se nerad osobně pouštěl do nějaké hlubší diskuse. Pokud by byly nějaké konkrétnější otázky, můžu je předat kolegyni, která je ráda zodpoví, ale spíš by to bylo asi lepší řešit e-mailem, protože už se posunujeme dost mimo zaměření původního článku a serveru obecně.

[Stano]

Podporuje abas aj portálové riešenia?

[xvasek]

Ano. Standardně jsou dva portály - jeden je zdarma, postavený na bázi liferay (+ portlety samotné jsou v Tibcu), který je určený víceméně spíš pro interní použití uvnitř firmy. Druhý placený se jmenuje "abas eB", ten se používá pro takové to opravdové portálové nasazení - ale to by bylo minimálně na další článek, spíš seriál.

[Frantisek]

protoze pisete, ze jste slibil 2 clanky, ocekaval bych pokracovani (nejsem si ale )jist, zda bude. Pro jistotu, ze kdyz uz pokracovani nebude, nekolik bodu, ktere (kdyz uz se zde takova problematika popisuje) by me (a mozna par ostatnich) zajimaly:

System:

• jakou databazi/e pouziva abas a je zde nejaka zvlastnost
• replikace, read-only server pro reports, listings, screens
• sprava background procedur, fronta vyrizenych uloh, pokracovani v uloze
• fax z aplikace (poptavka primo na fax, mail)
• podpora telefonie (volit tel.c. z aplikace, zobrazeni zakaznickych udaju pri prichozim hovoru)
• testovaci systemy,
• sber osobnich/provoznich dat (integrovan?, jake terminaly, mozno pouzit PC)
• dilensky monitoring
• podpora v expedici (termotiskarny pro stitky), dokumentace pro zakazku/jednotlive dily, kompletace instrukcnich podkladu/navodu k pouziti orientovanch na zakazku/dil
• sprava helpu na firemni , aplikacni uzivatelske urovni
• podpora PDA. mobile apod
• vicejazycne aplikace, omezeni

Filozofie

• podpora mandantu, vicefirmeni spoluprace (jeden nakupci pro vice firem)
• jak je resen dilensky monitoring
• jaka filozofie se skryva za planovanim vyroby
• reseni pristupovych prav (databaze , aplikacni server)

klient

• jakym stylem se deklaruje vzhled klienta a jak je svazan s daty
• jak se definuje vzhled formularu
• jak se definuje/programuje logika, ktera 'plni' formulare
• jak jsou administrovany tiskarny (jak svazane s uzivatelem, oddelenim, aplikaci)
• co je s GDI/nonGDI tiskarnami, ktere visi primo na pracovnich stanicich
• je pri provozu tiskaren pres lpr mozno vyuzivat specifickych tiskarenskych funcki (duplex,A3.)
• jak je resena velikost masek v klientu (zmena velikosti, font, fixace velikosti pro uzivatele)
• automatizace v klientu (zapnuti preddefinovynach masek na urcitem miste obrazovky)
• jak je podporovan multimonitor provoz (popup na druhe obrazovce? )
• multiwindow funkcionalita nebo pouze jedna maska v jednom okamziku)
• na jednom vasem screenu chybi 'y' u labelu (problem s velikosti labelu, prepslo by to edit )
• jak je odlisen v klientu testovaci system od produktivniho
• jak jsou realizovany graficka znazorneni udaju (kapacity, spotreby)
• jak je v klientu resena problematika pristupovych prav v situacich, kdy pristupova prava zavisi na konkretnim stavu dat (napr. pri zobrazeni dat je jiz jasne, ze nemohou byt zmenena)
• prebirani dat z excelu/jinych kancelarskych aplikaci na strabne klienta
• editacni moznosti pro nabidkove texty (formatovani, vzhled)
• integrace vykresove dokumentace (cad viewer)
• podpora konstrukce, svazanost s cad, napr. moznosti blokovani skladu/produkce pri konstrukcnich zmenach
• uzivatelske menu

upravy aplikace:

• jak se programuji dodatecne business-funkce (jazyk, podpurne prostredi, moznosti koncoveho uzivatele)
• programovani a uprava reportu
• uprava clienta
• uzivatelske menu (uzivatel/admin ?)

[Joseph]

Tak toto je aj na dva články.

[xvasek]

Wow, to je materiálu. Další článek bude (pokud mi jej na abclinuxu vezmou , měl by být spíš technicky zaměřený a chtěl bych vypíchnout různé finesy. Jinak zkusím odpovědět:

jakou databazi/e pouziva abas a je zde nejaka zvlastnost

Abas používá vlastní databázi, která se jmenuje "ekslogdb". Specifická je tím, že není SQL a je "objektová". Určitě se k ní dostanu v příštím článku.

replikace, read-only server pro reports, listings, screens

Replikace na druhý server / cluster může běžet na pozadí. Druhou možností je, že abas umí "zastavit zápis do databáze" (všechny změny od klientů se dějí do paměti a klienti se nic nedoví), pak se dá databáze "ukradnout" (cp, tar, rsync, cokoli je libo...) a znovu spustit zápis. Tím se dá vytvořit záložní read-only server, ale popravdě pro různé OLAP využíváme spíš vypumpování dat do MySQL / MSSQL / whatever, protože databáze je nestandardní.

sprava background procedur, fronta vyrizenych uloh, pokracovani v uloze

Popravdě se to moc nepoužívá, protože celý systém je navržený tak, aby všechno probíhalo okamžitě - třeba MRP běh je "net-change", takže trvá pár sekund. Jinak se ale dají spouštět úlohy přes interní spooler nebo přes cron. Využíváme to pro EDI, které má pak ale vlastní prostředí v GUI, kde jde vidět, co se zpracovalo a co zůstalo někde ležet.

fax z aplikace (poptavka primo na fax, mail)

Mail ano, fax přes řešení třetí strany - systém vysype PDFko, k tomu je v podstatě známé telefonní číslo a obojí je potřeba někam nacpat.

podpora telefonie (volit tel.c. z aplikace, zobrazeni zakaznickych udaju pri prichozim hovoru)

Volání z aplikace ano, zobrazení zákaznických údajů primitivně přes DDE (= Windows).

testovaci systemy,

Jako jestli je možné mít oddělenou databázi pro testování? Ano.

sber osobnich/provoznich dat (integrovan?, jake terminaly, mozno pouzit PC)

PC použít možno, ale je potřeba licence. Pro tyto jednorázové účely jsou licence samozřejmě za speciální ceny. Nicméně pořád je potřeba Linux nebo Windows na terminálu, což je omezující. Proto používáme občas řešení třetích stran, které mají terminály třeba jenom s dvouřádkovým ascii displayem a klávesnicí.

dilensky monitoring

Co vejde do systému ve zpětných hlášeních, to se tam samozřejmě zobrazí.

podpora v expedici (termotiskarny pro stitky), dokumentace pro zakazku/jednotlive dily, kompletace instrukcnich podkladu/navodu k pouziti orientovanch na zakazku/dil

Vše podporováno, ale je to potřeba chápat tak, že něco je standard a zrovna v expediční dokumentaci se (pokud to není VDA) vždycky dělá na přání zákazníka.

sprava helpu na firemni , aplikacni uzivatelske urovni

Help je aplikační (od výrobce / distributora) a dá se doplnit o vlastní (=firemní). Uživatelský není, ale dá se to řešit pomocí abas portálu, který se umí integrovat do GUI.

podpora PDA. mobile apod

Přímá podpora (nativní klient) není, ale dá se pracovat přes abas eB (webové rozhraní).

vicejazycne aplikace, omezeni

Vícejazyčnost je základní vlastností, jsou jazyky, ve kterých se dá přihlásit do GUI a jazyky korespondenční - těch bývá typicky víc. GUI tak může být CZ / EN / DE a korespondence pak běží například ještě v Polštině, Ruštině, Francouzštině. Zapnutí jazyků je v podstatě otázkou zatržení políčka v konfiguraci.

Omezení je v tom, že základním jazykem je Němčina a zbytek vzniká vlastně překladem. My to často "obcházíme" tím, že texty vkládáme rovnou česky, ty se v systému tváří jako německé a pokud pro dané věty neexistují překlady, použijí se německé (=naše) ve všech jazycích.

podpora mandantu, vicefirmeni spoluprace (jeden nakupci pro vice firem)

Pro toto se využívá EDI a funkcionalita zvaná multisite. V podstatě neexistuje jeden hlavní systém a několik "slave" (pokud se to takto nenakonfiguruje), nebo že by se všichni hlásili k jedné jediné databázi, ale vše je peer-to-peer a jednotlivé servery si vyměňují informace podle konfigurace EDI. Jeden nákupčí má tedy typicky svou vlastní instalaci a s ostatními si vyměňuje EDI zprávy.

Pokud navíc běží více abas serverů na jednom fyzickém hardware, mohou si navzájem sdílet licence - tzn. pool licencí je společný a všichni si z něj půjčují.

jak je resen dilensky monitoring

No, to je hodně široká otázka - v podstatě každé pracoviště má frontu práce a bere si z ní, vždycky je vidět, co má dělat a co udělal (ze zpětných hlášení). Pohledy jsou v podstatě dva - jeden na úrovni výrobních příkazů a jeden na úrovni operací (pracovních kroků) samotných.

jaka filozofie se skryva za planovanim vyroby

Základem je prakticky klasické MRP II s net-change (takže běží rychle, typicky jenom několik sekund). Pak se v tom dá různě vrtat - posouvat celé výrobní příkazy nebo jenom operace, fixovat, měnit množství.

reseni pristupovych prav (databaze , aplikacni server)

Přístupová práva řeší aplikační server, pro samotná práva se vytvoří šablony a ty se přidělí uživatelům. Fajn je, že jsou rozdělené databázové tabulky a pak ještě příkazy. Třeba příkaz "běh MRP" zasahuje do hodně tabulek, ale protože se nastavují práva na příkaz, není potřeba řešit to ještě na tabulkách. Pro různý "fine-tuning" se pak použijí programy pověšené na "maskein" event.

jakym stylem se deklaruje vzhled klienta a jak je svazan s daty

Pro GUI klienta je to textovým konfiguračním souborem - je v něm IP serveru a port, umístění samba share (nebo nfs cesta) a barvy + loga.

jak se definuje vzhled formularu

Existuje grafický návrhář, který "vyplivne" XML, ale my staromilci používáme mnohem raději textový soubor, do kterého se napíše, kam se má které pole umístit. Dynamická změna formuláře za běhu pak už není možná.

jak se definuje/programuje logika, ktera 'plni' formulare

No, jsou v podstatě dva typy formulářů - formuláře nad daty (například nad objektem "dodavatel") a ty plní systém sám + pole, u kterých to aplikační server dovolí, se dají ještě změnit / naplnit programem.

Pak jsou tzv. "infosystémy", což by se dalo přeložit jako interaktivní report. U toho člověk začíná "na čistém stole", nejprve si zadefinuje proměnné, pak je rozmístí na formuláři (nebo to nechá udělat systém automaticky a pak do nich nahraje data programem odkudkoli ze systému.

jak jsou administrovany tiskarny (jak svazane s uzivatelem, oddelenim, aplikaci)

Tiskárny jsou veskrze systémové a lokální. Systémové tiskárny se administrují přes lpd (popř. cokoli kompatibilního - třeba cups), o lokální tiskárny se systém nestará, protože vyplivne uživateli PDF, které se typicky otevře v PDF prohlížeči a odtud jej uživatel vytiskne. Systémové tiskárny jde svázat s konkrétním reportem (např. výrobní příkaz vždycky vyjede ve výrobě), popřípadě se vazba k čemukoli dá dělat primitivně programem ve stylu if oddělení = kontrola then tiskárna = hplj16 a rovnou tiskni.

co je s GDI/nonGDI tiskarnami, ktere visi primo na pracovnich stanicich

Stanice dostane PDF, to si pak může tisknout, mailovat, uložit, co se jí líbí.

je pri provozu tiskaren pres lpr mozno vyuzivat specifickych tiskarenskych funcki (duplex,A3.)

Ano, řešili jsme to pomocí nadefinování více tiskáren v CUPS a tiskárnám jsme přidali "banner před" a "banner po", kde byly esc sekvence pro nastavení. Tak třeba normální výrobní příkaz vyjede na normální papír a spěšný na červený z jiného zásobníku.

Jinak je nějaké nastavení i v systému, ale měnit to pro každý tisk...

jak je resena velikost masek v klientu (zmena velikosti, font, fixace velikosti pro uzivatele)

Popravdě řečeno nijak. Pokud si uživatel nastaví font tak veliký, že se mu maska nevejde na obrazovku, tak má holt smůlu. Jo, a dají se připravit speciální masky pro malé obrazovky.

automatizace v klientu (zapnuti preddefinovynach masek na urcitem miste obrazovky)

To je otázka WM, na to abas nesahá. V Linuxu se s tím dá hrát, ve Windows je to tuším tak, že maska se otevře stejně veliká, jako byla naposledy a na stejné místo.

jak je podporovan multimonitor provoz (popup na druhe obrazovce? )

Popup je je AFAIK jenom na první, pokud ovšem WM neřekne jinak. Myslím, že pod Windows toto zrovna umí řešit panel nVidia.

multiwindow funkcionalita nebo pouze jedna maska v jednom okamziku)

Multiwindow, vždy. abas je vlastně takový Gimp.

jak je odlisen v klientu testovaci system od produktivniho

Typicky barvou - testovací bývá žlutý a oranžový, "ostrý" necháváme v původní "abas" zelené, nebo jaká to je. + ještě logo.

jak jsou realizovany graficka znazorneni udaju (kapacity, spotreby)

Prostředí umí grafy. Mohl jsem dát nějaký do screenshotu, příště se polepším.

jak je v klientu resena problematika pristupovych prav v situacich, kdy pristupova prava zavisi na konkretnim stavu dat (napr. pri zobrazeni dat je jiz jasne, ze nemohou byt zmenena)

Programem na eventu "maskein".

prebirani dat z excelu/jinych kancelarskych aplikaci na strabne klienta

Přes script "edpimport.sh". O něm napíšu v příštím článku.

editacni moznosti pro nabidkove texty (formatovani, vzhled)

Je možnost editace formuláře výtisku (JasperReports), ale jednotlivé pole bude vždy stejným fontem. Šlo by asi embeddovat nějaké PDF, ale popravdě jsem to nikdy neřešil.

integrace vykresove dokumentace (cad viewer)

Externí a není problém. (Ani trávník sekat neumí, ale slibují v příští verzi.

podpora konstrukce, svazanost s cad, napr. moznosti blokovani skladu/produkce pri konstrukcnich zmenach

To se musí řešit hlavně organizačně. V principu je na dílu flag, jestli jde použít nebo ne, ale říct, že to řeší tento problém, by bylo příliš sprosté zjednodušení.

uzivatelske menu

Je. Je uživatelské, několik administrátorem přidělených + základní, každé jde upravit (kromě základního), zakázat nebo povolit u uživatele...

jak se programuji dodatecne business-funkce (jazyk, podpurne prostredi, moznosti koncoveho uzivatele)

Na to bych se podíval v příštím článku.

programovani a uprava reportu

JasperReports, popřípadě pak tisk do "Excelu", OOo apod. Ale nic zvláštního.

uprava clienta

Přiznám se, že moc nerozumím otázce, ale na hlavní metody se podívám příště.

No, tak se dívám, že by to mohli vydat jako další článek.

[Frantisek]

mohl bych napsat jednoduse dekuji, ale prijde mi to jaksi malo. Takze, mockrat dekuji (), za nas za vsechny, kteri se radi dovi vzdycky neco vice nez tu marketingovou omacku.

Ze by to vydalo na vice clanku je samozrejme, ono je ovsem na case, aby se i na tomto portalu zaclo mluvit o skutecne informacni technice. Tesim se na pristi clanek a uz si pripravuji dalsi otazky ...

[OndraZX]

Bohuzel Abas take ve firme mame.

Je to zastarala, nekompatibilni, pomala a uzivatelsky neskutecne neprivetiva aplikace.

Jen kratce: vylepsena souborova databaze (neni to SQL) s nestandardnim kodovanim (v dobe vzniku neexistovalo ani ISO8859-2), historie saha do 70 let = Abas tahne porad sebou tuto historii = jeste nedavno jen textovy rezim, nekompatibilita s nicim, klient je naprosto otresny, problemy s tiskem, atd. Protoze lokalizacni podpora je velmi slaba, mnoho vyrazu je neprelozeno, nebo vyznamove stejne polozky maji rozdilny preklad. Z tohoto duvodu neobsahuje modul mzdy - casta zmena zakonu.

Takze misto toho aby vyrobce se zbavil historicke zastaralosti tohoto produktu a napsal novou verzi od zakladu znova, tahne sebou kouli nekompatibility a zastaralosti a podle toho to tak vypada.

Firma ktera prezije implementaci SAPu, prezije vsechno.

Firma ktera implementuje Abas nemuze prezit.

PS: tento zapisek je mym osobnim nazorem a nemusi se ztotoznovat s nazory me firmy.

PS2: muzu poskytnout dalsi info

[Frantisek]

vylepsena souborova databaze (neni to SQL) ..

jake problemy jsou s tou databazi ?

- pada

- k datum je mozno pristouput pouze pres abas-aplikaci

- neexistuje export do nejakeho standardniho formatu

- neexistuje ODBC driver pro windows

- neexistuje ODBC driver pro uunix

- neexistuje zadny interpretacni jazyk (perl, python, ..) pres ktery je mozno manipulovat data

- je pomala

[OndraZX]

vylepsena souborova databaze (neni to SQL) ..

jake problemy jsou s tou databazi ?

1- pada

2- k datum je mozno pristouput pouze pres abas-aplikaci

3- neexistuje export do nejakeho standardniho formatu

4- neexistuje ODBC driver pro windows

5- neexistuje ODBC driver pro uunix

6- neexistuje zadny interpretacni jazyk (perl, python, ..) pres ktery je mozno manipulovat data

7- je pomala

1 - ne

2 - standardne ano

3 - to co si pracne vyfiltrujete (a filtrace je opravdu "zahul") muzete zkopirovat do Excelu,OO.org

4 a 5 - existuje, ale radeji se neptejte za kolik

6 - myslim ze ne

7 - ano velmi

[xvasek]

1 - Souhlas

2 - Nesouhlas. Můžete (kromě GUI) přímo přes EDP protokol, přes edpexport.sh a edpinfosys.sh (export do CSV, XML, textu...), dále přes eB, nebo portal. My dodáváme navíc naše vlastní rozhraní do různých DB - MySQL, Postgresql, MSSQL, cokoli existuje DBI pro Perl.

3 - "ručně" jak píše OndraZX, pak XML, CSV, do dalších DB.

4 - Existuje, prodává se zvlášť za cenu jedné licence.

5 - AFAIK neexistuje

6 - Standardně mají knihovny Java (JEDP) a Python (PyEDP), dále pak cokoli dalšího - EDP protokol je textový a samotný je primitivní, píšu pro něj programy v Perlu. Vše je popsané v přímo v helpu. Pomocí edpimport.sh je pak možno velmi primitivně manipulovat daty třeba i z bashe.

7 - To je sice velmi kategorické tvrzení, ale bohužel neobsahuje moc faktických informací. Mám tady server s netBurst Xeonem, někde okolo 2,6GHz (=vykopávka). Pokud se databází prochází podle indexu, je rychlá - řekl bych - "normálně" - odezvy jsou prakticky neměřitelné. Pokud se neprochází podle indexu, pak projít nějakých 20000 záznamů trvá asi 1s (měřeno stopkami).

Celkově je systém svižný, dokud nedáte vypsat velké množství řádků na obrazovku - ale to není o rychlosti databáze, ale samotného GUI, které na toto - pravda - není moc stavěné. GUI zobrazuje (při tady tom mém testu) přibližně 500 řádků za sekundu, tzn. zobrazení faktury o 1000 řádcích trvá přibližně 2s. No, pokud má někdo přístup k jinému ERP, může zkusit, jak na tom je.

[OndraZX]

2 - edpexport.sh pouzivame taky, ale ja mam hlavne na mysli jednoduchy uzivatelsky export - proste rychle vytahnou nejaka data. Proste SQL je standard a napojim se odkudkoliv. Navic struktura objektove databaze je pro neznaleho uzivatele velmi "chaoticka"

3 - az na to definovani filtru - uzivatel se musi naucit doslova programovat - o zavislostech mezi tabulkami ani nemluvim

4 - ktera neni levna

6 - porad jsem omezen tim nesmyslnym kodovanim

7 - s tim souhlasim - proste uzivatel pri hledani zaznamu vetsinou ceka az mu odroluje obrazovka i pri 2 sec je to neprijemne

Kdyz to shrnu: Problemy Abasu vyplyvaji z jeho historie. Pouziva propertialni databazi z nestandardnim kodovanim - proste v dobe vzniku nic jineho nebylo. Dlouho byl klient resen pomoci textoveho rozhrani coz je videt i dnes na jednoduchosti grafickeho klienta - na druhou stranu protokol definovani formularu umoznuje velmi slusnou customizaci - formulare jsou definovany v textovem souboru. Tiskove vystupy i dnes jsou z poloviny v ciste textovem formatu - ale situace s postupne zlepsuje. Uzivatelska neprivetivost vyplyva z orientace na ciselniky - v minulosti se to nedalo resit jinak - coz v kombinaci Case sensitive filtrovanim zaznamu je pro uzivatele doslova vrazedne - je na to specialni skoleni a bezni uzivatele to stejne dodnes nechapou - filtrovani = programovani - a to nemuzeme dnes po uzivatelich chtit. Napr. najit firmu RedHat z Brna znamena v Abasu hledat vyhledavaci slovo "REDHBR" - pripadne si pamatovat cislo (v rozsirenem filtru muzete hledat Redhat, ale system vam nic nenajde protoze v databazi je RedHat - jde to snad resit nejakym programovacim prikazem). Abas neodpousti chyby - zapomenete napsat napr. cenu v polozce dodaciho listu? - radek se smaze bez upozorneni. Myslite si ze v seznamu polozek na fakture vidite soucet jejich cen? - musite pridat specialni radek !!!

Abas byl asi v minulosti skvely system, ale dnes se konkurencni systemy ovladaji uplne jinak a dodrzujou urcite standardy. Abas zustal dle maho nazoru na pocatku 90 let.

[OndraZX]

Kdyz mluvim o "programovani" - mam na mysli, ze uzivatel casto zadava ruzne promenne, ktere by jsi mel pamatovat, tak si dovolim upozornit, ze vychazeji z nemciny - takze ovladat tento jazyk je velke plus.

[Frantisek]

.. . Napr. najit firmu RedHat z Brna ..

priznam se, ze jsem to nepochopil, asi je to tim prikladem. Nechapu, v jake situaci hleda uzivatel to slovo. Je mineno, ze napr. uzivatel hleda zakaznika a neni si jist, jak se to pise spravne a tak zada 'rathet' a nyni by mu mel prijit seznam zakazniku zacinajici s 'r' a nebo s 'R'.

Tedy 'Ramy a dvere s.r.o', 'repa a jine hlizy s.r.o' 'Redhat', Roztocka prvni sporitelna' ...atd.

Jestli jsem to pochopil, tak se neobjevi zadny setrideny seznam, coz si nedovedu predstavit.

[OndraZX]

System rozlisuje mala vs. velka pismena

tzn. RedHat se nerovna Redhat - tzn. uzivatel musi znat presny nazev a to i velikosti pisma - protoze uzivatel by nic nenasel tak ma Abas vyhledavaci slova, ktera se skladaji z nazvu firmy a mista napr REDHBRN ktere jsou velkymi pismeny (logiku vytvareni vyhledavaciho slova 8 zn. jde ale asi zmenit). Coz je problem u firem ktere zacinaji "Ing. Petr Pavel z Ostravy = INGPOST" a podobne. A to nemluvim o pripadu, kdy neznate zacatek nazvu - coz u hledani firmy celkem nevadi, ale zkuste takhle najit nejakou polozku ve skladu. (zase je na to nejaky parametr). Ale jak rikal skolitel Abasu - vse je to matematicka logika.

Takze kdybych mel v Abasu tyto realne polozky:

CNMG120408M3 TP1000

CNMG120408M3 TP2000

CNMG120408M5 TP1000

CNMG120408M5 TP2000

CNMG120412M3 TP1000

CNMG120412M3 TP2000

CNMG120412M5 TP1000

CNMG120412M5 TP2000

CNMG160612M5 TP1000

CNMG160612M5 TP2000

CNMM160612M5 TP1000

CNMM160612M5 TP2000

...atd

tak jsem s vyhledavacim slovem ktere ma 8 znaku v pr....

Navic se v Abasu zadava nejen zacatek hledani, ale i konec, jinak Abas vylistuje od nalezene polozky az po konec tabulky (a to chvili trva)

Existuje ale zase nejaky "sileny" parametr ktery uzivatel zada, ktery urci, at pri hledani se nedela rozdil male/velke pismeno

To chce proste videt na "zivo" kdyby mi to nekdo vypravel taky neuverim.

[xvasek]

Problémy vyřešíme paralelně na osobní úrovni - šéf už Vám posílal mail, sem přidám jenom několik poznámek. "Doslova programování" pro filtry opravdu potřeba není, je jenom potřeba říct systému, ve kterém poli má jakou hodnotu vyhledávat, a to buď vyjmenováním seznam polí, nebo jejich vybráním ze seznamu - což mi přijde jako zcela standardní postup. Administrátor pak typicky filtry (=selekční lišty v terminologii abasu) uloží uživatelům do menu, aby je mohli opakovaně použít. Pro převody mezi kódováními použijte s3_conv. Všechny programy pracující s EDP umí kódování změnit, v EDP protokolu samotném se to mění pomocí příkazu SET|TID|CHARSET|UTF8| (ale podle ostatního soudím, že EDP nevyužíváte). Pokud jde o cenu ODBC licence, vezměte to tak, že jste na druhou stranu neplatili za databázi ani euro. Pokud Vám vadí textové rozhraní, tak jej nepoužívejte. Pokud se Vám nelíbí textové tiskové výstupy, tak je nepoužívejte - kromě inventurního seznamu tam nevidím nějaké, které by by se dnes běžně používaly. Součtový řádek do faktury se přidává automaticky. Pokud máte špatně zvolená vyhledávací slova, tak si je změňte. Vyhledávací slovo nemá 8 znaků. U vyhledávacího slova stačí napsat začátek a zmáčknout "tab" - pokud zadáte "red" - "tab", systém přímo doplní "RedHat" nebo Vám dá na výběr ze všech firem, u kterých začíná vyhledávací slovo na "RED". Že se vyhledává v rozsahu "od" - "do" je vlastnost, nikoli chyba, řekl bych, že u konkurenčních systémů na tom nebudou jinak.

Ano, Vaše verze je case-sensitive na polích, které jsou case-sensitive. Uznávám, že uživatelé tuto vlastnost nevnímají příliš kladně (eufemicky řečeno :). V pozdější verzi jde case-senzitivita pro hledání nastavit.

Věřím Vám, že se Vám v systému nepracuje dobře - pokud bych s ním měl pracovat způsobem, který z Vašich textů prosakuje, určitě bych taky nebyl dvakrát nadšený. Pokud například hledáte díl způsobem, že zadáte "rozsah od C" a necháte systém, aby Vám vypsal všech zbývajících 20000 dílů (což trvá asi půl minuty), plně chápu, že označíte databázi (která za to chudák vůbec nemůže) za "velmi pomalou". Pokud jste přesvědčený, že systém komunikuje jenom v kódování "eks", určitě je legitimní použít slova jako "nekompatibilní" a "zastaralý". Uznávám, že pokud si uživatelé mají tvořit sami opakovaně selekční lišty, dostanou se do stavu, kdy systém označí za složitý. Nicméně to jsou všechno věci, které jdou jednoduše řešit konzultacemi a doškolením.

Trochu mě mrzí, že se tyto Vaše problémy dozvídáme přes diskusi tady a ne nějakým kanálem, kterým se zpravidla problémy / požadavky dodavateli oznamují - tedy telefonem, emailem, požadavkem na helpdesku... Ale aspoň už vím, jaký pocit má vývojář, když na jeho produkt lidi nadávají v diskusi a bugzilla je prázdná.

[OndraZX]

Mate pravdu, nema cenu to tady resit, at si kazdy prebere sam jestli mu Abas vyhovuje, nebo ne. Snad i z teto diskuze si nekdo udela na nej nazor a zameri se na zde uvedene mozne problemy.

Nicméně to jsou všechno věci, které jdou jednoduše řešit konzultacemi a doškolením.

To jste presne vystihl - uzivatel se potrebuje Abas opravdu naucit - ale dle meho nazoru se aplikace s dnesni dobe chovaji jinym zpusobem - jsou proste uzivatelsky mnohem privetivejsi - a to skolenim nezmenim

[Frantisek]

dovolte nekolik poznamek:

- to, ze jste zde oslovil nekolik problemu povazuji za mnohem dulezitejsi, nez kdyz zde 'zastanci' produktu (jejichz nazory jsou samozrejme take prinosne) produkt prezentuji veskrze pozitivne. Pro nas vyvojare jsou Vase nazory eminentne dulezite a kazdemu je snad jasne, ze to nelze popsat v bugzille. (konkretni problemy jiste, ale jakasi podvedoma 'nespokojenost' tam nepatri, to patri jednoznacne sem). Za to Vam jiste jmenem vsech zainteresovanych mohu jen podekovat.

- ta veta, ze jste byl jiz 'sefem kontaktovan pres mail' me dost sokovala. Ujistuje me to v tom, jak dulezita je anonymita na netu, nedovedu si predstavit, ze bych rekl nejaky nazor a pak bych byl obtezovan nejakymi maily, jestlize je nechci. (jestlize jste si tu komunikaci pral, tak pak je to neco jineho, ja jsem to nepostrehl).

- nyni k te veci, jak se dnes aplikace chovaji. Priznam se, ze jsem to jeste zcela nepochopil, ale i podle odpovedi autora clanku je jasne, ze je v systemu jakasi filozofie, kterou vy povazujete za prekonanou. To jsou osemetne veci, zejmena tehdy, kdyz se to dovi clovek pozdeji a ma platit dodatecne za skoleni. To je jedna stranka veci. Jina vec by byla, jestlize by po tom skoleni mohli uzivatele pracovat efektivneji.

Ale v zadnem pripade si nemyslim, ze resenim je, ' at si udela kazdy nazor'. To by byla odpoved politiku. Nasi snahou musi byt problem popsat, zaradit do nejake kategorie a snazit se definovat vseobecna kriteria, podle kterych by se mohli vyvojari ridit. Aby jste nemusel pouzivat takova slovni spojeni 'proste uzivatelsky mnohem privetivejsi'.

[xvasek]

Abych uvedl na pravou míru záležitost s e-mailem, ten šel od mého šéfa (dodavatele) zákazníkovi (odběrateli) a obsahoval nabídku pomoci se systémem. My si tady ten feedback (i touto netradiční formou) bereme k srdci a snažíme se situaci řešit.

Jestli je filosofie objektové databáze překonaná, je otázka druhá. Technologicky je objektová databáze mladší, ale osobně bych za překonanou nepovažoval ani jednu koncepci. Jako vývojář jsem přechod na objektovou databázi z původní SQL velmi ocenil (3 roky jsem aktivně pracoval s Helios Green) - všechno je prostě rychleji hotové a je v tom méně chyb a řešení je výkonnější (uživatel míň čeká). Na druhou stranu je pravda, že některé věci se dělají hůř, ale na srovnání bych se chtěl podívat v příštím článku.

[Slavo]

Pocatky 90 let dominuji ERP systemy typu JBA,BRAIN,MAPICS - tedy RPG atd - to snad nemyslite vazne, muzu se zeptat s kterym z nich jste delal?

[Frantisek]

... O tom se da hodiny diskutovat a neprinese to nic ...

Fakt je, ze od zacatku 90 let je trh v zapadni Evrope (ktery jste vlastne myslel vy?) ovladan 150 !! vyrobci software (viz kazdorocni zpravy o stavu PPS - prof. Geitner, Kassel), kteri si rikaji (pozdeji) take ERP. Jsou mezi nimi i ta jmena, ktera jste uvedl, ale urcite ne v segmentu, ze ktereho prichazi kolega, ktery si zde stezoval. Jemu je take treba samozrejme vycist, ze hovori obecne o ERP, aniz by prinejmensim zhruba objasnil, co si pod tim pojmem v 90. letech predstavuje. Mam dokonce pocit, ze pojem ERP vznikl pozdeji.

[xvasek]

Databáze interně funguje v "eks" kódování, ale externě jde komunikovat mimo jiné pomocí UTF-8, plus spousta dalších, je to jenom o nastavení. Bodům s nekompatibilitou moc nerozumím - nekompatibilita s čím? Co se týká lokalizace - používáte slovníky od abas AG, nebo amotIQu?

[OndraZX]

Databáze interně funguje v "eks" kódování, ale externě jde komunikovat mimo jiné pomocí UTF-8, plus spousta dalších, je to jenom o nastavení

Nejen datatabaze, masky, FOPy, ale i administratorska (root) konzole (v dobe minule i textovy klient) bezi v tomto kodovani - resi se to "berlickou" pomoci Putty s doplnenym "eks" kodovanim, pokud se neco zmenilo rad se poucim.

Bodům s nekompatibilitou moc nerozumím - nekompatibilita s čím?

Potrebuji vytahovat automaticky data z databaze - krome predrazeneho ODBC rozhrani nic jineho nenabizite. V dnesni dobe takove systemy bezi logicky na SQL standardu.

Co se týká lokalizace - používáte slovníky od abas AG, nebo amotIQu?

Amotiq - my jsme treba resili "Artikl" vs. "Zbozi" - v jednom dialogu byl prvni vyraz v jinem druhy. Je pravda ze mame customizace, kde se to vice projevuje.

[Slavo]

To zni jak starsi implementace nikym nepodporovana. abas bezne nahrazuje zhavarovane SAP implementace, nedostatek kompatibility - to je asi pokus o vtip, kolem abasu mame 6 externich systemu cez BI,CAQ, Teamcenter - a nevsimnul jsem si ze je problem kompatibility. abas mam v nasazeni od 2005 a o textovom rezime nic nevim, musim ric ze ve srovnani s Infor, SAP nebo Baan je to nadhera. Lokalizace je u nas kompletni. Mzdy mame vlastni a menit jsme nechteli. Reference k nedostatku v prekladu signalizuje ze se jedna asi o starsi implementaci, mozna i bez udrzby..

[OndraZX]

To zni jak starsi implementace nikym nepodporovana.

Implementovano v roce 2008 Amotiqem - tedy "cerstva" instalace

[OndraZX]

2007 - omlouvam se, ostry provoz od 2008

Ale je pravda ze slo o trochu nestandardni instalaci ve spolupraci s zahranicnim partnerem nasi materske firmy

[qwas]

Máte někdo zkušenosti s nějakým opensourcovým EPR řešením které by šlo nasadit v české firmě? Těchhle systémů je totiž stašná spousta a ne všechny asi budou kvalitní, tak nevím jaké vybrat do užšího okruhu na testování, díky všem

[OndraZX]

Mym favoritem je OpenERP, ale bez podpory na CZ trhu do toho rizika asi nikdo nepujde.

V posledni dobe se tlaci nahoru Openbravo, ale vadi mi ze je to jen "webovka"

A klasicke Compiere ma i CZ zastoupeni Synesis Technologies

[sparrowhawk]

zkusenosti s tim nemam, ale neda mi to nezminit ERP5

moznost stahnout Mandriva balicky - menu Community

[sparrowhawk]

ha, jsou tam i deb balicky + source code :)