Silverlight aplikace pro Dynamics CRM

Transkript

1 MASARYKOVA UNIVERZITA FAKULTA INFORMATIKY Silverlight aplikace pro Dynamics CRM DIPLOMOVÁ PRÁCE Bc. Tomáš Kopecký Brno, podzim 2013

2 Prohlášení Prohlašuji, že tato práce je mým původním autorským dílem, které jsem vypracoval samostatně. Všechny zdroje, prameny a literaturu, které jsem při vypracování používal nebo z nich čerpal, v práci řádně cituji s uvedením úplného odkazu na příslušný zdroj. Bc. Tomáš Kopecký Vedoucí práce: RNDr. Ing. Tomáš Ludík ii

3 Poděkování Chtěl bych poděkovat RNDr. Ing. Tomáši Ludíkovi za vedení mé diplomové práce, za cenné rady a čas, který mi věnoval. Dále děkuji Ing. Jiřímu Stříbrnému ze společnosti GEMMA Systems/Dynamica za konzultace k vytvářené aplikaci a za poskytnutou literaturu a softwarové prostředky. iii

4 Shrnutí Tato diplomová práce se zabývá systémem Microsoft Dynamics CRM, který je určen pro řízení vztahů se zákazníky, a technologií Microsoft Silverlight. Silverlight slouží k vývoji a spouštění RIA aplikací. Cílem práce je vytvoření Silverlight aplikace, která se bude spouštět z prostředí Dynamics CRM a umožní provádění pracovního postupu nad libovolným množstvím záznamů. Aplikace bude také dovolovat zobrazení pracovního postupu ve formě procesního diagramu. iv

5 Klíčová slova řízení vztahů se zákazníky, Microsoft Dynamics CRM, Microsoft Silverlight, zobrazení, uložené zobrazení, pracovní postup, UML Activity Diagram, Business Process Diagram v

6 Obsah 1 Úvod Řízení vztahů se zákazníky Charakteristika řízení vztahů se zákazníky Využití informačních technologií v řízení vztahů se zákazníky Webové aplikace Bohaté internetové aplikace Microsoft Silverlight Popis technologie Microsoft Silverlight Grafické uživatelské rozhraní Silverlight aplikace Zdrojový kód Silverlight aplikace Microsoft Dynamics CRM Charakteristika systému Microsoft Dynamics CRM Rozšířené hledání Procesy Microsoft Dynamics CRM z pohledu vývojáře softwaru Využití Silverlightu v Microsoft Dynamics CRM Zpřístupnění Silverlight aplikace v prostředí Dynamics CRM Silverlight aplikace jako ovládací prvek na formuláři Komplexní Silverlight aplikace v Dynamics CRM Analýza aplikace Požadavky na aplikaci Spouštění pracovního postupu nad libovolným počtem záznamů Zobrazení pracovního postupu ve formě diagramu Diagram případů užití Výběr technologií pro tvorbu aplikace Zpracování XAML dokumentu pro definici pracovního postupu Návrh aplikace Diagram tříd Grafické uživatelské rozhraní aplikace Obrazovka pro výběr uloženého dotazu Obrazovka pro výběr pracovního postupu Obrazovka zobrazující provádění pracovního postupu Obrazovka s diagramem pracovního postupu Implementace aplikace Předávání vstupních parametrů...41 vi

7 7.2 Získávání záznamů z Dynamics CRM serveru Vykreslování diagramu pracovního postupu Testování aplikace Závěr...45 Literatura...46 A Hlavní okno systému Microsoft Dynamics CRM...49 B Okno pro manipulaci s pracovním postupem...50

8 1 Úvod Cílem každého podnikatele nebo firmy je maximalizovat svůj zisk. Toto tvrzení platí a bude platit nejspíše napořád. Způsob, jak co největšího zisku dosáhnout, se však mění. Koncem 18. století, v období průmyslové revoluce, nastal rozvoj sériové a masové výroby produktů. Výrobci byli schopni dodat na trh větší množství zboží, než kolik jej bylo poptáváno. Jejich úkolem tedy bylo distribuovat své výrobky v širším měřítku, aby se dostaly k co nejvíce zákazníkům. Až do poloviny 20. století se podniky zaměřovaly především na své produkty, které se snažily protlačit na trh bez ohledu na to, jestli po těchto produktech existovala skutečná poptávka. Cílem bylo vyrábět výrobky, najít pro ně zákazníky a přesvědčit je ke koupi výrobku. Ve druhé polovině 20. století došlo k přehodnocení tohoto postoje. Spíše než na hledání zákazníků pro své výrobky se společnosti zaměřily na hledání výrobků pro dobré zákazníky. Do centra pozornosti se tak dostávají zájmy a potřeby zákazníka. Cílem podniků není maximální zvyšování tržeb z jednotlivých nákupů, ale vytvoření trvalého vztahu se zákazníkem [1]. Tento vztah je potřeba rozvíjet a musí z něj profitovat jak firma, tak i zákazník. Proces, při kterém se společnosti snaží zajistit co největší spokojenost svých zákazníků, je označován jako řízení vztahů se zákazníky 1. Vztah se zákazníkem nelze rozvíjet, pokud o zákazníkovi a vztahu nemáme žádné údaje. Podniky by měly zaznamenávat informace o interakci se zákazníkem, údaje o jeho postojích a názorech nebo jeho možných vazbách na jiné zákazníky [1]. Informace je dále nutno analyzovat, hodnotit a vyvozovat z nich závěry pro další směřování společnosti. Je proto přirozené, že v oblasti řízení vztahů se zákazníky hrají významnou roli informačně komunikační technologie. Pro podporu řízení vztahů se zákazníky existují specializované softwarové systémy. Jedním z nich je i Dynamics CRM od firmy Microsoft [2]. Dynamics CRM lze ovládat prostřednictvím webového prohlížeče, čímž uživateli odpadá starost s instalací programů do svého počítače. Microsoft využívá toho, že webové stránky dávno nejsou tvořeny jen textem a obrázky. Mnoho internetových stránek nabízí bohatý obsah ve formě interaktivních aplikací s propracovaným grafickým uživatelským rozhraním. Přes webový prohlížeč je tedy možné používat aplikace, které se funkcionalitou i svým vzhledem vyrovnají klasickým desktopovým aplikacím. Dynamics CRM poskytuje základní prostředky pro řízení vztahů se zákazníky a zároveň nabízí platformu pro rozšiřování své funkcionality. Tím je zajištěno, že systém bude schopen plnit i nestandardní požadavky svých uživatelů. Rozšiřování funkcionality je realizováno prostřednictvím webových aplikací, které 1 Místo termínu řízení vztahů se zákazníky se často uvádí jeho anglický překlad customer relationship management nebo zkratka CRM. 1

9 1. ÚVOD jsou začleňovány přímo do uživatelského rozhraní systému Dynamics CRM. Tyto webové aplikace jsou vytvářeny pomocí technologie Silverlight [3], což je produkt od společnosti Microsoft, který slouží pro vývoj a spouštění internetových aplikací s bohatým obsahem a funkcionalitou. Vývojem Silverlight aplikace, která rozšiřuje funkcionalitu systému Dynamics CRM, se zabývá i tato diplomová práce. Cílem práce je vytvořit aplikaci, která umožní automatické spouštění vybrané operace (v Dynamics CRM označované jako pracovní postup) nad množinou záznamů uložených v systému. Množina záznamů, nad nimiž se má pracovní postup provést, je specifikována pomocí tzv. rozšířeného hledání. Rozšířené hledání vrací jako výsledek sadu záznamů, které splňují kritéria zadaná při definici rozšířeného hledání. Aplikace je vytvářena ve spolupráci s firmou GEMMA Systems 2 a její partnerskou společností Dynamica 3. Práce je rozčleněna do osmi kapitol. Po první, úvodní kapitole, následuje kapitola 2, která představuje řízení vztahů se zákazníky. Kapitola 3 popisuje technologii Microsoft Silverlight. Čtvrtá kapitola se zabývá systémem Microsoft Dynamics CRM. Zbylé kapitoly jsou věnovány vývoji vlastní aplikace. Pátá kapitola popisuje analýzu aplikace, šestá její návrh a kapitola 7 se zaměřuje na implementaci aplikace. Poslední kapitolou je závěr práce. 2 GEMMA Systems < 3 Dynamica < 2

10 2 Řízení vztahů se zákazníky Druhá kapitola podává vysvětlení pojmu řízení vztahů se zákazníky. Další sekce kapitoly se zaměřuje na využití informačních technologií v tomto oboru. Samostatná část sekce je věnována internetovým aplikacím. 2.1 Charakteristika řízení vztahů se zákazníky Řízení vztahů se zákazníky je interaktivní proces, jehož cílem je dosažení optimální rovnováhy mezi firemní investicí a uspokojováním zákaznických potřeb. Optimum rovnováhy nastává tehdy, když ve vztahu mezi firmou a zákazníkem dosahují obě strany maximálního zisku. Předpokladem pro nastolení této rovnováhy je vytvoření partnerského vztahu se zákazníky. Dlouhodobý partnerský vztah se zákazníkem vyžaduje trvalé odhalování zákaznických potřeb, motivací a zvyků a využívání těchto znalostí při inovaci nabídky [4]. Místo pojmu řízení vztahů se zákazníky se často používá i jeho anglického překladu customer relationship management nebo zkratky CRM. Pro vybudování kvalitního partnerského vztahu se zákazníky může být potřebné značné úsilí a dostatečné peněžní investice. I přesto mnoho společností neváhá vložit své prostředky do CRM, protože na získání a udržení zákazníků závisí celkový úspěch podniku. Řízení vztahů se zákazníky klade důraz na získání loajality zákazníků tak, aby se k firmě znovu a rádi vraceli. Dlouhodobí zákazníci mají tendenci nakupovat více, jejich chování se dá předvídat a jejich obsluha obvykle stojí méně, než je tomu u nových zákazníků. Navíc bývají méně citliví na změny cen a dále mohou firmě sloužit jako bezplatný nosič reklamy (ústní doporučení známým apod.). Udržování stálých zákazníků také ztěžuje konkurentům vstup na trh či rozšiřování jejich tržního podílu. Programy podporující věrnost zákazníků zahrnují širokou škálu možností, od časopisů pro zákazníky až po zvláštní nabídky a dárky. Věrnostní program se snaží člověka přesvědčit, aby využil služeb konkrétního prodejce na základě výhodné nabídky. Znalost zákazníka a jeho předchozí interakce s firmou (nákupy, projevení zájmu o určitý výrobek či službu) umožňuje efektivní oslovování zákazníků na základě zvláštních nabídek nebo informačních materiálů cílených na konkrétní zákaznickou skupinu [5]. Důležitou částí řízení vztahů se zákazníky je i sledování poznatků od uživatelů firemních výrobků a služeb. Na základě těchto poznatků může společnost své služby a produkty upravovat, odstraňovat jejich nedostatky nebo vytvářet výrobky na míru pro konkrétní zákazníky [6]. Každému kupujícímu může být např. nabídnut dotazník zjišťující, jak je spokojen s právě zakoupeným výrobkem. To dává zákazníkovi možnost vyjádřit svůj názor a jasně to naznačuje, že dodavateli nejde jen o pouhý akt koupě, ale o vytvoření vztahu se zákazníkem. 3

11 2. ŘÍZENÍ VZTAHŮ SE ZÁKAZNÍKY 2.2 Využití informačních technologií v řízení vztahů se zákazníky Podnikatelský svět se odjakživa snažil pečovat o zákazníky a poskytovat jim slevy a jiné stimuly. To, co je dnes jiné, je vysoká organizovanost způsobu, jakým se firmy snaží vytvářet a rozvíjet vztahy a loajalitu zákazníků. Když jde o získávání věrných zákazníků, klíč k úspěchu představují specializované softwarové CRM systémy. Ty obsahují databázi, v níž se ukládají veškeré podrobnosti o zákaznících. CRM systémy umožňují firmám oslovovat jejich cílové skupiny mnohem efektivněji [5]. V podniku také usnadňují spolupráci zaměstnanců, kteří přicházejí do kontaktu se zákazníkem. CRM systémy hrají velkou roli v analytické části řízení vztahů se zákazníky. Získaná data o zákaznících je třeba vhodně zpracovat, pomocí analýz mezi nimi najít souvislosti a získat na jejich základě nové znalosti. Díky analýzám lze získat důležité informace, například [7]: preference zákazníků nákupní zvyklosti sezónní výkyvy predikce vzory a trendy v chování zákazníků ziskovost či ztrátovost zákazníků S CRM systémy typicky pracuje více uživatelů, kteří mezi sebou potřebují sdílet data. Proto je nutné, aby byla databáze s údají o zákaznícich umístěna v serverové části systému. K této části se připojují klientské aplikace, které jsou uloženy v osobních počítačích uživatelů. Klientskou aplikací většinou bývá desktopová aplikace. Někteří poskytovatelé CRM systémů však implementují klientskou část jako webovou aplikaci. Touto cestou se vydává i systém Microsoft Dynamics CRM, jemuž se diplomová práce věnuje. Z tohoto důvodu je zbytek kapitoly věnován tématu webových aplikací a bohatých internetových aplikací Webové aplikace Jako webovou aplikaci označujeme tu aplikaci, která je spouštěna přes webový prohlížeč. Jinak řečeno, webová aplikace je webová stránka nebo její část, která kromě prezentace informací poskytuje i určitou funkcionalitu. Mezi tuto funkcionalitu můžeme zařadit různé formulářové aplikace, administrativní rozhraní či firemní a dokumentové portály [8]. 4

12 2. ŘÍZENÍ VZTAHŮ SE ZÁKAZNÍKY Možnosti klasické webové aplikace jsou omezené. Její grafická podoba je limitována možnostmi HTML a kaskádových stylů. Funkcionalita se implementuje buď na straně klientského počítače, typicky pomocí programovacího jazyka JavaScript, nebo na straně serveru. V JavaScriptu je obtížné implementovat funkce, které jsou běžné u desktopových aplikací, jako třeba přehrávání animací a videa nebo práce s trojrozměrnou grafikou [9]. Protipólem klasických webových aplikací jsou desktopové aplikace. Ty jsou bohaté na funkcionalitu a zároveň mohou mít rozmanité grafické uživatelské rozhraní. I přes nesporné výhody desktopových aplikací si webové aplikace získaly velkou popularitu. Tato popularita pramení zejména ze snadné distribuce webových aplikací (není potřeba nic instalovat) a z toho, že jsou dostupné na mnoha platformách a operačních systémech Bohaté internetové aplikace V dnešní době se setkáváme s aplikacemi, které se snaží kombinovat nejlepší vlastnosti webu s komfortem desktopových aplikací. Takovým aplikacím říkáme bohaté internetové aplikace [10]. Termín bohatá internetová aplikace je překladem anglického rich internet application (RIA) 1. Jako RIA se označují aplikace, které jsou součástí webové stránky a nabízejí vysoký podíl funkcionality, jinak běžný jen u desktopových aplikací. Příkladem funkcionality bohatých internetových aplikací je např. práce s webovou kamerou, provádění vizuálních úprav obrázků, spouštění animací či drag and drop (táhni a pusť) operace. RIA aplikace umožňuje vysokou interaktivitu s uživatelem a poskytuje mu bohaté grafické uživatelské rozhraní. Funkcionalita RIA aplikací je prováděna na straně klienta. Ke komunikaci s webovým serverem dochází před spuštěním aplikace, kdy je aplikace stažena ze serveru do klientského počítače, a poté jen tehdy, kdy aplikace musí zapsat data na server nebo získat data, která na klientském počítači nemá k dispozici. Aby bylo možno zaručit vysokou interaktivitu aplikací s uživateli, využívají RIA aplikace asynchronní komunikaci se serverem. Aplikace nekomunikuje se serverem přímo, ale využívá běhové prostředí, které odesílá požadavky, zpracovává odpovědi a následně je předává zpět aplikaci. Samotná aplikace není blokována čekáním na odpověď serveru a může v mezičase reagovat na požadavky uživatele [8]. Běhové prostředí pro RIA aplikace je tvořeno zásuvným modulem webového prohlížeče. To je nevýhoda většiny RIA aplikací nemá-li uživatel zásuvný modul instalovaný ve svém počítači nebo má tento modul blokovaný, nemůže RIA aplikaci spustit. Technologií pro tvorbu RIA aplikací je mnoho a každá technologie 1 Místo pojmu rich internet application některé zdroje uvádějí termín rich interactive application, viz např. [11]. 5

13 2. ŘÍZENÍ VZTAHŮ SE ZÁKAZNÍKY používá svůj zásuvný modul. Pro bezproblémové spouštění RIA aplikací tedy musí mít uživatel nainstalováno hned několik zásuvných modulů. Mezi prostředky pro tvorbu a spouštění RIA aplikací se řadí i nová verze značkovacího jazyka HTML HTML 5. Oproti předchozím verzím nabízí HTML 5 spoustu nových značek, které umožňují vytvářet bohaté internetové aplikace jen pomocí HTML elementů. Na rozdíl od ostatních RIA technologií, pro fungování HTML 5 není vyžadován žádný zásuvný modul, stačí jen samotný webový prohlížeč [12]. V tom spočívá hlavní výhoda HTML 5. Nevýhodou HTML 5 je, že dosud není plně implementováno ve všech webových prohlížečích. Dalším problémem je to, že modifikace jazyka HTML 5 musí být odsouhlaseny standardizační komisí. To znesnadňuje rychlou reakci na změny a nové požadavky [13]. Kromě již zmíněných HTML 5 a Microsoft Silverlight patří mezi další známé technologie pro tvorbu RIA aplikací Adobe Flash 2 nebo JavaFX 3. 2 Adobe Flash < 3 JavaFX < 6

14 3 Microsoft Silverlight Tato kapitola popisuje technologii Microsoft Silverlight, která slouží pro vývoj RIA aplikací. Nejprve jsou rozebrány vlastnosti a schopnosti této technologie. Zbylá část kapitoly se věnuje principům vývoje Silverlight aplikací s důrazem na způsob tvorby grafického uživatelského rozhraní a zápisu zdrojového kódu. 3.1 Popis technologie Microsoft Silverlight Microsoft Silverlight [3] je technologie pro tvorbu a spouštění RIA aplikací. Silverlight funguje na všech běžných webových prohlížečích v operačních systémech Microsoft Windows a Apple Mac OS X [11]. Operační systémy Linux nejsou Microsoft Silverlightem přímo podporovány, nicméně existuje projekt Moonlight, jehož úkolem je implementace Silverlightu pro platformu Linux [14]. Kromě webových aplikací lze pomocí Silverlightu vytvářet i aplikace pro mobilní telefony s operačním systémem Windows Phone. U webových aplikací může vývojář povolit jejich stažení do počítače uživatele. Stažené aplikace mohou běžet mimo webový prohlížeč, tedy jako klasické desktopové aplikace. Silverlight aplikace běžící mimo prohlížeč se označují jako out-of-browser (OOB) aplikace [11]. Ačkoli je Silverlight poměrně mladá technologie (první verze byla vydána v září roku 2007), existuje již ve své páté verzi, která vyšla v prosinci roku 2011 [15]. Aby mohl uživatel spouštět Silverlight aplikace, musí mít na svém počítači nainstalovaný zásuvný modul zvaný Silverlight plug-in (někdy se používá i název Silverlight player [16]). Tento modul lze zdarma stáhnout z webu Microsoftu (viz [3]). Součástí platformy Silverlight je.net Framework for Silverlight, což je podmnožina klasického.net Frameworku 1, specializovaná pro tvorbu RIA aplikací [17]. To s sebou přináší velkou výhodu pro programátory, kteří mají v oblibě některý z programovacích jazyků používaných pro tvorbu.net aplikací. Pro zápis zdrojového kódu Silverlight aplikace lze totiž využít stejné jazyky. Na výběr jsou např. jazyky C# a Visual Basic nebo i dynamický jazyk IronPython [11]. Zkompilovaná Silverlight aplikace je tvořena jedním souborem s příponou.xap. XAP soubor poté může být, společně s webovou stránkou, nasazen na webový server. Umístění aplikace do webové stránky je realizováno HTML tagem <object>, jak ukazuje následující úryvek HTML stránky: 1.NET Framework je platforma pro vývoj a spouštění aplikací pro Microsoft Windows. Umožňuje vyvíjet aplikace ve více programovacích jazycích (např. C#, Visual Basic). Aplikace běží ve virtuálním stroji, tím se.net Framework podobá platformě Java. < 7

15 3. MICROSOFT SILVERLIGHT <object data="data:application/x-silverlight-2," type="application/x-silverlight-2" width="100%" height="100%"> <param name="source" value="clientbin/mojeaplikace.xap"/>... </object> Pro zvýšení přehlednosti byly z HTML kódu v ukázce odebrány některé řádky. Podstatné je, že umístění aplikace je určeno hodnotou parametru source. Na závěr této podkapitoly je uveden výčet funkcionality a schopností, které může Silverlight aplikace mít [16, 18]: Přehrávání audia a videa v různých formátech, včetně videa s vysokým rozlišením. Spouštění 3D animací. Vizuální efekty (rotace, zrcadlové zobrazení, změna velikosti, rozostření) na komponentách tvořících grafické uživatelské rozhraní aplikace. Přístup k síti a využívání webových služeb. Tisk dokumentů, obrázků i snímků grafického uživatelského rozhraní aplikace. Ukládání aplikačních dat do speciálního umístění (tzv. isolated storage) na počítači uživatele. Přístup ke schránce (clipboard) operačního systému za účelem kopírování dat. 3.2 Grafické uživatelské rozhraní Silverlight aplikace Grafické uživatelské rozhraní (GUI Graphical User Interface) bývá poskládáno z předpřipravených částí, kterým se říká ovládací prvky nebo komponenty. Typickou komponentou je tlačítko, popisek či políčko pro zadání textu od uživatele. V Silverlightu jsou tyto komponenty nazývány Button, TextBlock a TextBox. Některé komponenty slouží jako nosiče jiných komponent. Takové komponenty označujeme jako kontejnerové komponenty (kontejnery) [19]. Použití kontejnerů umožňuje rozdělit grafické uživatelské rozhraní aplikace na jednotlivé části a do těchto části umísťovat související komponenty. S komponentami umístěnými v kontejnerové komponentě je možné manipulovat jako s jedním 8

16 3. MICROSOFT SILVERLIGHT celkem. Toho lze s výhodou využít při úpravách vzhledu aplikace. Je-li třeba změnit polohu komponent a jejich kontejneru, není nutné měnit polohu každé komponenty zvlášť. Stačí upravit polohu kontejnerové komponenty a poloha ostatních komponent v kontejneru se automaticky přizpůsobí. V Silverlightu existují tři kontejnerové komponenty [19]: Grid: mřížka vytvořená z řádků a sloupců. Komponenty se umísťují do jednotlivých políček, definovaných číslem řádku a sloupce. Velikost řádků a sloupců může být nastavena na pevnou číselnou hodnotu nebo se může automaticky měnit v závislosti na velikosti komponent do Gridu vložených. Canvas: používá se v případě, kdy není vhodné umísťovat komponenty do políček a místo toho je třeba přesně stanovit jejich vzdálenost od okrajů kontejneru. Další typické použití Canvasu je k přímému kreslení vektorové grafiky čar, křivek, elips, kruhů atd. StackPanel: tento kontejner skládá ovládací prvky do jedné linie, a to buď horizontálně nebo vertikálně. Komponenty ve StackPanelu jsou tedy umístěny v řadě vedle sebe nebo pod sebou. Grafické uživatelské rozhraní Silverlight aplikace je popsáno pomocí jazyka Extensible Application Markup Language (zkratka XAML, čti zeml). XAML je deklarativní jazyk založený na jazyce XML [13]. Jazyk XAML se dále používá pro popis pracovních postupů v Dynamics CRM. O popisování pracovních postupů pomocí jazyka XAML podrobněji pojednává podkapitola 5.4. GUI aplikace je tedy reprezentováno XAML dokumentem a jednotlivé komponenty jsou definovány jako elementy tohoto dokumentu. Komponenty, které jsou umístěny uvnitř kontejnerů, jsou v XAML dokumentu deklarovány jako vnitřní elementy uvnitř elementu představujícího kontejnerovou komponentu. Soubory s XAML definicí uživatelského rozhraní mají příponu.xaml. Kromě zmíněných kontejnerů Grid, Canvas a StackPanel existuje ještě kontejner UserControl. Ten se používá jako kořenový element XAML dokumentu a může obsahovat pouze jednu vnořenou komponentu, což typicky bývá další kontejnerová komponenta [20]. Každý element může mít atributy, které popisují vlastnosti příslušné komponenty. Mezi typické vlastnosti patří jméno komponenty (to je určeno atributem Name), barva pozadí komponenty (atribut Background) nebo text zobrazený v komponentě (atribut Text). Některé komponenty (např. Button) mohou kromě textu obsahovat i složitější objekty, např. obrázky. Takové komponenty nemají vlastnost Text, ale místo ní mají vlastnost Content. Hodnoty vlastností komponent jsou reprezentovány textovými řetězci, které se zapisují jako hodnoty atributů v XAML dokumentu. Některé složitější vlastnosti, které nelze vyjádřit jednoduchým textovým atributem, se popisují jako vnořené elementy uvnitř elementu komponenty. Příkladem takové složitější vlastnosti je 9

17 3. MICROSOFT SILVERLIGHT vlastnost RowDefinitions komponenty Grid. Tato vlastnost slouží pro definici jednotlivých řádků kontejneru Grid. Následující kód představuje XAML dokument popisující grafické uživatelské rozhraní velmi jednoduché aplikace, která zobrazuje jedno tlačítko s textem Pozdrav : <UserControl x:class="silverlightapplication3.mainpage" xmlns=" presentation" xmlns:x=" xmlns:d= " xmlns:mc=" markup-compatibility/2006" mc:ignorable="d" d:designheight="480" d:designwidth="640"> <Button Content="Pozdrav" Height="23" Name="button1" Width="75" /> </UserControl> Je vidět, že kořenovým elementem je kontejnerová komponenta UserControl, která obsahuje komponentu Button. Komponenta Button zobrazuje text Pozdrav, má jméno button1, výšku 23 pixelů a šířku 75 pixelů. V kořenovém elementu UserControl jsou definovány XML jmenné prostory (atributy začínající textem xmlns). Jmenné prostory umožňují řešit problémy s kolizemi názvů elementů. Může se stát, že vývojář uživatelského rozhraní chce použít dvě různé komponenty, jimž jejich tvůrci náhodou dali stejná jména. V tomto případě je nutné pro každou z komponent definovat v kořenovém elementu UserControl vlastní jmenný prostor a při uvádění názvu komponenty je třeba psát název společně s názvem jmenného prostoru. Atribut x:class v elementu UserControl uvádí odkaz na třídu, která obsahuje zdrojový kód s funkcionalitou související s uživatelským rozhraním (viz následující podkapitola). Jazyk XAML dovoluje vytvořit takovou definici GUI, která je velmi přehledná a snadno čitelná a spravovatelná. To je výhodou oproti klasickým technologiím jako Windows Forms 2 nebo Java Foundation Classes 3, které popisují grafické 2 Windows Forms technologie pro tvorbu desktopových aplikací s grafickým uživatelským rozhraním, součást.net Frameworku. Jedná se o starší řešení, kromě něj poskytuje.net Framework i modernější technologii WPF, zmiňovanou výše. < 3 Java Foundation Classes (JFC) technologie pro tvorbu desktopových aplikací s grafickým uživatelským rozhraním, součást platformy Java. 10

18 3. MICROSOFT SILVERLIGHT uživatelské rozhraní běžným zdrojovým kódem s využitím konstruktorů a atributů tříd [19]. Pro srovnání je uveden kód vytvářející tlačítko s nápisem, nejprve zapsaný v jazyce XAML, který se používá v technologii Silverlight: <Button Content="OK" Background="Red" /> Poté v jazyce C#, který lze použít pro popis GUI v technologii Windows Forms: this.button1 = new System.Windows.Forms.Button(); this.button1.backcolor = System.Drawing.Color.Red; this.button1.text = "OK"; Je samozřejmé, že existují vývojová prostředí s interaktivním návrhářem GUI, který umožňuje vytvářet grafické uživatelské rozhraní Silverlight aplikace jen s pomocí počítačové myši. Tvůrce uživatelského rozhraní si vybírá z nabídky komponent a umísťuje vybrané komponenty na plochu, která představuje GUI vytvářené aplikace. Tento postup je jistě rychlejší než přímé psaní XAML kódu. Přesto je výhodné se v jazyce XAML orientovat, protože provádění drobných modifikací uživatelského rozhraní lze často pohodlněji uskutečnit přepsáním XAML dokumentu než úpravou přes grafický návrhář GUI. 3.3 Zdrojový kód Silverlight aplikace Aplikace s grafickým uživatelským rozhraním využívají model událostmi řízeného programování. Událostmi řízené programování spočívá v tom, že programátor píše zdrojový kód, který se vykoná při výskytu určité události. Pod pojmem událost si lze představit akci, která souvisí s GUI a byla vyvolána uživatelem (např. kliknutí myši, stisknutí klávesy) nebo vznikla bez přičinění uživatele (např. bylo dokončeno načítání webové stránky) 4. Zdrojový kód v událostmi řízeném programování je tvořen metodami, které nazýváme reakce na událost. Tyto metody se přiřazují událostem a jsou vykonány ve chvíli, kdy dojde k výskytu dané události. Silverlight aplikace dbá na důsledné oddělení grafického uživatelského rozhraní od zdrojového kódu. Tohoto oddělení je dosaženo rozdělením GUI a zdrojového kódu do samostatných souborů. GUI je popsáno XAML dokumentem a je umístěno v souboru s příponou.xaml. V kořenovém elementu 4 Obecně řečeno, událost je mechanismus umožňující jednomu objektu signalizovat nějakou věc jinému objektu [21]. Proto událost nemusí vždy souviset s GUI, ale může ji použít např. objekt, který se stará o asynchronní získání dat ze serveru. Tento objekt pomocí události signalizuje druhému objektu, že byla data úspěšně získána. Druhý objekt pak při výskytu této události provede zpracování získaných dat. V událostmi řízeném programování je však nejtypičtější použití událostí právě v souvislosti s GUI. 11

19 3. MICROSOFT SILVERLIGHT dokumentu se nachází atribut x:class, který odkazuje na třídu, jež obsahuje reakce na události. Zdrojový kód, který je oddělený od grafického uživatelského rozhraní, se označuje jako kód v pozadí (code-behind) [9]. Aby aplikace poznala, která reakce patří ke konkrétní události, je nutno událost a reakci na ni propojit. Toto propojení je realizováno v XAML dokumentu. Má-li existovat reakce na událost pro určitou komponentu, pak součástí elementu, který tuto komponentu popisuje, musí být atribut s názvem události. Hodnotou tohoto atributu je název metody, která slouží jako reakce na událost. Tato metoda musí být umístěna ve třídě, na niž odkazuje atribut x:class v kořenovém elementu XAML dokumentu. Jako příklad je uvedena aplikace typu Hello world. Součástí XAML dokumentu je definice tlačítka s názvem button1, které má přiřazenu reakci na událost Click. Reakcí na tuto událost je metoda pojmenovaná button1_click: <Button Name="button1" Click="button1_Click" Content="Pozdrav" Height="23" Width="75" /> V souboru s kódem v pozadí tedy musí existovat metoda s názvem button1_click. Do těla této metody je zapsán kód, který zajistí zobrazení okna se zprávou Hello world! : private void button1_click(object sender, RoutedEventArgs e) { MessageBox.Show("Hello world!"); } Metoda button1_click se vyvolá vždy, když dojde ke kliknutí na tlačítko button1. 12

20 4 Microsoft Dynamics CRM Třetí kapitola se zaměřuje na systém pro řízení vztahů se zákazníky od společnosti Microsoft Microsoft Dynamics CRM. Tento systém je charakterizován z pohledu běžného uživatele i z pohledu vývojáře, pro nějž je nejzajímavější možnost rozšiřovat systém o vlastní aplikace. Dále je představeno rozšířené hledání a procesy, což jsou části systému Dynamics CRM, které přímo souvisí s aplikací, jejíž vývoj je cílem této diplomové práce. V závěru kapitoly jsou popsány možnosti využití Silverlight aplikací v tomto systému. 4.1 Charakteristika systému Microsoft Dynamics CRM Dynamics CRM je softwarový systém pro řízení vztahů se zákazníky od společnosti Microsoft. Jedná se o produkt z řady Microsoft Dynamics, což je sada řešení, kterými Microsoft pokrývá oblast podnikových aplikací [22]. První verze tohoto systému vznikla v roce 2003 a dostala název Microsoft Dynamics CRM 1.0 [23]. Zatím poslední verzí je Microsoft Dynamics CRM 2013 Fall. Ta byla vydána na konci roku Dynamics CRM je webová aplikace postavená na platformě.net Framework [24]. Microsoft nenabízí pro přístup k systému žádný specializovaný software. Jako klientské aplikace slouží programy, které jsou běžně používané mnoha společnostmi při provádění každodenních pracovních úkonů. Konkrétně lze pro přístup k Dynamics CRM použít tyto programy a zařízení [25]: Webový prohlížeč: Jsou podporovány prohlížeče Microsoft Internet Explorer 1, Mozilla Firefox 2, Google Chrome 3 a Apple Safari 4. Je třeba zadat URL adresu, která odkazuje na Microsoft Dynamics CRM server požadované organizace. Po provedení autentizace uživatelským jménem a heslem získá uživatel přístup k datům, která jsou mu prezentována formou webových stránek. ový klient Microsoft Outlook 5 : Aby mohl být Outlook používán jako klientská aplikace pro přístup k Dynamics CRM, je nutné do počítače uživatele instalovat doplněk Microsoft Dynamics CRM for Outlook 6. Poté již může práce s CRM systémem probíhat přímo z prostředí tohoto ového klienta. Navíc je možné využít existujících a v Outlooku již uložených kontaktů, úkolů 1 Microsoft Internet Explorer < 2 Mozilla Firefox < 3 Google Chrome < 4 Apple Safari < 5 Microsoft Outlook < 6 Microsoft Dynamics CRM for Outlook < details.aspx?id=27821> 13

21 4. MICROSOFT DYNAMICS CRM a schůzek a synchronizovat je s Dynamics CRM. Tím se každá změna provedená na těchto záznamech automaticky uloží do databáze na CRM serveru. A naopak, změny těchto dat v databázi systému Dynamics CRM jsou reflektovány v aplikaci Microsoft Outlook. Tablet nebo mobilní telefon s webovým prohlížečem: Postup pro připojení k Dynamics CRM je obdobný jako při přístupu přes webový prohlížeč v počítači. Microsoft Dynamics CRM aktivuje doplněk Mobile Express, který uživateli umožní pracovat se systémem pomocí zjednodušených webových stránek. Ty jsou upraveny tak, aby odpovídaly možnostem těch zařízení, které mají menší rozlišení obrazovky než klasický osobní počítač. Mobile Express je aktivován také v případě, kdy uživatel přistupuje k Dynamics CRM z běžného PC, ale používá nepodporovaný webový prohlížeč. I v tomto případě má tedy přístup k Dynamics CRM, i když s omezenými možnostmi. Vlastní klientská aplikace: Aplikace (typicky desktopová, ale může být i webová) vytvořená vývojářem softwaru. Komunikuje se serverem Dynamics CRM pomocí webových služeb. Jak bylo uvedeno výše, systém Dynamics CRM je koncipován jako webová aplikace. Výhodou tohoto přístupu je to, že uživatel není nucen instalovat na svůj počítač žádný další software a k údajům o svých zákaznících přistupuje pomocí aplikací, jejichž ovládání mu je většinou důvěrně známé. Nevýhodou je nutnost být při práci se systémem neustále připojen k síti (ať už k Internetu nebo jen k firemní intranetové síti). Tuto nevýhodu odstraňuje doplněk Microsoft Dynamics CRM for Outlook with Offline Access. Ten umožňuje práci se systémem prostřednictvím aplikace Outlook i v případě, že počítač uživatele není připojen k žádné síti a nemá tedy přístup k Dynamics CRM serveru. Před odpojením od sítě dá uživatel pokyn ke stažení potřebných dat z CRM databáze do lokálního úložiště na svém počítači. Dále pracuje bez připojení k síti se svými lokálními daty. Po opětovném připojení do sítě dojde k synchronizaci dat mezi lokálním úložištěm a databází na CRM serveru [24]. Podle umístění serverové části rozlišujeme následující dvě varianty nasazení systému Dynamics CRM [24]: Microsoft Dynamics CRM Online Microsoft Dynamics CRM on-premise Varianta Online využívá tzv. cloudové řešení. Systém je umístěn na serverech společnosti Microsoft a uživatelé k němu přistupují přes Internet. Při použití varianty on-premise je Dynamics CRM server součástí lokální sítě organizace, která systém používá. Organizace může povolit přístup buď pouze z lokální sítě nebo i vzdáleně přes Internet. Varianta on-premise umožňující 14

22 4. MICROSOFT DYNAMICS CRM i vzdálený přístup přes Internet bývá označována Microsoft Dynamics CRM Internet-Facing Deployment (IFD) [26]. Aktuálnost systému, tedy provádění aktualizací a přechodů na nové verze, zabezpečuje u varianty Online samotný Microsoft. U varianty on-premise je za aktuálnost zodpovědný zaměstnanec organizace, který však může zajistit aktuálnost nastavením automatických aktualizací [27]. Systém Microsoft Dynamics CRM lze z hlediska funkcionality rozčlenit do tří základních modulů [24]: Prodej: Zajišťuje správu kontaktů na zákazníky a firmy, evidenci faktur, nabídek a objednávek. Mezi analytické funkce modulu patří vyhledávání nejvýnosnějších zákazníků či sledování počtu zákazníků v jednotlivých geografických oblastech. Marketing: Tento modul eviduje uskutečněné nebo plánované marketingové akce a umožňuje vyhodnocovat jejich úspěšnost (např. na základě množství nových zákazníků získaných díky kampani nebo podle výnosů plynoucích z těchto zákazníků). Služby: Umožňuje ukládat zákaznické požadavky (podněty, stížnosti, reklamace), analyzovat úspěšnost jejich řešení a sledovat počty požadavků za časové období. Modul podporuje vytváření znalostní báze, která obsahuje články s popisem problémů a jejich řešení. Znalostní báze umožňuje sdílení článků mezi pracovníky servisní podpory, kteří tak mohou rychle reagovat na opakovaně se vyskytující potíže. Základním stavebním kamenem datového modelu Dynamics CRM jsou entity. Entita je datový kontejner, který slouží pro ukládání objektů stejného typu. Entitu si lze tedy představit jako jednu nebo více tabulek v relační databázi [28]. Příklady entit v systému Microsoft Dynamics CRM jsou Kontakt, Smlouva či Telefonní hovor (ukládá informace o uskutečněných telefonních hovorech). Jednotlivé ukládané objekty (tj. výskyty entit) se nazývají záznamy. Každý záznam je jednoznačně identifikován pomocí svého ID. ID má tvar tzv. GUIDu (Globally Unique Identificator), což je 128 bitový číselný identifikátor [29]. Záznamy mají vždy jednoho vlastníka. Vlastníkem záznamu je uživatel, který jej vytvořil, nebo uživatel, jemuž byl záznam přidělen. Entita se skládá z množiny elementárních datových položek, tzv. atributů. Atribut 7 popisuje určitou vlastnost entity. Jako příklad je uvedena entita Kontakt, která slouží pro evidenci kontaktů na zákazníky nebo na kontaktní osoby ze spolupracujících či konkurenčních firem. Tato entita obsahuje (mimo jiné) textové atributy Křestní jméno, Příjmení či nebo číselný atribut Počet dětí. Mezi některými dvojicemi entit může existovat spojení. Toto spojení se v Dynamics CRM nazývá vztah. Například entita Kontakt má vztah s entitou 7 Místo pojmu atribut se mnohdy používá významově stejný termín pole [24]. 15

23 4. MICROSOFT DYNAMICS CRM Měna. Tento vztah přiřazuje každému záznamu typu Kontakt jeden záznam typu Měna. Tento záznam představuje primární měnu, kterou daný kontakt používá. Běžná práce se systémem Microsoft Dynamics CRM spočívá ve vytváření a mazání záznamů a v modifikaci hodnot atributů. Záznamy se otevírají v samostatných oknech, tzv. formulářích entity. Hodnoty atributů aktuálně otevřeného záznamu mohou být zobrazeny na formuláři jako jeho políčka. 4.2 Rozšířené hledání V systému Dynamics CRM může být uloženo velké množství záznamů a pro uživatele je často obtížné najít mezi nimi ten správný. Proto Dynamics CRM obsahuje techniku pro hledání záznamů podle zadaných kritérií. Nejjednodušším způsobem, jak hledat záznamy, je rychlé hledání (quick find) [24]. Při tomto způsobu hledání uživatel zapíše text do políčka, které se nachází nad seznamem záznamů konkrétní entity. Výsledkem rychlého hledání jsou ty záznamy dané entity, které v některém ze svých atributů obsahují zadaný text. Rychlé hledání nemusí být vždy postačující. Např. pokud chce uživatel hledat objednávky, jejichž celková částka se pohybuje v rozmezí od Kč do Kč, rychlé hledání mu pro tento dotaz nebude stačit. V takovém případě je nutné využít rozšířené hledání (advanced find). Rozšířené hledání je dotaz do databáze CRM systému, jehož výsledkem je množina záznamů, které splňují kritéria dotazu. Specifikace kritérií spočívá ve stanovení atributu entity, operátoru a hodnoty atributu. Nejčastěji používaným operátorem je operátor je rovno. Pomocí něj je určeno, že ve výsledku hledání mají být záznamy, které mají hodnotu daného atributu rovnu zadané hodnotě. Dalšími operátory jsou není rovno, menší než, větší než atd. Pro jedno rozšířené hledání lze stanovit více kritérií a určit, zda výsledné záznamy mají splňovat všechna kritéria nebo mají splňovat alespoň jedno kritérium. U rozšířeného hledání se vždy určuje entita, jejíž záznamy má hledání vracet. Tato entita se označuje jako primární entita. Není povoleno, aby hledání vracelo záznamy pro více různých entit. Dotazy rozšířeného hledání je možné ukládat do systému Dynamics CRM pro pozdější použití. Uživatel tak nemusí znovu definovat kritéria vyhledávání. Výsledky hledání budou odpovídat aktuálním datům v systému. Rozšířené hledání lze uložit buď jako záznam pro entitu Uložené zobrazení (v angličtině User query ), nebo jako záznam pro entitu Zobrazení ( Saved query ). Zobrazení je entita, jejíž záznamy jsou dostupné všem uživatelům Dynamics CRM. Uložené zobrazení je osobní uživatelský dotaz, ke kterému má přístup jen daný uživatel. 16

24 4. MICROSOFT DYNAMICS CRM Bude-li v dalším textu potřeba odkázat na obě entity zároveň, místo výrazu Zobrazení nebo Uložené zobrazení se bude obvykle používat jednodušší termín uložený dotaz. 4.3 Procesy Termín podnikový proces značí skupinu činností, transformujících souhrn vstupů do souhrnu výstupů pro jiné osoby nebo procesy [30]. Dynamics CRM obsahuje entitu Proces. Tato entita představuje funkcionalitu, která se spouští nad záznamy v systému, a umožňuje automatizovat podnikové procesy. V Dynamics CRM existují dva druhy procesů: Pracovní postupy Dialogy Pracovní postupy (anglicky workflow) se spouští buď na pokyn uživatele, nebo automaticky při výskytu určité systémové události (např. vytvoření záznamu či změna hodnoty atributu). Pracovní postup probíhá samostatně a pro své dokončení nevyžaduje asistenci uživatele. Dialogy musí být spuštěny uživatelem. Při provádění funkcionality dialogu je potřebná interakce s uživatelem, který dialogu předává potřebné vstupy. Po vytvoření se proces nachází ve stavu Koncept. V tomto stavu je možné proces upravovat, ale není povoleno ho spouštět. Po dokončení úprav převede uživatel proces do stavu Aktivní. Po aktivaci je možné proces spouštět, ale není možné ho upravovat. Proces je možné znovu deaktivovat, tedy přejít ze stavu Aktivní zpět do stavu Koncept. Během vytváření procesu uživatel specifikuje, pro kterou entitu je proces určen. Proces je možné spouštět jen nad záznamy jednoho typu, tedy pro záznamy jedné entity. Uživatel dále zadá, jestli se jedná o okamžitý proces. Okamžitý proces lze spouštět kdykoli pomocí uživatelského požadavku. Pokud proces není okamžitý, pak se spouští automaticky při výskytu určité události. Tato událost se také nastaví při vytváření procesu. Procesy v Microsoft Dynamics CRM se skládají z kroků, které představují základní jednotku funkcionality procesu. Dynamics CRM podporuje tyto kroky: Akce: Operace, kterou proces provádí, např. vytvoření či úprava záznamu, spuštění jiného procesu, odeslání u atd. Fáze: Logické seskupení ostatních kroků, přispívá k přehlednosti rozsáhlejšího procesu. Podmínka: Specifikace logické podmínky a kroků, které se provedou jen tehdy, když je podmínka splněna. 17

25 4. MICROSOFT DYNAMICS CRM Alternativní větev podmínky: Uvedení kroků, které se provedou, pokud podmínka není splněna. Podmínka cyklu: Specifikace logické podmínky a kroků, které se provádějí tak dlouho, dokud platí daná podmínka. Vlastní akce: Umožňuje rozšířit systém Dynamics CRM o další akce, které běžně nejsou procesy podporovány. Vlastní akce jsou definovány zdrojovým kódem zapsaným v jazyku C# nebo Visual Basic [31]. Ukončení procesu: Umožňuje předčasně ukončit proces. Typicky se používá v jedné z podmínkových větví. Jednotlivé kroky procesů jsou v Dynamics CRM zobrazeny jako řádky textu, které kroky popisují. Jsou-li kroky součástí podmínky, pak je text, který je popisuje, odsazen. To přispívá k zpřehlednění popisu procesu. Okno pro manipulaci s pracovním procesem je uvedeno v příloze B. 4.4 Microsoft Dynamics CRM z pohledu vývojáře softwaru Dynamics CRM je generický produkt 8 prodávaný v mnoha zemích po celém světě. Obsahuje funkcionalitu, která umožňuje efektivní řízení vztahů se zákazníky. Tato funkcionalita však nemusí plně vyhovovat všem organizacím, které systém používají. Některé podniky mohou mít nestandardní požadavky, jež generický systém neumí splnit. Každá firma, která má systém Dynamics CRM implementován, však může měnit či rozšiřovat funkcionalitu této implementace a vytvořit tak aplikaci na míru svým potřebám. Z pohledu softwarového vývojáře lze na Microsoft Dynamics CRM pohlížet jako na aplikační rámec (framework), který je základem pro celý informační systém podniku [13]. Tento informační systém proto není nutné vyvíjet na zelené louce. Místo toho lze využít připravenou funkcionalitu, která je součástí Dynamics CRM. Rozšířením Dynamics CRM lze získat systém, jehož účelem není jen řízení vztahů se zákazníky, ale který umožňuje jakékoli řízení vztahů. Microsoft Dynamics CRM lze tedy využívat v mnoha institucích, jako jsou vzdělávací či zdravotnická zařízení, pro řízení vztahů se zaměstnanci, studenty nebo pacienty [33]. Jádro Dynamics CRM, které slouží jako základ pro vývoj rozšířeného systému, je nazýváno platforma xrm. Zkratku xrm lze chápat buď jako extended relationship management, tj. rozšířené řízení vztahů, nebo tak, že x představuje proměnnou a jedná se tedy o řízení jakýchkoli vztahů [34]. 8 Generický (též krabicový) softwarový produkt je vytvářen s úmyslem budoucí nabídky v běžné obchodní síti širokému spektru potenciálních zákazníků [32]. 18

26 4. MICROSOFT DYNAMICS CRM Platforma xrm obsahuje prostředky pro realizaci těch požadavků, které bývají společné pro většinu informačních systémů. Tvůrce rozšíření systému se tak může více soustředit na samotnou aplikační logiku. Mezi požadavky řešené přímo platformou patří ukládání a zobrazování dat a zajištění bezpečnosti systému. Po rozšíření systému o novou entitu je na základě atributů entity automaticky vygenerován formulář pro zobrazení záznamů této entity. Grafické uživatelské rozhraní formuláře je možné dále upravovat. Bezpečnost systému je zajištěna vestavěnými funkcemi pro správu uživatelských účtů a rolí, autentizaci uživatelů, řízení přístupu k datům a sdílení záznamů. K nejjednodušším úpravám systému se řadí změna zobrazovaných názvů entit a atributů. Další běžně prováděnou změnou je modifikace grafického uživatelského rozhraní formuláře. Je možné přesouvat, měnit velikost nebo skrývat formulářová pole. U jednotlivých polí lze nastavit povinné vyplnění nebo je naopak nastavit pouze pro čtení. Žádná z těchto změn nevyžaduje programování a lze je provádět přímo z prostředí klientské aplikace pro přístup k Dynamics CRM. Tyto úpravy tedy zvládne i běžný uživatel systému. Chce-li společnost používat Dynamics CRM k řízení i jiných vztahů než jen vztahů se zákazníky, pak se neobejde bez rozšíření systému o nové entity. Kromě vytváření nových entit je také možné přidávat nové atributy do entit stávajících. I tato rozšíření se vykonávají pomocí klientské aplikace. Jejich správné provedení však vyžaduje schopnost korektně zachytit požadavky na data a funkce potřebné v rozšířeném systému. Na základě těchto požadavků je nutno vytvořit vhodné entity, jejich atributy a vztahy s ostatními entitami. Pokud výše popsané změny nejsou pro organizaci dostatečné, může systém rozšířit pomocí vlastních knihoven, HTML stránek nebo aplikací. V této oblasti Microsoft Dynamics CRM podporuje následující rozšíření: Skripty: Knihovny funkcí, jejichž zdrojový kód je zapsán v jazyce JScript. Tento jazyk, vytvořený firmou Microsoft, je implementací známého skriptovacího jazyka JavaScript [35]. Skripty se typicky používají pro kontrolu či nastavení hodnot v polích na formuláři nebo pro podmíněné ukrývání a zobrazování polí. JScriptové funkce se registrují k událostem, které na formuláři mohou nastat (např. změna hodnoty pole, načtení nebo uložení záznamu) a slouží jako reakce na tyto události. K provádění skriptů dochází na straně klienta. Webové stránky: HTML dokumenty s vlastním obsahem. Mohou být umístěny uvnitř formuláře nebo v samostatném okně, které se zobrazí např. po stisku tlačítka na ribbonu. Plug-iny: Knihovny se zdrojovým kódem psaným v libovolném jazyku pro platformu.net (většinou C# nebo Visual Basic) [36]. Plug-iny, stejně jako skripty, slouží jako reakce na události, které vznikají v systému Dynamics CRM. Zatímco skripty reagují na události v klientské části systému, plug-iny se spouští při výskytu událostí na CRM serveru (vytvoření nebo 19

27 4. MICROSOFT DYNAMICS CRM smazání záznamu, převod zájemce na zákazníka atd.). Při tvorbě plug-inu je nutné specifikovat, pro jakou entitu a událost je určen. Vlastní akce v procesu: Knihovny, jejichž zdrojový kód a možnosti funkcionality jsou podobné jako u plug-inů. Na rozdíl od plug-inů neslouží jako reakce na události, ale využívají se jako součást procesů. Silverlight aplikace: Používají se v případě, kdy je nutné vytvořit rozšíření, jehož součástí je grafické uživatelské rozhraní. To skripty, plug-iny ani procesy neumožňují, a proto se v této situaci využívají Silverlight aplikace. Ty mohou být umístěny uvnitř formuláře entity nebo na samostatné webové stránce. 4.5 Využití Silverlightu v Microsoft Dynamics CRM Tato sekce popisuje způsob umístění Silverlight aplikace na Microsoft Dynamics CRM server. Poté se zaměřuje na dva běžné způsoby využití Silverlight aplikací v Dynamics CRM Zpřístupnění Silverlight aplikace v prostředí Dynamics CRM Poté, co programátor vytvořil Silverlight aplikaci, musí ji nahrát na CRM server. Nahrává se pouze zkompilovaná aplikace v podobě XAP souboru. Aby Silverlight aplikace mohla být používána v prostředí systému Dynamics CRM, musí být po nahrání umístěna na vhodný formulář, kde se bude zobrazovat. U tohoto formuláře se zvolí pozice aplikace a velikost zobrazovacího prostoru, který bude mít k dispozici. Toto nastavení se provádí prostřednictvím návrháře formulářů, který je součástí klientské aplikace pro přístup k Microsoft Dynamics CRM. Na formuláři je také možno nastavit vstupní parametry, které se Silverlight aplikaci předají při jejím spuštění. Tyto parametry se posílají jako jeden textový řetězec, takže o formátu (názvy a oddělovače parametrů) a způsobu zpracování parametrů se rozhoduje pouze na základě dohody mezi vývojářem a uživatelem aplikace. Vstupní parametry se typicky používají pro určení záznamu nebo atributu, s nímž má aplikace pracovat, či pro nastavení jiných iniciálních hodnot. Měnit hodnoty vstupních parametrů je možné pouze z prostředí návrháře formulářů. Tento způsob změn není příliš pohodlný, proto se jako vstupní parametry předávají jen ty údaje, které nevyžadují častou modifikaci. Aplikace umístěná na formuláři se stává nedílnou součástí tohoto formuláře. Jinou možností je zobrazit Silverlight aplikaci v samostatném okně. V tomto případě je nutné nahrát na Microsoft Dynamics CRM server i HTML stránku, která Silverlight aplikaci obsahuje. 20

28 4.5.2 Silverlight aplikace jako ovládací prvek na formuláři 4. MICROSOFT DYNAMICS CRM Pro každý atribut entity lze na formuláři snadno vytvořit ovládací prvek, který zobrazuje hodnotu atributu a umožňuje ji měnit. Druh ovládacího prvku závisí na typu atributu. Textové a číselné atributy se zobrazují v textovém poli, výčtové typy v seznamu položek s možností výběru. Atributy, jejichž hodnotou je odkaz na jiný záznam, používají textové pole s tlačítkem, které zobrazuje okno pro vyhledávání použitelných záznamů. Tyto základní ovládací prvky, poskytované přímo systémem Dynamics CRM, však nemusí vždy postačovat požadavkům uživatelů. Microsoft Dynamics CRM nemá ovládací prvky pro zobrazení dat se stromovou strukturou, nastavení číselné hodnoty pomocí posuvníku či textové pole s našeptáváním (pole, které automaticky vyhledává použitelné hodnoty podle aktuálně zadaného textu). Požaduje-li organizace, která používá systém Dynamics CRM, některý z nestandardních ovládacích prvků, je možné využít právě Silverlightu. Ten obsahuje několik desítek komponent, které lze použít pro vytvoření grafického uživatelského rozhraní. Silverlight aplikace, která má sloužit jako ovládací prvek na formuláři, je obvykle tvořena pouze jedinou komponentou. Nutností je propojit Silverlight komponentu s atributem entity, jehož hodnotu má komponenta zobrazovat a nastavovat. K tomuto účelu se používají funkce z programovacího rozhraní Xrm.Page. Silverlight aplikace umístěná na formuláři může pomocí tohoto rozhraní získat a nastavit hodnoty všech atributů záznamu, který je na formuláři zobrazen [13]. Zdrojový kód, který přistupuje k rozhraní Xrm.Page, musí být zapsán v programovacím jazyku JScript. To však pro Silverlight aplikace nepředstavuje problém, protože Silverlight podporuje vyhodnocování JScriptového kódu. Protože Silverlight i JScript pracují na straně klienta, přístup k rozhraní Xrm.Page je prováděn synchronně a Silverlight aplikace má okamžitě k dispozici požadovaná data Komplexní Silverlight aplikace v Dynamics CRM Tento typ aplikace se používá v případech, kdy požadavky na rozšíření systému není možné splnit pomocí jiných způsobů řešení, jako jsou pluginy nebo procesy. Komplexní Silverlight aplikace má bohaté grafické uživatelské rozhraní, které umožňuje prezentovat výsledky činnosti aplikace v uživatelsky přívětivé podobě. Typická komplexní Silverlight aplikace komunikuje s Dynamics CRM serverem pomocí webových služeb. Často provádí zřetězené volání metod webových služeb, kdy jsou jednotlivá volání prováděny současně nebo navazují jedno na druhé. Webová služba je softwarová aplikace identifikovaná prostřednictvím URI (Uniform Resource Identifier adresa zdroje dostupného na Internetu či 21

29 4. MICROSOFT DYNAMICS CRM intranetu). Podporuje přímou interakci s jinými softwarovými aplikacemi prostřednictvím zpráv zapsaných v jazyku XML a přenášených protokoly Internetu [19]. Protože volání metod webových služeb ze Silverlight aplikace je prováděno asynchronně z klientské části systému do serverové části, není možno zajistit, aby byl výsledek volání k dispozici hned po realizaci volání. Aplikace tedy musí obsahovat mechanismus, který ji informuje o příchodu odpovědi na volání webové služby. Tímto mechanismem je tzv. zpětné volání (callback). Zpětné volání je funkce, která se provádí po obdržení odpovědi ze serveru. Tato funkce umožňuje zpracovat výsledky získané z webové služby. Microsoft Dynamics CRM obsahuje dvě webové služby, a to Organization Service a Organization Data Service. První služba komunikuje prostřednictvím protokolu SOAP, ta druhá pomocí protokolu REST [13]. Komunikace založená na protokolu SOAP je realizována obousměrným zasíláním zpráv ve formátu XML. U protokolu REST (Representational State Transfer) je každá metoda webové služby považována za zdroj, který má jednoznačný URI identifikátor. Klient tedy vyjadřuje své požadavky na webovou službu pouze uvedením URI a nemusí posílat celou XML zprávu [18]. Dynamics CRM vystavuje WSDL (Web Service Description Language) dokument, který popisuje metody, jež služba poskytuje, a datové objekty, které lze předávat do služeb a ze služeb [18]. Některá vývojová prostředí umožňují z WSDL dokumentu generovat zdrojový kód, který lze použít pro volání webových služeb. Účelem takového kódu je zapouzdřit složitou komunikaci založenou na XML a umožnit práci s webovými službami pomocí běžných objektů. Vygenerovaný zdrojový kód se bude lišit podle použité webové služby. Webová služba Organization Data Service, která je založena na REST, podporuje datový model s brzkou vazbou (early bound). Při použití tohoto datového modelu se vygeneruje samostatná třída pro každou entitu v systému Dynamics CRM. Webová služba Organization Service, založená na SOAP, podporuje datový model s pozdní vazbou (late bound). Tento datový model obsahuje jen jednu třídu, která má název Entity. Tato třída je používána pro reprezentaci všech entit v CRM systému. Použití brzké vazby je pro vývojáře pohodlnější, avšak vede k vytvoření XAP souboru, jehož velikost je několikanásobně větší než velikost XAP souboru při použití pozdní vazby. 22

30 5 Analýza aplikace Tato kapitola již popisuje tvorbu vlastní aplikace. Nejprve se zaměřuje na požadavky, které jsou na aplikaci kladeny budoucími uživateli. Požadavky jsou zapsány volným textem a poté shrnuty ve formě diagramu případů užití. Na základě požadavků jsou zvoleny vhodné technologie pro tvorbu aplikace. Další podkapitola se věnuje rozboru struktury XAML dokumentu, z něhož bude program generovat procesní diagramy. 5.1 Požadavky na aplikaci Cílem praktické části této diplomové práce je vytvoření aplikace, která rozšíří funkcionalitu systému Microsoft Dynamics CRM. Aplikace bude začleněna do klientské části CRM systému. Vzhled jejích ovládacích prvků tedy musí odpovídat grafickému uživatelskému rozhraní Dynamics CRM. Rozšiřující aplikace usnadní manipulaci s pracovními postupy. Na program jsou kladeny dva hlavní požadavky, a to umožnění automatizovaného spouštění pracovního postupu nad libovolným počtem záznamů a zobrazení pracovního postupu formou diagramu. Dále bude podporováno provádění některých operací se záznamy přímo z prostředí aplikace. Uživatel tak nemusí přecházet mezi různými částmi CRM systému. Všechny důležité činnosti, které souvisí se správou pracovních postupů, může vykonávat pomocí této aplikace Spouštění pracovního postupu nad libovolným počtem záznamů Organizace, která používá Dynamics CRM, může mít v systému uloženy tisíce záznamů jedné entity. Chce-li uživatel spustit proces nad všemi záznamy dané entity, narazí na omezení Dynamics CRM, které neumí současně zobrazit více než 250 záznamů. Uživatel tedy musí spustit proces nad částí záznamů, poté přejít na další stránku výsledků hledání a tento postup opakovat, dokud nedojde ke spuštění procesu nad všemi požadovanými záznamy. V případě velkého počtu záznamů je tato procedura značně zdlouhavá. Nejzásadnějším požadavkem na vytvářenou aplikaci je odstranění zmíněného omezení. Aplikace umožní provádět proces současně nad všemi vybranými záznamy bez ohledu na jejich počet. Je předpokládáno, že hlavním využitím aplikace bude dávkové provádění procesů nad velkým množstvím záznamů. Provádění by mělo být co nejvíce automatizované a mělo by vyžadovat minimum uživatelských zásahů. Z toho důvodu nebude aplikace pracovat s oběma druhy procesů. Podporovány budou pouze pracovní postupy, a nikoli dialogy. Dialogy při svém běhu nad každým 23

31 5. ANALÝZA APLIKACE záznamem vyžadují interakci s uživatelem, což není v tomto typu programu vhodné. Aplikace bude graficky prezentovat celkový postup provádění. Z aplikačního GUI musí být patrné, jaké procento záznamů již bylo dokončeno, tj. nad kolika procenty záznamů už skončil běh pracovního postupu. Také se bude zobrazovat seznam všech záznamů, nad nimiž je pracovní postup spuštěn. Pro každý záznam bude uveden stav provádění pracovního postupu (provádění nad záznamem probíhá, provádění nad záznamem bylo dokončeno). Program musí vědět, který pracovní postup chce uživatel spustit. Dále musí znát množinu záznamů, nad nimiž se má pracovní postup provést. Seznam záznamů není určen přímo, ale je definován pomocí zobrazení nebo uživatelského zobrazení. Pracovní postup tedy proběhne nad těmi záznamy, které jsou vráceny jako výsledek daného uloženého dotazu. Informace o pracovním postupu a uloženém dotazu jsou aplikaci předány prostřednictvím vstupních parametrů (v případě, že je aplikace umístěna na formuláři entity) nebo query stringu 1 v URL adrese (pokud je aplikace součástí vlastní HTML stránky). Předává se ID pracovního postupu a ID uloženého dotazu. Třetím parametrem je typ uloženého dotazu, tedy informace, zda uloženým dotazem je záznam pro entitu Zobrazení nebo Uložené zobrazení. Předávání parametrů bude nepovinné. Pokud některý z parametrů nebude vyplněn nebo bude chybný (špatné jméno parametru, ID má nesprávný tvar nebo neodpovídá žádnému záznamu), aplikace nabídne možnost výběru potřebného záznamu pomocí svého uživatelského rozhraní. Volba záznamu prostřednictvím GUI aplikace bude realizována tabulkou, jejíž vzhled bude odpovídat tabulkám pro výběr záznamů v systému Microsoft Dynamics CRM. Tabulky v Dynamics CRM obsahují ve své horní části lištu s tlačítky. Systémová tabulka s tlačítky dovoluje zobrazovat, modifikovat a mazat vybrané záznamy a vytvářet záznamy nové. Uvedené operace bude podporovat i tato rozšiřující aplikace. Tabulka pro výběr uloženého dotazu bude dle volby uživatele nabízet buď seznam všech zobrazení nebo seznam všech uložených zobrazení. V tomto seznamu se budou nacházet zobrazení či uložená zobrazení s libovolnou primární entitou. Tím vznikne další rozšíření původního systému. Microsoft Dynamics CRM totiž dovoluje v jedné tabulce zobrazit jen ty uložené dotazy, které mají stejnou primární entitu. Systém Dynamics CRM se skládá z několika desítek entit a pro mnoho entit existuje několik zobrazení. Z toho důvodu je tabulka obsahující všechna zobrazení poměrně dlouhá. Proto bude uživateli nabídnuta i možnost zvolit konkrétní entitu. Tabulka v aplikaci pak bude obsahovat jen ty uložené dotazy, jejichž primární entita je stejná jako entita vybraná uživatelem. 1 Query string je textový řetězec na konci URL adresy, který slouží pro předávání parametrů. 24

32 5. ANALÝZA APLIKACE Pro libovolné zobrazení nebo uložené zobrazení bude aplikace umožňovat vrácení výsledků dotazu. Výsledek dotazu bude prezentován formou tabulky. Tímto způsobem si může uživatel před spuštěním pracovního postupu přímo v prostředí aplikace ověřit, nad kterými záznamy bude pracovní postup proveden. K výběru pracovního postupu bude sloužit obdobná tabulka jako pro volbu uloženého dotazu. Tabulka však nebude zobrazovat všechny pracovní postupy. Bude obsahovat jen ty postupy, které je možné spustit nad záznamy vrácenými jako výsledek zvoleného dotazu. V tabulce tedy budou umístěny pracovní postupy, které splňují následující dvě podmínky: Pracovní postup je ve stavu Aktivní. Pracovní postup je určen pro entitu, která je shodná s primární entitou vybraného zobrazení nebo uloženého zobrazení. Kromě běžných operací pro manipulaci se záznamy (vytvoření, otevření, úprava a mazání) bude aplikace dovolovat i deaktivaci pracovního postupu. Deaktivovaný pracovní postup již nebude obsažen v tabulce spustitelných postupů. Aktivace pracovních postupů nebude podporována. Deaktivované postupy program vůbec nezobrazuje, proto jejich aktivace z prostředí aplikace nemá smysl. Bude-li uživatel chtít pracovat s neaktivním pracovním postupem, musí nejprve v prostředí Dynamics CRM převést daný postup do stavu Aktivní. Během provádění pracovního postupu i po ukončení jeho činnosti bude umožněno vracet se k výběru uloženého dotazu a pracovního postupu. Uživatel může zvolit jiné zobrazení či uložené zobrazení a jiný pracovní postup a spustit jeho běh. Tímto způsobem lze provádět více různých pracovních postupů současně. Každý běh pracovního postupu bude mít vlastní komponenty v grafickém uživatelském rozhraní, které budou informovat o stavu provádění daného postupu Zobrazení pracovního postupu ve formě diagramu Dalším důležitým požadavkem na aplikaci je poskytnutí alternativní formy popisu pracovních postupů. Microsoft Dynamics CRM zobrazuje kroky pracovních postupů v textové podobě. Někteří uživatelé mohou považovat textový popis pracovního postupu za nepřehledný. Takovým uživatelům bude pravděpodobně více vyhovovat grafický popis postupu. Formu grafického popisu pracovních postupů nabídne vytvářená aplikace. Ta umožní zobrazit kroky pracovního postupu pomocí procesních diagramů. Konkrétně se bude jednat o dvě varianty diagramů, a to Activity Diagram a Business Process Diagram. Activity Diagram je součástí standardu UML (Unified Modeling Language), který obsahuje několik diagramů používaných především v softwarovém 25

33 5. ANALÝZA APLIKACE inženýrství. Business Process Diagram je definován standardem BPMN (Business Process Model and Notation). Tento standard se zaměřuje na podnikové procesy. Jeho hlavním cílem je poskytnout notaci, která by byla srozumitelná všem uživatelům podnikových procesů, od analytiků vytvářejících procesy až po manažery, kteří procesy řídí [37]. Zobrazený diagram pracovního postupu bude možné vytisknout nebo uložit do souboru v počítači uživatele. Bude povolen výběr z několika typů obrázkových souborů (JPEG, PNG, BMP). 5.2 Diagram případů užití Tato podkapitola shrnuje funkční požadavky na aplikaci pomocí UML diagramu případů užití. Ke každému případu užití je podán vysvětlující popis. Obr. 5.1: Diagram případů užití 26

34 5. ANALÝZA APLIKACE Spustit pracovní postup: Aplikace zpracuje vstupní parametry. Na vstupu by mělo být ID uloženého dotazu spolu s parametrem, který určuje, zda je dotazem zobrazení nebo uložené zobrazení. Pokud některý z parametrů chybí, aplikace zobrazí tabulku se všemi uloženými dotazy. Jestliže mezi vstupními parametry není ID pracovního postupu, objeví se po vybrání uloženého dotazu tabulka se seznamem použitelných postupů. Po určení uloženého dotazu a pracovního postupu dojde ke spuštění pracovního postupu nad záznamy, jež jsou výsledkem zvoleného dotazu. Zobrazit výsledky dotazu: Pokud uživatel vybere ze seznamu uložených dotazů jednu položku, může zobrazit záznamy, které jsou vráceny jako výsledek vybraného dotazu. CRUD dotaz: Případ užití CRUD (Create, Read, Update, Delete) dotaz umožňuje zobrazit kritéria vybraného uloženého dotazu (Read). Kritéria je možné modifikovat a poté uložit (Update). Dále lze vytvářet nové uložené dotazy (Create) a existující dotazy mazat (Delete). Změnit stav pracovního postupu: Deaktivuje vybraný pracovní postup, tj. změní jeho stav ze stavu Aktivní do stavu Koncept. CRUD pracovní postup: Umožňuje vytváření, zobrazování, úpravy a mazání pracovních postupů. Zobrazit diagram pracovního postupu: Po vybrání pracovního postupu ze seznamu se zobrazí diagram daného pracovního postupu. Uživatel zvolí jeden ze dvou typů diagramu. Uložit diagram pracovního postupu na disk: Uživatel zvolí umístění, jméno a typ souboru. Typ souboru může být PNG, JPEG nebo BMP. Poté dojde k uložení diagramu jako obrázku do vybraného umístění v počítači uživatele. Vytisknout diagram pracovního postupu: Uživatel nastaví parametry tisku, po potvrzení je zahájen tisk diagramu. 5.3 Výběr technologií pro tvorbu aplikace Vytvářená aplikace musí obsahovat bohaté grafické uživatelské rozhraní, aby mohla prezentovat výsledky provádění pracovních postupů a zobrazovat postupy jako procesní diagramy. Z uvedených faktů vyplývá, že pro vytvoření aplikace bude vhodné použít technologii Silverlight. Alternativně by bylo možné aplikaci vytvořit jako sadu HTML stránek využívajících kaskádové styly a JavaScriptové funkce. Tvorba takové aplikace by však byla v porovnání s vývojem pomocí Silverlightu příliš komplikovaná a těžkopádná. Součástí Silverlightu jsou třídy, které lze s výhodou použít ke zobrazení diagramů pracovních postupů. Jako základní plocha pro kreslení diagramu poslouží komponenta Canvas. Jednotlivé elementy diagramu budou vykreslovány 27

35 5. ANALÝZA APLIKACE pomocí tříd Rectangle 2 (kreslení obdélníků), Ellipse 3 (kreslení kruhů a elips) a Polyline 4 (kreslení lomených čar). Silverlight umožňuje tvorbu aplikací v libovolném programovacím jazyce, který je kompatibilní s platformou.net. Výběr jazyka tak závisí především na preferencích vývojáře, jeho znalostech a zkušenostech s jednotlivými jazyky. Pro tuto aplikaci byl zvolen programovací jazyk C#. Jedná se o moderní objektově orientovaný jazyk, který je pokračovatelem ve větvi jazyků C, C++, Java. To znamená, že poskytuje stejnou syntaxi základních programových konstruktů a dále zjednodušuje zápis a čitelnost zdrojového kódu, a to i v porovnání s jazykem Java. Oproti Javě nabízí jazyk C# více deklarativní přístup k programování, což lze s výhodou použít např. při manipulaci s kolekcemi (pole, seznam, zásobník, seznam dvojic klíč-hodnota). Kolekce není nutné procházet pomocí for cyklu. Je možné využít technologii LINQ. LINQ 5 (Language-Integrated Query) umožňuje vyhledávání v kolekcích pomocí dotazů, jejichž syntaxe se podobá syntaxi jazyka SQL (Structured Query Language). Tyto dotazy jsou začleněny přímo do zdrojového kódu psaného v jazyce C#. Aplikace bude komunikovat s Dynamics CRM serverem prostřednictvím webové služby Organization Service, která je založena na protokolu SOAP. Práce s RESTovou webovou službou Organization Data Service není možná, protože tato služba nepodporuje metody pro spouštění pracovních postupů [13]. Omezení kladené na použití služby Organization Service v Silverlight aplikacích implikuje výběr datového modelu. Povolen je jen datový model využívající pozdní vazby. Tak bude zaručeno udržení relativně malé velikosti výsledného XAP souboru. Tvorba aplikace proběhne pomocí integrovaného vývojového prostředí Microsoft Visual Studio Protože Dynamics CRM i Silverlight jsou produkty společnosti Microsoft, je volba tohoto vývojového prostředí logická. Visual Studio je základní nástroj pro tvorbu aplikací pomocí Microsoft technologií. Microsoft Visual Studio podporuje všechny fáze vývoje aplikace. Ve fázi analýzy a návrhu je použito pro tvorbu UML diagramu případů užití a UML diagramu tříd. Dále bude jeho prostřednictvím realizována implementace aplikace. Visual Studio umí generovat kostru zdrojového kódu z diagramu tříd. Při implementaci se také využije možnost generování zdrojového kódu z WSDL dokumentu, který popisuje webovou službu a je umístěn na Dynamics CRM serveru. 2 Rectangle < 3 Ellipse < 4 Polyline < 5 LINQ < 6 Microsoft Visual Studio < 28

36 5. ANALÝZA APLIKACE 5.4 Zpracování XAML dokumentu pro definici pracovního postupu V databázi systému Microsoft Dynamics CRM jsou definice pracovních postupů uloženy jako XAML dokumenty. Stejným způsobem jsou předávány do Silverlight aplikace, která o ně požádá CRM server pomocí metody webové služby. Po obdržení XAML dokumentu je nutné tento dokument zpracovat, získat z něj jednotlivé kroky pracovního postupu a ty pak zobrazit jako elementy procesního diagramu. Bylo uvažováno o dalším rozšíření funkcionality, kdy by aplikace umožnila editaci elementů v procesním diagramu. Poté by se změnil obsah XAML dokumentu a byl by uložen na CRM server. Tato funkcionalita je však povolena jen pro On-Premise nasazení systému a nikoli pro verzi Online [38]. To by vedlo k rozdílnému chování aplikace v různých nasazeních, a proto bylo rozhodnuto, že tato funkcionalita nebude implementována. Webový portál Microsoft Developer Network 7 obsahuje oficiální dokumentaci k vývoji rozšiřujících aplikací pro Dynamics CRM. V této dokumentaci však nebyl nalezen žádný ucelený popis struktury XAML dokumentu pro definici pracovních postupů. Dokumentace ani neuvádí, jaké XAML elementy odpovídají jednotlivým krokům postupu. Proto bylo nutné samostatně vytvářet pracovní postupy skládající se z různých typů kroků a poté zkoumat strukturu jejich XAML dokumentů. Výsledky zkoumání jsou uvedeny v této podkapitole. XAML dokument se skládá z elementů, které reprezentují kroky pracovního postupu. Podle těchto elementů bude aplikace vykreslovat procesní diagram. XAML dokument obsahuje také elementy a atributy, které slouží k upřesnění funkce jednotlivých kroků (např. elementy určující hodnoty atributů entity u akce pro vytvoření nového záznamu). Tyto elementy nelze prezentovat v procesním diagramu, a proto nebudou v následujícím textu rozebírány. Každý XAML dokument s definicí pracovního postupu začíná kořenovým elementem Activity. Elementy představující kroky pracovního postupu jsou umístěny uvnitř elementu mxswa:workflow. Kroky, které se skládají z dalších vnořených kroků (fáze, podmínková větev atd.) jsou vždy definovány elementem mxswa:activityreference. Konkrétní typ kroku určuje hodnota atributu AssemblyQualifiedName. Vnořené kroky jsou uvedeny v elementu sco:collection, který má nastaven atribut x:key na hodnotu Activities. Tento element je vnořeným elementem uvnitř elementu mxswa:activityreference. Pro popis podmínky a čekací podmínky je použit stejný element. Jde o element mxswa:activityreference, který má hodnotu atributu AssemblyQualifiedName vždy rovnu textu ConditionSequence. Uvnitř zmíněného elementu se nachází element mxswa:activityreference.arguments 7 Microsoft Developer Network < 29

37 5. ANALÝZA APLIKACE a v něm element InArgument s atributem x:key a hodnotou Wait. V tomto elementu je hodnota True nebo False. Ta určuje, jestli se jedná o čekací podmínku nebo o obyčejnou podmínku. Fungování podmínky je popsáno ve vnořeném elementu sco:collection. Uvnitř tohoto elementu se na prvních místech nacházejí elementy, které provádějí vyhodnocení podmínky. Ty nejsou z pohledu tvorby diagramu důležité. Za těmito elementy následuje jeden nebo dva elementy mxswa:activityreference s atributem AssemblyQualifiedName nastaveným na hodnotu ConditionBranch. Tyto elementy představují větve podmínky. Pokud není uveden druhý element, znamená to, že při nesplnění podmínky nejsou prováděny žádné kroky. Mezi dvěma zmíněnými elementy mxswa:activityreference se může opět nacházet několik elementů vyhodnocujících podmínku. V takovém případě se nejedná o krok KDYŽ TAK JINAK, ale o KDYŽ TAK JINAK KDYŽ. Každá větev podmínky je tvořena jedním krokem typu Fáze. Fáze je reprezentována elementem mxswa:activityreference, jehož atribut AssemblyQualifiedName má hodnotu Composite. Ve fázi jsou umístěny všechny kroky, které se v dané větvi provádí. Většina akcí je reprezentována elementem Sequence. Výjimkou je akce ukončení procesu, která je reprezentována elementem TerminateWorkflow. Každému druhu kroku pracovního postupu lze přiřadit element z procesního diagramu. Vyjadřovací schopnost procesních diagramů je velká a přesahuje schopnosti pracovních postupů v Dynamics CRM. Aplikace proto bude využívat jen podmnožinu elementů. 30

38 6 Návrh aplikace Tato kapitola se zabývá návrhem aplikace. Prezentuje diagram tříd, který bude sloužit jako základ pro implementaci aplikace, a grafické uživatelské rozhraní vytvářené aplikace. 6.1 Diagram tříd Na následujících stranách je popsán UML diagram tříd. Tato podkapitola vysvětluje účel tříd, jež jsou v diagramu zobrazeny. Kvůli svému velkému rozsahu je v textu uveden diagram jen s názvy tříd, bez atributů a operací. Dále je vybrána část diagramu, která reprezentuje třídy pro provádění pracovního postupu. Tato část je popsána podrobněji, včetně atributů a operací. Nejprve budou představeny třídy používané při provádění pracovního postupu. Některé z těchto tříd komunikují s webovou službou na serveru Dynamics CRM. Spojení se službou je zajištěno třídou WCFService. Metody tříd, které provádějí volání webové služby, jsou označeny koncovkou Async, jež naznačuje, že komunikace se službou probíhá asynchronně. Poté, co instance třídy obdrží odpověd od webové služby, vyvolá určitou událost. Na tuto událost mohou reagovat jiné objekty a dále zpracovávat odpověď služby. Na událost typicky reagují objekty z GUI části aplikace, které se starají o zobrazení výsledků získaných z webové služby. Tímto způsobem je zajištěna nezávislost výkonné části aplikace na GUI. Výkonná část nepoužívá žádnou komponentu z grafického uživatelského rozhraní. Pokud instance třídy potřebuje při vyvolání události předat určité údaje, pak pro událost existuje třída, která tyto údaje reprezentuje. Třída reprezenující data události má vždy koncovku EventArgs. Vlastní provádění pracovního postupu je realizováno třídou Runner. Ta obsahuje atributy, které popisují aktuální stav běhu pracovního postupu. Stav provádění postupu nad jednotlivými záznamy je uložen v kolekci instancí třídy RunOnRecordProgressInfo. Po dokončení provádění pracovního postupu nad všemi záznamy je vyvolána událost ProgressDone. Třída QueryManager slouží pro získání všech zobrazení nebo uložených zobrazení ze serveru Dynamics CRM. Zároveň je možné volat její metody, které vracejí jen uložené dotazy s konkrétní primární entitou. Primární entita je určena parametrem entitytypecode, což je číselný kód přiřazený každé entitě v Dynamics CRM. Konkrétní hodnoty kódu jsou získávány z CRM serveru pomocí třídy MetadataManager. 31

39 6. NÁVRH APLIKACE Obr. 6.1: Diagram tříd 32

40 6. NÁVRH APLIKACE Dalším úkolem třídy QueryManager je spouštění uložených dotazů. Vlastní provádění dotazu probíhá na Dynamics CRM serveru. Jakmile QueryManager dostane odpověď ze serveru, zpracuje získané výsledky a vyvolá událost RunQueryCompleted. Data této události jsou umístěna ve třídě RunQueryCompletedEventArgs. Data obsahují záznamy vrácené jako výsledek dotazu a názvy atributů, jež se mají ve výsledcích dotazu zobrazit. Pro reprezentaci pracovních postupů je určena třída Workflow. Nejdůležitějším atributem této třídy je atribut Xaml, který obsahuje XAML dokument s definicí kroků pracovního postupu. Třída WorkflowManager je obdobou třídy QueryManager. WorkflowManager se stará o získání všech pracovních postupů z Dynamics CRM serveru. Následuje popis tříd, jejichž úkolem je zobrazování pracovního postupu ve formě procesního diagramu. Třída XamlProcessor slouží pro převod XAML dokumentu definujícího pracovní postup na seznam elementů procesního diagramu. Prvky diagramu jsou popsány třídou DiagramElement a jejími potomky DiagramElementOneSuccessor a DiagramElementTwoSuccessors. Aby se zajistilo zobrazení elementů ve správném pořadí, které odpovídá postupnému provádění kroků pracovního postupu, pamatuje si každý element svého následníka. Třída DiagramElement obsahuje atributy společné pro všechny elementy a slouží pro reprezentaci elementů, které nemají žádného následníka. Takovým elementem může být pouze prvek pro ukončení činnosti procesu. Mezi atributy společné pro všechny elementy patří Shape (grafická podoba elementu, která je zobrazena na diagramu) a Type. Type určuje typ elementu. Všechny podporované typy elementu jsou definovány ve výčtu ElementType. Třída DiagramElementOneSuccessor je určena pro elementy s jedním následníkem a obsahuje atributy Successor a Description. Successor obsahuje odkaz na následníka elementu. Description je popis elementu, který se zobrazí na diagramu pracovního postupu. DiagramElementTwoSuccessors reprezentuje elementy se dvěma následníky. Takovým elementem je pouze element typu ConditionFork, který představuje začátek rozdělení procesu do dvou podmínkových větví. Třída má atribut SuccessorTrue, jenž odkazuje na první element ve větvi, která se vykoná, pokud podmínka bude vyhodnocena jako pravdivá. Atribut SuccessorFalse odkazuje na první element ve větvi provedené při vyhodnocení podmínky jako nepravdivé. Pokud proces nemá definovány žádné kroky prováděné při nesplnění podmínky, je hodnotou atributu SuccessorFalse element typu ConditionJoin, který představuje ukončení provádění podmínkové větve. 33

41 6. NÁVRH APLIKACE Obr. 6.2: Diagram tříd, část pro provádění pracovních postupů 34

42 6. NÁVRH APLIKACE Třída ActivityDiagramElementDrawer slouží pro vykreslování jednotlivých elementů UML Activity Diagramu. Třída BPDElementDrawer dělá totéž pro Business Process Diagram. Obě třídy implementují rozhraní (interface) IDiagramElementDrawer. Vykreslení celého diagramu je zajištěno třídou DiagramDrawer a její jedinou metodou Draw. Tato metoda dostává jako parametr instanci třídy, která implementuje rozhraní IDiagramElementDrawer, a tuto instanci používá pro vykreslení elementů diagramu. DiagramDrawer tedy nepřistupuje k objektu pro kreslení elementů přímo, ale přes rozhraní. To umožňuje snadné rozšíření aplikace o další druhy procesních diagramů. Stačí přidat novou třídu implementující rozhraní IDiagramElementDrawer. V dalších odstavcích bude vysvětlen význam zbylých tříd aplikace. Třída MetadataManager udržuje metadata jednotlivých entit. Metadata jsou informace o entitách. Jsou získávána ze serveru Dynamics CRM pomocí asynchronních metod této třídy. Metadata se ukládají do instancí třídy EntityMetadata. Aplikace potřebuje znát tato metadata: logické jméno entity (LogicalName) zobrazované jméno entity (DisplayName, liší se podle jazykového nastavení systému) číselný kód entity (ObjectTypeCode) jména atributů entity (AttributeNames) jméno atributu, který obsahuje ID záznamu (PrimaryIdAttribute) jméno atributu, který obsahuje název záznamu (PrimaryNameAttribute). Na diagramu jsou uvedeny čtyři třídy, které implementují rozhraní IValueConverter 9. To obsahuje metody pro konverzi dat mezi prezentační podobou (tj. způsobem zobrazení v GUI) a uloženou podobou (tj. reprezentací dat v operační paměti). EntityNameValueConverter převádí logické jméno entity na zobrazované jméno. Logické jméno entity je vnitřně používáno programem, např. jako hodnota atributu AssociatedEntityName třídy Query. Tento atribut určuje primární entitu dotazu. Uživatelské rozhraní však musí zobrazovat jméno entity v uživatelsky přívětivé podobě, která respektuje jazyk zvolený v nastavení CRM systému. Konvertor EntityNameValueConverter při převodu jmen entit používá údaje ze třídy EntityMetadata. 9 IValueConverter < 35

43 6. NÁVRH APLIKACE Třídy RunnerToTotalStateValueConverter a RunStateValueConverter konvertují informace o aktuálním stavu provádění pracovního postupu na text, kterým se tyto informace prezentují v GUI. Prvně jmenovaná třída provádí konverzi celkového stavu, který je v aplikaci určen atributem IsRunCompleted ve třídě Runner. Druhá převádí informace o stavu provádění nad jednotlivými záznamy. Tyto informace jsou získávány z atributu IsCompleted třídy RunOnRecordProgressInfo. Třída DataGridQueryResultLinePresenter reprezentuje řádek tabulky, která zobrazuje výsledky uloženého dotazu. Obsahuje seznam objektů nazvaný LineList, kde každý objekt představuje jednu buňku tabulky. Informace o aktuálním stavu grafického uživatelského rozhraní drží třída GuiManager. Pro účely této aplikace postačí informace o aktuálně zobrazovaném procesním diagramu. Tyto informace jsou využívány při ukládání diagramu do počítače uživatele. Třída DiagramPrinter se stará o práci s tiskárnou při tisku diagramu procesů. XrmHelper zajišťuje otevírání záznamů do Dynamics CRM formulářů za účelem jejich čtení nebo editace. Otevírání záznamů je prováděno prostřednictvím objektového modelu Xrm.Page. Třída AppManager realizuje návrhový vzor Fasáda (Facade). Tento vzor požaduje přítomnost třídy, jejíž úlohou je ukrýt složitou část systému a poskytnout jednotné rozhraní pro přístup k dané části. Tím se sníží počet tříd, se kterými musí okolí subsystému komunikovat [39]. AppManager skrývá třídy z výkonné části aplikace před objekty v grafickém uživatelském rozhraní. GUI tak volá jen metody třídy AppManager, která se stará o koordinaci činnosti ostatních tříd ve výkonné části programu. Dalším úkolem třídy AppManager je udržování informací o stavu aplikace. Třída si pamatuje aktuálně vybraný uložený dotaz, pracovní postup a všechny spuštěné nebo dokončené běhy pracovních postupů. Třída RunSelectedQueryCompletedEventArgs obsahuje data události RunSelectedQueryCompleted. Tato událost se vyvolá poté, co je dokončeno zpracování záznamů, které jsou vráceny jako výsledky uloženého dotazu, a záznamy jsou připraveny ke zobrazení. 6.2 Grafické uživatelské rozhraní aplikace Aplikace je složena ze čtyř základních obrazovek, které budou v této sekci postupně rozebrány. Obrazovky budou realizovány jako Silverlight stránky (komponenta Page 10 ). Navigaci mezi obrazovkami zajistí rámec Navigation Framework [16]. 10 Page < 36

44 6. NÁVRH APLIKACE Obrazovka pro výběr uloženého dotazu Když uživatel nezadá ID uloženého dotazu jako vstupní parametr, zobrazí se tato obrazovka hned po spuštění aplikace. Největší část obrazovky zabírá tabulka (komponenta DataGrid 11 ), která obsahuje záznamy pro entitu Zobrazení nebo Uložené zobrazení. O tom, který typ záznamů se zobrazí, rozhoduje uživatel výběrem položky z rozevíracího seznamu (komponenta ComboBox 12 ) s názvem Vybrat. Vedlejší seznam Pro entitu určuje, jestli se mají zobrazovat všechny uložené dotazy nebo jen dotazy vracející záznamy vybrané entity. Obr. 6.3: Obrazovka pro výběr uloženého dotazu Tabulka s uloženými zobrazeními obsahuje tyto sloupce (odpovídají atributům entity Uložené zobrazení): Název Entita (primární entita dotazu) Vlastník Naposledy změněno (datum a čas poslední modifikace záznamu) Výběr atributů entity, které bude tabulka obsahovat, byl proveden tak, aby odpovídal atributům, jež pro tuto entitu zobrazuje systém Dynamics CRM. Tabulka v aplikaci zobrazuje stejné sloupce i pro záznamy typu Zobrazení. Chybí 11 DataGrid < 12 ComboBox < 37

45 6. NÁVRH APLIKACE jen sloupec Vlastník, protože zobrazení nemají vlastníka a jsou dostupná celé organizaci. Tabulky v Dynamics CRM mají na začátku každého řádku zaškrtávací políčko. Pomocí tohoto políčka je možné vybrat více záznamů současně. Vyvíjená aplikace se snaží svým vzhledem odpovídat grafickému uživatelskému rozhraní systému Dynamics CRM. Přesto však ve svých tabulkách zmíněná zaškrtávací pole neobsahuje, protože současný výběr více záznamů není v aplikaci povolen. Uživatel může vždy vybrat jen jeden uložený dotaz, nad jehož výsledky se bude provádět jeden vybraný pracovní postup. Výběr záznamu se provede kliknutím myši do požadovaného řádku tabulky. Vybraný řádek je zvýrazněn modrou barvou. Nad tabulkami v Microsoft Dynamics CRM jsou umístěna tlačítka pro vytvoření nového záznamu a smazání vybraného záznamu. Systém nemá tlačítko pro modifikaci záznamu. Kliknutím na jméno záznamu (příp. dvojím kliknutím kdekoli do řádku tabulky nebo výběrem zaškrtávacího políčka a stisknutím klávesy Enter) dojde k otevření vybraného záznamu do nového okna. V tomto okně lze záznam modifikovat a změny uložit. Ve vyvíjené aplikaci bude vytváření, modifikace a mazání záznamů fungovat stejným způsobem. Pokud dojde ke smazání záznamu pomocí aplikace, automaticky se obnoví řádky tabulky a odstraněný záznam už nebude zobrazen. Když je ale záznam smazán v prostředí Dynamics CRM, aplikace se o této akci nedozví a záznam stále zobrazuje. V této situaci pomáhá tlačítko Obnovit, které slouží k aktualizování záznamů v tabulce. Vybral-li uživatel některé zobrazení či uživatelské zobrazení, stisknutím tlačítka Výsledky dotazu může spustit provádění uloženého dotazu. Výsledky se zobrazí v tabulce v samostatném okně. Jednotlivé záznamy výsledku lze otevřít do nového okna s CRM formulářem entity. Ve spodní části obrazovky se nachází odkaz (komponenta HyperlinkButton 13 ) Vybrat pracovní postup. Jakmile byl vybrán uložený dotaz, je možné tímto odkazem přejít na následující obrazovku Obrazovka pro výběr pracovního postupu Tato obrazovka se podobá předchozí obrazovce. Její hlavní částí je opět komponenta DataGrid, která tentokrát obsahuje seznam pracovních postupů. Jsou zobrazeny jen ty pracovní postupy, jež jsou kompatibilní s dotazem vybraným v předchozím kroku. Tabulka pracovních postupů je tvořena stejnými sloupci, jaké jsou zobrazeny v seznamu procesů v Dynamics CRM. Jedná se o název pracovního postupu, datum a čas jeho vytvoření, jméno vlastníka a jméno vlastnící organizační 13 HyperlinkButton < system.windows.controls.hyperlinkbutton(v=vs.95).aspx> 38

46 6. NÁVRH APLIKACE jednotky. Systém Microsoft Dynamics CRM navíc zobrazuje sloupce Stav, Typ procesu a Entita. Všechny pracovní postupy, které jsou obsažené v tabulce v aplikaci, mají tyto atributy nastavené na stejnou hodnotu. Proto byly tyto sloupce vynechány. Opět je možné vytvářet a mazat pracovní postupy a upravovat je v CRM formuláři. Tlačítkem Deaktivovat lze postup převést do stavu Koncept. Po deaktivaci pracovního postupu dojde k obnovení seznamu postupů. Deaktivovaný postup již není možné spustit, a proto se po obnovení nebude nacházet v tabulce pracovních postupů. Tlačítky Zobrazit Activity Diagram a Zobrazit Business Process Diagram se otevírá nového okno, v němž bude zobrazen pracovní postup v podobě zvoleného diagramu. Odkazem Zpět na výběr dotazu se lze navrátit na předchozí obrazovku a změnit vybrané zobrazení nebo uložené zobrazení. Po výběru pracovního postupu a kliknutí na odkaz Spustit provádění se změní obrazovka a začne provádění pracovního postupu nad záznamy Obrazovka zobrazující provádění pracovního postupu V horní části obrazovky se nachází seznam běhů pracovního postupu (komponenta ListBox 14 ). Pro každý dokončený nebo probíhající běh je v tomto seznamu vytvořena jedna položka. Je využito toho, že položky ListBoxu nemusí být jen textové, ale mohou obsahovat i jiné komponenty. Zde jsou položky tvořeny komponentou Grid, v níž jsou umístěny další komponenty pro zobrazení textu (procento dokončenosti běhu pracovního postupu a celkový stav provádění postupu) a komponenta ProgressBar 15 pro grafické vyjádření dokončenosti běhu pracovního postupu. Po kliknutí na některou položku v seznamu běhů se ve spodní části obrazovky objeví tabulka, která obsahuje detaily o vybraném běhu. Jsou zobrazena jména všech záznamů, nad nimiž byl pracovní postup spuštěn. U každého záznamu je uvedeno, zda provádění postupu nad záznamem stále probíhá nebo již bylo dokončeno. Prostřednictvím odkazu Zpět na výběr pracovního postupu je možné znovu zobrazit předchozí obrazovky, vybrat jiný pracovní postup a jiný uložený dotaz a poté spustit běh nově vybraného postupu. 14 ListBox < 15 ProgressBar < 39

47 6. NÁVRH APLIKACE Obrazovka s diagramem pracovního postupu K této obrazovce se lze dostat po stisknutí tlačítka pro zobrazení diagramu, které je umístěno na obrazovce pro výběr pracovního postupu. Obrazovka s diagramem se zobrazuje v novém okně (komponenta ChildWindow 16 ), které zabírá celou plochu vyhrazenou pro aplikaci a překrývá tak původně zobrazenou tabulku pro výběr pracovního postupu. Obr. 6.4: Obrazovka s diagramem pracovního postupu Tlačítkem Uložit lze vyvolat dialog pro uložení diagramu ve formě obrázkového souboru do uživatelova počítače. Tlačítko Tisk zobrazí dialog pro nastavení parametrů tisku a zašle diagram k vytištění na vybranou tiskárnu. 16 ChildWindow < system.windows.controls.childwindow(v=vs.95).aspx> 40

48 7 Implementace aplikace Předposlední kapitola se zabývá implementací aplikace. Jsou představeny tři významné implementační části, a to postup zpracování vstupních parametrů, získávání záznamů z CRM serveru a vykreslování procesních diagramů. Závěr kapitoly stručně popisuje testování aplikace. 7.1 Předávání vstupních parametrů Jak již bylo uvedeno v předchozích kapitolách, aplikace může obdržet až tři vstupní parametry. Bylo rozhodnuto o následujících jménech parametrů: queryid workflowid querytype Hodnotou prvních dvou parametrů je textová reprezentace ID záznamu ve formátu GUID. Tato reprezentace nemusí obsahovat úvodní ani koncovou závorku (znaky { a } ). Povinné je správné rozdělení skupin hexadecimálních číslic pomocí pomlčky. Hodnotou parametru querytype je buď text userquery (uloženým dotazem je Uložené zobrazení) nebo savedview (uloženým dotazem je Zobrazení). U jmen a hodnot parametrů nezáleží na velikosti písmen, protože všechny textové řetězce jsou převedeny na velká písmena pomocí metody String.ToUpper. Jako oddělovač jednotlivých parametrů se bude používat středník (;), oddělovačem jména a hodnoty parametru bude znak rovná se (=). Správně utvořený řetězec pro předání vstupních parametrů může mít např. tuto podobu (přechod na nový řádek byl vytvořen pro udržení přehlednosti textu, ve skutečném řetězci být nesmí): queryid={ abc}; workflowid={ ab-cdef abcdef}; querytype=userquery Pořadí vstupních parametrů není podstatné. Po obdržení řetězce provede aplikace jeho rozdělení na části metodou String.Split( ; ). Argument ; specifikuje, že řetězec bude rozdělen v místech, kde se nachází středník. V každé části řetězce bude vyhledán znak =. Podle tohoto znaku se část rozdělí na jméno a hodnotu parametru. Neodpovídá-li hodnota parametru určeným pravidlům, je daný parametr považován za nevyplněný. Pokud aplikace neobdrží parametr querytype, nelze použít ani hodnotu parametru queryid. 41

49 7. IMPLEMENTACE APLIKACE Kromě předávání vstupních parametrů textovým řetězcem, který se vyplňuje v návrháři formuláře entity, může aplikace přijmout parametry i přes query string v URL adrese. Tento způsob předávání se uplatní v případě, kdy je aplikace spouštěna ze samostatného okna s HTML stránkou. Pravidla pro oddělování parametrů se řídí principy pro tvorbu query stringu. Parametry jsou oddělovány znakem & a názvy parametrů se od svých hodnot oddělují znakem =. S vyplněním vstupních parametrů souvisí to, jaké aplikační obrazovky se budou uživateli zobrazovat. Pokud jsou správně vyplněny parametry queryid a querytype, pak se nezobrazuje obrazovka pro výběr uloženého dotazu, ale přechází se přímo na obrazovku pro výběr pracovního postupu. Když je vyplněn také parametr workflowid, je vynechána i tato obrazovka a rovnou se objeví obrazovka s prováděním pracovního postupu. 7.2 Získávání záznamů z Dynamics CRM serveru Do projektu s aplikací jsou začleněny dva soubory, které byly získány ze sady nástrojů pro tvorbu rozšíření Dynamics CRM (Microsoft Dynamics CRM Software Development Kit 1 ). Tyto soubory obsahují pomocné třídy, které zajišťují sestavení URL adresy webové služby na CRM serveru a řeší známé problémy se serializací v Silverlight aplikacích [13]. Data z Dynamics CRM serveru získává aplikace voláním metod webové služby Organization Service. Seznam uložených dotazů a pracovních postupů je obdržen pomocí metody RetrieveMultiple. Komunikace s webovou službou probíhá se zpožděním, které je způsobeno přenosem dat přes internetovou nebo intranetovou síť. Než jsou získány záznamy, je v aplikační tabulce zobrazen text Načítání... a animace s točícím se kolečkem. GUI čeká na výskyt událostí GetAllQueriesCompleted, případně GetAllQueriesFailed ze třídy AppManager. Po obdržení události GetAllQueriesCompleted jsou zobrazeny vrácené záznamy. Pokud místo této události přijde událost GetAllQueriesFailed, je zobrazeno chybové hlášení. Událost GetAllQueriesFailed oznamuje, že nebylo možné získat záznamy, ať už z důvodu nefunkčnosti CRM serveru nebo proto, že se klient nemůže připojit k síti. Se zpožděním se objevuje i seznam entit v ComboBoxu s názvem Pro entitu, který je umístěn na obrazovce pro získávání uložených dotazů. Po spuštění aplikace je v tomto seznamu jen jedna položka s textem Všechny entity. Metodou MetadataManager.LoadEntityMetadataAsync se provede načtení všech jmen entit z Dynamics CRM serveru. Během načítání uložených dotazů je možné měnit vybrané položky v ComboBoxu pro volbu typu dotazu (zobrazení, uživatelské zobrazení) a typu entity. S každou změnou dojde k zaslání požadavku na webovou službu. Protože 1 Dynamics CRM SDK < 42

50 7. IMPLEMENTACE APLIKACE odpovědi služby přicházejí se zpožděním, může se stát, že odpověď na požadavek přijde až poté, co byl vyslán požadavek nový. Odpovědi na staré požadavky je nutné ignorovat. Proto má třída AppManager atribut CurrentQueryManager. S každým požadavkem na získání uložených dotazů se do atributu ukládá nová instance třídy QueryManager. Při příchodu odpovědi webové služby se kontroluje, zda je QueryManager, který je spojen s touto odpovědí, roven aktuálnímu QueryManageru. 7.3 Vykreslování diagramu pracovního postupu Při vykreslování diagramu se jako první zpracuje XAML dokument definující kroky pracovního postupu. Zpracování zajišťuje metoda Process třídy XamlProcessor. Tato metoda vrací seznam jednotlivých elementů v pořadí, v jakém se budou vykreslovat. Každý element je umístěn do samostatné komponenty Canvas, která obsahuje grafickou podobu elementu. Jednotlivé komponenty jsou následně spojovány do větších celků, až vznikne jediná komponenta Canvas, která reprezentuje celý diagram. Každý diagram začíná elementem označujícím start procesu. Tento element je vykreslen jako první. Další prvky jsou postupně kresleny pod sebou a spojeny šipkou, která označuje pořadí provádění kroků. Takto probíhá generování diagramu až do chvíle, kdy je nalezen prvek pro vyhodnocení podmínky. Pod tento element se umístí element, který označuje rozdělení toku diagramu do dvou větví. Dále je nutné najít prvek, který reprezentuje opětovné spojení podmínkových větví, a element, který má tento prvek za následníka. Element, jehož následník je spojovací prvek, je posledním elementem v levé podmíněné větvi. Zbylé elementy patří do pravé větve. Pokud neexistují žádné zbylé elementy, znamená to, že proces neprovádí žádné kroky, jakmile je podmínka vyhodnocena jako nepravdivá. Vykreslení elementů v jednotlivých větvích probíhá postupně pod sebou, stejným rekurzivním způsobem, který byl popsán výše. Tak je možné vygenerovat diagram s libovolným počtem zanoření podmíněných kroků. Po vykreslení levé i pravé větve jsou obě části diagramu spojeny do jedné, která zobrazuje obě větve vedle sebe. Tato část je umístěna pod dosud vygenerovanou část diagramu. Dále jsou zakresleny šipky vedoucí od elementu pro rozdělení toku provádění k levé i pravé větvi. Poté je zakreslen element pro spojení podmínkových větví a šipky vedoucími k tomuto elementu z posledních elementů v obou větvích. Pokud pravá větev nemá žádné elementy, je zakreslena šipka vedoucí z elementu pro rozdělení provádění přímo do elementu pro spojení provádění. 43

51 7. IMPLEMENTACE APLIKACE Aby bylo možné uložit procesní diagram do počítače uživatele, je nutné převést komponentu Canvas, jež diagram zobrazuje, na proud bytů, který reprezentuje obrázkový soubor. Tuto operaci třídy Silverlightu nepodporují. Na internetu však existuje knihovna ImageTools for Silverlight, která tento problém řeší. Knihovna umožňuje ukládání souborů ve formátu PNG, JPEG a BMP [40]. 7.4 Testování aplikace Aplikace byla testována v systému Microsoft Dynamics CRM ve verzích 2011 a 2013 Fall. U obou verzí byla odzkoušena funkčnost aplikace v nasazení On- Premise i Online. V rámci testování bylo vytvořeno několik zobrazení a uživatelských zobrazení. Dále bylo vytvořeno několik pracovních postupů, jejichž kroky byly vybírány tak, aby se vyzkoušelo, že je aplikace schopna zobrazit jakýkoli krok ve formě procesního diagramu. 44

52 8 Závěr Aplikace byla úspěšně navrhnuta a implementována. Její funkcionalitu ocení organizace, které používají systém Dynamics CRM a potřebují provádět automatizované pracovní postupy nad velkým počtem záznamů. Takových organizací bude jistě mnoho. Nezáleží na zaměření organizace, provádění pracovních postupů je dosti obecné a využívané téměř u všech firem, které mají systém Dynamics CRM implementován. Velký potenciál skýtá oblast zobrazování a úprav pracovních postupů pomocí procesních diagramů. Do budoucna lze vytvořit verzi aplikace, která bude určena jen pro On-Premise nasazení. Tato aplikace by mohla obsahovat editor diagramu, který by dovolal mazat, upravovat a přidávat elementy diagramu. Také je možné z části aplikace pro zobrazování diagramů vytvořit samostatný program, který nabídne tuto zajímavou funkcionalitu bez závislosti na provádění pracovních postupů. Aplikaci je také možno rozšiřovat o další, ač méně známé, procesní diagramy. Standard BPMN popisuje převod Business Process Diagramu do formátu XML. I to je námět pro další rozšíření. 45

53 Literatura [1] STORBACKA, Kaj, Jarmo, LEHTINEN. Řízení vztahů se zákazníky. Praha: Grada, ISBN X. [2] Microsoft. Microsoft Dynamics CRM [online] [cit ]. Dostupné z: < [3] Microsoft. Microsoft Web: Silverlight [online] [cit ]. Dostupné z: < [4] LOŠŤÁKOVÁ, Hana. Diferencované řízení vztahů se zákazníky: moderní strategie růstu výkonnosti podniku. Praha: Grada, ISBN [5] CRAINER, Stuart. Moderní management: základní myšlenkové směry. Praha: Management Press, ISBN [6] PRAHALAD, C. K., Venkatram RAMASWAMY. Budoucnost konkurence: spoluvytváření jedinečné hodnoty se zákazníkem. Praha: Management Press, ISBN [7] HOMMEROVÁ, Dita. CRM v podnikových procesech. Praha: Grada, ISBN [8] Vysoká škola báňská technická univerzita Ostrava. Microsoft Silverlight: Lekce 1 Technologie a RIA [online] [cit ]. Dostupné z: < [9] MACDONALD, Matthew, Adam, FREEMAN, Mario, SZPUSZTA. ASP.NET 4 a C# 2010 tvorba dynamických stránek profesionálně, kniha 2. Brno: Zoner Press, ISBN [10] BERNARD, Borek. Adobe Flex: Kompletní průvodce tvorbou interaktivních aplikací. Brno: Computer Press, ISBN [11] Microsoft. Microsoft Developer Network: Silverlight Overview [online] [cit ]. Dostupné z: < bb404700(v=vs.95).aspx>. [12] LUBBERS, Peter, Brian, ALBERS, Frank, SALIM. HTML 5: Programujeme moderní webové aplikace. Brno: Computer Press, ISBN [13] YACK, David. Silverlight + CRM. We Speak You Learn, ISBN [14] Novell. Mono: Moonlight [online]. [cit ]. Dostupné z: < [15] Microsoft. Microsoft Silverlight Release History [online] [cit ]. Dostupné z: < details.aspx?id=12121>. [16] BERES, Jason, Bill, EVJEN, Devin, RADER. Professional Silverlight 4. Indianapolis: Willey Publishing, ISBN

54 [17] Microsoft. Microsoft Developer Network: Silverlight Architecture [online] [cit ]. Dostupné z: < bb404713(v=vs.95).aspx>. [18] PAPA, John. Silverlight datové služby. Brno: Zoner Press, ISBN [19] LACKO, Luboslav. Silverlight: Výukový průvodce tvorbou interaktivních aplikací. Brno: Computer Press, ISBN [20] Microsoft. Microsoft Developer Network: UserControl Class [online] [cit ]. Dostupné z: < system.windows.controls.usercontrol(v=vs.95).aspx>. [21] PETZOLD, Charles. Programování Microsoft Windows Forms v jazyce C#. Brno: Computer Press, ISBN [22]Microsoft. Microsoft Dynamics: Podniková řešení ERP a CRM [online] [cit ]. Dostupné z: < default.aspx>. [23] NLC-academy.net: Microsoft Dynamics CRM [online] [cit ]. Dostupné z: < [24] SNYDER, Mike, Jim, STEGER, Brendan, LANDERS. Microsoft Dynamics CRM 2011 Step by Step. Redmond: Microsoft Press, ISBN [25] Microsoft. Microsoft Developer Network: Microsoft Dynamics CRM 2011 web application and mobile device requirements [online] [cit ]. Dostupné z: < [26] GLASS, Jim. Internet-Facing Deployment (IFD) for Microsoft Dynamics CRM MSDN Blogs: A CRM Riff [online] [cit ]. Dostupné z: < internet-facing-deployment-ifd-for-microsoft-dynamics-crm-2011.aspx>. [27] Microsoft. Microsoft Developer Network: What Is Microsoft Dynamics CRM 2011? [online] [cit ]. Dostupné z: < en-us/library/gg aspx>. [28] Microsoft. Microsoft Developer Network: The Metadata and Data Models in Microsoft Dynamics CRM [online] [cit ]. Dostupné z: < [29] Microsoft. Microsoft Developer Network: Guid structure [online] [cit ]. Dostupné z: < system.guid.aspx>. [30] ŘEPA, Václav. Podnikové procesy: procesní řízení a modelování. 2., aktualizované a rozšířené vydání. Praha: Grada, ISBN [31] Microsoft. Microsoft Developer Network: Custom Workflow Activities (Workflow Assemblies) for Microsoft Dynamics CRM [online] [cit ]. Dostupné z: < [32] RÁČEK, Jaroslav. Strukturovaná analýza systémů. Brno: Masarykova univerzita, ISBN

55 [33] AbleBridge. XRM: Microsoft Dynamics CRM as a Platform [online] [cit ]. Dostupné z: < why-ablebridge-xrm-crm-platform.htm>. [34] McARTHUR, Shan. An Introduction to XRM for a.net Developer (Microsoft Dynamics CRM 4.0). Microsoft Developer Network [online] [cit ]. Dostupné z: < [35] AITKEN, Peter G. Windows Script Host 2.0: dávkové soubory pro Windows. Praha: Grada, ISBN [36] Microsoft. Microsoft Developer Network: Write a Plug-In [online] [cit ]. Dostupné z: < [37] Object Management Group. Business Process Model and Notation (BPMN) [online]. Version [cit ]. Dostupné z: < [38] Microsoft. Microsoft Developer Network: Custom XAML workflows [online] [cit ]. Dostupné z: < [39] PECINOVSKÝ, Rudolf. Návrhové vzory: 33 vzorových postupů pro objektové programování. Brno: Computer Press, ISBN [40] Microsoft. Codeplex:.NET Image Tools [online]. [cit ]. Dostupné z: < 48

56 A Hlavní okno systému Microsoft Dynamics CRM 49

57 B Okno pro manipulaci s pracovním postupem Toto okno je součástí Dynamics CRM. V jeho dolní části se nachází seznam kroků pracovního postupu. 50