Jednou z mnoha funkcionalit systémů SharePoint je možnost spouštět workflow nad položkami seznamů a knihoven dokumentů. Ač vestavěná worflow mohou představovat dobrý startovací bod, jejich mnohá omezení přeci jenom brání širšímu rozšíření pro náročnější aplikace. Jako v mnohých jiných případech dokázal i zde Microsoft udělat z této skutečnosti výhodu. Díky otevřenosti platformy SharePoint mohou „třetí strany“ (tedy celý svět mínus Microsoft) vyvinout vlastní doplňky, nebo celé systémy, které napravují nedostatky a nedodělky samotného SharePointu, a tyto systémy nabízet ať už zdarma, nebo s cílem na tom něco vydělat. Co to znamená pro nás, stavitele portálových řešení?
Do naprogramování rozšiřujících aktivit se můžeme pustit sami, pokud máme dostatečně masochistickou náladu, nebo můžeme využít plodů práce jiných, v podobě různých rozšíření „povalujících“ se po webu CodePlex a jinde. Anebo na to můžeme jít ještě jinak a můžeme využít sofistikovaných komerčních produktů.
Dobrým příkladem jsou produkty K2 z dílny jihoafrické společnosti SourceCode. Tato společnost má ve svém portfoliu i produkty K2 BlackPearl a K2 BlackPoint. Nebudeme se nyní zabývat přesnými rozdíly mezi nimi, stačí, když si uvedeme, že se v obou případech jedná o komplexní systémy pro návrh, běh a správu elektronických procesů a že BlackPearl je ten větší a BlackPoint ten menší (prostě Perla a Bod).
Asi by bylo dobré se krátce zamyslet nad tím, proč vůbec do podobných produktů investovat, neboť se téměř nikdy nejedná o „drobné“ a konec konců SharePoint přeci v sobě už nějaké workflow má. Je to jako se vším v IT. I zde především záleží na tom, jaký problém se chystáme řešit. Pokud nám jde o několik málo procesů na přímočaré schvalování dokumentů, pak dozajista nemá smysl utrácet za žádný workflow systém, vše, co potřebujeme, máme vestavěné v SharePointu, v nejhorším si pomůžeme SharePoint Designerem.
Pokud nám však jde o kompletní systém na schvalování faktur, kde předpokládáme složitou „routovací“ logiku, různá opakovaně vykonávaná schvalovací kolečka a – nedej Ballmer – i nějaké napojení na externí systémy, pak už se začneme malinko potit. A přidejme k tomu ještě požadavek z byznysu na grafy a různé statistiky, jak se to s těmi různými fakturami má, a požadavek z IT oddělení, aby bylo možné všechny procesy centrálně spravovat, a nezbyde, než si přiznat, že, děti moje, tohle nebude žádný malý problém.
Jistě, i zde můžeme nasadit univerzální filozofii všech zapřisáhlých programátorů „vždycky-je-lepší-si-to-od-začátku-sám-napsat“. A ani sám SharePoint se nebude vzpouzet, nakonec podporuje Workflow Foundation a vůbec, jakýkoliv .NET kód obecně. Pokud nás podobné myšlenky napadají, pak je dobré se realisticky pokusit odhadnout, kolik času, nervů a peněz nás to bude stát. Programovat si sami. A bude potřeba do toho nutného času započíst i údržbu tohoto systému, neboť pokud si něco naprogramujeme, je rozvoj a odstraňování chyb jen a jen náš boj.
Především se pak zamysleme se nad tím, jaký že to problém máme řešit. My si pamatujeme proces přijatých faktur, ne to, jak to naprogramuji, aby se úlohy ze všech procesů na všech kolekcích webů zobrazovaly v jednom seznamu úloh.
Pojďme se podívat na nějaký konkrétní příklad. Zmiňovali jsme faktury, zkusme tedy nasimulovat nějaký jednoduchý proces.
Příklad použití workflow při zpracování faktur
V systému K2 BlackPoint máme dvě možnosti, jak můžeme spouštět workflow. Buď pomocí integrace s formulářovým systémem InfoPath, kde odesláním formuláře iniciujeme K2 proces, nebo tím, že proces „pověsíme“ na některou z událostí knihovny či seznamu. V našem příkladu vytvoříme knihovnu dokumentů, která nám bude sloužit jako inbox pro faktury. Do tohoto inboxu se faktury mohou dostat prostým nahráním uživatelem, nebo například skenovacím řešením, anebo tím, že na knihovně povolíme přijímání e-mailů a pak tedy odesláním e-mailu s fakturou na adresu knihovny.
Fakturu z inboxu ihned přesuneme do oddělené knihovny. To může být šikovné kvůli právům, fakturu může do systému nahrát ledaskdo, ale informace o průběhu zpracování už budou přeci jenom dostupné pouze určeným uživatelům. Pro jednoduchost nebudeme simulovat obvyklé kroky formální kontroly, přiřazení střediska a zakázky a podobně. My pouze dle celkové částky fakturu necháme schválit buď vedoucím, nebo přímo ředitelem. Tak jak bude každá faktura postupovat procesem, budeme vždy měnit stav jejího zpracování, abychom si mohli později faktury příslušně utřídit. Ještě poznamenejme, že workflow systém nám bude sloužit pouze a jenom pro řízení schvalovacího procesu, veškerá data budeme uchovávat ve formě metadat v SharePointu.
Procesy můžeme navrhovat buď přímo v prostředí SharePoint, v samostatné aplikaci K2 Studio, nebo v případě edice K2 BlackPearl i v prostředí Visual Studia nebo Visia. Pokud nepotřebujeme z procesů volat externí kód nebo webové služby, vystačíme si s Web Designerem přímo v SharePointu. Výsledný proces vypadá následovně:
Vlastní instance procesů můžeme spustit pouhým nahráním faktury do inboxu. Po čase budeme mít v seznamu úloh zaznamenány všechny požadavky na příslušná schválení (v tomto případě jsme pro jednoduchost přiřadili roli vedoucího i ředitele jednomu uživateli). Stejně tak nám naroste počet položek v seznamu zpracovávaných faktur. Tyto informace si pomocí webpartů můžeme přehledně uspořádat například následovně:
Zmiňovali jsme nástroje pro správce, nuže, v rámci kolekce webů si na příslušném místě vytvoříme ze šablony správcovský web systému BlackPoint. V něm jednak upravujeme parametry samotného systému, jednak spravujeme jednotlivé definice procesů a jejich instance. Takový web může vypadat třeba jako tento:
Zmínili jsme se též o reportech. Tady bude asi těžké nabídnout ukázku nějakého reportu, pokud nemáme dostatečný vzorek dat. (My jich samozřejmě máme hromady, ale zrovna data o fakturách nepatří do časopisu, byť by to byl sám softwarový QUAS :-)) Zmíníme tedy, že K2 nám umožní vytvářet vlastní reporty v systému SQL Reporting Services a že několik takových základních reportů je již dodáno přímo se systémem. Report téměř bez dat vypadá následovně:
Příklad, který jste sledovali, je velmi zjednodušen a samozřejmě není v této formě použitelný pro reálný systém zpracování faktur. O to ale ani nešlo. Naším cílem bylo naznačit možnosti komplexních nástrojů pro automatizaci procesů. Tyto systémy nabízejí nejen
- grafické návrháře pro modelování procesů,
- nástroje pro centrální monitorování a správu procesů,
- pokročilé možnosti reportování, ale především spolehlivý, výkonný a škálovatelný „workflow engine“.
Dosáhnout podobného rozsahu funkcí, spolehlivosti a vyzrálosti vlastními silami by byl úkol na mnoho let.
Aleš Klenka | Marap, s.r.o.