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

Mazinův blog o SharePointu

  • SharePoint a antiviry

    Antiviry jsou všude kolem nás. V desktopu, notebooku, tabletu, Exchange, fileserveru, … Střeží nás proti nebezpečí virů a jiného neřádstva obecně označovaného jako malware. I do SharePointu může být (a v SharePointu Online je) antivir integrován. Mnoho výrobců antivirových řešení na SharePoint pamatuje a prodává speciální verze právě pro něj. Typicky používají stejné jádro jako v jiných produktech, ale napojují se na SharePointí API pro antivirovou kontrolu souborů.

    Jeden takový jsem si ve své SP laboratoři zprovoznil a kouknul jsem se na zoubek tomu, jak to celé funguje.

    Nejprve trocha teorie

    Pro integraci antivirů Microsoft poskytuje rozhraní Virus Scan Engine API zkráceně VSE API, konkrétně ve verzi 1.4. Jde o COM rozhraní, které je založeno na Exchange Server VS API 2.0. Oproti němu zohledňuje odlišné fungování mailového severu a SharePointu. Toto rozhraní je podporováno v SharePointu 2010, 2013 i SharePointu Online. SharePoint sám o sobě nepodporuje scanování  na pozadí (background scanning) a tzv. naplánované scanování (scheduled scanning).

    Logika fungování antiviru podle VSA API:

    1. Antivir musí podporovat 2 módu scanování: při uploadu a při downloadu (otevření) souboru.
    2. Nejprve získá stavovou informaci z SP databáze o tom, jestli už byl soubor otestován (sloupec VirusStatus v tabulce AllDocs).
    3. Na základě toho provede případně otestování souboru a jeho metadat.
    4. Podle výsledků testování zobrazí UI (webovou stránku nebo dialogové okno), nebo dokončí požadovanou operaci (upload/download/open).
    5. Do databáze uloží příznak, že soubor byl otestován a s jakým výsledkem (sloupce VirusStatus a VirusInfoEx v tabulce AllDocs).

     

    Instalace

    Nyní přistupme k praxi. Instalace je závislá na konkrétním antiviru. V mém případě jsem prostě provedl instalaci typu další, další, další a vyplnil jsem licenční klíč.

     

    Konfigurace v SP

    Ta je celkem jednoduchá. Slouží k ní stránka v centrální administraci. Můžete nastavit, jestli má AV kontrolu souborů provádět při uploadu souborů, stahování, jestli dovolíte uživateli stáhnout soubor i v případě, že je zavirovaný a případně, jestli se má antivir pokoušet virus odstranit. Dalšími parametry jsou timeout pro testování souborů a maximální počet vláken testovacího enginu.

     

    Testy

    Pro potřeby testování pozornosti AV a chování SharePointu jsem si pořídil soubor s virem. Tedy ne skutečným, ale testovacím. Každý antivir by měl reagovat na soubor s obsahem X5O!P%@AP[4\PZX54(P^)7CC)7}$EICAR-STANDARD-ANTIVIRUS-TEST-FILE!$H+H*. Je to tzv. testovací soubor Eicar, který slouží právě k testování chování antivirů, protože to nic nedělá, ale antiviry by na to měly reagovat stejně, jako by to virus byl. Můj antivirus na něj spolehlivě reagoval. Stejně jako ten na stroji, ze kterého jsem testy prováděl. Na něm jsem musel antivirus dočasně vypnout, jinak mi nedovolil ani tento soubor vytvořit. Testy jsem prováděl i se zazipovaným souborem a výsledky byly stejné.

    Náhrání souboru pomocí UI

     

    Náhrání souboru pomocí Drag & Drop

     

    Náhrání souboru pomocí Windows Exploreru

    SharePoint Online

    Antivir v SharePointu Online je nakonfigurován pouze v režimu Scan document on download, protože při stejných nahrávání “zavirovaného” souboru ani necekl, zato jeho stažení bránil viz. následující screenshoty:

    Stažení pomocí průzkumníka

     

     

    Pokus o stažení pomocí kontextového menu souboru a příkazu Stáhnout kopii

     

    Přímý klik na jméno souboru

     

    Stažení infikované přílohy

    V Internet Exploreru (aktualizovaný IE 11) končilo spadnutím prohlížeče. V Chromu stejnou stránkou jako předchozí test.

     

    OneDrive for Business synchronizace

    Se chová poněkud schizofrenně.

    Při synchronizaci osobního prostoru (1 TB velká knihovna dokumentů v My Sites) synchronizuje zavirovaný soubor na server i z něho bez nejmenších zábran. To je změna oproti dosud pozorovanému chování i dalším testům. Pokusy pracovat se zavirovaným souborem pomocí UI, drag&drop a průzkumníka dopadají stejně jako v předešlých testech, tedy chybou.

    Při synchronizaci knihovny dokumentů z SharePointu Online se chová se stejným způsobem jako v předchozích situacích. Tzn. umožní nahrát zavirovaný soubor do SharePointu, ale synchronizaci zavirovaného souboru z SharePointu Online neprojde:

    Pokusy pracovat se zavirovaným souborem pomocí UI, drag&drop a průzkumníka dopadají stejně jako dosud, tedy chybou.

     

    Antiviry vně SharePointu

    Poslední dobou je běžná instalace speciálních verzí antivirů na servery SharePointí servery nevyjímaje. Cílem je chránit servery před jejich napadením ať už prostřednictvím neopatrného admina, který na server nainstaluje něco závadného, nebo před napadením virem, který zneužívá nějaké zranitelnosti něčeho na serveru nainstalovaného (např. OS, SharePointu, SQL, …). Tento bohulibý úmysl ale může mít fatální vliv na výkon takového serveru a SharePointu zvláště. Proto existuje doporučení MS, jak takový antivir nakonfigurovat, aby SharePoint, co nejméně omezoval a brzdil. Jde především o to, které adresáře vyčlenit z testování. Jsou to hlavně provozní adresáře, do kterých si SharePoint ukládá dočasné soubory, adresář s logy a podobně. Detailní výčet obsahuje tento dokument.

  • Vypočítaná pole a InfoPath

    Nedávno jsem se setkal s chybou při editaci listových formulářů pomocí InfoPathu. Projevovala se tak, že uložení změn formuláře končilo nicneříkající chybou “The SOAP message cannot be parsed”. Zkrátka fantazie ze světa troubleshootingu. Týkalo se to jen některých seznamů. Postupně jsem zjistil, že se problém projevuje u seznamů s velkým počtem položek.

    Problém byl nakonec v tom, že když publikujete InfoPath formulář pro seznam s vypočítanými sloupci, dochází k přepočítání hodnot těchto sloupců. A to i v případě, že formulář sám s žádným takovým sloupcem nepracuje. A při tomto přepočítávání, pokud seznam obsahuje dost položek a dost vypočítaných sloupců, může dojít k timeoutu. Ten se pak projeví onou “výstižnou” chybovou hláškou.

    Zmiňovaný troubleshooting mě přivedl k obecnější otázce: Jaké máme možnosti, když potřebujeme zobrazit v seznamovém formuláři další informace na základě uživatelem vyplněných údajů?

    V podstatě připadají v úvahu následující možnosti (seřazeno podle náročnosti provedení - vím, že je to subjektivní veličina a můžete mít jiné pořadí):

    1. Vypočítané sloupce
    2. Úprava formuláře pomocí InfoPathu:
      1. calculated values
      2. textové pole a defaultní hodnota
      3. .NET kód ve formuláři
    3. JS ve formuláři
    4. Workflow spouštěné po vložení nebo aktualizaci položky
    5. Event receivery
    6. Job

    Rozeberu si jednotlivé varianty a budu je srovnávat podle následujících kritérií:

    1. Potřebné nástroje a znalosti pro implementaci
    2. Možnosti a omezení výpočtů
    3. Live zobrazení vs. dostupnost až po uložení položky
    4. Persistence vypočítaných hodnot – výsledek je “jen” zobrazen, nebo se dá využít i v jiných procesech (např. ve workflow, jobech, …) aniž by se musel opětovně počítat.
    5. Použitelnost v on-premise vs SharePointu Online
    Vypočítané sloupce

    Nejjednodušší varianta. Vytvoří se nový sloupec odpovídajícího typu a zadá se výpočetní výraz. Jeho syntaxe a možnosti jsou podobné výpočtům v Excelu, což může být výhoda. Výpočet může používat ostatní sloupce dané položky. Výsledek je dostupný okamžitě při uložení položky. Tato varianta má nejvíce omezené možnosti výpočtů (kromě jiného se nedají použít např. lookup sloupce a “konstanty” jako aktuální datum, nebo aktuální uživatel). Výsledek je uložen v datech položky jako hodnota sloupce.

    Funguje i v SharePointu Online a je jedno jakým způsobem položku vytvoříme nebo změníme (UI, PowerShell, programově, …).

    Úprava formuláře pomocí InfoPathu

    Zde můžeme použít 3 varianty:

      1. calculated values – speciální ovládací prvek, u kterého se nastaví výpočetní výraz. Aktualizuje se okamžitě po změně polí použitých ve výpočtu už během vyplňování hodnot. Výsledek je pouze zobrazen, není součástí výsledných dat (resp. není v SP sloupcích).
      2. textové pole a defaultní hodnota – pokud je textové pole napojeno na data, výsledek je součástí SP dat. Pokud je záznam založen/změněn jiným způsobem než pomocí upraveného formuláře, výpočet se neprovede a ve výsledkovém poli bude prázdná/původní hodnota.
      3. .NET kód ve formuláři – i zde platí, že pokud je záznam založen/změněn jiným způsobem, výpočet se neprovede a ve výsledkovém poli bude prázdná/původní hodnota.

    Výpočetní možnosti prvních 2 variant jsou dány tím, co nám umožní InfoPath. Standardně jsou k dispozici data z aktuální položky, ale pomocí dalšího datového zdroje je možné pracovat i s dodatečnými záznamy a informacemi. První dvě varianty jsou použitelné jak v on-premise prostředí, tak v SharePointu Online. 3. varianta je možná pouze v on-premise prostředí a z pohledu možností je limitem jen .NET a datové zdroje ve formuláři.

    Problémem všech tří variant je v reakci na uživatelské změny sloupců, ať už přidání, odebrání, nebo změna nastavení sloupců se v upraveném formuláři samy neprojeví, je nutné je do něj zapracovat ručně.

    JS ve formuláři

    Je jedno, jakým způsobem JavaScript do formuláře dostaneme (CustomActions, content editor webpart, …). JS může číst hodnoty již vyplněných polí a případně reagovat na jejich změny (ne vždy je to jednoduché, zejména u polí typu people-picker, lookup a podobně). Může také volat SharePoint (REST API, JavaScript CSOM) a číst z něj další data případně volat externí webové službu a dočítat další informace. Výsledek výpočtu může ukládat do ovládacího prvku dalšího sloupce (pak se výsledek stane součástí dat), nebo ho zobrazit někde ve formuláři. Omezením této metody je, že pokud dojde k vytvoření nebo změně položky mimo upravený formulář, výpočet se neprovede.

    Workflow spouštěné po vložení nebo aktualizaci položky

    Worflow se dají definovat pomocí SharePoint Designeru, nebo tvořit ve Visual Studiu. Obě varianty jsou použitelné i v SharePointu Online za předpokladu, že si vystačíte s deklarativním způsobem tvorby (standardní aktivity bez .NET kódu) workflow. Toto řešení tedy zahrnuje jak “klikací”, tak kódovou variantu a s tím i související výpočetní možnosti. Nese s sebou ale i poměrně velkou zátěž, protože worklfow runtime není primárně cílen na rychlé operace. Díky tomu může docházet ke zpoždění, tzn. vypočítaná hodnota nemusí být dostupná ihned po uložení položky. Výsledek je uložen ve sloupci záznamu.

    Event receivery

    Jak SharePoint Online, tak SharePoint v on-premise umožnují reagovat na události vložení, případně změny položky. Díky tomu můžeme provést požadovaný výpočet a položku aktualizovat. V SharePointu Online jsou použitelné pouze remote event receivery, tzn. musíte mít vytvořenou webovou službu, která:

    1. načte data z SharePointu (nemusí se nutně omezit na aktuální položku) například pomocí Client Side Object Modelu.
    2. provede výpočet.
    3. uloží vypočítanou hodnotu do položky opět např. CSOMu.

    V obou prostředích je vypočítaná hodnota k dispozici okamžitě, nebo s určitým zpožděním po uložení záznamu (podle použitého typu použitého receiveru). Výsledek je součástí záznamu nejčastěji jako hodnota dalšího sloupce. Musí se implementovat programově. To sebou nese vyšší složitost, na druhou stranu ale široké možnosti výpočtu včetně dočítání dalších informací z jiných zdrojů a podobně.

    Job

    Pokud pro nás není důležitá aktuálnost vypočítaných údajů (tedy mít je dostupné “ihned”) a pokud například jejich výpočet je náročný, můžeme použít i job. Ten je použitelný jak v on-premise prostředí ve formě klasického SP jobu, tak v SharePointu Online. Tam ale musíme job implementovat ve vlastní infrastruktuře (může jím být i konzolová aplikace spouštěná systémovým timerem) a musí s SharePointem komunikovat vzdáleně. Vysloveně programovací záležitost.

  • SharePoint 2010 odchází do důchodu

    13. 10. 2015 SharePoint 2010 přešel z mainstream podpory do rozšířené podpory. Co to znamená? Konec některých vymožeností:

    1. Nadále budou vydávány pouze opravy řešící bezpečnostní problémy, žádné jiné.
    2. Veškeré support incidenty jsou nyní zpoplatněny.
    3. Microsoft nyní nepřijímá žádné další návrhy na změny a nové funkce.

    SharePoint 2010 se nám prostě přesouvá do další fáze svého životního cyklu. Ta bude trvat 13. 10. 2020. Z pohledu dalšího provozu máte na výběr:

    1. nechat instalaci dožít s rizikem, že se objeví chyba, která mě bude bolet, ale kterou už nikdo nebude řešit. Toto se netýká bezpečnostních chyb.
    2. upgrade na SharePoint 2013. To lze udělat pouze pomocí detach-attach scénáře. Tedy instalací nového serveru s SharePointem 2013 a připojením kopie databáze z SP 2010.
    3. upgrade na SharePoint 2016. Aktuálně je ve verzi IT preview. V tomto případě musíte vyčkat na SharePoint 2016, který je v RTM ohlášen na Q2 2016. Reálně to čekání bude trvat déle, než si nová verze tzv. “sedne”. Další otázkou je, jestli bude možný přímý upgrade, nebo bude nutný meziupgrade na SharePoint 2013.
    4. migrací do SharePointu Online. Z mého pohledu nejperspektivnější varianta. Hlavně proto, že v jejím případě se dalším upgradům vyhnete. Obsahuje taky nejvíce funkcí, které průběžně přibývají. Více než připravovaný SharePoint 2016. Na druhou stranu musíte vyřešit aktuální customizace. Zejména WSP balíčky. Ty prostě do SharePointu Online nedostanete. Některé se dají předělat na SharePoint apps nově přejmenované na SharePoint add-ins. S dalšími se holt budete muset rozloučit. Smutný obličej

    Zatím se nic tragického neděje. Většina chyb byla odstraněna. Nicméně je to určitě dobrý okamžik k zamyšlení se nad tím, co s vašimi stávajícími instalacemi SharePointu 2010.

  • SharePoint Designer 2013 a opakující se “Server-side activities have been updated” chyba

    S touto chybou se můžete setkat při tvorbě workflow pomocí SharePoint Designeru v SharePointu Online. Je způsobena tím, že SharePoint Designer není schopen otevřít uložené workflow. Týká se workflow 2013. Bohužel za určitých okolností se můžete dostat do situace, kdy se tato chyba opakuje, i když jste požadovaný restart SharePoint Designeru provedli.

    SharePoint Designer si z SharePointu stahuje v průběhu práce celou řadu informací, které si ukládá na disk. Pak se je snaží použít, aby další práce byla rychlejší. Včetně toho, že si je na disku nechává mezi jednotlivými spuštěními a následně jen zkontroluje, jestli v nich nedošlo ke změně. Informace si ukládá do adresářů %APPDATA%\Microsoft\Web Server Extensions\Cache a %USERPROFILE%\AppData\Local\Microsoft\WebsiteCache. Nás bude zajímat hlavně ten druhý. Obsahuje podadresáře, které odpovídají jednotlivým otevřeným tenantům. Zde je příklad:

    A ještě si ukážeme obsah adresáře 15.0.0.4455, což je evidentně verze runtime:

    Některé DLL jsou evidentně generované proxy. Datum jejich vytvoření je aktuální. Adresář 1033 obsahuje šablony do Visia, které se dá také využít pro tvorbu workflow (a které umí SharePoint Designer využít):

    Pokud je něco špatně, je obsah adresáře 15.0.0.4455 takovýto:

    Průběh zpracování workflow z SharePointu:

    1. Stáhnutí definice workflow
    2. Stáhnutí dostupných aktivit
    3. Zpracování stažených dat

    A právě bod 3 může být problém. Zobrazená chyba totiž předpokládá, že se workflow nepodařilo otevřít proto, že aktivit v něm použité neodpovídají staženým definicím aktivit v cache. V cache totiž mohou být dříve stažené aktivity. Restartem SharePoint Designeru a opětovnému připojení se ke spravovanému tenantu dojde ke znovunačtení aktivit a jejich definic. Pokud je ale problém lokální, tedy selže zpracování aktivit, ocitáme se v nekonečné smyčce.

    Zkoumáním přenosů z SharePointu a knihoven natahovaných do paměti SharePoint Designerem a srovnáním mezi fungujícím a nefungujícím SPD jsem došel k tomu, že problém je ve zpracování stažených informací. Důvod může být například v tom, že máte v systému zaregistrovaný novější modul pro zpracování definice WF (včetně dostupných aktivit), než se kterým počítá SharePoint Designer. I on totiž, stejně jako většina programů pro tvorbu workflow postavených na Windows Workflow Foundation, spoléhá na externí komponentu z Visual Studia. Visual Studio umožnuje tvořit workflow včetně vizuálního návrháře. Tuto komponentu (resp. sadu DLL) můžete použít ve vlastním projektu a udělat např. vizuálně odlišný designer. Standardní komponentu použijete na začátku pro načtení dostupných aktivit, XAML definice workflow a na konci pro vygenerování pozměněné definice workflow. Takto to dělá i SharePoint Designer.

    V mém případě SharePoint Designer přestal fungovat po instalaci Visual Studia 2015 (s Visual Studiem 2013 není problém). Nová verze Visual Studia zřejmě zaregistrovala svoje komponenty a SharePoint Designer se s tím nepopral. Nepomohla jeho reinstalace ani instalace shellu (jádra bez GUI) Visual Studia 2013. Smutný obličej Podle informací na Internetu ale není Visual Studio 2015 jediným možným zdrojem potíží tohoto typu.

    Možná řešení a workaround:

    1. Vymazání SPD cache (u mě nepomohlo):
      1. ukončete SharePoint Designer.
      2. smažte obsah adresáře %APPDATA%\Microsoft\Web Server Extensions\Cache
      3. smažte %USERPROFILE%\AppData\Local\Microsoft\WebsiteCache včetně podadresářů
    2. Překopírování obsahu ze “zdravého” systému do “nemocného”. Najděte si počítač s fungujícím SharePoint Designerem. Zkopírujte si obsah cache adresářů do počítače, kde vám SharePoint Designer nefunguje. U mě to zabralo. Toto bude fungovat jen do změny použitého runtime.
  • Zpracování chybových zpráv event receiverů při ukládání dokumentů z Office

    MS Office používá k ukládání změn v dokumentech otevřených z SharePointu protokol MS-FSSHTTP. Smyslem je neukládat dokument celý, ale pouze změny a šetřit tak čas a přenosové pásmo. Jeho detailní popis můžete najít v tomto článku.

    Event receivery umožnují reagovat na události v SharePointu včetně updatů položek v tomto případě ukládaných dokumentů. V rámci událostí ItemUpdating lze provádět nejrůznější kontroly a případně zabránit dokončení operace. Event receiver přitom může vrátit informaci o tom, co se stalo, a proč není možné operaci dokončit.

    public override void ItemUpdating(SPItemEventProperties properties){
        properties.ErrorMessage = "Error Message";
        properties.Status = SPEventReceiverStatus.CancelWithError;
    }

    To se určitě hodí, aby nebyl uživatel zmatený. Bohužel to sebou ale nese jeden problém. Jak uživateli tuto informaci zobrazit? Při aktualizaci položky nebo metadat dokumentu ve webovém UI SharePointu to není problém, uživateli se zobrazí chybové hlášení.

    Sice bych si posteskl nad tím, že zobrazené hlášení má podobu standardní SharePointí chyby, takže průměrný uživatel je natolik vyděšen, že si text ani nepřečte a volá support s tím, že “to spadlo…”. Dá se to alespoň trochu řešit přesměrováním uživatele na vlastní stránku s decentnějším podáním chybové hlášky. Horší je, pokud změnu dokumentu nebo jeho vlastností provádí uživatel v Office nástrojích. Tam nic podobného k dispozici nemáme. Office na to reaguje zobrazením informace v pruhu nad dokumentem:

    Takto se chovají Office 2010 i 2013 v kombinaci s SharePointem 2010 i 2013. Nicméně v případě SharePointu 2010 uživatel mohl jít na záložku Informace a tam mu Office zobrazil chybovou hlášku, kterou event receiver vrátil. Ne všichni uživatelé to sami našli, ale s trochou pomoci jste je tam navedli a oni si mohli přečíst, co je špatně.

    V případě SharePointu 2013 to už bohužel nefunguje. V jeho implementaci synchronizačního protokolu, o kterém jsem psal v úvodu, se z návratové hodnoty synchronizace “ztratil” atribut CoalesceErrorMessage (celý protokol je XML-based), který ji nesl. Úplně nechápu proč, ale je to tak. Jak by řekl Cimrman: “Můžeme s tím nesouhlasit, můžeme proti tomu protestovat, ale to je tak všechno, co se s tím dá dělat”. Smutný obličej

  • SharePoint 2016 IT Preview

    Včera byla uvolněna ke stažení první veřejně dostupná verze SharePointu 2016. Stáhnout se dá odsud.

    K jejímu zprovoznění budete potřebovat Windows Server 2012R2. V ostatních požadavcích se download stránka odvolává na požadavky SharePoint Serveru 2013. Tak snad to nebude takový nárůst požadovaného výkonu jako mezi SharePointem 2010 a 2013.

    Samozřejmě se jedná o rannou verzi, která se bude dále rozvíjet do betaverze (plánována na Q4 2015) až k RTM (měla by být v Q2 2016).

    Už od instalace, resp. od konfigurace prosakují nové funkce. Po zadání informací jako je SQL server a přístupový účet k němu, se zobrazí výběr jedné z rolí, kterou může SharePoint server zastávat. Kromě standardní volby Single-server farm si můžete zvolit Web End, Application, Distributed Cache, Search, Specialized Role. Ty mají usnadnit nasazení víceserverových farem kde jednotlivé servery mají své role. Volba Specialized Role je určena pro instalaci serverů do farmy dedikovaných aplikačním službám jako jsou Managed Metadata service, Excel Services a podobně.

    SharePoint 2016 je postaven na stejném jádře jako SharePoint Online. To sebou přináší některé věci, které znáte z SharePoint Online. Díky tomu je podoba nového bližší online verzi včetně např. app luncher. Podobně se přiblíží Online verzi i sdílení.

    Z SharePointu Online si také nový SharePoint přináší nový způsob aktualizací, jehož cílem je provádět aktualizace živě bez výpadku dostupnosti. Kromě toho dojde ke zmenšení aktualizačních balíčků.

    I přes určité sblížení s SharePointem Online mějte na paměti, že toto se bude týkat hlavně UI, funkčně se bude rozdíl mezi SharePoint Online a SharePoint on-premise zvětšovat.

    Pokud se chcete zapojit do hlasování o tom, která funkce by se měla v konečné podobě SharePointu objevit, můžete to udělat pomocí webu UserVoice. Dosud objevené a popsané chyby ale i rady najdete na TechNet fóru.

    Přeji hodně úspěchů při testování!

  • 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);
    }
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
Vyvojar.cz na prodej!