|
|
-
Upozornění jsou užitečná funkce v SharePointu. Jenže sebou přinášejí jeden problém (rozhodně ne jediný). Tím problémem je, jakou adresu má SharePoint použít u odkazů v upozorňovacím emailu. Např. na editaci položky, úpravu nastavení upozornění a podobně. SharePoint totiž může mít hned několik adres. Dají se spravovat v sekci Konfigurovat mapování alternativních adres URL v Centrální administraci.
Aby se s tím SharePoint nějak popral postupuje podle následujících pravidel:
- Uživatelovi se posílají upozornění s adresou, která odpovídá adrese použité v okamžiku vytvoření.
- U upozornění, které definuje administrátor (např. notifikace při přiřazení úkolu), je to adresa, kterou použil admin.
Zejména u těch uživatelsky definovaných upozornění jde o poměrně rozumný přístup, protože umožňuje různým uživatelům mít v upozorněních různou adresu. Navíc adresa odpovídá té, kterou uživatel minimálně jednou použil. U administrátorem definovaných upozorněních už to tak jednoduché není, protože administrátor může pro přístup k SharePointu používat jinou adresu než běžní uživatelé. Musí na to prostě pamatovat.
Naštěstí existuje powershell příkaz, kterým se URL adresy dají přemapovat. Bohužel není mezi standardními SharePointími příkazy, ale dá se stáhnout z MSDN. Bude se vám hodit nejen v situaci, kdy uživatel začne používat jinou adresu než v okamžiku definice upozornění, ale i v situaci, kdy např. obnovíte farmu ze zálohy na stroji, který se jmenuje jinak než ten původní.
|
-
Jednou z užitečných věcí, která je nová ve Visual Studiu 2010 a v SharePointu 2010, je možnost "naklikat" si v UI seznamy, typy obsahu, zobrazení atd a následně to uložit jako šablonu webu. Dobré je, že šablona webu je WSP (kéž by to tak bylo i u šablon seznamů). Další na to navazující užitečná věc je ve Visual Studiu 2010. Zde můžete toto WSP naimportovat tak, že Visual Studio 2010 z něj vytvoří projekt. V takovém projektu můžete dodělat věci, které se v UI udělat nedají, nebo se dělají špatně.
Důvodem pro takovou dvojitou akci může být např. to, že ve Visual Studiu 2010 není designer seznamů, typů obsahu, zobrazení a je nutné je definovat psaním nepřehledných XML. Naštěstí ve Visual Studiu 11 už takový designer je.
Problém je ale v tom, že Visual Studiem 2010 vytvořené řešení používá u feature seznamů receiver Microsoft.SharePoint.Workflow.SPDeclarativeWorkflowProvisioningFullTrustOnlyFeatureReceiver. Ten (nebo něco co používá) ale psal někdo, kdo zřejmě nikdy neslyšel o jiných než v angličtině se vyskytujících se znacích.
Například takové zobrazení "Všechny položky" se totiž vytvoří jako "VÅ¡echny položky". Je to proto, že š má UTF-8 reprezentaci c5a1. Zmíněný receiver ale nezpracovává konfigurační XML (např. schema.xml) jako UTF-8 (i když to mají nastavené v hlavičce), ale jako obyčejné ASCII, tedy po jednotlivých bytech. V tomto kódování odpovídá c5 znak Å a a1 znak ¡. Bohužel se to netýká jen seznamů, ale i zobrazení, sloupců atd zkrátka všemu, co může ve schématu seznamu být. Závěr Jde o školáckou chybu při psaní kódu. Navíc mi není jasné jak to mohlo projít testováním. Než bude stabilní verze Visual Studia 11, kde už designer seznamů je, je potřeba si na to dát pozor a doufat, že to v příští verzi MS v nějakém SP SharePointu opraví.
|
-
Před časem jsem řešil problém, kdy databáze služby Import uživatelských profilů měla velikost přes 21GB. To je na profily cca 150 členů domény poměrně dost. Začal jsem proto pátrat po tom čím by to mohlo být způsobeno a jak to vyřešit.
Prozkoumáním databáze (typicky ve svém jméně obsahuje UserProfile, její přesné jméno naleznete v konfiguraci služby Import uživatelských profilů) jsem zjistil, že drtivá většina dat se nachází v tabulce InstanceData. Tato tabulka slouží v průběhu importu. Problém je v tom, že se z ní nemažou nepotřebné záznamy z již proběhlých importů. Dokonce mezi uloženými procedurami můžete najít jednu, která se nachází ve schématu FIM a jmenuje se [TruncateInstanceData]. Je to dáno tím, že oproti předchozí verzi SP 2007, kde byl import omezen na Active Directory a byl řešen proprietárně, v SP 2010 je import řešen pomocí tzv. FIMu (Forefront Identity Manager). To je obecný nástroj pro distribuci informací z uživatelských profilů mezi různými systémy. Díky tomu může být zdrojem uživatelských informací i jiný informační systém, než jen Active Directory. Bohužel při implementaci FIMu (resp. jeho omezené části) do SharePointu došlo někde k chybě a zmíněná procedura se nevolá tak, jak by měla a nedochází k mazání již nepotřebných informací. Databáze proto roste a roste...
Řešením, které se nabízí, je ruční spuštění této procedury a její pravidelné spouštění. Protože ale procedura obsahuje jediný delete příkaz, může se vám stát, že po několika hodinách jejího běhu zjistíte, že skončila chybou a nedošlo ke zmenšení tabulky ani databáze. Je to proto, že elementární operace (např. DELETE) běží jako transakce. V průběhu transakce se vytváří log toho co se stalo, aby bylo možné případně transakci rollbackovat. Proto mazání velkého množství dat najednou vede k velkým nárokům na velikost databázového logu. Proto vám doporučuji následující:
- Změnte recovery schéma z Full na Simple. Tím docílíte toho, že po dokončení transakce se jí vygenerovaná část logu smaže.
- DELETE příkaz z procedury si vykopírute bokem a spouštějte několikrát za sebou s vhodnou podmínkou tak, aby množství mazaných záznamů nebylo příliš velké.
- Nakonec proveďte shrink databáze. Tím se uvolní prázdné místo po smazaných záznamech a dojde ke skutečnému zmenšení databázových souborů. To uděláte např. pomocí kontextového menu databáze v MS SQL Management Studiu. Zde najdete položku Tasks -> Shrink
- Přepněte recovery schéma databáze na původní hodnotu.
Protože jsem na webu narazil na informaci, že v některých databázích zmiňovaná procedura vůbec není, přikládám její podobu tak, jak jsem ji našel v mnou zkoumané databázi:
/****** Object: StoredProcedure [FIM].[TruncateInstanceData] */
SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE PROCEDURE [FIM].[TruncateInstanceData]
AS
BEGIN
--************************************************************
--* *
--* Copyright (C) Microsoft. All rights reserved. *
--* *
--************************************************************
SET NOCOUNT ON;
DECLARE @truncationTime datetime;
SET @truncationTime = DATEADD(day, -1, GETUTCDATE());
DELETE FROM [dbo].[InstanceData]
WHERE ([created] < @truncationTime)
END
GO
|
-
Celé to začalo podivným chováním úkolů v SharePointu. Jeden uživatel (říkejme mu třeba Karel Novák) měl přiřazeno několik úkolů. O všech mu přišla notifikace, že mu byly přiřazeny, ale některé nemohl měnit z důvodů nedostatku práv. Prostředí bylo nastaveno tak, že právo měnit úkol měl pouze přiřazený uživatel a zadavatel úkolů. Zběžná kontrola úkolů neodhalila nic podezřelého. Oba zkoumané úkoly vypadaly na vlas stejně. Práva byla nastavena automatickým procesem a taky byla stejná. Tedy alespoň na první a druhý pohled. Nakonec jsem si všiml, že problém byl v tom, že není Karel Novák jako Karel Novák. I když byl ve firmě jediný. On totiž měl 2 loginy v různých doménách se stejným jménem. Díky tomu se v dialogu pro výběr uživatele zobrazoval 2x. Pokud ale zadavatel úkolu zadal přesné jméno už v dialogu úkolu a stiskl Ctrl+K tedy ověření, tak ověření prošlo. Ale který z těch dvou účtů byl vybrán, to už se zadavatel nedozvěděl.
Naštěstí s tímto problémem při vývoji SharePointu počítali, takže se dá omezit, ze kterých organizačních jednotek se mají nabízet uživatelé při výběru uživatelů.
Dá se určit organizační jednotka AD, na kterou se má omezit výběr uživatelů:
stsadm -o setsiteuseraccountdirectorypath -path "OU=Sales,DC=ContosoCorp,DC=local" –url http://ServerName
Taky se dá určit, že
- při ověřování jména uživatele (tlačítko Kontrola jmen, nebo Ctrl+K) se mají brát v potaz pouze ti uživatelé, kteří mají přístup k dané kolekci webů:
stsadm -o setproperty –pn peoplepicker-Peopleeditoronlyresolvewithinsitecollection –pv yes –url
<Web application URL>
- ve vyhledávacím dialogu (tlačítko Procházet) se mají brát v potaz pouze ti uživatelé, kteří mají přístup k dané kolekci webů:
stsadm -o setproperty –pn peoplepicker-onlysearchwithinsitecollection –pv yes –url
<Web application URL>
Pokud potřebujete něco sofistikovanějšího, můžete výběr uživatelů z AD omezit pomocí LDAP dotazu:
stsadm –o setproperty –pn peoplepicker-searchadcustomfilter -pv
<LDAP query filter>
-url
<Web application URL>
Kompletní popis najdete na MSDN.
Při praktickém použití je ale nutné udělat ještě jednu věc. Samotné omezení výběru z Active Directory nestačí. Pokud totiž uživatel (resp. jeho login) už v SharePointu figuruje, např. proto, že mu byl přiřazen úkol, práva ... , je v seznamu uživatelů SharePointu. Jako takový je do výsledku vyhledávání v PeoplePickup editoru taky zahrnut, ať už výše uvedeným omezením vyhovuje, nebo ne. Proto je nutné, k tomu abyste se takového loginu zbavili uplně, odstranit ho i z tohoto "seznamu". S tím souvisí další trik. Standardně se totiž k seznamu všech uživatelů pomocí webového UI SharePointu nedostanete. Lze zobrazit jen členy určité skupiny. K tomu slouží stránka s adresou http://server/_layouts/people.aspx?MembershipGroupId=XXX. Parametrem XXX je ID té skupiny. Pokud použijete 0, dostanete seznam všech uživatelů bez ohledu na to členy jakých skupin jsou (pokud vůbec nějakých).
|
-
Úvod
PerformancePoint funkcionalita umožnuje zobrazit uživatelům top level pohled na nejrůznější ukazatele s vizuální informací o tom, jak si který z nich stojí (dobře, špatně, tak něco mezi). Vizuálnost je řešena pomocí grafů, budíků, semaforů, různě se tvářících smajlíků a podobně. Ale tím možnosti PerformancePointu nekončí. Při napojení na Analysis Services je možné zpřístupnit v prostředí SharePointu i analytické nástroje jako analytický graf, analytickou tabulku a mapu strategie. V tomto příspěvku se podíváme na základy toho, co PerformancePoint funkcionalita v SharePointu 2010 obsahuje.
PerformancePoint byl ještě nedávno samostatný produkt. S příchodem SharePointu 2010 se z něj stala jedna ze součástí Enterprise verze. Tedy ne ze všeho, ale z většiny. Funkcionalita proClarity zůstala samostatná a její obchodní název je ProClarity server.
Nejprve je potřeba zprovoznit PerformancePoint službu a Secure Store Service. Druhá z nich je důležitá pro správu identit pod nimiž se bude přistupovat k datovým zdrojům (viz. dále)
Na úrovni kolekce webů je potřeba zapnout Publikování a Performance Point funkci. Díky tomu se vám v šablonách webů objeví Centrum Business Inteligence na němž můžete vytvářet a publikovat vše o čem si dnes budeme povídat. Taky se vám tím zpřístupní PerformancePoint webparty, které můžete umístit na jakýkoliv web a publikovat s jeho pomocí Performance Point záležitosti i jinde.
Nástrojem, kterým se PerformacePoint věci konfigurují, je Dashboard Designer (Návrhář řídících panelů). To je ClickOnce aplikace a odkaz na ní je uveden na stránce webu Centra Business Inteligence.
Datový zdroj
Určuje odkud, jakým způsobem a pod jakou identitou se budou získávat data, která se pak budou prezentovat pomocí PerformancePoint funkcionality.
Je možno definovat následující typy připojení:
- Analysis Services - umožňuje čerpat data z Analysis Services SQL serveru. Spoustu pokročilé funkcionality Performance Pointu je omezena tím, že datový zdroj pro ni musí být tohoto typu.
- Seznam SharePointu
- SQL
- Excel services
- Excelový soubor
U datového zdroje si je potřeba uvědomit jednu důležitou věc, která se týká autentizace. Pokud nemáte rozchozený Kerberos, nebo zdroj dat neleží na stejném počítači jako SharePoint, nemá smysl v při nastavování autentizace používat volbu "Identita vázaná na uživatele". Důvod je v tom, že NTLM ověření se nedá delegovat dále, mimo počítač vůči kterému proběhlo.
Ukazatel (Indicator)
Definuje škálu, to znamená můžete určit popis, obrázek a barvu textu a pozadí pro až 10 "hodnocení". Například různé smajlíky, teploměry apod. Tyto škály se pak využívají pro grafické znázornění dat klíčových ukazatelů výkonu. Existují 2 druhy ukazatelů:
- Standardní - jejich logika je založena na hesle: "čím větší, tím lepší". Jinými slovy řečeno. Nejlepší a nejhorší hodnota jsou na kraji škály.
- ty, které mají nejlepší hodnotu uprostřed a oba "konce" představují "špatné" hodnoty.
Ukazatel sám ještě není svázán s konkrétními daty.
Klíčový ukazatel výkonu (Key Performance Indicator - KPI)
Spojuje dohromady předchozí věci a několik dalších nastavení. Určuje:
- zdroje dat - jeden nebo více zdrojů dat pro zobrazení indikátoru.
- skutečnost - sloupec ze zdroje dat, který reprezentuje "naměřené" hodnoty.
- cíl - sloupec ze zdroje dat, nebo pevná hodnota, která představuje cíl, kterého se snaží skutečnost dosáhnout. Zdroj dat cíle může být jiný než zdroj dat pro skutečnost.
- filtry - už na této úrovni můžeme definovat podle jakých kritérií bude možné hodnoty skutečnosti omezovat během analýzy dat
- ukazatel
- mapování vztahu skutečnosti a cíle na jednotlivé hodnoty ukazatele. Například určuje, že pokud skutečnost představuje 0 - 20% cílové hodnoty, použije se k jejímu zobrazení první "hodnota" (grafický symbol) škály ukazatele.
Klíčový ukazatel výkonu může obsahovat několik skutečností a cílů.
Filtr
Jde hodnoty z datového zdroje, které mohou být v dashboardu použity pro omezení zobrazené množiny dat. Problém je, že většinou musíte určit konkrétní hodnoty např. 1,2,3,4,5,6 a nemůžete říci: "Tento filtr bude umožňovat omezit zobrazení výsledků podle věku osoby s tím, že rozsah bude určen tím, jaké hodnoty se nachází ve sloupci "věk" datového zdroje.
Přehled výkonnostních metrik (scorecard)
První vizuální věc, tedy něco, co můžete uživatelům ukázat pomocí webpartu na stránce SharePointu. Je to vlastně zobrazení KPI, grafu,... s výběrem konkrétních metrik cílů. K zobrazení scorecard je určen webpart Přehled výkonnostních metrik serveru PerformancePoint.
Řídící panel (dashboard)
Další vizuální věc. Může se skládat ze všeho o čem jsem dosud psal. K jeho zobrazení na SharePointu ji ale musíte publikovat, nestačí to jen uložit. Jde totiž o celé stránky s webparty (scorecardy, filtry, grafy, viz. níže) a jejich propojeními. Kromě specifických PerformancePoint filtrů je možné využít i standardní SharePoint filtry. Užitečný je např. filtr aktuální osoby. To už ale neuděláte pomocí PerformancePoint Designeru. Musíte publikovanou stránku následně otevřít pomocí SharePoint Designeru.
Webparty
K zobrazení věcí PerformancePointu na stránkách SharePointu slouží následující webparty:
- Filtr serveru PerformancePoint - zobrazí filtr definovaný v rámci PerformancePoint funcionality
- Přehled výkonnostních metrik serveru PerformancePoint - webpart pro zobrazení scorecard
- Sestava serveru PerformancePoint - zobrazuje grafy
- Výběr zobrazení serveru PerformancePoint
Jak jsem se zmiňoval v úvodu, tyto webparty lze použít, při aktivaci příslušných funkcí, i jinde než na webech Bussiness Inteligence Center.
Závěr
PerformancePoint se hodí pro manažerský pohled na data. To znamená, že pohledem na teploměry klíčových ukazatelů výkonu manažer zjistí, jestli není něco potřeba řešit. Pomocí analytických možností následně může řešit, kde je zakopaný pes. PerformancePoint může pracovat nad tabulkami v SQL, seznamy SharePointu, ale většina cool funkcí je svázána s napojením na Analysis services MS SQL serveru a rozhodně se vám při práci s PerformancePointem budou zkušenosti (ať už vlastní, nebo cizí) hodit.
|
-
Tahle chyba mě stála spoustu energie, než se mi podařilo přijít na to, kde přesně je zakopaný pes.
O SPSiteDataQuery jsem psal ve článku SPSiteDataQuery a CrossListQueryInfo.
Vytvořil jsem webpart, ve kterém používám zmiňovaný objekt k zobrazení dokumentů roztříděných podle různých vlastností. Funguje to tak, že uživatel postupně vybírá hodnoty jednotlivých vlastností a tím omezuje dokumenty, které se mu zobrazí. Většinou to funguje dobře. Jenže...
Použil jsem dotaz na získání hodnot sloupce A (sloupec jsem použil ve viewfields). Pomocí vlastnosti Query jsem omezil výsledky na typ obsahu, který vlastnost A obsahuje. V mém konkrétním případě se mi vrátilo 71 záznamů. Jednou z hodnot vlastnosti A byla hodnota test. Mělo ji 6 záznamů. Následně jsem rozšířil podmínku tak, aby se navíc testovala právě hodnota test ve sloupci A. Pomocí nastavení viewfields jsem zjišťoval tentokrát hodnoty ve sloupci B. Očekával jsem, že dostanu 6 záznamů z předchozího dotazu, jen získám hodnoty ze sloupce B. Velmi jsem se mýlil. Vrátil se mi 1 záznam. Shodou okolností to byl jeden z těch 71 záznamů z výsledku předchozího dotazu. Jenže ten měl ve vlastnosti A něco úplně jiného než test. To nabourává důvěru v to, co se dá pomocí objektu SPSiteDataQuery najít. Proto jsem tento problém reportoval MS jako bug a ten ho teď řeší. Uvidíme s jakým výsledkem.
Naštěstí jsem mezitím našel řešení. Stačí nechat sloupec A, který je součástí podmínky, i mezi sloupci ve viewfields a vše už funguje jak má. Bohužel se tím zvyšuje množství dat získávaných z databáze. Na druhou stranu to aspoň funguje a vrací výsledky, které má.
|
-
Dnes jsem publikoval svůj první projekt na Codeplexu! Nazval jsem ho SharePoint 2010 Google Maps V3 WebPart. Jde o webpart, který zobrazuje geografické informace pomocí Google Maps. Využívá aktuální verzi Google Maps Javascript API, tzn. verzi 3.6. Ta, kromě jiného, oproti verzi 2.X nevyžaduje API key. Snažil jsem se ho udělat univerzální, takže může pracovat v několika režimech, podle toho, odkud získává data pro zobrazení bodů na mapě:
- Napojení na jiný webpart - seznam bodů je získán z nějakého seznamového webpartu na stránce. Pod seznam např. provozoven můžete umístit tento webpart a
propojit je. Díky tomu pak můžete mít na jedné stránce seznam i mapové zobrazení
včetně toho, že pokud v seznamu použijete nějaký filtr, účinky filtru se
projeví i v mapě.
- Napojení na seznam + podmínka - v tomto případě můžete na nějaké stránce SP zobrazit např. pouze otevřené pobočky.
- Napojení na seznam + jméno URL parametru, který obsahuje ID položky pro zobrazení - mód určený k použití na detailech záznamů. Webpart umístíte na display form seznamu s body a nastavíte, že URL parametr s ID záznamu je ID. Pak uvidíte na detailu záznamu nejen jeho vlastnosti, ale i umístění na mapě.
Taky jsem se snažil podporovat několik různých formátů pro zápis souřadnic:
- 40°26′47″N
- 40° 26.7717
- 40.446195N
- 40.446195
včetně toho, že šířka a délka mohou být uloženy v různých sloupcích, nebo v jednom. Kromě toho je možné určit, ve kterém sloupci je adresa bodů. Webpart pracuje tak, že:
- Snaží se zjistit informace o šířce a délce bodů.
- Pokud není definováno, ve kterých sloupcích je uložena, nebo neobsahuje polohu ve správném formátu (nebo ji vůbec neobsahuje), pak se pokouší převést adresu na souřadnice ty použít.
Webpart taky dynamicky vypočítává střed zobrazení mapy, pokud není střed zadán ručně.
Kromě toho, že dělá něco užitečného, tak díky tomu, že jsou u něj i zdrojáky, mohl by se vám hodit i z řekněme výukových důvodů:
- je to webpart, který implementuje rozhraní IWebPartTable pro získávání tabulky dat z jiného webpartu, typicky z webpartu zobrazující seznam.
- začátečníci se mohou inspirovat, jak se píše vlastní editační dialog, resp. editorpart.
- pokročilí si v editorpartu mohou všimnout využití standardního SharePointího dialogu pro výběr webu a seznamu.
Jde o první verzi, kterou budu dále rozvíjet, především v možnostech získávání dat pro zobrazení a ve zpřístupnění nastavení parametrů Google Maps. Pokud byste v něm našli chybu, nebo byste měli námět, jak ho vylepšit, nebojte se mi ozvat. Předem děkuji!
|
-
Koncem června vyšel ServicePack 1 pro SharePoint 2010. Co přináší nového se můžete dočíst na mnoha webech. V dnešním příspěvku si povíme něco o praktických zkušenostech z instalace a výsledku.
Instalace
Protože existují 2 základní edice SharePointu, tedy SharePoint Foundation 2010 a SharePoint Server 2010, existují i 2 service packy. Pokud provozujete SharePoint Server (ať už Standard, nebo Enterprise), je potřeba instalovat SP1 v následujícím pořadí: - SharePoint Foundation 2010 Service Pack 1
- Service Pack 1 for SharePoint Foundation 2010 Language Pack
- SharePoint Server 2010 Service Pack 1
- Service Pack 1 for Server Language Pack 2010
Instalace SP1 pro language pack je nutná samozřejmě pouze v případě, že na serveru nějaký language pack máte nainstalovaný. Pokud ano, musí jazyková verze SP1 language packu odpovídat jazykové verzi language packu samotného. Instalace samotná proběhla stylem "Další, další, ...". Jako druhý krok je nutné spustit "Průvodce konfigurací produktů SharePoint 2010". Pokud na to zapomenete zdánlivě se nic nestane, ale jednou narazíte na hlášku v tom smyslu, že verze schématu databáze je nižší než je podporováno.
Po instalaci
Na první pohled vše fungovalo, ale na druhý se ukázalo několik problémů
- Neběží FIMSynchronization služba - tu stačí naštěstí prostě spustit.
- Přestalo fungovat rozbalování skupin v zobrazeních, které výsledky groupovaly do skupin - pátráním na webu jsem zjistil, že tento problém se objevil v únorovém CU a týká se neanglických verzí, ve kterých je chyba v javascriptu. Problém se projevuje tím, že při pokusu o rozbalení groupy dojde k javascriptové chybě že g_ExpGroupXSLTQueue není definována. Existují v podstatě 2 možnosti:
- Vzít CORE.js z adresáře 1033, tedy anglickou verzi a přepsat jím postiženou verzi např. v adresáři 1029. Problém tohoto postupu je, že budete mít najednou v českém SharePointu anglické výrazy, takže to není řešení, ale náhradní řešení, aby to vůbec fungovalo.
- Je možné opravit postižený CORE.js. To ale je mimořádně obtížné, protože soubor jsou minimalizován. Je z něj vypuštěno vše, co není nutné pro interpret javascriptu. Výrazně snazší je upravit CORE.debug.js. Ten je sice delší, ale čitelný. Po úpravě jím přepíšeme CORE.js, dokud MS nevydá oficiální opravu. I v tomto případě se jedná spíše o hotfix, než o řešení. V souboru CORE.js je potřeba zakomentovat kód na řádcích 1937-1940
if (g_ExpGroupSeparateQueues)
{
//if (isDataView && g_ExpGroupXSLTQueue.length > 0)
//{
// ExpGroupFetchData(g_ExpGroupXSLTQueue.shift(), isDataView);
//} else
if (!isDataView && g_ExpGroupCAMLQueue.length > 0)
{
ExpGroupFetchData(g_ExpGroupCAMLQueue.shift(), isDataView);
}
}
a na řádcích 2002-2009
if (isLoaded=="false")
{
// if (g_ExpGroupSeparateQueues)
// {
// if (isDataView)
// g_ExpGroupXSLTQueue.push(groupName);
// else
// g_ExpGroupCAMLQueue.push(groupName);
// }
// else
g_ExpGroupQueue.push(groupName);
}
- Objevil se problém s několika průzkumy - tady bylo zvláštní, že se to týkalo jen někerých z průzkumů a nepodařilo se mi zjistit, čím sel lišily od těch nepostižených. Postižené průzkumy nešly otevřít a data bylo možné získat pouze z databáze. Nakonec nezbylo, než průzkumy smazat a opětovně je vytvořit a naplnit daty zachráněnými z databáze.
- V ULS logu se objevila chyba o tom, že v databázi neexistuje procedura proc_UpdateStatisticsNVP. To je důsledek změny v proceduře proc_UpdateStatistics, která se odkazuje na chybějící proceduru. Nutno podotknout, že proc_UpdateStatisticsNVP chybí jen v některých databázích SharePointu. Proto je možným řešením její zkopírování z databází, kde existuje do databází, kde chybí.
|
-
Tento příspěvek bude tak trochu propagační... 1.7. se mi podařilo složit poslední ze 4 MCP zkoušek týkající se SharePointu 2010: - 70-667: MCTS: Microsoft SharePoint 2010, Configuring
- 70-573: MCTS: Microsoft SharePoint 2010, Application Development
- 70-668: PRO: Microsoft SharePoint 2010, Administrator
- 70-576: PRO: Designing and Developing Microsoft SharePoint 2010 Applications
Pokud se na ně také chystáte, pak mám pro vás několik typů, na co byste se měli soustředit: - scénáře upgrade z verze SharePointu 2007
- scénáře upgrade již nasazených feature podle toho, co v nich měníte
- využití BCS
- managed Metadata Service
- tomu jaké scopy (Web,Site,Farm,...) je možné a vhodné definovat u feature obsahující definice šablon, seznamů, sloupců, typů obsahu,...
- jak konfigurovat joby, webparty, event handlery a další... pomocí seznamů, web.configu, SPPersistedObjectu, ...
Hodně zdaru při lovu!
|
-
Pokud používáte Visual Studio a Team Foundation Serveru, tak asi team buildy znáte. Dnes si ukážeme, co je potřeba udělat k tomu, aby bylo možné na Team Foundation Serveru 2010 překládat projekty pro SharePoint 2010.
Co to je team build a k čemu je to dobré?
Jde o fukci Team Foundation Serveru, která umožňuje centrální překlady projektů uložených s Souce Controlu. Hlavní přínos vidím v tom, že díky team buildu jste schopni provést překlad projektu bez závislostí na vývojářských stanicích. Může totiž dojít k tomu, že vývojář při vývoji projektu použije nějakou komponentu, nebo lokální konfiguraci, kterou má a zná jen on. V případě jeho nepřítomnosti se pak může stát, že projekt, na kterém dělal a ve kterém je potřeba např. opravit chybu, není schopen přeložit nikdo jiný na žádném jiném počítači. Dalším dobrým důvodem může být to, že máte jedno místo, kde máte dostupné přeložené kódy vašich projektů např. pro testery a pro týmy, které mají na starosti nasazení projektů. Ty pak nejsou závislé na tom, aby jim některý z vývojářů udělal build aktuální verze.
Co je pro to potřeba udělat?
- Je potřeba mít samozřejmě nainstalovaný Team Foundation Server a speciálně jeho volitelnou část build server.
- Je nutné na build server dostat (do GACu) vše potřebné, co je pro překlad SharePoint projektů potřeba. Jednou z možností, jak toho dosáhlout je nainstalovat SP 2010 a Visual Studio 2010 na build server. Tohle ale nedoporučuju, protože toho na build server nainstaluje mraky a jen něco budete skutečně potřebovat:
- SharePoint targets a tasks:
- Microsoft.VisualStudio.SharePoint.targets
- Microsoft.VisualStudio.SharePoint.Tasks.dll
Toto jsou komponenty z Visual Studia a najdete je v C:\Program Files (x86)\MSBuild\Microsoft\VisualStudio\v10.0\SharePointTools\
- SharePoint assembly:
- Microsoft.SharePoint.dll
- Microsoft.SharePoint.Security.dll
- Microsoft.SharePoint.WorkflowActions.dll
Assembly SharePointu, najdete je v adresáři C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI
- SharePoint tool assembly:
- Microsoft.VisualStudio.SharePoint.Designers.Models.dll
- Microsoft.VisualStudio.SharePoint.Designers.Models.Features.dll
- Microsoft.VisualStudio.SharePoint.Designers.Models.Packages.dll
- Microsoft.VisualStudio.SharePoint.dll
Opět součást Visual Studia, najdete je v adresáři C:\Windows\Microsoft.NET\assembly\GAC_MSIL\ . Budete potřebovat nějaký souborový manažer, který se sem dostane. Standardním průzkumníkem z Windows to totiž nepůjde. Ve zmíněném adresáři najdete podadresáře, které odpovídají jménům assembly bez přípony a v nich ještě podadresář s verzí a public key token. Uvnitř pak jsou hledané assembly.
- Také je samozřejmě nutné dostat na build server všechny komponenty třetích stran, které vaše řešení vyžaduje při překladu. Toho lze dosáhnout:
- buď tím, že je nainstalujete na build server - tato varianta se hodí, pokud na cílových serverech (tam, kde to nakonec poběží) budou již tyto komponenty nainstalovány. Tím ze z nich stávají prerekvizity vašich řešení.
- nebo je zahrnete přímo do projektů - ideálně i do WSP balíků tak, aby si je projekt nesl sebou.
- Je potřeba vytvořit na TFS buildy projektů a správně je nakonfigurovat:
- Při konfiguraci teamových buildů zadejte do MSBuild Action parameters hodnotu /p:IsPackaging=True - tím Build server přimějete k tomu, aby generovat WSP balíky vašich projektů.
- Pokud máte v solution projekt v Silverlightu, je potřeba je překládat pro platformu x86, tzn. nastavte parametr MSBuildPlatform na hodnotu x86. Můžete si také udělat zvlášť build pro Silverlight projekty (x86) a zvlášť pro ostatní (SharePointí), u kterých nastavíte x64.
Množství assembly, které je potřeba na Build server dostat se
samozřejmě liší podle toho, které části SharePointu ve svých projektech
používáte. Pokud například používáte ve svých řešeních Silverlight,
budete na Build server muset dostat ještě i jeho knihovny z jeho SDK.
ZávěrTFS je užitečný nástroj a redukovat jeho použití na pouhé úložiště zdrojových kódů by byla chyba. Jednou z mnoha možností je využívat např. právě teamové buildy jako součást zlepšení vývojových cyklů SharePointích projektů. Tím ale nejsou schopnosti TFS serveru zdaleka vyčerpány...
|
-
Úvod
Jednou z možných optimalizací, kterou můžete v SharePointu 2010 provést, je využití RBS (Remote Blob Storage). Tato technika spočívá v tom, že neukládá souborové informace do databáze obsahu, ale do jiného úložiště. Problém je totiž v tom, že pokud se souborová data ukládají do databáze, vzniká tam režie navíc. Ta by při přímém ukládání na disk nevznikala. U čtení je to samozřejmě podobné.
Způsobů jak realizovat RBS v SharePointu je více. Existují k tomu řešení třetích stran. V tomto článku se podíváme na způsob, jak toho dosáhnout pomocí prostředků MS SQL. Microsoft do SQL serveru 2008 zahrnul technologii FILESTREAM. Ta umožnuje data ze sloupců typu varbinary(max) tedy BLOBy (binary large objects) ... ukládat na disk v podobě souborů. Tato technologie je tedy vlastní MS SQL 2008 a dá se použít i bez SharePointu. RBS naproti tomu je záležitost SharePointu a jedna z jejich implementací využívá právě FILESTREAM.
Přínosy a omezení
Nejprve se zastavíme u srovnání výhod a nevýhod, které využití FILESTREAMu u MS SQL databází přináší:
+ technologie FILESTREAM je dostupná i u Express edice a velikost dat
uložených pomocí této technologie se nepočítá do limitu velikosti
databáze, kterou tato edice má zabudovanou (10GB).
+ rychlejší práce s dlouhými binárními daty (nejčastěji to jsou soubory)
+ menší databáze
+ větší odolnost proti fragmentaci - omezuje se vnitřní fragmentace databáze, po smazání velkého souboru nezůstane v db prázdná velká díra. Prostě se smaže soubor a v databázi se upraví jen krátký záznam. Externí soubory je možné snadněji defragmentovat než, když jsou uloženy v databázi (tam to nejde prakticky vůbec, lze max. defragmentovat vnitřek celé databáze a pak ještě defragmentovat její soubory).
+ to, jestli se mají data z konkrétního sloupce ukládat na disk se je vlastností jednotlivých sloupců, takže se to dá zapnout jen u těch sloupců, kde to má smysl.
+ zálohování databáze provede zálohu i FILESTREAM souborů
+ Pomocí třídy SqlFileStream lze pracovat s daty souborově přímo z .NET frameworku. (s tím, že soubor nelze vytvořit ani smazat). Při tomto se vnitřně využívá souborového WIN32 API.
- data jsou mimo samotnou databázi, je snadnější se k nim dostat (a případně je zcizit). Data nejsou šifrována a to ani v případě, že máte zapnuté šifrování databáze jako takové.
- je tam jedna nepříjemná chyba (viz. na konci)
- konfigurace je taková komplikovaná a snadno se v ní udělá chyba
Doporučení ohledně použití FILESTREAMu
- Používat u větších množství dat. SharePoint ukládá do FILESTREAMU data od cca 100 KB.
- Ideální je umístit adresář pro ukládání souborů na disk, kde není systém, swapovací soubor ani datové soubory databází.
Z výše uvedeného plyne, že je užitečné o tom uvažovat v případě, že na daném SharePointu ukládáte vetší množství souborů. To je obvyklé pro DMS systémy.
Jak to zprovoznit?
1. Zapnout FILESTREAM na úrovni SQL serveru
Toto se provede pomocí nástroje SQL server Configuration Manager 
Pak pomocí SQL Management Studia spusťte následující skript:
EXEC sp_configure filestream_access_level, 2
RECONFIGURE
2. Zapnutí FILESTREAMu na úrovni databáze - v našem případě to bude databáze obsahu
pomocí SQL Management Studia:
USE [WSS_Content]
If not exists (select * from sys.symmetric_keys where name = N'##MS_DatabaseMasterKey##') create master key encryption by password = N'eskfjhwsdkjh'
If not exists (select groupname from sysfilegroups where groupname=N'RBSFilestreamProvider') alter database [WSS_Content] add filegroup RBSFilestreamProvider contains filestream
Alter database [WSS_Content] add file (name = RBSFilestreamFile, filename = 'D:\DataStore\WSS_Content') to filegroup RBSFilestreamProvider
U prvního příkazu pozor, pokud máte SQL server na počítači v doméně, musí heslo odpovídat doménové politice na složitost hesla. U třetího příkazu nevytvářejte použitý adresář, SQL server by ho měl vytvořit sám.
3. Zapnutí podpory RBS v SQL serveru - proveďte na SQL Serveru
Na SQL server stáhněte a nakonfigurujte RBS.msi. I v případě, že máte SQL Server 2008 a ne SQL SErver 2008, použijte RSB.msi z uvedeného odkazu. RBS.msi je sice součástí FeaturePacku i SQL Serveru 2008, ale pro správnou funkci RBS v SharePointu, je potřeba verze RBS minimálně 10.50.xxx. Ta ve FeaturePacku SQL Serveru 2008 má verzi nižší.
Konfigurační příkaz je:
msiexec /qn /lvx* rbs_install_log.txt /i RBS.msi TRUSTSERVERCERTIFICATE=true FILEGROUP=PRIMARY DBNAME="WSS_Content" DBINSTANCE="SQLServer\instance" FILESTREAMFILEGROUP=RBSFilestreamProvider FILESTREAMSTORENAME=FilestreamProvider_WSS_Content
To že konfigurace proběhla v pořádku ověřte v zadaném log souboru. Měli byste v něm ke konci najít spojení "installed successuly".
4. Konfigurace RBS v SharePointu - musíte provést na všech webových serverech farmy
Použijte stejný RBS.msi jako v předchozím kroku. Tenhle krok má 2 varianty, podle toho, jestli konfigurujete první RBS:
msiexec /qn /i rbs.msi REMOTEBLOBENABLE=1 FILESTREAMPROVIDERENABLE=1 DBNAME="WSS_Content" FILESTREAMSTORENAME=FilestreamProvider_WSS_Content ADDLOCAL=Client,Docs,Maintainer,ServerScript,FilestreamClient,FilestreamServer DBINSTANCE="SQLServer\Instance"
nebo některý další:
msiexec /qn /i rbs.msi REMOTEBLOBENABLE=1 FILESTREAMPROVIDERENABLE=1 DBNAME="WSS_Content" FILESTREAMSTORENAME=FilestreamProvider_WSS_Content ADDLOCAL=EnableRBS,FilestreamRunScript DBINSTANCE="SQLServer\Instance"
5. Zapnutí RBS na úrovni databáze obsahu
Provádí se pomocí PowerShellu:
$cdb = Get-SPContentDatabase WSS_Content
$rbss = $cdb.RemoteBlobStorageSettings
$rbss.Installed()
$rbss.Enable()
$rbss.SetActiveProviderName($rbss.GetProviderNames()[0])
$rbss
6. Test
Pokud jste RBS rozcházeli nad už naplněnou databází, je ideálním testem pokračování v předchozím PowerShellu příkazem $rbss.Migrate() . Ten by se měl postarat o to, aby se soubory uložené v databázi "přesypaly" na disk.
Pokud máte databázi prázdnou, zkuste do nějaké knihovny dokumentů uložit 3 soubory:
- Jeden by měl mít méně než 100 KB. Tento soubor by měl být uložen do databáze.
- Druhý by měl být větší než 100 KB, ale menší než 1.2 MB - měl by se uložit na disk.
- Třetí by měl být větší než 1.2 MB - měl by se uložit na disk.
Rozdíl v testu 2 a 3 je v technice, jakou bude s tímto souborem zacházet SharePoint. Viz. následující bod. Přítomnost souborů na disku můžete zkontrolovat prohlídkou adresáře, který jste použili ve druhém kroku konfigurace. Podle jména je nepoznáte, ale můžete je identifikovat podle velikosti.
Možné potíže
Nejčastěji, pokud vám to nefunguje, jste se spletli v nějakém jménu. Výše uvedené kroky na sebe navazují a obvykle v jednom vytvoříte a pojmenujete něco, co v dalším kroku využijete. Pokud vám jména z obou kroků nesouhlasí, tak nastane problém. Bohužel většina kroků i při špatně zadaných jménech nic nezahlásí, ale chyba se objeví až při práci se soubory (migraci nebo pokusu o uložení prvního souboru).
Jednou z potíží, na kterou můžete narazit, je skutečnost, že pravděpodobně existuje chyba v .NET frameworku 2.0. Píše o ní toto KB. Jde o to, že pokud máte webové servery s SharePointem na jiné verzi operačního systému než na které máte SQL (typicky Windows 2008 a Windows 2008 R2), tak se máte problém. Ten se projevuje následovně: Při pokusu o uložení souboru většího než přibližně 1,2MB dojde k chybě s tím, že dokument nelze najít a byl pravděpodobně smazán. V prohlížeči událostí pak objevíte hlášku: "Either a required impersonation level was not provided, or the provided impersonation level is invalid". U menších souborů, nebo stejných verzích OS, se to nestane. Jádro pudla je v tom, že RBS má na straně SharePointu zabudovanou rozdvojku. V případě menších souborů se čtení/zápis jejich obsahu provádí pomocí SQL příkazů a tedy pomocí standardních (a už otevřených) SQL spojení. V případě větších souborů se obsah čte a zapisuje pomocí SqlFileStreamu. A tady nastává zádrhel, který se ale projeví jen pokud jsou různé verze OS. MS vydal hotfix (zmiňují se o něm v tom KB), ale mně se ho nepodařilo na Windows 2008 nainstalovat. Jediným řešením potom je uprgrade webfrontendových serverů na Windows 2008 R2. A nebo RBS nepoužívat. Důvodem té rozdvojky je fakt, že otevření nového streamu něco zabere (v porovnání s využitím už otevřených SQL spojení). Samotné čtení je pak sice rychlejší, ale v MS usoudili, že teprve od 1,2MB se režie s otevíráním streamu vyplatí.
|
-
Tak tahle "zajímavá vlastnost" mě stála dost nervů. Objevuje se u webů vytvořených ze šablony centra schůzek a projevuje se tak, že uživatelé nemohou přecházet mezi jednotlivými konáními schůzek. Při zapnutém logování chyb v prohlížeči nejprve zjistíte, že v JavaScriptovém kódu dojde k chybě, že není definována proměnná g_instanceId.
Tu "zajistíte" tak, že masterpage, kterou používá postižená stránka, rozšíříte. Moje centra schůzek byla odvozena od standardní masterpage pro centra schůzek mwsdefaultv4.master. Přidejte do záhlaví:
<%@ Register Tagprefix="Meetings"
Namespace="Microsoft.SharePoint.Meetings"
Assembly="Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral,
PublicKeyToken=71e9bce111e9429c" %>
a potom někam dovnitř elementu BODY:
<Meetings:PropertyBag runat="server"/>
Nyní se objeví chyba o tom, že není definována proměnná g_thispagedata. Proto musíte opět dovnitř elementu BODY (nejlépe za element Meetings:PropertyBag) přidat:
<script type="text\javascript">if(typeof(g_thispagedata)=="undefined") g_thispagedata="";</script> Bohužel spravení masterpage u jednotlivých existujících center schůzek je jen řešení následků. Proto, aby se i nová centra schůzek vytvářela se správnou masterpage, je nutné opravit i výchozí definici. Tu najdete na disku v adresáři: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\GLOBAL
Tato chyba se už vyskytovala ve WSS 3.0 a měla být odstraněna. Bohužel evidentně není. :( Možná bude opravena v blížícím se SP1, který by měl být uvolněn koncem června.
|
-
Jedním z mnoha vylepšení SharePointu 2010 je možnost definovat upozornění nad seznamy pomocí SMS. Nastavení je vidět zde: 
K tomu, aby to fungovalo je potřeba nastavit SMS bránu, přes kterou se budou SMS upozornění odesílat. Toto nastavení se provádí v centrální administraci. Lze ho definovat na úrovni celého SharePointu nebo na úrovni jednotlivých webových aplikací. 
Microsoft definoval rozhraní webové služby které implementují jednotlivý poskytovatelé. Seznam poskytovatelů SMS bran, které je schopen SharePoint použít naleznete zde. Mimochodem, je to stejný seznam na který vás odkáže Outlook 2010, když se začnete zajímat o možnost odesílat SMS zprávy z něj. Využívá totiž stejné rozhraní. Odesílat SMS umí i Outlook 2003 a 2007, je ale potřeba do nich nainstalovat addin a mít připojený GSM modem.
Aby jste si to mohli vyzkoušet, musíte si vybrat poskytovatele a vytvořit si testovací účet. U většiny z nich to lze. Nenašel jsem mezi nimi nikoho z Čech. Ceny za odeslání jedné SMS se pohybují něco přes 0,05 Eura tedy cca 1,2Kč. To mi připadá poměrně dost, ale co se dá dělat.
Poté, co to nastavíte, můžete se pustit do odesílání upozornění nebo zpráv z Outlooku 2010.
|
-
Nedávno jsem narazil na další zvláštní věc. Tentokrát se to týká skupin v SharePointu a systémového účtu. To je virtuální účet s loginem SHAREPOINT\system a SharePoint ho používá vždy, když nedokáže použít identitu nějakého konkrétního uživatele. Například pokud job provede změnu položky, je ve sloupci Změnil uveden právě systémový účet. Komplikace nastanou v situaci, kdy job vytvoří skupinu. Standardní chování SharePointu totiž je, že při vytvoření skupiny do ní automaticky přidá uživatele, který skupinu vytvořil. V jobu tedy do ní přidá právě systémový účet. Bohužel ale tento účet v ní není pomocí uživatelského rozhraní vidět. Nedá se z ní tedy ani odstranit. To se dá jen pomocí programového kódu. To bohužel není všechno.
V mém konkrétním případě se tento problém projevil následovně: Uživatelé spouštěli standardní schvalovací workflow a zadali do něj skupinu. Tato skupina byla vytvořena jobem. Workflow vygenerovalo úkoly pro jednotlivé členy zadané skupiny včetně systémového účtu. Schvalovací workflow běží tak dlouho, dokud se nevyjádří všichni oslovení lidé. A právě ten systémový účet to ne a ne udělat.  Když jsem ale kontroloval pomocí webového rozhraní, kdo v té skupině je, tak tam systémový účet nebyl vidět. To, že tam opravdu je, bylo vidět až v kódu.
|
-
Team Foundation Server (dále jen TFS) 2010 je serverový produkt pro podporu týmového vývoje aplikací. Využívají ji především vývojáři a jejich manažeři ke:
- správě procesu vývoje aplikací podle několika metodik
- sdílení, verzování a správu zdrojových kódů
- správě dokumentů vztahujících se k projektu (dokumentace, zadání,...)
- evidenci a správě chyb, testů,...
a k spoustě dalších věcí. Z technologického pohledu se TFS skládá z několika částí:
- Jádro TFS - správa zdrojových kódů, procesů, chyb, ...
- Webové portály projektů - umožnuje s projekty a jejich agendami pracovat pomocí webového rozhraní. Vhodné pro lidi, kteří s projekty spravovanými prostřednictvím TFS nepracují pomocí Visual Studia. Tato část je realizována pomocí SharePointu a lze ji instalovat samostatně. Existují 2 varianty:
- TFS si webové portály spravuje sám
- TFS vytváří webové portály projektů na existujícím SharePointu
- Reporting k projektům - součástí projektů jsou i sestavy pro ReportServer. Lze si definovat i další. Sestavy jsou také využívány webovými portály k zobrazení některých údajů (např. graf počtu nalezených chyb v čase). K využití reportů je potřeba SQL serveru s rozchozenými Reporting Services, které nejsou provozovány v režimu integrace s SharePointem
- Build služba - touto částí se realizují automatické překlady zdrojových kódů projektů. S ohledem na to, že překlady rozsáhlých projektů mohou běžet dlouho a jsou náročné na zdroje, je možné tuto část taky provozovat odděleně.
V plné variantě tedy může nasazení TFS 2010 vypadat nějak takto:
Ke správě TFS 2010 se používá Team Foundation Server Administration Console.
Dále se budeme věnovat následujícím scénářům:
- TFS využívá k hostování webových portálů projektů existující SharePoint 2010
- SharePoint 2010 a TFS 2010 fungují samostatně, ale uživatelé SharePointu mají možnost zobrazit si některá data z TFS případně do něj i něco vkládají.
TFS 2010 a SharePoint 2010
Bohužel musím hned na úvod napsat 3 důležité věci:
- Některé věci z portálů TFS 2010 fungují jen ve WSS 3.0, tedy v předchozí verzi SharePointu.
- Pokud se rozhodnete nainstalovat TFS 2010 na Windows 7, integrace s SharePointem není možná (TFS si spravuje portály projektů sám). Tato část se neobjeví v možnostech instalace a to ani v případě, že máte na dotyčném stroji rozběhnutý SharePoint 2010. Toto upozornění se týká především testování a zkoumání TFS 2010. V reálném nasazení tato varianta podle mě nepřipadá v úvahu.
- TFS je jen v angličtině, takže z českého SharePointu bude poněkud "trčet".
Postup integrace:
- Nainstalovat anglický LanguagePack na SharePoint. Toto je nutné, protože šablony webů TFS projektů jsou anglické.
- Nainstalovat Extension for SharePoint products and technologies na SharePoint server. Použijete instalační medium TFS 2010 a vyberete ze stromu částí TFS odpovídající uzel. Nainstalují se tím potřebné šablony webů a webparty.
- Nakonfigurovat SharePoint. Vytvořte spravovanou cestu, kterou bude TFS následně využívat pro zakládání webů projektů. Toto se definuje v centrální administraci na úrovni webové aplikace.
- Na TFS server nainstalovat TFS 2010. Opět použijete instalační medium TFS. Tentokrát nainstalujete ostatní komponenty. Doporučuju mít dopředu připravený doménový účet, pod kterým poběží služba TFS. Na závěr instalace se spustí průvodce konfigurací.
- Nakonfigurovat TFS 2010. Pomocí průvodce po instalaci (musíte zvolit advanced variantu, abyste mohli nastavovat SharePoint záležitosti), nebo později pomocí Team Foundation Server Administration Console vytvoříte SharePoint aplikaci.
- Dokonfigurovat SharePoint - Pomocí TFS extension manažeru na SharePoint serveru povolíte vytváření webů dotyčnému TFS.
- Pomocí stejného nástroje nakonfigurujete TFS kolekci tak, aby vytvářela weby projektů v určeném SharePointu
Weby projektů obsahují mnoho předkonfigurovaných webpartů. Některé z těchto webpartů jsou ve funci Visual Studio Team System Web Part Collection na úrovni kolekce webů a lze je provozovat i na jiných webech. Jsou to:
- Completed Builds
- Go To Work Item
- New Work Item Shortcuts
- Project Portal Links
- Query Results
- Recent Check-ins
- Team Web Access Shortcut
- Work Item Summary
Další (všechny dashboardy) jsou obsaženy v následujících funkcích webů:
- Agile Dashboards
- Agile Dashboards with Basic Reporting
- Agile Dashboards with Excel Reporting
- CMMI Dashboards
- CMMI Dashboards with Basic Reporting
- CMMI Dashboards with Excel Reports
Tyto funkce lze ale aktivovat pouze na webech projektů. Na jiných webech se bohužel aktivovat nedají. Na webech projektů jsou aktivovány automaticky při vytvoření projektu, která funkce se aktivuje je dáno použitou metodikou vývoje a tím, jak je nakonfigurováno reportování v TFS.
Pokud chcete TFS 2010 a SharePoint provozovat samostatně, ale nechcete přitom ochudit uživatele SharePointu o možnost spolupráce s TFS, tak můžete udělat následující kroky:
- Nainstalovat podporu TFS 2010 na SharePoint. Nemusíte instalovat LanguagePack, protože v tomto scénáři budeme používat pouze webparty a ty nejsou vázané na jazykovou verzi.
- Na straně TFS přidat účet, pod kterým běží SharePoint, do skupiny na TFS, která má oprávnění "Make requests on behalve of others", ideálně do skupiny SharePoint web application services. Toto provedete na úrovni Application Tier pomocí akce Administer Security.
- Aktivovat funkci Visual Studio Team System Web Part Collection.
- Na vámi zvolenou stránku umístíte a nakonfigurujete požadovaný webpart. Ať už zvolíte jakýkoliv, budete muset zadat odkaz na TFS a kolekci, se kterou má webpart pracovat.
Závěr
SharePoint 2010 a Team Foundation Server 2010 se dají integrovat ve dvou úrovních:
- TFS si spravuje weby projektů sám a SharePoint pomocí webpartů přistupuje k informacím v TFS uloženým
- TFS využívá SharePoint jako hosta webů projektů. Z jiných webů se k informacím na TFS části dá přistupovat pomocí webpartů zmíněných v předchozím bodě.
Integrace TFS 2010 a SharePointu má smysl v tom, že pokud je SharePoint používán jako firemní intranet nebo manažerský nástroj, lze informace, jeho pomocí přístupné, rozšířit o informace uložené v TFS. Manažeři (ale i jiní nevývojářští pracovníci) si mohou klíčové parametry projektů (např. počet evidovaných chyb,...) zobrazit ve známém prostředí bez nutnosti instalovat Visual Studio.
V jiném scénáři může být užitečná možnost upravovat portály projektů a dále je rošiřovat svými komponentami,... . Pokud si weby spravuje sám TFS, je tato možnost silně omezena.
Obecně mě mrzí, že informace v TFS nejsou ukládány v SP přímo (s vyjímkou dokumentů), ale jsou dostupné jen pomocí speciálních webpartů. Kdyby tam byly přímo, daly by se nad nimi spouštět workflow, vytvářet vazby s dalšími informacemi v SharePointu evidovanými. Např. si dovedu představit, že by existovala evidence obch. partnerů, zakázek a tyto zakázky by měly vazbu na projekty evidované v TFS. Tím by se dala propojit obchodní část projektu s jeho technickou realizací. Jinak se tyto informace evidují na 2 místech. Taky je škoda, že se dashboardy nedají použít na jiných než na projektových webech vytvářených TFS.
|
|
|
|