1. Přehled: SharePoint Services 3.0 a workflow Úvod do problematiky, motivace Popis technologie Workflow Foundation...

Transkript

1 1

2 Obsah 1. Přehled: SharePoint Services 3.0 a workflow Úvod do problematiky, motivace Popis technologie Workflow Foundation Sekvenční workflow Stavové workflow Přehled základních komponent WF Knihovna tříd Workflow Foundation Workflow Runtime Engine Workflow RuntimeServices Nástroje určené k návrhu workflow Komunikace WF s hostitelskými aplikacemi SharePoint WorkflowRuntime, RuntimeServices Aplikace Bankomat a jednoduché použití stavového workflow Základní popis funkčnosti aplikace Detailní popis stavů aplikace Popis komponent aplikace Vytvoření projektu Runtime Local Service ATMService Definice komunikačního rozhraní Definice argumentů sloužících ke komunikaci workflow a hostitelské aplikace Implementace komunikační služby Události vyvolané ve workflow ovlivňující hostitelskou aplikaci Implementace workflow Modelování workflow

3 Vytvoření prázdného stavu Vložení aktivity StateInitialization Vložení aktivity CallExternalMethod Vložení aktivity EventDriven Vložení aktivity HandleExternalEvent zpracování události Vložení aktivity SetState přechod workflow do stavu Karta vložena Dokončení modelu workflow pro platební bankomat Shrnutí modelování a programování workflow Hostitelská aplikace Potřebné objekty Inicializace WorkflowRuntime Spuštění instance workflow uvnitř WorkflowRuntime Volání událostí komunikační služby Obdržení a zpracování události o přechodu do nového stavu Shrnutí kapitoly o implementaci jednoduchého platebního bankomatu Vývoj aplikací v prostředí SharePointu co je potřeba Popis aplikačního rozhraní MS SharePoint Architektura MS SharePoint Definice přístupových práv Objektový model SharePoint Manipulace s položkami v seznamu pomocí SharePoint API Příprava seznamu v SharePointu Vytvoření projektu ve Visual Studiu Poznámka o uvolňování objektu objektového modelu SharePointu Zdrojový kód příkladu

4 8.5 Závěr, poznámky k příkladu Ukázková aplikace: Import kontaktů z ActiveDirectory do SharePointu Přístup do Active Directory Vytvoření projektu, přidání referencí Získání uživatelských dat z Active Directory Import získaných dat do seznamu kontaktů v SharePointu Závěr Přidání vlastních ASP stránek do SharePointu Master Pages Vytvoření projektu a přidání referencí Logika webové stránky Deployment ASPX stránek do složky LAYOUTS Deployment dynamické knihovny SharePoint a Workflow Foundation Úvod do problematiky a cíle této části Schválení požadavku na nový software Integrace Workflow Foundation do SharePointu Workflow jako sled úkolů Workflow SharePoint aktivity SharePoint Features Nástroj STSADM Napojení úkolů v SharePointu na webové formuláře Vlastní typy obsahu Architektura aplikace Návrh vstupního formuláře (formuláře požadavku)

5 13.2 Návrh a zpracování webových formulářů, sloužících jako vstupní body pro uživatele aplikace Návrh a zpracování workflow Přehled architektury aplikace Návrh formuláře požadavku pomocí nástroje MS InfoPath Návrh formuláře a jeho publikování Tlačítko Odeslat uložení formuláře do knihovny v SharePointu Tipy a triky pro vytváření formulářů Zisk aktuálního data Zisk aktuálního uživatele Návrh a implementace webového rozhraní Vytvoření projektu ASPX formulář pro schválení Zdrojový soubor formuláře Získání proměnných z požadavku a z úkolu Odeslání informací zpět do workflow Úprava hodnot v požadavku Další metody v požadavku Formulář pro dodání dodatečných informací Publikování formulářů Vytvoření vlastních typů obsahu pro jednotlivé úkoly Povolení typů obsahu Návrh a implementace workflow Soubory feature a workflow Úpravy workflow Příprava proměnných

6 16.4 Modelování workflow Vytvoření nového úkolu Změna úkolu Stav přidání dodatečných informací Ladění aplikace Ladění na vzdáleném počítači Deployment přenos do produkčního prostředí Ukázka fungování systému Závěr Tipy a triky pro vývoj workflow v SharePointu Programové povolení typů obsahu na seznamu Posluchače událostí seznamu Implementace posluchače události ItemAdded Registrace posluchače událostí se seznamem Nastavení práv k úkolu Závěr Shrnutí obsahu příručky Shrnutí programování workflow v SharePointu

7 1. Přehled: SharePoint Services 3.0 a workflow Windows SharePoint je webová platforma, intranetový portál, který má za úkol sloužit jako univerzální informační systém podporující sdílení informací. Základem sdílených informací v SharePointu jsou knihovny dokumentů a seznamy. Jednou z možností manipulace s dokumenty a položkami v seznamech SharePointu je vytváření workflow, tedy popsání a definování business procesů, které je možné s dokumenty nebo položkami seznamů provádět. Vytváření workflow v SharePointu je umožněno díky integraci Workflow Foundation a objektového modelu SharePointu. Workflow Foundation je platforma určená k modelování workflow, která je standardní součástí.net Frameworku od verze 3.0. K úplnému pochopení workflow pod SharePointem je nutné probrat nejen aplikační rozhraní SharePointu, ale také základy Workflow Foundation, a zároveň doplnit, jak jsou tyto dvě platformy vzájemně propojeny. Tato série bude rozdělena na následující kapitoly: 1. Motivace-popis možného využití workflow 2. Workflow Foundation a. Popis platformy, základní stavební kameny b. Příklady sekvenčních a stavových workflow c. Příklad ilustrující implementaci workflow do jednoduché aplikace 3. Windows SharePoint Services a. Popis architektury b. Příklad ilustrující využití aplikačního rozhraní SharePointu c. Vkládání vlastních ASP.NET stránek do SharePointu 4. Návrh a implementace workflow, sloužícího ke schválení dokumentu a. Popis integrace SharePointu a Workflow Foundation b. Popis workflow stavový diagram c. Návrh workflow pomocí jednotlivých aktivit SharePointu 7

8 2. Úvod do problematiky, motivace S rozvojem informačních technologií se v dnešní době stále častěji setkáváme s nutností zmapovat, jak některé firemní procesy ve společnostech fungují, a jako vývojáři připravit pro tyto činnosti informační systémy, které budou k jejich vykonávání nápomocné. Během jakéhokoliv business procesu mezi sebou vzájemně komunikují a vyměňují si informace zaměstnanci firmy. Je vhodné business proces popsat a zautomatizovat. Tím dojde ke zvýšení efektivnosti a snížení chybovosti. K popisu business procesů se nejčastěji používají tzv. workflow. Pojmu workflow v češtině asi nejlépe odpovídá slovní spojení sled prací. Workflow je definováno jako postup činností, které jsou vykonávány v běžném životě za určitým účelem. Tento postup lze většinou zaznamenat vývojovým nebo stavovým diagramem. V této sérii článků se budeme zabývat procesy, které se týkají dokumentů. Mezi takovéto procesy může patřit například: 1. Schvalování dokumentů nejčastější použití workflow, kdy uživatel po vytvoření dokumentu odešle dokument prostřednictvím informačního systému svému nadřízenému ke schválení. 2. Společné vytváření dokumentů a koordinace spolupráce situace, kdy se několik uživatelů podílí na vytváření dokumentu. 3. Issue tracking během některých business procesů může vznikat seznam problémů, které je nutné přidělovat jednotlivým řešitelům, a tyto problémy jsou potom řešeny paralelně. 8

9 3. Popis technologie Workflow Foundation V této kapitole bude popsáno, ze kterých komponent se Workflow Foundation skládá, jak tyto komponenty fungují a zároveň komunikují, a posléze bude na jednoduché aplikaci demonstrována funkčnost této platformy. Jak již bylo zmíněno, Workflow Foundation je součástí platformy.net od verze 3.0. Je to sada nástrojů a knihovna tříd, které umožňují modelovat libovolné procesy. Její základní výhodou je použití v jakékoliv hostitelské aplikaci. Workflow Foundation tedy můžeme použít v klientské aplikaci (Windows Forms) nebo například ve webové aplikaci postavené na platformě ASP.NET. Než probereme základní součásti platformy, nejprve jasně vymezíme, co lze pomocí Workflow Foundation modelovat. V zásadě jsou to dva typy workflow: sekvenční a stavové. 3.1 Sekvenční workflow Sekvenční (Sequential) workflow je dáno jako sled akcí a událostí, které jsou spouštěny v předepsaném pořadí. Tok událostí je stanoven podmínkami a cykly. Sekvenční workflow má jasně daný začátek, všechny cesty svého průběhu a konec. Můžeme si ho představit jako jednoduchý vývojový diagram, pro ilustraci uvádím diagram schválení bankovního úvěru: Vytvoření požadavku na úvěr Zjistit finanční situaci klienta Je uvěr dostatečně zajištěn? Alokovat prostředky pro klienta Poslat klientovi odůvodnění zamítnutí Konec Obrázek 1: Sekvenční workflow 3.2 Stavové workflow Stavové (State Machine) workflow neurčuje jednoznačně pevnou posloupnost kroků. Místo toho je určeno několika stavy a přechody mezi nimi. Stavové workflow může, ale nemusí, mít pevně daný 9

10 počáteční a konečný stav. Toto mu umožňuje být přerušeno v libovolnou dobu a být znovu inicializováno z jakéhokoliv stavu, pokud je to nutné. Přechody mezi stavy jsou vyvolány událostmi, které workflow obdrží z hostitelské aplikace (popsáno dále). Následující stavový diagram popisuje schválení úvěru z hlediska stavů. Obdržení žádosti Zjišťování zajištění Zjištěno úvěr zajištěn Prostředky alokovány Čekání na žádost o úvěr Žádost obdržena Zajištění zjištěno Zjištěno úvěr nezajištěn Žádost odmítnuta Obrázek 2: Stavové workflow Z výše uvedeného popisu je jasné, že každý z těchto typů je vhodný k modelování různých procesů. Vzhledem k tomu, že sekvenční workflow je určeno přesnou sekvencí kroků, dá se říci, že je vhodnější pro modelování systémových interakcí, kde dopředu známe přesný sled událostí, které nastanou. Naopak stavové workflow může dobře posloužit při modelování procesů, při nichž dochází k interakci s lidmi, kde je zapotřebí větší flexibilita, protože lidé ne vždy dělají vše podle předepsaných kroků. Závěrem je ale nutné zmínit, že ve většině případů můžeme namodelovat proces nebo činnost oběma typy workflow. 10

11 4. Přehled základních komponent WF Na následujícím obrázku jsou zobrazeny komponenty, které tvoří MS Workflow Foundation, a dále následuje jejich popis. Workflow Foundation WF Runtime Engine WF Runtime Services WF Framework Knihovna tříd WF Design Time Tools Visual Studio WF Designer.NET 2.0 Obrázek 3: Základní komponenty Workflow Foundation 4.1 Knihovna tříd Workflow Foundation Knihovna tříd Workflow Foundation (Workflow Class Library) obsahuje třídy a objekty, které slouží k modelování procesů. Základní entitou v platformě Workflow Foundation je aktivita. Aktivita je jakýkoliv proces, který je prováděn v průběhu workflow. Z výše zmíněných příkladů můžeme za aktivitu označit například zjišťování finanční situace klienta. Základem je třída Activity, od níž dědí všechny třídy, které specifikují určitou prováděnou činnost. WF Class Library obsahuje řadu již hotových aktivit, jež lze použít, jako například Send Activity nebo CallExternalMethodActivity, jejichž význam je zřejmý. Stejně tak můžeme ale definovat svoje vlastní aktivity, které budeme chtít ve workflow používat. Vzhledem k výše uvedenému příkladu si můžeme představit aktivity jako například CheckClientSituationActivity nebo ApproveLoanActivity. Základním objektem každého workflow je WorkflowInstance. Tento objekt obdržíme po vytvoření nového workflow a umožňuje nám kontrolovat a spouštět workflow. Obsahuje metody jako například Start( ), Suspend( ) a Terminate( ), jejichž význam také není potřeba vysvětlovat. Všechny třídy, které tvoří tuto knihovnu tříd, lze najít ve jmenném prostoru System.Workflow. 4.2 Workflow Runtime Engine WF Runtime Engine je reprezentován třídou WorkflowRuntime. Tuto třídu si můžeme představit jako kontejner, který je uzpůsoben ke spouštění, zastavování a všeobecné správě instancí jednotlivých workflow (WorkflowInstance). Pokud chceme v aplikaci využít workflow, musíme nejprve vytvořit WorkflowRuntime, který bude workflow instance spravovat. WorkflowRuntime tedy poskytuje prostředí, v němž je možné spouštět jednotlivá workflow. 11

12 4.3 Workflow RuntimeServices RuntimeServices poskytují různé externí funkce a metody pro instance, uvnitř kontejneru WorkflowRuntime. Aby mohla služba spolupracovat s instancí workflow, musí být registrována s kontejnerem WorkflowRuntime. Instance jednotlivých workflow uvnitř kontejneru WorkflowRuntime mohou využít externích služeb voláním metod a posloucháním událostí, které daná služba registrovaná s WorkflowRuntime poskytuje. RuntimeServices jsou základními komponentami, které umožňují komunikaci workflow s okolním světem, především s hostitelskou aplikací. Služby se dělí na Core Services a Local Services. Core Services (základní služby) jsou reprezentovány třídami, které už jsou součástí knihovny tříd Workflow Foundation. Tyto služby jsou již připravené k použití a služby, které pro workflow instance zajišťují, mohou být různé. Příkladem je například třída SqlWorkflowPersistanceService. Tato třída slouží k uchování stavu workflow v SQL databázi. K takovéto serializaci stavu workflow do databáze dochází vždy v případě, kdy je workflow v nečinném stavu a čeká na akci uživatele. Workflow může být následně znovu nahráno z této zálohy v databázi. Je ovšem možné implementovat i vlastní typy základních služeb. Například děděním od třídy WorkflowPersistanceService je možné vytvořit vlastní službu pro ukládání stavu workflow, například do XML (extensible Markup Language) souborů. Local Services (místní služby) jsou služby definované vývojáři, za účelem poskytnutí instancím workflow uvnitř kontejneru WorkflowRuntime metody a události, které mu umožní komunikovat s hostitelskou aplikací. 4.4 Nástroje určené k návrhu workflow Jedna ze základních výhod Workflow Foundation je možnost vizuální práce s workflow. Především možnost grafického návrhu workflow pomocí Designéru, který je součástí MS Visual Studia Grafický návrh workflow není podmínkou. Celé workflow se dá napsat ručně bez použití tohoto Designéru, ale tím se připravujeme o jednu ze základních výhod Workflow Foundation. V této souvislosti je vhodná paralela s designérem klasického GUI (Graphical User Interface) pro Windows Forms aplikace. Jeho použití také není nutností, ale ušetříme dost času, nemusíme-li psát lehce vygenerovatelný kód. 4.5 Komunikace WF s hostitelskými aplikacemi Jak již bylo zmíněno výše, jedním ze základních problémů a zároveň funkčností, bez které by bylo použití workflow naprosto bez užitku, je možnost komunikovat s hostitelskou aplikací. Také již bylo řečeno, že k tomu slouží Local RuntimeServices. Z následujícího obrázku je patrné, jak tato komunikace probíhá. 12

13 Registrovat službu Vytvořit službu WorkflowInstance WorkflowInstance Používá Core Services Workflow Runtime Hostitelská aplikace WorkflowInstance WorkflowInstance Doručení události Spusť událost Local Runtime Services Spusť událost Doručení události Registrovat službu Vytvořit službu Obrázek 4: Komunikace workflow s hostitelskou aplikací Hostující aplikace musí v první řadě obsahovat instanci třídy WorkflowRuntime, tato instance může obhospodařovat libovolný počet instancí jednotlivých workflow. Dále je nutné definovat třídu, která bude reprezentovat lokální službu určenou ke komunikaci. Tato služba má pevně danou strukturu, tak aby mohla být s instancí třídy WorkflowRuntime registrována a instance workflow, které běží uvnitř, mohly volat metody a poslouchat události této služby. Proces ovšem může fungovat i opačně, kdy hostitelská aplikace volá metody této služby a také poslouchá události, které jí tato služba odesílá. Tím je docíleno vzájemné komunikace. 4.6 SharePoint WorkflowRuntime, RuntimeServices Logická otázka zní: Jak tyto součásti nutné pro běh workflow zakomponovat do SharePointu? Pokud vyvíjíme Windows Forms nebo ASP.NET aplikaci, je to poměrně jednoduché (jak bude ukázáno v příkladu na konci této kapitoly). Nemáme v zásadě žádná omezení, můžeme si vytvářet libovolné objekty, které jsou potřeba ke spuštění instance Workflow. V případě SharePointu je situace odlišná. SharePoint je již hotový produkt a nemůžeme měnit jeho strukturu, nejde tedy například přidat do SharePointu nový Workflow Runtime a v něm spouštět instance vlastních workflow. SharePoint již obsahuje základní objekty Workflow Foundation. Obsahuje tedy Workflow Runtime, které je připravené k přidávání a spouštění jednotlivých instancí workflow. Zároveň obsahuje také vlastní implementace Core Services. Tedy například službu zajišťující perzistenci workflow do SQL databáze SharePointu. 13

14 Detailněji to bude popsáno v samostatné kapitole, která se bude zabývat integrací Workflow Foundation do SharePointu. 14

15 5. Aplikace Bankomat a jednoduché použití stavového workflow Nyní se již zaměříme na konkrétní příklad použití Workflow Foundation a tím bude jednoduchá aplikace simulující platební bankomat. Protože aplikace slouží jen k účelu vysvětlení technologie WF, byla co nejvíce zjednodušena, a bankomat tak provádí jen některé základní operace. 5.1 Základní popis funkčnosti aplikace Následující diagramy ukazují několik stavů, ve kterých se může bankomat nacházet od operace vložení karty až po výběr hotovosti. Bankovní automat Zapnout Vložit kartu První Bankovní a.s. Bankovní automat Zapnout Vybrat hotovost Zjistit stav účtu První Bankovní a.s. Vyberte akci kterou chcete provést: Vložte prosím kartu Bankovní automat Zapnout Vyjmout kartu Výběr hotovosti Zjištění zůstatku na Vašem účtu Potvrdit PIN Nyní jsem Vyjmout ve stavu: WaitingForCardState kartu První Bankovní a.s. Zadejte prosím Váš PIN a potvrďte stiskem tlačítka (PIN je: "1111") Nyní jsem ve stavu: WaitingForCardState Nyní jsem ve stavu: CardEnteredState Nyní jsem ve stavu: PINEnteredState Nyní jsem ve stavu: WaitingForCardState Nyní jsem ve stavu: CardEnteredState Obrázek 5: První tři stavy aplikace Bankomat 15

16 Bankovní automat Zapnout Bankovní automat Zapnout 200 První Bankovní a.s. 500 Vyberte částku, kterou chcete vybrat. Zpět do MENU Vyjmout kartu Jinou částku Zpět do MENU První Bankovní a.s. Výše zůstatku na Vašem účtu činí: Pokud Vám nabízené částky nevyhovují, můžete zadat vlastní. Bankovní automat Zapnout Nyní jsem ve stavu: Vyjmout WaitingForCardState Nyní jsem ve stavu: kartucardenteredstate Nyní jsem ve stavu: PINEnteredState Nyní jsem ve stavu: Zpět do WithDrawMoneyState MENU První Bankovní a.s. Transakce proběhla vpořádku. Nyní jsem ve stavu: WaitingForCardState Nyní jsem ve stavu: CardEnteredState Nyní jsem ve stavu: PINEnteredState Nyní jsem ve stavu: WithDrawMoneyState Nyní jsem ve stavu: TransactionCompletedState Nyní jsem ve stavu: PINEnteredState Nyní jsem ve stavu: CheckAccountState Přejete si návrat do hlavního menu? Nyní jsem ve stavu: WaitingForCardState Nyní jsem ve stavu: CardEnteredState Nyní jsem ve stavu: PINEnteredState Nyní jsem ve stavu: WithDrawMoneyState Nyní jsem ve stavu: TransactionCompletedState Obrázek 6: Stavy aplikace Bankomat při výběru hotovosti 5.2 Detailní popis stavů aplikace Popsat všechny stavy, ve kterých se bankomat nachází, lze nejlépe stavovým diagramem. 16

17 Čekání na vložení karty Vložení karty Vyjmutí karty Karta vložena Čekáni na PIN Chybný PIN Korektní PIN Vyjmuti karty Vyjmutí karty Návrat do hlavní nabídky PIN vložen Výběr operace Operace provedena Výběr hotovosti Dokončení operace Dokončení operace Výběr hotovosti Návrat do hlavní nabídky Zjistit stav účtu Výběr konkrétní částky Výběr konkrétní částky Zjištění zůstatku na účtu Obrázek 7: Stavový diagram Bankomatu Z tohoto diagramu je zřejmé, že aplikace má jeden počáteční stav, ve kterém bankomat čeká na vložení karty. Ve stavovém diagramu jsou vyznačeny události, jež způsobují přechody mezi stavy. Například pokud se aplikace nachází v počátečním stavu Čekání na vložení karty a je vložena karta, přejde do stavu Čekání na PIN. Toto stavové workflow nemá koncový stav, po vyjmutí karty bankomat přechází znovu do prvního stavu. 5.3 Popis komponent aplikace Aplikace Bankomat vytvořená pomocí WF se bude skládat ze tří základních částí: Hostitelská aplikace reprezentovaná formulářem (třída MainForm.cs) Dynamická knihovna obsahující workflow (třída ATMWorkflow.cs) Komunikační Runtime Local Service (třída ATMService.cs) Architektura aplikace je naznačena na níže uvedeném diagramu. Aplikace Bankomat Workflow Runtime WorkflowInstance CardEntered SendMenuText() ATMService RaiseCardEntered() UpdateMenuText() GUI Aplikace MainForm Obrázek 8: Schéma komponent aplikace Bankomat 17

18 Visual Studio Solution se bude skládat ze tří základních projektů, z nichž každý bude reprezentovat jednu z výše uvedených součástí. Uživatelské rozhraní aplikace reprezentované formulářovým oknem bude obsluhovat události prováděné uživatelem v tomto případě stisky jednotlivých tlačítek. V obsluze těchto událostí bude tyto vyvolávat události ATMService služby, která bude tvořit komunikační vrstvu. Takto vyvolané události se dostanou až k instanci workflow běžící ve Workflow Runtimu, a zde budou zpracovány a na základě stavu, v němž se workflow nachází, a vstupů, které obdrželo, budou zpět do aplikace reprezentující uživatelské rozhraní odeslány informace a vyhodnocení určující, co je potřeba provést. 5.4 Vytvoření projektu Nejprve navrhneme strukturu a vytvoříme prázdné projekty, ve kterých budeme vyvíjet jednotlivé části aplikace. Otevřeme tedy Visual Studio a vytvoříme v něm nový projekt typu Windows Forms Application. Zároveň s projektem se vytvoří i nové Solution. Obrázek 9: Vytvoření nového projektu 18

19 Do Solution následně přidáme další dva projekty. První typu State Machine Workflow Library, v němž budeme vytvářet a modelovat samotné workflow, a druhý typu Class Library, ve kterém budou třídy reprezentující ATMLocalService. Obrázek 10: Projekt workflow Obrázek 11: Projekt komunikační služby Výsledné řešení ve vašem Visual Studiu by mělo vypadat následovně: Obrázek 12: Přehled řešení ve Visual Studiu 5.5 Runtime Local Service ATMService Jak již bylo řečeno, třídy v projektu ATMLocalService budou sloužit jako komunikační prostředky mezi uživatelským rozhraním a workflow. Protože v obou ostatních projektech se budeme odkazovat na třídy z tohoto projektu, definujeme je nyní jako první Definice komunikačního rozhraní První je třeba definovat komunikační rozhraní, které určí události (events), jež bude workflow poslouchat. Vytvoříme tedy rozhraní, které pojmenujeme IATMService. Rozhraní musí být dekorované 19

20 atributem ExternalDataExchange, ten řekne workflow, že se jedná o třídu definující komunikační rozhraní. Rozhraní IATMService bude definovat všechny události spojené s bankomatem (vsunutí/vysunutí karty, zadání PINu atd.). Dále bude obsahovat jednu metodu SendMenuText. Tato metoda bude sloužit ke komunikaci směrem od Workflow Enginu k aplikaci. [ExternalDataExchange] public interface IATMService /// <summary> /// Metoda, která umožní našemu workflow nastavit výstupní /// text v hostitelské aplikaci. /// </summary> /// <param name="menutext">výstupní text</param> void SendMenuText(String menutext); /// <summary> /// Událost vsunutí karty /// </summary> event EventHandler<ATMEventArgs> CardInserted; event EventHandler<ATMEventArgs> PINEntered; event EventHandler<ATMEventArgs> CardRemoved; event EventHandler<ATMEventArgs> CheckAccoundRequested; event EventHandler<ATMEventArgs> MoneyRequested; event EventHandler<ATMEventArgs> SumRequested; event EventHandler<ATMEventArgs> ExactSumRequested; event EventHandler<ATMEventArgs> BackToMenuRequested; Definice argumentů sloužících ke komunikaci workflow a hostitelské aplikace Při definici EventHandleru je nutné specifikovat typ argumentu události. Argumenty události musí obsahovat veškeré informace, které chceme do workflow poslat v daném kroku. Formulář aplikace může do workflow posílat dva speciální argumenty: při vkládání karty její PIN a při výběru hotovosti celkovou požadovanou částku. Třída ATMEventArgs, kterou používáme ve výše uvedené definici EventHandlerů, zapouzdří tyto argumenty. Zároveň musí dědit od třídy ExternalDataEventArgs. Konstruktor třídy argumentů dědící od ExternalDataEventArgs má jeden parametr a tím je ID určující Instanci Workflow, jehož pomocí WorkflowRuntime zjistí, kterému workflow uvnitř má událost doručit. Vytvoříme tedy třídu ATMEventArgs. [Serializable] public class ATMEventArgs : ExternalDataEventArgs /// <summary> /// Zadávaný PIN /// </summary> 20

21 public string Pin get;set; /// <summary> /// Suma pří výběru hotovosti /// </summary> public int Amount get; set; /// <summary> /// Konstruktor třídy argumentů /// </summary> public ATMEventArgs(Guid instanceid) : base(instanceid) Implementace komunikační služby Nyní, když máme předdefinované komunikační rozhraní IATMService a zároveň argumenty, které chceme do workflow pomocí tohoto rozhraní posílat, můžeme přistoupit k navržení komunikační služby, jež bude toto rozhraní implementovat. Vytvoříme třídu ATMService, která tedy bude obsahovat všechny události rozhraní IATMService a navíc definovat metody sloužící pro probuzení těchto událostí. Pro ilustraci je níže uvedena metoda, která probudí událost PINEntered. Stejné metody musíme dopsat pro probuzení všech ostatních událostí. V metodě je nejprve zjišťováno, zda jsou s událostí registrované některé metody, a v případě, že tomu tak je, je vytvořen nový objekt typu ATMEventArgs. Tomuto objektu jsou předány argumenty: vložený PIN a identifikátor instance workflow. Následně je probuzena událost PINEntered s těmito argumenty. Zbytek komunikace již nemůžeme ovlivnit. WorkflowRuntime obdrží tuto událost od služby ATMService a podle identifikátoru jí doručí konkrétní instanci workflow. [Serializable] public class ATMService : IATMService public void RaisePINEnteredEvent(Guid instanceid,string lpin) //zjistí, zda jsou s událostí registrované metody if (PINEntered!= null) //vytvoří argumenty události ATMEventArgs e = new ATMEventArgs(instanceId); //přiřadí PIN do argumentů e.pin = lpin; //zavolá metody registrované s událostí PINEntered(null, e); public event EventHandler<ATMEventArgs> PINEntered; 21

22 Události vyvolané ve workflow ovlivňující hostitelskou aplikaci Za účelem odeslání výstupního textu do hostitelské aplikace implementuje služba ATMService metodu SendMenuText, také definovanou rozhraním IATMService. Pro pochopení implementace metody SendMenuText je nutné si uvědomit architekturu celého programu. Možnosti komunikace jedné instance workflow, které běží uvnitř WorkflowRuntime, s okolním světem jsou poměrně omezené. Pomocí speciálních aktivity CallExternalMethodActivity, ke které se ještě vrátíme, je možné volat externí metody, ale pouze definované v komunikační službě, která implementuje rozhraní dekorované atributem ExternalDataExchange. Takovou komunikační službou je v našem případě služba ATMService. Je tedy nutné definovat ve službě ATMService metodu SendMenuText. Tato metoda se ale nemůže odvolávat přímo na GUI aplikace. Je nutné definovat událost, která bude voláním této metody probuzena a GUI aplikace bude moci tuto událost odposlouchávat, a vždy při probuzení této události změnit výstupní text automatu. Definujeme tedy delegáta a k němu odpovídající událost MenuTextEvent, kterou budou moci využít klienti (v tomto případě GUI aplikace) k získání informace o změně výstupního textu. V metodě SendMenuText se nejprve zjistí, zda jsou s událostí MenuTextEvent registrované posluchače (zda událost není null), a v případě, že tomu tak není, je vytvořen objekt typu UpdateMenuTextEventArgs, do kterého zabalí text, jenž se má odeslat hostitelské aplikaci. Následně je probuzena událost MenuTextEvent s vytvořenými argumenty. Hostitelská aplikace tyto argumenty obdrží a zobrazí výstupní text. // Delegát sloužící k připojení k notifikaci o změně textu public delegate void UpdateMenuTextEventHandler(object sender, UpdateMenuTextEventArgs e); // Událost, kterou mohou využít klienti kdykoliv dojde ke změně textu public event UpdateMenuTextEventHandler MenuTextEvent; public void SendMenuText(string menutext) //nastavení textu k poslání this.currentmenutext = menutext; //zjistí, zda jsou s událostí registrované metody if (this.menutextevent!= null) //spustí metody registrované s událostí this.menutextevent(this, new UpdateMenuTextEventArgs(CurrentMenuText)); // Property k nastavení aktuálního textu, který se má odeslat private String CurrentMenuText get; set; 22

23 Posledním stavebním kamenem, který chybí, je definovat argumenty, jež může Workflow posílat hostitelské aplikaci ve třídě UpdateMenuTextEventArgs. Ta slouží k zapouzdření textu, který je potřeba poslat z WorkflowEnginu do formuláře aplikace. Stačí poslat pouze výstupní text automatu: public class UpdateMenuTextEventArgs :EventArgs // Text, který je odeslán do aplikace public String MenuText get; set; // Konstruktor argumentů public UpdateMenuTextEventArgs(String lmenutext) this.menutext = lmenutext; 5.6 Implementace workflow V této části vysvětlíme, jak modelovat a následně implementovat jednoduché stavové workflow pro platební bankomat Modelování workflow Prvním úkolem bude vytvořit počáteční stav bankomatu. Při vstupu do tohoto svatu by mělo workflow odeslat aplikaci bankomatu zprávu: Jsem v počátečním stavu, čekám na vložení karty. Toho docílíme následujícími kroky: 1. Vytvoříme dva stavy stav, kdy automat čeká na kartu, a stav, kdy již byla karta vložena. 2. Do počátečního stavu přidáme aktivitu StateInitialization ta se provede vždy při vstupu workflow do stavu. 3. Do StateInitialization aktivity vložíme aktivitu CallExternalMethod budeme chtít volat metodu komunikační služby, která oznámí bankomatu, co má zobrazit ve výstupním okně. 4. Vložíme do stavu aktivitu EventDriven tuto aktivitu budeme chtít probudit po vložení karty. 5. Do této aktivity vložíme aktivitu HandleExternalEvent ta zpracuje událost vložení karty. 6. Dále do EventDriven aktivity vložíme aktivitu SetState ta umožní přesunout workflow do jiného stavu Vytvoření prázdného stavu Projekt ATMWorkflow, který jsme vytvořili na začátku vývoje, obsahuje standardně třídu Workflow1. Obsahem je workflow diagram, který zatím obsahuje pouze jeden stav. 23

24 Obrázek 13: Vygenerované workflow s iniciálním stavem Využijeme tento stav pro náš účel a přejmenujeme stav na WaitingForCardState. Dále bude nutné přidat nový stav, do kterého workflow přejde po vložení karty. Z Toolboxu vybereme položku State a přetažením vložíme do workflow. Obrázek 14: Objekt State v Toolboxu Vložený stav je vhodné přejmenovat na CardInsertedState Vložení aktivity StateInitialization Do stavu vložíme aktivitu StateInitialization. Tuto aktivitu najdeme v Toolboxu ve skupině aktivit označené jako Windows Workflow v3.0. Aktivitu vložíme do workflow přetažením na počáteční stav. Obrázek 15: Aktivita StateInitialization v Toolboxu StateInitialization se provede vždy během vstupu workflow do daného stavu. Po jejím vložení se zobrazí její detail. Aktivitu přejmenujeme pomocí okna vlastností na WaitingForCardInitialize. Budeme chtít, aby se při vstupu do tohoto stavu odeslal do formuláře aplikace text: Vložte kartu. Toho docílíme tak, že z námi vytvořené StateInitialization zavoláme externí metodu SendMenuText, kterou jsme definovali v komunikační službě ATMService. 24

25 Vložení aktivity CallExternalMethod Přetáhneme tedy do StateInitialization z Toolboxu aktivitu CallExternalMethod. Výsledek by měl vypadat zhruba takto: Obrázek 16: Detail stavu WaitingForCardState Aktivitu můžeme v okně vlastností opět přejmenovat na CallShowMainMenu. Červený vykřičník v rohu aktivity CallExternalMethod naznačuje, že bude nutné upravit její vlastnosti. Otevřeme okno vlastností této aktivity a uvidíme, které vlastnosti je nutné modifikovat. Protože bude nutné jako v InterfaceType vybrat službu ATMService, která je ovšem v jiném projektu než samotné workflow, nejprve přidáme tento projekt do referencí workflow. Po kliknutí pravým tlačítkem na projekt ATMWorkflow vybereme Add Reference a na záložce Projects vybereme komunikační projekt obsahující třídu ATMService. Nyní po kliknutí na vlastnost InterfaceType se zobrazí dialog, ve kterém vybereme ATMService, tak jak je zobrazeno na následujícím obrázku: Obrázek 17: Nastavení vlastnosti InterfaceType aktivity CallExternalMethod 25

26 Nyní, jak ukazuje červený vykřičník, je nutné vybrat externí metodu, která se má zavolat. V rozevíracím seznamu se zobrazí jediná metoda: SendMenuText. Obrázek 18: Přehled vlastností aktivity CallExternalMethod Protože metoda má jeden argument menutext typu String, tak se tento argument automaticky zobrazí v okně vlastností. Do pole menutext můžeme vepsat přímo text, který chceme odeslat do hostující aplikace. Další možností je napojit (bind) toto pole na novou nebo již existující proměnnou ve třídě workflow. Po kliknutí na tři tečky, jež se objeví v rohu vlastnosti menutext, se otevře speciální dialog, který umožní napojení na nové pole. Pole pojmenujeme například insertcard. Obrázek 19: Napojení vlastnosti aktivity na nové pole 26

27 Při zobrazení zdrojového kódu workflow můžeme nyní například rovnou nastavit hodnotu této nově vytvořené proměnné. namespace ATMWorkflow public sealed partial class Workflow1 : StateMachineWorkflowActivity public Workflow1() InitializeComponent(); public String insertcard = "Vložte prosím kartu"; Krátká rekapitulace: Vytvořili jsme nový stav. Do něj jsme vložili aktivitu StateInitialization. V této aktivitě voláme externí metodu komunikační služby pomocí aktivity CallExternalMethod. Nyní zbývat namodelovat a naprogramovat vložení karty a přesunutí workflow do nového stavu Vložení aktivity EventDriven Exekuce EventDriven aktivity je svázaná s určitou událostí, a je to vlastně EventHandler, který se provede poté, co je přes komunikační interface probuzena určitá událost. Aktivitu najdeme v Toolboxu ve skupině Windows Workflow v3.0. Do stavu ji vložíme opět přetažením. Obrázek 20: Aktivita EventDriven v Toolboxu Po vložení bude náš stav vypadat následujícím způsobem: Obrázek 21: Detail stavu WaitingForCardState Po dvojkliku na právě vloženou aktivitu eventdrivenactivity1 se otevře její detail. Aktivitu přejmenujeme na CardInsertedEvent a pokračujeme dalším krokem, kterým je vložení HandleExternalEvent Vložení aktivity HandleExternalEvent zpracování události HandleExternalEvent najdeme opět v Toolboxu: 27

28 Obrázek 22: Aktivita HandleExternalEvent v Toolboxu Po vložení aktivity nám opět červený vykřičník u vlastností InterfaceType a EventName prozradí, že je nutné tyto vlastnosti doplnit. Obrázek 23: WaitingForCardState HandleExternalEvent Otevřeme kontextovou nabídku kliknutím na tři tečky u vlastnosti InterfaceType. Zde je opět nutné vybrat komunikační rozhraní. Pomocí stejného postupu jako v kroku 2 vybereme rozhraní IATMService. Nyní je již pouze nutné vybrat EventName, tedy událost, kterou chceme touto aktivitou zpracovat. Z kontextové nabídky vybereme vlastnost CardInserted. Tato aktivita nevolá žádnou další metodu. Pouze čeká a je probuzena událostí CardInserted. Jakmile je však probuzena a zpracována, může workflow pokračovat dál. Pro náš účel bude vhodné, aby workflow pokračovalo vstupem do stavu Karta vložena Vložení aktivity SetState přechod workflow do stavu Karta vložena Nyní pod dříve vloženou aktivitu, která zpracuje událost CardInserted, vložíme aktivitu SetState. Obrázek 24: Aktivita SetState v Toolboxu Po vložení aktivity vidíme v jejích vlastnostech, že jedinou vlastností, kterou je nutné nastavit, je TargetStateName tedy cílový stav. V kontextovém menu vlastnosti TargetStateName máme na výběr ze dvou stavů. Jedním je ten, v němž se právě nacházíme, a druhým ten, který je vhodné vybrat: CardInsertedState. 28

29 Obrázek 25: Vlastnosti aktivity SetState Když si nyní zobrazíme celkové workflow, uvidíme oba dva propojené, přechodovou hranou. Obrázek 26: Workflow po vložení prvních dvou stavů Tímto jsme provedli prvních šest kroků, kterými jsme schopni odeslat do aplikace výstupní text po vstupu do stavu, zpracovat událost vložení karty a přejít po této události do stavu, ve kterém budeme moci dále provádět zpracování zadání PINu. 5.7 Dokončení modelu workflow pro platební bankomat Pokud chceme namodelovat takové workflow, které bude odpovídat stavovému diagramu uvedenému v kapitole 5.2, bude nutné, aby workflow obsahovalo stejný počet stavů jako stavový diagram a stejné přechody mezi nimi. Nebudeme zde podrobně rozebírat vytvoření celého workflow. Zaměříme se pouze na některé detaily, které se liší od postupů uvedených v předchozí kapitole. Na následujícím obrázku je konečný návrh workflow diagramu pro platební bankomat. 29

30 Obrázek 27: Stavové workflow v Designeru Visual Studia 2008 Každý stav obsahuje vnitřní aktivity; jde v zásadě vždy o dvě aktivity, již zmíněné v předchozí kapitole. StateInitialization obsahuje všechny aktivity, které se mají provést při inicializaci stavu, tedy při vstupu workflow do tohoto stavu. EventDriven obsahuje aktivity, které se provádějí při obdržení externí události z hostitelské aplikace, například PIN obdržen. Každý stav obsahuje jednu aktivitu typu StateInitializationActivity, ve které odesílá výstupní text do hostitelské aplikace a pak několik aktivit typu EventDrivenActivity, jimiž reaguje na různé události, které mohou nastat. Například ve stavu CardEnteredState jsou obsaženy dvě aktivity tohoto typu: CardRemovedEvent reaguje na vyjmutí karty. PINEnteredEvent reaguje na zadání PINu. 30

31 Na příkladu PINEnteredEvent aktivity ze stavu CardEnteredState si můžeme ukázat, jak je možné na základě probuzené události a obdržených parametrů rozvětvit workflow a poslat do různých stavů. Na následujícím obrázku je detail aktivity PINEnteredState: Obrázek 28: Detail aktivity vyvolané událostí PIN vložen První aktivitou, která je prováděna při obdržení externí události, je HandleExternalEvent (v diagramu je to aktivita pojmenovaná handlepinenteredactivity) a k jejímu vykonání dochází v okamžiku, kdy workflow obdrží pomocí služby ATMService událost PINEnteredEvent. Jakmile je tato událost obdržena, spustí se následující aktivita typu IfElse, při které se vyhodnotí, zda byl zadán správný PIN. Vidíme dvě větve, z nichž každá obsahuje aktivitu typu SetState. Tato aktivita zaručuje přechod do dalšího stavu. V případě, že byl PIN zadán v pořádku, přecházíme do stavu PINEnteredState, v případě, že nebyl zadán pořádku, zůstáváme ve stavu CardEnteredState (aplikace tak znovu požádá uživatele o vložení PINu). Při vytváření této aktivity postupujeme podobně jako ve výše uvedeném případě. Rozdíl je v tom, že při zpracování vnější události PINEntered je nutné získat z argumentů této události vložený PIN. Po vložení HandleExternalEvent musíme nastavit InterfaceType a EventName, tak jak je ukázáno na obrázku. 31

32 Obrázek 29: Vlastnosti aktivity zpracující událost vložení stavu Nyní ovšem ještě napojíme argumenty události zde určené vlastností pojmenovanou e na novou proměnnou, kterou si uložíme do workflow. Otevřeme dialog pro napojení a pojmenujeme novou proměnnou: Obrázek 30: Napojení obdržených argumentů události na novou proměnnou Nyní vložíme aktivitu IfElse, která nám umožní rozdělit běh workflow pro různě zadané PINy. Po vložení této aktivity si všimneme, že u jedné z větví svítí červený vykřičník. Je totiž nutné alespoň u jedné z větví nastavit podmínku pro průchod touto větví. U vlastnosti Condition zvolíme Declarative Rule Condition. Obrázek 31: Vlastnosti aktivity IfElse 32

33 Declarative Rule Condition umožní vytvořit jednoduchá pravidla, která určí, kdy je daná podmínka splněna. Jedná se vlastně o logické výrazy, které si Designer workflow ukládá v položce souborech s příponou.rules. Každé workflow defaultně obsahuje alespoň jeden takovýto soubor. Klikneme-li tedy vpravo na tlačítko u vlastnosti ConditionName, otevře se okno správce těchto pravidel. Ještě v něm není uloženo žádné pravidlo. Klikneme tedy na tlačítko New a vytvoříme nové pravidlo. Otevře se k tomu speciální editor těchto výrazů. Obrázek 32: Vytvoření deklarativního pravidla Zadáme uvedený výraz. V něm se odkazujeme na získané argumenty události PINEntered. Ze skupiny těchto argumentů nás zajímá právě proměnná Pin. Porovnáme ji s jakoukoliv jinou stringovou proměnnou, která bude obsahovat PIN karty. Výsledná vytvořená podmínka se pojmenuje Condition1, je možné jí přejmenovat, aby byl seznam v budoucnu, kdy bude podmínek více, přehlednější. Nyní je již možné do jednotlivých větví aktivity IfElse vložit aktivity SetState, které posunou workflow do požadovaných stavů. 5.8 Shrnutí modelování a programování workflow Z výše zmíněných příkladů by mělo být jasné, že stavové workflow je souhrn stavů. Aby mohla být ve stavu provedena určitá činnost, musí stav obsahovat některou z aktivit. Aktivity nemohou být ve stavu přímo vloženy bez určení času jejich spuštění. Proto musí každý stav obsahovat nejprve aktivitu StateInitializationActivity nebo StateFinalizationActivity, které udávají, zda a kdy má ke spuštění určité činnosti dojít. Další a poslední možností jsou potom EventDrivenActivity. Jejich spuštění je inicializováno obdržením události od hostitelské aplikace. 33

34 5.9 Hostitelská aplikace Hostitelská aplikace je reprezentována klasickým formulářovým dialogem s několika tlačítky a vstupním a výstupním textovým polem. Jak již bylo řečeno, aplikace musí obsahovat instanci třídy WorkflowRuntime. WorkflowRuntime umožňuje spouštění a správu instancí workflow. V případě bankomatu tento runtime spravuje pouze jednu instanci workflow. Pokud by uměl bankomat paralelně pracovat s několika kreditními kartami najednou, mohla by být pro každou seanci vytvořena vlastní instance workflow Potřebné objekty Pro komunikaci s instancí workflow musí hostitelská aplikace obsahovat instanci třídy ATMService, tedy službu, která tuto komunikaci umožňuje. Tato služba je registrovaná s kontejnerem WorkflowRuntime a poskytuje workflow ty události, které vyvolávají přechody mezi stavy. Následující část kódu ukazuje proces inicializace WorkflowRuntime a registrace ATMService. public partial class MainForm : Form private WorkflowRuntime runtime; private ATMService atmservice; private StateMachineWorkflowInstance statemachineworkflowinstance; private Guid workflowinstanceid; public MainForm() InitializeComponent(); Inicializace WorkflowRuntime Při spuštění aplikace je nutné provést inicializaci WorkflowRuntime a jeho spuštění. Dále je nutné inicializovat a připojit komunikační službu ATMService. Můžeme také nastavit EventHandlery událostem, které obsahuje WorkflowRuntime, tedy spuštění, uspání a ukončení workflow. Všechny tyto události jsou prováděny v metodě StartWorkflowRuntime(), která je volána během inicializace formuláře. 34

35 private void StartWorkflowRuntime() runtime = new WorkflowRuntime(); //Vytvoříme posluchače událostí, které dodává WorkflowRuntime. runtime.workflowterminated += new EventHandler<WorkflowTerminatedEventArgs>(runtime_WorkflowTerminated); runtime.workflowcompleted += new EventHandler<WorkflowCompletedEventArgs>(runtime_WorkflowCompleted); runtime.workflowidled += new EventHandler<WorkflowEventArgs>(runtime_WorkflowIdled); //spuštění Workflow Runtime runtime.startruntime(); //Vytvoříme službu pro správu komunikace hostující aplikace a workflow ExternalDataExchangeService dataexchangeservice = new ExternalDataExchangeService(); //Registrujeme tuto službu s WorkflowRuntimem runtime.addservice(dataexchangeservice); //Vytvoříme novou službu pro komunikaci WF hostitelská aplikace atmservice = new ATMService(); //Přidáme ke službám registrovaným s WorkflowRuntimem dataexchangeservice.addservice(atmservice); //Registrujeme posluchače událostí, které nám bude posílat workflow atmservice.menutextevent += new ATMService.UpdateMenuTextEventHandler(atmService_MenuTextEventHandler); V aplikaci Bankomat se tato část programu vykonává při inicializaci formuláře. Kromě kroků inicializace WorkflowRuntime a registrace komunikační služby je v posledním řádku registrován nový EventHandler (posluchač) události MenuTextEvent. Pomocí této události předává instance workflow hostitelské aplikaci výstupní text. Tato událost je vybuzena vždy v inicializaci nového stavu Spuštění instance workflow uvnitř WorkflowRuntime Dalším nutným krokem je vytvoření instance workflow a její spuštění. Vytvoření se provádí pomocí třídy WorkflowRuntime a metody CreateWorkflow(Type), které se jako parametr předává typ workflow, jež má být vytvořeno. 35

36 private void StartATMWorkflow() //Vytvoříme instanci workflow typu ATMWorkflow WorkflowInstance instance = runtime.createworkflow(typeof(atmworkflow)); //spuštění této instance uvnitř WorkflowRuntimu instance.start(); //získání instance stavového workflow, aby bylo možné přistupovat ke stavům statemachineworkflowinstance = new StateMachineWorkflowInstance(this.runtime, instance.instanceid); //získáme ID instance,abychom jí mohli posílat události workflowinstanceid = statemachineworkflowinstance.instanceid; Jako návratová hodnota z metody CreateWorkflow(Type) je obdržen objekt typu WorkflowInstance, tedy odkaz na instanci workflow, následně je možné získat i objekt typu StateMachineWorkflowInstance. Tento objekt umožňuje přístup k některým užitečným informacím o spuštěné instanci stavového workflow, především její aktuální stav. Tyto objekty je nutné uchovat, protože umožňují posílat instanci workflow události, tedy změny stavů, vyvolané stisky jednotlivých tlačítek Volání událostí komunikační služby Následující část aplikace ukazuje, jak se volají události obsažené ve službě ATMService a jak je tato služba doručí konkrétní instanci workflow uvnitř WorkflowRuntime. Zde ukázaná metoda EventHandlerem stisku libovolného tlačítka. Podle textu tlačítka se rozpozná, která událost se má probudit a odeslat do WorkflowRuntime. Pro ukázku jsou zde zpracována pouze dvě tlačítka: Vložení karty a Potvrzení PINu. // Event Handler, připojený na stisk všech tlačítek ve formuláři bankomatu private void ButtonEventHandler(object sender, EventArgs e) //Odesílací tlačítko Button lbutton = sender as Button; string text = lbutton.text; //porovnáme text a zavoláme příslušnou událost if (lbutton.text == "Vložit kartu") //volání události Karta vložena atmservice.raisecardinsertedevent(workflowinstanceid); else if (lbutton.text == "Potvrdit PIN") //volání události PIN vložen atmservice.raisepinenteredevent(workflowinstanceid, txbinput.text); Metoda nejprve detekuje, z jakého tlačítka byla tato událost vyvolána, a podle toho zavolá jednu z metod ATMService, která probudí (Raise) některou událost z této služby. 36

37 Například po stisku tlačítka Potvrdit PIN se vyvolá metoda, která probudí událost PinEnteredEvent. Jako argumenty se této metodě předají identifikace instance workflow a vložený PIN. Pokud se workflow nachází ve stavu CardEnteredState, tato aktivita ho probudí a jako argument je mu doručen PIN. Jak bylo popsáno výše, PIN bude vyhodnocen a workflow se přesune do nového stavu. Při stisku tlačítka Vložit kartu se pouze probudí událost CardInserted, ale kromě ID workflow, kterému má být doručena, již není nutné přidávat další argumenty Obdržení a zpracování události o přechodu do nového stavu Kromě probouzení událostí, jež způsobují přechody mezi stavy workflow, poslouchá hostitelská aplikace také události, které jí posílá workflow. Takovou událostí je MenuTextEvent služby ATMService. Registrace EventHandleru k této události probíhá již při registraci služby, v inicializaci formuláře. V případě obdržení této události obdrží EventHandler argumenty události ve formě instance třídy UpdateMenuTextEventArgs. Tato instance má proměnnou MenuText, jež obsahuje řetězec se zprávou, kterou hostitelská aplikace zobrazí ve výstupním okně. Toto je řádek, kterým se přidá posluchač události: atmservice.menutextevent += new ATMService.UpdateMenuTextEventHandler(atmService_MenuTextEventHandler); Nyní je nutné implmentovat metodu atmservice_menutexteventhandler, která se stará o zpracování události. void atmservice_menutexteventhandler(object sender, UpdateMenuTextEventArgs e) //nastavíme RTF výstupního pole. Tedy nastavíme výstupní text outputwindow.text = e.menutext; V ideálním případě by vše mělo již fungovat. Narazíme zde ale na problém. V.NETu není povoleno updatovat nebo editovat grafické prvky, tedy GUI aplikace, z jiného vlákna než z vlákna, kterým byly vytvořeny. To je ale problém, protože instance workflow běží v jiném vlákně než samotná aplikace. Je tedy nutné obejít tento probléme pomocí nového delegáta, kterého vytvoříme přímo v hostitelské aplikaci. K tomuto delegátovi registrujeme tu samou metodu jako při registraci k události od WorkflowRuntimu a vyvoláme tohoto delegáta pomocí metody Control.Invoke(Delegate). Tím, že tuto metodu zavoláme na aktuálním formuláři, budou metody, které jsou s delegátem registrovány, spuštěny z aktuálního vlákna. V těle metody dále přidáme if klausuli, ve které otestujeme proměnnou Control.InvokeRequiered, jež je v.netu právě pro tento účel a určuje, zda je nutné Invoke provést. 37

38 Jinými slovy, když dojde k prvnímu volání metody z vlákna instance workflow, tak se pomocí proměnné InvokeRequiered zjistí, že je nutné volat metodu z aktuálního vlákna. To se provede pomocí nového delegáta, kterému se předají všechy parametry. Při druhém volání již není nutný nový Invoke a pouze se nastaví výstupní text aplikace. private delegate void UpdateMenuTextDelegate(object sender,updatemenutexteventargs e); void atmservice_menutexteventhandler(object sender, UpdateMenuTextEventArgs e) //Pokud je potřeba pustit metodu z jiného vlákna if (this.invokerequired) //Vytvoříme delegáta, s odkazem na tuto metodu UpdateMenuTextDelegate updatemenutext = new UpdateMenuTextDelegate(atmService_MenuTextEventHandler); //předáme argumenty, které obdržela tato metoda object[] args = new object[2] this, e ; //zavoláme delegáta z vlákna aktuálního formuláře this.invoke(updatemenutext, args); else outputwindow.text = e.menutext; 5.10 Shrnutí kapitoly o implementaci jednoduchého platebního bankomatu K vytvoření takovéto aplikace je tedy zapotřebí tří projektů: Workflow pro namodelování stavového diagramu aplikace Komunikační rozhraní Hostitelská aplikace obsahující uživatelské rozhraní Je nutné začít od komunikačního rozhraní, v němž se definují události, pomocí kterých mezi sebou mohou workflow a uživatelská aplikace komunikovat. Následně je možné namodelovat workflow pomocí workflow designéru. Zde je důležité si uvědomit, že každý stav musí obsahovat jednak aktivity, které se spustí při přechodu workflow do stavu, a jednak aktivity, jež umožní reagovat na události od hostitelské aplikace. Hostitelská aplikace musí obsahovat především instance třídy WorkflowRuntime a instanci komunikační služby. Je nutné implementovat volání především vyvolávání jednotlivých událostí, které jsou doručeny instancím workflow uvnitř WorkflowRuntime. Také je nutné implementovat odposlouchávání událostí, které workflow posílá hostitelské aplikaci. 38

39 6. Vývoj aplikací v prostředí SharePointu co je potřeba K vývoji na platformě SharePoint 2007 potřebujeme dva základní nástroje: SharePoint 2007 (na operačním systému Windows Server) Visual Studio 2008 Vývoj aplikací pro SharePoint 2007 má jednu podstatnou nevýhodu, a to fakt, že počítač, na kterém vyvíjíme, musí mít nainstalovaný SharePoint SharePoint 2007 je serverové řešení, a proto musí být nainstalován na operační systém Microsoft Windows Sever. Zároveň je postaven na databázi a ve standardní instalaci je obsažen SQL Server Pokud tedy nemáte vývojový počítač, který by používal Microsoft Windows Server, nebo máte, ale nechcete si instalovat SharePoint přímo na vývojový počítač, nabízí se vhodná a nejčastěji používaná alternativa, a to vytvoření virtuálního prostředí. K tomu je nejvhodnější využít program MS Virtual PC, který je zdarma. Nebudeme zde uvádět konkrétní návod na instalaci SharePointu ve virtuálním prostředí. Zmíníme jen pár detailů. Při vytváření nové Virtual Machine je nutné specifikovat: Množství operační paměti, které chceme virtuálnímu stroji přidělit. Vhodné jsou 2Gb, nicméně při nedostatku paměti na hostujícím stroji lze použít pouze 1Gb. Velikost disku a typ disku. Na virtuální stroj bude nutné nainstalovat kromě operačního systému i SharePoint 2007 a Visual Studio Pokud nebudete instalovat další větší aplikace, tak by 10 GB mělo být dostatečných. Pokud vytvoříte disk typu Fixed size, můžete zrychlit výkon virtuálního stroje, neboť diskový prostor se nealokuje na začátku a nebude nutné postupné rozšiřování. Ztratíte tím ale možnost disk rozšířit, pokud vám na něm dojde místo. Jakmile máte připraven vývojový počítač s SharePointem a Visual Studiem 2008, můžeme se pustit do vývoje. 39

40 7. Popis aplikačního rozhraní MS SharePoint MS SharePoint je intranetový informační systém. Vstupem do tohoto systému je webové rozhraní. SharePoint si klade za cíl sloužit jako server kombinující správu obsahu (CMS), správu procesů (Workflow) a umožnění spolupráce a komunikace pro jeho uživatele. Pomocí webu se mohou uživatelé podílet na vytváření obsahu webu. SharePoint obsahuje šablony pro vytváření seznamů, osobních webů, knihoven dokumentů, diskuzních skupin, dotazníků, kalendářů, webových galerií a dalších typů obsahu. Tyto šablony může běžný uživatel využít bez hlubších znalostí technologie, vytváření obsahu tedy probíhá pouze prostřednictvím webového rozhraní. Následující obrázek znázorňuje webové rozhraní portálové stránky. Obrázek 33: Webové rozhraní SharePointu Kromě toho, že se uživatelé sami podílí na vytváření obsahu webu, mohou také rozhodovat o tom, jakým způsobem bude obsah zobrazen a kdo k němu bude mít přístup. 7.1 Architektura MS SharePoint Architekturu systému MS SharePoint popisuje následující diagram: 40

41 Architektura technologie SharePoint Windows SharePoint Services Definice práv a uživatelů Grafické rozhraní Podpora pro Workflow Podpora Administrace Napojení na Active Directory Integrace se službami MS Office Prohledávání obsahu Napojení na mail server SQL Server IIS ASP.NET.NET Framework Workflow Foundation Windows 2003 / 2007 Server Základem pro MS SharePoint je Windows Server. Další podmínkou je přítomnost databázového SQL Serveru a IIS (Internet Information Services). Internet Information Service je druhým nejpoužívanějším webovým serverem hned po Apache Serveru, který je známý vývojářům pracujícím s programovacími jazyky JAVA nebo PHP (PHP Hypertext Preprocessor). Je to sada služeb, jež umožňují dynamické vytváření webového obsahu, o který si uživatel zažádá, prostřednictvím webového prohlížeče. Internet Information Service umožňuje publikování webových aplikací napsaných pomocí technologie ASP.NET. Protože SharePoint je intranetový portál, je tvořen sadou ASPX souborů, které definují stránky tohoto portálu, a sadou dynamických knihoven, jež jsou s těmito stránkami linkovány a zajišťují logiku tohoto portálu. SharePoint tedy potřebuje ke svému chodu Internet Information Service, aby mohly být publikovány webové formuláře, které ho tvoří. Dalším důležitým stavebním kamenem je SQL Server. SharePoint je server sloužící ke správě obsahu a všechna data, která jsou do něj přes webové rozhraní ukládána, musí být uložena do SQL databáze. Další vrstvou je poté.net Framework. V diagramu jsou pro ilustraci zobrazeny komponenty ASP.NET a Workflow Foundation, ačkoliv jsou již součástí.net Frameworku. Nad těmito vrstvami je následně postaveno aplikační rozhraní SharePointu, označované jako Windows SharePoint Services. 41

42 7.2 Definice přístupových práv SharePoint je napojen na technologii Active Directory, která je postavená na protokolu LDAP (Lightweight Directory Access Protocol). Active Directory je centrálním úložištěm uživatelů operačních systémů Windows, kteří jsou rozděleni do takzvaných domén. Uživatel přihlašující se k počítači pod operačním systémem Windows se může přihlásit přímo na tento počítač anebo do domény. Přihlášením do domény je mu zpřístupněna organizační struktura na základě jeho uživatelských práv nastavených v této doméně. Domény velice často kopírují personální struktury firem a organizací. SharePoint používá autentifikaci na základě LDAP protokolu vůči Active Directory Serveru. Pokud se uživatel přihlásí k webu SharePointu, je podle aktuálního kontextu zjištěn uživatel přihlášený k operačnímu systému Windows, a pokud má nastavena dostatečná práva, je vpuštěn do SharePointu. Pokud práva nemá, zobrazí se výzva ke vložení identifikačních údajů, které jsou potom zkontrolovány pomocí Active Directory Serveru. 7.3 Objektový model SharePoint SharePoint Object Model označuje knihovnu tříd uspořádanou do několika jmenných prostorů (namespaces), pomocí které je SharePoint server naprogramován a která je otevřena vývojářům k jeho editaci. Každá část webové stránky, jakýkoliv seznam, webová galerie, soubor, položka seznamu nebo jiný typ obsahu, vše má svůj ekvivalent v objektovém modelu. Programátoři mohou ke všem těmto objektům pomocí tohoto modelu přistupovat (3). Objektový model Windows SharePoint Services je rozdělen na dva základní jmenné prostory. Těmi jsou Microsoft.SharePoint namespace a Microsoft.SharePoint.Administration. První jmenný prostor umožňuje přístup k obsahu webů, druhý definuje třídy, které slouží k přístupu k nižším úrovním, jako jsou servery, webové služby, databázová připojení serverové farmy a další. Namespace Microsoft.SharePoint umožňuje vývojářům přístup k obsahu webu. Tento jmenný prostor obsahuje desítky tříd detaily lze najít v dokumentaci objektového modelu SharePointu (4), my se v následujícím diagramu omezíme jen na několik základních tříd. 42

43 SPSite SPUser SPUser sdssds SPWeb SPFolder SPFile SPList SPField SPListItem Obrázek 34: Objektový model SharePointu Každá třída SPSite neobsahuje referenci na konkrétní třídu SPWeb, ale obsahuje třídu SPWebCollection, tedy několik tříd SPWeb v této kolekci, reprezentujících několik konkrétních webů. Stejně tomu je i u všech ostatních tříd. Jména tříd jsou poměrně jednoznačná a není potřeba vysvětlovat, ke kterým položkám pomocí těchto tříd získáme přístup. Prefix SP je součástí jmenné konvence a mají ho všechny třídy související s objektovým modelem SharePointu. K diagramu je přiložen obrázek se zobrazeným seznamem v SharePointu. Ten ukazuje, ke kterým grafickým komponentám třídy diagramu umožňují přístup. 43

44 8. Manipulace s položkami v seznamu pomocí SharePoint API V tomto příkladu vytvoříme jednoduchou aplikaci, která nám umožní pochopit základ programování v SharePointu, čímž jsou práce se seznamy a položkami. Cílem tohoto příkladu bude vytvořit v SharePointu seznam, který bude reprezentovat katalog produktů. Každý produkt bude obsahovat sloupec Je v prodeji, jenž bude moci nabývat hodnot Ano/Ne. Naprogramujeme jednoduchou konzolovou aplikaci, jež projde celý katalog produktů a vymaže z něj položky, které již nejsou v prodeji. 8.1 Příprava seznamu v SharePointu Nejprve připravíme seznam a položky, se kterými budeme později pomocí aplikačního rozhraní SharePointu pracovat. Administrace a vytváření obsahu v SharePointu není obsahem této brožury, navíc jde o oblast velice intuitivní. Nebudeme zde tedy popisovat všechny kroky, jež jsou nutné, ale pouze ty, které budou souviset s níže popsanými ukázkami kódu. Vytvoříme si tedy seznam v SharePointu, který pojmenujeme například Katalog produktů. Obrázek 35: SharePoint vytvoření nového seznamu Do tohoto seznamu přidáme sloupec Popis a sloupec Je v prodeji, který bude typu Yes/No tedy booleovská hodnota. V české verzi je to sloupec typu Ano/Ne : 44

45 Obrázek 36: SharePoint vytvoření nových polí v seznamu Kromě těchto dvou sloupců bude seznam obsahovat ještě další tři sloupce: Created By, Modified by a Title ; tyto sloupce jsou automaticky vytvořeny SharePointem při vytváření nového seznamu. Sloupec Title využijeme, ale přejmenujeme ho na Produkt. Do seznamu vytvoříme ručně několik položek. Výsledek by měl vypadat zhruba takto: Obrázek 37: Ukázkový seznam pro práci s položkami 8.2 Vytvoření projektu ve Visual Studiu Nyní se již pustíme do programování. Ve Visual Studiu 2008 založíme nový projekt konzolovou aplikaci. Protože v projektu budeme používat API SharePoint, musíme na něj přidat referenci. V dialogu pro přidání referencí vybereme Windows SharePoint Services. 45

46 Obrázek 38: Vložení referencí na objektový model SharePointu Projekt již obsahuje vygenerovanou třídu Program.cs s Main metodou. Po přidání reference na API SharePoint můžeme přidat direktivu using. using Microsoft.SharePoint; 8.3 Poznámka o uvolňování objektu objektového modelu SharePointu Nyní již můžeme používat třídy a objekty z programového rozhraní SharePointu. Ještě nez začneme, je nutné zmínit, že při programování v SharePointu můžeme narazit na některé zvláštnosti oproti tradičním metodám, na které jsme zvyklí v prostředí.net. Jednou z nich je nutnost uvolňovat některé objekty z paměti ručně. Konkrétním příkladem jsou například objekty typu SPWeb a SPSite, které použijeme v následující ukázce. Tyto dvě třídy nám umožní získat instanci portálové stránky SharePointu (SPSite) a libovolného podwebu (SPWeb). Tyto objekty jsou navrženy jako managed objekty, to znamená, že jsou uchovávány na haldě (heap) objektů, kterou spravuje.net CLR (Common Language Runtime). O vyčištění těchto objektů se za normálních okolností stará GC (Garbage Collector). Nicméně tyto objekty využívají další unmanaged kód a paměť, tedy využívají objekty, které nejsou součástí.netu a jsou uchovány přímo v paměti a ne na haldě. Protože managed část je mnohem menší než unmanaged část, GC, který by za normálních okolností objekt z paměti vyčistil, si této malé části objektu nevšímá, a tak spolu s ní zůstává v paměti uchovaná i mnohem větší unmanaged část (která již ovšem také není používána). Je tedy nutné objekt uvolnit ručně. 46

47 K uvolnění stačí na objektu zavolat metodu Dispose(). V C# máme druhou možnost a tou je použití klíčového slova using. Objekt, který je ohraničen pomocí klíčového slova using, je uvolněn z paměti hned po dokončení takto označeného kódu. Toto vysvětlení přispěje k pochopení kódu, který vytvoříme. 8.4 Zdrojový kód příkladu Následuje přímo ukázka zdrojového kódu příkladu. Jde o jednoduchý příklad, a tak bude vše provedeno ve stupním bodě aplikace, tedy v metodě Main. Následující kód můžete zkopírovat přímo do své aplikace. static void Main(string[] args) //získám stránku SharePointu using(spsite ospsite = new SPSite(" //otevřu web na dané stránce using (SPWeb ospweb = ospsite.openweb()) //získám seznam "Katalog produktů" SPList osplist = ospweb.lists["katalog produktů"]; //získám kolekci položek a jejich počet SPListItemCollection ocollection = osplist.items; int itemscount = ocollection.count; for (int i = itemscount-1; i >= 0; i--) //vezmu i-tou položku v kolekci webů SPListItem oitem = ocollection[i]; //zjistím, zda je položka v prodeji bool vprodeji = (bool)oitem["je v prodeji"]; if (!vprodeji) //smažu položku, pokud není v prodeji ocollection.delete(i); Console.WriteLine("Smazána položka číslo: " + i); Na počátku získáme objekt SPSite. Objekt SPSite reprezentuje celou kolekci stránek (týmových webů, podwebů, všechny stránky, které vytvoříme na daném portálu). Když ale do konstruktoru odkážeme přímo na danou stránku, získáme kolekci stránek obsahující pouze tu, kteoru žádáme pomocí odkazu education. Tuto stránku pak můžeme otevřít pomocí metody OpenWeb. SPSite ospsite = new SPSite(" SPWeb ospweb = ospsite.openweb(); 47

48 Další možností, jak získat stránku, by bylo získat kolekci stránek celého portálu a z této kolekce vybrat pouze stránku, kterou potřebujeme: SPSite ospsite = new SPSite(" SPWeb ospweb = ospsite.allwebs["education"]; Oba přístupy jsou ekvivalentní a v objektu SPWeb dostaneme požadovaný Web, v terminologii uživatelů SharePointu je ovšem většinou nazýván Stránka. Ve výše uvedených ukázkách jsme pro přehlednost vynechali bloky direktivy using. Ovšem v případě, že pracujeme s objekty SPSite a SPWeb, je nutné se o uvolnění paměti vždy starat. Pokud nechceme použít using blok, můžeme na jednotlivých objektech, které implementují rozhraní IDisposable, zavolat metodu Dispose(), jež se postará o uvolnění objektu z paměti. ospweb.dispose(); ospsite.dispose(); Tyto techniky jsou velice dobře popsané v Microsoft Developer Network knihovně v článku Best Practices: Using Disposable Windows SharePoint Services Objects (MSDN). Jakmile máme objekt SPWeb, můžeme pomocí jména získat seznam, který nás zajímá, tedy získat kolekci a počet jeho položek: SPList osplist = ospweb.lists["katalog produktů"]; SPListItemCollection ocollection = osplist.items; int itemscount = ocollection.count; Následně provádíme iteraci. V každém kroku iterace získáme i-tou položku v seznamu a zjistíme, zda je produkt v prodeji. Přetypování na proměnnou typu bool funguje samozřejmě pouze, pokud je sloupec seznamu typu Ano/Ne. SPListItem oitem = ocollection[i]; bool vprodeji = (bool)oitem["je v prodeji"]; 8.5 Závěr, poznámky k příkladu Poznámka k iteraci Pokud iterujeme položky, jež během iterace mažeme, nemůžeme použít foreach klauzuli a metodu Delete(), kterou nabízí objekt SPListItem. Při další iteraci hned po prvním smazání se změní iterovaná kolekce a obdržíme následující výjimku. InvalidOperationException: Collection was modified; enumeration operation may not execute. Dalším problém může nastat, pokud zvolíme iteraci odspodu, tedy: 48

49 for (int i=0 ; i <itemscount; i++) //vezmu i-tou položku v kolekci webů SPListItem oitem = ocollection[i]; oitem.delete(); V takovém případě, pokud by došlo alespoň k jednomu smazání položky, změní se indexování položek v kolekci a ke konci iterace (podle toho, kolik položek bylo smazáno) obdržíme výjimku ArgumentOutOfRangeException, protože položky na pozici i již nebudou v kolekci existovat. Závěr Po spuštění programu by měly v seznamu zůstat jen ty položky, které mají pole Je v prodeji nastaveno na Ano. To je vše k prvnímu příkladu. Mělo by být jasné, že základem pro přístup k objektům SharePointu jsou třídy SPSite a SPWeb, které nám umožní nalézt danou stránku. Pomocí objektu SPList můžeme s manipulovat jednotlivými seznamy a pomocí objektu SPListItem můžeme libovolně manipulovat i s jednotlivými položky. Znalosti z této části bude možné využít v Příkladu 2, kde provedeme import uživatelských kontaktů z ActiveDirectory do seznamu v SharePointu. 49

50 9. Ukázková aplikace: Import kontaktů z ActiveDirectory do SharePointu Jedním z možných využití seznamů v SharePointu může být například zobrazení všech kontaktů z určité skupiny v Active Directory v seznamu na SharePointu. V tomto příkladu bych chtěl vytvořit jednoduchou konzolovou aplikaci, která umožní projít uživatele v Active Directory, a pokud má uživatel alespoň jeden z kontaktů telefon nebo , vytvořit v SharePointu ekvivalentní položku, do níž bude uživatel importován. Než začneme importovat, je nutné vytvořit seznam v SharePointu, do kterého budeme chtít kontakty přesunout. Vytvoříme pro tento účel standardní seznam kontaktů podle šablony, která je v SharePointu již připravená. Tuto šablonu lze najít při vytváření nového obsahu webu ve skupině Komunikace (Communications). Tato šablona již obsahuje sloupce jako , Příjmení, Telefon, a navíc jsou tyto sloupce identifikovatelné pod stejným identifikátorem (GUID) na všech jazykových mutacích SharePointu. 9.1 Přístup do Active Directory K provedení takového importu bude nutné nejprve přistoupit do Active Directory a získat odtud uživatelská data. Active Directory je hierarchicky uspořádaná databáze, ve které jsou shromážděna data o všech síťových prvcích v síti. V zásadě se jedná o zařízení a uživatele. Hierarchie Active Directory začíná organizací (Organization) a následují organizační jednotky (Organization Units); ty již obsahují jednotlivé síťové zdroje a zařízení zjednodušeně řečeno uživatele a počítače. V.NETu lze pro přístup k Active Directory použít namespace System.DirectoryServices. Třídy z tohoto namespace využívají rozhraní Active Directory Services Interface. ADSI je sada programových rozhraní, která umožňuje všeobecnou správu síťových objektů. ActiveDirectory Services Interface je možné použít s několika různými síťovými zprostředkovateli, především WinNT, Novel Netware Directory Services (NDS), Light Directory Access Protocol (LDAP) a Internet Information Services (IIS). Pro přístup k Active Directory je vhodné použít Light Directory Access Protocol, jemž je jediným z výše zmíněných zprostředkovatelů, který podporuje i prohledávání stromu síťové struktury. Jedná se o síťový protokol postavený nad síťovou vrstvou TCP/IP, jemž umožňuje přístup k síťovým objektům. Ze tříd, které obsahuje System.DirectoryServices, budeme používat především následující dvě: DirectoryEntry základní třída definující jeden objekt ve struktuře Active Directory, ať již jde o počítač, uživatele nebo definici organizační jednotky. DirectorySearcher třída, která umožňuje prohledávání Active Directory. 50

51 Objekty typu DirectoryEntry a DirectorySearcher implementují rozhraní IDisposable, a je tedy nutné zavolat funkci Dispose() k uvolnění paměti zabrané těmito objekty. Pokud použijeme direktivu using, této nutnosti se vyhneme a k uvolnění dojde ihned po dokončení akcí definovaných v dané direktivě. 9.2 Vytvoření projektu, přidání referencí Opět půjde o konzolovou aplikaci. Vytvoříme tedy projekt ve Visual Studiu a kromě referencí na Windows SharePoint Service do něj přidáme i reference na namespace System.DirectoryServices. Obrázek 39: Vložení referencí na objekty sloužící pro přístup k Active Directory Průběh programu rozdělíme do dvou částí: získání dat z Active Directory a nahrání dat do SharePointu. Abychom měli strukturu pro uchování a manipulaci s daty, vytvoříme třídu User, která bude obsahovat pole určující Jméno, Příjmení, a Telefon. 51

52 class User public String FirstName get; set; public String SurName get; set; public String get; set; public String Phone get; set; public User() public User(String fn, String sn, String em, String ph) this.firstname = fn; this.surname = sn; this. = em; this.phone = ph; Než začneme programovat, je nutné přidat do projektu referenci na jmenný prostor Microsoft.SharePoint a také referenci na System.DirectoryService. V hlavičce souboru potom použijeme tyto reference: using System.DirectoryServices; using Microsoft.SharePoint; 9.3 Získání uživatelských dat z Active Directory Teď již můžeme přistoupit k implementaci získání dat z Active Directory. Vytvoříme statickou metodu, jejímž jediným parametrem bude řetězec se síťovou adresou Active Directory serveru a bude vracet objekt typu List<User>, tedy seznam uživatelů. 52

53 public static List<User> GetUsersFromADServer(string url) List<User> users = new List<User>(); using (DirectoryEntry searchroot = new DirectoryEntry(url)) using (DirectorySearcher searcher = new DirectorySearcher(searchRoot)) //Nastaveni parametru prohledavani String filter = "(&(givenname=*)(sn=a*)(department=*) + "(objectclass=user)(mail=*)(telephonenumber=*))"; searcher.filter = filter; searcher.pagesize = 10000; searcher.propertiestoload.add("sn"); searcher.propertiestoload.add("givenname"); searcher.propertiestoload.add("mail"); searcher.propertiestoload.add("telephonenumber"); using (SearchResultCollection resultcollection = searcher.findall()) if (resultcollection.count > 0) foreach (SearchResult result in resultcollection) //Volam metodu, ktera vytvori uzivatele z vysledku hledani User user = new User(); using (DirectoryEntry userentry = result.getdirectoryentry()) user.firstname = userentry.properties["givenname"].value as String; user.surname = userentry.properties["sn"].value as String; user. = userentry.properties["mail"].value as String; user.phone = userentry.properties["telephonenumber"].value as String; //pridam uzivatele do seznamu users.add(user); //using DirectoryEntry //foreach result //pokud count>0 //using SearchResultCollection //using DirectorySearcher //using DirectoryEntry return users; Prní řádek otevře kořenový uzel v Active Directory, ze kterého budeme chtít začít prohledávání. Dále vytvoříme nový objekt DirectorySearcher, který nám umožní prohledávání. Jak již bylo řečeno, Active Directory je stromová, hierarchicky uspořádaná databáze. Prohledávání tedy musí probíhat rekurzivně do hloubky stromu. DirectorySearcher v tomto směru usnadňuje práci, a tak není nutné metody pro rekurzivní prohledávání programovat. 53

54 Další řádka definuje řetězec, který později použijeme jako filtr pro prohledávání. Jedná se o syntaxi filtrování LDAP protokolu. Znak & za první závorkou značí logickou spojku AND, tedy že budeme chtít splnění všech výrazů uzavřených v takto označené závorce. (& (givenname=*) (Sn=A*) (mail=*) (telephonenumber=*) (objectclass=user) ) V zásadě zde říkáme, že požadujeme pouze takové objekty typu user (tedy pouze uživatele, tím vypadnou počítače, kontakty a další typy objektů), které mají vyplněné pole Jméno, Příjmení, Telefon a . Navíc požadujeme pouze objekty, u nichž pole Příjmení začíná velkým písmenem A. Vlastnost PageSize určuje maximální omezení počtu objektů, které budou nalezeny pomocí třídy DirectorySearcher. Jak již bylo řečeno, DirectorySearcher prohledává rekurzivně, říkáme mu tedy, po kolika nalezených objektech má vyhledávání zastavit. Následně určíme vlastnosti, jež chceme získat u prohledávaných objektů. Následující řádek přidá vlastnost Sn, která odpovídá příjmení uživatele. searcher.propertiestoload.add("sn"); Po zavolání metody FindAll() je navrácen objekt typu SearchResultCollection, který můžeme iterací procházet. Tento objekt obsahuje množinu objektů SearchResult. Ty již obsahují výsledky vyhledávání. Je vhodné použít metodu GetDirectoryEntry(), která z daného výsledku vrátí objekt DirectoryEntry, jenž reprezentuje vyhledaný objekt ve stromové struktuře Active Directory. Z tohoto objektu je pak již poměrně snadné získat požadované vlastnosti toho objektu. DirectoryEntry userentry = result.getdirectoryentry(); user.firstname = userentry.properties["givenname"].value as String; 9.4 Import získaných dat do seznamu kontaktů v SharePointu Druhou částí bude metoda, která data získaná z ActiveDirectory nahraje získané uživatele jako položky dp seznamu v SharePointu. Vytvoříme tedy metodu, jejíž argumenty budou: seznam získaných uživatelů, které chceme nahrát do SharePointu, adresa webu a jméno seznamu kontaktů. 54

55 public static void UploadToSharePoint(string siteurl, string listname,list<user> users) using (SPSite site = new SPSite(siteUrl)) using (SPWeb web = site.openweb()) SPList list = web.lists[listname]; foreach (User user in users) SPListItem item = list.items.add(); item[spbuiltinfieldid.firstname] = user.firstname; item[spbuiltinfieldid.title] = user.surname; item[spbuiltinfieldid. ] = user. ; item[spbuiltinfieldid.workphone] = user.phone; item.update(); list.update(); Struktura metody pro získání objektu SPList v SharePointu je stejná jako v předchozím příkladu. Jakmile získáme SPList reprezentující seznam, do kterého chceme objekty naimportovat, procházíme iterací jednotlivé uživatele v seznamu users. Pro přidání nové položky do seznamu je použito následující volání: SPListItem item = list.items.add(); Metoda Add() přidá do seznamu novou položku a vrátí ukazatel na tuto položku typu SPListItem. K takto získanému objektu můžeme následně přistoupit a modifikovat jeho vlastnosti. Změny se v SharePointu neprojeví, dokud nezavoláme metodu Update() na položce SharePointu a následně na seznamu v SharePointu. Za zmínku stojí použití třídy SPBuildInFieldId. Tato třída obsahuje GUID pro pole, která jsou v SharePointu již obsažená. Pokud tedy použijeme standardní seznam kontaktů, který již obsahuje standardní pole v SharePointu, můžeme použít ID, jež tato třída obsahuje k referencování těchto polí. Například pro vepsání do sloupce ová adresa ve standardním seznamu kontaktů použijeme následující volání. item[spbuiltinfieldid. ] = user. ; V Main metodě vstupním bodu konzolové aplikace již jen zavoláme po sobě tyto dvě metody. 55

56 static void Main(string[] args) List<User> users = GetUsersFromADServer("LDAP://sr-ad-001.mountfield.lad"); UploadToSharePoint(" "Kontakty", users); 9.5 Závěr Jak je vidět, import uživatelských dat z Active Directory může být poměrně jednoduchou záležitostí. V tomto případě je vždy nutné myslet na uvolňování objektů z paměti, tedy na volání metody Dispose() anebo na používání klíčového slova using. Pokud bychom tak nečinili a program by se spouštěl například pravidelně, tak by při každém spuštění docházelo k alokaci paměti, která by nikdy nebyla uvolněná, a to by mohlo mít vliv na výkonnost serveru. 56

57 10. Přidání vlastních ASP stránek do SharePointu SharePoint ukládá většinu svého obsahu do své databáze obsahu (nejčastěji MS SQL Server). Všechny stránky, které jsou vytvořeny nebo upraveny, ať již z webového rozhraní SharePointu nebo pomocí SharePoint Designeru, jsou uloženy v databázi SharePointu. Tyto stránky ale nemohou obsahovat ani provádět vlastní kód. Existuje však možnost, jak přidat do SharePointu vlastní stránky, které budou obsahovat logiku zkompilovanou do dynamické knihovny, a jak spouštět tyto stránky v kontextu SharePointu. Tímto způsobem je přidání stránek do složky LAYOUTS v úlu SharePointu. (Anglicky je toto umístění označováno jako SharePoint 12 HIVE. ) SharePoint 12 HIVE budeme v následujícím textu označovat jako úložiště SharePointu a cesta k němu je: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12 Složka LAYOUTS má tu vlastnost, že pomocí IIS serveru dochází k její virtualizaci do všech webů SharePointu. Toho můžeme využít, neboť jakýkoliv ASPX soubor, který přidáme, bude virtualizován do všech týmových webů a přístupných z SharePointu. Cílem tohoto příkladu bude zobrazit v SharePoint stránku, na které se zobrazí jméno aktuálně přihlášeného uživatele a aktuální čas. Obrázek 40: Vestavěná stránka v SharePointu zobrazující aktuálního uživatele a datum 57

58 10.1 Master Pages Než začneme vytvářet stránky, je nutné si uvědomit, že SharePoint využívá takzvaných Master Pages. Master Pages nahrazují v ASP.NET dědičnost grafických komponent. Master Pages jsou vlastně šablonami. Například na hlavním portálu SharePointu jsou levý a horní panel již definovány příslušnou Master Page a nový obsah je možné vkládat pouze do hlavního okna ohraničeného těmito panely. Master Pages obsahují speciální tagy ContentPlaceHolder, které slouží jako kontejnery pro obsah, jenž je později vložen prostřednictvím stránek, které od této Master Page dědí. Následující příklad ukazuje jednoduchou Master Page: <%@ Master Language="C#" AutoEventWireup="true" CodeBehind="Demonstration.master.cs" Inherits="MPDemonstration.Demonstration" %> <!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" " <html xmlns=" > <head runat="server"> <title>demonstrační Master Page</title> </head> <body> <form id="form1" runat="server"> <div> <p>toto je ještě část Master Page</p> <asp:contentplaceholder ID="demoContent" runat="server"> </asp:contentplaceholder> </div> </form> </body> </html> A nyní příklad stránky, která tuto Master Page používá. V atributu MasterPageFile je odkaz na výše definovanou Demonstration.Master. <%@ Page Language="C#" MasterPageFile="~/Demonstration.Master" AutoEventWireup="true" CodeBehind="MPDemonstration.aspx.cs" Inherits="MPDemonstration.MPDemonstration" Title="Untitled Page" %> <asp:content ID="Content1" ContentPlaceHolderID="demoContent" runat="server"> <p>a toto již je z obsahu stránky, která dědí Master Page</p> </asp:content> Výsledek předchozího příkladu vypadá následovně: 58

59 Obrázek 41: Ukázka využití Master Page 10.2 Vytvoření projektu a přidání referencí Nyní se již pustíme do vývoje vlastní stránky pro SharePoint. Vytvoříme nový projekt typu WebApplication ve Visual Studiu a následně upravíme strukturu projektu, tak aby vypadala následujícím způsobem: Obrázek 42: Struktura webového projektu 59

60 Nyní upravíme soubor SPCustomPage.aspx. Jelikož SharePoint používá Master Pages, musíme vědět, jak se jmenují kontejnery typu ContentPlaceHolder, které můžeme použít a do nichž je možné vložit vlastní obsah. My pro svůj obsah využijeme kontejner s ID PlaceHolderMain. Do tohoto kontejneru umístíme to, co na stránce SharePointu chceme zobrazit, tedy aktuálně přihlášeného uživatele a aktuální čas. <asp:content ContentPlaceHolderID="PlaceHolderMain" runat="server"> <p>je právě:</p> <asp:textbox ID="txtActualTime" runat="server"></asp:textbox> <p>a jste přihlášen jako uživatel:</p> <asp:textbox ID="txtActualUser" runat="server"></asp:textbox> </asp:content> Naše stránka tedy obsahuje tag <asp:content>, ve kterém jsou dva objekty typu TextBox. Ty využijeme ke zobrazení jména aktuálního uživatele a aktuálního času. Nyní je nutné dopsat potřebnou logiku do souboru, který je za naší ASPX stránkou Logika webové stránky Protože k zisku informací o aktuálním uživateli potřebujeme objekty SharePoint API, je nutné použít následující jmenné prostory. using Microsoft.SharePoint; using Microsoft.SharePoint.WebControls; Ve jmenném prostoru Microsoft.SharePoint je objekt SPUser, který přímo reprezentuje uživatele v SharePointu. Abychom získali aktuálního uživatele, budeme potřebovat aktuálně otevřený web. Ten získáme prostřednictvím třídy SPContext, která je ve jmenném prostoru Microsoft.SharePoint.WebControls. Nyní již přistoupíme ke konkrétní implementaci. Vytvoříme ve třídě dvě základní vlastnosti ActualTime a ActualUser a jejich obsah následně v přepsané metodě OnLoad() vložíme do textových polí, která jsme připravili v ASPX formuláři. K získání Master Page z galerie šablon v SharePointu budeme potřebovat objekt SPWeb, reprezentující aktuální otevřenou stránku v SharePointu. 60

61 public partial class SPCustomPage : System.Web.UI.Page private SPWeb teamsite; public String ActualTime get return DateTime.Now.ToString("hh:mm:ss"); public String ActualUser get return SPContext.Current.Web.CurrentUser.Name; protected override void OnPreInit(EventArgs e) base.onpreinit(e); //ziskame SPWeb this.teamsite = SPControl.GetContextWeb(Context); //nastavi se masterpage teto stranky stejny jako masterpage webu this.masterpagefile = teamsite.masterurl; protected override void OnLoad(EventArgs e) base.onload(e); txtactualtime.text = this.actualtime; txtactualuser.text = this.actualuser; Nejprve definujeme dvě vlastnosti: ActualTime a ActualUser. ActualTime pouze vrátí aktuální čas ve formátu HH:MM:SS. Vlastnost ActualUser vrátí aktuálně přihlášeného uživatele. Toho získáme z objektu SPWeb, který reprezentuje aktuálně otevřený web. Díky tomu, že kód je prováděn v prostředí ASP.NET, můžeme použít objekt SPContext, který nám přes svou vlastnost Current vrátí aktuálně otevřený objekt typu SPWeb. Vyhneme se tak získávání objektu typu SPWeb pomocí konstruktoru, tak jak to bylo provedeno v předchozích příkladech. return SPContext.Current.Web.CurrentUser.Name; Je nutné poznamenat, že i když používáme objekt typu SPWeb, který implementuje rozhraní IDisposable, je zakázáno zde volat metodu Dispose()nebo použít klíčové slovo using, a nutit tak Garbage Collector k úklidu objektu z paměti. Garbage Collector by se pokusil z paměti uvolnit objekt SPWeb, který jsme sami nevytvořili a který reprezentuje aktuální otevřený Web v SharePointu. 61

62 Velice důležité je přepsání metody OnPreInit(). Ve výše uvedeném příkladu na použití Master Pages obsahovala stránka obsahu v directivě Page odkaz na svou mateřskou Master Page, tak jak je ukázano níže: <%@ Page Language="C#" MasterPageFile="~/Demonstration.Master" > To ovšem nemůžeme provést, protože chceme použít jednu z defaultních Master Page SharePointu, tedy Master Page uloženou v Galerii v databázi SharePointu. Pokud bychom například zkopírovali tuto Master Page z Galerie do adresáře projektu, nepůjde projekt zkompilovat, protože Master Page SharePointu obsahují odkazy na další stránky a dynamické knihovny SharePointu. Je tedy nutné přepsat Master Page dynamicky v metodě OnPreInit(), která se provede před načtením stránky. this.teamsite = SPControl.GetContextWeb(Context); //nastavi se masterpage teto stranky stejny jako masterpage webu this.masterpagefile = teamsite.masterurl; Nejprve získáme aktuálně otevřený objekt SPWeb a následně použijeme Master Page z tohoto objektu. Poslední přepsanou metodou je metoda OnLoad(), která se provede v momentě načtení stránky. Zde již pouze nastavíme hodnoty vlastností Text výstupních TextBoxů na požadované hodnoty. Výslednou knihovnu budeme chtít nakopírovat do BIN složky, aplikace SharePointu v Internet Information Services Serveru, bude o ní ještě řeč. Ta je standardním umístěním dynamických knihoven pro všechny ASP.NET webové aplikace. Dynamické knihovny v tomto umístění nemají ve standardním nastavení webové aplikace přístup k objektovému modelu SharePointu. Pokud se o přístup k objektovému modelu SharePointu pokusí, CLR (Common Language Runtime) vyhodí následující výjimku: Request for the permission of type Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version= , Culture=neutral, PublicKeyToken=71e9bce111e9429c failed Proto bude nutné tyto knihovny nainstalovat zároveň i do Global Assembly Cache (GAC). Global Assembly Cache je centrálním uložištěm dynamických knihoven platformy.net a je přítomen na každém počítačí s nainstalovaným.net Frameworkem. K instalaci dynamické knihovny do GAC je nutné, aby dynamická knihovna měla takzvané silné jméno (Strong Assembly Name). Strong Assembly Name u dynamické knihovny zaručuje její jedinečnost. Strong Assembly Name je tvořené identitou dynamické knihovny a veřejným klíčem spolu s digitálním podpisem. Toto jméno vygenerujeme ze souboru dynamické knihovny a odpovídajícího privátního klíče, který musíme ve Visual 62

63 Studiu vytvořit. To provedeme na okně vlastností projektu na záložce Signing. Je nutné zaškrtnout checkbox Sign the assembly. Z nabídky Choose a strong name key file: vyberme New a v novém dialogu pojmenujeme a vytvoříme nový soubor primárního klíče. Není nutné, aby byl soubor chráněn heslem. Obrázek 43: Vytvoření Strong Name Key V této fázi máme projekt hotov, teď je nutné přesunout stránky do složky LAYOUTS a zajistit jejich přístupnost ze SharePointu. Tomu se věnuje následující podkapitola Deployment ASPX stránek do složky LAYOUTS V tuto chvíli máme stránky připravené a je nutné provést jejich nasazení. Nejprve je nezbytné nakopírovat ASPX soubory do složky LAYOUTS v úložišti aplikací SharePointu. C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\template\layouts Můžeme sem nakopírovat složku projektu společně se soubory ASPX a Web.config. 63

64 Obrázek 44: Nakopírování výsledného formuláře do složky LAYOUTS Nyní je nutné nastavit tuto složku jako webovou aplikaci v nastavení IIS serveru. Ve webových aplikacích naleznete aplikaci SharePointu po standardní instalaci je pojmenovaná SharePoint 80. Pokud otevřete složku _layouts, měli byste zde vidět obsah výše uvedené složky LAYOUTS na vašem disku. Obrázek 45: Nastavení IIS serveru 64

65 Kliknutím pravým tlačítkem na složce vaší nové aplikace zobrazte její vlastnosti. V aplikačním nastavení ( Application settings ) naleznete položku Jméno aplikace ( Application name ). Aplikace v této chvíli ještě nemá žádné jméno. Stiskem tlačítka Vytvořit ( Create ) toto jméno vytvoříte. Po vytvoření aplikačního jména by mělo okno vypadat následujícím způsobem: Obrázek 46: Nastavení složky aplikace v IIS serveru Zároveň uvidíte, že se v okně správce internetové Informační služby změní ikona složky na ikonu aplikace Deployment dynamické knihovny Nyní je nutné nahrát DLL knihovnu, ve které je zkompilovaná logika formuláře, do dvou umístění. Tím prvním je BIN složka Internetové informační služby a tím druhým GAC Global Assembly Cache. Umístění BIN složky webové aplikace SharePointu může být různé, nejčastěji jde o následující umístění (pokud byla provedena čistá instalace do prázdné IIS): C:\Inetpub\wwwroot\wss\VirtualDirectories\80\bin\ Do této složky nahrajte soubor SPCustomPage.dll, ve kterém je logika vašeho formuláře. Pokud tak neučiníte, objeví se po navigování prohlížeče na vaši nově vytvořenou 65

66 stránku (například následující chybová hláška: Could not load type 'SPCustomPage.SPCustomPage'. at System.Web.UI.TemplateParser.GetType(String typename, Boolean ignorecase, Boolean throwonerror) at System.Web.UI.TemplateParser.ProcessInheritsAttribute(String basetypename, String codefilebasetypename, String src, Assembly assembly) at System.Web.UI.TemplateParser.PostProcessMainDirectiveAttributes(IDictionary parsedata) Toto chybové hlášení v zásadě říká, že se nepovedlo nalézt třídu SPCustomPage ze jmenného prostoru SPCucstomPage, a to proto, že dynamická knihovna chybí ve složce BIN aplikačního serveru IIS. Dalším krokem bude nainstalovat tuto dynamickou knihovnu do Global Assembly Cache. Jak již bylo řečeno, Global Assembly Cache je centrálním uložištěm dynamických knihoven pro platformu.net na každém počítači. Jeho umístění se může opět lišit. Pokud používáte jako vývojový server Windows Server 2003, naleznete GAC na následující cestě: C:\WINDOWS\assembly\GAC_MSIL\ K instalaci dynamických knihoven do Global Assembly Cache se používá systémový nástroj GACUTIL. Užitečné je použít nástroj Visual Studio 2008 Command Prompt, který již má nastevenu cestu k nástroji GACUTIL. Intalaci provedeme příkazem gacutil i <Umístění a jméno dll souboru> Pokud se instalace povedla, mělo by váše výstupní okno vypadat jako na obrázku. Po instalaci do GAC bude nutné provést restart IIS serveru. Ten se provede příkazem iisreset. Pokud bychom instalaci do GAC vynechali, objevila by se v LOGu SharePointu nebo přímo na obrazovce po navigaci na vytvořenou stránku již zmíněná chyba: 66

67 Request for the permission of type Microsoft.SharePoint.Security.SharePointPermission, Microsoft.SharePoint.Security, Version= , Culture=neutral, PublicKeyToken=71e9bce111e9429c failed Nyní již můžete navigovat váš prohlížeč na adresu: Všiměte si, že dochází k virtualizaci složky LAYOUTS do všech webů na daném portálu. To má tu výhodu, že můžete vytvořenou stránku použít hned z několika webů na portálu. Tedy a obshují stejné stránky ve složce _layouts. 67

68 11. SharePoint a Workflow Foundation 11.1 Úvod do problematiky a cíle této části V první kapitole byly probrány základy Workflow Foundation a v kapitole druhé byly rozebrány základy programování pomocí objektového modelu SharePointu. Tato kapitola by měla objasnit, jak a za jakých podmínek lze integrovat Workflow Foundation a SharePoint, a vytvářet tak vlastní workflow přímo v SharePointu. Jinými slovy jak lze spojit znalosti z předchozích dvou kapitol tak, abychom s jejích pomocí byli schopni vytvořit workflow spustitelné v prostředí SharePointu. Během této kapitoly vytvoříme jednoduché workflow sloužící ke schválení zaměstnaneckého požadavku na nový software. Můžeme si představit větší firmu, používající elektronickou formu schvalování v případě, že její zaměstnanci potřebují ke své práci nový software. Následuje popis procesu schválení Schválení požadavku na nový software V praxi by měl proces schválení probíhat následujícím způsobem: 1. Uživatel potřebuje nový software otevře si intranetovou stránku, vyplní formulář, specifikuje, co konkrétně požaduje a za jakou orientační cenu. 2. Takto vyplněný formulář se uloží do knihovny dokumentů a automaticky se k němu spustí workflow. 3. Nadřízený uživatele, který vyplňoval formulář, dostane em informaci s žádostí o schválení od svého podřízeného. 4. Nadřízený klikne na odkaz, který mu byl zaslán elektronickou poštou. Otevře se mu webová stránka, kde bude vyobrazen obsah požadavku, a bude mu umožněno schválit požadavek, zamítnout požadavek nebo požádat o dodatečné informace. 5. Nadřízený by měl mít možnost požádat o dodatečné informace libovolnou osobu z firmy, například odborníka na IT nebo přímo žadatele. 6. Pokud si nadřízený vyžádal dodatečné informace, tazatel obdrží opět s odkazem na webovou stránku, na které bude moci doplnit požadované informace. 7. Workflow se vrátí k nadřízenému žadatele, který bude mít opět na výběr, co si přeje s požadavkem provést. Protože budeme workflow programovat jako stavové, bylo by vhodné nastínit, jak bude vypadat stavový diagram. V tomto případě půjde o velice jednoduchý stavový diagram pouze se třemi stavy. 68

69 Žádost o dodatečné informace Počáteční stav: Schválení požadavku Informace doplněny Čeká se na dodatečné informace Schválení nebo zamítnutí Workflow dokončeno Požadavek schválen nebo zamítnut Takto vytvořený stavový diagram odpovídá výše popsanému procesu schválení. Je jasné, že mezi stavem schválení a čekání na dodatečné informace může probíhat nekonečná smyčka. 69

70 12. Integrace Workflow Foundation do SharePointu Podpora workflow je ve Windows SharePoint Services docílena pomocí integrace objektového modelu SharePointu a Workflow Foundation. Jak bylo zmíněno v kapitole o základech Workflow Foundation, její využití nezáleží na hostující aplikaci. Pomocí komponenty WorkflowRuntime je možné hostovat workflow v jakékoliv aplikaci. V našem případě je hostitelskou aplikací MS SharePoint. Integrace workflow do SharePointu se od výše popsané integrace do okénkové aplikace v některých detailech liší, princip je ale v zásadě stejný. Objektový model SharePointu již obsahuje komponentu WorkflowRuntime, která je připravena spouštět workflow. Jak víme z popisu Workflow Foundation, zbývá tedy ještě dořešit umístění dynamické knihovny workflow a komunikace workflow s okolním světem. SharePoint Object Model Workflow Runtime GAC Global Assembly Cache Workflow.dll Workflow Instance Workflow Instance Workflow Instance Runtime Services SQL Persistance SQL Server Obrázek 47: SharePoint a Workflow propojení Windows SharePoint Services již obsahují RuntimeServices a současně nám nedovolují žádné další komunikační služby přidat. Nemůžeme tedy napsat vlastní službu, která by umožnila komunikaci workflow s další vnější aplikací. K tomu, abychom byli schopni předat data z instance workflow uživateli, musíme využít některé speciální aktivity, které již jsou součástí objektového modelu SharePointu a tuto komunikaci nám umožní. To je detailněji popsáno v následující kapitole. Řešení druhého problému, tedy uložení dynamické knihovny workflow a její načtení do komponenty WorkflowRuntime, je na diagramu také znázorněno. Za normálních okolností se dynamická knihovna obsahující šablonu workflow připojí do projektu a workflow se vytvoří pomocí metody CreateWorkflow(třída_workflow). 70

71 Co se týče SharePointu, řešení je složitější. Máme sice přístup do API SharePointu, ale s určitými restrikcemi. Nemůžeme do něj například nalinkovat nové dynamické knihovny ani nemáme konkrétní přístup k objektu WorkflowRuntime uvnitř SharePointu. Knihovna s šablonou workflow musí být nahrána do místa, které bude SharePointu přístupné, a tím je GAC (Global Assembly Cache). Zároveň, abychom SharePoint na existenci nově vytvořeného workflow, které bude uloženo do GAC, upozornili, využijeme konceptu SharePoint Features, jež je vysvětlen později. WorkflowRuntime se také stará o stav workflow a jeho pravidelné ukládání do databáze (persistence). Stavem workflow nemyslíme pouze textové vyjádření stavu, například Požadavek zamítnut, ale celkový stav všech objektů a proměnných, nacházejících se uvnitř instance workflow Workflow jako sled úkolů Workflow v SharePointu jsou nejčastěji modelovaná jako sled po sobě jdoucích úkolů. Z příkladu, jejž budeme modelovat, jasně vidíme, které úkoly to budou. Úkol: Schvalte požadavek na nový software, řešitelem bude nadřízený žadatele. Úkol: Doplňte dodatečné informace, řešitelem bude libovolná osoba vybraná žadatelem. Náš příklad je pouze krátký a ukázkový. Je ale možné si představit rozšíření námi uvedeného schválení požadavku na nový software. Celý proces by mohl obsahovat například následující úkoly: Schvalte za vedení IT, řešitel: vedoucí IT oddělení Získejte nabídku od dodavatele, řešitel: pracovník IT oddělení Schvalte nabídku za vedení divize, řešitel: vedoucí divize Odešlete objednávku na dodavatele, řešitel: pracovník IT oddělení Zjistěte datum předpokládaného obdržení softwaru, řešitel: pracovník IT oddělení Nainstalujte software, řešitel: pracovník IT oddělení V každém takovém kroku by se měnil stav požadavku, například Schváleno vedením divize nebo Objednávka odeslána. Workflow v SharePointu umožňuje svázat sled úkolů s určitou položkou v seznamu, nejčastěji s dokumentem, který je uložený v knihovně dokumentů Workflow SharePoint aktivity Jak víme z první kapitoly, workflow se modeluje pomocí aktivit. Protože, jak bylo řečeno, workflow je v SharePointu modelované jako sled úkolů, tak i aktivity, které jsou pro vývoj workflow k dispozici, úzce souvisí s úkoly. V příkladu uvedeném v příští kapitole budou použity především tyto aktivity: 71

72 CreateTask aktivita, sloužící k vytvoření nového úkolu. CreateTaskWithContentType aktivita, sloužící k vytvoření nového úkolu, kterému zároveň přiřadí GUID typu obsahu. OnTaskChanged aktivita, která je aktivována při změně úkolu v SharePointu SharePoint Features Features jsou balíčky, které umožňují rozšířit funkcionalitu jednotlivých stránek v SharePointu. Je to skupina elementů, které mohou být aktivované na určité stránce a umožňují nové funkce webu. Features snižují komplexnost vyvíjených řešení. Když chceme přidat do stránky novou funkcionalitu, není nutné přepisovat zdrojový kód stránky, ale stačí vytvořit novou feature, kterou aktivujeme na stránce a která požadované rozšíření umožní. SharePoint všechny své features uchovává ve svém centrálním úložišti ve složce FEATURES (podobně jako uživatelem vytvořené stránky najdeme ve složce LAYOUTS) na následující cestě: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\template\features Každá složka v tomto adresáři reprezentuje jednu feature. Složka musí obsahovat definici v souboru feature.xml. Definice feature se následně může odkazovat na více dalších souborů libovolného typu, označovaných jako elementy, které musí být obsaženy ve stejné složce. Po vytvoření složky s potřebnými soubory je možné provést instalaci feature. Instalace se provádí pomocí nástroje STSADM, což je administrátorský nástroj pro správu SharePointu, jehož používání je popsáno níže. Soubor feature.xml, který složí k definici a instalaci nové feature, má následující strukturu: <?xml version="1.0" encoding="utf-8"?> <Feature Id="6EE26DEC-458C-46fe-98E5-7D1C9D43027C" Title="ContentTypesFeature2" Description="Additional Content Types For Workflow 2" Version=" " Scope="Site" xmlns=" <ElementManifests> <ElementManifest Location="soubor_elementu.xml"/> </ElementManifests> <Properties> <Property Key="GloballyAvailable" Value="true"/> </Properties> </Feature> Element feature v tomto souboru musí obsahovat minimálně následující dva argumenty: 72

73 ID identifikační číslo feature ve formě GUID. Scope určuje rozsah nasazení feature, jinými slovy, zda je feature určena pro jeden web (Site), kolekci webů (Site Collection,) nebo pro celou aplikaci (Web Application). V případě workflow je soubor feature.xml vygenerován Visual Studiem, takže nevyžaduje uživatelskou editaci. V případě nových typů obsahů, které budeme muset vygenerovat, abychom umožnili uživatelům vstoupit do workflow přes webové rozhraní, je již nutné napsat soubor feature.xml ručně Nástroj STSADM Tento nástroj příkazového řádku umožňuje provádět celou řadu administrátorských operací. My se zde omezíme především na instalace a aktivace features, ale tím využití tohoto nástroje rozhodně nekončí. STSADM najdeme v BIN složce v centrálním úložišti SharePointu neboli v následujícím umístění: C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\bin\stsadm.exe Následuje popis a syntaxe operací, které bude nutné používat: Stsadm o installfeature name MyFeature (-force) Stsadm o uninstallfeature name MyFeature (-force) Stsadm o activatefeature name MyFeature url Stsadm o deactivatefeature name MyFeature url Je dobré si všimnout, že zatímco instalace se provádí bez určení URL stránky, tedy pro celý SharePoint, aktivaci feature provádíme pouze na určitém konkrétním webu. K aktivaci feature není nutné utilitu STSADM používat, protože ji lze provést přímo z webového rozhraní SharePointu Napojení úkolů v SharePointu na webové formuláře Jak již bylo řečeno, workflow jsou v SharePointu modelována jako sled úkolů. Úkoly jsou v SharePointu uchovávány jednoduše jako položky seznamu, tedy objekty SPListItem, které obsahují pole jako Přiřazeno, Termín splnění a podobné. Ve standardním zobrazení tato položka vypadá jako jakákoliv jiná položka seznamu, tedy jednoduchá tabulka s páry Jméno sloupce a Hodnota. Pakliže bude vytvořen úkol Schvalte požadavek na software, nebudeme chtít zobrazit tabulku s hodnotami tohoto úkolu, ale webový formulář, zobrazující požadavek a umožňující schválení nebo zamítnutí. Abychom toho docílili, bude nutné definovat vlastní typy obsahu (Content Types) pro zobrazení jednotlivých úkolů. Nám budou stačit dva nové typy obsahu, a to pro dva úkoly, které budou ve workflow zastoupeny: Schvalte požadavek na software Doplňte dodatečné informace 73

74 12.6 Vlastní typy obsahu SharePoint uchovává jednoznačné identifikační číslo pro různé typy obsahu (Content Types). Existuje tedy identifikace pro všechny typy souborů i pro ostatní obsah, jakým mohou být položky seznamů, webové formuláře, grafy, ankety, položky úkolů a další. Protože workflow je sled úkolů a každý úkol je pouze objektem SPListItem, je nutné dosáhnout toho, aby se při otevření této položky SPListItem neotevřelo standardní zobrazení položky seznamu, ale formulář definovaný pro tento úkol. Toho dosáhneme definováním nového typu obsahu pro každý úkol, který bude workflow obsahovat. Každý typ obsahu v SharePointu má určeno, jak má být zobrazen. Při definici typu obsahu tedy určíme jeho zobrazení pomocí speciálního webového formuláře, který pro tento typ obsahu vytvoříme. V momentě, kdy je pomocí SharePoint Workflow CreateTaskWithContentType aktivity vytvářen nový úkol, má konkrétně nastaven i typ obsahu. Když uživatel otevře tento úkol v SharePointu, otevře se mu vytvořený webový formulář. Abychom definice nových typů obsahů zprostředkovali SharePointu, vytvoříme feature, kterou bude možné aktivovat na konkrétním webu a tím i přidat typy obsahu do daného webu. Typy obsahu je následně vždy nutné povolit na konkrétním seznamu, který bude položky tohoto typu obsahovat. Vytvoříme-li tedy typ obsahu pro úkol Schválení požadavku, bude nutné tento typ obsahu povolit na seznamu úkolů. Typ obsahu vytvoříme jako XML soubor, se speciálním elementem ContentType. Tento XML soubor je nutné zahrnout do feature, která SharePointu tento typ obsahu zprostředkuje. 74

75 13. Architektura aplikace Cílem příkladu bude vytvořit jednoduché workflow, umožňující schválení zaměstnaneckého požadavku na nový software. Řešení je vhodně rozdělit na následující tři části Návrh vstupního formuláře (formuláře požadavku) Návrh formuláře požadavku na software a vytvoření knihovny dokumentů, do které se budou požadavky ukládat, provedeme pomocí aplikace MS InfoPath. Použití MS InfoPath není nutnou podmínkou, ale má dvě následující výhody: Umožňuje využití výhod integrace MS InfoPath se SharePointem. To nám dovolí nejprve navrhnout formulář a následně ho publikovat do SharePointu jako knihovnu dokumentů. Tím bude vytvořena knihovna dokumentů, jejíž sloupce budou přesně odpovídat polím ve formuláři. Vyplněný formulář uchovaný v knihovně dokumentů SharePointu je vlastně XML soubor, jehož elementy odpovídají polím ve formuláři navrženém pomocí MS InfoPath. To nám umožní jednoduchou programovou editaci formuláře. V případě, že uživatel například schválí požadavek, bude moci programově přepsat pole stavu požadavku na Schváleno, a to pouze použitím standardních nástrojů.net Frameworku pro editaci XML souborů Návrh a zpracování webových formulářů, sloužících jako vstupní body pro uživatele aplikace V této části navrhneme dva webové formuláře pro dva základní úkoly, které budou uživatelé se systémem provádět: Schválení požadavku. Formulář, který zobrazí informace o požadavku a umožní ho uživateli schválit, zamítnout nebo požádat o dodatečné informace. Doplnění dodatečných informací k požadavku. Formulář, který zobrazí základní informace o požadavku a umožní uživateli doplnit dodatečné informace. Při vývoji využijeme znalostí popsaných v kapitole a publikaci vlastních stránek do SharePointu, ve které je popsána implementace vlastních stránek do SharePointu jejich publikováním do složky LAYOUTS v úložišti SharePointu. Kromě této techniky bude nutné zajistit přenos informací z webového formuláře do workflow tak, aby po schválení formuláře instance workflow dostala informaci a workflow mohlo podle obdržené informace přejít do nového stavu. Protože workflow v SharePointu je sledem úkolů, bude nutné zajistit, aby se při otevření úkolu zobrazil správný formulář. To nám umožní vytvoření vlastních typů obsahu pro oba dva formuláře. Když je pak ve workflow vytvořen daný úkol, bude mu přidělen právě jeho typ obsahu, a tím zaručíme, že při otevření tohoto úkolu v SharePointu se otevře ten správný formulář Návrh a zpracování workflow Workflow namodelujeme ve Visual Studiu 2008, a to jako stavové workflow. 75

76 Výsledná dynamická knihovna bude nainstalována do Global Assembly Cache, čímž ji zpřístupníme SharePointu. Aby toto workflow mohl SharePoint použít, Visual Studio za nás vytvoří feature, do které bude workflow zabaleno. Tuto feature pak již bude možné aktivovat na jednotlivé weby a workflow následně bude možné použít v seznamech daného webu. Každý krok workflow je specifikován jako úkol přidělený uživateli. Úkoly ve workflow jdou vytvořit pomocí dvou speciálních aktivit: CreateTask CreateTaskWithContentType My použijeme aktivitu CreateTaskWithContentType, protože nám umožní vytvořit úkol konkrétního typu a následné zobrazení formuláře vytvořeného pro daný úkol Přehled architektury aplikace Celkovou architekturu aplikace popisuje následující diagram. Windows Server SharePoint Workflow Runtime Workflow Instance FEATURES workflow.xml approveformct.xml Webový formulář LAYOUTS form.aspx Schválit dokument Zamítnout dokument Požádat o dodatečné informace Odeslat Zrušit Global Assembly Cache Forms.dll Workflow.dll SQL Server.NET IIS - BIN Forms.dll Obrázek 48: Architektura aplikace Dynamická knihovna workflow je uložena v Global Assembly Cache a definice workflow je aktivována jako feature na dané stránce. V momentě, kdy je na dokumentu spuštěna nová instance workflow, SharePoint pomocí definice zjistí, kterou dynamickou knihovnu má k inicializaci workflow použít. 76

77 V momentě, kdy je workflow již spuštěné a objeví se v něm aktivita CreateTaskWithContentType, tedy vytvoření úkolu, SharePoint vytvoří novou položku v seznamu úkolů, tedy objekt typu SPListItem, a přiřadí mu typ obsahu, a tedy i zobrazovací formulář. Typy obsahu jsou vytvořeny a aktivovány jako feature na webu SharePointu. V momentě, kdy uživatel otevře daný úkol v SharePointu, použije se formulář, který byl připraven ve složce LAYOUTS. Tento formulář odkazuje na dynamickou knihovnu, která je ve složce BIN Internet Information Services Serveru, ale zároveň, protože přistupuje k objektovému modelu SharePointu, musí být nainstalována i v Global Assembly Cache. 77

78 14. Návrh formuláře požadavku pomocí nástroje MS InfoPath V této kapitole popíšeme, jak vytvořit jednoduchý formulář představující požadavek zaměstnance na nový software. Tento formulář publikujeme do SharePointu, tak abychom vytvořili knihovnu dokumentů, jejíž sloupce budou přesně odpovídat polím požadavku. Tato kapitola není návodem na používání aplikace MS InfoPath, pouze zde budou popsány některé kroky užitečné při návrhu formulářů určených k publikaci na SharePointu. Zároveň je dobré poznamenat, že použití InfoPath formuláře není podmínkou. Můžeme připojit workflow k jakékoliv položce v seznamu SharePointu, tedy i k jakémukoliv jinému dokumentu. Jelikož vyplněný InfoPath formulář není nic jiného než XML soubor, tak nám umožní jednak čtení, ale zároveň i zpětný zápis do požadavku pomocí standardních tříd jmenného prostoru System.xml. Pro SharePoint existuje rozšíření InfoPath Form Services, umožňující zobrazování InfoPath formulářů přímo v okně webového prohlížeče. Pokud bychom navrhovali formulář pro SharePoint, na kterém je rozšíření InfoPath Form Services nainstalováno, byl by jeho návrh, co se některých aspektů týče (například ukládání do knihovny dokumentů v SharePointu), odlišný a snadnější. Zde ale budeme postupovat tak, aby byl formulář kompatibilní a funkční i na SharePointu bez InfoPath Services Návrh formuláře a jeho publikování Navrhovaný formulář by měl vypadat zhruba takto: Obrázek 49: Design formuláře 78

79 Formulář obsahuje čtyři pole, která bude moci uživatel vyplnit, a to Datum požadavku, Jméno žadatele, Požadovaný software a Předpokládaná cena. Další dvě pole, tedy pole Stav požadavku a Schvalovatel požadavku, budou jen pro čtení. Jejich modifikaci budeme provádět prostřednictvím workflow a uživatelé nebudou mít možnost změnit hodnoty těchto polí. Pomocí okna vlastností jednotlivých polí nastavíme jejich jména, například pole pro požadovaný software jsme pojmenovali jednoduše software. Obrázek 50: Dialog vlastností pole Software ve formuláři Tlačítko Odeslat zatím necháme pouze tak, jak je, a formulář publikujeme do SharePointu. Zvolíme tedy File -> Publish -> To SharePoint Server with or without InfoPath Form Services. V dalším dialogu potom vybereme publikování formuláře jako knihovny dokumentů, tedy: Document Library -> Create New Document Library. V nově otevřeném dialogu bude nutné nastavit jméno nové knihovny dokumentů a její popis. Po stisknutí tlačítka Next se otevře dialog, umožňující nastavit propagaci vybraných polí do SharePointu. Označíme zde tedy pole, pro které chceme v SharePointu vytvořit odpovídající sloupec. Čím více polí přidáme, tím více možností filtrování a řazení budeme následně v SharePointu mít. Zvolíme tedy Add a v následujícím dialogu vybereme pole a nastavíme, jak má být pojmenován sloupec v knihovně dokumentů. 79

80 Obrázek 51: Nastavení propagace polí do SharePointu V následujícím kroku již jen potvrdíme a stiskem tlačítka Publish publikujeme nový formulář, čímž vytvoříme novou knihovnu dokumentů. Otevřeme-li tuto knihovnu, můžeme vyzkoušet vytvoření nového dokumentu v této knihovně. Pokud vše proběhlo v pořádku, měl by se zobrazit námi vytvořený formulář Tlačítko Odeslat uložení formuláře do knihovny v SharePointu Vrátíme se zpět do návrhu formuláře a pokusíme se přidat akci k tlačítku Odeslat tak, aby po stisknutí došlo k uložení formuláře do SharePointu a jeho zavření. K tomu je nutné vytvořit nový datový zdroj, sloužící pro uložení do SharePointu. Zvolíme tedy: Tools, Data Connections, Add. Otevře se nový dialog, ve kterém vybereme: Create a new connection to, Submit data. V dalším dialogu potom vybereme: To a document library on a SharePoint site. 80

81 Obrázek 52: Výběr datového zdroje pro uložení do SharePointu V novém dialogu bude nutné zadat adresu knihovny dokumentů a zároveň jméno, pod jakým se požadavek uloží. Knihovnu dokumentů jsme vytvořili v předchozím kroku, takže teď jen zkopírujeme její adresu. Pozor na interpunkci, SharePoint používá ve svých adresách pouze znaky anglické abecedy, takže pokud jste svou knihovnu pojmenovali Požadavky, adresa bude podobná té následující: Nyní musíme zvolit jméno, pod kterým se požadavek uloží do knihovny. Je vhodné použít pole vepsaná uživatelem, tak aby od sebe mohly být požadavky v knihovně odlišené. Můžeme zvolit například kombinaci Jméno datum. Kliknutím na ikonu funkce se zobrazí nové okno pro podrobnější zadání funkce. Můžeme použít funkci concat, která skládá řetězce. Metodě dáme tři argumenty, dva z nich budou vybraná pole a třetím argumentem bude pouze řetězec sloužící k jejich spojení. 81

82 Obrázek 53: Využití funkce pro spojení slov v SharePointu Vyplněný dialog pro nastavení datového připojení do ukládání do SharePointu by měl vypadat následovně: Obrázek 54: Nastavení datového zdroje pro ukládání do SharePointu Po kliknutí na OK již jen zadáme jméno pro nově vytvořené datové připojení, například savetosp. S takto vytvořeným datovým připojením už budeme moct uložit požadavek do knihovny. 82

83 Otevřeme nyní okno vlastností tlačítka Odeslat a kliknutím na Rules se dostaneme do sekce pro přidávání pravidel, která se provedou při stisku tlačítka. Zde zvolíme Add pro přidání nového pravidla a otevře se následující dialog. Obrázek 55: Vytvoření nového pravidla pro ukládání do SharePointu V tomto dialogu pojmenujeme pravidlo a zvolíme Add Action, čímž se otevře dialog pro určení akce, která se má provést. V tomto dialogu již jen vybereme Submit data using data connection a zvolíme datové připojení na uložení do knihovny v SharePointu tak, jak ukazuje následující obrázek. Obrázek 56: Vytvoření nové akce pro ukládání do SharePointu 83

84 Vrátíme se k původnímu dialogu a stiskem Add Action přidáme ještě jednu akci. Zde vybereme Close the form, tak aby byl formulář po úspěšném odeslání do knihovny dokumentů uzavřen. Tím jsme nastavili akci, která po stisku tlačítka zavolá 14.3 Tipy a triky pro vytváření formulářů Zde uvedeme jen dva základní tipy, které se často hodí při vytváření formulářů Zisk aktuálního data Jedním z ulehčení při vyplňování formuláře může být například automatické vyplnění aktuálního data do pole Datum požadavku. To umožníme přidáním pravidla, které se provede po otevření formuláře. Je tedy potřeba provést následující kroky: Tools -> Form Options -> Open and Save -> Rules -> Add V tomto okně pojmenujeme nové pravidlo a přidáme novou akci. Zvolíme Add Action, otevře se nový dialog pro vytvoření nové akce. V něm nastavíme typ akce na Set a fields value, jako cílové pole vybereme pole obsahující datum. Pro vyplnění pole Value otevřeme pomocný dialog kliknutím na ikonu funkce (malé f). Otevře se dialog, ve kterém zvolíme Insert Function. Z kategorií nabízených funkcí vybereme Data and Time a funkci today(). Obrázek 57: Vytvoření akce pro nastavení hodnoty pole na aktuální datum To nám zaručí, že po otevření dialogu se do pole Datum požadavku automaticky dotáhne aktuální datum Zisk aktuálního uživatele Často je potřeba získat informace o aktuálním přihlášeném uživateli, tedy o osobě vyplňující formulář. Získat tyto informace nám umožní jedna z webových služeb SharePointu. Najdeme ji na adrese: 84

85 Pro přístup k této službě v InfoPathu je potřeba vytvořit nové datové připojení, které nasměrujeme na výše uvedenou URL. Po odeslání požadavku se zobrazí seznam metod, které můžeme použít. Zde vybereme metodu GetUserProfileByName. Tato metoda vrátí pro dané jméno uživatelský profil, tedy vrátí podrobná data o uživateli. Pokud ovšem nespecifikujeme jméno a necháme tento parametr prázdný, obdržíme aktuálního uživatele. Klíčem k tomu, abychom dostali informace o aktuálním uživateli, je tedy použít tuto metodu bez parametrů, takže při vytváření datového připojení přeskočíme zadávání parametrů. Dále nastavíme, aby byla tato webová služba volána při otevření formuláře a její hodnoty uloženy ve formuláři. Tato metoda vrátí pole pojmenované PropertyData, což je vlastně tabulka obsahující data jako uspořádané dvojice klíč hodnota. Pokud tedy chceme nastavit hodnotu některého pole na jméno a příjmení aktuálního uživatele, musíme filtrovat hodnoty ve vráceném poli PropertyData, tak abychom získali právě jen jméno nebo příjmení. Otevřeme okno vlastností pole, do kterého chceme vepsat jméno a příjmení, a následně v tomto okně klikneme na ikonu funkce, pomocí které lze nastavit hodnotu vybraného pole. V následujícím dialogu vybereme Insert Field Or Group. Nyní je potřeba najít pole obsahující hodnotu, kterou chceme získat z webové služby. Najdeme ho ve struktuře výše vytvořeného datového zdroje, jedná se o pole Value. Obrázek 58: Získání hodnoty z webové služby SharePointu 85

86 Nyní je potřeba zvolit možnost Filter Data a určit, že chceme získat pouze pole, které odpovídá klíči FirstName. V nově otevřeném dialogu přidáme nový filtr a v tomto filtru vybereme filtrování podle hodnoty pole. Vybereme pole Name, které obsahuje klíč pro datovou hodnotu. Obrázek 59: Výběr pole použitého pro filtrování Nyní dokončíme nastavení filtru. Obrázek 60: Nastavení filtrování Výsledná funkce bude vypadat následovně: Value[Name = "FirstName"] Pokud ovšem chceme vložit jméno i příjmení, můžeme použít funkci concat, sloužící ke spojování řetězů, a upravíme tak výslednou funkci. concat(value[name = "FirstName"]; " "; Value[Name = "LastName"]) 86

87 Obrázek 61: Výsledná funkce pro zisk aktuálního uživatele Takto jsme vytvořili nový datový zdroj napojený na webovou službu. K získání dat z tohoto zdroje dojde ihned po otevření formuláře. Získaná data je nutné následně filtrovat, a tím zobrazit v požadovaném poli jen ty informace, které potřebujeme. 87

88 15. Návrh a implementace webového rozhraní Náplní této kapitoly bude vytvoření webových stránek, které uživatelé použijí k interakci s workflow systémem. Vytvoříme dva webové formuláře, první z nich umožní schválení dokumentu nadřízeným žadatele a druhý umožní žadateli vložení dodatečných informací. Oba formuláře integrujeme do SharePointu a výsledek bude vypadat zhruba takto (ukázka formuláře pro schválení požadavku): Obrázek 62: Ukázka výsledného formuláře Při vývoji těchto stránek bude použito techniky rozebrané v předchozím textu, která popisovala publikaci vlastních webových stránek do složky LAYOUTS Vytvoření projektu Ve Visual Studiu vytvoříme nový projekt typu WebApplication. Visual Studio vygeneruje třídu Default, kterou nebudeme používat a můžeme ji smazat. Cílem bude vytvořit dva formuláře: jeden pro schválení požadavku a druhý pro případné doplnění dodatečných informací k požadavku. Vytvoříme tedy tyto formuláře přidáním dvou nových položek typu WebForm do projektu. V našem příkladu jsou formuláře 88

89 pojmenované ApproveForm.aspx (schvalovací formulář) a AddInfoForm.aspx (formulář pro doplnění vlastností) ASPX formulář pro schválení Začneme vytvořením formuláře, který umožní schválení. Formulář jsme v této ukázce pojmenovali ApproveForm.aspx. Smažeme celý obsah kromě direktivy Page, která odkazuje na soubor s logikou. <%@ Page Language="C#" AutoEventWireup="True" CodeBehind="ApproveForm.aspx.cs" Inherits="RequestWeb.ApproveForm" %> Pro vložení obsahu použijeme kontejner Master Page SharePointu pojmenovaný PlaceHolderMain, do kterého je možné vložit obsah stránky. 89

90 <table class="main"> <col width="220px" style="text-align:left; vertical-align:top"/> <col width="450px" style="text-align:right" /> <tr class="header"> <td>úkol:</td> <td><%#this.tasktitle%></td> </tr> <tr class="header"> <td>přiděleno uživateli:</td> <td><%#this.assignedto%></td> </tr> <tr> <td class="topborder">jméno žadatele:</td> <td class="topborder"><%#this.name%></td> </tr> <tr> <td>datum požadavku:</td> <td><%#this.date%></td> </tr> <tr> <td>software:</td> <td><%#this.software%></td> </tr> <tr> <td>předpokládaná cena:</td> <td><%#this.price%></td> </tr> <tr id="addedinfolayer" runat="server" visible="false"> <td>informace od žadatele:</td> <td class="addedinfo"><%#this.addedinfo%></td> </tr> <tr> <td colspan="2" align="right" class="topborder"> <asp:radiobuttonlist ID="rdbSelect" runat="server" OnSelectedIndexChanged="IndexChanged" AutoPostBack="True"> <asp:listitem Value="1">Schválit</asp:ListItem> <asp:listitem Value="2">Zamítnout</asp:ListItem> <asp:listitem Value="3">Požádat o dodatečné informace</asp:listitem> </asp:radiobuttonlist> </td> </tr> <tr id="infolayer" runat="server" visible="false"> <td>vyplňte dodatečné informace které požadujete:</td> <td><asp:textbox ID="txtInfo" runat="server" TextMode="Multiline" width="100%"></asp:textbox></td> </tr> <tr> <td></td> <td> <asp:button id="btnsubmit" runat="server" text="odeslat" onclick="btnsubmit_click1" Enabled="false"/> <asp:button id="btncancel" runat="server" onclick="btncancel_click" Text="Zrušit"/> </td> </tr> </table> 90

91 Obsahem stránky je jednoduchá tabulka se dvěma sloupci. V levém sloupci je vždy popis a v pravém sloupci jsou vložené proměnné, které popisují daný úkol a požadavek. Hodnoty těchto proměnných vkládáme do formuláře pomocí techniky ASP.NET data binding. V jednoduchosti lze říci, že například na místo <%#this.tasktitle%> ASP.NET vloží obsah proměnné TaskTitle, obsažené ve třídě formuláře, tedy například titulek úkolu: Schvalte požadavek na software. Kromě takto napojených proměnných formulář obsahuje jednu komponentu RadioButtonList, obsahující tři položky (Schválit, Zamítnout, Požádat o dodatečné informace) s hodnotami 1, 2, 3, které uživateli umožní zvolit akci. Dále jsou zde dvě tlačítka Odeslat a Zrušit, umožňující odeslat vybranou akci do workflow ( Odeslat ) nebo neprovádět žádnou akci a vrátit prohlížeč na předchozí stránku ( Zrušit ). Formulář také obsahuje definice kaskádových stylů použitých v uvedené tabulce. <style> table.main tdborder-left-width:0px;border-right-width:0px table.mainborder-spacing:0px;border-collapse:collapse tr.header background-color:#3b6b9c; color:white; td.info color:red td.topborder border-top:1px solid #C1DAD7 </style> 15.3 Zdrojový soubor formuláře Ještě než budeme definovat metody, je vhodné určit objekty, které bude stránka potřebovat k získání potřebných dat jak z položky úkolu, tak z položky požadavku. //Web SharePointu private SPWeb teamsite; //Položka seznamu, která reprezentuje požadavek private SPListItem document; //Položka seznamu, která reprezentuje aktuální úkol private SPListItem task; //Vybraný seznam úkolů private SPList tasklist; //Dodatečné vlastnosti úkolu private Hashtable wfproperties; Všechny uvedené objekty jsou poměrně jednoznačné. Poslední zde uvedený objekt typu Hashtable slouží k získání informací odeslaných do formuláře z workflow. V tomto objektu získáme proměnné, které budeme vkládat do položky úkolu během jeho vytváření aktivitou CreateTaskWithContentType ve workflow. Úkol obsahuje standardně vlastnosti jako DueDate (Datum dokončení), AssignedTo (Přiřazeno). Pokud chceme z workflow poslat do formuláře jakoukoliv další informaci (zde například 91

92 informace dodatečně doplněné uživatelem), použijeme objekt ExtendedProperties, který je definován na položce úkolu (SPListItem) Podobně jako v příkladu zabývajícím se vývojem vlastních webových stránek je opět nutné přepsat metodu OnPreInit(), ve které získáme aktuální web SharePointu a přepíšeme Master Page: protected override void OnPreInit(EventArgs e) base.onpreinit(e); //ziskame SPWeb this.teamsite = SPControl.GetContextWeb(Context); //nastavi se masterpage teto stranky stejny jako masterpage webu this.masterpagefile = teamsite.masterurl; Dalším zásadním krokem bude přepsání metody OnLoad, v níž získáme všechny výše definované objekty, které jsou následně použité pro zobrazení informací ve webové stránce. protected void Page_Load(object sender, EventArgs e) Guid tasklistguid = new Guid(Request.Params["List"]); tasklist = teamsite.lists[tasklistguid]; int taskid = Convert.ToInt16(Request.Params["ID"]); task = tasklist.getitembyid(taskid); Guid wfinstanceguid = new Guid(task[SPBuiltInFieldId.WorkflowInstanceID] as String); SPWorkflow workflow = new SPWorkflow(teamSite, wfinstanceguid); SPList documentlist = teamsite.lists[workflow.listid]; document = documentlist.items[workflow.parentitem.uniqueid]; wfproperties = SPWorkflowTask.GetExtendedPropertiesAsHashtable(task); addedinfolayer.visible = AddedInfo!= String.Empty; this.databind(); Když je webový formulář otevřen, jsou mu parametrem připojeným k URL adrese odeslána identifikační čísla seznamu, ve kterém se úkol nachází, a úkolu samotného. Část URL adresy může vypadat například následujícím způsobem: 93cd-ec d7&ID=64&Source= V této adrese jsou zdůrazněny právě ty části, které použijeme. V OnLoad() metodě tedy získáme tyto parametry a pomocí nich získáme objekt SPList reprezentující seznam a objekt typu SPListItem reprezentující samotný úkol. 92

93 Guid tasklistguid = new Guid(Request.Params["List"]); tasklist = teamsite.lists[tasklistguid]; int taskid = Convert.ToInt16(Request.Params["ID"]); task = tasklist.getitembyid(taskid); V dalším kroku je nutné získat dokument, ke kterému je workflow připojené. Nejprve zjistíme identifikační číslo instance workflow, která je spojená s tímto úkolem. Guid wfinstanceid = new Guid(task[SPBuiltInFieldId.WorkflowInstanceID] as String); Následně si vytvoříme objekt SPWorkflow, použitím získaného identifikačního čísla. Z tohoto objektu již je možné získat seznam dokumentů a následně i dokument samotný. SPWorkflow workflow = new SPWorkflow(teamSite, wfinstanceid); SPList documentlist = teamsite.lists[workflow.listid]; document = documentlist.items[workflow.parentitem.uniqueid]; Poslední, co budeme potřebovat, je objekt typu Hashtable, reprezentující vlastnosti úkolu, které vložíme do úkolu při jeho vytváření ve workflow. Tento objekt nám tedy bude sloužit jako komunikační prostředek, který umožní workflow posílat do formulářů libovolné objekty. K získání tohoto objektu je v Objektovém modelu SharePointu speciální statická metoda. wfproperties = SPWorkflowTask.GetExtendedPropertiesAsHashtable(task); Poslední řádky již jen zkontrolují, zda zobrazit vrstvu dodatečných informací, které mohou být do formuláře z workflow poslány, a poslední volání zaručí nahrazení proměnných v ASPX formuláři jejich hodnotami (ASP.NET Data Binding) Získání proměnných z požadavku a z úkolu Nyní definujeme všechny proměnné, které jsou metodou Data Binding vloženy do těla formuláře. K získání těchto proměnných používáme právě objekty vytvořené v přepsané metodě OnLoad. 93

94 public String Name get return document["jméno"] as String; public String Software get return document["software"] as String; public String Price get return document["cena"] as String; public String Date get return document["datum požadavku"] as String; Při přístupu k jednotlivým polím v požadavku používáme názvy sloupců knihovny dokumentů. Následující vlastnosti jsou získávány přímo ze samotné položky reprezentující úkol. Při přístupu k těmto vlastnostem opět používáme statickou třídu SPBuildInFieldId, která zpřístupňuje GUID pro vestavěné sloupce SharePointu. V případě sloupce AssignedToSharePoint vrací řetězec, který reprezentuje uživatele ve formě: ID#Jméno Příjmení, je tedy nutné tento text oříznout. public String AssignedTo get String assignedto = task[spbuiltinfieldid.assignedto] as String; if (assignedto.contains("#")) assignedto = assignedto.substring(assignedto.indexof("#")+1); return assignedto; else return String.Empty; public String TaskTitle get return task[spbuiltinfieldid.title] as String; Poslední vlastnost, kterou bude nutné zobrazit, je text dodatečných informací doplněných žadatelem, ale to pouze v případě, že workflow vstupuje poprvé do prvního stavu a schvalovatel v předchozím kroku žádal o tyto informace. Tyto informace pošle do webového formuláře přímo workflow, které navrhneme v další kapitole. K získání těchto informací využijeme vlastnosti úkolu, konkrétně objekt 94

95 ExtendedProperties, do kterého lze vložit libovolné objekty na straně workflow a tyto objekty později vybrat na straně webového formuláře, nebo naopak. Následuje tedy definice vlastnosti AddedInfo. public String AddedInfo get if(wfproperties!= null && wfproperties.contains("addedinfo")) return wfproperties["addedinfo"] as String; else return String.Empty; V případě proměnné AddedInfo kontrolujeme, zda objekt wfproperties není prázdný. Metoda GetExtendedPropertiesAsHashtable(task) vrací null, v případě, že úkolu žádné ExtendedProperties nebyly přiřazeny. V této proměnné si uložíme řetězec reprezentující dodatečné informace doplněné uživatelem a obdržené od instance workflow. Pakliže schvalovatel požádal o dodatečné informace a žadatel tyto informace poskytl, dojde ke druhému vstupu do schvalovacího stavu a k druhému vytvoření schvalovacího úkolu, kterému je z workflow poslán řetězec reprezentující informace poskytnuté žadatelem Odeslání informací zpět do workflow Stav úkolu je měněn v momentě, kdy uživatel zmáčkne tlačítko Odeslat. V té chvíli se provede následující procedura: Hashtable table = GetReturnTable(); if (document.file.checkoutstatus == SPFile.SPCheckOutStatus.None) if (task[spbuiltinfieldid.taskstatus].tostring()!= "Dokončeno") bool returnval = SPWorkflowTask.AlterTask(this.task, table, true); if (returnval == false) ReturnError("Nepodařilo se odeslat do Workflow změnu stavu"); else ReturnError("Tento úkol již byl jednou odeslán."); else ReturnError("Schvalujete dokument, který je právě otevřen. Zkuste to později."); 95

96 Nejprve se zavolá metoda GetReturnTable, jež vrací objekt typu Hashtable, který se použije ke změně stavu objektu. Pomocí této Hashtable se upraví vlastnosti úkolu. Úprava vlastností úkolu je provedena pomocí metody AlterTask, tak jak je popsáno níže. private Hashtable GetReturnTable() Hashtable table = new Hashtable(); table.add("changed", 1); table.add(spbuiltinfieldid.percentcomplete, "100"); table.add(spbuiltinfieldid.taskstatus, "Dokončeno"); table.add("action", rdbselect.selectedvalue); if (rdbselect.selectedvalue == "3") table.add("requestedinfo", txtinfo.text); return table; Ještě před samotnou aktualizací úkolu jsou provedeny dvě kontroly. Nejprve je zjištěno, zda daný schvalovaný dokument nemá některý uživatel rezervován k editaci. V takovém případě by došlo k chybě při pozdějším zapisování do samotného dokumentu a navíc by nadřízený schvaloval neaktuální verzi dokumentu. Druhá kontrola již pouze zjišťuje, zda úkol nemá pole Stav nastaveno na Dokončeno, tedy zda úkol již nebyl řešen. Dalším krokem je již samotná aktualizace úkolu. Ta se provádí pomocí volání statické metody AlterTask. Tato metoda má tři parametry. Prvním parametrem je objekt SPListItem, reprezentující úkol, který se má upravit. Druhým parametrem je objekt Hashtable, jenž reprezentuje vlastnosti, které se mají na dané položce změnit. A posledním parametrem je binární hodnota určující, zda spustit volání této metody synchronně, nebo asynchronně. Tato metoda vytváří při svém spuštění nové vlákno, které se stará o změnu úkolu, je tedy možné pokračovat dál bez čekání na výsledek updatu nebo čekat, až dojde k provedené změně. Metoda vrátí binární hodnotu určující, zda se změna úkolu povedla. Pokud existuje vlastnost úkolu (tedy vlastnost objektu SPListItem) pojmenovaná stejně jako některý z klíčů v objektu Hashtable, dojde k úpravě hodnoty této vlastnosti. Pokud ovšem takový klíč ve vlastnostech položky SPListItem neexistuje, je tato nová vlastnost přidána do objektu ExtendedProperties. Ve výše uvedeném příkladu je použit jako klíč GUID SPBuiltInFieldId.TaskStatus,který ve vlastnostech objektu SPListItem zaručeně najdeme, dojde tedy pouze k úpravě hodnoty této vlastnosti. Naopak vlastnost Action slouží pro vnitřní účely workflow a dojde k jejímu uložení do objektu ExtendedProperties. Po provedené úpravě položky úkolu je zavoláno přesměrování na stránku defaultního zobrazení seznamu úkolů. Přesměrování pomocí metody Redirect umožňuje použít sadu SPRedirectFlags, a upravit tak cíl přesměrování. Hodnota UserSource zajistí navrácení do původně otevřené stránky, ze které byl úkol otevřen. Hodnota DoNotEndResponse zaručí, že webový server neukončí vlákno aktuálně 96

97 zpracovávající otevřenou webovou stránku ihned po přesměrování, ale dokončí zpracování stránky. Pokud by tato hodnota nebyla ve volání metody Redirect přítomná, došlo by k ThreadAbortException. SPUtility.Redirect(this.taskList.DefaultViewUrl, SPRedirectFlags.UseSource SPRedirectFlags.DoNotEndResponse, HttpContext.Current); Ve chvíli, kdy jsou změny úkolu odeslány do workflow, je možné provést poslední krok a tím je změna stavu požadavku, tedy změna obsahu pole Stav požadavku a Schvalovatel požadavku Úprava hodnot v požadavku Pakliže se povedlo změnit úkol (tedy jeho stav), posledním nutným krokem bude změnit stav požadavku, tedy změnit hodnotu pole Stav v požadavku a do pole Schvalovatel vepsat, kdo provedl schválení nebo zamítnutí požadavku. Vyplněný soubor požadavku uložený v knihovně dokumentů má formát XML. Zdroj může vypadat následujícím způsobem: <my:myfields xmlns:xsi=" xmlns:xhtml=" xmlns:my=" 03T20:40:31" xmlns:xd=" xml:lang="en-us"> <my:date> </my:date> <my:name>pavel Novák</my:name> <my:software>ms Visual Studio 2010, Ultimate</my:software> <my:price>1000 Kč</my:price> <my:state>zamítnuto</my:state> <my:approver>fajfr Jan</my:approver> </my:myfields> Elementy, které XML soubor obsahuje, přesně odpovídají polím požadavku. Hlavní element my:myfields odpovídá jménu hlavního datového zdroje formuláře stejně tak jako definované namespace my tomu uvedenému ve formuláři. Pokud otevřeme formulář v editačním módu, můžeme si zobrazit namespace formuláře takto: Na záložce Data Source vybereme libovolné z polí a po kliknutí na Properties zvolíme záložku Details. 97

98 Obrázek 63: Zjištění namespace formuláře v MS InfoPath K editaci XML souboru můžeme zvolit v.netu více cest, my zde použijeme namespace System.Xml. Abychom se k XML datům dostali, použijeme objekt SPFile, reprezentující soubor uložený v SharePointu. Referenci na něj získáme z položky požadavku, tedy opět z objektu SPListItem. SPFile file = document.file; MemoryStream instream = new MemoryStream(file.OpenBinary()); XmlDocument doc = new XmlDocument(); doc.load(instream); instream.close(); Abychom mohli v tomto XML dokumentu navigovat a pohybovat se po konkrétních elementech, je nutné použít třídu XMLNamespaceManager a již výše zmíněný řetězec, který reprezentuje namespace požadavku. private const String formnamespace = "my"; private const String formuri = " XmlNode root = doc.documentelement; XmlNamespaceManager xmlnsmanager = new XmlNamespaceManager(doc.NameTable); xmlnsmanager.addnamespace(formnamespace, formuri); Nyní již můžeme získávat a editovat požadované elementy. Prvním elementem bude pole Approver, tedy schvalovatel. Získáme tento element, pomocí Objektového modelu SharePointu získáme jméno aktuálně přihlášeného uživatele a vepíšeme jej do elementu. K získání elementu použijeme metodu SelectSingleNode, která je definovaná na objektu XmlNode. Tato metoda získá element ve struktuře XML souboru na základě XPath výrazu a XmlNamespace. XPath výraz nutný k nalezení elementu je opět 98

99 možné zjistit v editačním módu InfoPath formuláře. Na záložce Data Source otevřeme kontextové menu na libovolném poli v hlavním datovém zdroji a zvolíme volbu Copy XPath, čímž se zkopíruje hledaný XPath výraz do schránky. XmlNode approver = root.selectsinglenode("/my:myfields/my:approver", xmlnsmanager); SPUser user = SPContext.Current.Web.CurrentUser; approver.innertext = user.name; Podobně získáme pole State neboli stav. Textovou hodnotu tohoto pole nastavíme podle položky vybrané v seznamu rdbselect (RadioButtonList). XmlNode state = root.selectsinglenode("/my:myfields/my:state", xmlnsmanager); String approvedtext; if (rdbselect.selectedvalue == "1") approvedtext = "Schváleno"; else approvedtext = "Zamítnuto"; state.innertext = approvedtext; Nyní pouze změny v objektu XmlDocument vepíšeme zpět do soboru požadavku. MemoryStream outstream = new MemoryStream(); doc.preservewhitespace = true; doc.save(outstream); file.savebinary(outstream.toarray()); outstream.close(); Všimněte si nastavení proměnné PreserveWhiteSpaces na hodnotu true. Pokud by nebyl tento atribut nastaven, byly by vymazány všechny prázdné znaky. InfoPath klient s otevřením takového formuláře nemá problém, ale pokud by byl formulář browser enabled a byl by otevírán v prohlížeči pomocí InfoPath Services, došlo by k chybě při jeho otevření (Schema validation found non-data type errors). Vykreslování formulářů v SharePointu je na změny v XML struktuře dokumentu citlivější než InfoPath klient. Sebemenší změna ve struktuře XMLdokumentu, zde například vymazání prázdných znaků mezi elementy, může způsobit chybu při validaci a nevykreslení dokumentu Další metody v požadavku Obsluha tlačítka Zrušit bude pouze přesměrování zpět na stránku s přehledem úkolů daného workflow: SPUtility.Redirect(this.taskList.DefaultViewUrl, SPRedirectFlags.UseSource,HttpContext.Current); Další metodou bude posluchač události OnSelectedIndexChanged komponenty pro výběr zvolené akce, zde se provede pouze kontrola pro povolení tlačítka Odeslat a zobrazení vrstvy s žádostí o dodatečné informace (pakliže je tato možnost vybrána). 99

100 protected void IndexChanged(object sender, EventArgs e) btnsubmit.enabled = rdbselect.selectedvalue!= null && task[spbuiltinfieldid.taskstatus].tostring()!= "Dokončeno"; infolayer.visible = rdbselect.selectedvalue == "3"; Poslední metodou ve formuláři pak bude metoda sloužící pro výpis chybové hlášky používaná v ostatních metodách formuláře. public void ReturnError(string errormessage) Response.Write(String.Format("<sctipt>alert(0)</script>",errorMessage)); 15.8 Formulář pro dodání dodatečných informací Tento formulář zde již nebude rozebrán do detailu, většina použitého kódu se dá převzít z formuláře pro schválení. Formulář bude obsahovat sumář požadavku a TextBox, do kterého bude moci žadatel doplnit požadované informace. Obrázek 64: Ukázka formuláře pro dodání dodatečných informací Jediným podstatným rozdílem zde budou informace, které odesíláme zpět do workflow. Není nutné odesílat identifikaci akce, kterou uživatel vybral, takže vložíme pouze text reprezentující doplněné informace. Hashtable returntable = new Hashtable(); returntable.add("changed", 1); returntable.add(spbuiltinfieldid.percentcomplete, "100"); returntable.add(spbuiltinfieldid.taskstatus, "Dokončeno"); returntable.add("addedinfo", txtinfo.text); SPWorkflowTask.AlterTask(this.task, returntable, true); 100

101 Tento formulář nebude provádět žádné změny v požadavku, není nutné měnit ani stav schvalovatele požadavku Publikování formulářů Formuláře budeme publikovat do složky LAYOUTS v centrálním úložišti SharePointu. Podrobně je tato část popsána již v jedné z předchozích kapitol, která se zabývá publikováním webových stránek do SharePointu. Zde je pouze přehled nutných kroků: Nakopírování ASPX souborů do složky LAYOUTS Vytvoření aplikace pomocí konfigurace Internet Information Services serveru (nutné pouze, pokud budou formuláře v samostatné složce) Nahrání dynamických knihoven do BIN složky IIS serveru Podepsání dynamické knihovny a její instalace do Global Assembly Cache Po posledním kroku restart IIS serveru Nyní by měly být formuláře připraveny k použití. V této chvíli ještě není možné je otestovat, protože formuláře se snaží při načítání ze HTTP požadavku získat ID seznamu a ID položky úkolu. Tyto hodnoty jsou automaticky vloženy do HTTP požadavku SharePointem, během požadavku na zobrazení úkolu Vytvoření vlastních typů obsahu pro jednotlivé úkoly Nyní, když máme formuláře hotové, vytvoříme vlastní typy obsahu, ve kterých použijeme tyto formuláře. Tím umožníme použití formulářů jako vstupních rozhraní pro uživatele našeho workflow. Definicí typu obsahu je soubor elementu ve formátu XML, se specifickou strukturou. 101

102 <?xml version="1.0" encoding="utf-8"?> <Elements xmlns=" <ContentType ID="0x e84cf086952b4531a617da aed" Name="RequestApproveForm" Group="WorkflowForms" Description="Formulář schválení požadavku." Version="0" Hidden="FALSE"> <FieldRefs></FieldRefs> <XmlDocuments> <XmlDocument NamespaceURI=" <FormUris xmlns=" <New> <Display> <Edit> </FormUris> </XmlDocument> </XmlDocuments> </ContentType> </Elements> Element ContentType definuje typ obsahu. Jeho součástí jsou následující atributy: ID identifikátor typu obsahu, který je složen ze dvou částí: Prefix 0x , který určuje, že se jedná o úkol pro workflow Vygenerovaný GUID, pro jednoznačnou identifikaci Prefixy typů obsahů tvoří stromovou strukturu; například k prefixu, který označuje úkol ve workflow se dospěje následujícím způsobem: 0x01 položka seznamu 0x0108 úkol 0x úkol pro workflow Existuje více prefixů, například následující strom určuje XML dokument : 0x01 položka seznamu 0x0101 dokument 0x XML dokument Group volitelný atribut, řetězec určující, do jaké skupiny spadá tento typ obsahu. Podstatná informace v této definici typu obsahu je obsažena v elementu FormUris. Zde najdeme URL adresy použité ke zobrazení typu obsahu. Můžeme určit jiné webové adresy, tedy vytvořit různé webové formuláře pro vytvoření, editaci a zobrazení položky daného typu obsahu. Podobný ContentType vytvoříme i pro druhý úkol, tedy pro úkol přidání informací. 102

103 <?xml version="1.0" encoding="utf-8"?> <Elements xmlns=" <ContentType ID="0x e185d630b44ef2b3453fc496bc2eb5" Name="RequestInfoForm" Group="WorkflowForms" Description="Formulář pro přidání dodatečných informací." Version="0" Hidden="FALSE"> <FieldRefs></FieldRefs> <XmlDocuments> <XmlDocument NamespaceURI=" <FormUris xmlns=" <New> <Display> <Edit> </FormUris> </XmlDocument> </XmlDocuments> </ContentType> </Elements> Upozornění: Definice typu obsahu musí obsahovat element FieldRefs, specifikující sloupce použité v typu obsahu, i v případě, kdy je tento element prázdný tak jako v předchozích ukázkách. Kdyby tento element nebyl zastoupen, došlo by při programové změně úkolu pomocí statické metody SPWorkflowTask.AlterTask k NullReferenceException. V tomto případě jde nejspíše o chybu v SharePointu. V momentě, kdy máme k dispozici definice typů obsahu, je nutné vytvořit feature a zabalit tyto soubory jako elementy do této feature. <?xml version="1.0" encoding="utf-8"?> <Feature Id="28B43F4B0ADA4e028E2A42E47750D64A" Title="RequestWFForms" Description="Formuláře pro workflow" Version=" " Scope="Site" xmlns=" <ElementManifests> <ElementManifest Location="ApproveContentType.xml"/> <ElementManifest Location="InfoContentType.xml"/> </ElementManifests> <Properties> <Property Key="GloballyAvailable" Value="true"/> </Properties> </Feature> Nyní nakopírujeme složku se souborem feature.xml a soubory elementů typů obsahu do složky FEATURES v centrálním úložišti SharePointu a následně pomocí nástroje STSADM nainstalujeme feature. 103

104 Jelikož atribut Scope, tedy rozsah feature, je nastaven na hodnotu Site, stačí nám aktivovat tuto feature pouze na kořenové stránce SharePointu. stsadm o installfeature name WorkflowForms (-force) stsadm o activatefeature name WorkflowForms url Tím jsme vytvořili vlastní typy obsahu pro úkoly Schvalte požadavek a Doplňte dodatečné informace. Správná otázka by nyní byla: Jak v průběhu workflow vytvořit úkol daného typu obsahu? Odpověď je jednoduchá, slouží k tomu aktivita CreateTaskWithContentType, ze skupiny aktivit Windows SharePoint Services. O jejím použití se dočtete v následující kapitole o vývoji a modelování workflow Povolení typů obsahu Jakmile jsou typy obsahu vytvořeny a feature je s nimi nainstalována a aktivována na vybrané stránce, je nutné je povolit na konkrétním seznamu v SharePointu, na kterém budou používány. Postupujeme následující způsobem: Navigujeme na stránku seznamu: Settings (Nastavení) Advanced Settings (Upřesnit nastavení) Allow management of content types (Umožnit správu typů obsahu?) Content Types (Typy obsahu) Add from existing site content types (Přidat ze stávajících typů obsahu webu) Zde bychom již měli v nabídce najít typy obsahu, pod jmény, která jsme jim dali v předchozím kroku. Po přidání by měl seznam obsahovat čtyři typy obsahu: Úkol, Úkol pro workflow a naše dva speciální typy, tak jak ukazuje následující obrázek: Obrázek 65: Aktivování vlastních datových typů na seznamu v SharePointu 104

105 16. Návrh a implementace workflow Ve Visual Studiu vytvoříme nový projekt typu SharePoint 2007 State Machine Workflow. Pokud postupujete podle tohoto návodu, tak je vhodné přidat tento projekt do společného řešení (Solution) s projektem webových formulářů. Usnadníte si tak společné ladění obou projektů. Po vytvoření projektu bude nutné zadat URL adresu stránky, na niž chceme workflow vyvíjet, a po jejím správném zadání se objeví formulář, pomocí kterého určíme, ke kterému seznamu chceme workflow připojit. Dále na tomto formuláři určíme, který seznam se použije jako History list (tedy pro logování historie workflow) a který seznam použijeme jako seznam úkolů ( Task list ). Pro úkoly je možné si vytvořit vlastní seznam nebo použít seznam úkolů, jenž je standardně vytvořen na stránkách SharePointu. Obrázek 66: Nastavení projektu workflow ve Visual Studiu Po úspěšném zadání nás čeká již jen poslední formulář, na kterém lze vybrat, v jaké chvíli se workflow na dokumentu spustí. Povolíme manuální spuštění a automatické spuštění po vytvoření položky. 105

106 Obrázek 67: Nastavení podmínek spouštění workflow 16.1 Soubory feature a workflow Jak již bylo řečeno, zkompilované workflow bude nainstalováno do Global Assembly Cache. Abychom toto workflow zpřístupnili SharePointu, je nutné vytvořit feature, která SharePointu sdělí, kde konkrétní dynamickou knihovnu najít. Za tímto účelem obsahuje projekt workflow soubory feature.xml a workflow.xml. Tyto soubory jsou vygenerovány pomocí Visual Studia během vytváření projektu Úpravy workflow Po vytvoření projektu se zobrazí design automaticky vygenerované třídy Workflow1 s prázdným počátečním stavem, který bude obsahovat jednu EventDriven aktivitu. Uvnitř této EventDriven aktivity najdeme aktivitu OnWorkflowActivated. Nejprve je vhodné přejmenovat třídu Workflow1. Pokud bychom se rozhodli pro přejmenování až později, kdy by workflow již bylo hotové, museli bychom ručně měnit vlastnosti většiny aktivit. V tomto příkladu je třída přejmenována a pojmenována RequestWF. Jakmile tak učiníme, musíme také upravit hodnotu CodeBesideClass v souboru workflow.xml tak, aby odpovídala novému jménu. CodeBesideClass="RequestWF.RequestWF" 16.3 Příprava proměnných Dalším vhodným krokem je příprava proměnných, které budeme používat v průběhu programování workflow. Do třídy RequestWF vložíme následující proměnné: GUID hodnoty specifikující vlastní typy obsahu, které jsme si vygenerovali v minulé kapitole. Budeme je používat ke správnému nastavení typů obsahu úkolu, které budeme pomocí aktivit CreateTaskWithContentType vytvářet. public string APPROVE_CONTENT_TYPE = "0x BF e1B1A2B1A93C4A1308"; public string ADD_INFO_CONTENT_TYPE = "0x C D3CD555EE21574"; Dále si definujeme konstanty, jež nám pomohou při tvorbě workflow s určením, kterou akci uživatel s dokumentem provedl. Nejprve uložíme vybranou akci od proměnné selectedaction a následně 106

107 budeme pomocí IfElse aktivit porovnávat s jednotlivými konstantami, do kterého stavu má workflow přejít. public byte selectedaction; public const byte APPROVED = 1; public const byte REJECTED = 2; public const byte ADD_INFO = 3; Proměnné, které nám dají informaci, zda uživatel již změnil úkol, tedy zda provedl schválení, zamítnutí nebo doplnění informací: public bool approvetaskchanged = false; public bool addinfotaskchanged = false; Proměnné, ve kterých si uložíme informace, jež bude schvalovatel dodatečně požadovat nebo žadatel doplní, když je o to požádán: private String requestedinfo; private String addedinfo; Poslední proměnná bude uživatelské jméno osoby, která vytvořila požadavek. Tomuto uživateli později přiřadíme úkol s žádostí o dodatečné informace: private String requesterlogin; Všechny tyto proměnné budeme potřebovat během vytváření workflow na různých místech, ale považujeme za vhodné je zde takto popsat a v dalším textu se na ně pouze odkazovat Modelování workflow Upravíme vygenerovaný workflow diagram tak aby odpovídal stavovému diagramu aplikace. Z počátečního stavu (zde přejmenován na approvestate ) lze přejít do stavu, kdy uživatel přidává dodatečné informace ( addinfostate ), nebo do konečného stavu ( approvingfinishedstate ). Připravte si prozatím stavy workflow a vložené EventDriven a StateInitialization aktivity. Detaily jednotlivých aktivit budou popsány dále. Stav approvestate obsahuje kromě již implicitně vložené aktivity EventDriven, obsahující OnWorkflowActivated aktivity, ještě aktivitu StateInitialization, sloužící k vytvoření nového úkolu, a další EventDriven aktivitu, obsahující OnTaskChanged aktivitu čekající na změnu nově vytvořeného úkolu. Stav addinfostate obsahuje obdobně aktivity pro vytvoření úkolu (StateInitialization) a aktivitu pro změnu tohoto úkolu (EventDriven). 107

108 Obrázek 68: Stavový diagram workflow ve Visual Studiu Vygenerovaný diagram obsahoval jeden stav s aktivitou typu EventDriven (v diagramu výše přejmenovaná na workflowactivatedevent. Tato aktivita již automaticky obsahovala aktivitu OnWorkflowActivated, tak jak to ukazuje následující obrázek. Obrázek 69: Stav schválení aktivita OnWorkflowActivated Budeme chtít, aby se po aktivaci workflow provedly určité kroky. Toho dosáhneme správným nastavením a použitím této aktivity. V okně vlastností najdeme vlastnost Invoked. Ta odkazuje na metodu, která má být spuštěna při vstupu workflow do této aktivity. Zde můžeme buď vyplnit jméno metody anebo dvojklikem na aktivitu nechat Visual Studio vygenerovat požadovanou metodu. Otevře se soubor třídy RequestWF s nově vygenerovanou metodou. V momentě aktivace workflow budeme chtít zjistit, kdo je autorem požadavku, tak abychom v případě, že si schvalovatel vyžádá dodatečné informace, byli schopni přidat nový úkol Doplňte dodatečné informace právě žadateli. To provedeme následujícím způsobem: 108

109 private void onworkflowactivated_invoked(object sender, ExternalDataEventArgs e) requesterlogin = workflowproperties.item.file.author.loginname; K získání autora požadavku použijeme proměnnou WorkflowProperties, také automaticky vygenerovanou při založení projektu, na kterou je napojená vlastnost WorkflowProperties aktivity OnWorkflowActivated, jejíž přehled vlastností je vidět na následujícím obrázku. Obrázek 70: Vlastnosti aktivity OnWorkflowActivated Tato proměnná obsahuje užitečné informace o workflow, jakými jsou: Seznam dokumentů, ke kterému je workflow připojené Seznam úkolů k danému požadavku Uživatele, který započal workflow Konkrétní položku seznamu, ke které se toto workflow váže Právě z posledního zmíněného objektu, tedy z položky dokumentu, ke kterému je workflow připojené, můžeme získat autora tohoto dokumentu Vytvoření nového úkolu Nyní popíšeme podrobně aktivitu StateInitialization ve stavu approvestate, ve které dojde k vytvoření úkolu. Do této aktivity vložíme pouze jednu vnitřní aktivitu, a to CreateTaskWithContentType. 109

110 Obrázek 71: Stav schválení aktivita StateInitialization Nyní bude nutné nastavit vlastnosti této aktivity. Je zde hned několik vlastností, které musíme nastavit. ContentTypeId určuje typ obsahu nově vytvořeného úkolu. Správným nastavením určíme, který formulář použije SharePoint ke zobrazení nově vytvořeného úkolu. Právě zde použijeme GUID, které jsme vygenerovali pro typy obsahu v předchozí kapitole. Toto ID máme uložené jako globální proměnnou třídy RequestWF. Můžeme tedy pouze napojit tuto vlastnost na výše definovanou proměnnou. Napojení vlastnosti se ve Visual Studiu provádí kliknutí na ikonu se třemi tečkami v rohu dané vlastnosti. Pokud jsme si uložili GUID jako řetězcovou konstantu do třídy RequestWF, měli bychom jí být schopni lokalizovat na panelu Bind to an existing member. Další možností by bylo vložit text reprezentující GUID přímo v okně vlastností. CorrelationToken je značka, jež jednoznačně určí, ke kterému úkolu se vložená aktivita vztahuje. Všechny aktivity týkající se úkolů musí mít správně nastavený CorrelationToken. K úkolu se mohou vztahovat aktivity CreateTask, CompleteTask, OnTaskChanged, UpdateTask. Ty aktivity, které se vztahují ke společnému úkolu, musí mít nastavený CorrelationToken na stejnou hodnotu. V této chvíli můžeme vytvořit nový CorrelationToken. Je potřena nastavit vlastníka tohoto tokenu. Jako vlastníka nastavíme stav approvestate, čímž zpřístupníme tento CorrelationToken všem aktivitám v daném stavu. TaskId GUID jednoznačně určující úkol v SharePointu. Napojíme tuto vlastnost na nové pole postupem Bind to a new member, Create Field a designér nám automaticky vytvoří proměnnou, ke které budeme moci přistupovat a programově pro úkol vytvořit nové ID. TaskProperties vlastnosti úkolu. Tuto položku využijeme pro nastavení standardních (AssignedTo, DueDate) i nestandardních (jakékoliv jiné) vlastností úkolů. Právě nastavení nestandardních vlastností nám umožní odeslat libovolný objekt do webových formulářů, pomocích, který bude uživatel pracovat s workflow systémem. Opět napojíme tuto vlastnost na nové pole ( Bind to a new member, Create Field ), ke kterému budeme přistupovat programově. Důležité je pro proměnnou zvolit vhodné jméno, 110

111 protože k ní budeme přistupovat během vytváření úkolu. My jsme ji zde pojmenovali approvetaskproperties. MethodInvoking Zde se specifikuje metoda, která bude volána při vstupu workflow do této aktivity. Dvojklikem na objekt aktivity nám Visual Studio tuto metodu vygeneruje. Jakmile dojde k vygenerování metody, otevře se třída RequestWF a zobrazí se vygenerovaná metoda. Můžeme v této chvíli rovnou pokračovat a vepsat do metody následující řádky. private void createapprovetask_methodinvoked(object sender, EventArgs e) approvetaskid = Guid.NewGuid(); approvetaskproperties = new SPWorkflowTaskProperties(); approvetaskproperties.title = "Schvalte požadavek na nový Software"; approvetaskproperties.assignedto = "domena\\uzivatel"; if (addedinfo!= null) approvetaskproperties.extendedproperties.add("addedinfo",addedinfo); requestedinfo = null; Pracujeme zde s poli, která vygenerovalo Visual Studio v předchozím kroku, během nastavování vlastností. Nejprve vygenerujeme nový GUID pro nový úkol v SharePointu. Následně vygenerujeme pro tento úkol nový objekt vlastností (SPWorkflowTaskProperties). Nastavíme nadpis úkolu a přidělíme úkol uživateli. Zde je nutné nastavit login uživatele ve tvaru doména\uživatel. Pro začátek budeme předpokládat, že znáte login schvalovatele dokumentů, takže ho sem doplníme již v kódu. Poslední část nemusí být ještě zřejmá. Ve workflow máme vytvořenu proměnnou addedinfo, která obsahuje dodatečné informace, jež žadatel vyplní, pokud je o ně tázán. Jak tyto informace získáme z druhého úkolu Doplňte dodatečné informace, bude vysvětleno později. Zde kontrolujeme, zda toto pole není prázdné, a pokud není, uložíme jeho hodnotu do objektu ExtendedProperties, který je součástí vlastností. Objekt ExtendedProperties je typu Hashtable, proto můžeme uložit řetězec do této tabulky pod klíčem AddedInfo. V momentě otevření formuláře tyto ExtendedProperties získáváme a čteme z nich objekty, které nám odeslalo workflow. Jedná se v zásadě o vše, co bychom chtěli zobrazit a nejsme schopni to přečíst ani z položky úkolu (Title, AssignedTo), ani z položky samotného požadavku (Software, Jméno žadatele atd.). Při prvním vstupu workflow do approvestate stavu je proměnná addedinfo zcela jistě prázdná. Jakmile uživatel požádá o dodatečné informace a žadatel tyto informace v dalším úkolu vyplní, vstoupí workflow podruhé do tohoto schvalovacího stavu. V té chvíli již ale bude v proměnné addedinfo uloženo vše, co uživatel doplnil, takže dojde ke zobrazení těchto dodatečných informací ve formuláři úkolu. 111

112 Tím jsme vyřešili vytvoření úkolu. Nyní je nutné definovat změny, které nastanou v případě, že uživatel provede určitou akci, tedy kdy dojde ke změně tohoto úkolu. Pro úplnost ještě uvádíme přehled vlastností CreateTaskWithContentType aktivity. Obrázek 72: Vlastnosti aktivity CreateTaskWithContentType 16.6 Změna úkolu Změně úkolu je vyhrazena druhá EventDriven aktivita v inicializačním stavu, v projektu pojmenována approvechangedevent. V této aktivitě budeme chtít zpracovat uživatelskou akci a na základě dat obdržených z webového formuláře přejít do požadovaného stavu, zde buď koncového, anebo stavu pro přidání dodatečných informací. Zpracování se provede pomocí aktivity OnTaskChanged. V závislosti na výsledku se pomocí IfElse aktivity vybere jedna z možných větví a pomocí SetState aktivity se přejde do požadovaného stavu, tak jak je to znázorněno na následujícím obrázku. 112

113 Obrázek 73: Detail EventDriven aktivity reakce na změnu ve stavu úkolu Nejprve se podíváme na nastavení aktivity OnTaskChanged. Zde je nutné nastavit minimálně následující vlastnosti: CorrelationToken jak již bylo zmíněno, musí být nastaven na stejný token jako u aktivity, která tento úkol vytváří. Tím dojde ke spojení požadovaných aktivit a WorkflowRuntime bude vědět, že se týkají stejného úkolu. TaskId je potřeba napojit na již existující pole obsahující ID úkolu, které bylo vytvořeno během vytváření úkolu. AfterProperties jedná se o objekt typu Hashtable, který po změně úkolu, tedy po změně položky SPListItem, jež reprezentuje úkol, vrátí vlastnosti na této položce SPListItem změněné. Tento objekt napojíme na nové pole (zde pojmenované approveafterproperties ), pomocí kterého následně získáme hodnoty vložené do úkolu pomocí webového formuláře. 113

114 Obrázek 74: Vlastnosti aktivity OnTaskChanged Invoked opět specifikuje metodu, k jejímuž spuštění dojde při vstupu workflow do této aktivity. Dvojklikem lze vygenerovat automaticky. Tuto metodu upravíme následujícím způsobem. private void onapprovetaskchanged_invoked(object sender, ExternalDataEventArgs e) object changed = approveafterproperties.extendedproperties["changed"]; this.approvetaskchanged = Convert.ToBoolean(changed); object action = approveafterproperties.extendedproperties["action"]; this.selectedaction = Convert.ToByte(action); if (this.selectedaction == ADD_INFO) object info = approveafterproperties.extendedproperties["requestedinfo"]; requestedinfo = info as String; V této metodě se snažíme získat informace, které byly odeslány do workflow pomocí metody SPWorkflowTask.AlterTask z webového formuláře. Pomocí této metody jsme upravili vlastnosti úkolu tak, aby obsahoval i vlastnosti definované v objektu Hashtable, který se předával jako argument metodě SPWorkflowTask.AlterTask. Teď k těmto objektům můžeme přistoupit podobným způsobem, tedy najdeme objekty v Hashtable pod těmi samými klíči, pod kterými jsme je do objektu Hashtable ve webovém formuláři ukládali. Prvním získávaným objektem je informace o tom, zda byl úkol opravdu editován naším webovým formulářem. Protože Hashtable vrací vždy pro daný klíč instanci třídy Object, je nutné přetypování. object changed = approveafterproperties.extendedproperties["changed"]; this.approvetaskchanged = Convert.ToBoolean(changed); 114

115 Dále je nutné zjistit, kterou akci uživatel vybral, a také tuto akci si uložit do globální proměnné. Pokud uživatel vybral akci Požádat o dodatečné informace, tak z objektu ExtendedProperties získáme ještě řetězec specifikující, co konkrétně schvalovatel požaduje. Pro kontrolu vybrané akce používáme konstantu ADD_INFO. Získané hodnoty si ukládáme do dříve definovaných globálních proměnných. Nyní, když jsme získali informace z webového formuláře, je nutné na jejich základě rozhodnout, do kterého stavu má workflow přejít. Na obrázku detailu aktivity approvechangedevent jsou vidět dvě větve. Jedna přechází do konečného stavu a druhá do stavu sloužícího pro přidání informací. Nejprve nastavíme podmínku pro větev, která přechází do stavu pro přidání dodatečných informací. Použijeme deklarativní podmínku (Declarative Rule Condition) tak, jak ukazuje následující obrázek: Obrázek 75: Nastavení deklarativního pravidla pro přechod do stavu přidání informací Jinými slovy, chceme přejít do této větve v případě, že byl úkol změněn a vybraná akce měla hodnotu konstanty ADD_INFO. this.selectedaction == RequestWF.RequestWF.ADD_INFO && this.approvetaskchanged V případě druhé větve budeme chtít podmínku upravit. Nutné bude, aby byl úkol změněn a vybraná akce neměla hodnostu konstanty ADD_INFO, tedy aby měla hodnotu konstanty APPROVE nebo REJECT, ale to zde již není podstatné. this.selectedaction!= RequestWF.RequestWF.ADD_INFO && this.approvetaskchanged Pak zbývá již jen upravit vlastnosti TargetStateName u aktivit SetState a máme vyřešenou změnu úkolu, tedy změnu stavu požadavku, a můžeme přejít k úpravě stavu, který slouží k přidání dodatečných informací. 115

116 16.7 Stav přidání dodatečných informací Modelování tohoto stavu bude již mnohem jednodušší. První aktivitou bude StateInitialization. V této aktivitě opět vytvoříme nový úkol, ve kterém žadatel doplní požadované informace. Struktura této aktivity bude podobná jako v případě prvního stavu, bude tedy obsahovat pouze jednu CreateTaskWithContentType aktivitu. Opět zde bude nutné nastavit vlastnosti, které byly nastavovány i v případě prvního stavu, tedy především: CorrelationToken, TaskId, TaskProperties a Invoked, tj. odkaz na metodu, která se má vyvolat. Struktura této metody bude opět velice podobná té již dříve uvedené. private void createaddinfotask_methodinvoked(object sender, EventArgs e) addinfotaskid = Guid.NewGuid(); addinfotaskproperties = new SPWorkflowTaskProperties(); addinfotaskproperties.title = "Doplňte dodatečné informace"; addinfotaskproperties.assignedto = requesterlogin; addinfotaskproperties.extendedproperties.add("requestedinfo", requestedinfo); Zde jsou pouze dvě změny. Úkol je přiřazen osobě, která vyplňovala požadavek, login této osoby máme uložen v globální proměnné requesterlogin. A dále je do objektu ExtendedProperties přidána hodnota proměnné requestedinfo. Tu jsme získali z minulého úkolu, v momentě, kdy schvalovatel požádal o dodatečné informace. Jakmile tuto proměnnou vložíme do objektu ExtendedProperties, můžeme k ní přistupovat pomocí objektu Hashtable získaného ve webovém formuláři voláním. wfproperties = SPWorkflowTask.GetExtendedPropertiesAsHashtable(task); Teď je již nutné pouze zpracovat změnu tohoto úkolu. Změnu zpracujeme pomocí aktivity OnTaskChanged. Následující obrázek ukazuje detail EventDriven aktivity, která obsahuje OnTaskChanged aktivitu a následně aktivitu SetState, jež přejde zpět do schvalovacího stavu za podmínek určených aktivitou typu IfElse. 116

117 U aktivity OnTaskChanged je nutné nastavit CorrelationToken a TaskId tak, aby odpovídaly hodnotám z výše uvedené aktivity CreateTaskWithContentType. Dále je nutné napojit vlastnost AfterProperties na novou proměnnou, která umožní získat potřebná data po změně úkolu. Posledním krokem bude určení metody, která má být zavolána pomocí vlastnosti Invoked. Tato metoda bude obsahovat následující kód: private void onaddinfochanged_invoked(object sender, ExternalDataEventArgs e) object changed = addinfoafterproperties.extendedproperties["changed"]; this.addinfotaskchanged = Convert.ToBoolean(changed); if (addinfotaskchanged) object info = addinfoafterproperties.extendedproperties["addedinfo"]; this.addedinfo = info as String; Zde opět používáme vlastnosti úkolu po změně, tedy objekt AfterProperties, abychom získali informace z webového formuláře. Jednak proměnnou indikující, zda byl formulář změněn, a jednak dodatečné informace, tedy řetězec, který vyplnil žadatel. Zde se tedy opět odkazujeme na klíče, pod kterými jsme vložili informace do objektu Hashtable, jenž byl použit ke změně úkolu. Zde je pro doplnění uvedena ta část kódu webového formuláře, ve které vytváříme objekt Hashtable, abychom s jeho pomocí editovali položku SPListItem reprezentující úkol. 117

118 Hashtable returntable = new Hashtable(); returntable.add("changed", 1); returntable.add(spbuiltinfieldid.percentcomplete, "100"); returntable.add(spbuiltinfieldid.taskstatus, "Dokončeno"); returntable.add("addedinfo", txtinfo.text); Právě pod klíčem AddedInfo jsme tedy schopni získat řetězec reprezentující informace, které uživatel doplnil. Jakmile máme zpracovánu událost o změně úkolu, je již jen potřeba zaručit, aby došlo k přechodu do počátečního stavu. Avšak pouze, pokud byl úkol opravdu změněn a dodatečné informace doplněny. Za aktivitu OnTaskChanged je tedy vložena IfElse aktivita, která kontroluje, zda došlo ke změně úkolu. Podmínka této aktivity je opět zadána pomocí deklarativního pravidla (Declarative Rule Condition) a pouze odkazuje na proměnnou, ve které je již indikace změny úkolu uložená. Stačí tedy nastavit podmínku na: this.addinfotaskchanged Vložená aktivita SetState má nastaven jako cílový stav počáteční schvalovací stav našeho workflow Ladění aplikace Visual Studio 2008 nám usnadňuje ladění workflow. Stačí pouze spustit projekt stisknutím klávesy F5 a automaticky se otevře okno prohlížeče přesměrované na stránku se seznamem, ke kterému je workflow připojeno. Zde je možné vkládat breakpointy na libovolná místa, i na jednotlivé aktivity ve workflow diagramech, a můžeme tak odkrokovat celou aplikaci. Pokud vložíme projekt webového formuláře do stejného řešení jako u projektu workflow a projekt workflow necháme nastaven jako inicializační ( Set As Start Up Project v kontextovém menu Solution Exploreru), budeme moci ladit zároveň i kód webových formulářů. SharePoint používá pro svůj běh proces označený w3wp. Visual Studio po stisknutí F5 provede hned několik úkonů: Nainstaluje nebo aktualizuje dynamickou knihovnu v Global Assembly Cache Nainstaluje a aktivuje feature obsahující workflow na nastavenou stránku v SharePointu Provede restart IIS serveru Připojí Debugger k procesu w3wp na lokálním počítači Všechny tyto kroky bychom mohli provést ručně, nicméně Visual Studio ušetří hodně času právě tím, že vše provede jednorázově a za nás. Webové stránky ve složce LAYOUTS jsou také spouštěny procesem w3wp. Pokud tedy máme stránky ve stejném projektu jako workflow a debugger je připojen k procesu w3wp, Visual Studio nám umožní ladit i webové formuláře. 118

119 Ladění na vzdáleném počítači Pokud ovšem převedeme vytvořené řešení do produkčního prostředí, tedy většinou na jiný než vývojový počítač, kde nebude nainstalované Visual Studio 2008, budeme muset použít vzdálené ladění, tj. připojit Debugger k procesům běžícím na jiném počítači. K tomu je nutné spustit na hostitelském stroji nástroj Remote Debugger Ten je možné samostatně stáhnout nebo jej můžete najít v instalaci vašeho Visual Studia. Jakmile spustíme tento nástroj na hostitelském stroji, můžeme se vzdáleně z Visual Studia připojit k tomuto stroji a připojit Debugger k procesu w3wp. Zvolíme v menu Tools, Attach to Process a v novém dialogu zadáme do pole Qualifier jméno nebo IP adresu vzdáleného počítače. Po aktualizaci seznamu procesů bychom již měli být schopni lokalizovat proces w3wp. Samozřejmě je nutné mít na hostitelském a vývojovém počítači stejné verze dynamických knihoven Deployment přenos do produkčního prostředí Pro přenesení workflow do produkčního prostředí je vhodné si uvědomit, které části je nutné převést a kam jednotlivé dynamické knihovny umístit a nainstalovat. Zde ještě jednou krátký přehled: Global Assembly Cache Dynamická knihovna workflow Dynamická knihovna webových formulářů BIN složka IIS serveru Dynamická knihovna webových formulářů Složka FEATURES Feature pro vložení nových typů obsahu Feature obsahující odkaz na workflow Složka TEMPLATES Webové formuláře Aby proces instalace několika nových funkcí mohl být proveden jednorázově, lze využít technologii SharePoint Solutions. SharePoint Solutions jsou balíčky dodatečných funkčností zkomprimovaných do jednoho souboru, které lze jednorázovou instalací nasadit na konkrétní portál SharePointu. Řešení se skládají především z features a webových stránek, ale mohou obsahovat i další položky, například webové části (SharePoint Web Parts). Instalace řešení se provádí pomocí nástroje STSADM. SharePoint Solutions jsou soubory s příponou WSP, jež musí obsahovat XML soubor manifest.xml, který definuje obsah řešení. Zde se konkrétně tvorbou WSP balíčků nebudeme zabývat. Je vhodné poznamenat, že existuje celá řada open source nástrojů, které mohou usnadnit tvorbu řešení. Jedním z nejlepších je bezesporu nástroj WSPBuilder, který je lze integrovat do Visual Studia 2008, a nastavit tak, aby po kompilaci došlo vždy ke zkompilování všech částí projektu do WSP balíčku a ten mohl být následně bez dalších komplikací převeden do produkčního prostředí. 119

120 16.10 Ukázka fungování systému Vložení požadavku se provádí otevřením šablony na seznamu požadavků. Pokud jsou na SharePoint serveru povoleny InfoPath Services, je možné požadavek vyplnit přímo jako webovou stránku. Pokud tomu tak není, je nutné mít nainstalovaný InfoPath na klientském počítači. Obrázek 76: Zadání požadavku Po kliknutí na tlačítko Odeslat se okno s formulářem zavře a zobrazí se přehled požadavků s již vloženým vyplněným formulářem. Zde si můžete všimnout, že sloupce tohoto seznamu odpovídají polím formuláře stejně jako hodnoty vložené do těchto polí. Obrázek 77: Seznam požadavků V pravém rohu tohoto seznamu je u vloženého požadavku sloupec, ve kterém je stav workflow. Protože je povoleno automatické spuštění workflow ihned po vložení požadavku je zde již workflow spuštěné (hodnota Probíhá nebo In Progress podle jazykové mutace SharePointu). Po kliknutí na tento odkaz se otevře stránka s bližšími informacemi o workflow. 120

121 Obrázek 78: Stav workflow v prostředí SharePointu Na této stránce je vidět mimo jiné, kým a kdy bylo workflow započato, ke kterému dokumentu se vztahuje, jaký je jeho status a ve spodní části seznam úkolů, které se k tomuto workflow vztahují. Zde vidíme, že byl vytvořen první úkol s názvem Schvalte požadavek na nový software. Po kliknutí na odkaz se otevře webová stránka, kterou jsme pro tento úkol vytvořili. Obrázek 79: Úkol schválení požadavku Pro tuto chvíli jsme jako schvalovatel zvolili žádost o dodatečné informace a vyplnili jsme, co konkrétně po žadateli požadujeme. Po kliknutí na tlačítko Odeslat se opět vrátíme na stránku s informacemi o workflow, zde se změnil seznam úkolů. 121

122 Obrázek 80: Stav workflow po dokončení více úkolů Je vidět, že je zde druhý úkol, přidělený osobě, která vyplňovala žádost. Stav prvního úkolu je nastaven na Dokončeno. Po kliknutí na odkaz úkolu se otevře připravený formulář, s žádostí o dodatečné informace. Obrázek 81: Úkol sloužící k doplnění informací Jakmile uživatel stiskne tlačítko Odeslat, formulář se zavře a uživatel se ocitne zpět na stránce s informacemi o workflow. Zde je opět možné otevřít nový úkol, ve kterém je schvalovatel žádán o schválení. Pokud tentokrát schvalovatel provede schválení či zamítnutí, stav workflow stejně jako stav všech úkolů v tomto workflow bude nastaven na Completed nebo Dokončeno. Samozřejmě, pokud je na seznamu úkolů nastaveno automatické odesílání ů, uživatelé obdrží informaci o přiřazení nového úkolu poštou Závěr Závěrem ještě jednou popíšeme, které kroky byly potřeba k vytvoření workflow v SharePointu. 1. Vytvoření seznamu s dokumenty, na kterých bude spuštěno workflow, případně použití nástroje MS InfoPath k vytvoření toho seznamu včetně šablony dokumentu. 2. Vytvoření webových formulářů jako rozhraní pro uživatele workflow, publikování těchto formulářů do SharePointu. 122