SharePoint 2010 Variations

Variations in SharePoint is voor de ingewijde geen onbekend begrip. In SharePoint 2007 was dit concept al bekend. In SharePoint 2010 is dit mechanisme nog steeds aanwezig, en zijn ern zelfs wat verbeteringen doorgevoerd. Omdat bij mijn klant de behoefte is om hun nieuwe corporate website meertalig te laten zijn, is het goed om SharePoint 2010 Variations is onder de loep te nemen. In deze blogpost zal ik eerst een korte inleiding geven over Variations. Vervolgens zal ik de configuratie toelichten, de onderdelen waaruit het bestaat en enkele nieuwe features t.o.v. zijn oudere broer in 2007.

SharePoint 2010 Variations Intro

Variations is hét mechanisme om meertaligheid aan te bieden in SharePoint omgevingen. Het word vrijwel alleen gebruikt in Publish sites wat bedoeld is voor een breed publiek (meestal internet facing). Wanneer Variations geactiveerd word binnen de Site Collection zien gebruikers een handmatig vertaalde pagina van de broncontent. Het mechanisme werkt zo dat als de gebruiker binnenkomt op de landingspagina van de omgeving, deze automatisch geredirect word naar een specifieke taal op basis van de language instellingen van de browser. Door middel van een control kunnen eindgebruikers van taal switchen.

Variation Labels

Voor de content editors betekend dit echter wel dat er meerdere (taal)varianten van een pagina of site moeten zijn en deze allemaal onderhouden moeten worden. Wanneer er een nieuwe pagina op de site moet komen word deze aangemaakt in de ‘Source Label’. Een Label staat gelijk aan een taal en binnen een omgeving is er één taal (Label) wat leading is, de Source Label in dit geval. Wanneer Engels de Source Label is en hier een nieuwe pagina aangemaakt word, word deze door middel van een TimerJob gepushed naar de verschillende Labels. Op basis van configuratie kan de content-editor een mail krijgen van het feit dat er een nieuwe/gewijzigde pagina/site is geplaatst om vervolgens hier actie op te ondernemen. Het is ook mogelijk om een workflow in te richten die automatisch de pagina naar bijvoorbeeld een vertaalbureau/vertaler stuurt om deze vervolgens weer vertaald neer te zetten op de omgeving.

Een Label binnen SharePoint staat gelijk aan een subsite die allemaal op hetzelfde niveau zitten binnen de site hierarchie. Meestal is dit een subsite van de SiteCollection root. Deze Label sites worden automatisch aangemaakt door middel van een timerjob wanneer men een nieuw label aanmaakt en via Create Hierarchies de timerjob scheduled.

SharePoint Variations Instellen

Als eerste dient Variations geconfigureerd te worden en vervolgens moeten de Labels gedefinieerd worden. Ga naar ‘Site Settings > Site Collection Administration > Variations’.

• Variations Home: Geef hier aan vanaf wel punt meertaligheid moet gaan gelden binnen de Site Collection. Is dit de Site Collection root, geef dan hier een ‘/’ op.
• Automatic Creation: Geef hier aan of Pagina’s en Site’s automatisch naar de target Labels gepushed moet worden of dat dit Handmatig gebeurt. Er is nog een derde optie, hier kom ik later op terug.
• Recreate Delete Target Page: Wanneer een pagina is de Target Label verwijderd is, maar in de Source Label gewijzigd word, kan hier geconfigureerd worden of de pagina opnieuw aangemaakt moet worden.
• Update Target Page WebParts: Hiermee configureer je of webpart instellingen meegenomen moeten worden naar de Target Label(s) pagina.
• Notification: Wanneer een nieuwe pagina/site aangemaakt word kan hier aangegeven worden of er een notofication gestuurt moet worden naar de ‘beheerder’ van de site. Dit kan aangegeven worden bij de landingspagina van de Label Site door het veld Contact in te vullen.
• Resources: wanneer een pagina gebruik maakt van een afbeelding die op een andere locatie staat, heb je hier de mogelijkheid om aan te geven of resources, gerelateerd aan deze pagina mee gekopieëerd moeten worden naar de Target Labels, of dat deze het origineel moeten blijven referencen.

De volgende stap is het aanmaken van een nieuw label. Ga naar ‘Site Settings –> Site Collection Administration –> Variation Labels’ en klik op ‘New Label’.

• Geef een naam (word gebruikt in de url: http://intranet/nl-NL) en een display name op.
• Selecteer de taal die geselecteerd moet zijn in de browser en die ook opgepakt word als geïnstalleerd language pack wanneer de gebruiker de site bezoekt.
• Geef aan, wanneer de hierarchie opgebouwd word (volgende stap) of alleen de root site, alleen de publishing sites, zowel publishing sites als pagina’s gekopieerd moeten worden.
• Geef aan of het huidige Label de Source Label is. Dit kan vanzelfsprekend maar 1 keer. Vervolgens moet er een SiteDefinitie opgegeven worden op basis waarvan de Target Labels aangemaakt moeten worden. Het is daarom ook aan te raden om zowel de Source als alle Target Labels te laten baseren op de zelfde Site Definition

Herhaal dit proces voor alle talen die je wilt ondersteunen en klik vervolgens op Create Hierarchies in het voorgaande scherm. Hier word je geinformeerd over het feit dat er een TimerJob draait die dit voor je gaat doen tussen 12 uur ‘s nachts en 3 uur ‘s ochtends.

Om dit proces wat te versnellen kan je naar de TimerJob gaan die dit proces uitvoer en op Run Now te klikken (afbeelding hierboven). Wanneer deze klaar is kan je zien dat bij het overzicht van Labels in de kolom Hierarchies Created ‘yes’ staat en je ineens voor het aantal Labels hetzelfde aantal subsites hebt gekregen.

Wil je kijken wat er goed of fout is gegaan, ga dan naar ‘Site Settings –> Site Collection Administration –> Variation Logs’

De Onderdelen

Om te beginnen heb je in de Pages Library van de Site Collection Root een RedirectPage gekregen die VariationRoot heet en gebasseerd is op de PageLayout VariationRootPageLayout.aspx. Hier zit een User Control op genaamd VariationsRootLanding.ascx. Binnen deze control die in de CONTROLTEMPLATES folder staat, staat de logica om de redirect uit te voeren op basis van de taal van je browser. Indien je deze logica aan wil passen, staat hier hoe je dat moet doen.

Om gebruikers de mogelijkheid te geven om te switchen tussen talen (Labels) kan er gebruik gemaakt worden van een control genaamd VariationsLabelMenu.ascx die ook in de CONTROLTEMPLATES folder leeft. Helaas werkt deze niet OOB. De control bevat wel de Datasource maar geen logica om de data die deze in zich heeft te tonen. Om dit voor elkaar te krijgen kan je de volgende tag toevoegen  wat een drop down renderd:

<cms:VariationsLabelEcbMenu id ="varlabelmenu1" DataSourceID="LabelMenuDataSource" DisplayText="LanguageSelector" IsCallbackMode="true" runat="server" />

Of een repeater-achtige constructie schrijven wat je meer controle geeft over de weergave. Daarnaast was er het vreemde gedrag dat in situaties waar je aan de achterkant van SharePoint zit (situaties waar hij de ‘application.master’ zou willen laden in 2007) de dropdown wel geladen word, maar aan voorkant niet. Dit is het resultaat van de volgende tag in de masterpage (v4.master etc).

<SharePoint:DelegateControl runat="server" ID="GlobalDelegate0" ControlId="GlobalSiteLink0" />

Verwijder deze control en plaats de volgende control op de gewenste locatie

<SharePoint:DelegateControl runat="server" ControlId="VariationsFlagControl" />

Je ziet nu dat de language picker wel getoond word in zowel de voorkant als de achterkant. Je zou er ook voor kunnen kiezen om twee masterpages te gebruiken. Dit geeft je meer vrijheid qua positionering van de language picker aan de voorzijde.

Enkele veranderingen t.o.v. Variations 2007

Server Citizenship: Variations processen draaien nu op de achtergrond via timerjob. Geen synchroon proces, gebruikers hoeven niet meer te wachten totdat bijvoorbeeld replicatie klaar is. Voor beheerders geeft het de mogelijkheid dit intensieve proces beter te beheren met behulp van scheduling. Het proces heeft nu ook geen last meet van App Pool Recycles

Overzicht van de timerjobs die gebruikt worden:

Variations Create Hierarchies Job Definition	Dit is de TimerJob die gebruikt word om de Label Hierarchie mee te creeëren zoals hierboven beschreven.
Variations Create Page Job Definition	Creeërt een pagina in de Target Label site.
Variations Propagate Page Job Definition	Update pagina wijzigingen naar de pagina in de Target Label site
Variations Propagate Site Job Definition	Update site wijzigingen naar de site in de Target Label site

Nieuwe toevoeging in propogation:

Variations kent verschillende methodes van propogation. 'Automatic' zorgt ervoor dat wanneer in de bron een document toegevoegd word, dit automatisch door gevoerd word in alle target variation sites. 'Manual' zorgt ervoor dat er enkel gepropogate word wanneer men op de propogate knop in de ribbon klikt. In SharePoint 2010 kent een nieuwe methode genaamd OnDemand. Dit kan aangezet worden via PowerShell. Dit mechanisme geeft de mogelijkheid om bijvoorbeeld wanneer er inde engelse variant een typo zit, enkel de engelse variation (source) te updaten zonder dit door te pushen naar alle andere variations.Om dit in te stellen maak je gebruik van powershell:

Enable On-Demand Page Propagation:

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$site = new-object Microsoft.SharePoint.SPSite("http://yourserver/sites/abc")
$folder = $site.RootWeb.Lists["Relationships List"].RootFolder
$folder.Properties.Add("DisableAutomaticPropagation", "True")
$folder.Update();

Disable On-Demand Page Propagation:

[System.Reflection.Assembly]::LoadWithPartialName("Microsoft.SharePoint")
$site = new-object Microsoft.SharePoint.SPSite("http://yourserver/sites/abc")
$folder = $site.RootWeb.Lists["Relationships List"].RootFolder
$folder.Properties.Remove("DisableAutomaticPropagation")
$folder.Update();

View Changes

Wanneer er een wijziging is kan men door middel van View Changes in de target sites zien wat er veranderd is, zodat de content editors zich enkel op de veranderingen kunnen focussen. Wanneer een pagina door een publish versie 2 krijgt en de timerjob Propogate Page Job Definition afgaat om deze te propogaten naar de verschillende targets, kunnen conentmanagers gemakkelijk zien in de originele pagina (source) wat de wijzigingen zijn.

 

Linq to SharePoint werkt niet OOB met Anonymous Access

Voor een project hebben we gebruik gemaakt van een techniek genaamd SPMetal. Deze techniek gaat op basis van aanwezige metadata (sitekolommen en contenttypes) een datamodel genereren in c# wat het mogelijk maakt een data strongly typed uit SharePoint te halen. SPMetal genereert dus het datamodel, maar daadwerkelijk de data uit SP halen word door Linq to SharePoint gedaan.

Gisteren gingen we aan de slag om een custom Forms Based Authentication oplossing te testen en zetten daarmee de site op anonymous. Poef… niks werkte meer. Al onze data-retrieval ging via Linq to SharePoint en toen dat onderuit ging werkte niks meer en kregen we overal een 401 – not authorised. En dat klopt. Een anonieme gebruiker mag geen dynamische queries uitvoeren tegen een sql database. Elevated Priveleges dan maar… werkte ook niet!? In de InnerWorkings gebruikt Linq to SQL namelijk SPContext.Current. Dan kan je er wel een elevated web omheen wrappen maar dat gaat het toch niet worden.

Nee, wat er moest gebeuren, is dat tijdens het daadwerkelijk uitvoeren van de query, de HttpContext geback-upped moest worden in een variabele, de originele context op Null gezet moest worden, opdat we de code uit konden voeren in elevated mode waarna de originele context weer terug gezet kon worden.


 

Wanneer nu data opgehaal gaat worden word het uitgevoerd via deze methode. Denk hieraan wanneer je een anonieme website gaat maken!

Bron: Link naar bron

Change SPField(link) Displayname on SPContentType

Bij een klant van me hadden moesten we even de displayname wijzigen van een veld op een contenttype. We hadden de kolom zelf al gewijzigd, maar op het contenttype stond nog steeds de oude naam. Via de Fields property op het ContentType kan je NIET de displayname van een veld wijzigen. Hij geeft dan de melding dat je deze operatie enkel kan doorvoeren op een veld wat gelijk op een lijst zit, en dat is bij ons niet het geval omdat ik een contenttype aan het bewerken ben. Wil je de titel van een veld wijzigen wat op een contenttype zit, dan moet je gebruik maken van een andere property op het contenttype namelijk FieldLinks. Hier staat de link die het contenttype heeft met het daadwerkelijk veld. Door de SPFieldLink te bewerken en vervolgens het contenttype te updaten, krijg je het voor elkaar. Zie code hieronder.

SPContentTypeId contentTypeId= new SPContentTypeId("0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF3900037D15CE78048842B5F3709F848D9818");
SPContentType contentType= site.RootWeb.ContentTypes[contentTypeId];
SPFieldLink fieldLink= contentType.FieldLinks[new Guid("{d3858a2d-33e6-4f61-8eb8-037a20bf5b69}")];
fieldLink.DisplayName = “Nieuwe titel";
contentType.Update();

Task Assigned Notification bevat verkeerde url (Alternate Access Mappings)

Vandaag weer een bijzonder probleem tegen gekomen bij een klant van me. Was een bijzondere zoektocht, maar wel gaaf dat ik het gevonden heb! Hier het verhaal:

Wat contextinfo:

1. Deze klant maakt gebruik van Alternate Access Mappings. De url http://sp.***.nl is gemapped naar http://vkc.***.nl.
2. Wanneer er een nieuwe sitecollection gedeployed word, word dit met Import/Export van SharePoint gedaan.
3. Er word gebruik gemaakt van een workflow om taken aan te maken.

Het probleem:

In 8 van de 10 sitecollections bevatten alerts van de takenlijst die je krijgt als een item aan jou assigned is overal de url http://sp.***.nl ipv http://vkc.***.nl…. dit muv 2 andere sitecollections die wel goed schenen te werken.

De analyse:

In eerste instantie twijfel je aan je code, dus ga je kijken of de context wel klopt waaronder de taak aangemaakt word. Dit was correct, dus daar kon het niet aan liggen. Helemaal omdat het niet overal fout ging en de workflow overal gelijk is. Daarnaast maakt de workflow alleen de taak aan. Het feit dat deze aan jou assigned is en daar een alert van verstuurd word is standaard SP.

Vervolgens de database maar eens opengeschroefd. In de contentdatabase van de betreffende sitecollection de tabel ImmedSubscription geopend. Daar stond de verradelijke url hard in de tabel. Blijkbaar slaat SP de url van de locatie (site/web) waar de alert is aangemaakt, hard op in de database.

Nieuwe alerts werden goed aangemaakt in deze tabel, enkel oude alerts bevatten de verkeerde waarde. Kan dit niet 100% bevestigen, maar tijdens de import procedure loopt er waarschijnlijk een andere procedure die genoemde tabel update qua waarde. Helaas pakte hij de verkeerde en kan deze dus niet goed overweg met Alternate Access Mappings.

Wanneer in de tabel een url staat die niet bestaat binnen de omgeving, worden er totaal geen alerts meer verstuurd. Dit was een bekend probleem bij migratie van wss2.0 naar wss3.0. Echter, als de url wel bestaat (sp.***.nl) word de mail wel verstuurd, maar bevat hij dus de verkeerde url. Hierdoor lopen andere zaken in de soep die wel afhankelijk zijn van het feit dat de gebruiker op vkc.***.nl zit.

Als eerste werd ik getriggerd door de volgende blogpost. Hier werd uitgelegd welke situatie ervoor zou zorgen dat er geen alerts meer verstuurd werden. Vervolgens een repro op mijn omgeving uitgevoerd en jawel, ik kon de url wijzigen in mijn mails door de SiteUrl in de betreffende tabel te wijzigen. Let wel, de url moet wel bestaan, anders worden er geen mails verstuurd!

De oplossing:

In de Microsoft Sharepoint Administration toolkit zit het UpdateAlert stsadm commando. Met dit commando kan je een site opgeven (siteUrl) en de waarde die je wil veranderen (oldSiteUrl). Vervolgens uitvoeren en voila, de alerts bevatten weer de juiste url.

SP2007, InfoPath: This form template is browser-compatible, but it cannot be browser-enabled on the selected site.

Vandaag tegen deze melding aangelopen bij de UBU. Wanneer InfoPath Services correct geconfigureerd is en je ziet dat InfoPath formulieren op andere sites wel correct werken maar op die éne site net niet. Dan is dit te wijten aan een Hidden feature die niet goed aan is gezet…

Hoe op te lossen:

Gebruik STSADM en voer de volgende commando’s uit:

- stsadm -o deactivatefeature -filename IPFSSiteFeatures\feature.xml -force -url <<Target URL>>
- stsadm -o activatefeature -filename IPFSSiteFeatures\feature.xml -url <<Target URL>> –force

Het is een site scoped feature, dus geef bij <<Target URL>> de url van de Site Collection op.