Na het oplossen van het probleem dat in de vorige post wordt beschreven, wist een collega van mij te vertellen dat dit wellicht te maken kon hebben met het KB artikel 947284 (https://support.microsoft.com/kb/947284).

Hier staat namelijk dat er vanaf Servicepack 1 van Sharepoint een wijziging is geweest in het security model. Het Systeem-account mag namelijk niet meer ‘declaratieve’ workflows opstarten. Wat ‘declaratief’ in deze context betekend weet ik niet, maar het lijkt er dus op dat het Systeem account helemaal geen workflows meer op mag starten.

Wanneer je code uitvoert met RunWithElevatedPrivileges, dan wordt dit onder het Systeem-account uitgevoerd, omdat dat account alle rechten zou moeten hebben op de web applicatie.

Dit had ik dus ook in mijn stuk code gedaan. Om er zeker van te zijn ben ik even ingelogd als het Application Pool account op m’n Sharepoint site. Als naam stond hier inderdaad dat ik het Systeemaccount was.
Het is dus zeker een nuttig KB om te kennen bij het schrijven van code dat afhankelijk is van workflows.

Sowieso is het handig om de best-practices te kennen voor het inrichten en configureren van een Sharepoint omgeving. Op zich wist ik namelijk wel dat deze specifieke omgeving niet echt best-practice was, maar had niet gedacht dat zoiets eenvoudigs als het starten van een workflow dan niet meer zou gaan werken.

Enige tijd geleden moest ik iets maken voor een klant dat vanuit een ‘gewone’ ASP.NET pagina een item aanmaakte in een Sharepoint lijst. Op zich geen probleem, zeker niet omdat er in dezelfde application pool werd gewerkt, waardoor er gewoon gebruik gemaakt kon worden van de RunWithElevatedPrivileges die Sharepoint biedt.

Dit had ik dan ook al snel voor elkaar, maar bij het testen bleek dat de workflow van de lijst niet automatisch werd gestart. Aan de lijst hing namelijk een workflow die automatisch zou moeten starten wanneer er een nieuw item in de lijst wordt aangemaakt.

Na wat zoeken ben ik er achter gekomen dat dit ’normaal’ gedrag is en er een work-around voor is, namelijk door de workflow ook zelf via code op te starten. Als je dit weet is dat op zich prima, maar ook dat levert een foutmelding op. De melding was (vrij vertaald): ‘Failed to start (retrying)’. Enkele minuten later start de workflow alsnog. Wat wel vervelend is, is dat de gebruiker dit niet kan zien, omdat de status continu hetzelfde blijft, totdat de workflow is beeindigd.

Zelf kan ik hier prima mee leven, zeker omdat ik geen alternatief had.

Vandaag kreeg ik de melding dat er nog iets anders mis ging in het formulier. Na deze melding al vrij snel opgelost te kunnen hebben, heb ik toch even verder gekeken naar dit bovenstaande probleem. Na even zoeken kwam ik langs een post op het MSDN forum waarop staat dat je de workflow ook via de Sharepoint webservices kunt gaan opstarten. Logisch, maar had niet verwacht dat dat een oplossing zou zijn.

Al geruime tijd werkt het zoeken niet goed op m’n Sharepoint server waar ook dit weblog op draait. In de eventviewer zag ik het event 6398 continu terug komen.

Normaliter krijg je dit event te zien, samen met nog enkele anderen, en geven ze aan dat je de rechten op de dcom OSearch en de IWAM moet wijzigen.

Aangezien ik geen MOSS draai heb ik geen OSearch. Wel de IWAM, maar daar had ik de betreffende accounts al lokale activatie rechten op gegeven.

De fout die ik ook kreeg sloeg op het register:

Requested registry access is not allowed.

Heeft natuurlijk weinig met DCOM te maken. Jammergenoeg stond er niet echt een pad bij waar de accounts dan geen rechten op zou hebben.

Alle Sharepoint accounts in de Administrators groep plaatsen hielp niet.

Uiteindelijk kwam ik op deze post (Technet): https://social.technet.microsoft.com/Forums/en/sharepointsearch/thread/29c1a681-5996-4e71-ada7-3abc4fe772b5

Hier geeft iemand aan dat het mogelijk is dat de zoek database misschien corrupt is, dat was bij hem het geval. Het kan natuurlijk zo zijn dat dit ook bij mij het geval is.
Wat ik nu heb gedaan is de zoekservice gestopt, daarna weer gestart, maar met een andere database naam.

Na de indexer weer te alloceren aan m’n web applicatie is die begonnen met indexeren. Ik heb het zoeken nu even getest met de term ‘Sharepoint’ en het lijkt te werken. Ik krijg in ieder geval resultaten terug die ik zou verwachten.

Vandaag is dan eindelijk m’n weblog in WSS3.0 live. Er zal nu dus ook niet meer iets worden geschreven via het ‘oude’ weblog.

Aangezien met maken van een post in Sharepoint toch iets eenvoudiger en gebruiksvriendelijker is dan in een eenvoudig zelfgemaakt weblog, zal ik ook wat meer posten. Er is namelijk veel waar ik nog iets over wil schrijven.

De performance laat momenteel nog wel wat te wensen over, aangezien de server nog niet de hardware heeft die het zou moeten hebben. Hopelijk wordt dat ergens deze week of begin volgende week geleverd.

Het weblog is ook nog in ontwikkeling. Zo wil ik ook nog een integratie met Twitter in implementeren. Tevens moet het wat eenvoudiger worden om oude posts te zoeken in het archief.

Nog veel te doen dus, maar het begin is er!

Oh ja, de redirect naar weblog.jan-v.mobi is hopelijk tijdelijk. Zodra m’n hosting goed is geregeld zal het weblog weer onder jan-v.nl geplaatst worden. In wat voor tijdsbestek dit gerealiseerd kan worden is nog onbekend. Er zijn nog zoveel dingen die geregeld moeten worden (en een hogere prioriteit hebben), dat dit nog een grote onbekende is.

Ook wel goed om te weten is, is dat er momenteel nog geen accounts gemaakt kunnen worden die op een post kunnen reageren. Dit moet ook nog worden gerealiseerd. Heeft wel een redelijk hoge prio, maar dan zal ik eerst de hardware van de server in orde moeten hebben.

Het gebeurd me nagenoeg altijd. Altijd wanneer ik een webpart moet toevoegen aan een pagina, moet het Chrome type worden aangepast, zodat alleen de titel wordt getoond of juist helemaal niets. Dit kost niet enorm veel tijd, maar ik vind het wel vervelend om te doen, aangezien ik hem eigenlijk altijd zet op niets tonen.

Wat blijkt nu, de standaard Chrome instellingen kunnen worden gewijzigd per webpart zone via de onet.xml bestanden. Deze bestanden zijn standaard te vinden in de map /program files/common files/Microsoft shared/web server extensions/12/templates/sitetemplates/../XML.

In dit bestand staat als het goed is een stukje tekst ChromeType bij iedere webpart zone van de template. De waarde bij dit attribuut kan dan worden aangepast. De waarden zijn:

• Default
• TitleAndBorder
• None
• TitleOnly
• BorderOnly

Bron: http://msdn.microsoft.com/en-us/library/system.web.ui.webcontrols.webparts.partchrometype.aspx

Zelf heb ik het nog niet zien werken, omdat ik nog niet de tijd en gelegenheid heb gehad om dit een keer uit te proberen. Het is natuurlijk ook zo dat er meerdere onet.xml bestanden zijn, dus moet je wel weten welke je aan moet passen. Het is uiteraard wel handig om eerst even een backup te maken van de originele bestanden voordat je hierin aanpassingen gaat maken.

Onlangs kwam ik een mooie post tegen op een blog. Dit ging over het gebruiken van Linq op de items van een Sharepoint lijst. Het origineel is hier te vinden: https://asadewa.wordpress.com/2008/01/03/direct-linq-to-splistitemcollection/

Volgens de post is het standaard niet mogelijk, maar heeft hij heeft er wel een leuke work-around voor gevonden. Zelf heb ik het nog niet uitgeprobeerd, omdat ik nog niet een goede toepassing heb gevonden/bedacht.
Het komt er in het kort op neer dat je een wrapper schrijft om de SPListItemCollection en daar de item collectie in stopt. De wrapper ziet er ongeveer zo uit:

public class SPListItemCollectionAdapter : List 
{ 
	private SPListItemCollection _listItemCollection; 
	public SPListItemCollectionAdapter(SPListItemCollection listItemCollection) 
	{ 
		_listItemCollection = listItemCollection; Refresh(); 
	} 
	private void Refresh() 
	{ 
		this.Clear(); 
		foreach (SPListItem item in _listItemCollection) 
		{ 
			this.Add(item); 
		} 
	} 
}

Zoals te zien wordt deze wrapper afgeleid van de List, waardoor je er dus Linq-queries op uit kunt voeren.

In de constructor wordt dan de itemcollectie toegevoegd en kan er dus mee worden gewerkt. Door deze wrapper kun je nu dus met Linq werken op een Sharepoint lijst item collectie. Dit kan er zo ongeveer uit komen te zien:

//De items ophalen vanuit de lijst 
SPListItemCollection itemcol = mossWeb.Lists[listname].Items; 
//De opgehaalde item collectie in de adapter stoppen. 
SPListItemCollectionAdapter itemsAdapter = new SPListItemCollectionAdapter(itemcol); 
//Een Linq-query uitvoeren met het wrapper object 
var result = itemsAdapter.Max(x => x[fieldname]);

Om eerlijk te zijn vind ik dit wel een stuk mooier dan gebruik maken van CAML-queries.

De laatste tijd was ik bezig met het maken van een Sinterklaas website in Sharepoint (WSS 3.0 welteverstaan). Dit ging prima, totdat ik hem voor de buitenwereld beschikbaar wilde maken. Via de AAM heb ik de website beschikbaar gemaakt voor de buitenwereld via een ander domein van mij. Dit werkte redelijk goed. Jammergenoeg kon ik de website niet onder poort 80 hosten, want het lijkt alsof Ziggo dat blokkeert. Nu heb ik dus maar een poort met een veel hoger nummer gebruikt. Dit werkte ook goed en de hoofdpagina kon nu worden bekeken. Er was echter 1 groot probleem. Zodra iemand naar een andere pagina navigeerde kregen ze de melding ‘Request Failed’. Het vervelende hieraan was, was dat er geen error informatie werd getoond in de logs of op het scherm. Ook kon ik hier geen logische verklaring voor geven. Eerst dacht ik dat het misschien aan het poortnummer zou liggen, maar dat heb ik ook uitgesloten. Uiteindelijk heb ik de web.config maar aangepast in de hoop dat ik meer informatie zou krijgen door de callstack=“true” parameter aan te passen. Hier had ik geluk mee. Nu kreeg ik bij de ‘Request Failed’ melding een .Net foutmelding waar ik iets meer mee kon. De exacte melding was iets als dit:

Aangezien ik de laatste tijd veel met Sharepoint bezig ben, moet ik ook wel geregeld lastige of (op het eerste gezicht) onmogelijke dingen uitvoeren. Een van deze dingen is het maken van een nieuw inhoudstype (content type) dat overerft van de kalender lijst. Standaard kun je een mooie kalender lijst maken met al de benodigde velden, echter wilde ik hier een eigen inhoudstype bij maken. Ik begon op de normale manier, totdat ik er achter kwam dat je hier niet van kunt overerven. Het inhoudstype Event staat in de groep _Hidden waardoor je er niet bij kunt. Na even zoeken op internet kwam ik uit op Will’s Blog ( https://blogs.vertigo.com/personal/willa/Blog/archive/2007/04/25/calendar-content-types-in-sharepoint-2007.aspx ) die iets vergelijkbaars wilde doen als mij. Wat hij lijkt te doen is de groep _Hidden een andere naam geven, waardoor deze zichtbaar wordt en je dus van alle inhoudstypen in die lijst kunt gaan overerven. De acties die hij beschrijft zijn redelijk te volgen, maar echt ideaal is het niet, zeker niet om op een semi-productie omgeving te doen. Nu kwam ik toevallig op een andere oplossing. Via de interface van Sharepoint kun je helemaal ‘inzoomen’ op het inhoudstype Event en uiteindelijk kun je deze ook gaan bewerken. Als je deze nou gaat bewerken kun je hem ook in een andere groep gaan opslaan. Zelf heb ik nu een groep aangemaakt met de naam Sharepoint verborgen en daar dit inhoudstype in geplaatst. Nu kan ik vanuit die groep nieuwe inhoudstypen maken die afleiden van de Event. Hier kwam ik achter omdat ik eerder al een keer de kolom Titel had hernoemd naar iets anders op eenzelfde manier. Na deze ‘spannende’ actie kon ik verder met het afmaken van m’n kalender op de website die ik aan het maken was.

Onlangs vond ik het nodig of handig om C# code toe te kunnen voegen aan m’n eigen pagina’s die in Sharepoint Designer waren aangemaakt. Dit heeft natuurlijk ook behoorlijk veel potentieel, aangezien je met C# enorm veel en krachtige dingen kunt doen. Omdat Sharepoint toch in het .Net Framework draait, moet dit ook mogelijk zijn vond ik. Na nog geen 30 seconden kwam ik er achter dat dit niet triviaal was. Nadat je een code blok hebt toegevoegd (en uiteraard server-side code in uitvoert) krijg je een mooie melding in het scherm dat dit niet is toegestaan, iets in de trend als dit:

An error occurred during the processing of /Pages/test.aspx. Code blocks are not allowed in this file.

Ok, het plaatsen van code blokken is dus afgeschermd. Hier kan ik me wel iets bij voorstellen, aangezien het een enorm krachtige feature kan zijn die ook misbruikt kan worden.

Toch moet zoiets mogelijk zijn vond ik. Nu had ik in de tussentijd al een work-around bedacht om toch geen code blokken te hoeven gebruiken, maar toch bleef dit in m’n achterhoofd rond dwalen. In m’n pauze heb ik even gezocht hoe je toch code toe kunt voegen in je eigen aspx-pagina’s die je hebt gemaakt in Sharepoint Designer. M’n vermoeden was juist, server-side code is standaard uitgeschakeld in Sharepoint pagina’s.

Een van de onderdelen die ik onlangs heb moeten maken in een Sharepoint website zijn Infopath formulieren. Het mooie van deze formulieren is dat ze redelijk gebruikersvriendelijk zijn en je ze in Sharepoint ook volledig kunt ontleden. We hadden gekozen om deze formulieren in een eigen venster (applicatie) op te starten en dat het formulier na indienen werd gesloten. Nadat het formulier wordt gesloten belandt je in de lijst van formulieren. Dit wil je als eindgebruiker natuurlijk niet zien, aangezien dat er veel te technisch uit ziet.

Eigenlijk wil je dat je dan op een pagina komt met een melding dat het formulier is opgestuurd en het venster kan worden gesloten. We zagen hier echter geen mogelijkheid tot. Iedere keer dat ik het formulier opende en verstuurde was het een doorn in het oog dat die lijst werd getoond.

Plotseling zag ik iets in de hyperlink die het formulier aanriep. Hier werd namelijk de parameter Source in gestopt. De waarde van deze parameter was de locatie van de lijst met Infopath formulieren (wel helemaal ge-encode). Nu kon ik wel raden wat de parameter Source deed, maar toch voor de zekerheid heb ik deze even gewijzigd naar https://www.jan-v.nl (en niet ge-encode). Precies wat ik dacht er wordt naar deze source-url ge-redirect nadat je het formulier hebt verstuurd. Dat we eerst op de Infopath lijst uit kwamen was niet zo heel raar, aangezien we de link hadden gekopieerd van de Nieuw item-knop in de lijst. De originele url was: