SPContentDBManager auf Codeplex
Lange war es hier ruhig, aber heute gibt es eine kleine Premiere. Ich habe mein erstes, noch sehr kleines, Tool für SharePoint 2007 auf Codeplex Online gestellt.
Das Tool hat den Namen SPContentDBManager und erlaubt die Verwaltung der eingebundenen Content Datenbanken in SharePoint 2007. Gerade bei einer großen Anzahl von Content Datenbanken, fällt die Verwaltung durchaus leichter aus.
Folgende Funktionen sind bereits implementiert:
- Content Datenbanken im Bulk in den Status “disabled” versetzen
- Content Datenbanken im Bulk in den Status “online” versetzen
Features in der nächsten Version:
- Lösen und anbinden von Contentdatenbanken
- Das Limit der SiteCollection und Warnungen verwalten
SharePoint 2010 Service Pack 1 veröffentlicht
Es ist soweit, das erste Service Pack für den SharePoint Server 2010 wurde veröffentlich und bringt einige Verbesserungen mit.
Neuerungen und Verbesserungen:
- Verbesserte Unterstützung für Internet Explorer 9.
- Papierkorb: Sie können eine gelöschte Websitesammlung oder Website wiederherstellen.
- Remote Backup Systems (RBS) und flaches Kopieren können die Ausfallzeiten verringern und die Effizienz steigern, indem die Zeiger auf die Datenbanken und nicht die Datenbanken selbst verschoben werden.
- Mithilfe der verbesserten Speicherverwaltungsfunktion in den Websiteeinstellungen können Sie sehen, welche Ordner wertvollen Speicherplatz belegen.
- Unterstützung für Microsoft SQL Server 2011
- Ein robusterer Search-Host-Verteilungsdienst verbessert Fehlerbehebung und Leistung während der Suchdurchforstung.
- Stellt Sicherungs- und Wiederherstellungsfunktionen zum Wiederherstellen gelöschter Websitesammlungen und Websites bereit.
Hier findet ihr das ServicePack 1 zum Download:
| SharePoint Server 2010 | http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=26623 |
| SharePoint Designer 2010 | http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=26628 (32 Bit) http://www.microsoft.com/download/en/details.aspx?displaylang=en&id=26634 (64 Bit) |
Synchronisation von Aufgaben aus Microsoft Project 2010 mit SharePoint 2010
Wer von euch Microsoft Project für die Planung von Projekten und deren Aufgaben einsetzt, bekommt mit der Version 2010 eine interessante Neuerung um die Aufgaben mit einer SharePoint Liste zu aktualisieren.
Was wird benötigt?
- Microsoft Project 2010 Professional
- SharePoint Server oder Foundation 2010 mit einer Aufgabenliste
Nun erstellt man wie gewohnt in Project 2010 einen Zeitplan und Aufgabenplan. Wie dies im Detail funktioniert möchte ich hier nicht näher erläutern. So z.B. könnte ein kleiner Aufgabenplan aussehen:
Wichtig hierbei ist, dass den Aufgaben Ressourcen (Personen) zugeordnet werden, damit die Aufgaben von SharePoint später korrekt zugewiesen werden können.
Das Veröffentlichen der Aufgaben funktioniert wie folgt: Über Datei –> Speichern und Senden –>Mit Aufgabenliste synchronisieren gibt man eine SharePoint Site an und wählt eine Aufgabenliste aus. Über den Button synchronisieren werden die Aufgaben aus Microsoft Project 2010 mit SharePoint 2010 synchronisiert.
Das sieht in SharePoint dann wie folgt aus:
Setzt man nun eine neue Ansicht von Typ Balkendiagramm (Gantt) auf, sieht da Ansicht in SharePoint plötzlich wie in Microsoft Projekt 2010 aus. Somit kann man die Aufgaben wesentlich besser in einer zeitlichen Abfolge betrachten.
Eines der wichtigsten Features ist in meinen Augen jedoch die Synchronisation in beide Richtungen. Was würde es einen Projektleiter nutzen, wenn er immer nur seine Aufgaben anderen zuweisen kann aber nie ein Feedback in sein Microsoft Project Diagramm zurückbekommt, ob die Aufgaben durch die Projektteilnehmer bereits erledigt wurden.
Hierzu muss der Projektmanager in Microsoft Project 2010 denselben Weg der Synchronisierung gehen. Also auch über Datei –> Speichern und Senden –>Mit Aufgabenliste synchronisieren. Sollte es Konflikte geben, so werden diese angezeigt.
SharePoint Workflow Fehler in der Workflow History speichern
Die Fehlerbehandlung in SharePoint 2010 Workflows welche mit Visual Studio 2010 entwickelt wurden, kann man auf unterschiedlichsten Wegen angehen. Ein Weg wäre das Abfangen der Fehler in der jeweiligen Activity mit einem klassischen Try Catch Blog und die darauf folgende Ausgabe in der Workflow History. Alternativ kann man zum Beispiel bei If-Else, While und anderen Activities einen Fault Handler implementieren.
Diese Wege haben alle etwas gemeinsam, sie funktionieren nur gut, solange man in etwa lokalisieren kann wo der Fehler auftreten wird. Ist man sich darüber jedoch nicht im Klaren erhält, man im Fall einer Exception nur die Standardausgabe in der Workflow History “Fehler im Workflow [NAME]”.
Die Workflow Foundation bietet jedoch die Möglichkeit diesen Standard FaultHandler zu überschreiben und eine eigene Implementierung zu hinterlegen. Somit ist es möglich die Informationen der Fehlerausgabe selbst zu definieren und zu skalieren.
Dazu muss als ersten in der Codeansicht die Funktion HandleFault überschrieben werden. Wie dies in einem konkreten Beispiel aussehen könnte, ist in dem Codesnippet zu erkennen.
SharePoint konferenz: Workflowentwicklung mit SharePoint 2010
Ich werde am 17.02.2011 um 16.30 Uhr einen Vortrag auf der SharePoint konferenz in München halten. Dabei wird es um die Entwicklungsmöglichkeiten für Workflows unter SharePoint 2010 gehen. Ich werde die verschiedenen Wege aufzeigen, welche der SharePoint Server zur Entwicklung von Workflows zur Verfügung stellt. Der Schwerpunkt hierbei wird die Entwicklung von Workflows mit Visual Studio 2010 sein.
Unter dem Motto Building & Connecting Know-how finden die große SharePoint konferenz sowie die VSone – nur wenige Meter von der Microsoft Zentrale Deutschland entfernt – in München statt. Das neue Designhotel Dolce Munich stellt dabei einen perfekten Ort für Konferenz, Networking, Business Forum sowie Fachausstellung dar. Erleben Sie auf 10 parallelen Vortragsreihen mehr als 120 Sessions zu allen Top-Themen rund um aktuelle Microsoft-Technologien – von SharePoint und ECM über SQL Server, Business Intelligence, Visual Studio, .NET, Silverlight, Windows Azure und Co. bis hin zu User Interface & Design.
Infos und Anmeldung unter www.SharePointKonferenz.de
Aktivieren der Workflow Visualisierung in SharePoint 2010
Seit dem SharePoint Server 2010 gibt es die Möglichkeit laufende und bereits abgeschlossene Workflows visuell in Form eines Visio Flowcharts anzeigen zu lassen.
Dafür kommen im SharePoint 2010 die Visio Services zum Einsatz, welche jedoch Silverlight 3.0 oder höher benötigen.
Achtung: Für die Visio Services benötigt man die Enterprise Lizenz des SharePoint Servers 2010
Ist die Visualisierung von Workflows in SharePoint 2010 erst einmal eingerichtet so findet man folgende Visualisierung des Workflows in dem jeweiligen Workflow Status.
Wie Aktiviert man die Visualisierung der Workflows?
- Öffnen der Central Administration (CA) und unter “Manage Services on server” den Dienst “Visio Graphics Services” starten
- Danach öffnet man in der CA den Bereich “Manage Web Applications” und schaut nach ob der “Visio Graphics Service” zur Verfügung steht und gestartet ist.
Steht der “Vision Graphics Service” nicht zur Verfügung, so muss man einen neuen “Visio Graphics Service” anlegen. - In den Farm Features muss das Feature “Visio Web Access” gestartet werden
- Danach sollte sowohl in den Site Collection Features, wie auch in den Site Features, das Feature “SharePoint Server Enterprise Site (Collection) features” aktiviert werden.
- Zu beachten ist lediglich noch, das in den Einstellungen des Workflows, welcher durch den SharePoint Designer veröffentlicht wird, die Option “Show workflow visualization on status page” aktiviert ist. (Siehe Bild)
Deaktivieren und Aktivieren von Event Receivern in WSS 3.0
Meine Aufgabe heute war die Implementierung einen Migrationstools um den Inhalt einer Liste auf einer SharePoint Seite in andere Listen auf einem anderen SharePoint Server zu kopieren. Hierbei waren auch zahlreiche Transformationen des Inhaltes nötig.
In meinen Ziellisten existierten jedoch unzählige Event Receiver welche diverse Dinge taten wenn Listeneinträge erzeugt bzw. gelöscht werden. Zum Beispiel wurden Emails und Termine versendet oder Einträge in anderen Listen erzeugt.
Mein Migrationsworkflow (stark vereinfacht) ist im Bild rechts zu erkennen. Hier wurde zuerst die Quell- und die Zielliste geladen. Danach sicherte der Event Manager alle Eventdefinitionen für die Zielliste und löschte diese anschließend aus der Zielliste. Danach wurde die Zielliste gelöscht und neu erstellt, dies ist nötig da ich die ID’s der Listeneinträge aus dem alten System mit übernehmen musste. Jetzt wird jeder Listeneintrag einzeln aus der Liste selektiert und transformiert. Danach wird er in der Zielliste gespeichert. Ganz zum Schluss werden die Eventdefinitionen, welche wir am Anfang gesichert haben, wieder an die Zielliste angehangen.
Ich möchte mich in diesem Beitrag jedoch nur auf die Verwaltung der Event-definitionen stützen und den Rest außen vor lassen. Da es leider keine Deactivate bzw. Activate Funktion in der SPEventReceiversDefinitionCollection gibt, war ich gezwungen mir ein Workaround zu bauen.
Als erstes habe ich mir eine Klasse gebaut, welches die wichtigsten Daten des Event Receivers hält und eine Möglichkeit bietet diese am Ende auch zu speichern. Die Klasse seht ihr im unteren Screenshot.
Den Inhalt dieses Objekts vom Typ EventDefinition wird aus der jeweiligen SharePoint Liste ausgelesen. Dazu gibt es in der SPList Klasse die Property “EventReceivers” vom Typ SPEventReceiversDefinitionCollection, welche alle Eventdefinitionen für die SharePoint Liste zurück gibt.
Damit ich die Properties vom SPEventReceiversDefinition Objekt nicht jedes Mal von Hand zuweisen muss, habe ich mir einen expliziten Operator geschrieben, der das konvertieren übernimmt.
Nun kommen wir zu der Klasse EventManager. Dieser sorgt dafür, dass die Event Definitionen aus der Zielliste entfernt und nach dem Import der Daten wieder eingefügt wird. Die Klasse hat folgendes Schema:
Die Event Receiver Definitionen werden dem EventManager beim Erstellen über den Konstruktor übergeben. Dieser fügt sie dann in die Liste Events ein.
Die Funktion DeleteEvents sorgt dafür, dass die Eventdefinitionen aus der SharePoint Liste, welche man übergibt, entfernt werden.
Hingegen ist die Funktion AddEvents dafür verantwortlich, das die Events wieder an die Zielliste angehangen werden. Hierfür muss man die Zielliste der Funktion übergeben. Die Eventdefinitionen selbst befinden sich in der Liste Events, welche durch den Konstruktor gefüllt wurde. In der Funktion AddEvents wird die Funktion Save aufgerufen, welche Die Aufgabe hat jede einzelne Definition wieder in ein Objekt vom Typ SPEventReceiverDefinition umzuwandeln und in der Zielliste zu speichern.
Server mit WSS 3.0 umbenennen
Ich werde heute meinen Blog um eine neue Kategorie erweitern: SharePoint. Der erste Eintrag in dieser Kategorie stellt sich einem, auf den ersten Blick, sehr einfachen Problem.
Problem:
Ich musste heute in meiner SharePoint Entwicklungsumgebung den Servernamen anpassen. Das ist prinzipiell nicht kompliziert, nur muss bei Windows SharePoint Services bzw. SharePoint Server auf einiges geachtet werden, damit er danach weiterhin fehlerfrei läuft.
Lösung:
- Umbenennen des Servers geschieht über die Eigenschaften des Arbeitsplatzes. Nachdem umbenennen muss der Rechner neu gestartet werden.
- Wenn der Servername geändert ist, wird die Änderung leider nicht im SQL Server übernommen. Wir müssen uns also mit dem SQL Server verbinden und den Servernamen per T-SQL anpassen. Sich mit dem SQL Server der WSS 3.0 zu verbinden, funktioniert leider nur über NAMED PIPES.
Servername (WSS 3.0): \\.\pipe\mssql$microsoft##ssee\sql\query
Servername (SP 2010): \\.\pipe\mssql$sharepoint\sql\queryIn beiden Fällen sollten ihr als Authentifizierungsmodus die Windows Authentifizierung wählen!
Wie der Servername geändert werden kann, erfahrt ihr in einem etwas älteren Blog Post von mir:
SQL Server 2008: Tatsächlichen Servernamen ändern - Als nächstes öffnen wir die Eingabeaufforderung um den Servernamen in den SharePoint Services anzupassen.
cd c:\program files\common files\microsoft shared\web server extensions\12\bin
stsadm -o renameserver -oldservername [alter Servername] -newservername [neuer Servername] - Der letzte Schritt wäre die bestehenden Webanwendungen im SharePoint Server anzupassen. Dort werden wir Adressen unter denen die Seiten gefunden werden anpassen. Wir öffnen dazu die SharePoint Zentral-administration (Wichtig: Beim öffnen nicht über den Fehler wundern. Ihr müsst den neuen Servernamen in der URL benutzen!), begeben uns unter Vorgänge in die Einstellungen der Alternativen Zugriffszuordnungen (Alternate Access Mappings) und passen dort in allen Einträgen den Servernamen entsprechend an.
Abfragen mit dem Entity Framework nur über Stored Procedures erlauben
Diesen Blog Post habe ich meinen Kollegen Marcel Felder zu verdanken, der die Lösung zu diesem Problem gefunden hat. Da ich aber glaube, dass der eine oder andere ebenfalls dieses Szenario haben könnte, habe ich mich entschlossen die Lösung zu veröffentlichen. Danke Marcel!
Szenario:
Mein Kollege hatte in einem Projekt die Anforderung, Abfragen welche über das Entity Framework auf eine Datenbank ausgeführt werden nur über Stored Procedures zu erlauben. Das bedeutet, eine direkte Abfrage über den ObjectContext mit Zugriff auf die EntitySets soll nicht möglich sein (siehe Bild unten).
Lösung:
Als erstes werde ich eine Stored Procedure im SQL Server anlegen, welche mir alle Kunden selektiert, die in einer bestimmten Stadt wohnen.
Danach werde ich mein Entity Data Model aktualisieren und die Stored Procedure hinzufügen. Damit steht die Stored Procedure jedoch noch nicht im ObjectContext zum Aufruf zur Verfügung. Die Stored Procedure muss nun vom Store Model in das Conceptual Model importiert werden. Dazu öffnet man das Model Browser Fenster, begibt sich in den Store Bereich und wählt unter Stored Procedures die gewünschte Stored Procedure aus. Mit einem Rechtsklick auf die ausgewählte Stored Procedure, öffnet sich ein Kontextmenu wo man den Eintrag Add Function Import auswählt. Jetzt muss noch ein Funktionsname und ein Rückgabewert gewählt werden.
Nun steht die Stored Procedure im ObjectContext zum Aufruf zur Verfügung. Jetzt müssen wir nur noch dafür sorgen, dass die EntitySets, welche nicht über den ObjectContext aufrufbar sein sollen, verschwinden. Dazu begeben wir uns wieder in den Model Browser und schauen uns den Bereich EntityContainer –> Entity Sets näher an. Hier wählen wir nun das gewünschte EntitySet aus. Nun können wir in den Eigenschaften den Getter Zugrifflevel definieren. Hier wählen wir Private aus.
Jetzt stehen uns im ObjectContext die EntitySets, welche wir auf Private gesetzt haben, nicht mehr für Abfragen zu Verfügung. Die Abfrage ist somit nur noch über die vorgegeben Stored Procedures möglich.
Fazit:
Zugegeben ist dieses Szenario eher selten in dieser extremen Form anzutreffen. Aber z.B. in besagten Projekt geht es leider nicht anders und so sollen andere Entwickler, gar nicht erst auf die Idee kommen die Abfragen auf die EntitySets direkt auszuführen. Mit dieser Lösung wird uns nur ein Weg zur Abfrage von Daten, für die Tabelle Customer, zur Verfügung gestellt.
