*Gratis* SharePoint 2013 training for IT pros

SharePoint 2013 training for IT pros...

Een cursus in 14 modules een goede inleiding op SharePoint 2013. Met presentaties en video materiaal.

Module 1: SharePoint 2013 IT pro introduction and overview
Module 2: SharePoint 2013 system requirements
Module 3: SharePoint 2013 architectural changes
Module 4: SharePoint 2013 server farms and site architecture planning
Module 5: Office Web Apps 2013 architecture and deployment
Module 6: SharePoint 2013 service application architecture and individual service applications
Module 7: SharePoint 2013 enterprise search overview
Module 8: SharePoint 2013 social features
Module 9: SharePoint 2013 enterprise content management and web content management considerations
Module 10: SharePoint 2013 customization options and management
Module 11: SharePoint 2013 authentication and authorization overview
Module 12: Overview of SharePoint 2013 business continuity management
Module 13: Upgrading to SharePoint 2013
Module 14: What’s new for IT pros in Project 2013

5 Zaken die NIET in SharePoint architectuur documentatie thuis horen

Ik mijn werk kom ik regelmatig architectuur documenten tegen; ik maak ze zelf, ik gebruik ze en ik review ze. Hoewel iedere situatie weer anders is, kom ik vaak een aantal zaken tegen waarvan ik vind dat ze niet thuis horen in architectuur documentatie.

In deze blogpost de top 5...

1. Een beschrijving van de werking en het gebruik van SharePoint

Op eenzame hoogte: de "SharePoint handleiding" als onderdeel van de architectuur. Pagina's lange beschrijvingen hoe site collecties en site in elkaar zitten, hoe bibliotheken kunnen worden ingericht en welke "out-of-the-box" rollen bij welke rechten horen. Misschien interessant voor een beginnende SharePoint gebruiker, maar niet voor de doelgroep van de architectuur. Bovendien denk ik dat bij SharePoint architecturen juist niet de "standaard" van belang is te beschrijven, maar de wijzigingen die hierop zijn aangebracht.

2. Details, details, details

Er valt aan SharePoint veel in te stellen. En natuurlijk moet dat allemaal gedocumenteerd worden. Het is alleen de vraag waar dat moet gebeuren. Veel informatie hoort niet thuis in een architectuur document en kan verhuizen naar technische documentatie. Een architectuur document hoort de relevante hoofdlijnen te beschrijven en niet de details.

3. Project afhankelijke informatie

Projecten zijn veranderingen op de korte termijn, een architectuur beschrijft in het algemeen de richtlijnen voor de langere termijn. Voor een project relevante principes en richtlijnen (en afwijkingen hierop) horen thuis in een Project Start Architectuur (PSA). Project overstijgende zaken horen thuis in een referentie -, domain - of enterprise architectuur.

4. Architectuur als schetsboek van een eilandbewoner

Een architectuur is een communicatiemiddel; het geeft regels die in de praktijk gebruikt moeten worden. Daarvoor is 1) begrip en 2) draagvlak nodig. Veel architectuurdocumenten verdwijnen in de spreekwoordelijke lade omdat ze niet worden bijgehouden, daarom verouderen en onbruikbaar worden. Zonde van tijd en geld en uiterst frustrerend voor de architect en voor de CIO. Oorzaak hiervan ligt vaak bij de betrokkenheid van de organisatie bij het opstellen van de architectuur en door het type architect. Organisaties hebben veelal de neiging om "het maken van een architectuur ergens te beleggen" en vervolgens het resultaat af te wachten. Daarnaast zie ik dat architecten vaak de neiging hebben om "het beter te weten", "de hele wereld volgens eigen inzicht te willen modelleren" en dit "in hun eigen taal" te willen doen. Met dat laatste doel ik op de bonte verzameling PowerPoint plaatjes waarmee architectuurdocumenten regelmatig worden opgefleurd.

5. Her-her-her-herhaling

Copy and paste is makkelijk en staat garant voor lijvige documenten. Nadelen zijn: verminderde leesbaarheid en verminderde onderhoudbaarheid (wijzigingen moeten op meerdere plaatsen worden doorgevoerd). Ook hier geldt: "less is more".

Om de bovenstaande valkuilen te vermijden, de volgende tips voor SharePoint architecten:

1. Schrijf een architectuur document met het doel ervan in gedachten. Stem het document hierop af en beperk je daarbij. Aanvullende informatie wordt niet gebruikt en ontmoedigt het lezen en gebruiken ervan. Beperk je tot het niveau (waarom, wat, hoe en waarmee) en tot de aspecten (Business, Informatie, Informatie systemen, Infrastructuur, Security, Governance, et cetera) die echt relevant zijn.

2. Voortbouwend op het vorige punt: baken de scope van de te beschrijven architectuur duidelijk af. Bepaal hiervoor vantevoren duidelijk hoe het architectuur landschap wordt ingedeeld en welke delen in het de betreffende architectuur document worden beschreven. Geef ook expliciet aan welke delen buiten scope vallen.

3. Schrijf je architectuur document met de gebruikstermijn in gedachten. Legt een architectuur document richtlijnen vast voor de gehele organisatie (zoals een enterprise -, referentie of domain architectuur), dan mag dit slechts zeer beperkt aan verandering onderhevig zijn.

4. Kom van je eiland af en betrek de doelgroep!
Gebruik architectuur als een echt communicatiemiddel; stem het al op de doelgroep, gebruik raamwerken, talen en technieken (b.v. Archimate, IAF) die open en vrij verkrijgbaar zijn en betrek de doelgroep actief vanaf het begin. Zodoende kan voldoende getest worden of de doelgroep de architectuur nog begrijpt (b.v. door regelmatige reviews, inspraak sessies en informele gesprekken) en of de architectuur nog "gedragen" wordt.

Maatwerk, configuratie en out of the box: waarom en hoe onderscheid maken?

Ik hoor de discussie overal; waar ik ook kom, altijd wordt dezelfde discussie gevoerd: wat is precies maatwerk? En hierbij wordt maatwerk ook altijd angstvallig vermeden.

Tijd om eens wat dieper in te gaan op dit vraagstuk, om duidelijkheid te scheppen en handvatten te geven hoe hiermee om te gaan.

Waarom onderscheid tussen out of the box en maatwerk?
Maatwerk wordt in het algemeen geassocieerd met dure software ontwikkeling in een programmeertaal als C#, lange trajecten, duur in onderhoud en lastig overdraagbaar. Out of the box, daarentegen, wordt geassocieerd met goedkope en snelle ontwikkeling.

Het laatste is voor klanten (management, business) natuurlijk veel aantrekkelijker dan maatwerk, terwijl voor de gebruiker (business) en voor de programmeur (techniek) maatwerk interessanter is.

Voorkeur wordt voor een belangrijk deel gekleurd door emoties (ja, zelfs bij technici) en de gevolgen daarvan kunnen voor een project of programma het verschil betekenen tussen succes of falen.

Voorbeelden hiervan te over, bijvoorbeeld op aanbestedingsgebied. Hierin wordt door de klant vaak "out of the box" geëist waaraan in eerste instantie ook door de leverancier wordt voldaan. Gedurende de implementatie blijft dat maatwerk toch de voorkeur geniet (of zelfs noodzakelijk is), waarna zowel de implementatie doorloop tijd als de bijbehorende kosten door het dak gaan.

Resultaat: klant ontevreden en de leverancier en/of de gekozen technologie (of het platform) krijgen de schuld.

Jammer en niet nodig, als vantevoren maar nagedacht was geweest over de verschillende "smaakjes" en de gevolgen daarvan. In het woord "nadenken" zit het woordje "na", maar dat wil niet zeggen dat je pas ergens na moet gaan denken.

Maar waar gaat het eigenlijk mis?

De beloften van platforms en tooling
De laatste jaren bieden (webportal)platforms (dms,ecm, collaboration), veel beter dan vroeger, mogelijkheden om snel tot resultaat te komen door standaard (out of the box) basis functionaliteit te bieden waarmee de eindgebruiker relatief snel aan de slag kan. Ook tooling biedt steeds meer mogelijkheden voor niet software "gurus" om de functionaliteit van platformen aan te passen en uit te breiden.

Allemaal mooie ontwikkelingen, maar ontwikkelingen die hoge verwachtingen kunnen veroorzaken... en zelfs te hoge verwachtingen...

In de praktijk blijkt namelijk het volgende:
1. Out of the box functionaliteit is vaak te generiek om specifieke business processen te ondersteunen.
2. De eindgebruiker (en de business in het algemeen) weten te weinig af van de standaard mogelijkheden van platforms.
3. De eindgebruikers (en de business in het algemeen) zijn onvoldoende bereid zich neer te leggen bij de discrepanties tussen de eigen werkwijze en de werkwijze die het betreffende platform oplegt.
4. Projectmanagers (ICT, business) bieden onvoldoende weerstand aan de eis van de business om het platform te veranderen, hebben te weinig inhoudelijke bagage om te weten waar de grenzen van een platform liggen en geven specialisten te weinig inspraak bij belangrijke beslissingen die hierover worden gemaakt.

Om juiste beslissingen (lees: waar de klant tevreden mee is en waarvoor hij een redelijke prijs/doorlooptijd voor betaalt) is het nodig om zicht te hebben op de volgende zaken:

Wat wordt (in termen van het platform waaraan gesleuteld wordt) verstaan onder maatwerk? Zijn er gradaties hierin? Welke zijn dit, wat bieden ze aan mogelijkheden, beperkingen?

Wat zijn de gevolgen van de keuze voor een bepaalde gradatie? Wat is hiervoor nodig in termen van kosten en doorlooptijd?

Van out-of-the-box tot maatwerk: definities

Laat ik beginnen met een aantal definities die ik al een tijdje gebruik, en kijken of we die kunnen verbeteren (let wel: het gaat hier om SharePoint):

Out-of-the-box (OOTB): the supporting platform supports the recommended solution by default;
Configuration: the configuration of the supporting platform needs to be changed to support the recommended solution;
Limited Customization: adaptations by means of configuration, browser supported or SharePoint related tooling (e.g. Designer, InfoPath , XSLT);
Customization: software components of the supporting platform need to be changed / extended to support the recommended solution;
Extension: new, independent, software components need to be added to the supporting platform to support the recommended solution.

Van out-of-the-box tot maatwerk: definities
De volgende stap is even terug te gaan naar de vraag achter de vraag, namelijk waarom onderscheid gemaakt wordt tussen de verschillende categorieën. Deze vraag komt vaak neer op het willen beoordelen of een bepaalde oplossing te veel "pijn" gaat doen of niet. Ik heb expres de term "pijn" gebruikt, want in iedere situatie is deze pijn weer anders en wordt deze pijn andere gevoeld. "Pijn" kan betekenen dat een bepaalde oplossing duur is om te ontwikkelen, te veel onderhoud kost of lastig te migreren is naar een ander platform en daarom toekomstige pijn in de portemonnee (lees: budgetten) kost. Pijn kan ook betekenen dat de eindgebruikers (de business) onvoldoende worden ondersteund door de betreffende oplossing omdat deze bijvoorbeeld te weinig mogelijkheden biedt of te ver afstaat van de bestaande werkprocessen.

Bij de afweging tussen maatwerk en het gebruik van out-of-the-box functionaliteit moet dus gekeken worden  waar de "pijn" gelegd moet worden.

Projectmanager en opdrachtgever: kijk verder dan jullie neuzen lang zijn
Bovenstaande voorbeelden illustreren dat pijn voorkomt binnen en buiten het project waarin de oplossing ontwikkeld wordt. Een projectmanager is aangeleerd om zijn zaken binnen het project tijdig, binnen budget en kwaliteitseisen te realiseren, hetgeen natuurlijk op zich goed is, maar in de praktijk vaak niet voldoende blijkt te zijn. De "pijn" die binnen het project wordt vermeden kan buiten het project des te harder aankomen. Een goed voorbeeld hiervan is migratie; in migratieprojecten moeten gevolgen van beslissingen in eerder projecten vaak worden gecorrigeerd. Met name ongecontroleerd toestaan van maatwerk komt tijdens een migratietraject een organisatie duur te staan.

Het is daarom een goede zaak om verder te kijken dan het project zelf, bijvoorbeeld naar het overkoepelende programma of zelfs naar het overkoepelende informatieplan of de enterprise roadmap.

Ee doeltreffend denkraam hierbij is de software life cycle. Hierin wordt grofweg weeggegeven in welke levensfasen software zich kan bevinden en vormt daarmee een denkraam vanwaaruit bepaald kan worden welke gevolgen de keuze van maatwerk of out-of-the-box (of een variant hierop) heeft.

Samenvatting en conclusie
Een platform biedt (potentieel) een middel om snel een oplossing te bieden aan de business. Keuzes bij het aanpassen van het platform aan de wensen en eisen van de business dienen vantevoren goed te worden doordacht, waarbij verder gekeken moet worden dan de eerste op te leveren versie.

Vantevoren (samen met experts) nadenken is hierbij een betere investering dan achteraf de gevolgen van slechte beslissingen te moeten corrigeren.

Aanpassen van SharePoint lijst weergaven met JavaScript

Een tijdje geleden heb ik blogposts gemaakt over het aanpassen van de SharePoint user interface middels JavaScript (zie links onderaan deze blog post onder "Verder lezen"). Het ging toen over edit pages van lijst items waarin ik velden manipuleerde door er JavaScripts op los te laten waarmee ik, na het laden van de pagina, veldwaarden, gedragingen en opmaak kon wijzigen.

Onlangs vroeg een klant mij om een soort dashboard te maken waarin bij taken werd vermeld of ze op tijd danwel te laat waren afgerond. Iets dat je gemakkelijk met de juiste tools kunt maken. Helaas had ik ook in dit geval weer niet de beschikking over deze tools (en ook niet de juiste rechten), zodat ik weer moest terugvallen op de "dirty JavaScript tricks" die ik eerder had gebruikt.

Reden om na de opdracht maar weer eens een blog post te schrijven... hieronder het recept van mijn oplossing...

Ingredienten
- Een lege web part pagina.
- Een takenlijst met "due date" (datum/tijd) waarop een taak afgerond moet zijn.
- Een stukje JavaScript waarvan ik de werking hieronder zal toelichten.
- Een Image library met daarin de plaatjes voor de LED's.

Doel
Een lijst met daarin voor iedere taak, waarvan de "due date" datum/tijd kleiner is dan de huidige datum/tijd (today), een indicatie dat de taak niet op tijd is afgerond. In dit geval heb ik gekozen voor een rood LEDje (lampje).

Probleem
In SharePoint is het niet mogelijk om de huidige datum/tijd (Today) te gebruiken in een berekende kolom. Het is dus helaas niet mogelijk om in een berekend veld aan te geven of een taak te laat is afgerond.

Oplossing

Stap 1: Uitbreiden van de takenlijst met een extra kolom met een gemakkelijk te herkennen berekende waarde
Oplossing die ik hiervoor heb gekozen is om een aparte kolom toe te voegen waarin ik de "due date" in een eigen formaat weergeef. Dit formaat heb ik gekozen om er zeker van te zijn dat de datum - en tijd delen (jaar, maand, dag etc.) in een vaste volgorde worden weergegeven. Afhankelijk van instellingen kan het datum formaat namelijk anders zijn dan gewenst. Verder wil ik dat de kolomwaarden van de "due date" gemakkelijk door JavaScript zijn te herkennen zodat ik deze gemakkelijk kan inlezen en gebruiken. Hiervoor heb ik een berekende kolom gemaakt met de volgende formule:

=TEXT(DueDate,"~yyyy~m~d~h~m~s~")

Hierin wordt de DueDate omgezet in een string waarde met daarin het jaar in 4 karakters, de maand in minimaal 1 karakter, et cetera.

Dit resulteert in kolomwaarden zoals: <TD Class="ms-vb2">~2013~3~22~8~30~0~</TD>

In een SharePoint lijst zijn deze velden dus gemakkelijk te herkennen:
<TD Class="ms-vb2">~2013~3~22~8~30~0~</TD>

Stap 2: Aanmaken van een web part pagina met daarin de lijst en een Content Editor Web Part
De lijst moet zichtbaar zijn in een web pagina. Gezien de lijst moet worden aangepast met JavaScript is een Content Editor Web Part nodig waarin we het JavaScript plaatsen waarmee de lijst wordt aangepast. Van belang is dat het Content Editor Web Part onder de lijst wordt geplaatst. Reden hiervoor is dat de DOM nodes in de lijst beschikbaar moeten zijn voor het JavaScript.

Het JavaScript dat ik het Content Editor Web Part wordt geplaatst heeft de volgende functionaliteit:
- GetAllListFields: functie die de speciale lijstvelden opneemt in een array (vIconListFields). Zo kunnen we ze gemakkelijk gebruiken. Leuke extra uitdaging hierbij is dat je hiervoor de getElementsByClassName functie nodig hebt die in IE niet voorhanden is. Daarvoor heb ik een aparte functie gemaakt.
- ConvertFieldsToIcons: functie die de objecten in de vIconListFields array uitleest, bepaalt of de data/tijden daarin eerder of later vallen dan de huidige datum/tijd, en de HTML code in de objecten vervangt door een rood of groen plaatje (LED).

Omdat ik het niet kon laten moest ik de LED's ook laten animeren. Een rode LED wordt geanimeerd zodat het gaat flikkeren. Hiertoe laat ik het plaatje middels een setInterval JavaScript call varieren.

De volledige JavaScript code hieronder, happy coding!

<script language="JavaScript">

// ----------------------------------------
    // Global constants and variables
var vIconListFields = new Array();

// ----------------------------------------
// Functions
    function GetAllListFields(ioIconListFields) {

        // Look for nodes like &lt;TD Class="ms-vb2"&gt;~2013~3~22~8~30~0~&lt;/TD&gt;
 
   vAllMsVb2Nodes = document.getElementsByClassName("ms-vb2");

for (var vIndex = 0; vIndex &lt; vAllMsVb2Nodes.length; ++vIndex ) {

if ( 
   vAllMsVb2Nodes[vIndex].innerText.substring(0,1) == "~" &&
vAllMsVb2Nodes[vIndex].innerText.substring(vAllMsVb2Nodes[vIndex].innerText.length-1, vAllMsVb2Nodes[vIndex].innerText.length) == "~"
) {
   // Add node to Fields array
ioIconListFields[ioIconListFields.length] = vAllMsVb2Nodes[vIndex];
}

}

    }

function ConvertFieldsToIcons(ioIconListFields) {

   var vCurrentDateTime = new Date();
var vTimeDifference;

for (var vIndex = 0; vIndex &lt; ioIconListFields.length; ++vIndex ) {

// Get date in DOM field into Date object to compare with current date/time
var vDateTimeArray = ioIconListFields[vIndex].innerText.split("~");
   var vDateTime = new Date(vDateTimeArray[1], vDateTimeArray[2], vDateTimeArray[3], vDateTimeArray[4], vDateTimeArray[5], vDateTimeArray[6], 0);

vTimeDifference = vDateTime.getTime() - vCurrentDateTime.getTime();

// Change contents off DateTime cell according to TimeDifference
if (vTimeDifference&gt;=0) {
   ioIconListFields[vIndex].innerHTML = "&lt;img src='http://portal.demo.intra/DigitaalLoket/StatusIcons/icon_green.png'/&gt;";
}
else {
  ioIconListFields[vIndex].innerHTML = "&lt;img class='AnimatedLED' src='http://portal.demo.intra/DigitaalLoket/StatusIcons/icon_red.png'/&gt;";
}

// Dispose
delete vDateTime;
}

}

function changeImage()
{

if ( vCurrentImageFileIndex &lt; vImageFiles.length - 1 )
++vCurrentImageFileIndex;
else
vCurrentImageFileIndex = 0;

for ( var i = 0, len = vImageObjects.length; i &lt; len; i++ ) {
vImageObjects[i].src = vImageFiles[vCurrentImageFileIndex];
}

}
   
// ----------------------------------------
   // Helper functions

   // Implement getElementsByClassName because IE does not support this natively

if (!document.getElementsByClassName) {

document.getElementsByClassName = function(classname) {
var elArray = [];
var tmp = document.getElementsByTagName("*");
var regex = new RegExp("(^|\\s)" + classname + "(\\s|$)");
for (var i = 0; i &lt; tmp.length; i++) {

if (regex.test(tmp[i].className)) {
elArray.push(tmp[i]);
}
}

return elArray;
};
}

// ----------------------------------------
// Main procedure

    GetAllListFields(vIconListFields);
ConvertFieldsToIcons(vIconListFields);

// Initialize animation function

var vImageFiles = new Array();
vImageFiles[0] = "http://portal.demo.intra/DigitaalLoket/StatusIcons/icon_clear.png";
vImageFiles[1] = "http://portal.demo.intra/DigitaalLoket/StatusIcons/icon_red.png";

var vCurrentImageFileIndex = 0;
var vImageObjects = document.getElementsByClassName("AnimatedLED");

setInterval("changeImage()", 500);

</script>

Verder lezen
SharePoint 2010 Content Editor Web part maakt rommel van mijn JavaScriptjes
Aanpassen van lijst- en bibliotheekformulieren in SharePoint 2010, zonder SharePoint Designer of InfoPath
Aanpassen van standaard webpagina's voor nieuwe items en bewerken van items: een generieke aanpak

Help! Mijn web part doet het niet! Een checklist voor het debuggen...

Komen de volgende foutmeldingen bekend voor als je een web part werkend wilt krijgen?

"A Web Part or Web Form Control on this Page cannot be displayed or imported. The type could not be found or it is not registered as safe"

"Cannot import web part"

De volgende checklist kan je misschien met de oorzaak van het probleem helpen:

1. Controleer of het betreffende web part is opgenomen in de Web Part Gallery

2. Controleer of de xml in de Web Part Gallery (View XML) overeen komt met de .webpart XML in je solution

3. Controleer de assembly paden in je .webpart files:

Deze paden zijn case sensitive, aaa is anders dan AAA.
Is het Public Key Token in het Assembly Path opgenomen?

4. Controleer de inhoud van de wsp solution file, zitten alle onderdelen erin?

De wsp solution file is een zip-file (of cab file) die je kunt renamen in .cab zodat je de inoud ervan kunt controleren.

5. Na een update van de Web Part solution (retract, delete, add, deploy) worden:
- Web Part Gallery bijgewerkt
- Web Parts in pages updated

Als dat niet het geval is:
- Verwijder en herinstalleer de solution dan handmatig (retract, delete)
- Verwijder de web parts uit de Web Part Gallery
- Disable de bijbehorende feature.

Daarna:
- Handmatig de solution weer installeren (add, deploy)
- Eventueel (als het Web Part nog steeds niet werkt): deactiveer de bijbehorende feature, verwijder de Web Parts handmatig uit de Gallery, en activeer de feature weer zodat de Web Part Gallery weer wordt gevuld.

6. Is de bijbehorende DLL in de GAC opgenomen? Met de juiste naam en versie?

Voor de GAC, zie de commandline tool gacutil of de map "C:\WINDOWS\assembly".
Let op: versienummers als "1.0.*" werken soms niet, gebruik liever de volledige versie nummering, bijvoorbeeld: "1.0.0.0".

7. Controleer of het betreffende web part als "safe" is aangemerkt in de web.config.

Deze wordt aangepast zodra de solution wordt deployed, in de SafeControls sectie. Controleer hier ook de paden, het versienummer en het PublicKeyToken.

8. Controleer de SharePoint logfiles "C:\Program Files\Common Files\Microsoft Shared\web server extensions\12\logs" op fouten.

9. Kijk kritisch naar de programmacode van het betreffende web part:
- Controleer de programmacode op de juiste class declaraties (naamgeving) en het gebruik van "public".
- Fouten als het aanpassen van properties die niet bestaan, etc..

10. En af en toe een extra iisreset na installatie kan ook helpen... ;)

Bij het debuggen van web parts is het belangrijk om nauwkeurig te zijn: een foutje zit in een klein hoekje en SharePoint is erg kritisch.

Content publiceren binnen of buiten een Site Collectie: wat kan en wat kan niet?

Of je content vanuit de ene site in een andere kunt publiceren is eigenlijk afhankelijk of beide sites binnen dezelfde Site Collectie liggen of niet.

Publiceren binnen dezelfde Site Collectie

Als dat het geval is kun je gegevens van de ene site met de andere site delen door b.v. het Content Query Webpart te gebruiken. Liggen de plaatsen waar de content moet worden gepubliceert binnen dezelfde site (b.v. verschillende webpagina's binnen dezelfde site), dan zijn hiervoor (per Lijst of Bibiotheek) standaard Webparts in de Gallery beschikbaar.

Publiceren buiten een Site Collectie

Als de sites in verschillende Site Collecties liggen dan zou dit met de zoekfunctie kunnen (zoekpagina’s kunnen informatie over verschillende Site Collecties heen verzamelen). Nadeel van gebruik van de zoekmachine is dat er een tijd zit tussen het publiceren van content en het daadwerkelijk zien ervan in een andere Site Collectie, omdat de zoekmachine de content eerst moet indexeren voordat deze beschikbaar is voor publicatie. Deze vertraging is dan afhankelijk van de frequentie waarin de content wordt geïndexeerd (meerdere keren per dag is gebruikelijk).

Andere mogelijkheden

Alternatieven zijn:

• Gebruik maken van RSS (op een lijst of bibliotheek kan een RSS feed worden aangezet en deze feed kan in een andere site of Site Collectie worden gebruikt in een RSS Webpart). Wel moet dat zijn toegestaan middels een instelling door systeembeheer in de SharePoint omgeving).
• Zelf een Webpart ontwikkelen waarin een CAML Query wordt gebruikt om content te verzamelen over sites of Site Collecties.
• Gebruik maken van al aanwezige (third party) Webparts die daarvoor speciaal zijn ontwikkeld en die al beschikbaar zijn in de Webpart Gallery. Anders kan een oplossing worden aangekocht die door een third party is ontwikkeld (zoals een Webpart dat over meerdere Site Collecties kan worden gebruikt, als http://www.lightningtools.com/pages/lightning-conductor-web-part.aspx).

Content Types en kolommen in Site Collecties en Subsites: hoe werkt het, en valkuilen, tips en truuks

Waarom dit artikel?
In de praktijk zie ik regelmatig problemen (die je als projectmanager natuurlijk "uitdagingen" zou noemen) met metadata (kolommen) en metadata sets (Content Types) in SharePoint omgevingen. Regelmatig worden  wijzigingen doorgevoerd waarna onverwachte en vervelende situaties ontstaan. Veel van die situaties zijn te herleiden tot te weinig begrip metadata(sets) binnen SharePoint en de wijze waarop SharePoint hiermee omgaat. Daarom in dit artikel een praktische inleiding hierop, aangevuld met praktische tips en valkuilen. Dit artikel zal ik de komende tijd verder uitbreiden, reden om regelmatig terug te keren.

Metadatering in SharePoint
Dat metadatering belangrijk is, daar ga ik in dit artikel niet op in, dat is te lezen in Metadata: belang, inleiding en hoe ermee om te gaan. Laat ik beginnen met uit te leggen hoe metadatering in het algemeen en binnen SharePoint is geïmplementeerd...

Metadata in lijsten en bibliotheken
Lijsten en bibliotheken kunnen voorzien worden van kolommen. Wanneer een item aan een lijst, of een document aan een bibliotheek wordt toegevoegd, kunnen deze kolommen worden gebruikt om het betreffende lijstitem of document te beschrijven. De kolommen zijn dan kenmerken van de items resp. de documenten. Veelgebruikte kolommen zijn bijvoorbeeld: auteur, datum van opslag en titel.

Op deze manier wordt ieder item in een lijst en ieder document in een bibliotheek voorzien van dezelfde kenmerken, dezelfde "metadata set", namelijk de kolommen die voor de lijst resp. de bibliotheek zijn gedefinieerd.

Wanneer je echter verschillende typen documenten hebt, en je wilt voor ieder type document of item een andere verzameling kenmerken (metadata set) wilt gebruiken, dan volstaat de bovenstaande aanpak niet. Ook als je metadata sets wilt hergebruiken voor meerdere lijsten of bibliotheken is er meer nodig dan alleen kolommen in een lijst of bibliotheek. En als metadata sets elkaar overlappen en je wilt deze metadata sets doelmatig onderhouden, dan is er meer nodig dan alleen kolommen.

Wat hierbij helpt zijn Content Types, herbruikbare metadata sets.

Herbruikbare metadata sets: Content Types
Alle content; documenten (web pagina's, Office documenten, plaatjes, PDF's en alle andere typen bestanden), maar ook lijstitems kunnen worden beschreven door er kenmerken (b.v. titel, auteur, datum aanmaak) aan te koppelen. Deze kenmerken, kolommen, worden ondergebracht in verzamelingen, metadata sets. Deze metadatasets worden binnen SharePoint "Content Types" genoemd. Aan documenten en lijstitems kunnen binnen SharePoint dus Content Types worden gekoppeld die deze documenten of lijstitems beschrijven. Deze Content Types worden opgenomen in zogenaamde "Site Content Type Galleries" (bibliotheken met Content Types). Iedere site kent een Site Content Type Gallery.

Binnen een bibliotheek of lijst kunnen documenten en items worden opgenomen. Aan een bibliotheek of lijst kunnen zowel losse kolommen (zoals in een spreadsheet) als Content Types worden toegevoegd. Door Content Types te koppelen aan de kenmerken (properties) van document templates (b.v. Word, PDF, Excel) worden alle kenmerken van documenten als kolommen in de bibliotheek of lijst opgenomen wanneer deze documenten in de bibliotheek of lijst worden opslagen.

Overlappende Content Types
Wanneer je meerdere Content Types hebt gedefinieerd die erg op elkaar lijken, bijvoorbeeld als bepaalde kolommen in ieder van deze Content Types voorkomen, kun je ervoor kiezen om deze Content Types in een hiërarchie onder te brengen. Hierin kunnen "gedeelde" kolommen in een "parent" Content Type worden ondergebracht waarbij de kolommen in het "parent" Content Type automatisch worden opgenomen in de "child" Content Types. Zodoende kunnen wijzigingen in Content Types met minder moeite worden doorgevoerd. Hier zitten echter wel wat haken en ogen aan, maar meer daarover later in dit artikel.

Standaard biedt SharePoint al een aantal Content Types die als basis kunnen worden gebruikt voor zelfgedefinieerde Content Types. Deze Content Types zijn ondergebracht in een hierarchie waarvan het parent Content Type van het type "Item" is. Daaruit zijn andere standaard Content Types als "Document", "Event" en "Task" afgeleid, welke bekend zullen voorkomen omdat deze standaard in bepaalde voorgedefinieerde bibliotheken met dezelfde naam worden gebruikt.

Standaard kolommen: Site Columns
Naast Content Types kunnen ook standaard kolommen (Site Columns) binnen SharePoint worden gedefinieerd. Deze standaard kolommen kunnen vervolgens in Content Types, lijsten en bibliotheken worden gebruikt. Dit is handig omdat je op die manier slechts een maal een kolom definitie, bijvoorbeeld een keuzelijst met standaard status waarden (draft, concept, final), hoeft te definiëren. Deze Site Columns worden opgenomen in zogenaamde "Site Column Galleries" (bibliotheken met Site Columns). Iedere site kent een Site Column Gallery.

Standaard biedt SharePoint al een aantal Site Columns die gebruikt kunnen worden voor lijsten, bibliotheken en Content Types.

Metadatering op verschillende niveaus: SharePoint Farm, Site (Collection) en lijst/bibliotheek niveau
Zowel Columns als Content Types kunnen op verschillende niveau's in een SharePoint Farm worden gedefinieerd en (her)gebruikt:

• Op Farm niveau; te gebruiken binnen een heel SharePoint farm;
• Op Site niveau: te gebruiken binnen sites en subsites;
• Op bibliotheek / lijst niveau: te gebruiken binnen lijsten en bibliotheken.

Meta datering op Farm niveau
Sinds SharePoint 2010 kunnen Content Types op Farm niveau worden gedefinieerd en op deze manier worden (her)gebruikt (gepubliceerd) binnen meerdere Site Collecties. Daarnaast kunnen sinds SharePoint 2010 ook taxonomieën (Managed Metadata, zie Managed metadata overview (SharePoint Server 2010) en Plan terms and term sets (SharePoint Server 2010)) op Farm niveau worden gedefinieerd en in het gehele Farm worden (her)gebruikt.

Meta datering op Site Collectie, Site en Subsite niveau
Vanaf SharePoint 2007 kunnen Content Types en Site Columns op ieder niveau binnen een Site Collectie worden gedefinieerd en worden gebruikt in de sites eronder. Definieer je een Site Column of Content Type in een bepaalde Site, dan verschijnt deze ook in de Site Column Gallery resp. Site Content Type Gallery in alle Subsites van de betreffende Site.

Meta datering op lijst - en bibliotheek niveau
Op het niveau van lijsten en bibliotheken kunnen kolommen en Site Columns (die gedefinieerd zijn in de site waarin de lijst of bibliotheek zich bevindt of een van de parent sites erboven) worden toegevoegd. Van een geselecteerde Site Column wordt een onafhankelijke kopie gemaakt die, als List Column, wordt gebruikt binnen de betreffende lijst of bibliotheek.
Ook kunnen Content Types worden toegevoegd die gedefinieerd zijn in de site waarin de lijst of bibliotheek zich bevindt en Content Types die in de sites erboven zijn gedefinieerd. Van het geselecteerde Content Type wordt dan een onafhankelijke kopie gemaakt die, als List Content Type, wordt gebruikt binnen de betreffende lijst of bibliotheek.

Beginnen met Content Types gebruiken in lijsten en bibliotheken
Om Content Types in lijsten en bibliotheken te kunnen gebruiken moet eerst in de instellingen van de betreffende lijst of bibliotheek ingesteld worden dat er gebruik wordt gemaakt van Content Types. Dit gaat via het menu: List settings > Advanced Settings > Allow management of content types.
Wanneer dit ingesteld is kunnen Site Content Types en Content Types van de bovenliggende sites worden toegevoegd

Wijzigingen doorvoeren in Columns en Content Types
Wanneer je een wijziging wilt doorvoeren in Content Types is het belangrijk een aantal zaken goed in de gaten te hebben en te houden:

• Op welk niveau de wijziging wordt doorgevoerd en welke consequenties dat heeft voor de onderliggende niveaus. De betrokken menu schermen zien er namelijk verradelijk eender uit;
• Welke consequenties de verschillende mogelijkheden die SharePoint biedt om additionele wijzigingen door te voeren hebben voor andere Content Types, lijsten en bibliotheken op hetzelfde niveau of andere niveaus.

Het niet goed in de gaten hebben van de bovenstaande zaken is in veel gevallen de reden dat het doorvoeren van wijzigingen niet de gewenste gevolgen hebben.

Wat meer in detail...

Wijzigen in meta data structuren
Op de verschillende genoemde niveaus kunnen lijst/bibliotheek kolommen, Site Columns en Content Types gewijzigd worden.  Deze wijzigingen kunnen vaak, naar believen ook op onderliggende niveaus worden doorgevoerd. Vantevoren nadenken over wijzigingen is aan te raden, omdat wijzigingen nadelige gevolgen kunnen hebben. Daarom hieronder uitleg over wat mogelijk is en wat hierbij de overwegingen kunnen zijn.

Toevoegen van Site Columns aan lijsten en bibliotheken
Wanneer een Site Column wordt toegevoegd aan lijsten of bibliotheken kan ervoor gekozen worden dat deze ook toegevoegd wordt aan alle Content Types die aan de betreffende lijst of bibliotheek zijn toegevoegd.

Toevoegen van Site Columns aan Site Content Types
Wanneer een Site Column wordt toegevoegd aan een Site Content Type kan ervoor gekozen worden dat  deze ook toegevoegd wordt  aan alle Content Types die afgeleid zijn van dit Content Type, zowel List – als Site Content Types. SharePoint vraagt dan: “Update all content types inheriting from this type?”

Toevoegen van Site Columns aan List Content Types
SharePoint biedt hier niet de mogelijkheid om alle Content Types met de toegevoegde Site Column bij te werken (Update all content types inheriting from this type?). Dat is logisch, want een List Content Type kent geen verdere afgeleide Content Types; het is immers een zelfstandige kopie van een bestaand Site Content Type.

Wijzigen van Site Columns
Een Site Column kan op het (site) niveau waarin het is aangemaakt, worden gewijzigd. Hierbij kan gekozen worden de wijziging door te voeren in alle Content Types, zowel List – als Site Content Types en in alle lijsten en bibliotheken (op alle niveau’s) die gebruik maken van de betreffende Site Column.

Wijzigen van List Columns
Een List Column (ook wanneer deze is afgeleid van een Site Column) kan direct in een lijst of bibliotheek worden gewijzigd. Wanneer een List Column deel uitmaakt van een List Content Type dan verandert dat niet doordat de betreffende List Column wordt gewijzigd. In de lijst/bibliotheek settings wordt achter de betreffende kolom nog steeds weergegeven dat  de List Column uitmaakt van de oorspronkelijke List Content Type bij de betreffende kolom .

Wijzigen van het type van een (List) Column
Wanneer het type van een List Column (b.v. van een tekst naar een numerieke waarde) wordt gewijzigd geeft SharePoint een waarschuwing: “Changing the type of this column may result in loss of data. Are you sure that you want to change this column from <Type> to <Other Type>?”. De wijziging kan worden doorgevoerd, maar de afhankelijk van de Site Column waar de betreffende kolom van is afgeleid gaat deels verloren. Bestaande waarden worden omgezet in waarden van het nieuwe kolom type. Hierbij kan informatie verloren gaan. Hoe waarden worden omgezet is een nieuwe blogpost waard :).

Verwijderen van Site Columns
Site Columns kunnen niet verwijderd worden als ze nog in gebruik zijn in Site - en List Content Types Wanneer dit toch geprobeerd wordt, geeft SharePoint de volgende foutmelding: “Site Columns which are included in content types cannot be deleted. Remove all references to this prior to deleting it.”.

Wanneer een Site Column als losse kolom aan een lijst of bibliotheek is toegevoegd en de betreffende Site Column wordt verwijderd geeft SharePoint een waarschuwing (“This site column will be removed and list columns which were created from it will be permanently orphaned. Are you sure you want to delete this site column?”). Wanneer de betreffende Site Column toch wordt verwijderd, dan blijven de kopies die gemaakt zijn in de lijsten of bibliotheken bestaan, onder dezelfde naam, maar kunnen niet meer in een slag worden gewijzigd. Wijzigingen zullen dan in iedere lijst of bibliotheek apart moeten worden doorgevoerd.

Toevoegen van Content Types aan lijsten en bibliotheken
Wanneer een Site Content Type wordt toegevoegd aan een lijst of bibliotheek worden alle kolommen hierin opgenomen als kolommen in de betreffende lijst of bibliotheek. In de lijst/bibliotheek settings wordt dan achter de betreffende kolom weergegeven in welk List Content Type de betreffende kolom voorkomt.

Wijzigen van Site Content Types
Een Site Content Type kan op het (site) niveau waarin het is aangemaakt, worden gewijzigd. Hierbij kan gekozen worden de wijziging door te voeren in alle Content Types, zowel List – als Site Content Types (op alle niveau’s) die afgeleid zijn van het betreffende Content Type.

Wijzigen van List Content Types
Een List Content Type kan direct worden gewijzigd. Hierbij kan niet gekozen worden de wijziging door te voeren in afgeleide Content Types. Immers: een List Content kent geen afgeleide Content Types.

Verwijderen van Site Content Types
Wanneer Site Content Type in gebruik is binnen een lijst of bibliotheek, kan deze niet worden verwijderd. Wordt dit toch geprobeerd dan geeft SharePoint een foutmelding: “The content type is in use. Troubleshoot issues with Windows SharePoint Services. ”.

Verwijderen van List Content Types
Wanneer een List Content Type wordt verwijderd, worden de kolommen in dit List Content Type niet uit de lijst verwijderd, maar blijven bestaan als onafhankelijke List Columns.

Let op: als vervolgens een nieuw (List Content Type) wordt toegevoegd aan de lijst met een of meer kolomnamen die al in de lijst voorkomen, dan zullen in de betreffende lijst dubbele kolomnamen lijken voor te komen. In werkelijkheid geeft SharePoint aan deze nieuw toegevoegde kolommen nieuwe (interne) namen, gebaseerd op de kolomnaam waaraan een volgnummer is toegekend (b.v. MijnKolom0). Deze namen zijn zichtbaar in de URL van het edit formulier waarin de betreffende kolom details kunnen worden bekeken (FldEdit.aspx).

Valkuilen, voetangels en klemmen
In de bovenstaande wijzigingen heb ik al gehint naar risico’s. Voordat wijzigingen worden doorgevoerd zullen deze risico’s goed afgewogen moeten worden tegen de voordelen ervan.

Onderstaand een (niet compleet) lijstje van veel tegengekomen situaties…

Wijzigen van kolom typen kan verlies van data veroorzaken.

Preventie: weten wat de invulling is van de betreffende kolommen en weten welke gevolgen omzetten naar een ander kolom type heeft.

Doorvoeren van “uitzonderingen” op lagere niveaus verlaagt de beheerbaarheid van de informatie architectuur.

Hoe meer uitzonderingen, hoe groter de moeite die gedaan moet worden de uitzonderingen te beheren en hoe groter de kans dat uitzonderingen (maatwerk) worden overschreven door andere wijzigingen die ook doorgevoerd worden op lagere niveaus. Vooral de uitrol van Solutions waarbij de bestaande informatie architectuur “globaal” wordt gewijzigd (gestandaardiseerd) kan zorgen voor onverwachte wijzigingen.

Preventie:

1. Beperken van uitzonderingen, documenteren ervan;
2. Read-only maken van Site – en List Content types;
3. Bepalen en implementeren van duidelijke regels voor het wijzigen van Content Types

In de “Advanced settings” van een Site – en List Content Type kan gekozen worden voor het read-only maken ervan (“Choose whether the content type is modifiable. This setting can be changed later from this page by anyone with permissions to edit this type. “).

Van een Site Content Type kan (in de advanced settings) gekozen worden voor het automatisch bijwerken van afgeleide Site – en List Content Types (“Specify whether all child site and list content types using this type should be updated with the settings on this page. This operation can take a long time, and any customizations made to the child site and list content types will be lost.  Update all content types inheriting from this type? “).

Gelijktrekken van Site - en List Content Types
Wanneer Site Content Types en List Content Types niet meer gelijk zijn, dan kun je, door wijzigingen in het Site Content Type aan te brengen en deze wijzigingen in de onderliggende List Content Types door te laten voeren, de Site - en Lijst Content Types weer gelijk maken.

Voorbeeld:
Worden in een Site Content Type kolommen verwijderd en staan deze nog in de afgeleide List Content Types, dan kunnen deze verwijderde kolommen niet meer allemaal in een keer worden gewijzigd (b.v. Required / Optional gemaakt worden). De kolommen bevinden zich immers niet meer in het Site Content Type.
Wanneer de ontbrekende kolommen weer aan het Site Content Type worden toegevoegd kunnen wijzigingen hierop weer automatisch in de onderliggende List Content Types (waarin de kolommen dezelfde naam / type hebben) worden doorgevoerd. Soms is het nodig om daarbij kolom eigenschappen een extra keer te wijzigen om alle kolom eigenschappen weer gelijk te krijgen (b.v. Required / Optional maken).


Wees voorzichtig met het verwijderen van Site Columns
Wanneer een Site Column als losse kolom aan een lijst of bibliotheek is toegevoegd en de betreffende Site Column wordt verwijderd, dan blijven de kopies die gemaakt zijn in de lijsten of bibliotheken bestaan, onder dezelfde naam. Helaas kunnen deze kolommen niet meer in een slag worden gewijzigd. Wijzigingen zullen dan in iedere lijst of bibliotheek apart moeten worden doorgevoerd. Needless to say dat dit niet bevorderlijk is voor de beheersbaarheid.

Content Types met dezelfde naam kunnen op verschillende site niveaus worden aangemaakt.

Dit wekt natuurlijk verwarring en zal voorkomen moeten worden.

Preventie: gebruik unieke namen voor alle Content Types.

Verander standaard SharePoint Content Types niet

SharePoint kent een aantal standaard Content Types. Verander deze liever niet omdat ze de basis vormen van SharePoint en veel standaard (out of the box) lijsten en bibliotheken hierop zijn gebaseerd.

Content Type en Column Menus lijken veel op elkaar: verwar ze niet met elkaar

Door niet goed in de gaten te hebben op welk niveau een menu wordt gebruikt, kunnen onbedoeld wijzigingen worden doorgevoerd.

Remedie: goed letten op het niveau waarin de het menu zich evindt en de titel van het menu, b.v. “List Content Type” of “Site Content Type”.


Let op in welke groep je een kolom toevoegt

Als je een kolom per ongeluk aan een verkeerde groep hebt toegevoegd en je hebt ervoor gekozen deze wijziging door te voeren op de onderliggende niveaus, dan wordt de betreffende kolom ook op de onderliggende niveaus in de verkeerde groep ondergebracht.

Remedie: goed opletten.

Let bij het wijzigen van Columns op het gebruik ervan in custom Page Layouts

Weleens gehoord van de SharePoint “Unknown error”? Een van de oorzaken hiervan kan zijn dat in een custom (aangepast) Page Layout wordt verwezen naar een Column die is gewijzigd.

Remedie:  aanpassen van de betreffende Page Layout.