Novou vlastností MS SQL 2008 R2 je možnost zpracovávat reporty nad daty uloženými v seznamech SharePointu (2007 i 2010). Jak to udělat můžete vidět například na webu MSTV. Já jsem šel o něco dál. Zprovoznil jsem následující sestavu: SQL Server 20087 R2 + Reporting Services v tzv. integrated módu a SharePoint 2010 jako úložiště reportů a místo jejich zobrazení.

Integrace Reporting Services a SharePointu 2010

Postupoval jsem následovně:

1. Nainstaloval jsem SQL server 2008 R2 včetně Reporting Services (dají se doinstalovat dodatečně). V instalačním kroku, který se týkal konfigurace reporting Services jsem zvolil možnost, že je nebudu konfigurovat nyní. Další 2 možnosti byly: Native mode (weby pro správu a zobrazování reportů si spravují Reporting Services samy) a Integration Mode (integrace s SharePointem, to je sice můj cíl).
2. Nainstaloval jsem SharePoint 2010 a pro uložení databáze jsem využil SQL server z kroku 1.
3. Pomocí ReportingServices Configuration Management nástroje jsem:
1. určil účet, pod kterým má služba Reporting Services běžet. Použil jsem stejný účet, pod kterým běží SQL server.
   
2. vytvořil databázi Report Serveru
3. nastavil web service URL a Report Manager URL vytvořením webových aplikací na IIS serveru nainstalovaném na stejném stroji jako ten SQL
4. nakonfiguroval Reporting services do Integrated modu.
4. Na SharePoint 2010 jsem nainstaloval SQL Server 2008 R2 Reporting Services Add-in for Microsoft SharePoint Technologies 2010. Ten vám umožní konfigurovat nastavení spolupracujících Reporting services, ale také nainstaluje webpart pro zobrazení reportů (Report Viewer) a typy obsahů věcí využitelných v reportech (Report Builder Model a Report Data Source) a pro reporty samotné (Report Builder Report).
5. Aktivoval jsem vlastnosti Report Server Integration Feature a Report Server Central Administration Feature na webu centrální administrace
   
6. Provedl jsem konfiguraci na straně SharePointu v administračním webu (v sekci General Application Settings):
• Integrate a Report Server - sem jsem vložil jméno serveru hostujícího reporting services a určil jméno instance. To umožní report serveru přístup k databázi SharePointu, aby mohl Report Server získat informace nutné zpracování reportů uložených v SharePointu (přístup k reportu samotnému, ke sdíleným datovým zdrojům a datasetům).
  
• Reporting Services Integration - na této stránce jsem nastavil web service URL report serveru z bodu 3.3. Taky je zde potřeba určit pod jakým účtem se bude přistupovat Report Serveru. Můžete určit konkrétní účet, nebo povolit windows autentizaci. Druhá možnost naráží na omezení NTLM (více v kapitole Bezpečnost při zobrazení reportů).
  
• Reporting Services Server Defaults - zde jsem jen zkontroloval a nechal jsem výchozí hodnoty. Nastavují se zde věci jako timeout, možnost stažení Report Builderu... Ty se dají ovlivnit na úrovni jednotlivých webů SharePointu.
  
7. Vytvořil jsem knihovnu pro datové zdroje a přiřadil jsem k ní typy obsahu Report Builder Model a Report Data Source
8. Vytvořil jsem knihovnu dokumentů pro reporty a použil jsem v ní typ obsahu Report Builder Report.
9. Vytvořit jsem zkušební report - zkušenosti jsem shrnul v kapitole Vytváření reportů
   
10. Na, k tomu účelu vytvořenou, stránku umístit webpart pro zobrazení reportů (Report Viewer) a nastavil jsem jeho vlastnosti. Především jsem určil report, který se má zobrazit, a jeho parametry.

Bezpečnost při zobrazování reportů

Bezpečnost v reportech je komplikované téma. Je zde celá řada služeb a jejich účtů, které se v procesu generování reportu využívají. Pokud to zkombinujeme s SharePointem, je jich ještě o 1 více.

Navíc existují 2 základní scénáře pro informace zobrazené v reportu:

• Chci, aby report zobrazoval informace z dat, k nimž má práva uživatel, který si report prohlíží. Tento scénář se hodí tehdy, pokud chci mít 1 report, jehož výsledky jsou závislé na tom, jaká práva má uživatel v systému obsahujícím data. Např. report prodejů. Když si ho zobrazí obchodník, vidí report, ze svých prodejů. Když si ho zobrazí vedoucí obchodníků, který má právo číst data o prodejích jednotlivých obchodníků, vidí souhrnná data za všechny. K realizaci tohoto scénáře potřebuji, aby se identita koncového uživatele dostala až do systému obsahujícího zdrojová data.
• Chci, aby report zobrazoval informace z dat, ke kterým uživatel, který si report prohlíží, přístup nemá. V tomto scénáři chci zpřístupnit uživateli souhrnná data bez toho, aniž by měl uživatel přístup ke zdrojovým datům. Příkladem může být report dostupný všem obchodníkům, který zobrazuje klíčové ukazatele obchodního oddělení (např. sumu realizovaných prodejů), aniž by jednotliví obchodníci měli přístup ke všem údajům o prodejích. Řešením je použít vyhrazený účet, který je součástí definice datového zdroje použitého v reportu.

Obvykle se využívá druhého scénáře a to hned ze několika praktických důvodů:

1. První scénář předpokládá, že systém, který report zobrazuje, je schopen předat identitu uživatele, který si report prohlíží, do Reporting Services. Ty pak následně musí být schopny použít tuto identitu tak, aby pod ní přistoupily ke zdrojovým datům reportu.
2. V systému, který obsahuje zdrojová data pro report musím řídit přístup jednotlivých uživatelů reportu. To obvykle bývá spojeno s velkou administrativní náročností, a proto se nejčastěji založí 1 účet, který má přístup k datům potřebným k vygenerování příslušného reportu a práva jednotlivých uživatelů se neřeší. Navíc často systémy používají vlastní systémy identit.
3. MS SQL, jako nejčastějším zdroji dat pro Reporting Services, neumí řídit přístup k jednotlivým řádkům tabulek. Umí řídit přístup pouze k celým tabulkám a sloupcům v nich. Protože ale reporty obvykle zobrazují data z konkrétních tabulek a jejich sloupců, tak se skutečnost, že k nim daný uživatel nemá práva, projeví nejčastěji tak, že report nejde vygenerovat. Tudíž nemá smysl práva pro jednotlivé uživatele řešit.
4. NTLM, což je standardní autentizační protokol používaným při Windows autentizaci, neumí delegovat bezpečnostní token dále (a tedy neumí předat identitu uživatele předat dále, viz. bod 1).

Pokud ale zdrojem dat pro report je SharePoint, tak nám odpadají důvody č. 2 a 3. Stále nám ale zbývají body 1 a 4 byť spolu souvisí. Řešením je využití autentizačního protokolu Kerberos. Pár detailů můžete najít např. zde. Blíže si o něm a jeho zprovoznění v SharePointu, Reporting Services, MS SQL povíme jindy.

Vytváření reportů

Při vytváření reportů hostovaných v SharePointu a pracujících s daty z SharePointu jsem narazil na následující komplikace:

• Visual Studio 2008 neumí vytvořit report založený na SharePoint datech. Je to proto, že nepodporuje dotyčný datový zdroj. To se dá obejít tím, že jako zdroj použijete webovou datovou službu http://server/_layouts/lists.asmx. Použití WCF jako zdroje dat ale má problém v tom, že neumožňuje zadat uživatelský účet, pod kterým má být přístup k datům (volání webové služby) proveden. Jedinou možností je Windows autentizace, nebo přístup bez hesla. Problém použití Windows autentizace je diskutován výše (bez rozchozeného Kerbera je to k ničemu).
• Visual Studio 2010 se sice tváří, že vytvářet reporty založené na datech v SharePointu umí, ale díky chybě, kterou obsahuje, to neumí. Problém je v tom, že sice mezi datovými zdroji SharePoint je, ale kliknutím na tuto možnost se vám zobrazí stejný dialog, jako při konzumaci dat z webové službu.
• Jedinou fungující možností tedy je použít Report Builder 3.0, ale ani s ním to není bez komplikací. S jeho pomocí se nedají vytvářet sdílené datové zdroje. Dají se vytvářet pouze zdroje lokální (jsou součástí reportu), nebo konzumovat sdílené. Sdílené datové zdroje a datasety, jsou takové, které nejsou součástí reportu, ale jsou uloženy samostatně v knihovně dokumentů a report se na ně pouze odkazuje. Jejich použití je doporučené, protože je můžete použít v několika reportech a případnou změnu související s přesunem datového zdroje provedete jen jednou. Navíc můžete řešit práva přístupu k jednotlivým zdrojům dat. Sdílené zdroje dat můžete vytvářet prostřednictvím UI SharePointu pomocí typu obsahu Report Data Source.
  
• Konzumace dat z SharePointu je problematická, protože obvykle se v reportu zobrazují data z několika navzájem provázaných tabulek (v případě SharePointu seznamů nebo knihoven dokumentů). Spojení těch tabulek se ale realizuje na úrovni reportu obtížně a komplikovaně. Při přístupu k datům v SQL se to proto řeší obvykle tak, že report nepřistupuje přímo k jednotlivým tabulkám, ale k view, které spojení (join) provede na databázové úrovni. To však v případě dat pocházejících z SharePointu nelze, protože není jak definovat SharePointí ekvivalent onoho view.