In SharePoint 2010 gibt es mehrere Möglichkeiten, um kundenspezifische Voreinstellungen für neu angelegte Websites zu automatisieren. Durch diese Art der Vorkonfiguration wird der administrative Aufwand für neue Website massiv reduziert. Als Resultat dieser Anpassungen kann eine neue Website in Optik und Verhalten komplett vom SharePoint-Standard abweichen und so gut wie jede Kundenanforderung erfüllen.

Generell gibt es in SharePoint drei verschiedene Varianten, um Voreinstellungen automatisiert auszuführen:

  1. Das WebProvisioned-Event:
    Wem man sich auf dieses Event registriert, wird die eigene Provisionierungs-Logik unabhängig von der Website-Vorlage bei jeder neuen Website aufgerufen. Soll auf verschiedene Vorlagen unterschiedlich regiert werden, kann dies nur serverseitig geschehen, was nicht sehr charmant ist und bei Anpassungen immer ein Kompilieren des Quellcodes (inkl. aller Tests) mit sich bringt.
  2. Staple-Feature:
    Mit einem Staple Feature kann exakt definiert werden, welches Feature beim Erstellen einer neuen Website mit einer Vorlage aktiviert werden soll. Das automatisch aktivierte Feature kann dann mit Hilfe eines “Feature Event Receivers” die Provisionierungs-Logik ausführen.
  3. Über die Klasse “SPWebProvisioningProvider” direkt aus der Vorlage heraus:
    In der Definition einer eigenen Website-Vorlage kann eine SPWebProvisioningProvider-Klasse inklusive beliebiger Input-Daten angegeben werden. Dieses Szenario ist immer dann interessant, wenn ein Kunde eigene Website-Vorlagen benötigt.
    Die SharePoint-Standard-Vorlagen dürfen nicht modifiziert werden! Bei ihnen darf daher nur der Staple Feature-Ansatz verwendet werden. Für eigene Website-Vorlagen allerdings ist der SPWebProvisioningProvider-Ansatz ideal und wird daher nachfolgend tiefer erläutert.

In der Definition einer eigenen Website-Vorlage mit Provisionierungs-Logik müssen drei Angaben vorhanden sein:

  1. ProvisionAssemply: Die vollqualifizierte Angabe der DLL
  2. ProvisionClass: Der Name der Klasse inkl. Namespace
  3. ProvisionData: Jegliche Daten in String-Format (XML, DateiPfad, etc.)

In der Praxis sieht die Definition einer Website-Vorlage mit integrierter Provisionierungs-Komponente wie folgt aus. Hier ist die Definition der “out-of-the-box” Veröffentlichungsvorlage zu sehen. 

 <Template Name="BLANKINTERNETCONTAINER" ID="52">
    <Configuration ID="0" Title="Publishing Portal" Hidden="FALSE" ImageUrl="/_layouts/1033/images/IPPT.gif" Description="A starter site hierarchy for an Internet-facing site or a large intranet portal. This site can be customized easily with distinctive branding. It includes a home page, a sample press releases subsite, a Search Center, and a login page. Typically, this site has many more readers than contributors, and it is used to publish Web pages with approval workflows."
        ProvisionAssembly="Microsoft.SharePoint.Publishing, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c"
        ProvisionClass="Microsoft.SharePoint.Publishing.PortalProvisioningProvider"
        ProvisionData="xml\\InternetBlank.xml"
        RootWebOnly="TRUE" DisplayCategory="Publishing" VisibilityFeatureDependency="97A2485F-EF4B-401f-9167-FA4FE177C6F6">
         
    </Configuration>
 </Template>

Folgende Besonderheit muss bei diesem Ansatz beachtet werden:

Wenn eine “ProvisionClass” in der Vorlage angegeben wurde, dann muss  in der Provisionierungs-Logik erneut eine Website-Vorlage zugewiesen werden! (Geschieht dies nicht, muss die Vorlage beim Öffnen der angelegten Website von Hand neu zugewiesen werden.)

Und jetzt kommt die Stolperfalle:

Es darf programmatisch nicht erneut die selbe Website-Vorlage zugewiesen werden, da es sonst zu einer Endlosschliefe  kommt.

  
Die Grundstruktur einer einfachen Provisionierungs-Komponente sieht wie folgt aus:

namespace HanseVision.Demo.Provisioning.Logic
{
    public class SimpleCustomProvisioner : SPWebProvisioningProvider
    {   
        public override void Provision(SPWebProvisioningProperties properties)
        {
            try
            {
                if(properties != null &amp;&amp; !String.IsNullOrEmpty(properties.Data))
                {
                    string appyTemplateName = properties.Data; // Name of the template to assign (for example: sts#1)

                    SPWeb web = properties.Web;
                    SPWebTemplateCollection collWebTemplates = web.Site.GetWebTemplates((uint)Thread.CurrentThread.CurrentCulture.LCID);
                    SPWebTemplate oWebTemplate = collWebTemplates[appyTemplateName];

                    //not the same as assigned in the SP UI 
                    web.ApplyWebTemplate(oWebTemplate);

                    //ToDo: Enter your provisioning logic here
                }
            }
            catch (Exception exception)
            {
                //logging
                throw exception;
            }
        }
    }
}

Da nicht erneut das selbe Template zugewiesen werden darf, müssen ggf. zwei Website-Vorlagen erstellt werden. In der Praxis hat sich der Ansatz bewehrt  eine sichtbare Vorlage mit der Provisionierungs-Anweisung und eine versteckte, die programmatisch zugewiesen wird, umzusetzen. Der Mehraufwand für die zweite Website-Vorlage geht gegen null, da die erste Definition als Kopiervorlage dienen kann.

<Templates xmlns:ows="Microsoft SharePoint">
  <Template Name="Demo" ID="10001">
    <Configuration ID="0" 
                   Title="Eigene Projekt-Teamsite" 
                   Hidden="False" 
                   ImageUrl="/_layouts/images/stts.png" 
                   Description="Eigene Projekt-Bereichs Website" 
                   DisplayCategory="Demo"
                   ProvisionAssembly = "HanseVision.Demo.Provisioning, Version=1.0.0.0, Culture=neutral, PublicKeyToken=11e99323d9a1fb04"
                   ProvisionClass = "HanseVision.Demo.Provisioning.Logic.SimpleCustomProvisioner"
                   ProvisionData = "Demo#"

                   >       
    </Configuration>
    <Configuration ID="1"
               Title="Versteckte Demo Projekt Team Site"
               Hidden="True"
               ImageUrl="/_layouts/images/stts.png"
               Description="Versteckte Demo Projekt Demo Website. Wird programmatisch zugewiesen."
               DisplayCategory="Demo"  >
    </Configuration>
  </Template>
</Templates>

 

Mit Hilfe des Ansatzes können ganze Website-Strukturen automatisch generiert und konfiguriert werden. Dazu macht es Sinn die Konfiguration der Provisionierungs-Logik in einer XML-Datei im 14 Hive-Ordner zu speichern. Über die “ProvisionData”-Angabe kann der Pfad zu dieser Datei der eigenen Komponente übergeben werden. 

Leave a comment

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.

Time limit is exhausted. Please reload the CAPTCHA.