Suche

Freitag, 17. Juni 2011

Überblick PerformancePoint Services - SharePoint 2010

Wie ich in einem meiner vorherigen Posts erwähnt habe, wollte ich mich noch einmal zu dem Thema PerformancePoint Services äußern und meine Erfahrungen an die Aussenwelt kommunizieren. Da dies eine wirklich breit gefächerte Thematik ist und auf die unterschiedlichsten Daten zugreifen kann, würde ein einzelner Post entweder zu lang werden oder aber es würden viele Informationen verloren gehen. Daher habe ich mich dazu entschieden, das Ganze in ein paar kleinere Posts zu splitten (aufgrund meiner derzeitigen Projektauslastung kann es eventuell mal etwas länger dauern).

Den Anfang macht man natürlich mit einer Übersicht. Ich werde also in diesem Post die PerformancePoint Services beschreiben und Euch einen Überblick darüber verschaffen, was die PerformancePoint Services überhaupt darstellen. Meine Informationen habe ich der msdn entnommen bzw. basieren Sie auf eigenen Erfahrungen.



Was sind PerformancePoint Services (PPS)
Generell kann man sagen, dass die PPS ein Tool zur Überwachung und zum Analysieren von Daten sind. Die PerformancePoint Services gibt es bereits seit der 2007er Version, wo Sie jedoch noch als ein eigener PerformancePoint Server 2007 eingesetzt wurden. In der SharePoint 2010 Version wurden die PPS direkt in den SharePoint Server integriert. Die PPS stehen jedoch nur in der Enterprise Edition zur Verfügung. Die Funktionalität wurde im Gegensatz zur alten Version verbessert und erweitert. Mit den PPS wird es den Anwendern möglich gemacht Geschäftsentscheidungen, Analysen und Überwachungen der Kennzahlen durchzuführen. Als Hilfsmittel dienen hier die zur Verfügung gestellten
  • ·         Dashboards
  • ·         Scorecards
  • ·         KPIs
  • ·         Reports
  • ·         Diagramme.

Ohne Daten nutzen einem diese Hilfsmittel natürlich nichts, daher unterstützen die PerformancePoint Services eine Reihe an möglichen Datenquellen. Auf die Implementierung dieser Datenquellen werde ich in einem der nächsten Posts drauf eingehen. Eins werde ich jedoch jetzt schon erwähnen. Um aussagekräftige und optimal nutzbare Auswertungsmöglichkeiten zu erzielen ist es vorzuziehen, dass man die SQL Server Analysis Services als Datenherkunft einsetzt. Die insgesamt zur Verfügung stehenden Datenquellen sind folgende:
  • ·         SharePoint-Listen
  • ·         Excel Services
  • ·         SQL Server
  • ·         SQL Server Analysis Services

Wie bei allen anderen Auswertungen/Analysen/Berichten ist man auch bei den PPS auf eine zuverlässige Datenqualität angewiesen, denn ohne korrekte Daten helfen auch die besten Tools nicht weiter.

Wie funktionieren die PerformancePoint Services
Die PerformancePoint Services sind eine SharePoint 2010 Server-Dienstanwendung. Datenquellen und  Dashboards werden in Dokumenten-Bibliotheken gespeichert, während alle anderen Dashboard-Inhalte in Listen abgelegt werden. In der folgenden Abbildung (Quelle: http://technet.microsoft.com/de-de/library/ee890835.aspx) wird einmal die Architektur und Funktionsweise der PerformancePoint Services in einer 3-Server-Farm dargestellt:



Wie man hier erkennen kann haben wir hier ein Zusammenspiel von unterschiedlichen Features, wie z.B. Microsoft Office Excel oder auch der Dashboard Designer. Der Dashboard Designer ist eine Click-Once-Anwendung, die beim ersten Gebrauch der PPS heruntergeladen und auf dem Client ausgeführt wird. Die Handhabung des Dashboard Designers folgt in einem der nächsten Posts. Die Datenquellen werden hier auch noch einmal dargestellt.

Das Sicherheitsmodell der PerformancePoint Services
Wenn es im Unternehmen um Daten geht kommt immer auch die Frage von einem Sicherheitskonzept auf. Wie verhält es sich bei den PerformancePoint Services? Die PerformancePoint Services speichern die Objekte in Dokumenten-Bibliotheken und Listen ab, somit werden die Daten durch das Sicherheitsmodell des SharePoint Server geschützt. Die folgenden Punkte sollte man der Nutzung der PerformancePoint Services beachten und planen:
  • ·         verschiedenen Methoden für die Authentifizierung
  • ·         Vertrauenswürdige Speicherorte
  • ·         Vertrauenswürdige Dateninhaltsbibliotheken
  • ·         Vertrauenswürdige Listen für Dashboard-Inhalte
  • ·         Datenquellensicherheit
  • ·         Secure Store Service und unbeaufsichtigte Dienstkonten
  • ·         Forderungsbasierte Authentifizierung

Weiterführende und detaillierte Informationen findet Ihr auf http://technet.microsoft.com/de-de/library/ee748637.aspx.

Um einen ersten Überblick der PerformancePoint Services zu erlangen, sollte es erst einmal reichen. In weiteren Posts werde ich dann auf die Handhabung und Erstellung von Dashboards mit dem Dashboard Designer eingehen.

Viele Grüße...
Patrick

Mittwoch, 15. Juni 2011

Erstellen einer Inhaltsdatenbank mit dazugehöriger Webseitensammlung

Heute habe ich bei meinen Kollegen mitbekommen, dass Sie eine neue Webseitensammlung (Site-Collection) mit einer eigenen Inhaltsdatenbank (Content Database) anlegen mussten. Ich habe es so wahrgenommen, dass dieses Szenario über die UI doch etwas umständlich ist. Da ich in letzer Zeit immer mehr Begeisterung für PowerShell empfinde, habe ich mich doch einfach daran gemacht und das folgende Script angefertigt :-)

# Enter your SQL Server Instance
$SQLServer = 'SPS2010SQLServer'
# This variable stores your content-database
$contentDB = 'SP_2010_Content_DB'
# Here you have to enter the URL of your webapplication
$SPWeb = 'http://SharePoint2010'
# Enter the URL of your new site-collection
$SPSite = 'http://SharePoint2010/websites/newSiteCollection'
# Please enter here your primary site-collection administrator
$SPSiteAdmin = 'Domain\SP_Admin'
# Enter your primary language (1031 = German)
$LanguageID = '1031'
# You although can specify the template for this site-collection (STS#1 = blank)
$SPTemplate = 'STS#1'
# This statement creates the new content-DB
New-SPContentDatabase -Name $contentDB -DatabaseServer $SQLServer -WebApplication $SPWeb
# Creates the new Site-Collection on the specified Content-Database
New-SPSite -URL $SPSite -OwnerAlias $SPSiteAdmin -ContentDatabase $contentDB -Language $LanguageID -Template $SPTemplate


Viele Grüße,
Patrick

Benutzer einer SharePoint-Gruppe auslesen (Data One Power Activity for Nintex Workflow)

Ich habe dieser Tage ein kleines Problem mit der Nintex-Aktivität << Data Request >> gehabt. Derzeit ist es leider nur möglich dieser Aktivität einen Benutzer zuzuweisen. Was nun aber tun, wenn mehrere Benutzer diese Dateneingabe vornehmen sollen. Man kann das Ganze umgehen, indem man eine neue SharePoint-Gruppe anlegt und die Benutzer in dieser Gruppe einpflegt.
Hier bin ich dann jedoch auf das nächste Problem gestoßen. Die SharePoint-Gruppe wird nicht aufgelöst, so dass die Aufgabe nicht in den Nintex-Webpart << Meine Workflowaufgaben >> angezeigt wird. Ich habe mir nun Gedanken über eine mögliche Lösung gemacht und bin zu folgendem Ergebnis gekommen.

Schritt 1: SharePoint Webservice
Auslesen der SharePoint-Gruppe mit dem SharePoint Webservice (http://sharepoint/_vti_bin/UserGroup.asmx) und der Methode << GetUserCollectionFromGroup >>. Als Ergebnis bekommen wir folgendes XML-Konstrukt (aus Darstellungsgründen habe ich es auf den LoginName beschränkt):


<GetUserCollectionFromGroup xmlns="http://schemas.microsoft.com/sharepoint/soap/directory/">
   <Users>
        <User  LoginName="Domäne\ps_test"  />
        <User  LoginName="Domäne\tk_bpmhelp" />
        <User  LoginName="Domäne\tk_discmanager"  />
   </Users>
</GetUserCollectionFromGroup>

Schritt 2: Auslesen mit PowerShell
Für die weitere Vorgehensweise werden die einzelnen Benutzer (in diesem Fall der LoginName) benötigt. Das Auslesen der Benutzer habe ich mit der Powershell realisiert. Die meisten werden nun fragen, wie kann ich Nintex Workflow in Verbindung mit der PowerShell nutzen? Ganz einfach, man benutzt die  << Data One PowerActivity for Nintex Workflow >>. Das folgende Script liest die einzelnen Benutzer aus und speichert Sie in einer ArrayList. Das Ergebnis wird dann einer Nintex-Collection-Variablen übergeben und man hat nun die Möglichkeit auf die einzelnen Benutzer dieser SharePoint-Gruppe zuzugreifen.


# path to the xml-file
$InputXML = 'C:\Users\ps\Desktop\UserGroup.xml' 
# get the content from the xml-file
$xml = [xml](Get-Content -Path $InputXML)
# create a variable of type System.Collections.ArrayList
$users = new-object 'System.Collections.ArrayList'
# iterate through the xml-file and get all users of the SharePoint-Group
$xml.GetUserCollectionFromGroup.users.user | foreach { 
$users.Add($_.Loginname)
}


Schritt 3: Zuweisen << Data Request >> an die Benutzer
Damit die Benutzer nun Ihre Aufgaben auch im Webpart << Meine Workflowaufgaben >> sehen können, muss jedem Benutzer ein << Data Request >> zugewiesen werden. In der Collection-Variable, die zuvor in der << Data One PowerActivity >> gefüllt wurde, sind alle Benutzer der SharePoint-Gruppe enthalten. Für jeden Eintrag wird ein << Data Request >> gestellt. Nun müssen wir noch die Abarbeitung der restlichen Aufgaben realisieren, wenn jemand seine Eingabe getätigt hat. Die << Data Request >> Aktivität hat derzeit leider nicht die Möglichkeit, dass man in der Konfiguration angeben kann, dass die erste Antwort zählt (wie man es z.B. vom Flexi-Task gewöhnt ist). Man muss sich die Action-ID's der einzelnen Aufgaben speichern und kann hiermit dann die noch offenen Aufgaben abschließen.

Die Lösung ist zwar nur suboptimal, aber man kann damit arbeiten und diese Aktivität auch mit mehreren Usern nutzen. Ich hoffe, dass in einem der nächsten Releases dieses Feature implementiert sein wird.

Viele Grüße,
Patrick