In meinem letzten Blogpost habe ich gezeigt, wie einfach man die SharePoint-Oberfläche verändern kann und einen Hyperlink in das SiteActions-Menü integriert. Dies ist auch umgekehrt möglich, d.h. es können nicht nur neue Einträge hinzugefügt, sondern auch Vorhandene entfernt werden, um gezielt Bereiche oder Funktionalitäten für den Webanwender unerreichbar zu machen.
In diesem Beitrag wird an einem Beispiel erläutert, wie es möglich ist, einen Bereich (Gruppe “CustomizeList”) innerhalb des SharePoint Standard Ribbons (Menübandes) komplett auszublenden. Dies kann über verschiedene Wege erreicht werden: a) deklarativ mittels Custom Action, b) als User Control (.ascx) mit serverseitigem Code oder c) via CSS in der ASPX-Seite oder Masterpage. Hinweis: Die Struktur des Ribbons (inkl. aller Gruppen und Buttons) ist in der XML-Datei C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\TEMPLATE\GLOBAL\XML\CMDUI.XML deklariert (Link bezieht sich auf SharePoint 2010, für SharePoint 2013 ist im Pfad statt der Versionsnummer 14 die 15 zu verwenden). Aus dieser XML-Datei lassen sich die Bezeichnungen/IDs jedes Ribbon-Eintrags finden.
Folgende Bilder zeigen das originale Ribbon des Beispielszenarios vor der Änderung und das angepasste Ribbon, ohne die Gruppe “Customize List” nach der Änderung.
Hide Custom Action
Zunächst ist in Visual Studio ein neues leeres SharePoint-Projekt anzulegen.
Anschließend wird ein neues Feature hinzugefügt im Solution Explorer über Rechtsklick auf den “Feature” Ordner –> Add Feature. Dieses sollte am besten direkt entsprechend aussagekräftig benannt werden (per Doppelklick auf das Feature öffnet sich der Feature Designer).
Nun kann die eigentliche Custom Action hinzugefügt werden. Rechtsklick auf den fettgedruckten SolutionName –> Add –> New Item –> Empty Element.
In der neu angelegten Elements.xml muss nun folgender Code eingefügt werden:
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<CustomAction Id="RemoveCustomizeListGroup" Location="CommandUI.Ribbon">
<CommandUIExtension>
<CommandUIDefinitions>
<CommandUIDefinition Location="Ribbon.List.CustomizeList" />
</CommandUIDefinitions>
</CommandUIExtension>
</CustomAction>
</Elements>
Anschließend kann die Solution getestet und deployt werden. Nach erneutem Refresh der Listenansicht haben sich die Änderungen direkt ausgewirkt.
User control (Server Code)
Auch hier ist zunächst in Visual Studio ein neues leeres SharePoint-Projekt anzulegen.
Die Assemply “Microsoft.Web.CommandUI.dll” muss als Referenz hinzugefügt werden. References –> Add –> Browse –> C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\14\ISAPI
Nun muss ein User Control (*.ascx) hinzugefügt werden via Solution Explorer –> Add –> New Item –> User Control (ascx).
Im Solution Explorer taucht nun ein sogenannter mapped folder, der Ordner “ControlTemplates” mit einem Unterordner mit dem SolutionName auf. Darin Liegt die ascx-Datei und darunter eine .cs Datei (C#).
In dieser Code behind Datei wird nun in der Page_Load Methode folgendes Codesnippet eingefügt:
SPRibbon ribbon = SPRibbon.GetCurrent(this.Page);
if (ribbon != null)
{
ribbon.TrimById("Ribbon.List.CustomizeList");
}
Damit die SPRibbon-Klasse verwendet werden kann, muss noch eine Referenz inkludiert werden:
using Microsoft.SharePoint.WebControls;
Jetzt kann die Solution deployt werden.
Um das Control verwenden zu können, muss es an entsprechender Stelle (in einer aspx-Seite oder der Masterpage) eingebunden werden. Dazu z.B. im SP Designer die Masterpage öffnen und oben im <Register…> Bereich die Referenz setzen mittels:
<%@ Register TagPrefix="HRB" TagName="HideRibbonButton" src="~/_controltemplates/HideRibbonButtonUserControlSolution/HideCustomizeListGroup.ascx" %>
Anschließend kann das Control z.B. direkt zu Beginn des Body-Bereichs eingebunden werden:
<HRB:HideRibbonButton id="HideRibbonButton" runat="server"></HRB:HideRibbonButton>
Die Änderungen der Masterpage sollten dem folgenden Bild entsprechen:
Jetzt kann die Masterpage gespeichert werden. Nach erneutem Refresh der Listenansicht im Browser ist der “CustomizeList” Bereich im Ribbon verschwunden.
CSS
Diese Methode ist recht schnell umgesetzt, dazu muss die aspx-Page oder Masterpage zunächst mit einem Editor geöffnet werden (z.B. SharePoint Designer).
Nun wird im ASP-Code im Bereich <PageHead> einfach folgendes Script eingefügt. Kurzer Syntaxausflug: Die “\” sind wichtig, damit der Webserver die darauf folgenden Punkte nicht als CSS-Klassenselektor interpretiert – die CSS ID der Gruppe lautet nämlich “#Ribbon.List.CustomizeList”. Da das danach folgende “ms-cui-group” jedoch eine CSS-Klasse darstellt, steht dort davor kein “\”.
<style type="text/css">#Ribbon\.List\.CustomizeList.ms-cui-group{display:none;}</style>
Im Beispiel wurde die Standard Listenansicht (AllItems.aspx) angepasst, so dass sich die Änderung am Ribbon in dem Fall nur auf die bezogene Liste auswirkt.
Nachdem die Page gespeichert und die Listenansicht im Browser einmal aktualisiert wurde, sollten sich die Änderungen bereits ausgewirkt haben.
Eine Provider-hosted SharePoint App ist letztendlich eine normale Webanwendung, die mit WebForms oder MVC erstellt werden kann. Daher ist es nur eine Frage der Zeit, bis der Wunsch entsteht einen WEB-API-Controller zu schreiben und diesen in der App zu nutzen. Dieser Schritt ist noch simpel. Unlängst wollte ich aber in der Controller-Funktion die aktuell angemeldeten User ermitteln.
Eigentlich sind es nur drei Zeilen Code:
var user = ctx.Web.CurrentUser;
ctx.Load(user, u => u.LoginName);
ctx.ExecuteQuery();
Die Tücke steckt aber im SharePoint-Kontext. In meinem Fall die Variable “ctx”.
In einer normalen WebForm-Klasse kann der Kontext mit den mitgelieferten SharePoint-Kontextklassen leicht erstellt werden.
var spContext = SharePointContextProvider.Current.GetSharePointContext(Context);
using (var ctx = spContext.CreateUserClientContextForSPHost())
{
...
Leider stehen uns diese Klassen in einem API-Controller nicht zur Verfügung und Microsoft hat die mitgelieferten Klassen noch nicht aktualisiert. Aber was Microsoft nicht erledigt, übernimmt die Community.
Bas Lijten hat sich des Themas angenommen und unter http://blog.baslijten.com/getting-sharepoint-2013-apps-and-webapi-to-work/ ist seine Lösung nachzulesen. Er hat die SharePoint-Kontextklassen umgeschrieben, sodass diese auch in einem API Controller zur Verfügung stehen.
Mir waren es zu viele Dateien, die einzubinden sind, und daher habe ich alle Klassen in eine Datei kopiert. Die Datei kann hier heruntergeladen werden: Link zur Datei
Sobald diese Datei eingebunden ist und der Namespace in der Datei auf den Namespace der Anwendung gesetzt wurde, kann nun ein API Controller mit SharePoint-Kontext programmiert werden.
Die Klasse des Controllers muss mit dem Attribut “SharePointApiControllerContextFilter” versehen werden.
[SharePointApiControllerContextFilter]
public class QuartalTrainerController : ApiController
{
...
In der Methode des Controllers kann nun ein SharePoint Context gebildet werden und wie gehabt mit dem Client Object Model verwendet werden. Das Anfangsbeispiel, das Abfragen des aktuellen Users, sieht nun wie folgt aus:
public Goalsheet Get(string Quartal)
{
var spCtx = SharePointApiControllerContextProvider.Current.GetSharePointContext(this.ControllerContext);
using (var ctx = spCtx.CreateUserClientContextForSPHost())
{
var user = ctx.Web.CurrentUser;
ctx.Load(user, u => u.LoginName);
ctx.ExecuteQuery();
...
Der SharePoint 2013 hat im Zuge seines neuen, für mobile Endgeräte optimierten Looks den ein oder anderen Menüeintrag einbüßen müssen. So ist es beispielsweise nicht mehr möglich, direkt über das SiteActions-Menü (Zahnrad) eine neue Website anzulegen (Bild links). Dies dürfte der ein oder andere User vermissen, da nun das Anlegen nur noch über den “Umweg” im SiteContent-Bereich möglich ist. (Bild rechts).
Mit Hilfe einer Custom Action ist es jedoch ohne großen Aufwand möglich, diesen Menüeintrag auch in SharePoint 2013 zu implementieren. Dies beschreibt die folgende Anleitung:
Zunächst ist in Visual Studio ein neues leeres SharePoint 2013 Projekt (als Farm Solution) anzulegen.
Anschließend wird die Custom Action selbst hinzugefügt. Dies geschieht im Solution Explorer über Add –> New Item –> Empty Element. Mit dem Empty Element lassen sich sämtliche in XML definierte Inhalte bereitstellen. Nichts anderes ist eine Custom Action.
Also muss nun die XML wie folgt deklariert werden:
<?xml version="1.0" encoding="utf-8"?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<CustomAction
Id="CreateSite"
GroupId="SiteActions"
Location="Microsoft.SharePoint.StandardMenu"
Sequence="0"
Title="Create Site"
Description="Create Site Link" >
<UrlAction Url="~site/_layouts/15/newsbweb.aspx"/>
</CustomAction>
</Elements>
Die Properties Location und GroudId spezifizieren, dass der künftige Eintrag in der “SiteActions” Rubrik auftauchen wird. Weitere Informationen zu den möglichen Locations bietet Microsoft hier.
Nun kann noch das entsprechende Feature etwas aussagekräftiger benannt werden. Zum einen geschieht dies im Feature Designer (Doppelklick auf den Feature-Namen), zum anderen über das Umbenennen des Feature-Ordners im Solution Explorer (letzteres dient nur der besseren Übersichtlichkeit innerhalb des Solution Explorers, falls mehrere Features in der Solution liegen sollten).
Jetzt kann die Solution getestet und deployt werden. Schließlich sollte das SiteActions-Menü den folgenden neuen Link besitzen:
Über diesen Weg lassen sich übrigens auch beliebige weitere Hyperlinks in das SiteActions-Menü – oder andere SharePoint-Menüs - einbinden.
Machen Sie so etwas nie! Wenn Sie diese Meldung in Sharepoint 2013 bei den Office Web Apps bekommen oder etwa Access Services 2013 Lösungen nicht veröffentlichen können, dann steht vermutlich oben im Eck der Sharepoint-Seite:
SYSTEMKONTO
Der Fehler tritt auf, da die Office Web Apps beim SharePoint-Server einen Benutzertoken bei jeder Anforderung übergeben müssen. Jedoch erstellt SharePoint Server 2013 kein Benutzertoken für ein Systemkonto. Also auch kein Konto bzw. Token für die Office Web Apps.
Verwenden Sie ein anderes Konto und schon wird wieder alles funktionieren
Also liebe Installateure, die das DOM\Administrator-Konto für die Testfarm verwenden. Das steht auf den 10 Geboten für den Sharepoint Server ganz oben.
Nachzulesen unter: http://support.microsoft.com/kb/2761265/de
Die Office Web Apps Installation ist keine besondere Herausforderung bei der Installation. Lediglich ein Punkt ist mir immer wieder aufgefallen, auf den ich hier mal hinweisen möchte. Ein Punkt, der mir dann und wann auch unter Sharepoint 2013 und Sharepoint 2010 unter die Finger gekommen ist. Vermutlich kennen Sie den Gedankengang: “das kenn ich doch schon, aber was war das denn..?” Nun hier die Lösung schriftlich zum Nachlesen für die Nachwelt.
Fehler bei der Verwendung von Powershell
Problem mit der Powershell ”Die Benennung .. wurde nicht als Name eines Cmdlets, einer Funktion, einer Skriptdatei .. erkannt."
Simpler Grund: Die Powershell wird nicht in der korrekten Version ausgeführt. Sharepoint 2013 oder Office Web Apps erwarten die Version 3.0. Geladen haben Sie aber eventuell die Version 2.0. Wie kann man seine Version feststellen? Geben Sie dazu $PSVersionTable ein: Für Sharepoint 2013 bzw. Office Web Apps ist die hier genannte Version 2.0 nicht geeignet. Das können Sie ganz leicht beheben, indem Sie entweder in der Powershell die geforderte Version laden oder die Verknüpfung schlichtweg ändern:
Kleine Änderung, große Wirkung.
Office Web Apps sind sehr einfach zu installieren und haben nur wenige Stolperfallen. Gut ausgerüstet mit den richtigen Powershellskripten sind die Office Web Apps innerhalb von 15 Minuten inkl. Installation und Skripten funktionsfähig.
Welche Etappen haben wir dazu vor uns:
Vorbereiten des Office Web App Servers
Installation der Office Web Apps
Per PowerShell eine Office Web App Farm einrichten
Unsere SharePoint-Farm per PowerShell mit der Office Web App Farm verbinden
So und nun mal der Reihe nach:
Vorbereiten des Office Web App Servers
Office Web Apps benötigen einen eigenen Server. Das bedeutet: Windows Server 2008 R2 SP1 oder höher ohne Office 2013 und ohne SharePoint-Installation. Also ein wirklich nackter Server! Der SharePoint Designer 2013 zählt hier logischerweise mit als Office-Produkt. Auf dem Server müssen je nach Betriebssystem verschiedenste Dinge an Board sein:
Windows Server 2008 R2 Service Pack 1
.NET Framework 4.5
Windows PowerShell 3.0
Plattformupdate für Windows 7 SP1 und Windows Server 2008 R2 SP1 (KB2670838)
und eine Reihe von Features müssen aktiviert werden. An dieser Stelle verweise ich auf folgende Skripte, da sie alle notwendigen Features auf dem OS aktivieren:
Für Windows 2008:
Import-Module ServerManager
Add-WindowsFeature Web-Server,Web-WebServer,Web-Common-Http,Web-Static-Content,Web-App-Dev,Web-Asp-Net,Web-Net-Ext,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,Web-Security,Web-Windows-Auth,Web-Filtering,Web-Stat-Compression,Web-Dyn-Compression,Web-Mgmt-Console,Ink-Handwriting,IH-Ink-Support
Für Windows 2012
Add-WindowsFeature Web-Server,Web-Mgmt-Tools,Web-Mgmt-Console,Web-WebServer,Web-Common-Http,Web-Default-Doc,Web-Static-Content,Web-Performance,Web-Stat-Compression,Web-Dyn-Compression,Web-Security,Web-Filtering,Web-Windows-Auth,Web-App-Dev,Web-Net-Ext45,Web-Asp-Net45,Web-ISAPI-Ext,Web-ISAPI-Filter,Web-Includes,InkandHandwritingServices,NET-Framework-Features,NET-Framework-Core
Fertig mit Schritt 1
Nun kann die Installation der Office Web Apps folgen
Installation Office Web Apps
Gelinde gesagt, sieht dies so aus:
Falls hier jemand Probleme hätte, kann er sich gerne melden
Günstigerweise installieren Sie an dieser Stelle das SP1 der Office Web Apps. Oder wer das noch nicht einsetzen möchte, dann zumindest das Update http://support.microsoft.com/kb/2810007/de
Konfigurieren der Office Web App Farm
Nun wird die Farm erstellt. Sie müssen dazu die PowerShell verwenden und unter Umständen noch die Offce Web Apps-Module nachladen
Import-Module -Name OfficeWebApps
New-OfficeWebAppsFarm -InternalURL "http://servername" -AllowHttp –EditingEnabled
Wobei AllowHTTP ohne Zertifikate arbeitet und EditingEnabled eine Lizenzierung der Clients mit Office 2013 erfordert.
Wollen Sie die Farm per Zertifikat absichern und nach extern veröffentlichen, dann verwenden Sie folgendes Script:
New-OfficeWebAppsFarm -InternalUrl https://intern.firma.de -ExternalUrl https://extern.firma.de -CertificateName "OfficeWebApps Certificate" –EditingEnabled
Wobei CertificateName den Namen des Zertifikats darstellt.
Ob das erfolgreich war läßt sich ganz gut testen:
Rufen Sie im Browser folgende Adresse auf:
http://ServerName/hosting/discovery
Erfolg sieht so aus:
SharePoint-Server mit Office Web App Farm verbinden
Auf dem SharePoint-Server führen Sie in der SharePoint-Verwaltungshell folgendes aus:
New-SPWOPIBinding -ServerName <WacServerName> –AllowHTTP
Wobei <WacServerName> dem Namen des Office Web App Server entspricht.
Set-SPWOPIZone -zone "internal-http"
Letzter entscheidender Schritt: Falls nun per HTTP ein Zugriff stattfinden soll, dann muss dies explizit auf dem SharePoint-Server erlaubt werden:
(Get-SPSecurityTokenServiceConfig).AllowOAuthOverHttp
Falls Sie hier ein False bekommen, müssen folgende Zeilen nicht ausgeführt werden.
$config = (Get-SPSecurityTokenServiceConfig)
$config.AllowOAuthOverHttp = $true
$config.Update()
(Get-SPSecurityTokenServiceConfig).AllowOAuthOverHttp
Nun sollte den Office Web Apps nichts mehr im Wege stehen..
Nun sollten Dokumente im Browser editierbar sein und in Bibliotheken oder bei Suchergebnissen als Preview zur Verfügung stehen.
Office WebApps machen SharePoint so richtig rund: OneNote, Word, Excel im Browser inklusive Editieren. Super. Lizenzrechtlich verhält sich die Sache in etwa so:
Nur lesen kostet nichts. Schreiben kostet Office 2013 Lizenzen.
Genaueres dazu findet man auch bei Microsoft unter http://technet.microsoft.com/de-de/library/ff431682(v=office.15).aspx mit folgendem Wortlaut:
“…
Nur anzeigen. Office Web Apps erlaubt standardmäßig nur das Anzeigen von Dateien. Diese Funktionalität wird kostenlos bereitgestellt.
Bearbeiten und anzeigen. Sie müssen eine Lizenz zum Bearbeiten erwerben, um die Bearbeitungsfeatures von Office Web Apps mit SharePoint 2013 verwenden zu können. Sie ermöglichen die Bearbeitung, wenn Sie eine Office Web Apps Server-Farm erstellen.
Unternehmenskunden, die über ein Volumenlizenzierungsprogramm für Office 2013 lizenziert sind, können lokal die Office Web Apps-Bearbeitung für SharePoint 2013 ermöglichen. Dadurch können Benutzer Office-Bearbeitungsfunktionen zu Hause oder an anderen Orten nutzen, an denen unter Umständen keine Office-Clients installiert sind. Bearbeitungslizenzen für Office Web Apps können nicht separat erworben werden.
Ausführliche Details zu Ihrer Lizenz finden Sie in den Microsoft-Software-Lizenzbedingungen, die bei der Installation von Office Web Apps Server angezeigt werden.
SharePoint 2013 stellt eine neue Lizenzerzwingung bereit, die mit Office Web Apps verwendet werden kann. Wenn Sie die SharePoint-Lizenzierung und anschließend die Office Web Apps-Bearbeitung aktivieren, können nur Benutzer, die über die entsprechende Lizenz ("OfficeWebAppsEdit") verfügen, Office-Dateien in einem Browser bearbeiten. Falls für Benutzer keine Office Web Apps-Bearbeitungslizenzen angewendet werden, wird nur das Anzeigen unterstützt. Weitere Informationen zur Funktionsweise der Lizenzierung in SharePoint 2013 finden Sie unter Konfigurieren der Lizenzierung in SharePoint Server 2013. Der Parameter EditingEnabled, der die Bearbeitung ermöglicht, wird unter New-OfficeWebAppsFarm sowie unter Set-OfficeWebAppsFarm beschrieben. …”
Folgendes erklärt ausserdem noch die unterschiedliche Lizenzierung zwischen externen Benutzern und internen:
zu finden unter: http://blogs.technet.com/b/volume-licensing/archive/2013/05/22/how-to-license-office-web-apps-server.aspx
Es geht sicher noch komplizierter Also lassen Sie sich daher gut beraten.
Sharepoint 2013 glänzt mit vielen Neuerungen was die Suche betrifft. Dabei spielt das sogenannte Suchschema eine herausragende Rolle. Erst durch Einstellungen im Suchschema lassen sich beispielsweise gezielte Suchen nach Metadaten einstellen. Wollen Sie etwa nur Treffer Ihres Intranets mit der Metadateneigenschaft Abteilung=IT finden, dann sind Sie im Suchschema genau richtig. Mit Hilfe von verwalteten Eigenschaften können Sie durchforstete Eigenschaften für die Suche gezielt zur Verfügung stellen. Für unser Beispiel der Abteilung wäre das Abteilung:IT. Keine Treffer, weil das Dokument IT enthält, kein Treffer, weil in der URL IT vorkommt. Sondern ein Treffer, weil die Spalte Abteilung den Wert IT aufweist. Diese verwalteten Eigenschaften lassen sich für viele weitere Dinge nutzen, wie die Ergänzung des Verfeinerungsbereichs, Firmenextraktion usw. Leider, leider muss dafür eine Neuindizierung stattfinden. Das kann inkrementell, aber auch eine vollständige Indizierung bedeuten. Ich mag gar nicht überlegen, was wäre, wenn mein Sharepoint Server 100 GB mal schnell indizieren soll. Daher ist es für die Planung der Suche absolut notwendig sich vorab Gedanken über das Suchschema zu machen. Um ein wenig den Überblick zu behalten, wenn eine vollständige Neuindizierung notwendig hier eine kleine Liste: Settings der verwalteten Eigenschaft Aktion vollständige Indizierung Zuordnen einer durchforsteten zu einer verwalteten Eigenschaft Zuordnung hinzufügen/löschen Ja Tokennormalisierung Aktivieren/Deaktivieren Ja Vollständiger Vergleich Aktivieren/Deaktivieren Ja Extraktion von Firmennamen Aktivieren/Deaktivieren Ja Extraktion von benutzerdefinierten Entitäten Aktivieren/Deaktivieren Ja Durchsuchbar Aktivieren/Deaktivieren Ja Abfragbar Aktivieren Ja Abfragbar Deaktivieren Nein Abrufbar Aktivieren Ja Abrufbar Deaktivieren Nein Einschränkbar Aktivieren (wenn nicht bereits "Sortierbar") Ja Einschränkbar Deaktivieren Nein Sortierbar Aktivieren (wenn nicht bereits "Einschränkbar") Ja Sortierbar Deaktivieren Nein Alias Hinzufügen/Löschen Nein Na denn: Gute Planung http://www.ppedv.de/SharePoint
Eine Provider Hosted App ist eine normale ASP.NET Anwendung die entweder mit WebForms oder mit ASP.MVC programmiert werden kann. Solange man keine SharePoint Zugriffe aus der App heraus benötigt kann man die Anwendung wie eine alleinstehen ASP Anwendung programmieren. Nachdem ich aber dem User ein einheitliches Erscheinungsbild bieten möchte, verwende ich das Chrome Control um die Styles von SharePoint auch in meiner App zu nutzen. (Siehe Blog von meinem Kollegen Markus Hiller) Sobald das Chrome Control verwendet wird, müssen in den Parametern des Seitenaufrufes auch die SharePoint eigenen Parameter wie SPHostUrl, AppUrl udgl. übergeben werden. Bei der Startseite der App erledigt das der SharePoint Server. Wenn aber von der StartSeite auf eine weitere Seite der App verlinkt wird beginnen die Probleme. Wir müssen selbst die Übergabeparameter weitergeben. Da ich im href-Attribut des Links nicht immer die gesamten Parameter schreiben möchte, und auch nicht kann, da sie zur Entwicklungszeit nicht bekannt sind, muss ich den Umweg über JavaScript oder genauer JQuery gehen. Jeder Link erhält einen ID: <a id="l1" href="MembersFirstSeminar.aspx"><img alt="" class="auto-style2" src="goto.jpg" /></a>
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, "Courier New", courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
nun kann in der Document-ready Funktion das href-Attribut verändert werden. Es werden einfach alle Aufrufparameter der Startseite an das href-Attribut angehängt.
$(document).ready(function(){
$('#l1').attr("href", $('#l1').attr("href") + '?' + document.URL.split("?")[1]);
});
.csharpcode, .csharpcode pre
{
font-size: small;
color: black;
font-family: consolas, "Courier New", courier, monospace;
background-color: #ffffff;
/*white-space: pre;*/
}
.csharpcode pre { margin: 0em; }
.csharpcode .rem { color: #008000; }
.csharpcode .kwrd { color: #0000ff; }
.csharpcode .str { color: #006080; }
.csharpcode .op { color: #0000c0; }
.csharpcode .preproc { color: #cc6633; }
.csharpcode .asp { background-color: #ffff00; }
.csharpcode .html { color: #800000; }
.csharpcode .attr { color: #ff0000; }
.csharpcode .alt
{
background-color: #f4f4f4;
width: 100%;
margin: 0em;
}
.csharpcode .lnum { color: #606060; }
Simpel und einfach
diese und weitere Themen werden in unseren Schulungen behandelt:
SharePoint-Schulungen
Wie im Teil 1 schon beschrieben, können wir per Auftrag alle Einträge des ULS Logfiles in die Datenbank schreiben lassen. Die Abfrage per T-SQL läßt deutlich mehr Spielraum die Suche nach Problemen, KorrelationsID usw. zu vereinfachen. Aber ehrlich gesagt: das muss noch besser gehen. Wie wäre es ,das Logile in der Zentraladministration anzuzeigen? Inklusive Filterfunktion, Hervorhebung von kritischen bzw unerwarteten Ereignissen? Hört sich gut, läßt sich gut machen! Zwei Dinge braucht der Mann dazu: Den Zugriff zur Datenbank und den Sharepoint Designer 2010. Datenbankzugriff Die Daten stecken in der WSS_Logging Datenbank und können sehr komfortabel per Sicht (ULSTraceLog) ausgelesen werden. Für den Zugriff könnten wir einerseits das Konto derFarm verwenden oder ein spezielle dediziertes Konto für die Logfileanlayse, das nur Leserechte auf die Datenbank erhält. Dazu legen wir einen Benutzer (bspw. SQLULSUSer) an und geben bei der Benutzerzuordnung die Rechte in der WSS_Logging Datenbank lesen zu dürfen. (hier: per Datenbankrolle db_datareader, mit der in jeder Tabelle lesen dürfte) Sharepoint Designer 2010 Im Sharepoint Designer öffnen wir die Zentraladministration und legen per Menu eine Datenquelle an: An dieser Stelle gilt es aufzupassen, denn die Anmeldedaten werden im Sharepoint Designer im Klartext gespeichert.! Sofern die Anmeldung geklappt hat, sollte die WSS_Loggingdatenbank auswählbar sein und wählt als Datenbasis für die späteren Abfragen die Sicht ULSTraceLog. Da vermutlich nicht jede Information beobachtet werden muss, lassen sich Felder aus er Ansicht entfernen. Sharepoint Designer liebt es es eh nicht besonders, wenn zu viele Felder anzeigt werden und unterdrückt oft genug einige Felder, obwohl diese angezeigt werden sollten. Nun kann man noch die Ergebnisse der Abfrage nach Logtime absteigen sortieren, so dass auf jeden Fall aktuellste Ereignisse ganz oben zu finden sein werden. Ebenso ließe sich ein Filter einbauen, der nur bestimmte Ereignisseinträge anzeigt. Da es später sehr viele Logeinträge sein könnten, würde ich den Filter eher auf die TOP 1000 EInträge oder per Datum (max. der letzten 24 Stunden) eingrenzen. Das kann man aber per T-SQL deutlich leichter bewerkstelligen als im Sharepoint Designer irgendein Rumgefummle zu starten. Dazu schließen wir zunächst die eben erstelle Sortierung und klicken auf Datenquelle. Dort ändern wir im weiteren Dialog die Einstellung so, dass an statt der Sicht ein T-SQL Befehl eintragen werden kann, wie zum Beispiel folgender: Neue Seite für Logfileanzeige Um die Logfileeinträge in der Zentraladministration komfortabel lesen zu können, werden nun im folgenden eine neue Seite anlegen: Logfile.aspx Die Datenquelle einbinden und die anzuzeigenden Felder festlegen Die Masterpage anhängen Das Layout auf ein besser lesbares ändern bedingte Formatierungen für den Level (warning oder unexpected bspw) einführen. So nun der Reihe: Zuerst die Seite (ich nenne sie Logfile.aspx) Wenn die Datei angelegt ist, diese doppelklicken und zum Bearbeiten öffnen. Den Hinweis, dass die Datei im erweiterten Modus geöffnet werden muss, bejahen wir. Nun sehen wir eine leere Seite mit einem Form Feld, in das wir die Datenquelle per Klick einfügen. Im Ergebnis sehen wir, dass nicht alle Spalten angezeigt werden. Daher fügen wir die relevanten Spalten hinzu, andere lassen wir weg. So macht zum Beispiel die RowID hier wohl keinen Sinn, sehr wohl der Level oder die Message. Damit das ganze auch irgendwie nach Sharepoint aussieht und vor allem das Menu der Zentraladministration vorhanden sein sollte, fügen wir der Logfile.aspx die Masterpage v4 an. Das Ergebnis hat nun schon mehr mit Sharepoint Ähnlichkeit: Allerdings hasse ich es wenn ich horizontal und vertikal scrollen muss! Das kann man allerdings dadurch beheben, wenn man irgendwo in die Tabelle klickt und dann per Menü “Entwurf” den Wiederholenden Abschnitt wählt: Letzter Schliff Optimal wäre nun noch die Ladezeiten zu verbessern und Fehler hervorzuheben. Bitte schön: Markieren Sie dazu das Feld Level, in dem sich Warning, Unexpected usw befinden, und wählen im kontextmenü “bedingte Formatierung. Nun können Sie via “Erstellen”.. Formatierung übernehmen unserer Regeln für die Formatierung anlegen. Nachdem wir die Regeln festgelegt haben, definieren wir die Formatvorlage. Hintergrund “rot” etwa. Fast geschafft. Nur noch per Seitenverwaltung das Paging aktivieren und die Anzeigen auf eine gewünschte Anzahl der Datensätze einschränken.. und schon wird die Anzeige schon deutlich flüssiger. Und zuletzt noch eine Gruppierungs- und Filtermöglichkeit aktivieren: Und so könnte das Endergebnis aussehen. Mit Filterfunktion: