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

Mazinův blog o SharePointu

  • Sady dokumentů

    Sady dokumentů je jedna z možností, jak rozšířit možnosti práce s dokumenty v SharePointu. Dnes se podíváme na to, co takové sady dokumentů umí a jak se s nimi pracuje.

    Co to je?

    Po zapnutí funkce kolekce webů Sady dokumentů (není dostupná ve Foundation verzi SharePointu) se vám mezi typy obsahu objeví nový typ, právě sada dokumentů. Sady dokumentů jsou vlastně takový kříženci mezi soubory a adresáři. Můžete představit jako chytré obálky dokumentů. Mají svoji sadu vlastností/metadat, mohou mít navázaná workflow, zásady informací.

    S adresáři je pojí především to, že jsou odvozeny z typu obsahu složka. Dále pak to, že mohou obsahovat další soubory a adresáře.

    Naopak s dokumenty mají společné:

    • mají ID dokumentu – dá se tedy na ně odkazovat krátkým konstantním URL.
    • Dají se přesouvat nebo kopírovat pomocí funkce Odeslat – i když je ikona této funkce umístěná jinde než u dokumentů.

    Mají ale i vlastní speciální schopnosti:

    • určit, které typy dokumentů mohou obsahovat.
    • propojit jejich vlastnosti s vlastnostmi dokumentů v nich – tzv. sdílené sloupce.
    • výchozí obsah - tedy soubory a adresáře, kterými se má naplnit nově vytvořená sada dokumentů.
    • upravovat úvodní stránku sady a vlastnosti, které na ní mají být dostupné.
    • zafixovat stav sady dokumentů a dokumentů v ní obsazených v čase, tedy udělat jakousi souhrnnou verzi.
    A jak se s nimi tedy pracuje?

    Vezměme si například smlouvy. Ty mývají obvykle, kromě smlouvy samotné, přílohy a dodatky a to vše tvoří jeden celek s jedním číslem smlouvy, platností a smluvními stranami.

    Obvyklý postup je následující:

    1. Vytvoříte si sloupce webu, které potřebujete u dokumentů. – např. číslo smlouvy, platnost do
    2. Definujete si typy obsahu odvozené od dokumentu a použijete v nich připravené sloupce. – smlouva, dodatek ke smlouvě, příloha smlouvy
    3. Definujete si typ obsahu odvozený od sady dokumentů (např. smluvní případ) a použije v nich sloupce, které mají smysl na úrovni celé sady (číslo smlouvy, platnost do).
    4. Nakonfiguruje váš typ obsahu sada dokumentů:
      1. Specifikujete, které typu obsahu může obsahovat (nemůžete určit, že sada dokumentů bude obsahovat další sadu dokumentů)
      2. Nastavíte, které vlastnosti mají být sdílené mezi sadou dokumentů a dokumenty, které bude obsahovat.
      3. Určíte defaultní obsah sady po jejím vytvoření: adresáře, soubory a jejich typy obsahu a šablony.
    5. Určíte, které ze sloupců a jejich hodnot sady dokumentů budou vidět přímo na úvodní stránce sady.
    6. Vytvoříte si knihovnu dokumentů a přiřadíte typy obsahů.
    7. Vytvoříte si zobrazení, které chcete použít pro zobrazení souborů uvnitř vaší sady dokumentů. Díky tomu můžete mít jiné výchozí zobrazení knihovny dokumentů a jiné zobrazení uvnitř sady dokumentů.
    8. V nastavení typu obsahu sady dokumentů si upravíte nastavení úvodní stránky:
      1. Určíte zobrazení pro výpis souborů v sadě.
      2. Případně můžete upravit stránku samotnou. Je to webpart page, takže na ní můžete umístit vlastní webparty, případně přemístit ty standardní.

     

    Výsledek pak může vypadat např. takto:

     
    Verze sady dokumentů

    Sady dokumentů mají svoje vlastní specifické verzování. Pro jeho fungování musí být zapnuto verzování na úrovni knihovny dokumentů (je jedno, jestli jde o verzování hlavních verzí nebo i vedlejších verzí). Tlačítka pro zachycení verze, resp. pro přístup k historii verzí jsou vidět na předchozím obrázku v ribbonu. Funguje to tak, že při zachycení verze sady dokumentů se uloží odkazy na aktuální verze (v případě zapnutí verzování s koncepty si můžete vybrat, jestli chcete pouze hlavní verze, nebo aktuální hlavní verzi nebo podverzi) jednotlivých dokumentů v sadě.

    Při vytváření verze nesmí být žádný z dokumentů rezervovaný, jinak se nepodaří vytvořit novou verzi sady dokumentů.

    Obnova verze sady dokumentů obnoví verze všech dokumentů v ní obsažených. Neobnoví se smazané dokumenty, Smutný obličej ale alespoň je v historii verzí vidět, že něco zmizelo.

    Sloupce sady a sdílené sloupce

    Sdílené sloupce sady dokumentů se vyskytují u všech dokumentů v sadě bez ohledu na jejich typ obsahu. Např. pokud bychom číslo smlouvy označili jako sdílený sloupec a současně umožnili do sady vložit typ obsahu Dokument (ten standardní typ obsahu pouze se sloupcem název), tak každý dokument s typem obsahu Dokument bude mít i sloupec číslo smlouvy.

    Změna hodnoty sdíleného sloupce sady dokumentů se projeví na dokumentu, i když je rezervovaný a nevytváří novou verzi dokumentů. Když se pokusíte změnit hodnotu sdíleného sloupce přímo na dokumentu, jde to, ale hodnota se vrátí na hodnotu ze sady.

    Technicky je realizováno pomocí event receiverů (ItemAdding a ItemUpdating). Navíc je ještě definován job Document Set fields synchronization, který se spouští standardně každých 15 minut. Ten má pokrýt situace, které receivery nepokryjí. K tomu může dojít např. v situaci, kdy sada obsahuje více než deset dokumentů se sdílenými sloupci. V takovém případě by zpracování pomocí event receiveru mohlo být příliš pomalé, a proto se o přenos hodnot sdílených sloupců postará job.

    Funkce Odeslat

    Sady dokumentů je možné odesílat například do centra záznamů (sloužícího např. jako archiv) pomocí tlačítka Odeslat. To ale nenajdete na záložce Soubory v ribbonu, nýbrž při otevření sady dokumentů na záložce Správa v ribbonu.

    Samotný dialog pak vypadá takto (možnosti umístění se konfigurují v centrální administraci):

    Pozor na 2 věci:

    1. Součet velikostí dokumentů v takové sadě nesmí být větší než 50MB
    2. Sada dokumentů se do odkládací knihovny uloží jako ZIP, který obsahuje soubory ze sady dokumentů a několik dalších souborů, které obsahují původní metadata sady.
    OneDrive pro firmy a procházení pomocí průzkumníka

    Pokud si knihovnu dokumentů se sadou dokumentů otevřete pomocí průzkumníka, zobrazí se sada dokumentů jako adresář. Stejné chování zjistíte, když si rozhodnete knihovnu dokumentů se sadami synchronizovat lokálně pomocí OneDrive. Opět se z nich stanou adresáře.

    Programování

    Z programátorského pohledu najdete potřebné třídy pro práci se sadami dokumentů v knihovně Microsoft.Office.DocumentManagement.dll

  • 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í.

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!