Vítejte na blog.vyvojar.cz Přihlásit | Registrovat | Pomoc
Titulní Blogy Fotky Soubory

Mazinův blog o SharePointu

  • Připojení knihovny dokumentů SharePointu jako disk

    SharePoint může sloužit jako vylepšená náhrada sdílených sítových disků. Na rozdíl od nich poskytuje pokročilou práci s jejich vlastnostmi, právy, verzováním, rezervacemi, vyhledáváním a workflow. Navíc umožnuje i webový přístup. Někdy je ale důležité moci k souborům přistupovat postaru, tedy jako k sítovému disku. Například tehdy, když potřebujete nahrát do nebo z knihovny dokumentů větší množství souborů nebo pokud chcete do knihovny ukládat soubory z programů, které přímé ukládání do SP (na web) nepodporují. Dnes si popíšeme jak na to. Ponechme pro dnešek stranou variantu použití OneDrive pro synchronizaci knihovny na lokální disk.

    Jak dosáhnout toho, aby byl obsah knihovny dokumentů přístupný souborovým způsobem? Existují 3 základní způsoby:

    • Jednoduchá varianta je použití tlačítka Open with Explorer v ribbonu knihovny dokumentů. Tato varianta má svoje omezení: funguje jen v IE a neumožnuje namapovat knihovnu jako disk.
    • Když potřebujete mít obsah knihovny dostupný jako disk, lze to udělat pomocí z průzkumníka Windows kliknutím pravým tlačítkem na Tento počítač a použitím volby Připojit síťovou jednotku…. Dále zvolíte volné písmeno disku a zadáte adresu knihovny v jednom z níže popsaných formátů.
    • Mapování můžete automatizovat pomocí skriptů.

    Ať už zvolíte kteroukoli variantu, je dobré vědět, že souborový přístup do SharePointu je realizován pomocí technologie WebDAV. Jde o rozšíření HTTP protokolu. SharePoint tuto technologii podporuje coby WebDAV server. Protikusem je WebDAV klient, který souborové operace převádí na HTTP volání. Ten je automaticky nainstalovaný ve všech klientských systémech Windows. Ne ale na serverových! Na těch je potřeba zapnout funkci Desktop experience (správa serveru –> funkce serveru).

    Další důležitou věcí je, že připojovaný SharePoint je dobré mít v Internet Exploreru nastaven jako důvěryhodný server s povoleným automatickým přihlašováním.

    K samotnému mapování se používá příkaz NET USE.

    SharePoint on-premise

    V případě SharePoint on-premise je použití jednoduché. Můžete použít některou z následujících forem (jde o příklady) podle toho, co potřebujete:

    • NET USE Z: http://server/site/web/library
    • NET USE Z: \\server:port\site\web\library
    • NET USE Z: \\server\site\web\library /persistent:yes
    • NET USE Z: \\server\site\web\library /user:jmeno heslo

    Někdy bývá problém s připojováním knihoven dokumentů, které se nacházejí ve webových aplikacích se zapnutým formulářovým ověřováním. Možným řešením je extenze takové webové aplikace v Centrální administraci. Tím vytvoříte novou webovou aplikaci zpřístupňující stejný obsah jako původní. Můžete ji ale nastavit jiné autentizační metody. V našem případě bychom vypnuli formulářové ověřování a mapovali knihovnu pomocí této nové webové aplikace.

    SharePoint Online

    Varianty pro SharePoint Online se trochu liší. Jedním z rozdílů je to, že SharePoint Online běží přes HTTPS. Navíc je potřeba se k danému serveru předem přihlásit v Internet Exploreru a zaškrtnout: Keep me signed in. Tím získáte přihlašovací token s dlouhou platností.

    • NET USE Z: \\tenant.sharepoint.com@SSL\\site\web\library
    • NET USE Z: https://tenant.sharepoint.com/site/web/library
    • NET USE Z: \\tenant.sharepoint.com@SSL\DavWWWRoot\site\web\library
    • NET USE Z: \\mazinv.sharepoint.com@SSL\DavWWWRoot\site\web\library /persistent:yes

    Použití parametrů /user:user@tenant.sharepoint.com heslo bohužel nefunguje. Tímto způsobem nelze získat přihlašovací token. Někdy se může zdát, že to funguje. Je to ale jen v případě, že už máte platný token z dřívějška. Kvůli problémům se získáním (potřeba přihlásit se předem v IE) a obnovováním přihlašovacího tokenu můžete najít některé PowerShell skripty, které se to snaží řešit, nebo produkty třetích stran.

  • Next-gen portals v Office 365

    Microsoft investuje velké množství energie do Office 365 včetně SharePointu Online. Souvisí to s jeho strategií Cloud-first. Další myšlenkou, kterou lze v poslední době vypozorovat, je propojování služeb a využívání existujících technologií na pozadí nově dostupných funkcí. Cílem je využití synergického efektu. Tedy využití něčeho, co máme a přidání něčeho malého, abychom získali nový produkt, službu nebo funkci. Případně získání nové přidané hodnoty tím, že propojíme dvě nebo více existujících funkcí dohromady.

    Posledním (tedy ne z pohledu významu, pouze v mém výčtu) impulzem pro vytvoření něčeho nového je velké množství informací o v Office 365 provozovaných portálech, které má nyní MS k dispozici. Pokud jde o on-premise portály, mohou být zdrojem informací pro MS o tom, jak vypadají, pouze nejrůznější průzkumy nebo přímá účast MS na jejich tvorbě. V případě portálů v Office 365 může MS z titulu provozovatele získat mnohem přesnější představu, jak takové portály vypadají a s čím se jejich tvůrci nejčastěji “perou”.

    V MS identifikovali následující nejčastěji používané typy portálů:

    1. Rozcestníky pro existující obsah – ústřední místo pro navigaci uživatele po portálu ale i do jiných systému, vyhledávání napříč systémy
    2. Vyhledávače lidí – portály pro nalezení lidí, kteří mají hledanou kompetenci, znalost, zkušenost, …
    3. Knowledge base – sdílení znalostí mezi uživateli, pracovní postupy, známé chyby, dokumentace, návody…
    4. Video portály – návody a videoprezentace, kanály - zkrátka firemní YouTube
    5. Portály oddělení – informace poskytovaný např. HR týmem jako jsou onboarding informace, web IT s ServiceDeskem, …
    6. Portály uživatelů – místo kde jsou zobrazeny informace pro uživatele, jeho úkoly, dokumenty a informace na kterých aktuálně pracuje, schválené žádosti např. o dovolenou a podobně.

    Také zjistili (celkem bez překvapení), že typický portál dneška:

    1. obsahuje mnoho obrázků a videí
    2. často slouží pro ukládání znalostí firem v podobě knowledge base
    3. je na ně přistupováno z celé řady nejrůznějších zařízení s širokou škálou podporovaných funkcí a vlastností
    4. mnoho funkcí nabízených portály je založeno na hledání. Hledají se dokumenty, lidé, ale i dokumenty mající vztah k nějakému člověku a naopak.
    5. obsah je vytvářen hlavně přímo v prohlížeči, méně v speciálních aplikacích

    Odpovědí na tato zjištění mají být tzv. Next-gen portals.

    O co tedy jde?

    Předně je potřeba si říci, že zatím o nic hotového. Nic v produkční kvalitě. Dále jde hlavně o využití existujících věcí a jejich rozšíření. Next-gen portal si kladou za cíl zjednodušit tvorbu typických firemních portálů pomocí připravených šablon. Ideálně za využití něčeho existujícího.

    Office 365 Graph

    Toto je implementace Azure machine learning v prostředí Office 365. Obecně umožnuje pomocí strojového učení hledat vazby a vztahy mezi objekty. Tyto vazby a vztahy se hledají pomocí signálů. Signál může být například to, že uživatel si prohlédnul daný dokument, sleduje ho, prohlížel si profil jiného uživatele a podobně. Microsoft pracuje na tom, aby se mezi signály zpracovávané v Office Graph zahrnuly i operace z Exchange (příjem mailu, přílohy), Skypu, OneDrive.

    Cards

    Jde o zobrazení informací na stránce, tak aby bylo atraktivní, přehledné a umožnovalo zobrazit i informace různého charakteru (stránka, uživatel, video, office dokument, …). Dalším požadavkem bylo, aby bylo možné s jednotlivými objekty dělat operace, které mají smysl (sledování, označení klíčovým slovem,  přehrání videa, náhled a otevření dokumentu, …). Samozřejmostí je podpora responsivního designu, tedy uzpůsobení aktuálního zobrazení na základě rozlišení, velikosti obrazovky. Aktuální použití je v Office Delve.

    Delve

    Office 365 Video

    Funkce postupně rolloutovaná do tenantů. Využívá Azure Media Services na konverzi videí do nejrůznějších formátů a rozlišení tak, aby se jejich přehrávání přizpůsobilo možnostem prohlížeče a zařízení, které uživatel aktuálně používá. Do úvahy se bere i dostupná šířka pásma a umístění uživatele. Umístění má vliv na využití CDN sítě při přehrávání. Tzn. uživateli je obsah poskytován z nejlépe dostupného uzlu CDN sítě.

    Pro vytváření vazeb a hledání podobností mezi videi se využívá Office Graph. Na něm je postaveno fungování funkce Podobná videa.

    Pro přehrávání se využívá HTML5 klient, ale existují i nativní klienti pro různé platformy. Office 365 video má i své REST API, takže je možné vytvářet vlastní aplikace pro práci s ním (např. umístění videa, přehrávání podle možností, hledání souvisejících videí a podobně).

    People portal

    Vzniká jako následovník stránky About Me. Opět využívá Office Graph pro získání relevantních informací a cards pro jejich zobrazení. Tentokrát je pojítkem mezi zobrazenými informacemi uživatel. Řeší problém hledání  informací p lidech a obsahu, který se k nim vztahuje.

    User profile

    Knowledge management – codename “InfoPedia”

    Ve firmě (a nejen v ní) je člověk obklopen až zahlcen mnoha informacemi. Ty se dají rozdělit do 2 kategorií:

    • Informace shora – informace proudící z vedení k zaměstnancům, marketingové a jiné informační kampaně, prezentace. Typicky někým řízené.
    • Informace zespoda – reporty, dokumentace, informace pro stávající i nové kolegy – jak co pracuje, kdo je kdo. Často bez jasného řízení, ale se správcem.

    Mnoho zdrojů – emaily, OneDrive, teamové weby, … = problematické hledání. Pro vybudování rozumně použitelných knowledgebase portálů mají sloužit následující 2 technologie.

    Boards

    Zobrazení informací (dokument, příloha mailu, video, yammer vlákno, …) v podobě cards, které mají něco společného. Je to vlastně Delve, ale s tím, že takové zobrazení bude možné umístit na vlastní stránku a říci, co má být pojítkem zobrazených informací (jméno projektu, zákazníka a podobně). Označením např. dokumentu v Office 365 klíčovým slovem se dokument dostane na odpovídající board.

    Microsites

    Stávající možnosti tvorby obsahu v SharePointu neodpovídají aktuálním trendům. Práce s layoutem stránek, webparty a samotným obsahem není úplně jednouchá. Proto je snaha tento proces zjednodušit. Podobnou iniciativou, i když vedenou z jiného směru je projekt Sway. Ten míří na prezentace a je aktuálně rolloutován do všech tenantů. V rámci tohoto projektu je snaha zjednodušit a zmodernizovat proces tvorby prezentací dosud vytvářených v PowerPointu. I ten už je poněkud letitý. Ačkoli jde o nezávislé projekty, mají společný cíl a oba vývojové týmy spolupracují (opět snaha o synergický efekt).

    Úvodní stránka Microsite

    Microsites je web s úvodní stránkou, stránkami článků a automaticky generovanou navigací. Z mého pohledu jde o vylepšené wikistránky se sociálními funkcemi, snadnějším propojením na existující obsah Office365 a lepším editorem. Také je do nich možné umisťovat boardy a dokumenty (zobrazené pomocí Office Online). Technologicky opět podporuje responsivní design.

    Tvorba stránky v Microsite

  • Další várka novinek o SharePointu 2016

    Tak tady máme další várku informací o chystaném SharePointu 2016. Předně je potvrzeno, že SharePoint 2016 bude dostupný ve druhém kvartále 2016 s tím, že betaverze bude dostupná koncem roku 2015 (Q4 2015).

    Další potvrzení se týká toho, že i po mnoho dalších let chce Microsoft podporovat Online, on-premise i hybridní scénáře.

    Globálním cílem má být rozšíření funkcí SharePointu on-premise a zjednodušení využití výhod cloudu podporou hybridních scénářů.

    Vylepšení a nová funkcionalita SharePointu 2016 se týkají především 3 oblastí:

    • vylepšení uživatelské zkušenosti
    • cloudem inspirovaná infrastruktura
    • Ochrana dat a auditování
    Vylepšená uživatelská zkušenost

    Podle prohlášení Microsoftu nová verze bude lépe podporovat mobilní a dotyková zařízení s různou velikostí obrazovky. Chce také nabídnout přímočařejší přístup k informacím. Jednak tím, že vylepší funkce jako Office Graph a Delve tak, aby pracovaly jak s daty uloženými v SharePoint Online, tak v SharePoint on-premise. Další vylepšení se mají týkat větší integrace mezi SharePointem, Exchange a Yammerem. Do on-premise světa se chystá i nedávno uvolněná funkce Office365 videa.

    Cloudem inspirovaná infrastruktura

    SharePoint 2016 má být první on-premise verzí, do které se Microsoft pokusí zapracovat zkušenost z provozování SharePointu ve vlastních datových center v rámci Office365. Mělo by to přinést vyšší spolehlivost, výkon a rozšířit podporu hybridních scénářů, která zatím je dost omezená. Dalším cílem v této oblasti je integrace s novou verzí Windows Serveru, chystanou novou verzí SQL Serveru a Exchange 2016.

    Rovněž je v plánu rozšiřování API SharePointu a umožnění tím další rozvoj ekosystému řešení využívajících SharePoint.

    Ochrana dat a auditování

    Nová verze se zaměří i na podporu ochrany dat. Nejde jen o zálohování, ale hlavně ochranu citlivých dat před zcizením. Na to kladou důraz jak právní předpisy, tak nejrůznější certifikace a audity. Vzpomeňme například ISO 27001. Půjde o funkce pro šifrování dat a nástroje pro kontrolu a evidenci umožňují vyvážit uživatelskou rozšiřovatelnost a samosprávu SharePointu na jedné straně a dodržování firemních politik na straně druhé.

    Další informace budou dostupné v rámci Ignite akce, která se bude konat 4-8. května v Chicagu.

    Z těchto zatím kusých informací je zřejmé, že se Microsoft pokouší o sevření pomyslných nůžek mezi funkcionalitou SharePointu Online a SharePointu on-premise. Ty se průběžně rozevírají s rolloutem každé další funkcionality v SharePointu Online. Za poslední dobu to jsou funkce jako:

    • Office Graf
    • Office Delve
    • Office Video

    O všech v souvislosti s SharePoint Serverem 2016 Microsoft hovoří. Zatím se ale jedná především obecné vize a tvrzení bez bližších detailů. Jsem zvědavý, jaký bude nakonec výsledek.

  • Programové získání změn provedených v SharePointu

    Někdy může být zajímavé zjistit všechny změny provedené v SharePointu nebo některé jeho části během určitého období. Typickým scénářem jsou různé evidenceTuto informaci byste se mohli pokusit získat pomocí CAML query s dotazem na hodnotu sloupce Modified. Tato metoda má ale několik omezení:

    • nezachytíte operace smazání a ani vícenásobnou úpravu (pokud byste chtěli reagovat na každou změnu zvlášť)
    • nedá se použít u ničeho jiného než u položek seznamů a knihoven dokumentů
    • při potřebě reagovat na změny napříč více seznamy byste museli kontrolovat každý z nich

    SharePoint provedené změny eviduje, především kvůli asynchronním event receiverům, notifikacím a workflow. V databázi mu k tomu slouží tabulka EventCache.

    Evidují se změny těchto typů objektů:

    • Položky, soubory a adresáře
    • Vlastnosti seznamů, fieldy
    • Vlastnosti webů, notifikace
    • Skupiny a uživatelé

    Naopak neevidují se změny těchto typů objektů:

    • webové aplikace
    • globální nastavení farmy
    • řešení (WSP), featury
    • webparty
    • konfigurace webů, kolekcí webů, webových aplikací a databází obsahu

    Evidované typy změn:

    • Přidání
    • Změna vlastností
    • Smazání
    • Přejmenování
    • Přesun položek mezi seznamy

    Můžeme zjišťovat  změny v rozsahu:

    • seznamu – SPList
    • webu – SPWeb
    • kolekce webů – SPSite
    • databáze obsahu – SPContentDatabase

    Všechny tyto třídy mají metodu GetChanges. Ta má 4 prototypy:

    • GetChanges()
    • GetChanges(SPChangeQuery) – změny vyhovující podmínce
    • GetChanges(SPChangeToken) – změny od časového okamžiky doteď
    • GetChanges(SPChangeToken, SPChangeToken) – změny mezi 2 časovými okamžiky

    Všechny vrací SPChangeCollection, což je kolekce potomků třídy SPChange, podle toho o změnu čeho šlo (např. SPChangeItem, SPChangeList, SPChangeUser, …).

    Zastavme se ještě na chvíli u SPChangeTokenu. Ten kombinuje několik informací dohromady. Má i svou textovou podobu, na které si můžeme ukázat, co reprezentuje. Má následující strukturu: Int1;Int2;Guid;Long;Int3

    • Int1 - verze change tokenu. aktuálně 1.
    • Int2 – scope změny
      • 0 – databáze obsahu
      • 1 – kolekce webů
      • 2 – web
      • 3 – seznam
    • Guid - unikátní ID objektu, kterého se událost týká
    • Long – timestamp provedení změny, vyjádřeno v tickech
    • Int3 – číslo změny v EventCache tabulce

    Příklad použití objektu SPChangeQuery:

    SPContentDatabase db = SPContext.Current.Site.ContentDatabase; SPSite site = SPContext.Current.Site; SPWeb web = SPContext.Current.Web; SPChangeToken token = new SPChangeToken(SPChangeCollection.CollectionScope.ContentDB, db.Id, DateTime.Now - timespan); SPChangeQuery query = new SPChangeQuery(false, false); //nastavíme, že nás zajímají změny položek. Dalšími možnostmi jsou oznámení, fieldy, uživatelé a podobně query.Item = true; //jaké typy operací nás zajímají query.Update = true; query.Add = true; query.Delete = false; query.ChangeTokenStart = token; query.FetchLimit = 10; SPChangeCollection changes = web.GetChanges(query);

    Tím ale bohužel práce nekončí. Spíš začíná. Jednotlivé změny, vrácené metodou GetChanges, jsou seřazeny chronologicky tak, jak byly postupně provedeny. Získáte ale jen sadu GUIDů identifikátorů jednotlivých objektů. Např. informace o změně položky obsahuje její ID, ID seznamu, ID webu a ID kolekce webů, kde se položka nachází. Žádné bližší detaily. Ty si musíte načíst z aktuální položky. Tedy pokud ještě existuje, protože se mohlo stát, že vámi zpracovávaná změna může být následována operací delete.

    Výsledky metody GetChanges nepodléhají security-trimmingu, tedy “ořezání” podle práv uživatele. Důvodem je především rychlost, protože může jít i za krátký časový interval o poměrně dost dat. Takže se dozvíte o vzniku, změně a smazání i objektů, ke kterým nemáte přístup. Jak jsme si už ale řekli, informací, které se o těchto změnách, dozvíte je minimum. Smyslem, kromě rychlosti, je i to, že z nich nic (ani tajného) nezjistíte. Musíte je použít jako parametry metod pro získání webů, seznamů, položek a ty už security-trimming obsahují. Díky tomu tento mechanizmus nevytváří zadní vrátka do systému. Maximálně se s jeho pomocí dozvíte, že v čase T byla vytvořena položka s ID = Y.

    A jak dlouho do minulosti se můžeme podívat? To záleží na nastavení vlastnosti ChangeLogRetentionPeriod třídy SPWebApplication. Standardní hodnota je 60 dní. Poté jsou záznamy prostřednictvím jobu smazány.

  • Zvláštnosti notifikací při přidání uživatele do skupiny

    Když v SharePointu přidáváte uživatele do skupiny, můžete mu poslat oznámení o této úžasné události. Před pár dny jsem si s touto funkcí trochu hrál a přišel jsem na některé zvláštnosti.

    Tak například email, na který se notifikace odesílá, se bere z domény a ne ze seznamu UserList v SharePointu. Měl jsem uživatele, který měl v doméně email A@domena.cz, ale v seznamu uživatelů měl email B@domena.cz. Ostatní notifikace (o přiřazení úkolů, uživatelské informující o změnách v seznamech) chodily na 2. z nich, ale ty o přidání do skupiny na 1. Doprovodný efekt je, že pokud uživatel nemá v doméně vyplněný email, notifikace mu nedorazí. Poznat se to dá tak, že při kontrole jména se v tooltipu objeví, nebo neobjeví i email uživatele.

    Tomuto uživateli email neodejde.

    Druhou podivností je, že v předmětu onoho notifikačního není nic o přiřazení do skupiny. V anglickém SharePointu je předmět emailu “User XY has invited you to ‘jmeno webu’”. A to i přesto, že členstvím v dané skupině nemusíte získat přístup vůbec nikam. Z těla mailu už pak už naštěstí přijdete na to, o co jde.

  • A zase ten IFRAME!

    IFRAME prvek je v HTML dlouho a celou dobu má kontroverzní pověst. Umožnuje dělat užitečné a zajímavé věci, ale současně taky představují způsob, jak realizovat nejrůznější útoky na uživatele. Celé je to o tom, že díky IFRAMU můžete do jednoho okna prohlížeče dostat obsah ze 2 zdrojů. V ideálním případě jsou oba mírumilovné. V horším případě jeden z nich není a obvykle používá ten druhý (mírumilovný) jako zástěrku. Navíc často zneužívá nějaké zranitelnosti prohlížeče tak, aby měl uživatel pocit, že pracuje jen s mírumilovným obsahem. Protože je obsah stránky a obsah IFRAMU zobrazen v jednom okně, sdílejí objektový model a javascriptem mohou navzájem ovlivňovat obsah toho druhého.

    Z pohledu bezpečnosti by asi bylo nejlepší IFRAMy zrušit, ale jejich použití je natolik rozšířené, že to nepřipadá v úvahu. SharePoint apps je využívají v tzv. app partech, což není nic jiného než IFRAME. Prohlížeče se proto snaží omezit možnosti míchání obsahu různými restrikcemi jako je např. zobrazením chybové hlášky v situaci, kdy se míchá obsah získaný pomocí HTTPS a HTTP protokolu.

    Jedním z posledních útoků, který zneužívá IFRAME je tzv. clickjacking. Ten spočívá v tom, že mateřská stránka obsahuje nebezpečný kód a IFRAME, který zobrazuje něco užitečného, např. SharePoint. IFRAME je dost veliký, takže uživatel má pocit, že kouká na stránku jen a pouze s SharePointem. Podvodný JS “unese” kurzor myši a za uživatele “klikne” na něco, na co by normálně uživatel nekliknul. Existuje i varianta, kdy uživatel má pocit, že kliká na něco užitečného, ale ve skutečnosti kliká na něco jiného (obvykle neviditelného a škodlivého). Blíže se o tomto útoku můžete dočíst na Wikipedii.

    Obrana proti tomuto typu útoků je v podstatě dvojí:

    • Pomocí JS na stránce tak, aby nemohla být zneužita v IFRAME – v podstatě aktivní způsob obrany. Problém této metody je v tom, že je jen tak dobrá, jak dobrý použijete obranný skript.
    • Pomocí HTTP hlavičky X-FRAME-OPTIONS – tato metoda zabraňuje zobrazení stránky v IFRAME. Je ale účinná pouze u prohlížečů, které ji podporují (viz. níže).

    X-FRAME-ORIGIN může nabývat následujících hodnot:

    • DENY – zakazuje zobrazení v IFRAME
    • SAMEORIGIN – umožnuje zobrazit stránku v IFRAME jiné stránky ze stejného serveru
    • ALLOW-FROM server URL – umožnuje zobrazit stránku v IFRAME nacházejícím se na serveru s daným URL

    Tabulka podpory X-FRAME-ORIGIN hlavičky

    Prohlížeč DENY/SAMEORIGIN podporován od ALLOW-FROM podporován od
    Chrome 4.1.249.1042  
    Firefox (Gecko) 3.6.9 (1.9.2.9) 18.0
    Internet Explorer 8.0 9.0
    Opera 10.50  
    Safari 4.0  

    Tak jako v mnoha jiných případech je zajímavé, jak různě různé prohlížeče reagují na přítomnost této hlavičky na stránce v IFAME. Zatímco Chrome nezobrazí nic, Internet Explorer zobrazí IFRAME a v něm chybovou hlášku. Podobně různě reagují vnitřně. Obvykle načtou základní stránku (ta, co obsahuje hlavičku X-FRAME-ORIGIN) ale většina z nich díky vícevláknovému zpracování začne okamžitě stahovat i referencované obrázky, CSS a JS. V okamžiku, kdy parser zjistí přítomnost X-FRAME-ORIGIN, aktuální stahování jsou přerušena.

    SharePoint tuto hlavičku používá s hodnotou SAMEORIGIN. Vychází se z toho, že SharePoint standardně neběží v IFRAMU, ani k tomu není určen. Nicméně mohou existovat situace, kdy potřebuje nějakou svoji část zobrazit sám v sobě. Proto ta hodnota SAMEORIGIN. Pokud potřebujete z nějakého důvodu, aby SharePoint byl zobrazen v IFRAMU umístěném na stránce jiné domény, musíte mu k tomu pomoci. Slouží k tomu serverový prvek <WebPartPages:AllowFraming runat="server"/>. Pokud je na stránce přítomen, SharePoint negeneruje X-FRAME-ORIGIN mezi hlavičky odpovědi. Můžete ho podle potřeby umístit:

    • na konkrétní stránku
    • do masterpage – pokud chcete ovlivnit všechny stránky odvozené od dané masterpage

    Prvek lze přidat i pomocí SharePoint Designeru. Samozřejmě musíte mít před jeho použitím registrovaný prefix:

    <%@ Register Tagprefix="WebPartPages" Namespace="Microsoft.SharePoint.WebPartPages" Assembly="Microsoft.SharePoint, Version=15.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" %>
    
  • SharePoint 2016 poodhalen

    Julia White generální manažerka Office Product Management týmu oznámila některé informace o chystané nové verzi SharePointu. Další informace budou oznámeny na Microsoft Ignite 4. - 8. 5. 2015.

    Z uveřejněných informací plyne, že novinky se budou točit kolem SharePointu Online. To je logické, protože do něj investoval Microsoft mnoho energie. Jednak budou posíleny možnosti integrace mezi SharePoint on-premise a SharePoint online pro použití v hybridních scénářích. Toto je v současnosti slabým místem, které určitě potřebuje vylepšit.

    Pokud jde o další vylepšení, půjde vlastně o přenos některých funkcí implementovaných v SharePointu online do on-premise světa. Týká se to:

    1. Vyhledávání a zejména Delve
    2. Práce se soubory -  viz. rozvoj OneDrive, OneDrive for Business
    3. BI – podpora Power BI
    4. Rozšiřování API tak, aby byly nové funkce dostupné a konzumovatelné z mimo SharePoint. Viz. koncept SharePoint Apps.

    Myslím, že se máme na co těšit.

  • Načítání dat ze seznamu do Excelu

    Excel se velmi často používá nejen k práci s tabulkami dat a kreslení grafů, ale mnohdy i k tvorbě “formulářů” pro výpočet případně vyplnění kdečeho. Takový formulář kromě informací zadaných uživatelem zpracovává i informace načtené např. z SharePointu.

    SharePoint umožnuje načítání dat do Excelu pomocí tlačítka v ribbonu. Tento způsob je velmi jednoduchý. Takto můžete načítat data z konkrétního zobrazení seznamu nebo knihovny dokumentů. To znamená, že si můžete definovat podmínku, řazení a vybrat sloupce, které chcete zobrazit. Technicky to pak probíhá tak, že SharePoint sestaví soubor s příponou iqy. Je to definice datového zdroje a přípona je asociována s Excelem. Ten na otevírání takového souboru reaguje tak, že vloží do aktuálně otevřeného XLS souboru nový datový zdroj a na nový nebo existující list zobrazí načtená data. To aby bylo zřejmé, jestli napojení funguje nebo ne. Důležité na tomto způsobu je, že XLS soubor obsahuje kopii dat a současně je v něm uložena i definice datového zdroje. Díku tomu můžete soubor použít offline (bez dostupnosti SharePointu) a pokud je SharePoint jako datový zdroj dostupný můžete provést aktualizaci dat.

    Na druhou stranu má tento jednoduchý scénář i nevýhody. Jednou z nich je, že se do XLS souboru načítají všechna data ze zobrazení a teprve v Excelu se vybírají jen ty, které jsou skutečně potřeba. Například podle uživatelem vyplněných hodnot. Načítání celého zobrazení může někdy představovat mnoho dat, i když je nebudete nikdy potřebovat všechny najednou. Jednak se tím zbytečně zvětšuje excelový soubor, ale narůstá tím i množství přenášených dat při aktualizaci. 

    Praktický příklad:

    Mějme excelový soubor fungující jako formulář, ve kterém zaměstnanci vykazují náklady služebních cest. Služební cesty jako takové se do SharePointu dostanou dříve a mohou procházet i nějakým schvalování. V našem scénáři zaměstnanec vybere služební cestu a zaeviduje výdaje, které mu v jejím rámci vznikly. Můžeme vytvořit zobrazení v seznamu služebních cest, které bude obsahovat jen nevyúčtované služební cesty, ale i to může představovat poměrně dost dat. Ideální by bylo si načíst jen služební cesty aktuálního uživatele za jim zvolený měsíc. Toho ale standardním způsobem nedosáhneme. Naštěstí si můžeme pomoci jinak.

    Dá se využít toho, že SharePoint podporuje REST volání a OData protokol a Excel umožnuje zpracovávat OData datové zdroje. Navíc s datovými zdroji (nejen s OData) umožnuje manipulovat pomocí maker. Takže si můžeme do Excelu dát datový zdroj v podobě http://server/kolekce/web/_api/lists/getlistbyname(‘Seznam’)/Items?rest dotaz. Nechci se teď pouštět do hlubšího rozboru práce s REST rozhraním, ale nedá mi to, abych si nepostesknul: Všimněte si toho getlistbyname. Není možné otevřít seznam podle jeho URL. Smutný obličej Druhou alternativou, kterou podle MSDN máme, je otevření seznamu pomocí jeho ID (GUID).

    V ribbonu Data použijeme volbu Načíst data z externích zdrojů a variantu Z datového kanálu OData.

    V následujícím okně do pole Odkaz nebo soubor vyplníme URL http://server/kolekce/web/_api/lists/getlistbyname(‘Seznam’)/Items. Excel standardně uloží definici datového zdroje do externího souboru. Musíme si ho znovu otevřít a provést jakoukoli změnu, aby ho uložil přímo do XLS souboru. Když se podíváme do definice datového zdroje, najdeme v poli Připojovací řetězec něco podobného:

    Data Source="https://server/_api/web/lists/getByTitle('Seznam')/items";Namespaces to Include=*;Max Received Message Size=4398046511104;Integrated Security=SSPI;Keep Alive=true;Persist Security Info=false;Base Url=https://server/_api/web/lists/getByTitle('seznam')/items

    Naše URL se v něm objevuje 2x. Pro nás je důležitá část Base Url na konci. Jejím měněním se dá ovlivňovat to, co SharePoint bude vracet. Ani tentokrát se nechci věnovat REST dotazům podrobně, na to si nechám samostatný příspěvek. Pro tuto chvíli si řekněme, že na konci adresy se dá pomocí REST syntaxe specifikovat podmínka, kterou musí záznamy splňovat, řazení a další věci obvyklé při dotazování. Detaily najdete na MSDN. Takže není problém načíst jen ty záznamy, které vyhovují nějaké podmínce a klidně tuto podmínku poskládat z informací zadaných uživatel.

    Zde máme příklad, jak můžeme pomocí VBA v Excelu měnit connection string a provést aktualizaci dat:

        Dim mm As String
        mm = ActiveWorkbook.Connections("jméno zdroje").DataFeedConnection.Connection
        ActiveWorkbook.Connections("jméno zdroje").DataFeedConnection.Connection = mm & "?$filter=Type eq 'Test'"
        ActiveWorkbook.Connections("jméno zdroje").Refresh

    Samozřejmě je to velmi zjednodušený příklad. Podmínka je statická, nefungoval by správně při opakovaném provedení a dalších situacích. V tuto chvíli mi jde spíše o demonstraci myšlenky, než kompletní řešení.

  • Provádění dlouhých operací v UI

    I v SharePointu občas dojde k situaci, kdy je potřeba provést delší operaci. Znáte to: vytváření webů,… Při vývoji vlastních řešení na to určitě narazíte také. Pro ASP.NET existuje několik řešení nejčastěji v podobě javascriptů, které na stránce vykreslují točící se kolečko nebo něco podobného, co uživateli říká “ještě vydrž …”.

    SharePoint nám k tomu poskytuje podporu v podobě 2 tříd: SPLongOperation a SPStatefulLongOperation. Na obě se dnes podíváme blíže. Jejich problém spočívá v tom, že jsou mizerně dokumentované v MSDN a na internetu se o nich a jejich použití spoustu zavádějících informací.

    Timeouty

    Jednou z nepřesností je otázka timeoutů. Dočtete se, že tyto třídy umí “obejít” standardní timeouty pro zpracování stránek. Možná to tak v předchozích verzích SharePointu bylo, ale v SharePointu 2013 to bohužel neplatí. Timeouty jsou standardně 110 nebo 360 sekund podle umístění stránky. Nastavují se ve vlastnosti executionTimeout elementu httpRuntime. Pro aplikační stránky platí 360s, který je nastaven ve <SharePoint>\template\layouts\web.config. Když se do něj podíváte, zjistíte, že mnoho systémových stránek má vlastní, delší. Pro ostatní stránky (např. stránky z knihovny stránky webu) se uplatňuje nastavení web.configu příslušné webové aplikace. A protože v něm SharePoint standardně nemá tento atribut nemá (pouze pro některé konkrétní stránky), platí výchozí hodnota ASP.NET, tedy 110s. Bez použití těchto dvou objektů skončí zpracování stránek po vypršení diskutovaných timeoutu vyjímkou.

    Naštěstí se problém timeoutů dá řešit přímo v kódu vaší stránky/webpartu/user controlu nastavením this.Page.ScriptTimeout na hodnotu, kterou považujete pro zpracování vaší operace za dostatečnou (ideálně s nějakou rezervou pro případ většího zatížení serveru). Nedoporučuju to zase přehánět. Připravíte se tak o indikátor toho, že je něco špatně, když váš kód bude trvat výrazně déle, než by měl.

    Nezapomeňte ale, že zpracování klientských požadavků v SharePointu ovlivňuje více timeoutů. Jedním z dalších je i FormDigest timeout. I když by se mohlo na první pohled zdát, že se to týká pouze formulářového přihlašování, není to pravda. FormDigest je bezpečnostním prvkem ve formulářích (odtud to form) ale nejen tam. Ano to je ten, který občas způsobuje chybu: The security validation for this page is invalid. Click Back in your Web browser, refresh the page, and try your operation again.). Kromě jiných vlastností má i dobu platnosti. Standardně 30min. Takže pokud zpracování vaší stránky bude trvat déle než 30 minut, budete muset řešit i tento timeout.

    Použití

    Zahájení

    Oba objekty se používají podobně. Nejprve zavoláte některou z metod Begin. Tím SharePointu řeknete, aby uživateli zobrazil “čekací stránku”, pak provedete to, co dlouho trvá, a na konci uživatele nejčastěji přesměrujete na stránku s výsledkem (může to být samozřejmě i stránka na které uživatel aktuálně je). Variantně na konci můžete uživateli “poslat” javascript, který provede něco spektakulárního.

    SPStatefullLongOperation se od SPLongOperation liší tím, že podporuje aktualizaci stavu operace v jejím průběhu. Můžete tedy uživateli zobrazovat něco jako “už jsem zpracoval 6 položek z 15” a postupně to aktualizovat. Toto se nicméně dá realizovat i vhodným použitím LeadingHTML u SPLongOperation. Například využitím javascriptu, který bude např. volat webovou službu a zjišťovat průběžný stav. Při použití SPStatefullLongOperation se aktualizace děje tak, že s každou aktualizací stavu se do response streamu (tedy na klienta) zapíše váš text (může to být i HTML a javascript).

    Oba objekty využívají stránku <SharePoint>\template\layouts\gear.aspx jako podklad pro zobrazení “točícího se kolečka” a informace, kterou mu dodáte. Uživatel zůstává na vaší stránce, ale po zavolání metody Begin je mu zobrazen obsah gear.aspx a vaše texty. K tomu slouží vlastnosti LeadingHTML a TrailingHTML. Obě vlastnosti slouží především k zobrazení informace o tom, co stránka tak dlouho dělá, např. “Právě vytvářím strukturu webů”.

    Můžete se podívat, jak vypadá základ gear.aspx, do kterého se vaše LeadingHTML a TrailingHTML vyrenderují. Teoreticky je možné změnou tohoto souboru změnit vzhled čekací stránky, ale není to doporučený ani podporovaný scénář. Minimálně se vám může stát, že update SharePointu vám ho přepíše.

    Podporovaným způsobem, jak ovlivnit vzhled a chování čekací stránky jsou zmiňované vlastnosti LeadingHTML a TrailingHTML. Díky tomu, že do nich můžete dát neencodované HTML, lze jejich prostřednictvím do stránky dostat javascript, CSS, HTML, … zkrátka téměř vše, co můžete potřebovat.

    Ukončení

    Po dokončení dlouhé operace zavoláte metodu End (má několik přetížení), nebo EndScript. V konečném důsledku End metody volají EndScript. Na rozdíl od přechozích verzí SharePointu se totiž přesměrování na cílovou stránku v metodách End neděje pomocí metody Response.Redirect, ale klientským javascriptem. Buď tím, který podporuje MDS (Minimal Download Strategy – standardně zapnuto např. na týmových webech), nebo prostým přiřazením window.location.href. Anebo vašim vlastním. To když použijete metodu EndScript.

    Při práci s těmito objekty určitě ošetřujte chyby a provádějte vlastní reakci na ně. Neošetřené vyjímky totiž vedou k tomu, že uživatel vidí často jen prázdnou stránku s titulkem “Chyba”. Když se podíváte do těla stránky tak zjistíte, že v ní to chybové hlášení je. Ale vzhledem k rozpadlému formátování uživatel nic nevidí, nebo vidí jen torzo (podle schopností prohlížeče).

    Příklad na závěr

    Jde o metody z mé testovací stránky. Každá demonstruje použití jednoho z objektů. Obě pracují s textovým polem RunningSeconds, do kterého jsem zadával čas pro otestování chování různě dlouhých operací. Tuto operaci simuluje metoda LongOperation, která simuluje dlouhý běh uspáním vlákna na určenou dobu.

    protected void LongOperation_Click(object sender, EventArgs e)
    {
         int seconds = Int32.Parse(this.RunningSeconds.Text);
         this.Page.Server.ScriptTimeout = seconds * 2;

         using (SPLongOperation longOp = new SPLongOperation(this.Page))
         {
             longOp.LeadingHTML = "LeadingHTML";
             longOp.TrailingHTML = "TrailingHTML";

             longOp.Begin();

             try
             {
                 LongOperation(seconds);
                 longOp.End(HttpContext.Current.Request.UrlReferrer.ToString());
             }
             catch (Exception)
             {
                 longOp.End(HttpContext.Current.Request.UrlReferrer.ToString()+"?Error=1");
             }
         }
    }

    protected void LongStateOperation_Click(object sender, EventArgs e)
    {
         int seconds = Int32.Parse(this.RunningSeconds.Text);
         this.Page.Server.ScriptTimeout = seconds * 2;

         SPStatefulLongOperation.Begin(
             "<span id='leadingSpan'>(0 of 10)</span>",
             "<span id='trailingSpan'>Trailing span</span>",
             (op) =>
             {
                 try
                 {
                     op.Run((opState) =>
                     {
                         for (int i = 0; i < 10; i++)
                         {
                             // Update status.
                             opState.Status = String.Format("<script type='text/javascript'>document.all.item('leadingSpan').innerText = '({0} of {1})';</script>", i + 1, 10);
                             LongOperation(seconds / 10);
                         }
                     });

                     op.End(HttpContext.Current.Request.UrlReferrer.ToString());
                 }
                 catch(Exception)
                 {
                     op.End(HttpContext.Current.Request.UrlReferrer.ToString()+"?Error=1");
                 }
             });
    }

    private void LongOperation(int seconds)
    {
         Thread.Sleep(seconds * 1000);
    }
  • Lokalizace a typy obsahu

    Lokalizace je komplexní téma. Něco o něm už jsem popsal dříve. Dnes se ale podíváme na jednu oblast. Tou je práce s typy obsahu v kódu.

    Na rozdíl od sloupců nemají typy obsahu ID, internal name – interní název typicky používaný v kódu a display name – to vidí koncový uživatel a lokalizuje se. Mají jen ID a name. Jméno se zobrazuje uživateli a současně může sloužit i jako interní identifikátor a protože ho vidí uživatel, lokalizuje se.

    Pokud chcete pracovat s typem obsahu programově, můžete se na něj odkazovat dvěma způsoby:

    1. Pomocí ID
    2. Pomocí jména

    Při použití je ID problém v tom, že content type id je lidsky obtížně čitelný (i pro programátora) a navíc se mění seznam od seznamu. To je proto, že SharePoint při použití typu obsahu webu v seznamu vždy vytvoří jeho potomka a ten má jiné ID než jeho předek (ID předka je prodlouženo). Naproti tomu jméno typu obsahu je stále stejné ať jde o typ obsahu webu, nebo jeho použití na úrovni seznamu. Má to ale jinou potíž. Díky tomu, že jméno typu obsahu je obvykle lokalizováno, mění se podle jazykového prostředí aktuálního uživatele.

    Takže konstrukce item["ContentType"] = "jmeno typu obsahu" nebo list.ContentTypes["jmeno typu obsahu"] si říkají o problém, protože nevíte v jakém jazykovém nastavení (řídí se jazykem uživatele) se bude kód spouštět. Když daný kód poběží v kontextu česky mluvícího uživatele, ale jméno typu obsahu v kódu bude anglickou variantou, první příklad povede k tomu, že položka dostane výchozí typ obsahu seznamu a druhý vrátí null.

    Dá se použít item["ContentType"] = SPUtility.GetLocalizedString("$Resources:resourceKey","Resourcefile",(uint)Thread.CurrentThread.CurrentUICulture.LCID). Tím zajistíte, že se použije vždy správně lokalizované jméno. Bohužel ale tento přístup nemůžete použít vždy. Pokud máte například scénář, kdy jméno typu obsahu zadává uživatel v nějaké konfiguraci, tak obvykle zadá to, co vidí v systému (tedy lokalizované jméno), ne resource key. Uživatel ho nemá jak zjistit, nehledě na to, že mnohdy ani netuší, co to je.

    Pokud tedy máte jméno typu obsahu a nevíte, v jakém je jazyce, musíte vyzkoušet jazyky podporované příslušným webem. Podpora více jazyků je totiž vlastností jednotlivých webů. Můžete měnit vlastnost Thread.CurrentThread.CurrentUICulture a zkoušet, až vám list.ContentTypes["jmeno typu obsahu"] vrátí něco jiného než null. To má ale tu nevýhodu, že nesmíte zapomenout vrátit nastavení CurrentUICulture zpět na původní hodnotu. Jinak se vyrenderuje i zbytek stránky v nově nastaveném jazyce. Alternativou může být následující kus kódu:

    string searchCTName = "Content Type A"; //načteno z konfigurace
    foreach (CultureInfo cultureInfo in web.SupportedUICultures)
    {
          foreach (SPContentType contentType in list.ContentTypes)
          {
              if (string.Compare(searchCTName, contentType.NameResource.GetValueForUICulture(cultureInfo), true) == 0)
              {
                  // to je ten, co hledám
                  break;
              }
          }
    }

    Závěr

    Je doporučeno pracovat s ID typu obsahu. Když to z nějakého důvodu nejde a musíte použít jméno, nic není ztraceno, jen se to při podpoře lokalizace komplikuje.

  • Volání webové služby s klientským certifikátem

    Zabezpečení je tématem dneška a SSL je běžným zabezpečením výměny dat mezi klientem a serverem. Minimálně je k němu nutný serverový certifikát. Čím dál častěji se ale objevuje i používání klientských certifikátů, zejména pro autentizaci.

    O úskalí ověření serverového certifikátu při volání webových služeb přes SSL v SharePointu jsem psal dříve. Nyní se podíváme na komplikaci při použití klientského certifikátu. Ten je uložen nejčastěji v úložišti certifikátů, obvykle v profilu počítače. Odtud ho může používat více aplikací. Alternativou je jeho umístění do úložiště účtu, pod kterým běží proces klienta. Důležité je, že při použití klientského certifikátu musíte mít i odpovídající privátní klíč. Tím prokazujete, že máte kompletní klíč. Stejně tak je důležité, že standardně nemá pool IIS, přístup k privátním klíčům v úložišti certifikátů. To je z důvodů ochrany, aby při hacku IISka nemohlo dojít ke kompromitaci privátních klíčů. V našem scénáři ale přístup potřebujeme udělit. Chyba, se kterou se tato situace projevuje, je:
    System.Net.WebException. The Underlying Connection Was Closed. Could Not Establish Trust Relationship with Remote Server.

    Nebudu zde popisovat, jak nainstalujete certifikát s klíčem (typicky ve formě PFX souboru) do správného úložiště. Předpokládejme, že je máme správně nainstalované v úložišti lokálního počítače. Další důležitou podmínkou je, že musíte mít nainstalované i všechny certifikáty CA až ke kořenovému certifikátu (certifikát CA, vystavený jí samotnou, tzv. self-signed certifikát). Ten musí být nainstalovaný mezí důvěryhodnými kořenovými certifikáty.

    K nastavení práv, ale i k instalaci certifikátu a privátního klíče, slouží nástroj winhttpcertcfg.exe.

    Příklady volání:

    winhttpcertcfg -i PFXFile -c LOCAL_MACHINE\My -a IWAM_TESTMACHINE -p PFXPheslo – instalace certifikátu z PFX souboru

    WinHttpCertCfg.exe -g -c LOCAL_MACHINE\MY -s "IssuedToName" -a "uživatelské jméno poolu" – povolení použití privátního klíče certifikátu pro účet.

  • MVP certifikace

    S radostí vám chci napsat, že se mi podařilo dosáhnout MVP certifikace pro oblast SharePointu. Udělám, co budu moci, abych ji udržel. Tedy mimo jiné pokračovat v psaní tohoto blogu. Smile

    Děkuji vám za přízeň.

  • Problematická trojka – workflow, úkol a correlation token

    Před časem jsem psal článek o detailech implementace SharePoint workflow. Dnes se podíváme na praktické důsledky. Jde zejména o práci s úkoly a položkami, nad nimiž běží workflow, a problémy s tím spojenými.

    Zmiňoval jsem se o tom, že pro “publikaci” událostí o změnách nad položkami se používají event receivery. Ty jsou zodpovědné za automatické spouštění workflow a předávání informací o změnách na úkolech a položkách do spuštěných workflow. To ale není vše, co se na pozadí děje. A nutno také říct, že o mnohém z dále uvedeného MSDN mlží, nebo přímo neříká pravdu.

    Práce s úkoly

    Proto, aby si SharePoint udržel přehled o tom, že změna na úkolu byla zpracována workflow, mají workflow úkoly (typy obsahu odvozené od Workflow Task) definovaný sloupec WorkflowVersion. Ten nevyjadřuje verzi workflow, které úkol vygenerovalo, jak se můžete občas na internetu dočíst. Sloupec funguje jako zámek. Jeho výchozí hodnota je 1. Update metody (včetně SystemUpdate) nejprve kontrolují:

    1. jestli daný úkol je součástí běžícího workflow.
    2. jestli není vypnutý EventFiring. Když je vypnutý, že nehrozí, že by na změnu mohlo reagovat workflow (posouvané pomocí event receiverů).

    V případě, že oba testy jsou pozitivní, kontroluje se hodnot sloupce WorkflowVersion. Pokud je vyšší než 1, vyhodí známou vyjímku “This task is currently locked by a running workflow and cannot be edited”. V opačném případě se provede aktualizace úkolu. Na aktualizaci reaguje systémový event receiver a nastaví hodnotu sloupce na 512. Obsluha události ve workflow, tedy  aktivita onWorkflowTaskChanged, nastaví hodnotu sloupce WorkflowVersion opět na 1, tedy uvolní zámek pro další změny úkolu. V ideálním případě se informace o změně úkolu dostane do workflow téměř ihned. Může se ale stát (některé situaci si popíšeme dále), že informace do workflow je doručena jobem. Jeho spouštění je standardně naplánováno v 5 minutových intervalech. A během té doby je úkol uzamčen pro veškeré úpravy. Vhodnější je při úpravách workflow úkolů volat SPWorkflowTask.AlterTask(). Ta sice vnitřně také volá SPListItem.Update(), který může vyvolat vyjímku. Ale na svém začátku volá SPWorkflowTask.SetWorkflowData(), čímž posílá informace o změně přímo do workflow subsystému. Navíc v případě synchronního volání (parametr metody) počká před updatem až 30s na případné uvolnění zámku. Metodu AlterTask volá i editform úkolů.

    Podle MSDN by se měly event receivery pro sběr událostí o úkolech a položkách registrovat až v okamžiku, kdy se začne na tyto události čekat (workflow ve svém běhu dojde do aktivit onWorkflowTaskChanged, onWorkflowItemChanged, …). Naopak by se receivery měly deregistrovat po jejich dokončení, tedy obsluze odpovídajících událostí.

    Bohužel to celé nefunguje úplně dobře. Například když workflow vytvoří úkol a skončí (nebude čekat na změnu), vznikne nepříjemná situace. Úkol můžete editovat. Na tuto změnu zareaguje event receiver a nastaví hodnotu workflowversion na 512. Další pokusy o změnu už skončí neúspěchem. Zafunguje totiž kontrola v SPListItem.Update(). Problém je v tom, že chybí onWorkflowTaskChanged aktivita, která by hodnotu vrátila na 1.

    Correlation tokeny

    Correlation tokeny vytváří vazbu mezi aktivitami, které pracují s úkoly případně s položkou, nad níž workflow běží. Díky tomu může být ve workflow několik aktivit, které vytváří úkoly, mění je, čekají na jejich změnu a to celé souběžně a propleteně. Proto může workflow obsahovat více CreateTask aktivit a po nich několik onWorkflowTaskChanged, které budou reagovat na změnu “toho svého” úkolu. Workflow runtime je používá k určení místa, kam má v běžícím workflow doručit informaci o změně úkolu, nebo položky.

    Důležitou vlastností correlation tokenu je parent activity. Ta definuje rozsah platnosti tokenu, resp. toho, kde se pracuje s úkoly s ním svázanými. Pro práci s položkou (aktivity UpdateItem, onWorkflowItemChanged, …) se používá přímo token workflow, protože jeho parent aktivitou je workflow samotné. Pro práci s úkoly (CreateTask, onWorkflowTaskChanged, …) se definují vlastní tokeny s parent aktivitou zvolenou tak, aby objímala všechny operace, které se s jedním úkolem dějí. Někdy se vkládá do workflow uměle sequence aktivita právě pro definici rozsahu platnosti tokenu.

    A opět musím napsat, že to nefunguje úplně dobře. Correlation tokeny mohou způsobit dead-locky workflow, které workflow zcela zablokují. Nebo se může workflow chovat velmi nečekaně.

    Kombinace práce s úkolem a položkou v 1 workflow

    Člověk by řekl, že na workflow, které čeká na změnu položky, nad níž běží, vytváří úkoly a čeká na jejich dokončení, nemůže být nic dramatického. Zejména proto, že jde o běžný scénář. Pravda je to jen částečně. Změna položky a změna úkolu mohou vést k zámku workflow. To se programově pozná tak, že je nastavena vlastnost SPWorkflow.IsLocked na true. V UI to poznáte tak, že v detailu workflow uvidíte následující hlášku: Z důvodu velkého zatížení byla nejnovější operace pracovního postupu zařazena do fronty. K pokusu o její obnovení dojde později. Tím workflow runtime říká, že má několik konfliktních změn, které není schopen vyřídit live a proto je zařadil do fronty a vyřeší je job posouvající workflow kupředu. Z uživatelského pohledu to znamená, že workflow se zpracuje provedené změny se zpožděním odvislým od toho, jak je naplánovaná perioda toho jobu (standardně 5 min).

    Pojďme si na zjednodušených příkladech ukázat některé problémové situace, a jak se jim případně vyhnout.

    Příklad 1

    Začneme jednoduchým příkladem. Nejprve se čeká na změnu položky. Pak se vytvoří úkol a čeká se na jeho změnu. Tím workflow končí. Prosté a funkční.

    Příklad 2

    Nejprve se vytvoří úkol (CreateTask1), pak se čeká na jeho změnu (onTaskChanged1) a následně na změnu položky, nad níž úkol běží (onWorkflowItemChanged1). Úkolové aktivity mají vlastní token, onWorkflowItemChanged1 používá workflowToken. Jednoduché workflow, na kterém není nic složitého. Ale pozor! Workflow se totiž dokončí i v následujícím scénáři: Nejprve změním položku. Protože se hned na začátku registruje event receiver pro registraci změn položky a současně onWorkflowItemChanged1 používá workflowToken, který je platný od rozběhnutí workflow, tak se informace o změně položky uschová. Pak se vytvoří úkol, počká se na jeho změnu a ihned se z šuplíku vytáhne událost změny položky workflow, obslouží se a workflow skončí.

    Příklad 3

    Využití aktivity InitializeWorkflow a použití stejného correlation tokenu pro ni a aktivitu onWorkflowItemChanged1. Toto workflow už se opět chová očekávaně. Tedy změna položky provedená ještě v době před aktivitou InitializeWorkflow se nebere v úvahu.

    Příklad 4

    Komplikovanější scénář, ale stejný výsledek. Pokud provedete změnu záznamu ještě během úvodního čekání před vytvořením úkolu, listen aktivita proběhne větví s onWorkflowItemChanged1 aktivitou. Takže nestihnete reagovat na změnu úkolu.

    Příklad 5

    Řešení předchozího příkladu. Před listen aktivitu umístíme InitializeWorkflow a použijeme nový (jiný než WorkflowToken) token. Stejný pak použijeme v onWorkflowItemChanged1 aktivitě.

    Příklad 6

    Poslední příklad. Nejsložitější, ale nejreálnější. Čekání na změny je obalenou while aktivitou, která zajistí to, že dojde ke změně (úkolu, nebo položky), na kterou čekáme. Např. to, že úkol je dokončen, nebo že je nastavena požadovaná hodnota v nějakém sloupci. Pokud je registrována jiná změna, smyčka se vrátí zpět a čeká se znovu.

    V tomto případě jsem ještě přidal updatetask1 aktivitu do větve reagující na změnu položky. Po změně položky se tedy provede okamžitě změna úkolu a jde se na čekání na změnu. A dojde k zamknutí workflow. Tzn. další změny řeší job se zpožděním. Ale ať už provedete dále změnu úkolu z UI, nebo změnu položky, průběh workflow bude stejný. Poté, co se spustí workflow job, zpracuje se událost o změně úkolu (tu, kterou provedlo workflow samotné).

    Troubleshooting

    Chyby ve Workflow subsystému se logují do ULS logu v kategorii Workflow Infrastructure.

    Pokud ani to nestačí a potřebujete se podívat problému opravdu na kost. Můžete zapnout logování na úrovni Windows Workflow Runtime, nad kterým jsou SharePoint worklfow postavena. To uděláte úpravou konfigurace. Protože workflow je hostováno do první dehydratace v procesu W3WP.exe a po rehydrataci v procesu OWSTIMER.exe, musíte konfiguraci upravit, jak ve web.configu příslušné aplikace, tak v souboru owstimer.exe.config. Např. následující konfigurace bude do souboru WFtrace.log ukládat logování na úrovni Windows Workflow Foundation.

    <?xml version="1.0" encoding="utf-8"?>
    <configuration>
      <system.diagnostics>
        <sources>
          <source name="System.Workflow.Runtime" >
            <listeners>
              <add name = "System.Workflow"/>
            </listeners>
          </source>
          <source name="System.Workflow.Runtime.Hosting">
            <listeners>
              <add name="System.Workflow"/>
            </listeners>
          </source>
          <source name="System.Workflow.Activities">
            <listeners>
              <add name="System.Workflow"/>
            </listeners>
          </source>
        </sources>
        <sharedListeners>
          <add name="System.Workflow"
               type="System.Diagnostics.TextWriterTraceListener"
               initializeData="c:\WFTrace.log"
               traceOutputOptions="DateTime,ProcessId"/>
        </sharedListeners>
        <switches>
          <add name="System.Workflow.LogToTraceListeners" value="1"/>
          <add name="System.Workflow.Runtime" value="All" />
          <add name="System.Workflow.Runtime.Hosting" value="All" />
          <add name="System.Workflow.Runtime.Tracking" value="All" />
          <add name="System.Workflow.Activities" value="All" />
          <add name="System.Workflow.Activities.Rules" value="All" />
        </switches>
      </system.diagnostics>
    </configuration>

    Závěr

    Workflow ve SharePointu jsou užitečným nástrojem. Je potřeba jim ale věnovat pozornost, protože se může na první pohled chovat “podivně”. Z pohledu kolize změn a zamykání workflow je problematický souběh změn úkolu workflow a položky. Doporučuju předřazovat aktivitu InitializeWokflow všem onWorkflowItemChanged aktivitám, aby se eliminovaly některé z problematických situací. Díky tomu se z uživatelského pohledu budou posouvat workflow kupředu ihned a ne se zpožděním. Stejně tak pro úpravy úkolů doporučuji používat metodu SPWorkflowTask.AlterTask().

  • Centra schůzek a malý trik než úplně vyhynou

    Microsoft centra schůzek postupně odsouval do pozadí, až je nejspíš zařízne úplně. Pracuje na tom už od SharePointu 2010 a zejména Outlooku 2010. V Outlooku 2007 byla ikona pro připojení schůzky k centru schůzek normálně v menu. V Outlooku 2010 tam už nebyla, ale bylo možné ji tam přidat. V Outlooku 2013 už není vůbec. Existují sice komponenty 3. stran, které ji umí nahradit, ale směřování Microsoftu je zřejmé.

    Podobně je to v SharePointu samotném. Do SharePointu 2010 můžete centra normálně vytvářet. Obsahuje hned několik šablon těchto webů. V SharePointu 2013 ty šablony jsou ještě také a použitelné, ale nejsou viditelné a slouží zejména k usnadnění migrace SharePointu 2010 na novou verzi. Funkcionalita center schůzek je označená jako obsolete. Jak to dopadne v další verzi SharePointu je asi jasné, že.

    Microsoftí vysvětlení je založeno na tom, že centra schůzek jsou dnes překonaná. Doporučuje pro podporu spolupráce týmu použít normální týmový web v kombinaci se sdíleným OneNotem a Lyncem. Ideálně v prostředí Office365.

    Pro ty, kterým ale centra schůzek vyhovují, existují klony microsoftích šablon, např. na Codeplexu nebo postupy, jak si vyrobit vlastní šablony webů podobné těm standardním.

    Teď slibovaný trik. Pro mnoho uživatelů je problém připojit organizovanou schůzku k centru schůzek. A to, ať už centrum existuje, nebo si uživatel chce vytvořit nové. Problém je zejména v tom, že musí zadat URL existujícího centra, nebo webu, pod nímž se má centrum vytvořit. Problém je v tom, že obvykle nezná URL centra schůzek. Zejména, pokud k němu zatím žádnou schůzku nepřipojoval. V případě vytváření nového centra je to podobné s webem, kam centrum schůzek umístit. Situaci mu můžete zjednodušit tím, že připravíte centra pro očekávané schůzky (např. víte, že se budou ve firmě pořádat schůzky marketingového týmu). To je ale jen půlka problému. Ta další je v tom, jak uživatelům zjednodušit připojení 1. plánované schůzky v Outlooku k tomuto centru. Outlook si pamatuje, když už to uživatel jednou udělá a nabízí mu seznam. Ten je uložen v registrech, a proto s ním můžete manipulovat. Například pomocí připravených reg souborů, které distribuujete příslušným uživatelům. Ještě lepší je to pomocí doménových politik. Ty můžete cílit na skupiny uživatelů. V našem případě to budou členové marketingového týmu, zejména ti, kteří plánují schůzky. Stejně tak můžete uživateli tento seznam pročistit od už nepoužívaných center.

    Jsou v registrech na cestě HKEY_CURRENT_USER\Software\Microsoft\Office\14.0\Meetings\Profile klíč MRUInternal, typ REG_SZ a hodnota http://sp/schuzky|Schůzky|||||http://sp/schuzky/marketing|marketing||||| pro Outlook 2010. V Outlooku 2007 je tam 12.0 Nejprve je URL, pak oddělovač v podobě | , pak jméno centra a nakonec |||||.

  • Hostování workflow v SharePointu 2010 a SharePointu 2013 v modelu 2010

    V tomto článku bych se chtěl podívat blíže na to, jak jsou workflow hostována v SharePointu. Dlouho mi zůstávaly některé věci záhadou. Navíc se o nich různě píše různých místech na internetu a MSDN je na slovo skoupá. Proto jsem strávil několik večerů s iLspy v ruce a výsledky se pokusím shrnout do několika článků. Snad vám to pomůže vysvětlit některé věci a chování, které jsou jinak obtížně uchopitelné.

    Architektura

    SharePoint 2010 hostuje workflow pomocí implementace Windows Workflow Foundation z .NET frameworku 3.5. Tady si Microsoft snědl to, co si sám uvařil. A protože jsem Workflow Runtime implementoval i samostatně, tak si troufnu říct, že docela dobře.

    SharePoint 2013 uvádí jako jednu z novinek podporu Workflow Runtime z .NET frameworku 4.5. Je to řešeno externě pomocí samostatného Workflow Manageru. Bohužel je dostupný pouze v SharePoint Serveru 2013. V SharePoint Foundation 2013 máte smůlu. Nicméně SharePoint 2013 obsahuje i model provozování workflow z SharePointu 2010. Je tam z kompatibilních důvodů, ale v SharePoint Foundation 2013 nemáte ani jinou možnost.

    Tento článek je proto platný i pro SharePoint 2013. Pro SharePoint Foundation 2013 zcela a pro SharePoint Server 2013 pro workflow provozovaná v modelu 2010.

    Z obrázku je vidět, že SharePoint funguje z pohledu Windows Workflow Runtime dvěmi způsoby:

    • Jednak implementuje služby jako PersistenceService, která se stará o dehydrataci (tedy persistenci workflow po dobu, kdy aktivně neběží) a o rehydrataci, tedy o nahrání workflow z úložiště do paměti.
    • A také jako externí služba. Externí služby obecně slouží pro volání externího kódu, který není přímo součástí workflow, ale také pro registraci událostí, které až nastanou, tak se ve workflow obslouží.

    Pro persistenci instance běžícího workflow do databáze (tzv. dehydrataci) se používá XML serializace. Rehydratace odpovídá pro změnu XML deserializaci. Při deserializaci instance workflow z databáze do paměti je nezbytné, aby persistovaný tvar odpovídal tomu, co má SharePoint k dispozici. Jinými slovy XML uložené v databázi musí odpovídat třídě, která reprezentuje workflow v DLL. Může se vám stát, že provedete změny kódu workflow, které povedou k tomu, že SharePoint nedokáže pomocí definice třídy v DLL a XML v databázi znovuvytvořit objekt workflow. V takovém případě workflow zůstane ve stavu Probíhá a už se nikdy nepohne z místa. Situace je o to horší, že se o tom nedozvíte a SharePoint se bude v pravidelných intervalech, bez naděje na úspěch, pokoušet workflow oživovat.

    SharePoint workflow mohou pracovat s daty (vytvářet, měnit a mazat položky a úkoly) v SharePointu a reagovat na události (změna položky, změna úkolu), které se v něm nastanou. Slouží k tomu aktivity:

    • CreateTask, CreateTaskWithContentType, UpdateTask, DeleteTask, UpdateItem, … - pro manipulaci s daty workflow
    • OnWorkflowItemChanged, OnTaskCreated, OnTaskChanged, … - pro obsluhu událostí v SharePointu

    Zmíněné aktivity využívají služeb SPWinOeTaskService a SPWinOeWSSService obě jako potomci třídy ExternalDataExchangeService. Obě komunikují s SPWinOeHostService což je SharePointí interface pro komunikaci s Workflow Runtime.

    Event receivery

    Jako zdroje událostí používá SharePoint event receivery. Stejně tak je využívá pro automatické spouštění workflow při založení nebo změně položky. Když se seznamem asociujete workflow, SharePoint na tomto seznamu registruje SPWorkflowAutostartEventReceiver, který obsluhuje události ItemAdded a ItemUpdated a v nich podle definice prostřednictvím objektu SPWorkflowManager spouští instance workflow. K zachycení událostí o změně úkolů nebo položky, nad níž běží, registruje SharePoint při spuštění workflow SPWinOEItemEventReceiver.

    Proto, aby se nestalo, že při výpadku systému dojde ke ztrátě informací o událostech v SharePointu, jsou informace uloženy v tabulce SheduledWorkitems v obsahové databázi. Po doručení je smažou.

    Joby

    Může se stát, že informaci o události není možné doručit instanci workflow “online”. Pro tyto situace má SharePoint naplánovaný job (SPWorkflowJobDefinition), který frontu událostí zpracovává asynchronně. Tento job je standardně naplánovaný každých 5 minut. Proto může workflow za určitých okolností reagovat na události se zpožděním.

    Dále SharePoint používá SPWorkflowFailOverJobDefinition. Tento job se pokouší rozběhnout instance workflow, které selhaly z “vnějších” příčin. Tedy např. neběžící SQL, síťové problémy a podobně.

    Posledním jobem souvisejícím s workflow je poněkud kontroverzní job SPWorkflowAutoCleanJobDefinition. Cílem tohoto jobu je mazat informace workflow, které byly ukončeny (doběhly, nebo spadly), a uvolnit prostor v databázi. Standardně se tak děje po 60 dnech od ukončení. Nepříjemné na tom je, že jsou smazány informace o běhu workflow, ale i vytvořené úkoly. Pokud chcete po 60 dnech něco z toho dohledat, máte smůlu. Perličkou je, že historie běhu workflow v databázi zůstane, ale už se k ní jinak než v databázi nedostanete. A hromadí se v tabulce alluserdata s ostatními užitečnými položkami. Záznamy historie workflow jsou totiž také položky v seznamu. Sice v trochu speciálním seznamu, ale seznamu.

     

    Zajímavostí pro mě bylo zjištění, že úkoly vytvořené pomocí CreateTaskActivity se fakticky vytvoří až v okamžiku dehydratace workflow.

    Workflow může během svého života vytvořit, měnit a případně reagovat na změnu mnoha úkolů. K tomu, aby si SharePoint udržel vazbu mezi aktivitami, které pracují se stejným úkolem, používá tzv. correlation tokeny. S nimi je spojena celá řada potíží a na ně se, stejně jako na další věci, které se mohou pokazit, podíváme v dalším článku.

Více článků Další stránka »

Syndication

News

  • Web Developer
  • Enterprise Application Developer

  • Microsoft Office SharePoint Server 2007, Application Development
  • Microsoft Windows SharePoint Services 3.0, Application Development
  • Microsoft Office SharePoint Server 2007, Configuration
  • Microsoft Windows SharePoint Services 3.0, Configuration
  • .Net Framework 2.0, Distributed Applications
  • .Net Framework 2.0, Web Applications
  • .Net Framework 2.0, Windows Applications
Powered by Community Server (Personal Edition), by Telligent Systems