Oliver Wirkus : SharePoint

ShareConnect 2010 – ich bin als Sprecher dabei

Oliver Wirkus — Mon, 02 Aug 2010 08:49:00 GMT

Ich freue mich sehr, am 23.9.2010 in Mainz auf der ShareConnect einen Vortrag zum Thema “Best Practices in der SharePoint-Entwicklung” halten zu dürfen.

Zwar startet mein Vortrag gleich am ‘frühen’ Morgen (23.9. 8:30Uhr bis 9:45) – und eigentlich bin ich kein ‘Morgenmensch’, aber ich hoffe, dass ich mit der Hilfe von einer guten Tasse Kaffee, oder zwei … einen interessanten und spannenden Vortrag halten werde.

Ich freue mich schon auf interessante Tage (nicht nur) rund um das Thema SharePoint-Entwicklung in Mainz und besonders auf viele interessante Gespräche rund um unser Liebblingshobby :-)

Wir sehen uns dann also am 23.9.2010 auf der ShareConnect 2010 in Mainz …

SharePoint Pitfall - SPUtility.SendEmail

Oliver Wirkus — Thu, 29 Jul 2010 11:36:00 GMT

Um Emails aus SharePoint heraus zu verschicken, gibt es die Methode SPUtility.SendEmail(). Der große Vorteil dieser Methode ist, dass man sich als Programmierer nicht um die Einstellungen für den Mailversand kümmern muss. SPUtility.SendEmail holt sich selbst ein Einstellungen aus der Zentraladministration. Einfach Adresse, Betreff und Mailtext eintragten und abschicken. In vielen Fällen ist es wirklich so einfach, aber es gibt eine Sache, die muss man wissen, wenn man SPUtility.SendEmail() verwenden will: die Zeilenlänge im Mailtext ist auf 2048 Zeichen beschränkt. Manchmal findet man in Blogs auch den Hinweis, dass der gesamte Mailtext auf 2048 Zeichen limitiert ist – diese Aussage ist aber nicht richtig. Beschränkt ist nur die Zeilenlänge.

Aber warum ist eine begrenzte Zeilenlänge bei SPUtility.SendEmail() einen Blogeintrag wert? Und warum in dieser Rubrik?

Um das zu erklären, zuvor eineinfaches Beispiel: der Ablauf eines WebParts (oder einer anderen SharePoint-Entwicklung) soll protokolliert und am Schluss per Mail verschickt werden. Während des Laufs werden einzelne Statusmeldungen in einem StringBuilder-Objekt gesammelt. Am Ende des Durchlaufs wird der Mailtext aus dem Stringbuilder-Objekt erzeugt. Und genau hier versteckt sich das Problem:

Wenn man –wie gewohnt– einzelne Strings mit der Append()-Methode einem StringBuilder-Objekt hinzufügt, dann kann es durchaus passieren, dass diese 2048-Zeichen pro Zeile-Limitierung bei SPUtility.SendEmail() zuschlägt. Wenn man statt Append() AppendLine() verwendet, dann passiert dies nicht. AppendLine() fügt New Line-Zeichen in den Text ein.

Man kann dann z.B. so eine Email aus einer SharePoint-Entwicklung verschicken:

StringBuilder oErrorMessages = new StringBuilder();

oErrorMessages.AppendLine(“Fehlermeldung 1”);

OErrorMessages.AppendLine(“Fehlermeldung 2”);

SPUtility.SendEmail(SPContext.Current.Web,
                    false,
                    false,
                    SPContext.Current.Web.CurrentUser.Email,
                    "Betreffzeile",
                    oErrorMessages.ToString());

SharePoint Pitfall – Custom Field Types

Oliver Wirkus — Tue, 27 Jul 2010 07:55:00 GMT

Custom Field Types sind eigentlich eine sehr praktische Sache wenn es darum geht, Eingaben benutzefreundlicher zu gestalten. Wie man ein Custom Field Type programmiert, dazu findet man im Internet zahlreichen Anleitungen und auch ich habe zuletzt auf der BASTA! Spring 2010 in einem Vortrag darüber und über mögliche Einsatzszenarien berichtet. Mit dem WSPBuilder (oder auch den Visual Studio Extensions) ist es wirklich keine große Sache mehr, ein Custom Field Type zu programmieren und in eine Solution zu verpacken.

Ich selbst verwende in meinen Kundenprojekten Custom Field Types sehr gern, um Listen mit Vorgabewerte (z.B. Dokument-Status, …) aus einem administrativen Web auszulesen und in Listen oder Bibliotheken anzuzeigen. Zu diesem Web haben dann nur wenige ausgewählte Mitarbeiter Zugang und können die Listen mit den Vorgabewerten pflegen.

Bevor man sich aber in der Planungsphase eines neuen Projektes allzu schnell auf die Verwendung von Custom Field Types festlegt, sollte man wissen, dass es neben den Vorteilen auch einige Nachteile (oder besser gesagt: Pitfalls) gibt, die man kennen muss.

1. Datenblatt-Ansicht

In den Forms (View, New, Edit) funktionieren Custom Field Types – aber leider funktionieren sie nicht in der Datenblatt-Ansicht. Normalerweise erreicht man diese Einstellung, wie im folgenden Screenshot dargestellt:

Zwar werden hier dann auch die Spalten dargestellt, denen ein Custom Field Type zugrunde liegt, aber diese Spalten können in dieser Ansicht nicht editiert werden. Beim Versuch, diese Spalten zu ändern oder zu beschreiben, bekommt man nur die Meldung, dass diese Spalten schreibgeschützt (read-only) sind.

Mit den Standard-Datentypen (z.B.: Choice) funktioniert es hingegen, wie erwartet. Bedeutet: die Auswahlen in einem Auswahlfeld werden in der Datenblatt-Ansicht angezeigt und auch als Auswahl dargestellt.

2. Microsoft Office Integration

Seit Microsoft Office 2003 gibt es eine SharePoint-Integration. Es ist damit möglich, Office-Dokumente direkt in eine SharePoint-Bibliothek zu speichern. Sind in dieser Bibliothek Pflichtfelder vorhanden, gibt Office eine enstrpechende Meldung aus und blendet den Document Information Panel ein. Bei Office 2003 war dies noch ein eigenes Fenster, aber ab Office 2007 wird der Document Information Panel unterhalb der Ribbon-Leiste eingeblendet. Hier kann der Benutzer dann die fehlenden (Pflicht-)Felder ergänzen. Leider funktioniert dies nicht mit programmiertem Custom Field Types. Mit den Standarddatentypen (z.B. Choice) funktioniert die Office-Integration wie erwartet.

Zwar werden im Document Information Panel Custom-Field-Type-Felder angezeigt, aber nur als einfache Textfelder – selbst wenn diese Felder eigentlich z.B. als Listboxen dargestellt werden. Dies bedeutet, dass Custom Field Types bei der Office-Integration leider auch nicht unterstützt werden. Schreibt man in diese Textboxen, die eigentlich Custom Field Types ein sollten, beliebige Werte, dann werden diese Werte auch in die Bibliothek übernommen – auch dann, wenn die eingegebenen Werte überhaupt nicht in z.B. einer Listbox auftauchen. Dazu ein kurzes Beispiel: gehen wir davon aus, ein Feld wäre als Custom Field Type umgesetzt und würde die Werte (1,2,3,4) enthalten. Dieses Feld ist als Pflichtfeld markiert. Wenn man über die Office-Integration ein neues Dokument in die entsprechende Dokumentbibliothek speichert, kann man im Document Information Panel beispielweise den Wert 5 eingeben – dieser Wert wird übernommen, auch wenn er nicht in der Listbox auftaucht.

In obigem Bild sieht man oben (im blauen Teil) einen Teil des Document Information Panel (hier ist das Feld Firma ein reines Textfeld) und unten einen Auschnitt aus der SharePoint-Bibliothek (hier ist das Feld Firma ein Custom Field Type basierend auf einer Auswahl).

3. Webservice

Das bisher gesagte gilt leider auch für die Standard-SharePoint WebServices. Auch diese habe so ihre Probleme mit den Custom Field Types. Man kann zwar z.B. mit dem lists.asmx auf Listen oder Bibliotheken zugreifen, die selbstprogrammierte Custom Field Types enthalten, aber diese werden hier so wenig unterstützt, wie schon beim vorherigen Punkt (2. Microsoft Office Integration) geschildert.

4. Deployment

Custom Field Types werden normalerweise in eine Solution verpackt und in den Global Assembly Cache installiert. Dies sollte man auf jeden Fall berücksichtigen, denn nicht in allen Installationen ist dies möglich. Weiterhin werden Custom Field Types server-global installiert. Dies bedeutet: sie werden im Solution Management in der Zentraladministration als “globally deployed” dargestellt – und das ist in diesem Fall wörtlich zu nehmen. Laufen auf einem SharePoint-Server mehrere Web-Applications, dann ist der Custom Field Type in allen Web-Applications verfügbar und kann in allen Web-Applications genutzt werden. Dies sollte man unbedingt berücksichtigen, wenn man in einem Shared-Umfeld arbeitet. Nicht immer ist es sinnvoll bzw. gewünscht, dass ein Custom Field Type, der für WebApp_1 programmiert wurde, auf auf WebApp_2 sicht- und verwendbar ist!

SharePoint Pitfalls – Intro

Oliver Wirkus — Wed, 14 Jul 2010 09:58:03 GMT

SharePoint ist ein sehr mächtiges Werkzeug, mit dem man viele Anforderungen teilweise sogar sehr elegant und benutzer-freundlich umsetzen kann.

Aber manchmal passiert es eben einfach mal: man stolpert über ein Verhalten oder eine Reaktion von SharePoint, dass bzw. die man so in der aktuellen Situtation nicht erwartet hätte. Jeder, der schon in einem SharePoint-Projekt mitgearbeitet oder es sogar geleitet hat, kennt sicher diese Situtation.

Zugegeben, diese Situationen gibt es nicht nur bei SharePoint, aber da ich mich hauptsächlich (und sehr gern) mit SharePoint beschäftige, fällt es mir meist eben in Zusammenhang mit SharePoint-Projekten auf.

Offensichtlich geht es aber nicht nur mir so :-)

In letzter Zeit haben mich einige Emails mit den klassischen SharePoint-Stolpersteinen erreicht und auch im Forum der SharePointCommunity findet man immer mal wieder entsprechende Fragen oder Kommentare.

Ich habe mich entschlossen, einen Versuch zustarten und möchte in einer eigenen Rubrik in meinem Blog über diese klassischen Stolpersteine bei SharePoint berichten. Ich werde dies nicht regelmäßig tun – schließlich stolpert man ja nicht alle 4½ Tage über unerwartetes Verhalten. Ich werde in den nächsten Wochen über die mir bekannten Fallen und Stolpersteine berichten. Ich möchte aber auch ganz explizit meine Leser aufrufen und um Mithilfe und Unterstützung bitten. Berichtet mir doch von Euren Erfahrungen und Euren “Lieblingsstolpersteinen” – gern auch anonym. Ich würde sehr gern Erfahrungen und Berichte von Euch –von meinen Lesern– in diese Rubrik einfliessen lassen.

Daher mein Aufruf: schickt mir eine Email mit Euren Erfahrungen! Über welche Stolpersteine seid Ihr schon gestolpert und wie habt ihr das Problem gelöst. Ich würde gern Euer Feedback in diese Rubrik aufnehmen – denn ich bin mir sicher: die meisten von uns habe schon Bekanntschaft mit dem einen oder anderen Stolperstein bei SharePoint gemacht :-)

E-mailing a Document from a SharePoint Document Library

Oliver Wirkus — Tue, 13 Jul 2010 13:25:00 GMT

Jeder der schon mit Dokument-Bibliotheken in SharePoint gearbeitet hat, kennt sicher den Kontextmenü-Befehl “Link als E-Mail versenden” und hat sich schon gefragt, warum es nicht möglich ist, eine Datei aus einer Dokument-Bibliothek direkt zu verschicken.

Nun – da gibt es mehrere Gründe: wenn ich SharePoint nutze, um z.B. mit Kollegen zusammenzuarbeiten (was grundsätzlich schon mal eine gute Idee ist), warum sollte ich dann eine Datei (die vielleicht auch noch eine gewise Größe hat) direkt verschicken und so die Netz- bzw. Internetverbindung unnötig belasten? Sicher ein gutes Argument, gibt es doch auch in der heutigen Zeit immer noch Mitarbeiter bzw. Kollegen, die die Anfahrtsskizze zum Mitarbeitertreffen als 27MB große TIF-Datei per Email verschicken :-)

Ein anderer Grund – und das ist meiner Meinung nach ein wichtiger Grund: hier geht es um das Thema Sicherheit! Wenn ich statt eines Dokuments ‘nur’ den Link auf das Dokument in einer SharePoint Dokument-Bibliothek verschicke, kann ich halbwegs sicherstellen, dass dieses Dokument nur von berechtigten Benutzer geöffnet und gelesen werden kann. Wie schnell ist es passiert, dass man in der Büro-Hektik versehentlich eine falsche Email-Adresse auswählt – und schon hat man ein wichtiges Dokument an jemanden verschickt, der es eigentlich nicht bekommen sollte. Daher also der Kontext-Befehl “Link als E-Mail versenden”.

Aber – manchmal möchte man doch einmal die Möglichkeit haben, ein Dokument direkt aus einer SharePoint Dokumentbibliothek zu verschicken. Und so war es auch in einem meiner Projekte. Ich gebe zu, dass ich mir eine ganze Weile den Kopf zerbrochen habe, wie man das man besten umsetzen könnte (wobei ich sagen muss, dass meine Anforderungen noch etwas weitergehender sind). Das Erweitern des Kontextmenüs war dabei sicher nicht das Problem, denn die Vorgehensweise habe ich in einem älteren Post bereits beschrieben. Mein Problem war: wie komme ich an das Dokument und wie soll der angemeldete Benutzer die Email-Adresse eingeben, an die das Dokument dann letztendlich verschickt werden soll.

Im Blog von Becky Bertram (nicht in ihrem aktuellen Blog, sondern im Archiv ihres früheren Blogs) habe ich einen sehr interessanten Artikel darüber gefunden. Becky hat darin nicht nur ihren Lösungsansatz sehr detailliert beschrieben, sondern stellt auch ihren Code zum Download bereit.

Für alle, die sich Becky’s Lösung einmal genauer ansehen möchten, hier der Link zu ihrem Artikel im Blog-Archiv:

http://www.beckybertram.com/oldblog/index.php?p=31&more=1&c=1&tb=1&pb=1

Zielgruppenadressierung (Target Audiences) bei einem WebPart nicht vorhanden

Oliver Wirkus — Fri, 02 Jul 2010 11:27:58 GMT

Ein Kollege bat mich bezüglich eines etwas seltsamen Problems um Hilfe: bei einem WebPart war plötzlich die Einstellung für die Zielgruppenadressierung (engl.: Target Audiences) verschwunden.

Normalerweise sieht die entsprechende Einstellung in den WebPart-Properties ungefähr so aus:

Aber genau dieser markierte Eintrag fehlt.

Nach etwas Recherche im Internet habe ich einen Eintrag im Blog von Edward Wilde gefunden. Er hatte offensichtlich ein ähnliches Problem und hat sich die Mühe gemacht, es näher zu untersuchen. Hier der Link zu seinem Artikel:

http://blogs.edwardwilde.com/2009/12/03/target-audience-property-not-displaying-missing-for-web-parts/

Die alte Frage: SharePoint oder SAP? Was ist besser?

Oliver Wirkus — Tue, 20 Apr 2010 08:33:00 GMT

Ich werde oft bei Kundenbesuchen gefragt, was besser ist: SharePoint oder SAP? Klar: diese Frage kann man nicht so einfach beantworten, auch wenn manche Kunden das von einem guten SharePoint Consultant erwarten :-)

In diesen Fällen habe ich meinen Kunden bisher immer einen kleinen Workshop angeboten, in dem ich anhand einer langen Liste von Anforderungen und Auswahlmöglichkeiten beide Portale (SharePoint und SAP) gegenüber gestellt habe. Nachdem alle Anforderungen durchgesprochen und die Auswahlmöglichkeiten priorisiert sind, haben meine Kunden dann ein durch ihre eigenen Anforderungen und Wünsche fundiertes Ergebnis bekommen. Anhand dieses detaillierten Ergebnisses kann dann eine Entscheidung pro-SAP oder pro-SharePoint vom Kunden selbst getroffen werden.

Diese Workshops haben mir immer sehr viel Spaß gemacht, weil es dabei immer zu langen und interessanten Diskussionen kommt und weil ich viele interessante Einblick in die interne Firmenpolitik meiner Kunden bekomme. Letztendlich helfen mir diese Diskussionen, meine Kunden besser zu verstehen und zu beraten.

So wie es aussieht, bekomme ich jetzt aber ernst zu nehmende Konkurrenz: http://hunch.com/sharepoint-or-netweaver/

Ich habe mal ein paar mir bekannte Szenarien durchgespielt: ok, zugegeben - bei hunch.com kommt man schneller zu einer Entscheidung, aber mein Workshop liefert ein wesentlich detaillierteres Ergebnis und diskutieren kann man bei hunch.com auch nicht! Also: keine wirkliche Konkurrenz :-)

jQuery Library for SharePoint Web Services

Oliver Wirkus — Thu, 15 Apr 2010 11:55:41 GMT

ich bin auf eine sehr interessante Artikel-Serie von Marc D. Anderson gestoßen, die ich hier gern verlinken und weiterempfehlen möchte. Absolut lesenswert, wie ich finde. Auf endusersharepoint.com findet sich auch eine weitere Artikelserie von Marc zum Thema “Unlocking the Mysteries of Data View Web Part XLS Tags” – diese Artikelserie umfasst aktuell 20 Teile :-)

SPQuery, CAML und RowLimit

Oliver Wirkus — Fri, 09 Apr 2010 14:08:00 GMT

In letzter Zeit habe ich öfter meinen Vortrag “Best Practices in der SharePoint-Entwicklung” auf Konferenzen gehalten und darin u.a. Tipps zur Reduzierung der Serverlast bei Abfragen von SharePoint-Listen und Dokumentbibliotheken gegeben.

Die wichtigsten beiden Tipps waren (und sind):

ein SPQuery-Objekt mit einer CAML-Query verwenden
RowLimit setzen

Nach meinen Vorträgen bzw. etwas später per Email kam dann oft die Frage: “Wie programmiere ich denn nun eine Abfrage, bei der ein RowLimit gesetzt ist?”. Da ich auf den Folien meines Vortrags dazu bisher kein Beispiel gezeigt habe, hier ein kurzes Beispiel zur Veranschaulichung:

Zuerst erstellen wir die CAML-Query. In meinem einfachen Beispiel möchte ich alle Einträge aus einer Liste haben, in denen das Feld ProjektID auf den Wert 4711 gesetzt wurde. Um die Serverlast zu reduzieren, setzen wir den Wert für das RowLimit auf 100. Die CAML-Query kann man sich übrigens sehr einfach und komfortabel mit dem U2U CAML Query Builder zusammenklicken.

SPQuery oQuery = new SPQuery();
oQuery.Query = "<Where><Eq><FieldRef Name='ProjektID' /><Value Type='Text'>4711</Value></Eq></Where>";
oQuery.RowLimit = 100;

Danach kann ich eine einfache Schleife programmieren, in der die entsprechenden Items aus der Liste ausgelesen werden:

do
{
SPListItemCollection oItems = oList.GetItems(oQuery);

foreach (SPItem oItem in oItems)
{

// Do something …

}

oQuery.ListItemCollectionPosition = oItems.ListItemCollectionPosition;
}
while (null != oQuery.ListItemCollectionPosition);

Auf diese Weise werden bei großen Listen die Items nur in handlichen Portionen á 100 Stück (siehe RowLimit) geholt. Zusätzlich kann man die Anzahl an zurückgegebenen Feldern noch durch einen ViewFields-Eintrag begrenzen. Bedeutet: alle Felder, die ich in meiner Bearbeitungsschleife nicht benötige, kann ich über einen ViewFields-Eintrag am SPQuery-Objekt ausblenden.

Technorati-Tags: SharePoint,Development

Das SharePoint UI mit Custom Actions erweitern

Oliver Wirkus — Mon, 29 Mar 2010 08:00:00 GMT

Die für mich besten Gelegenheiten, einen längeren Beitrag zu schreiben, sind wenn eine entsprechende Anforderung in einem Projekt auftaucht. Da kann man dann immer das Schreiben mit der Recherche verbinden – so auch in diesem Fall.

In diesem Post geht es um die Möglichkeiten, das SharePoint UI mit Custom Actions zu erweitern. Dazu schauen wir uns zuerst einmal an, an welchen Stellen man das SharePoint-UI mit Custom Actions erweitern kann. Custom Actions können Links, Toolbar Buttons oder Menüeinträge sein, die man dem SharePoint UI hinzufügen oder aber auch daraus entfernen kann.

In der folgenden Tabelle habe ich einmal die Erweiterungsmöglichkeiten aufgelistet. Neben den List forms (Display, Edit, New) kann man auch den sogenannten Edit Control Block (ECB) –also das Item-Kontextmenü– und sogar die Central Administration mit Custom Actions erweitern. Auch das Site Action Menü kann mit Custom Actions erweitert werden.

Description	Location	GroupId
Display form toolbar	DisplayFormToolbar	-
Edit form toolbar	Edit form toolbar	-
New form toolbar	New form toolbar	-
List view toolbar	List view toolbar	-
List item context menu	EditControlBlock	-
New menu for list and document library view toolbars	Microsoft.SharePoint.StandardMenu	NewMenu
Actions menu for list and document library view toolbar	Microsoft.SharePoint.StandardMenu	ActionsMenu
Settings menu for list and document library view toolbars	Microsoft.SharePoint.StandardMenu	SettingsMenu
Upload documents menu for document libraries	Microsoft.SharePoint.StandardMenu	UploadMenu
Site Actions menu	Microsoft.SharePoint.StandardMenu	SiteActions
Site Settings Site Collection Administration links	Microsoft.SharePoint.SiteSettings	SiteCollectionAdmin
Site Settings Site Administration links	Microsoft.SharePoint.SiteSettings	SiteAdministration
Site Settings Galleries Links	Microsoft.SharePoint.SiteSettings	Galleries
Site Settings Look and Feel links	Microsoft.SharePoint.SiteSettings	Customization
Site Settings Users and Permissions links	Microsoft.SharePoint.SiteSettings	UsersAndPermissions
Site Actions menu for surveys	Microsoft.SharePoint.StandardMenu	ActionsMenuForSurvey
Site Settings links for survey	Microsoft.SharePoint.SiteSettings	-
Content Type Settings links	Microsoft.SharePoint. ContentTypeSettings	-
Central Administration Operations page	Microsoft.SharePoint.Administration. Operation	-
Central Administration Application Management page	Microsoft.SharePoint.Administration. ApplicationManagement	-

(Tabelle von André Vala)

Da wir jetzt wissen, welche Teile des SharePoint UI wir mit Custom Actions erweitern können, schauen wir uns an, wie man so eine Custom Action erstellt. Wie bei SharePoint üblich werden auch Custom Actions an ein Feature gekoppelt. Das erste was wir also brauchen, ist eine Datei mit dem Namen feature.xml:

<?xml version="1.0" encoding="utf-8" ?>
<Feature Id="2CF55F2C-0A07-4a2d-BF9C-63BFDE32168D"
    Title="Feature Custom Action Feature"
    Description="My Custom Action Feature Description."
    Version="1.0.0.0"
    Scope="Site"
    xmlns="http://schemas.microsoft.com/sharepoint/">
<ElementManifests>
    <ElementManifest Location="MyCustomAction.xml"/>
</ElementManifests>
</Feature>

Schauen wir uns die feature.xml etwas näher an. Unter Feature Id hinterlegen wir eine neu generierte GUID (bitte nicht von irgendwo her kopieren). Title und Description sind selbsterklärend. Interessant ist dann wieder der Eintrag ElementManifest Location. Hier geben wir den Namen einer XML-Datei an, die die eigentliche Beschreibung unserer Custom Action enthält.

Da es eine ganze Menge an möglichen Locations gibt, gibt es auch nicht die eine elements.xml. Bedeutet: je nach Location unterscheiden sich die einzelnen Parameter in der XML-Datei. Eine gute Übersicht findet sich bei MSDN oder im Blog von André Vala.

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<CustomAction
    Location="EditControlBlock"
    RegistrationType="List"
    RegistrationId="101"
    Title="My Custom Action"
    Description="My Custom Action Description">
    <UrlAction Url="http://sharepointcommunity.de/blogs/owirkus"/>
</CustomAction>
</Elements>

In meinem einfachen Beispiel möchte ich eine Custom Action in den EditControlBlock (also das Item Kontextmenü) einer Dokumentlibrary einbauen (daher die RegistrationId = 101). Interessant an der obigen elements.xml ist die Zeile UrlAction. Hier sieht man, wie die Sache mit den Custom Actions funktioniert. Man trägt im SharePoint UI über eine Custom Action einen Link oder einen Button ein und dahinter verbirgt sich immer eine URL – etwas anderes ist nicht möglich! In meinem Beispiel soll die CustomAction die Startseite meines Blogs im Browser anzeigen.

Die Installation läuft ab wie üblich. Am besten wäre es natürlich, beide Dateien z.B. mit dem WSPBuilder in eine Solution zu verpacken. Hier in meinem Beispiel möchte ich aber den manuellen Weg wählen. Zuerst erstellen wir also ein Verzeichnis mit dem Namen CustomActionDemo und dorthin kopieren wir die beiden XML-Dateien. Die erste muss feature.xml heissen, die zweite –weil in der feature.xml so festgelegt– mycustomaction.xml. Das Verzeichnis mit beiden Dateien kopieren wir nun in den 12-Hive in TEMPLATE\Feature. Danach können wir das Feature mit STSADM wie gewohnt installieren:

stsadm –o installfeature –filename customactiondemo\feature.xml

Wenn das geklappt hat können wir das Feature aktivieren:

stsadm –o activatefeature –filename customactiondemo\feature.xml –url http:\\mossdemo01 (die Url muss natürlich angepasst werden)

Wenn alles geklappt hat, sollte unser Feature in den Site Collection Features so auftauchen:

Und im SharePoint bei einer Dokumentbibliothek sieht das Ganze dann so aus:

So kann man also eine Custom Action mit einer Dokumentbibliothek verbinden. Das ist sicherlich gut um die Grundlagen von Custom Actions zu erklären, aber im praktischen Projekteinsatz ist die starre Verbindung zwischen Liste und Custom Action nicht immer sinnvoll. Da ich ein großer Fan von ContentTypes bin, habe ich mir gleich auch noch angesehen, wie man eine Custom Action mit einem ContentType verbinden kann. Prinzipiell ist die Vorgehensweise ähnlich, wir müssen nur die Einträge für RegistrationType und RegistrationId verändern.

Das sieht dann z.B. so aus:

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<CustomAction
    Location="EditControlBlock"
    RegistrationType="ContentType"
    RegistrationId="0x010100D894B664B7852642BC207CEBD680600D"
    Title="My Custom Action"
    Description="My Custom Action Description">
    <UrlAction Url="http://sharepointcommunity.de/blogs/owirkus"/>
</CustomAction>
</Elements>

Schlecht an der Konfiguration ist leider nur, dass man den ContentType über seine GUID referenzieren muss. Eine Referenzierung über den Namen klappt leider nicht! Wenn man –wie ich– ContentTypes gern über die SharePoint-Oberfläche (und weniger über Code) anlegt, dann hat man in diesem Fall leider zwei Probleme: wie komme ich an die GUID eines ContentTypes, den man über die Oberfläche angelegt hat und wie verhält sich die Sache, wenn ich vom Entwicklungssystem auf das Produktivsystem bzw. auf das Testsystem übertrage?

Erste Frage: wie komme ich an die GUID des ContentTypes? Sofern man den ContentType über die Oberfläche von SharePoint angelegt hat, gibt es meines Wissens nach nur eine Möglichkeit: aus der Statuszeile rauskopieren. Zugegeben – sehr unschön, aber immerhin möglich. Man lässt sich dazu die Site Content Type Gallery anzeigen und schiebt vorsichtig den Mauszeiger auf den Namen des ContentType – aber nicht klicken!!! In der Statuszeile wird jetzt die GUID angezeigt. Das sieht dann ungefähr so aus:

Der lange String hinter ctype= ist die GUID des ContentTypes. Wie gesagt – etwas unschön das Ganze, aber wenn jemand eine bessere Möglichkeit kennt, wäre ich froh über einen Hinweis in einem Kommentar zu diesem Post.

Zur zweiten Frage: die Übertragung vom Entwicklungssystem auf das Produktivsystem bzw. das Testsystem ist natürlich in diesem Fall etwas heikel. Sofern bei der Übertragungsmethode die GUID des ContentTypes nicht geändert wird, wird die Custom Action weiterhin funktionieren. Besser ist es, den ContentType programmatisch zu erzeugen. Auf diese Weise kann man sicherstellen, dass die GUID des ContentTypes weiterhin gültig bleibt. Allerdings gibt es durchaus Situationen, in denen der Weg über die Programmierung nicht funktioniert – z.B. wenn der ContentType bereits existiert.

Soweit zu den Basics von Custom Actions! Das Hauptproblem bei Custom Actions ist meiner Meinung nach das Erstellen der elements.xml. Je nach Location ändern sich die folgenden Parameter. Hier hilft dann wirklich nur noch ein wenig Experimentieren und ein Blick in die MSDN. Das zweite was man sicher vorher überlegen sollte: kann ich die Aktion, die durch die Custom Action ausgeführt werden soll, über einen Link ansprechen? Wenn ja, wie implementiere ich die auszuführende Aktion? Da man als Url nicht unbedingt einen festen Wert (wie in meinem Beispiel), sondern auch lokale Pfade verwenden kann, gibt es hier einige Möglichkeiten der Umsetzung.

Weitere Informationen über Custom Actions finden sich in der MSDN:

http://msdn.microsoft.com/en-us/library/ms460194.aspx

Nachtrag: man kan seine eigene Custom Action natürlich auch mit einem kleinen Icon versehen. Im 12-Hive unter TEMPLATE/IMAGES gibt es eine ganze Menge mitgelieferter Icons. Auf diese Icons kann man zurückgreifen. Dazu fügt man einfach folgende Zeile in die Datei elements.xml zwischen die CustomAction-Tags ein:

ImageUrl="/_layouts/images/lg_ICMSG.gif"

Technorati-Tags: SharePoint,Custom Action,Development

Nachtrag: Danke an Andi Fandrich für den Hinweis: klar – aus der URL im Browser kann man sich die GUID des ContentTypes auch herauskopieren. Das geht sogar besser, weil man hier mit Cut and Paste arbeiten kann. Das Ganze sieht dann so aus:

ShareConf, München, 22.-24.6.2010 – ich bin als Sprecher dabei

Oliver Wirkus — Fri, 26 Mar 2010 11:24:53 GMT

Ich freue mich Ende Juni auf der ShareConf in München als Sprecher dabei sein zu dürfen. Auf der ShareConf werde ich mich mal etwas von dem aktuellen SharePoint-2010-Hype lossagen und in meinem Vortrag nicht über Neuerungen von SharePoint 2010 berichten.

Vielmehr möchte ich mich auf Praxisbeispiele konzentrieren und von den Möglichkeiten berichten, wie man SharePoint (egal ob 2007 oder 2010) und SAP zusammenbringen kann. In meinem Vortrag zeige ich, dass man eine SAP-Anbindung an SharePoint durchaus auch mit Bordmitteln hinbekommt – Lösungen von Drittanbietern sind also nicht in jedem Fall erforderlich.

Wie gesagt – ich freue mich auf München, auf die ShareConf, einen hoffentlich spannenden Vortrag und natürlich die Gespräche mit interessierten SharePoint-Usern.

Wir sehen uns also dann in München auf der ShareConf!

P.S.: Die Agenda ist bisher noch nicht verfügbar, bis Mitte April soll diese aber veröffentlicht werden!

Technorati-Tags: Event,SharePoint,SAP

MOSS vs WSS

Oliver Wirkus — Wed, 03 Mar 2010 10:28:00 GMT

Bei vielen meiner Kundenbesuche kommt meist am Anfang die Frage nach den Unterschieden zwischen MOSS und WSS. Meist steckt hinter dieser Frage der durchaus verständliche Wunsch, bei der Einführung von SharePoint die ersten Tests und Prototypen auf WSS aufzubauen und später auf MOSS zu migrieren.

Bisher habe ich zur Beantwortung dieser Frage meine eigene Tabelle mit einer Gegenüberstellung der wichtigsten Unterschiede verwendet. Aber wirklich glücklich war ich damit nie.

Jetzt habe ich bei Miles Consulting eine ausführliche Tabelle gefunden, die die Unterschiede zwischen MOSS und WSS gut und verständlich auflistet.

Hier der Link: http://www.milesconsultingcorp.com/SharePoint-Portal-2007-Version-Comparison-between-MOSS2007-and-WSS3.aspx

SharePoint 2007 – Calculated Field Formulas

Oliver Wirkus — Thu, 11 Feb 2010 11:07:00 GMT

Ich gerade in einem Kundenprojekt sehr intensiv mit dem Thema “Berechnete Felder” (Calculated Fields) beschäftig. Bei einer Recherche nach einer Formelübersicht bin ich auf diese Seite bei Microsoft gestoßen. Microsoft gibt hier eine gute Übersicht über die Formeln und illustriert deren Verwendung anhand von Beispielen. Ideal, wenn man sich mal näher mit dem Thema Berechnete Felder beschäftigen will.

Hier der Link: http://msdn.microsoft.com/en-us/library/bb862071.aspx

Technorati-Tags: SharePoint 2007,MOSS 2007

WSPBuilder in einer neuen (Beta)-Version

Oliver Wirkus — Wed, 10 Feb 2010 14:17:00 GMT

Mein Lieblingstool im SharePoint-Umfeld liegt in einer neuen (Beta) Version vor. Carsten Keutmann hat seinen WSPBuilder erweitert und unterstützt nun zusätzlich SharePoint 2010 und Visual Studio 2010.

Zum Glück werden aber auch SharePoint 2007 und Visual Studio 2005 und Visual Studio 2008 weiter unterstützt. Carsten ist die Backward-Compatibility sehr wichtig – und dies gilt sicher auch für alle SharePoint-Entwickler.

Alle neuen Features mit ausführlichen Erklärungen und Screenshots finden sich in seinem Blog.

Hier der Link: http://keutmann.blogspot.com/2009/12/wspbuilder-2010-beta.html

Technorati-Tags: SharePoint 2007,MOSS 2007,SharePoint 2010,Visual Studio 2010

BASTA! Spring 2010 - Ich bin als Sprecher dabei

Oliver Wirkus — Fri, 08 Jan 2010 12:04:00 GMT

Ich freue mich, als Sprecher auf der BASTA! Spring 2010 (22. - 26.2.2010 in Darmstadt) zwei Vorträge zu den Themen "Best Practices in der WebPart-Entwicklung" und "Custom Field Types - Entwicklung und Einsatzmöglichkeiten" halten zu dürfen.

Weitere Infos zur BASTA! Spring 2010 gibt es über diesen Link: http://it-republik.de/dotnet/basta10spring/

Eine Liste aller Sprecher und ihrer Themen gibt es hier: http://it-republik.de/dotnet/basta10spring/speaker/

Ich freue mich auf auf interessante Vorträge und gute Gespräche!

Treffen wir uns am 25.2.2010 auf der BASTA! Spring 2010 in Darmstadt :-)

Übrigens: hier die Daten zu meinen beiden Vorträgen:

Nachtrag: es gab eine kleine Änderung - mein Vortrag "Best practices in der WebPart-Enwicklung" findet nun etwas später statt.

Nachtrag: Ich habe heute Nachmittag erfahren, dass mein zweiter Vortrag (Best Practices in der WebPart-Entwicklung) auf Video aufgezeichnet und veröffentlicht werden soll. Das freut mich natürlich und es wäre für mich eine echte Premiere :-) Daher bin ich für Unterstützung in Form eines großen Publikums sehr dankbar. Also - wer mit auf's Video will sollte in meine Session kommen :-)