Využití jazyka XML pro tvorbu dokumentů v IS Microsoft Dynamic NAV

Bankovní institut vysoká škola Praha Katedra informačních technologií a elektronického obchodování

Využití jazyka XML pro tvorbu dokumentů v IS Microsoft Dynamic NAV Bakalářská práce

Autor:

Petra Blahoušková, DiS. informační technologie, manažer projektů

Vedoucí práce:

Praha

Ing. Vladimír Šamal

červenec 2009

Prohlášení:

Prohlašuji, že jsem bakalářskou práci zpracovala samostatně a s použitím uvedené literatury.

Ve Velešíně dne 01. 07. 2009

Děkuji panu Ing. Vladimíru Šamalovi za odborné vedení mé práce, za rady a čas, který mi během vypracovávání této práce věnoval.

Anotace práce: V této práci si popíšeme vznik značkovacího jazyka XML. Rozebereme si možnost generování XML souborů dle uživatelsky vytvářených definic uložených v šablonách. Soubory XML nám poslouží jako datový zdroj pro tiskové sestavy, které si vytváří uživatel. Navrhneme si XML šablonu a popíšeme si postup definice. Dále se seznámíme s aplikací Microsoft Office InfoPath 2007 a popíšeme její možnosti a funkce. V závěru vytvoříme propojení XML šablon s SQL serverem pomocí webových služeb a otevírání XML šablony z webové stránky.

Annotation: The origin of the XML mark up language will be described in this work. We will analyse the possibility of generating XML files based on user definitions which are allocated in templates. XML files are used as a data source for printing formation created by a user. We will project an XML template and describe the definition procedure. Next we will mention the application Microsoft Office InfoPath2007 and describe its possibilities and functions. In the end we will create an interconnection of XML templates with an SQL Server using web services and opening an XML template from a web page.

Obsah Úvod ...................................................................................................................................... 6 1.

Historie informačních systémů a jejich význam v průběhu vývoje ............................... 7

2.

Ukládání dat a těžení informací z datových úložišť ..................................................... 12 1.

Úložiště dat a způsob přístupu k nim ....................................................................... 12

2.

Získávání informací a jejich formy .......................................................................... 16

3.

Definice datové struktury přenášených dat .................................................................. 17 1.

XML jazyk................................................................................................................ 17

2.

XML šablona ............................................................................................................ 20

3.

Záložka XML šablony „Obecné“ ............................................................................. 21

4.

Záložka XML šablony „Definice“ ............................................................................ 23

5.

XML definice-relace................................................................................................. 25

6.

Poznámky XML ....................................................................................................... 26

7.

Export do XML ........................................................................................................ 27

8.

Proměnné XML definice .......................................................................................... 28

4.

Popis tvorby datového modelu pro plnění datové struktury ........................................ 29 1.

Tvorba vlastní XML šablony.................................................................................... 29

5.

Principy práce s datovým modelem a možnosti tvorby dat ......................................... 33

6.

Použití XML dat pro zpracování programem Microsoft Office InfoPath .................... 34

7.

Výsledky a doporučení ................................................................................................. 45 1.

Rozvoj publikačních šablon v rámci Microsoft Dynamic NAV .............................. 45

2.

Využití dat pro synchronizaci ................................................................................... 46

Závěr .................................................................................................................................... 48 Literatura ............................................................................................................................. 49

5

Úvod Bakalářská práce se zabývá řešením zvýšeného počtu výskytů požadavků na zobrazení, tisk či export dat ve výrobní firmě s využitím XML jazyka. XML jazyk je jednoduchý prostředek pro export modifikovaných dat ze základních dat pořízených či generovaných v aplikaci Microsoft Dynamic NAV, kdy je možno využívat standardních nástrojů společnosti Microsoft. Společnost Microsoft byla založena roku 1975 Billem Gatesem. V současné době je nejvýznamnější firmou na počítačovém trhu. V roce 1980 firma Microsoft uzavřela smlouvu s IBM a pro Microsoft to znamenal strmý růst nahoru. Oproti tomu firma IBM sestoupila z nejvýsadnějšího postavení o několik pozic směrem dolů. IBM totiž koupila licenci na operační systém od firmy Microsoft pro teprve vznikající počítač IBM PC a ve formulaci podmínek si nevyhradila výhradní práva. Díky těmto podmínkám smlouvy Microsoft dodnes poskytuje operační systém i jiným výrobcům PC, který je kompatibilní s originálem od IBM. Microsoft vede světovému trhu s výpočetní technikou a dodává operační systém jednotlivým výrobcům PC, kteří spolu svádějí tvrdý boj. Novinkou prorazil systém Windows, který byl originálně vytvořen firmou Microsoft jako grafická nadstavba nad operačním systémem MS-DOS. Nejdůležitějším a nejhlavnějším cílem tohoto systému bylo umožnit uživateli mnohem příjemnější obsluhu počítače. Uživatelé jej začali ale používat až v roce 1995 a to pod jménem operačního systému „Windows95“. Microsoft tento operační systém i nadále vyvíjel a tak postupem let vznikl „Windows98“, Windows Millenium“, „Windows XP“ až nejnovější verze nese název „Windows Vista“. Pro Windows operační systémy jsou vyvinuty desetitisíce aplikačních programů a to od nejrůznějších dodavatelů. I firma Microsoft dodává kancelářské balíky, výkonné databáze či jiné programy. Toto vedlo k obvinění, že firma Microsoft zneužívá monopolního postavení na trhu. Úspěchem firmy Microsoft je prodej operačního systému, který firmu vynesl do role dodavatele, jemuž patří nejméně 80% trhu operačních systémů. Tato firma je firmou, která má velice razantní obchodní taktiku, a která bere konkurenční boj vážně. Někteří odpůrci firmy Microsoft říkají, že firma konkurenční boj povýšila na ideologii.

6

1. Historie informačních systémů a jejich význam v průběhu vývoje Informační systém je obecně vzato způsob, jakým jsou ve firmě evidovány, zpracovávány a poskytovány informace. Vzhledem k tomu, že tyto úkony jsou dnes prakticky bez výjimky prováděny pomocí výpočetní techniky, potažmo programů na ní běžící, můžeme říci, že informační systém, je označení pro software, který slouží pro účely chodu firmy. Ve firmě, kde sbírám podklady pro tuto bakalářskou práci je základem informačního systému systém Microsoft Dynamic NAV verze 4.3, jehož vývoj měl následující historii. Roku 1984 vznikla v Dánsku společnost PC&C ApS (Personal Computing and Consulting). V roce 2002 se Navision Software A/S sloučila s dánskou společností založenou roku 1983 jménem Damgaard A/S a společně vytvořili firmu s názvem NavisionDamgaard A/S. Později bylo jméno změněno na Navision A/S. 11. července roku 2002 koupil Microsoft společnost Navision A/S a vznikla tak nová divize Microsoft Business Solution, která již zahrnovala produkt Microsoft CRM. V září roku 2005 Microsoft změnil značku produktu a oznámil uvedení na trh Microsoft Dynamic NAV. Samotný produkt prošel několika změnami, kdy se postupně jmenoval „Navision Financials“, „Navision Attain“, „Microsoft Business Solution Navision Edition“ a naposledy „Microsoft Dynamic NAV“. Implementaci ERP systémů na bázi Microsoft Navision poskytuje několik firem v České republice. Mezi nejvýznamnější tyto firmy patří AutoCont, AXIOM SW, CDL SYSTEM, Infinity nebo NESS Logos. ERP systém neboli Enterprise Resource Planning je informační systém, který musí být schopen zajistit procesy podniku a další individuální požadavky uživatelů. Nejvíce využívaný je pro oblasti logistiky, výroby, financí nebo distribuci. Pro výběr informačního systému předchází důkladné prověření ze strany dodavatele ERP systému. To zde hraje důležitou roli pro vybrání vhodné verze ERP systému a jeho další případné úpravy. Jednotliví dodavatelé těchto informační systémů na základě svých zkušeností vytvořili různé upravené verze svých systémů. Takovéto upravené systémy se označují za branžové nebo také vertikální řešení. Dodavatelé většinou slibují svým zákazníkům všelijaké úpravy systému, ale ve velkém počtu se zákazník přizpůsobí dané nainstalované verzi. Jelikož je ERP systém založen na automatizaci procesů, je nutné, aby firma měla své procesy vyřešené. Poté bude mít implementace tohoto informačního systému pro firmu přínos. 7

U informačního systému ERP nejde o pouhou instalaci. Základem každé takovéto instalace je následná parametrizace systému. Je potřeba velkého úsilí a hlavně vzájemné spolupráce dodavatele a firmy se zaměstnanci. Implementace ERP systému je důležitý a nákladný krok. Cílem je popis dosavadních ekonomických procesů a ty nadefinovat do ERP systému tak, aby provoz procesů byl efektivní, rychlý, jednoduchý a provázaný s procesy, na kterých je závislý. Implementace systému začíná definicí ekonomických procesů, naprogramováním, případně úpravou stávajícího kódu, dále pak testováním a na posledním místě je přenos do produkčního prostředí. V praxi bývají instalovány tři totožné systémy. Vývojový, testovací a produkční systém. Ve vývojovém systému pracují programátoři a v případě, že mají hotový kód, přenášejí ho do dalšího systému. Testovací neboli konsolidační systém obsahuje kopii produktivních dat. Testuje kód vytvořený právě ve vývojovém systému. V případě, kdy konzultanti zjišťují, zdali kód pracuje správně, provede se obnovení produktivního systému do testovacího. V produkčním systému je již ostrá verze systému s produkčními daty. V prostředí tohoto systému pracují koncoví uživatelé. Pokud je systém správně implementován, přináší všem mnoho výhod. Hlavní výhodou jsou centralizovaná data, snížení chybovosti, zvýšení bezpečnosti a rychlejší výstupy pro vedení firmy. Ve finále nejvíce ohodnocenými vlastnostmi se stává flexibilita a díky tomu i konkurenceschopnost. ERP systémy mají dva základní modely dodání. Prvním modelem je takzvaný OnPremise model. Což je aplikace nainstalovaná na serverech organizace, která vlastní ERP systém. Organizace, která vlastní ERP systém tak musí mít vnitřní zdroje na provoz a údržbu systému. Aktualizace a upgrady si zajišťuje firma sama spolu s dodavatelem. Toto je nejběžnější model provozování ERP systémů. Druhým modelem ERP systémů je OnDemand model. Tento model je také znám pod pojmem ASP model (Application service provider) nebo SaaS (Software as a Service). Hlavním rysem je, že ERP systém je poskytován vzdáleně přes Internet. To pro firmu, která má tento ERP systém zaveden, znamená, že o veškeré aktualizace a upgrady se stará dodavatel. ERP systémy jsou tak provozovány na serverech dodavatele. Zde je riziko bezpečnosti a spolehlivosti služby. Toto riziko je ale diskutabilní, jelikož dodavatel vlastní velká datová úložiště a disponuje s velkými prostory. Jak z hlediska antivirové bezpečnosti, tak z hlediska nákladů a výnosů. Umožňují tak minimalizovat náklady na zabezpečení. Zde bychom si mohli povídat i o outsourcingu neboli ASP. ASP je Application Service Providing, což je forma outsourcingu informačních technologií. To znamená, že více uživatelů využívá na dálku 8

aplikaci telekomunikačních technologií tohoto ASP poskytovatele. Po dobu co tuto službu uživatel používá, platí smluvní poplatky v pravidelných časových intervalech dle míry užívání aplikace. Poskytovatel garantuje správné fungování aplikace, její údržbu a další vývoj a rozvoj. Uživatel k této aplikaci, kterou si platí, přistupuje zpravidla pomocí webového rozhraní. Další výhodou pro uživatele je, že nemusí platit žádné počáteční náklady na vývoj či nákup aplikace, ke které se může připojit odkudkoliv. Významnými výrobci ERP systémů jsou SAP, Lawson, Oracle Applications nebo Microsoft. Na počátku všeho byl ale COBOL. Počátek éry najdeme v šedesátých letech minulého století, kdy organizace vyvíjely a provozovaly centralizované počítačové systémy automatizující nejnáročnější úlohy spojené s chodem podniku. Tyto systémy byly v tu dobu naprogramované v jazycích jako FORTAN, COBOL nebo ALGOL. V sedmdesátých letech byly vyvinuty systémy, které řeší materiálové plánování výroby neboli MRP (Material Requirements Planning). Od počátku osmdesátých let se v podnicích začaly implementovat systémy, které sloužily pro řízení a optimalizaci dodávek materiálu a výroby neboli MRP II (Manufacturing Resource Planning). První ERP systémy vznikaly na konci osmdesátých a začátku devadesátých let, kdy pokryly větší část o fungování podniku. Aplikovaly do sebe takové úlohy, které byly dříve vykonávány lidmi a vedly tak k integraci podnikových procesů. Jejich zavádění však někdy nutilo firmy k úpravě stávajících procesů, tak aby byly použitelné na jednotlivé moduly pro dané odvětví. Současné ERP systémy soutěží o přízeň zákazníků, že nabízejí co nejvíce funkcí a možností pro dané moduly a vytvářejí také specifická řešení pro různé odvětví firem. Tím dochází k tomu, že mají navrch dodavatelé robustnějších řešení, která jsou snadno upravitelná dle požadavků zákazníka. Mezi hlavní výhody ERP systémů proto patří dostupnost přesných a konzistentních dat, které podnik produkuje, omezení duplicit při práci s daty, se kterými pracují všichni uživatelé, automatizace procesů, které jsou méně časově náročná a mají větší efektivitu práce a v neposlední řadě i propojení dodavatelů a odběratelů na systémové úrovni. Nevýhodou ERP systémů je drahé pořízení, náklady na správu a údržbu, rozšiřování či školení uživatelů. Velkým přínosem pro dodavatele ERP systému se tak stává závislost dané firmy, jelikož není snadné ukončit takovýto vztah dodavatele s odběratelem. Ukončení tohoto vztahu by vedlo ke zvyšování nákladů. ERP systémy v České republice jsou implementovány do firem tak často, že nyní jsme srovnali krok s vyspělým světem. V posledních letech se ERP systémy začaly také implementovat do sfér státní a veřejné správy. Databáze jsou většinou schopny pojmout 9

pouze data, která jsou ve formátu tabulek, jelikož se dají snadno zpracovávat. Z tohoto je víceméně jasné, že s délkou doby provozu ERP systému poroste i velikost databáze. To sebou nese i negativní vliv na provoz. A proto druhou oblastí, kterou firmy ve spojení s ERP systémy řeší, je omezení nárůstu databází formou archivace. ERP systémy jsou pro mnoho firem a podniků klíčové. Zatímco systémy MRP řešily problémy spojené s plánováním a řízením nákupu materiálu. Používané metody pro řízení materiálu postavené na sledování historie spotřeby, byly nahrazeny závislým objednáváním materiálu na základě skutečné objednávky nebo prognózy od zákazníka. MRP počítá s požadavky na materiál zpětně v čase od termínu dodání objednávky nebo prognózy od zákazníka. Do této kalkulace zahrnuje i veškeré známé údaje jako jsou technologické postupy výroby a stavy skladů. Bohužel do této kalkulace se započítávaly i údaje, které nebyly vždy správné. K těmto údajům patří informace, jakože materiál je neomezeně dostupný nebo že průběžný čas výroby daného produktu je dán a je stále stejný aniž by bral v úvahu velikost výrobní dávky. MRP systémy procházely dalším vývojem a vylepšováním až vznikla smyčka MRP (Closed Loop MRP) umožňující efektivnější práci s vytvořeným plánem. Na počátku osmdesátých let se vývoj posunul tak dopředu, že světlo světa spatřil systém MRP II, který umožňoval nejen plánování nákupu materiálu, ale i práci s výrobními kapacitami. Jako dnešní ERP systémy, systém MRP II byl vytvořen pro centralizovanou databázi. Microsoft Dynamic NAV je aplikace, která pomáhá automatizovat, integrovat a lépe řídit jednotlivé firemní procesy v různých oblastech. Mezi tyto oblasti patří například finance, výroba, řízení projektů, distribuce, správa zákaznických vztahů a e-commerce. Vzhledem ke komplexnosti této aplikace a přizpůsobitelnosti je ideálním řešením, které nabízí rostoucí společnosti rychlou reakci na tržní příležitosti, růst konkurenceschopnosti a zvyšování produktivity zaměstnanců. Tato aplikace dovoluje svému majiteli stávající systém nahradit jedním, plně integrovaným řešením, které propojuje každého zaměstnance se zákazníkem nebo dodavatelem či partnery. Toto je hlavní důvod proč společnosti využívají právě tuto aplikaci ve více než 30 zemích světa. Tato aplikace má nástroj pro řízení vztahů se zákazníky a tím pomáhá získat kompletní jasný obraz, který firma potřebuje, aby identifikovala, získala a dále pak udržela své zákazníky. Microsoft Dynamic NAV vytváří vysoce produktivní prostředí pro zaměstnance společnosti pomocí osobních portálů, které uživatelé mohou používat pro rychlý přístup k informacím, které potřebují v danou chvíli maximálně využít. Velikou výhodou této aplikace je i jednoduchá možnost 10

změny jazykové mutace, kterou zajisté ocení společnosti podnikající na globálním trhu. Je zcela jasné, že výběr správného systému řízení podniku balancuje mezi krátkodobými a dlouhodobými cíli společnosti a finančními zdroji. Microsoft Dynamic NAV je speciálně vyvinutá aplikace pro střední a velké společnosti, které hledají takové řešení, které jim pomůže zefektivnit produktivitu bez narušení denní rutiny. Microsoft Dynamic NAV pomáhá sedmi způsoby ulehčit každodenní práci zaměstnancům společnosti. Ulehčuje práci denním přehledem jak řídit a rozvíjet podnikání tím, že ukazuje data o výkonnosti společnosti, analytické sestavy, prodejní a nákupní rozpočty nebo webová rozhraní. Pomáhá zobrazit data různými způsoby, podle toho co je pro společnost relevantní. Aplikace se zaměřuje na kritická místa podnikání pomocí detailní viditelnosti každé transakce nebo jednoduchými sestavami pro lepší analýzy. Aplikace má i lví podíl na odstranění a vylepšení pracovní náplně v oblasti financí, kde se například zákazník může vybrat způsob, jakým bude platit v případě cizí měny. Mezi další způsob, již čtvrtý, patří i zvýšení výkonnosti zaměstnanců tím, že si mohou personalizovat své vlastní menu. Aplikace předchází obchodním problémům tím, že nás varuje či oznamuje kritické problémy pomocí automaticky generovaných e-mailů. V předposledním případě ulehčení se jedná o práci a její růst způsobem jakým je požadován. Posledním způsobem je práce ve známém prostředí. Známým prostředím se myslí společnost Microsoft. Zajisté v každé firmě či společnosti najdeme kancelářský balík jménem Microsoft Office. Společnost Microsoft má licenční podmínky pro tuto aplikaci platné od roku 2006 a jejich pořízení je možné dvěma způsoby. První způsob je standardní nákup licence a druhým způsobem je pronájem licence. Pronájem licence Microsoft Dynamic NAV formou SaaS je nejmodernějším a nejnovějším způsobem pořízení licence. Výhodou je to, že společnost platí pouze ty licence, které skutečně potřebuje. Dostupné licenční moduly SaaS jsou licence, které jsou poskytnuté v rámci měsíčního pronájmu, nikoli však trvalého a lze je využívat pouze po dobu uzavření smlouvy. Existují dva typy licencí SaaS. První je Per Subscriber a druhá je Per Processor. První typ licence je nutný pro jedinečného uživatele či zařízení, který má právo přistupovat ke zvoleným produktům nebo je nějak využívat. V této variantě společnost nepotřebuje samostatnou serverovou licenci. Příkladem produktů v této licenci jsou Microsoft Dynamics, Microsoft Windows Server, SQL Server, Exchange Server, SharePoint Server nebo Office. Zatímco v druhém typu licence SaaS se jedná

o přístup

pro

každou

procesorovou

jednotku,

která

umožňuje

k nainstalovanému softwaru na daném procesoru neomezenému počtu uživatelů. 11

přístup

2. Ukládání dat a těžení informací z datových úložišť 1. Úložiště dat a způsob přístupu k nim Původně byla data ukládána na magnetických nosičích, jako jsou datové pásky. Počítače z té doby ještě nedisponovaly vysokým výkonem a takovou operační pamětí, aby mohly zpracovávat objemná data. Tudíž při zpracování byla veškerá data vždy obnovována z těchto nosičů. Velkou nevýhodou byl přenos těchto dat a jejich následné uložení. Další formou ukládání dat byly takzvané pevné disky neboli hard-disky, které umožňovaly daleko efektivnější a rychlejší přístup k datům. Tyto nosiče se v obměněné formě využívají dodnes. V současné době, se ale oproti původním diskům změnila strategie k datům uloženým na těchto discích. A hlavně se začaly sdružovat do diskových polí, proto při vhodně zvolené strategii přístupu, umožní eliminovat i případné výpadky některých elementů z diskového pole. Zde bychom mohli zmínit pojem RAID. RAID je forma ukládání dat, kdy máme několik disků, většinou dva, na které se data ukládají současně. To sebou nese výhodu dvojího zapisování dat na samostatné jednotky a v případě poruchy, převezme druhý disk plnou funkci a po opravení prvního disku proběhne automatická synchronizace. Tím se opět dostáváme do bodu, kdy je vše v pořádku a ukládání dat probíhá znovu do obou disků naráz. Samozřejmě, že jako každá funkcionalita, má i tato forma nevýhody. Jednou z nevýhod je dvojnásobná kapacita. U diskových polí jsou data rozložena tak, že stačí cca třetinový nárůst kapacity a navíc umožňuje opravu diskového pole bez nutnosti odstávky, což je výměna jednoho disku v rámci diskového pole. Nesmíme opomenout ani ukládání dat do textových souborů. Jejich výhodou byla jednoduchost a čitelnost. Nevýhodou ovšem bylo, že jednak veškerou režii správy zajišťovali aplikace, jednak velice problematické zabezpečení takovýchto souborů. Vývoj dospěl k relačním databázím, kde jsou data ukládána do tabulek. Mezi těmito tabulkami jsou definovány vazby pomocí primárního klíče. Nad těmito tabulkami je vystavěná funkcionalita, která umožňuje řídit přístup k datům, dále umožňuje efektivní uložení a správu dat s možností částečné archivace a tím zmenšení nároků na prostor pro jejich uložení. V neposlední řadě bychom měli ještě zmínit ochranu dat zabezpečenou pomocí nástrojů pro správu přístupu k datům. Jediné, co lze těmto databázím vytknout je platformová nekompatibilita. Například Microsoft SQL Server nekomunikuje se Serverem Oracle. Pro těžení z nekonzistentních dat byly vyvinuty aplikační nástroje, které umožní 12

přístup k datům. Mezi takovýto nástroj patří i například ODBC. Zkratka anglického názvu Open DataBase Connectivity označuje rozhraní, které poskytuje standardní aplikační přístup k datům. Zavedení ODBC se ukázalo velice vhodným a potřebným nástrojem pro programátory, ale i pro vývojáře systémů pro řízení báze dat. Struktura ODBC se dá posadit do čtyř vrstev. První je samotná aplikace, druhou je takzvaný správce ovladačů a do třetí vrstvy patří ovladače. Čtvrtou poslední vrstvou je SŘBD (Systém Řízení Báze Dat), který zpracuje operace ovladačem a výsledky této operace vrací. Nevýhodou je, že musí být napsáno pro každé úložiště. Pro sdílení dat mezi těmito daty byla vyvinuta speciální XML prostředí. V prvopočátku byly data zpracovávaná na sálových počítačích, takzvaných mainframech. Jelikož byly založeny na primitivních součástkách, byly jejich rozměry obrovské a vyžadovaly speciální haly, sály s velkým elektrickým příkonem a klimatizací. Výpočetní výkon takovýchto počítačů byl nízký a zpracovávané aplikace a potřebná data byly uchovávány na děrných štítcích. Jistý pokrok pak znamenaly výše zmíněné pevné disky a přístup pomocí terminálů. V osmdesátých letech se začaly ve větší míře šířit personal computer alias PC. Postupem času byly propojovány pomocí sítí a sdílely datové zdroje a výkony. Využívaly se dva typy propojení. Kruh a hvězda. Každý uživatel je připojen na dalšího uživatele a tak tvoří kruh. Topologie kruh je méně efektivní než topologie hvězda, je to díky tomu, že data musí projít všemi uzly, než se dostanou k cíli. Další nevýhodou kruhové topologie je i to, že pokud zkolabuje jeden uzel, zkolabují i ostatní uzly a tím celá síť. Abychom zde neuváděli pouze nevýhody, řekneme si i pár výhod. Výhodou kruhové topologie je mezi hlavními body relativně jednoduchý přenos, jelikož přenos paketů je pouze v jednom směru. Další výhodou je i to, že náklady na tuto topologii jsou mnohem menší než u hvězdicové topologie.

Hvězdicová

topologie,

viz

Obr.

č.

1

(Hvězdicová

topologie)

Zdroj:http://cs.wikipedia.org/wiki/Hv%C4%9Bzdicov%C3%A1_topologie, označuje síť, která svým tvarem připomíná hvězdu. Tento způsob je nejběžnějším způsobem zapojení počítačů do počítačové sítě. Každý počítač je připojený na centrálním bodu pomocí kabelu. Mezi uživateli existuje vždy jen jedna cesta. Pokud jednomu uživateli selže počítač, ostatní stále fungují. Mohou i nadále vysílat a přijímat pakety. Tudíž mezi nimi nedochází ke kolizím a počítače mohou samostatně přenášet data. Velikou výhodou je, že závady a kolize se dají snadno identifikovat. Velikou nevýhodou této topologie jsou metry

13

použitých kabelů, jelikož ke každému počítači vede jeden kabel. V neposlední řadě je to i selhání centrálního počítače, kdy pak přestane fungovat celá síť.

Obrázek 1 (Hvězdicová topologie) Zdroj:http://cs.wikipedia.org/wiki/Hv%C4%9Bzdicov%C3%A1_topologie

Jistý přelom pro přenos dat v aplikacích přichází s doplněním podpory takzvaného tenkého klienta,

viz

Obr.

č.

2

Zdroj:http://en.wikipedia.org/wiki/Thin_client.

(Zapojení Což

je

koncové

tenkého zařízení

klienta) nazývané

„bezdisková stanice“. Znamená to tedy přístup přes velice jednoduché počítače nebo terminálové služby, obdoba terminálů u zmíněných mainframů. To má tu výhodu především v tom, že nejenom veškerá data jsou uložena na centrálním serveru, ale i aplikační logika probíhá v centru a následně jsou přenášeny pouze opisy obrazovek. Takže kromě vstupu z myši, klávesnice a obrazovky klienta se žádná data nepřenášejí. Server přijímá a zpracovává veškeré stisknutí kláves a kliknutí myši od připojeného klienta, směřuje výstup z obrazovky k příslušnému klientovy. Klientská zařízení mají tedy okamžitý přístup přes server, aniž by musela být nainstalována aplikace. Bezdiskové stanice mají nainstalován pouze software uživatelského rozhraní. Jelikož bezdiskové stanice nejsou mnohdy zatíženy, mají menší velikost, energickou náročnost i cenu nákupu a provozu. Veškeré aplikace jsou spuštěny na serveru a slouží pro ukládání dat. Vytížením několika serverů a odlehčením mnoha tenkých klientů získáme zjednodušené správy systému, dále pak snížení nákladů a v neposlední řadě lépe využijeme výhody sítě. Tyto terminály tenkých klientů byly dříve nazývány jako grafické terminály, protože jejich vývoj plynul z textových terminálů, které byly před nimi. Textové terminály jsou v jádru také tenkými klienty, ale již se jim tak neříká, protože byly vyvinuty z jiné výpočetní doby. Nevýhodou tenkých klientů je problém s využitím lokálních zařízení. Je nutné mít kvalitní síť mezi tenkým klientem a serverem. Přitom musí být splněná podmínka perfektně fungujícího serveru, protože pokud bude výpadek sítě, bude veškerá práce přerušena. Funkci tenkého klienta snadno může zastat i tlustý klient. Tlustý klient klade větší 14

softwarové i hardwarové nároky na klienta, což je vlastně úplně naopak od tenkého klienta. Dále je také znám hybridní klient, což je terminál, který je směsicí obou již zmíněných klientů. Tento hybridní klient zpracovává některé operace sám, ale na některé musí využívat služby serveru.

Obrázek 2 (Zapojení tenkého klienta) Zdroj:http://en.wikipedia.org/wiki/Thin_client

Systémy Klient-Server používají samostatnou paměť, vlastní procesor, ale mají také přístup na lokální disky. Aplikace je oddělena na jiném počítači než server. Aplikace komunikuje s databází pomocí datových protokolů. Počítač, na kterém běží aplikace a umožňuje uživateli zobrazovat aplikaci pomocí uživatelského rozhraní, se označuje jako Klient. Počítač, kde běží databáze, se nazývá Server. Když tedy chceme z klientského počítače komunikovat se serverem, pak se dotaz s dotazem zašle do serveru, dále se předá dotaz do databázového programu, který jej předá do databázového serveru. Odtud se odpověď na dotaz pošle zpět do databázového programu a ten zobrazí výsledek pomocí uživatelského rozhraní. Nejběžnějším příkladem klientské architektury jsou webové prohlížeče. Opakem Klient-Server architektury je architektura Klient-Klient. V této architektuře spolu komunikují sami klienti. Tato architektura nezná pojem Server, jelikož jej vůbec nevyužívá. V této struktuře jsou klienti zároveň i serverem pro jiného klienta v síti. Hlavní výhodou této architektury je, že s větším počtem klientů roste i přenosová kapacita sítě. Postupem času se ale architektury vyvíjely a vznikla tak vícevrstvá architektura. Z vrstvy se tak stala dvouvrstvá architektura a nově přibyla třívrstvá architektura. Vícevrstvá třívrstvá architektura se vyznačuje tím, že mezi vrstvy KlientServer přibyla další vrstva. Architektura je také známa pro své tři vrstvy jako uživatelské rozhraní, logika aplikace a přístup k datům. Tato vložená vrstva usnadňuje administrativu, ale i správu změn. Také může být použita pro plánování nebo i prioritní zpracování. Díky této architektuře je klient více izolován od zbytku aplikace a ne jenom od uživatelského rozhraní. Tím je aplikace více flexibilní a odolná. Další výhodou této architektury je celkově větší oddělení mezi všemi vrstvami. Posledním typem známých systémů je File 15

server. Tato architektura je centralizovaná. Jejím znakem je, že server je připojen do sítě a poskytuje tak přístup k souborům, které jsou na disku počítače uloženy. Komunikace této architektury probíhá následovně. Nejprve je nutný přístup pomocí uživatelského jména a hesla k požadovaným službám. Klient si připojí adresovou strukturu z dostupného serveru a poté využívá standardní funkce zobrazených souborů jako u lokálních souborů či adresářů. Klient poté zasílá požadavky, které chce s danými soubory či adresáři provést na server. Toto se děje na základě aplikačního protokolu. Server požadavky zpracuje. Může ovšem nastat, že požadavky od klienta jsou serverem nesplnitelná, jelikož ne všechny funkce, které požadavek požaduje, jsou povoleny. Poté, pokud je možno, výsledek je zaslán na klienta.

2. Získávání informací a jejich formy Pro zobrazení či export dat z datových úložišť můžeme využívat standardní nástroje aplikací. Ty jsou většinou velmi specifické a tvorba a úprava takovéto sestavy vyžaduje zásah programátora, který musí nejprve upravit zdrojový kód, následně provést jeho kompilaci a konečně implementaci do prostředí, ve kterém je sestava zobrazována. Pro zobrazení takovýchto dat byl pro systém Microsoft Dynamic NAV vyvinut nástroj, který umí vytěžit data ve formě XML a následně je přes šablonu produktu InfoPath zobrazit v HTML podobě v libovolném internetovém prohlížeči. Tento nástroj umožní vytvořit šablonu XML v aplikaci, kde dokážeme pomocí vlastních znalostí a prostředků z Microsoft SQL a ERP systému Microsoft Dynamic NAV zpracovat data a exportovat je do XML formátu. Tyto data jsou poté následně zpracována externími programy jako podklad pro publikování šablon XML. Dokážeme vytvořit datový soubor ve formátu XML na základě XML šablony definované v aplikaci Microsoft Dynamic NAV. Tento soubor můžeme přes šablonu třetího produktu zobrazit jako sestavu v HTML prostředí s možností vytištění na tiskárně, popřípadě zaslání e-mailovou formou. V případě této práce je třetím produktem Microsoft InfoPath software. Tento způsob je relativně univerzálním nástrojem pro těžení dat a jejich případnou vizualizaci. Může sloužit jako dokladové sestavy, kterými jsou faktury nebo příjemky. V těchto sestavách hrají důležité aspekty nastavení. Například nastavení formátu písma. Z těchto tabulek můžeme vytvářet i přenos XML do jiných aplikací. Tento přenos se osvědčil i pro komunikaci s technologickým systémem pro sběr dat ve výrobě, kde jsou tímto jednak validována zadávaná data do výrobních terminálů při jejich pořízení, jednak 16

zpětně přenášena data právě takto pořízená. Je to standardní řešení v aplikaci Microsoft Dynamic NAV, připravené na následné upravování dle požadavků firmy.

17

3. Definice datové struktury přenášených dat Data v informačním systému Microsoft Dynamic NAV (dále jen Navision) jsou ukládána v tabulkách nativní databáze Navision nebo, jako v našem případě v databázovém prostředí Microsoft SQL Serveru. Toto uložení dat umožňuje daleko efektivnější správu dat s pomocí robustního nástroje serveru Microsoft SQL. Další výhodou je, že ke správě dat je možno použít nástroj Object Designer, který umožňuje jednak modifikaci dat, jednak veškeré potřebné optimalizace dat jako je například indexování a trendování a v neposlední řadě i zálohování. V případě firmy, kde pracuji na této bakalářské práci, provádíme rozdílovou zálohu každých pět minut, takže případný výpadek či kolaps systému by neměl prakticky žádný dopad na zpracování dat.

1. XML jazyk Pojem XML již v dnešní době není nikomu v oblasti výpočetní techniky neznámý. Zkratka XML znamená eXtensible Markup Language. V češtině to tedy znamená rozšiřitelný značkovací jazyk. Tento jazyk umožní označit význam jednotlivých částí textu, a ne jejich vzhledu. Jde o značkovací jazyk, který byl vyvinut World Wide Web konsorciem k překonávání omezení v HTML. Nejde tedy o první jazyk svého druhu. World Wide Web konsorcium je mezinárodní konsorcium, ve kterém jeho zaměstnanci společně s veřejnosti vyvíjejí webové standarty a software. Prvním známým značkovacím jazykem byl GML (Generalized Markup Language), který vytvořili pánové Goldfarb, Mosher a Lorie při práci na systému ohledně uchování a využití právních textů pro společnost IBM. Jelikož se museli potýkat s nekompatibilitou jednotlivých systémů a programů, vedla nejsnazší cesta k vytvoření obecného značkovacího jazyka. Princip GML se uchytil a v osmdesátých letech začala organizace ANSI vyvíjet jazyk, který definoval vlastní sadu značkování. To znamená, že uživatel si mohl vytvořit svoje vlastní značky pro daný druh dokumentu. V té době GCA (Graphics Communications Association) se snažilo vytvořit standardní formátovací jazyk GenCode, který by se dal použít pro různé druhy zařízení. Většina cílů obou organizací byly stejné, a proto se organizace spojili a výsledkem byl SGML (Standart Generalized Markup Language) jazyk. Tento jazyk je definován v ISO normě 8879 z roku 1986. Jazyk SGML je hodně obecný a umožňoval vlastní sadu značek pomocí definic typu dokument, neboli DTD (Document Type Definition). Tento DTD dokument měl ale bohužel jednu obrovskou nevýhodu a to, že on sám měl svůj vlastní formát. Chtěl-li tedy programátor zavést kontrolu dokumentů, musel navíc počítat s dalším formátem. Pomocí 18

DTD bylo možno kontrolovat správnost dokumentů po stránce rozložení elementů a atributů, ale již nebylo možno definovat datové typy uložených dat. Nápravu nedostatků, které DTD mělo, opravilo konsorcium W3C, které navrhlo XSD jazyk (XML Schema Definition). Od roku 2001 je XSD oficiálním doporučením a v roce 2004 byla publikována jeho revidovaná verze. Formát XSD schématu plně specifikuje XML dokument. XML je tedy vlastně XML dokument, který popisuje jiný XML dokument. Toto sjednocení formátů vedlo k velkému zjednodušení kontroly dokumentů, kdy přibyla možnost uložit samostatné schéma přímo do dokumentu a díky tomu kontrolovat datovou část oproti schematické části. Vše tedy v XML formátu. Další výhodou XSD je i možnost definovat datové typy jednotlivých elementů a referenční vlastnosti. Nejznámější aplikací SGML je jazyk HTML (Hypertext Markup Language). HTML jazyk se používá pro tvorbu webových stránek. Tento značkovací jazyk je díky své jednoduchosti oblíben, což je paradoxem, protože jazyk SGML je velice komplexní. Nejdůležitější podmnožina SGML byla vybrána jako nový jazyk, který má tu moc dovést Web do třetího tisíciletí. Jistě tušíte, že nový jazyk dostal jméno XML. XML je tedy podmnožinou SGML u níž je zachována možnost definovat si DTD, a tedy značky, pro jednotlivé skupiny dokumentů. Jazyk XML přebírá mnohé části jazyka HTML, ale jazyk HTML úplně nenahrazuje. XML jazyk je určen především pro aplikace a pro publikování dokumentů, jelikož HTML jazyk byl příliš složitý pro tuto činnost. Můžeme tedy říci, že XML pochází z oblasti zaměřující se na uchování a zpracování textových dokumentů. XML jazyk má dvě nové funkce oproti HTML jazyku. XML jazyk nemá žádné předdefinované tagy a má mnohem přísnější syntaxi. Tím, že nemá žádné předdefinované tagy, si autor zdrojových kódů může použít ty tagy, které sám potřebuje. XML jazyk je také upraven pro více světových jazyků a lze v něm psát nejen v angličtině, ale i v mnoha jiných světových jazycích jako je například Mongolština. Jako znaková sada se používá Unicode neboli ISO 10646. Díky této sadě můžeme tedy text v daném dokumentu psát jak v angličtině, tak i v němčině a přitom nemusíme přepínat nastavení do toho či onoho jazyka. Zároveň XML také umožňuje libovolné kódování jako je například UTF-8 nebo windows-1250. Kódování windows-1250 se budeme v následujících stránkách věnovat i pro tuto bakalářskou práci. Toto kódování musí být v dokumentu určeno, pro rozdělení při konverzi z jednoho kódování do druhého. V dnešní době je aktuální verzí XML jazyka verze 1.1, která je platná od 16. 8. 2006, jelikož předchozí verze 1.0 má omezení v názvech elementů a atributů, které byly do 19

kódování Unicode přidány později. Toto omezení ale není jediným rozdílem mezi verzemi 1.1 a 1.0. Verze 1.0 se používá dodnes, ale již ve čtvrté revizi.

Obrázek 3 (příklad XML dokument)

Na Chyba! Nenalezen zdroj odkazů.Obr. č. 3 Obrázek 3 (příklad XML dokument) vidíme příklad XML dokumentu, který nám říká, o jakou verzi se jedná. V našem případě se jedná o XML verzi 1.0 s kódováním windows-1250. Jelikož XML budeme chtít i zobrazovat ve formátu, kterému každý rozumí, potřebujeme tedy nějaký stylový jazyk. XML samo nenabízí žádné prostředky pro vzhled, a proto využijeme jazyk, který umožní, jak se mají jednotlivé elementy a atributy zobrazit. Pravidlům a příkazům, které definují převod do jiného formátu, říkáme styly. Vytvořený styl se dá použít na mnoho dokumentů stejného typu. Mezi nejznámější styl patří XSL nebo CSS. XSL, neboli eXtensible Stylesheet Language, umožňuje různě upravovat a převádět dokument. Výhodou je, že jeden styl můžeme použít na mnoho různých dokumentů stejného typu. Tím dosáhneme jednotného formátování. Velice zásadní je to, že na jeden dokument můžeme použít několik různých stylů. Tento styl také umožňuje vybírat části dokumenty nebo generovat obsahy. Stylový jazyk XSL zahrnuje tři jazyky. Mezi ně patří XSL Transformace, což je jazyk, který převádí XML dokumenty. Dále XSL Formátovací objekty, který slouží pro vizuální specifikaci formátování XML dokumentů. A jako poslední je uveden XSL Path jazyk, který využíváme hlavně pro adresování částí XML dokumentu, který ale není sám XML jazykem. Naopak proti tomu existují styly CSS, neboli Cascading Style Sheets, které lze využít pro jednoduché formátování. Toto jednoduché formátování slouží pro zobrazení dokumentu, který je ve formátu HTML, XHTML nebo XML, na obrazovce. Cílem tohoto stylu je oddělit vzhled dokumentu od jeho struktury a obsahu. 20

XML je otevřený formát, který je každému zdarma k dispozici na serveru konsorcia W3C. Konsorcium se stará o další technologie související s Webem. Je tedy na každém z nás, chceme-li jít na server konsorcia a aplikaci si tak bez problémů implementovat nebo ne. Práce s XML je nám usnadněna, jelikož je to práce s textem. Můžeme si jej tedy otevřít i v pouhém Poznámkovém bloku nebo jiném jednoduchém textovém editoru. V dnešní době se ale nesluší posílat informace pomocí aplikace Word ve formátu DOC, jelikož někdo kdo má unixový počítač, si je nepřečte. Proto použijeme jednoduchý otevřený formát jako je XML. Dnes je kladen důraz na srozumitelnost a snadnou práci s daty. Většina protokolů pro síťovou komunikaci umožňuje zcela transparentně pro potřeby přenosu zkomprimovat data tak, že se u příjemce opět dekomprimují do původní podoby.

2. XML šablona XML šablona, viz Obr. č. 4 Obrázek 4 (Záložka Obecné), nám poslouží jako ukázka, abychom si mohli popsat jednotlivá pole šablony. Co to vůbec XML šablona je? XML šablona je mustr, neboli podklad pro to, jak mají výstupní data vypadat. Na XML šabloně si definujeme veškeré vstupy, abychom mohli potom vygenerovat výstupy potřebné k další naší práci. Tyto vstupy doplníme na kartě šablony do záložek „Obecné“ a „Definice“. Každá jedna XML šablona je jedinečnou kartou v systému, která je nějakými daty definována. V šabloně XML vidíme 2 záložky. A to záložku „Obecné“ a záložku „Definice“. Nejprve si popíšeme jednotlivá pole záložky „Obecné“.

21

3. Záložka XML šablony „Obecné“

Obrázek 4 (Záložka Obecné)

Pole „Dokument“ je primární klíč šablony. Zde je uveden jednoznačný kód, pod kterým šablona v systému identifikována. Z podstaty primárního klíče vyplývá, že toto pole je unikátní a systém nedovoluje pořídit duplicitní záznamy. Pole „Popis“ je popis pole v českém jazyce. I pro popis se doporučuje jistá struktura popisu, byť není nijak definována universálně. Je tudíž na každé firmě, aby si vytvořila předpisy pro tvorbu popisu. Pole „ Popis 2“ je popis pole v anglickém jazyce. Platí to samé, jako výše. Pole „Vyhledávací popis“ slouží pro využití rychlého vyhledávání. V poli „Export XML dokumentu“ se definuje, cesta a název do jakého souboru se budou data ukládat. Jedná se o soubor typu XML. Pole „Export XSL dokumentu“ popisuje cestu a název pro uložení dokumentu ve formátu XSL. Pole „Transformovat XSL šablonu“ musí být zaškrtnuto, jelikož nám určuje, zda se při spuštění funkce bude vytvářet prostý XML soubor nebo dokument transformovaný prostřednictvím XSL šablony, která byla vytvořena pomocí externích nástrojů.

22

V poli „ID ref. objektu“ se definuje místo, odkud se spouští akce neboli daný formulář. Pole „Testovací tabulka číslo“ je tabulka, nad kterou primárně data vznikají a slouží pro testovací účely zobrazení. Pole „Filtr testovací tabulky“ slouží pro test, kdy se vybere první záznam pro test a tím testujeme XML přenos. Pole „Import XML instance“ je pole, které je třeba vyplnit při využití funkce Import schématu z XML. Pole „Šablona XSL“ je necitovatelné pole definující, že byla k dané šabloně XML naimportována XSL šablona. Pole „Kódování XML“ je pole, kde si vybíráme kódování pro daný XML soubor. Toto kódování určuje, jaká bude použita kódovací sada pro XML soubor. Výchozí hodnota je nastavena v Nastavení XML editoru. Pole „Certifikováno“ je důležitým polem. Šablona, která je certifikována se zobrazuje a je možné nad ní v aplikaci Navision pracovat. Což také znamená, že je připravená k používání. Pole „Certifikováno kdy“ je pole, kde je uveden datum oné certifikace. Pole „Certifikováno kdo“ je pole, kde je pro změnu uvedena osoba, která danou šablonu certifikovala. Posledním polem v záložce „Obecné“ je pole „Archivováno“. Když je šablona archivována, tak nám nenabízí žádné možnosti práce v aplikaci Navision. Zůstává, však k dispozici pro případné dohledání zdroje dat při revizi dokladů na kterých byla použita. Po dokončení nadefinování jednotlivých polí se podíváme na funkce této záložky. „Kopie šablony“ provede kopii definice XML zvolené šablony do šablony, nad kterou je funkce spuštěna. V případě, že existují řádky definice, jsou bez varování odstraněny. Tato funkce může ušetřit čas a práci. A využijeme jí v případě vytváření podobných definic XML nebo zálohování definice při pokusném testování. „Import schématu z XML“ se uplatní především v situaci, kdy se vytváří definice XML podle již existujícího vzoru XML souboru. Cesta a název XML souboru se zadá na 23

šabloně. Tím se automaticky rozpoznají elementy a atributy, dále jejich označení a vztahy. Poté se provede import celé struktury do definice XML. Pokud jsou nutné nějaké úpravy, musíme je provést ručně. Tyto úpravy většinou zahrnují nadefinování proměnných, provázání s tabulkami, dále určení exportovaných polí případně filtry tabulek a jiné. „Testovací zobrazení“ se využije zvláště při vytváření a definování definic XML. Podstatou je vybrat si číslo zdrojové tabulky, které koresponduje s tabulkou u proměnné na řádku definice označené jako „Referenční řádek“ a filtr na záznamy v této tabulce. Po spuštění této funkce se zobrazí výsledný XML soubor, který odpovídá aktuální definici a vstupním parametrům. Zároveň výsledek tohoto zobrazení využijeme při vytváření šablony InfoPath – viz dále. Poslední funkcí této záložky Definice je „Testovací zobrazení (XSL)“, kde platí zásady testovacího zobrazení jako u předešlého odstavce s tím, že výstupem není prostý XML soubor, ale dokument transformovaný pomocí definované XSL šablony. Nyní máme všechny pole ze záložky „Obecné“ vyjasněny a podíváme se na pole ze záložky „Definice“.

4. Záložka XML šablony „Definice“

Obrázek 5 (Záložka Definice)

24

V této záložce, jak vidno na Obrázek 5 (Záložka Definice) Obrázek 5 (Záložka Definice), je definováno, jakým způsobem budou vybírána data z aplikace Navision do XML šablony. Položky šablony jsou v řádcích a jsou typu element a atribut. Tímto se definuje, jaké položky neboli pole, se z tabulky budou využívat a element nám definuje tabulku, ze které si vybírám. Celé vybírání je posazené nad základní tabulkou. Říká nám, jak se šablona bude chovat, což je důležité. Šablona je postavena nad jedním záznamem oné základní tabulky, která je relačně svázaná s jinými tabulkami. Co například nejde pomocí XML šablony? Nejde vytvořit přehled, kde se zafiltruje více záznamů, jelikož filtr by proběhl pouze nad záznamem, kde je primárně nastaven kurzor. Z toho vyplývá omezení pro XML šablony. Nejsou vhodné pro výčty dat, jelikož je zde ono omezení výběru. XML šablony jsou ale vhodné jako dokladové sestavy jako například faktury. Šablona dokáže data vyexportovat v unikátním formátu a s využitím externích aplikací, v našem případě InfoPath, jsme schopni vytvořit formát pro tisk. K tomu potřebujeme onu XML šablonu a datový soubor, kdy dostaneme dokladovou sestavu, která se zobrazí v HTML formě pomocí Internet Explorer aplikace. Definice XML je přímo přístupná z karty šablony XML na záložce Definice. Níže si popíšeme význam jednotlivých polí. „Číslo řádku“ je pole, které je automaticky přiřazeno systémem při vložení řádku. Pole „Úroveň“ určuje, kde se daný element či atribut nachází v hierarchii logické struktury celé definice. Pokud chceme úroveň přesunout na jinou úroveň tak toto činíme pomocí šipek vlevo a vpravo ve spodní části formuláře. Pokud ale známe číslo této nové úrovně, pak jej pouze ručně zadáme. Graficky jsou úrovně znázorněny odsazením, a tudíž se můžeme posouvat i o celý označený blok řádků. Toto vše lze provést pouze za předpokladu, že má pouze jeden kořenový element na úrovni nula a tomuto elementu nesmí být přiřazená žádná proměnná. Elementy na dalších úrovních mohou být pro lepší přehlednost také vždy definovány samostatným elementem bez přiřazení proměnné. Pole „Typ“ určuje, zda se jedná o Element nebo Atribut. „Název“ je pole, kde jméno elementu nebo atributu se objeví ve výsledném XML souboru. V tomto poli může být použito velkých i malých písmen bez diakritiky, číslice či podtržítka, ale nesmí obsahovat mezery. 25

Pole „Opakovat“ ukazuje, zda se jednou definovaný element může vyskytovat ve výsledném XML souboru i vícekrát. Využívá se u řádkových relací, kdy pomocí tohoto tlačítka vynutíme opakování více řádků k jednomu záznamu hlavičky. „Referenční řádek“ ukazuje na tabulku spojenou přes proměnnou s tímto řádkem. Při spuštění funkce exportu do XML se nasadí filtr vybraných záznamů a od toho se odvíjí navázání dalších údajů. V definici může být takto definován pouze jeden řádek. „Typ zdroje“ je pole pro rozlišení, zda řádek definuje proměnnou nebo textovou konstantu. V případě, že řádek je definován jako proměnná, tak se hodnota elementu nebo atributu bere z tabulek systému. Pokud se jedná o textovou konstantu, pak je hodnota zadaná přímo z řádku v poli nazvaném „Název proměnné“. „Název proměnné“ jsme si již trošku přiblížili v odstavci výše. Je-li tedy předchozí pole nastaveno jako typ zdroje Proměnná, pak se vybírá z pomocné tabulky Proměnné XML definice. Pokud tak není nastaveno, pak se vyplní pole hodnotou textové konstanty. V „Pole proměnných“ se definuje výběr z polí tabulky přiřazené dané proměnné. Obsah bude vyexportován jako konkrétní hodnota daného elementu či atributu. Více o definici proměnných si řekneme v podkapitole číslo 5 „Proměnné XML definice“. V poli „Filtr tabulky“ lze na tabulku nadefinovat potřebný filtr. Pole „Název relační proměnné“ ukazuje relaci z pomocné tabulky Proměnné XML definice, prostřednictvím kterého odkazuje na řídící tabulku pro daný řádek. „Relační pole“ definuje relace mezi poli řídící a závislé tabulky. V této záložce je opět jasně patrné na každém řádku, kdo a kdy daný řádek vytvořil či změnil. Tudíž veškerá historie je zde zaznamenána.

5. XML definice-relace Tato podkapitola nás zavede k tabulce, v níž je specifikována vzájemná vazba mezi řídící a závislou tabulkou. Což jsou vazby, kdy pole ze závislé tabulky korespondují s poli tabulky řídící. Tato tabulka je opět formulář pro definování vazeb, který lze editovat. Tyto vazby jsou definovány pod tlačítkem Definice na kartě šablony, viz Obr. č. 6 (Relace XML definice). 26

V aktuálním řádku musí být vyplněno pole Název relační proměnné. Opět existuje i jiná cesta jako i v případě tabulky Proměnné XML definice. Tato druhá cesta vede rovnou z řádku AssistEdit v poli „Relační pole“.

Obrázek 6 (Relace XML definice)

6. Poznámky XML Ke každé šabloně lze připojit libovolné textové poznámky. Tyto poznámky jsou ve formuláři, který je volán přímo z karty šablony. Poznámky lze doplnit také o kód, ID uživatele a datum. Jak vidno, opět máme historii veškerých poznámek na kartě šablony, které můžeme vidět i na Obrázek 7 (List poznámek) Obrázek 7 (List poznámek).

Obrázek 7 (List poznámek)

27

Tyto poznámky nejsou součástí následného zobrazení, popřípadě přenosu dat. Slouží pouze pro záznamy k struktuře a definici šablony. Jsou využívány návrhářem šablony pro popis kroků a akcí, které byly při tvorbě použity.

7. Export do XML Na formuláři, ze kterého bude prováděn export do XML, je tlačítko, jaké lze vidět na Obr. č 8. Toto tlačítko slouží pro zavolání exportní funkce. V našem případě není standardně nastaveno na kartě šablony XML, kterou si právě popisujeme pro aplikaci Navision, společnosti Microsoft.

Obrázek 8 Tlačítko export XML

Pokud existuje právě jedna certifikovaná šablona XML vztahující se k danému formuláři, pak export proběhne rovnou. Toto je definováno na kartě šablony v poli „ ID ref. Objektu“. Jestli ale existuje několik certifikovaných šablon XML vztahující se k danému formuláři, pak se nabídnou všechny certifikované šablony a po výběru šablony se provede export. Při této akci je důležité nastavení pole „Transformovat XSL šablonu“ na kartě šablony XML, kdy dojde buď k exportu čistých XML dat, nebo je možné vyexportovat přímo dokument naformátovaný pomocí uložené XSL šablony i v požadované grafické podobě.

28

8. Proměnné XML definice Po několika zmíněních si představíme tabulku Proměnné XML definice, viz Obr. č. 9 (Proměnné XML definice), která slouží pro zadání proměnných k určité šabloně. V této tabulce se definuje jméno proměnné a tabulka v systému, ke které se vztahuje. Tyto tabulky slouží především pro definici relací mezi hlavní tabulkou, což je tabulka, nad kterou je šablona vystavěna a tabulkami podřízenými. Z těchto tabulek v systému se pak vybírají jednotlivá pole a jejich hodnoty se exportují do XML souboru.

Obrázek 9 (Proměnné XML definice)

Editovatelný formulář pro definování proměnných k dané šabloně má vazbu na kartu šablony pod tlačítkem Šablona. K tomuto můžeme dojít i pomocí jiné cesty a to, že přímo v řádku definice XML zadáme LookUp a vidíme definování proměnné v poli Název proměnné nebo Název relační proměnné, jak je tomu i v Chyba! Nenalezen zdroj odkazů. Obrázek 9 (Proměnné XML definice).

29

4. Popis tvorby datového modelu pro plnění datové struktury Definice na kartě šablony nám určuje datový model. V této části vytvoříme vlastní šablonu a popíšeme jednotlivá vyplněná pole v záložce definice. Tím si vytvoříme pokusný datový model pro další naše potřeby. Tato šablona bude sloužit pro zobrazení konkrétního HelpDeskového požadavku (hlavička) a výpisu jednotlivých stavů, ve kterých se nacházel (řádky). Aplikace helpdeskových požadavků se ve firmě používá k zadání a řízení požadavku na správu informatiky. Jedná se především o úpravy infrastrukturního charakteru či ERP systému Navision. Aplikace má nad sebou postavené workflow stavy, na jejichž základě je řízena. Překlápěním do různých stavů vznikají jednotlivé řádky. Nad těmito stavy jsou postavena kritéria, která účinně měří výkonnost oddělení IT.

1. Tvorba vlastní XML šablony Novou XML šablonu si vytvoříme tak, že si najedeme již na nějakou existující šablonu v systému Navision a zmáčkneme klávesu F3, což je klávesa pro vložení nového záznamu. Tím se nám vytvořila nová, prázdná šablona, kterou můžeme naparametrizovat vstupními daty. Cílem tohoto příkladu je získat data z helpdeskového požadavku. Primárně data vytváříme pro konkrétní zobrazení přes XSL šablonu, kterou vytvoříme v produktu InfoPath. Naše šablona XML bude obsahovat jak hlavičku, tabulka HelpDesk požadavek, tak i její řádky, tabulka Řádek HelpDesk požadavku. XML šablona bude sloužit pro helpdeskové účely, a proto jí přidáme parametry do záložky Obecné jako je dokument, což bude naše pojmenování dokumentu, například Helpdesk požadavek. Popis nemusíme vyplňovat, pokud nepotřebujeme. Vyhledávací popis se nám automaticky propíše podle jména dokumentu. Do pole Export XML dokumentu zadáme cestu, kam se nám budou exportovaná výstupní data ukládat a do pole Export XSL dokumentu zadáme stejnou cestu, ale s formátem souboru XSL. V poli ID objektu bude číslo formuláře pro Helpdesk požadavek, jak jej máme již v aplikaci Navision vytvořené. Na tento formulář bude nutné umístnit tlačítko Export XML. V našem případě formulář Karta HelpDesk požadavku má číslo 4003310 a toto číslo zde nadefinujeme. Dále zadáme číslo testovací tabulky, která bude zároveň tabulkou produkční. Šablona je v současné době použitelná právě pro jednu 30

tabulku. Toto číslo je stejné z toho důvodu, že číslování tabulek a souvisejících formulářů v aplikaci Navision je identické. Je to pouze mnemotechnické pravidlo a platí pouze v případě, kdy k jedné tabulce existuje právě jeden formulář. V poli filtr testovací tabulky bude omezení, které se týká právě jednoho záznamu daného libovolným filtrem. V našem případě jsme vybrali požadavek HDN0002481. Poslední pole, které v tuto chvíli na záložce Obecné vyplníme, bude pole kódování XML. Pro naše účely potřebujeme kódování windows-1250. Tímto máme naparametrizovanou záložku Obecné a klikneme na záložku Definice. V záložce Definice bude definování dat velice důležitou rolí. Zde vlastně zadáme relace, které nám umožní získat výstupní data v právě takové podobě, jaké si zadáme do karty šablony. Do těla definice budeme zadávat element nebo atribut. Co vlastně znamená element? Element je základní stavební kámen každého dokumentu a většinou se označuje pomocí počátečních a koncových tagů. Názvy těchto tagů se zapisují pomocí závorek < >. V našem případě element je tabulka, ze které čerpáme data neboli primární záznamy. Atribut slouží pro upřesnění významu element a pro přidání dalších důležitých informací. Hodnota atributu musí být vždy uzavřena do uvozovek nebo apostrofů. V našem případě se atributem míní pole požadavku tabulky, ze které čerpáme data. Jednotlivé tabulky k sobě provážeme relacemi, abychom si definovali, co jednotlivý záznam znamená v tabulce druhé. Nyní přejdeme k vyplňování jednotlivých řádků těla definice. Do prvního sloupce zapíšeme Element s názvem „HelpdeskPožadavekHl“ a zadáme mu parametry. Tento element bude takzvaně kořenový. Každý XML dokument musí být celý obsažen v tomto kořenovém elementu. Jakmile klikneme do prvního řádku, automaticky se nám vybere, že jsme na řádku 10000. 10000 je označení prvního řádku. Poté číslování bude dále pokračovat takovým způsobem, že druhý řádek bude mít hodnotu 20000, třetí řádek 30000 a tak dále. Kdybychom chtěli vložit řádek mezi již existující řádky, číslo bude dáno rozpůlením intervalu těchto dvou řádků. Tudíž rozpůlením řádků 10000 a 20000 bude vložený řádek mít hodnotu 15000. Na našem prvním řádku vybereme ve sloupci „Typ“ hodnotu element. Tento element bude nultou úrovní XML dat. Jedná se o nejvýše postavený element, který bude definován ve sloupci typ zdroje jako proměnná. Název elementu je vždy započat písmenem, pro další znaky můžeme použít mimo písmen i čísla, tečku, dvojtečku, pomlčku, anebo podtržítko. Za písmeno jsou také považovány další 31

znaky z abecedy různých světových jazyků, nejen tedy ty z anglické abecedy. Pokud chceme, můžeme tedy použít i písmena s českou diakritikou nebo ruskou azbukou. Jediný problém, se kterým se můžeme setkat díky těmto písmenům z jiné než anglické abecedy, je to, že některé programy s takovouto XML specifikací neumějí spolupracovat. Proto se ve většině firem používá písmenná forma bez diakritiky. Jako druhou úroveň budeme definovat odsazený element, který ponese název proměnné „HelpDeskPozadavek“. Tento název nám ukazuje, ze které tabulky se data berou. To neurčuje název, ale proměnná zadaná v poli Název proměnné. Proměnné jsou definovány v samostatné tabulce. Mezi specifika tohoto elementu bude určitě patřit to, že element nechceme opakovat, tudíž jej vyloučíme z toho procesu tím, že nezaškrtneme proměnnou ve sloupečku Opakovat. Element nemá žádné hodnoty ve sloupci Pole proměnných, tedy není atributem. Toto pole totiž definuje pole, které chceme, aby nám výsledný XML náhled ukázal. Dále nadefinujeme atributy na řádcích šablony XML 30000 až 50000. V XML může každý element deklarovat libovolné množství atributů. Atributy již budou mít definované pole proměnných dle tabulky nadřazeného atributu, jelikož deklarace každého atributu se skládá ze jména, typu a hodnoty. Ty je nutné vybrat z tabulky definované v proměnné, která je zadána ve sloupci název proměnné. Pro název atributu platí stejná pravidla a omezení jako pro název elementu. Dále provedeme provázání řádků s hlavičkou. To bude v řádku v úrovni 3 a typu Element. Ve sloupci Název proměnné bude teď proměnná, jež definuje tabulku řádků. Protože chceme, aby se řádky opakovaly, jelikož v definici existuje k hlavičce n řádků, bude zaškrtnuto pole ve sloupci Opakovat. Pole proměnných bude v tomto případě prázdné, protože řádek není typu Atribut. Důležitý pro vytvoření relační vazby je definovat, ke které tabulce neboli hlavičkové tabulce se bude daný řádek vázat. To se definuje ve sloupci Název relační proměnné, což v našem případě bude zadána proměnná odkazující na hlavičkovou tabulku „HelpDeskRequest“. Nyní musíme definovat pole, přes která budou tabulky svázány. To definujeme ve sloupci Relační pole. Zde dojde k zobrazení podřízeného formuláře XML definice. Relace, která má tedy pouze dvě pole. A to Název pole a Název pole-relace. Do Názvu pole vybereme vazební pole z tabulky řádků. Data z tabulky hlavičky doplňujeme do pole Název pole-relace. Ve sloupci Relační pole se pak tato vazba zobrazí bez možnosti editace. 32

Následuje naplnění atributů řádků, které budeme zobrazovat ve výsledném dokumentu. Vytvoříme řádky s úrovní č. 4 a naplníme je podobným způsobem, jako atributy hlavičky. V poli proměnných budeme tentokrát vybírat ne přes vazbu na tabulku hlavičky, ale přes vazbu na tabulku řádků. Takto v našem případě naplníme řádky 70000, až 130000 vybranými proměnnými viz Obr. č. 10 (Výběr element/atribut). Díky odsazení elementů a atributů snadno vidíme strukturu zobrazeného XML v náhledu, který je použit v obrázku 3Obrázek 3 (příklad XML dokument). Tím náš dokument splňuje veškerá pravidla. Je syntakticky v pořádku a můžeme tedy o něm říci, že je správně strukturovaný. S takovýmto dokumentem si již poradí veškeré aplikace podporující formát XML.

Obrázek 10 (Výběr element/atribut)

Když už máme připravený XML dokument, zobrazíme si jej pomocí prohlížeče. K tomu ale budeme potřebovat již zmíněný prohlížeč s podporou XML. Takovým prohlížečem je například Internet Explorer 5.0 a výše nebo Mozilla. XML dokument uložíme v souboru, který bude mít příponu „xml“ a teprve poté jej můžeme zobrazit. Cílem tohoto příkladu je získat data z HelpDeskového požadavku. Primárně data vytváříme pro konkrétní zobrazení přes XSL šablonu, kterou vytvoříme v produktu InfoPath. Jestliže ale chceme používat tabulku i pro jiné zobrazení, například Internet Explorer, pak je možné v tabulce různě filtrovat či použít funkce pro tisk.

33

5. Principy práce s datovým modelem a možnosti tvorby dat Výše popsaný konkrétní příklad lze samozřejmě rozvíjet. Popsali jsme pouze dvouúrovňovou relaci, ale v praxi dochází k požadavkům na daleko košatější provázání až desítek tabulek. Jedinou zásadu, kterou je v tomto modelu nutno dodržovat, je zákaz cyklení tabulek. To znamená, že nesmí dojít k uzavření kruhu hlavičkové a relační proměnné, například přes třetí tabulku. V popsaném příkladě rovněž předpokládáme, že data budou použita pro šablonu produktu InfoPath a následně zobrazována, popřípadě tištěna. Šablonu lze použít i pro export dat do jiných produktů. Jedná se o velmi výhodný formát dat, protože řada produktů disponuje importem dat ve formátu XML. Ve firmě, kde pracuji, je tohoto využíváno při propojení docházkového modulu realizovaného v aplikaci Navision se mzdovým programem. Reálně toto budeme provádět následovně. V aplikaci Navision si zobrazíme XML šablonu, ze které chceme získat data a klepneme na tlačítko funkce, které je umístěno v levé dolní části šablony XML. Poté si dáme testovací zobrazení, datový XML soubor. Tento datový XML soubor uložíme do souboru s příponou xml. XML soubor si uložíme do nějakého adresáře, třeba na ploše počítače. Takto máme zpracovaný zdrojový kód, který je vidět na obrázku 3 Obrázek 3 (příklad XML dokument) z aplikace Navision a nyní můžeme tyto data libovolně použít. Pokud chceme konkrétní data, můžeme pro jednorázové zobrazení použít filtr testovacího zobrazení a ten upravit na požadovanou hodnotu. Pokud by měl tento export probíhat pravidelně, je možno umístit tlačítko Export XML na definovaný formulář v poli ID ref.objektu. Pro jiná data je nutno vytvořit novou šablonu, která by byla k požadovaným účelům ta pravá a na ní bychom postupovali stejným způsobem jako v kapitole 4. Znovu bychom si definovaly nějakou strukturu v záložce Definice s určitými parametry toho, co chceme ve výsledku zobrazovat.

34

6. Použití XML dat pro zpracování programem Microsoft Office InfoPath Prvním krokem v této kapitole bude samozřejmě spuštění programu Microsoft Office InfoPath. V tomto programu si zdrojový kód, který jsme si uložili do nějakého adresáře na ploše, otevřeme a budeme s ním dále pracovat. V prostředí aplikace Microsoft Office InfoPath nahlížíme na náš uložený xml soubor jako na zdroj dat. Tyto zdrojové data následně přenášíme do šablony, kterou si budeme v programu InfoPath vytvářet a upravovat je do podoby námi potřebné. Úvodní obrazovka, kterou vidíme na Obr. č. 11 (Úvodní obrazovka InfoPath), nám nabízí plno možností a funkcí.

Obrázek 11 (Úvodní obrazovka InfoPath)

Jelikož ale chceme vytvářet šablonu, do které použijeme data ze zdrojového kódu, vybereme si navrhnutí šablony formuláře dle Obr. č. 12 (Návrh šablony formuláře).

35

Obrázek 12 (Návrh šablony formuláře)

Opět máme několik možností. Tentokrát si vybíráme, jakou šablonu budeme vytvářet. Jelikož máme zdrojový kód v podobě XML, logicky použijeme formulář pojmenovaný „XML nebo schéma“.

Obrázek 13 (Průvodce)

Zobrazí se nám průvodce zdrojového kódu a žádá cestu, kde máme uložený zdrojový kód. Toto okno průvodce můžeme vidět na Obr. č. 13 (Průvodce). 36

Pokračujeme dál a dostáváme se do dalšího okna průvodce. Zde zaškrtneme možnost, zdali chceme nebo nechceme další XML. Jelikož veškerá potřebná data máme ve zdrojovém kódu již uložena, dáme v okně průvodce možnost NE dle Obr. č. 14 (Další schéma XML) a pokračujeme dál. Kdybychom dali ANO, pak bychom mohli kombinovat více souborů XML se zdrojovými kódy.

Obrázek 14 (Další schéma XML)

Posledním krokem je kliknutím na tlačítko Dokončit a tím pádem otevření aplikace. Poté jsme již v prostředí InfoPath, kde si můžeme programovat potřebnou šablonu. Po dokončení všech kroků se nám zobrazí jakoby prázdný papír a v pravé části obrazovky je zdrojový kód, který jsme si v průvodci zadali, viz Obr. č. 15 (Prostředí InfoPath).

Obrázek 15 (Prostředí InfoPath)

37

Aplikace Microsoft Office InfoPath, jak lze podle názvu poznat, řadíme do rodiny aplikací firmy Microsoft. Tento program nemá menu jako ostatní programy firmy Microsoft jako například aplikace Word či Excel. Menu aplikace InfoPath má více menu podobné minulé verzi, nežli verzi 2007. Tato verze také účinně pomáhá firmě k dosažení správy podnikových procesů založených na formulářích. Tato aplikace pomáhá firmě také vytvořit a řešit sběr dat pomocí těchto elektronických formulářů, která tato aplikace nabízí. InfoPath nenabízí firmě pouze používání podkladů z XML dat, ale i z aplikací Microsoft Word či Excel s tou výhodou, že data budou zachována ve stejné struktuře. Podpora schémat XML, kterými se zabýváme v této bakalářské práci, zajišťuje kompatibilitu se stávající firemní infrastrukturou. Formuláře, lze pomocí této aplikace vyvíjet, aniž bychom programovali či využili šablon knihoven. Abychom měli co nejefektivnější shromáždění informací, potřebuje tato aplikace spojení se serverem Office SharePoint Server, čímž je dosažena centralizace nasazení a správy těchto formulářů celé firmy. Aplikace InfoPath umožňuje nejen návrh jednoduchých formulářů, ale i složitějších formulářů procesů. Pokud je možnost přístupu k serveru se Službou InfoPath Form Services, lze šablonu navrhnout přímo ve webovém prohlížeči nebo v mobilním zařízení. Když se navrhují a vyplňují formuláře, využívá se standardních funkcí jako s jinými dokumenty v aplikacích firmy Microsoft. Lze tedy kontrolovat pravopis, různě formátovat buňky, používat stylů písma či úpravy grafiky. Tato aplikace také umožňuje sloučení několika formulářů do jednoho výsledného formuláře nebo exportovat výsledek do jiného programu. Tato aplikace je založena na programovacím jazyku XML, což v našem případě je velice výhodné, jelikož jak zdrojový kód máme v XML podobě, tak i výsledek tohoto formuláře. Jediná šablona této aplikace může firmě usnadnit mnoho administrace, protože se dá využít pro více procesů. Formuláře mají i další výhodu, pokud jsou propojené s expertními či interními webovými rozhraní, lze je využívat i od zaměstnance, dodavatele či zákazníka. Další výhodou je, že se šablona dá stáhnout i do mobilního zařízení a poté ji uživatel může jednoduše otevřít a vyplnit. Další výhodou této aplikace je i návrh formulářů pomocí Microsoft Office Outlook a jejich následné odeslání pomocí e-mailů. Tato aplikace může nejen pomoct s požadavky na sběr informací a následným návrhem formulářů, ale může usnadnit i práci programátorům, kteří si mohou část formulářů vložit do vlastních aplikací. Formuláře nebo jejich části se dají opětovně použít pro jiné návrhy nebo je lze použít jinými způsoby. Nejvíce jsou formuláře navržené v této aplikaci kladně hodnoceny od uživatelů, kterým způsob vyplňování dat velice usnadňuje práci, a mají možnost se tedy vyhnout zadávacím chybám. Tato aplikace také disponuje s offline režimem, což znamená, 38

že uživatel nemusí být připojen do sítě, když je šablona vyplňována potřebnými daty. Tuto funkci ocení uživatelé, kteří mají omezený nebo jinak limitovaný přístup do sítě. Těmito uživateli mohou být i uživatelé na cestách. Nyní přistoupíme k vlastnímu návrhu šablony InfoPath. Máme jakoby čistý papír a budeme kreslit. Šablona bude mít strukturu tabulky, kterou si vytvoříme pomocí dvou způsobů. Máme jednodušší možnost pomocí tlačítka Vložit. Zde si dáme počet sloupců a řádků. Nebo druhá možnost, jak si vytvoříme tabulku, je pomocí tlačítka Tabulka a dále pak tabulka rozložení. Pro účely této práce použiji tuto druhou možnost. Na prázdném papíře, který se nám zobrazil po ukončení průvodce zdrojovým kódem, máme myš ve tvaru tužky. Pomocí této tužky můžeme kreslit tabulky, sloupce a řádky jak je potřeba. Výhoda této tužky je velice snadné ovládání a tudíž i kreslení tabulek, sloupců a řádků. Někde stojíme, máme kurzor zobrazen jako tužku a pomocí stisknutí levého tlačítka myši kreslíme čáry neboli hrany tabulky. Je nutné se ovšem trefit na hranici řádku či sloupce a táhnutím kurzoru zase na hranici řádku nebo sloupce kurzor pustit. Pokud se toto nepovede, žádná čára neboli nová hranice buňky se nevytvoří. Takto kreslíme a tím navrhujeme tabulku šablony v aplikaci InfoPath. Když je tabulka navržena, lze do ní přenášet data ze zdrojového kódu, který vidíme v pravé části obrazovky. Tento zdrojový kód funguje na bázi rozbalování dat. To znamená, že plusy jsou jako zabalená data, mínusy jsou rozbalená data. Přenášení dat je opět jednoduché a snadné, najedeme kurzorem na zdrojový kód a pomocí myši přetáhneme právě to pole zdrojového kódu, které jsme si vybrali, nad buňku v tabulce šablony InfoPath. Tím, že máme nějaká zdrojová data v buňkách tabulky, se objevuje nad najetím myší nad danou buňku modrý index s popisem proměnné ze zdrojového kódu, který je zobrazen v pravé části obrazovky. Podle Obr. č. 16 (Tabulky) máme navrženy dvě tabulky. Abychom mohli vytvářet několik tabulek, sloupců či řádků, musíme při každé nové činnosti kliknout na tlačítko Tabulka a vybrat si Navrhnout tabulku. Tímto se nám zobrazí místo klasického kurzoru kurzor tužky, pomocí které malujeme potřebné buňky. Dále můžeme tabulku z hlediska vlastností modifikovat. Například jí můžeme různě ohraničit. Ohraničení může být skryté nebo viditelné. Vnitřní nebo vnější. Slabší či silnější. Může mít různě velikou šířku ohraničení, styl ohraničení či jeho barvu a jiné. S návrhem tabulek si jde vyhrát hodiny a hodiny. Lze vložit tabulku do hlavní tabulky i přemisťování části tabulky na jiné pozice. Pokud ovšem 39

chceme tyto činnosti provádět, musíme mít daný úsek modře označený myší a poté z menu vybrat co vlastně s ním chceme provádět. Pro jednotlivé kategorie se dělají řádky, aby se s tím dalo lépe pracovat. Pomocí kurzoru zobrazeného jako tužka, tedy připraveného na kreslení, můžeme tabulku různě upravovat. Rozdělovat řádky a sloupce na několik částí. Tyto buňky se dají také různě přesunovat, přemisťovat dle potřeby návrháře šablony InfoPath.

Obrázek 16 (Tabulky)

První tabulka obsahuje hlavičku, kam jsou vkládána zdrojová data z prvního elementu a jeho atributů dle definice XML šablony. Zde je tedy možno vidět buňky jako jsou číslo, kategorie či popis. V těle tabulky jsou obsaženy data z druhého elementu. Jsou jimi atributy stav, uživatel, jméno či popis. Tyto atributy jsou v definici XML šablony dány jako opakované atributy pomocí zaškrtnutí pole opakování u elementu těchto atributů. Díky tomuto opakování jsou data v aplikaci InfoPath zobrazeny v tabulce jako oddíl s opakováním. Abychom viděli, jak šablona v aplikaci InfoPath vypadá, můžeme si dát její zobrazení. Bohužel v náhledu šablony jsou buňky prázdné, i když jsou tam zadány hodnoty ze zdrojového kódu. Další možností jak na šablonu můžeme nahlížet, je pomocí Internet Exploreru.

40

Když je šablona v aplikaci InfoPath hotová. Uložíme si jí jako zdrojové soubory z XML šablony v aplikaci Navision do adresáře, kde máme již uložený XML soubor. To provedeme pomocí tlačítka Soubor a vybereme si uložit jako zdrojové soubory, viz Obr. č. 17 (Uložení šablony).

Obrázek 17 (Uložení šablony)

Když si otevřeme tento adresář z plochy, vidíme mnoho souborů. Pro nás je hlavní soubor s příponou XSL. Tento soubor s popisem Šablona stylů ve formátu XSL je uložena pod názvem View1, jelikož jsme si ho nijak nepojmenovali při ukládání XSL je zkratkou anglického názvu eXtensible Stylesheet Language. Tento programovací jazyk měl být jakousi odrůdou kaskádových stylů. Umožňoval definovat vzhled či zarovnání jednotlivých elementů nebo jej bylo možné použít pro automatické generování obsahu, číslování obrázků nebo kapitol. Postupně však došlo k názoru, že XSL jazyk se bude používat ke dvěma odlišným věcem. Jednou z nich bude transformace XML dokumentů a druhou možností bude definování vzhledu. Během příprav standartu XSL z něj byla ona část ohledně transformace vyjmuta a nyní se pro ni používá samostatné pojmenování XSLT z anglického názvu eXtensible Stylesheet Language Transformations. Pomocí tohoto jazyka lze definovat, jak se budou soubory XML transformovat do tvaru 41

HTML, do jiných textových editorů nebo do XML dokumentů, které budou mít již jinou strukturu. Z tohoto výčtu možností je dnes nejvíce využívána možnost transformace do HTML formátu. Je to z důvodu, že většina prohlížečů si neumí poradit s formátem XML. Jazyk XSLT byl přijat jako standard konsorcia W3C. Tento jazyk má nastaven softwarové procesy, které umožňují zpracování XML souborů na základě XSLT metody. Vlastním procesorem programu XSLT se může pochlubit mimo jiné i firma Microsoft, která v této bakalářské práci hojně vystupuje. Dalšími firmami na trhu jsou Oracle, IBM či jiné světové firmy. Název druhé části XSL, která slouží právě k definici vzhledu, se říká XSL FO, zkráceně XSL. Což znamená formátovací objekty. I pro tento programovací jazyk jakož i pro XSLT existují programy, které podporují XSL jazyk. Je jich ale výrazně méně. To je důvodem toho, že XSL prozatím nebyl standardizován. Tímto bychom ukončili malý výlet do XSL stylu a vrátíme se zpět k tématu této bakalářské práce. Máme vytvořenou šablonu v aplikaci InfoPath a máme jí uloženou v adresáři spolu s XML zdrojovým kódem. Přepneme se do aplikace Navision a zobrazíme si šablonu, pro kterou máme zdrojový kód. Dole je tlačítko šablona. Klikneme na toto tlačítko a dáme importovat. Najdeme námi vytvořenou šablonu InfoPath a dáme otevřít. Tímto procesem se nám přiřadí šablona InfoPath k šabloně v aplikaci Navision. Můžeme to zaregistrovat i tím, že se automaticky zaškrtlo políčko Šablona XSL v záložce Obecné na kartě šablony XML, viz Obr. č. 18 (Zaškrtnutí šablony XSL). Pomocí tlačítka Funkce na kartě šablony dáme testovací zobrazení XSL a tím se nám zadají zdrojová data z aplikace Navision do šablony, kterou jsme si vytvořili v aplikaci InfoPath. Data do této šablony jsou brána z filtru tabulky, který máme definovaný na záložce Obecná na kartě XML. Tento filtr testovací tabulky je právě a jenom pro toto dané testovací zobrazení.

42

Obrázek 18 (Zaškrtnutí šablony XSL)

Standardně aplikace Microsoft Office InfoPath není používána pro tisk, jako je tomu u našeho případu. Aplikace se standardně využívá k zadávání dat. Nadneseně můžeme o aplikaci InfoPath říci, že je to jakási forma programovacího jazyka, jelikož si ve formuláři aplikace InfoPath definujeme, co chceme, aby se zobrazovalo. Tyto informace můžeme zobrazovat třeba přes webové stránky. Jelikož máme šablonu InfoPath přiřazenou k šabloně XML, vyzkoušíme si, zdali správně funguje na nějakém konkrétním případě. V aplikaci Navision si zobrazíme pult dispečera, kde si zobrazíme HelpDeskové požadavky. Vybereme si některý HelpDeskový požadavek, který poslouží této práci, a zobrazíme si jeho kartu. Abychom mohli zobrazit data této karty, musíme mít na ní umístěné tlačítko, které nese na sobě nápis Export XML. Bohužel na zobrazené kartě HelpDeskového požadavku toto tlačítko není standardně umístěno a proto si jej musíme pořídit z jiného formuláře, kde víme, že toto tlačítko je dostupné. Také víme, že toto tlačítko na jiném formuláři je otestované a funguje jak má. Musíme se přepnout do programního prostředí, jelikož doposavad jsme používali pouze uživatelské prostředí aplikace Navision. Pro programátorské prostředí budeme potřebovat práva programátora. Pokud tyto práva máme, cesta je nám otevřena. Zobrazíme si tlačítko Nástroje v hlavičce aplikace Navision a najedeme na pole Designer. Tímto krokem jsme se dostali do programátorského prostředí 43

a můžeme nakopírovat potřebné tlačítko Export XML z jiné karty. Najedeme si na kartu, která na sobě nese toto námi potřebné tlačítko, dáme na klávesnici klasický proces pro kopírování, neboli zmáčkneme klávesnice CTRL+C a vrátíme se na kartu HelpDeskového požadavku, kde provedeme proces pro vložení dat, neboli zmáčknutí kláves CTRL+V. Nyní máme na kartě HelpDeskového požadavku vkopírované tlačítko Export XML. Tímto máme kartu připravenou, aby se její data mohla zobrazit pomocí InfoPath šablony. Aby k tomu mohlo dojít, musíme šablonu XML v aplikaci Navision certifikovat. To provedeme zaškrtnutím políčka certifikovat na záložce Obecné v šabloně XML. Poté se vrátíme na kartu HelpDeskového požadavku, který chceme zobrazit pomocí šablony InfoPath a klikneme na nově umístěné políčko Export XML. Zde na tomto tlačítku máme dvě možnosti, jak ukazuje Obr. č. 19 (Políčko Export XML). Jednou z možností je Dokument XML a druhou možností je Náhled XSL.

Obrázek 19 (Políčko Export XML)

Dokument XML nám vyexportuje data ze šablony XML. Konkrétně ze záložky Obecné data. Exportuje je do souboru dle definice z karty šablony XML. Náhled XSL je možnost, pro kterou tlačítko Export XML ve firmě, kde pracuji na této bakalářské práci, primárně používáme. Je to náhled námi navržené tabulky dle šablony InfoPath. V tomto náhledu jsou aktuálně použita data z daného HelpDeskového požadavku, pro který máme náhled zobrazen. 44

V našem případě této bakalářské práce použijeme právě možnost náhledu XSL. Náhled se nám zobrazí přes použití Internet Exploreru. Zde využíváme standardní funkce zobrazení jako je náhled či tisk zobrazených dat. Internet je síť celosvětově propojených uzlů. Uzlem se míní počítač, nebo specializované zařízení. Počítače zde komunikují přes rozhraní protokolů TCP/IP. Každý počítač má v TCP/IP svou IP adresu, ale pro snadnější orientaci se používají doménová jména. Všichni uživatelé této celosvětové sítě se snaží o jediný cíl a to o bezproblémovou komunikaci. Pomocí Internetu jsme schopni využívat nejvíce rozšířenou službu a to je služba WWW. Na druhém místě je to služba E-mail, a dále pak i jiné služby. Počítačové programy, které jsou potřeba pro tyto služby, spolu komunikují pomocí protokolů. I Internet má svá doporučení pro tyto protokoly. Tyto doporučení jsou známá pod anglickou zkratkou RFC (Request For Commments). Jednotlivé RFC jsou vytvořeny autory, kteří řeší konkrétní problém a naleznou možnost opravy. Tuto opravu zveřejní ve formě návrhu RFC Internetové veřejnosti. Jestliže tento návrh projde, je dokument vydán jako RFC. I když RFC je jenom doporučení, je až na výjimky všemi uživateli dodržováno. Vznik započal v roce 1958. Tehdy byla založena agentura ARPA (Advanced Research Projects Agency), která zajistila obnovu technického postavení USA. A v roce 1969 se zprovoznila síť ARPANET. Tato síť měla 4 uzly v různých částech území USA. Jelikož byla síť decentralizovaná, neměla žádné centrum, které by se dalo zničit. Od té doby se počet připojených uzlů zvyšuje a roste čím dál rychleji. V dnešní době má síť Internet více než miliardu uživatelů. K velice dobrému pochopení propojení uživatelů v této síti je níže uvedený

Obr.

č.

20

(Grafické

znázornění

části

Zdroj:http://cs.wikipedia.org/wiki/Internet

Obrázek 20 (Grafické znázornění části Internetu) Zdroj:http://cs.wikipedia.org/wiki/Internet

45

Internetu)

46

7. Výsledky a doporučení 1. Rozvoj publikačních šablon v rámci Microsoft Dynamic NAV S využitím publikačních šablon se nadále počítá. Samotný modul je současně rozvíjen a to do dvou směrů. Prvním je směr, který zpřesňuje a zkvalitňuje možnost získávání primárních dat. Tyto primární data jsou uloženy v řádcích nad primárními tabulkami nebo i na opakování řádků základní tabulky. Druhým směrem, kterým se rozvoj udává, je směr, který rozšiřuje možnosti zobrazení XML dat pomocí jiných programů než InfoPath. V současné době jsou vytvářeny konektory do aplikací firmy Microsoft. Těmito aplikacemi se míní Excel či Word. Tak jak byla a je používána šablona v aplikaci Microsoft Office InfoPath, tak se šablona bude vytvářet podobným způsobem i v aplikacích Excel nebo Word. Dále se připravuje možnost používání obrázků v šabloně. Pod pojmem obrázek si můžeme představit logo nebo čárový kód, který je integrován v databázi SQL, což je primární databáze aplikace Microsoft Dynamic NAV. Dalším směrem v rozvoji publikačních šablon je možnost ukládání sestav do formátu pdf s možností automatického vytváření některou ze standardních úloh plánovačů aplikace Navision. Plánovač je typ objektu jako procedura nebo sestava. Na základě tohoto objektu jsou nastaveny nějaké parametry. Podle těchto parametrů se vyberou data, vloží se jako parametry do tvorby XML šablony a poté co je úloha zpracována, se uloží do pdf souboru. Tento pdf soubor se odešle na účty uživatelů pomocí e-mail služby. Tyto e-maily jsou přednastaveny v definicích, v akcích úlohy. Každou úlohu lze plánovat a automaticky spouštět v cyklu. Když je nutné, lze některé období vyloučit z plánu, a tudíž se zadají data jako „plánovat od“ nebo „příští běh“ či „interval“. O dávkovém zpracování lze říci, že je vykonáno pomocí programů bez účasti uživatele. Dávky jsou připraveny předem, tudíž mohou být zpracovány a předány bez účasti jakéhokoli uživatele. Všechna vstupní data jsou připravena v úloze zpracování, která má jasně dané parametry. Takovéto dávkové zpracování je už od prvních počítačů spojeno se sálovými počítači. Jelikož byly počítače příliš nákladné, toto bylo jediným hospodárným způsobem, jak to lze zefektivnit. Dávkové zpracování je opakem interaktivního zpracování. Interaktivní zpracování umožňuje uživateli za běhu programu zadávat

47

požadované vstupy. V minulosti Interaktivní textová nebo grafická rozhraní nebyly příliš rozšířeny, jelikož počítače nebyly schopné zpracovávat více programů najednou. Dávkové zpracování je ale i přes svoji historii stále velmi populární. Využívají jej stále programy v prostředí Microsoft Windows nebo i Unixové systémy. Hlavní výhodou tohoto zpracování je odložení zpracování dávek do doby, na kdy je plánováno. Tyto plány tvoří uživatel tak, aby počítač v době dávkového zpracování byl méně vytížen a měl tedy prostor pro vlastní zpracování vstupů. Další velkou výhodou tohoto zpracování je propojení zdrojů s dalšími uživateli a programy. Zajisté je třeba zmínit i výhodu odstranění prodlev, kdy program čeká na nějaký vstup od uživatele. Z hlediska financí bychom měli zmínit i maximalizaci využití počítače a tím i zlepšení míry investic. Mezi nevýhody tohoto dávkového zpracování neboli batch processing patří na prvním místě vysoký požadavek na paměť a procesor počítače, ale i maximální využití systémových zdrojů. Dalším rozvojem publikačních šablon je plán zpracování předání obecných parametrů mimo tabulky aplikace Navision, aktuální čas, pracovní datum nebo uživatel. Tyto parametry budou zadány do XML šablony v aplikaci Navision. Posledním směrem rozvoje je použití pro jeden datový základ. Připravuje se datový základ s nějakými parametry a volbou použití pro více tabulek.

2. Využití dat pro synchronizaci Data pro více aplikací jsou zajišťována pomocí synchronizace. S pomocí této funkce se může uživatel přihlásit k různým počítačům ze stejného uživatelského účtu, ke kterým má daný uživatel přístup. Vždy je třeba zajistit, aby data byla konzistentní pro větší počet aplikací. Může se jednat o údaje z konkrétních míst nebo z několika částí světa. Data, která jsou využita pro různé aplikace, se obvykle uchovávají v jednom systému a v tom je největší problém. Z toho plyne, že IT oddělení musí zajistit synchronizace dat tak, aby veškeré údaje byly odkudkoliv kdykoliv v aplikaci nebo i jiných systémech k dispozici. Synchronizace dat je většinou částí velkého projektu ve firmě, který umožňuje měnit obchodní procesy a kde je třeba implementace nových klíčových aplikací. Toto vede ve velkých organizacích k zakonzervování firemní struktury, která se velice často setkává se složitostí, obtížnou údržbou, ale zároveň se vyskytuje i nekonzistence dat. 48

Pokud je potřeba synchronizovat data mezi notebookem a domácí stanicí, je nutné mít přístup ke stejným souborům. Mnoho z nás jistě několikrát potřebovali pracovat z jiného místa než jen z práce. Vzniká zde potřeba využívat některé soubory, které zůstaly na počítači v práci. Tím, že budeme mít tento přístup ke stejným souborům, odpadá zasílání si práce domů. Uživatel se jednoduše přihlásí na svůj účet a soubory, které jsou určené k synchronizaci, se synchronizují. Podle kapacity internetového připojení je délka trvání této synchronizace. Zde je možnost, aby si uživatel definoval, kolik z této kapacity program bude využívat. Když se uživatel přihlásí na svém počítači v práci, veškerá práce, kterou vykonal v domácím prostředí, bude v té samé verzi i na počítači v kanceláři. Což vlastně znamená, že se provedla aktualizace souborů a uživatel má k dispozici neaktuálnější možnou verzi požadovaného souboru. Dalším podobným typem synchronizace dat je synchronizace, která se provádí většinou u velkých firem, kde jsou data uložena na serverech. Pro uživatele se nic nikterak nemění. Má stále aktuálnost dat na všech úložištích. Synchronizace pro data stejných aplikací se provádí jedenkrát denně, nejlépe v noci, kdy žádný uživatel není připojen. Tato činnost však ustupuje do pozadí s rozvojem Klient-Server a třívrstvou architekturou, jelikož uživatelé přistupují k souborům pomocí tenkého klienta. Nevýhodou této synchronizace je, že záznamy, které byly upraveny jednou stranou, nesmí být druhou stranou modifikována, dokud nejsou synchronizována. Dnes ale již existují programy, které umí i toto ošetřit. Druhým typem této synchronizace dat je synchronizace dat mezi různými aplikacemi, kde platí obdobné zásady. Nelze modifikovat stejná data, jelikož by došlo ke křížení. Může však docházet k modifikaci jiných dat, třeba i na stejné kartě v dané aplikaci. Synchronizace je u většiny firem nákladným a rizikovým projektem, jelikož dochází k požadavkům na data v tak velkém měřítku, že je nutné použit dávkového i transakčního zpracování pro různé požadavky, ale i časy. Také pokud má firma outsourcingovou podporu, poskytovateli tato synchronizace může způsobovat problémy v rychlosti. Synchronizace dat klade také důraz na složitosti aplikací, neboť aplikace požadují specifické formáty dat. Práce s nimi může vést k nárůstu datových struktur, které vedou ve většině případů k nekonzistenci. Pro klíčové aplikace je nejdůležitější spolehlivost a výkon, pro které je právě ona synchronizace dat tak potřebná.

49

Závěr V předešlých kapitolách jsme probrali historii vzniku informačních systémů vázajících na programové řešení. Zabývali jsme se blížeji platformou Microsoft, uložením dat na Microsoft SQL Serveru a ERP systémem NAV. Ukázali jsme si, jak získávat data z datového úložiště přes interní nástroj zmiňovaného ERP systému. Z výše uvedeného vyplývá jedna skutečnost. Data, která vznikají ať již ručním pořízením v ERP systému či automatickým sběrem dat v technologických systémech jsou v syrové formě nepoužitelná. Vzniká potřeba nástroje, který tyto data zpracuje tak, aby měla vypovídající charakter. Jednak aby informace byla komplexní a jednak, že je stále větší tlak na propojování datových úložišť různých platforem a různých typů. Dalším fenoménem je výměna dat mezi jednotlivými aplikacemi, jejich sdílení a to nejen v rámci jedné firmy, ale i v rámci odběratelsko-dodavatelského řetězce. Vznikají datová úložiště, do kterých jsou tyto data ukládána a následně importována do ERP systémů obchodních partnerů. Toto vše přispívá k reálnosti pohledu na stav jak hospodářských tak obchodních ukazatelů firmy, ale hlavně jejich aktuálnost. To přispívá ke zkracování a zpřesňování požadavků na zdroje, jejich efektivní využití, popřípadě modelování dopadů výpadků do celkového řetězce ať vlastní výroby, tak dodavatelsko-odběratelských vztahů. Pro tuto datovou komunikaci se ukázal vhodný právě zmiňovaný jazyk XML. Právě jeho univerzální struktura, jednoduchost a platformou daná nezávislost z něj činí jednotného kandidáta na jazyk budoucnosti. Tato práce ukázala pouze jednu z možností jeho využití a propojení několika málo aplikací. Šíře použitelnosti je však obrovská.

50

Literatura [1] INFORMATICA. Synchronizace dat [online]. 2009.[cit. 2009-06-22] Dostupný z WWW: [2] KOČÍ Michal. Co je XML? [online]. 2001. [cit. 2009-06-05]. Dostupný z WWW: [3] KOSEK Jiří. Jazyk XSL aneb jak snadno a rychle transformovat XML dokumenty [online]. 2009. [cit. 2009-06-05]. Dostupný z WWW: [4] KOSEK Jiří. XML [online]. 2009. [cit. 2009-06-05]. Dostupný z WWW: [5] KOSEK Jiří. XML a stylové jazyky [online]. 2009. [cit. 2009-06-05]. Dostupný z WWW: [6] MICROSOFT. Microsoft Office InfoPath 2007 [online]. 2009. [cit. 2009-06-20]. Dostupný

z WWW:

[7] MUKNŠNÁBL Josef. Ukládání a zpracování dat [online]. 2001.[cit. 2009-06-15]. Dostupný

z WWW:


dat/articles.html?id=148> [8] SYNCHRONIZACE. Bezpečná synchronizace dat mezi vašimi počítači [online]. 2009. [cit. 2009-06-05]. Dostupný z WWW: [9] WAIC Vlastimil. Data všude a bez hnutí prstem [online]. 2009. [cit. 2009-06-05]. Dostupný z WWW: [10] WIKIPEDIE. Extensible Markup Language [online]. 2009. [cit. 2009-06-05]. Dostupný z WWW: [11] WIKIPEDIE. Microsoft InfoPath [online]. 2009. [cit. 2009-06-15]. Dostupný z WWW: 51

[12] WIKIPEDIE. XPath [online]. 2009. [cit. 2009-06-15]. Dostupný z WWW:

52