Gisteren ben ik terug gekomen van een 60+ uur durende critsit bij een klant in Oostenrijk, waar zij MOSS in single-server configuratie op VMWare Server (dus de gratis versie… In productie J ) draaien op 40+ locaties.

Gedurende deze critsit kwam ik, zoals vele malen eerder, in de discussie terecht over het support van Microsoft op VMWare producten. Dit is de aanleiding dat ik het nu luid en duidelijk probeer neer te zetten in deze post.

Microsoft heeft beperkte support op niet-microsoft hardware virtualisatie producten voor onze Windows Server besturingssystemen. Dit houdt in dat wij FULL support leveren op onze eigen producten en alle producten die onder het Server Virtualization Validation Program (SVVP) (http://go.microsoft.com/fwlink/?LinkId=125649&clcid=0x409).

Op dit moment zijn dat:

• Cisco WAAS Virtual Blades 4.1.1
• Citrix XenServer 5 Embedded Edition
• SUSE Linux Enterprise Server 10 SP2
• VMware ESX 3.5 Update 2
• XenServer 5

Naast het FULL support leveren wij BEST EFFORT support voor PREMIER klanten voor producten die niet onder het SVVP vallen. Let wel, dit is dus best effort, en alleen voor klanten met een premier contract, en alleen voor Windows Server besturingssystemen.

http://support.microsoft.com/kb/897615

Voor onze Server applicaties gelden aparte regels. Elk product team kan zelf bepalen wat deze regels inhouden.

Voor Sharepoint en voor SQL server zijn deze als volgt 

http://support.microsoft.com/kb/909840

http://support.microsoft.com/KB/956893

Uiteindelijk bleek het probleem dus ook mede veroorzaakt te worden doordat SQL gevirtualiseerd was en de VM problemen had met de hardware klok en 461 identieke items aanmaakte in de database wanneer er een workflow gestart werd.

Problemen met workflow zijn vaak lastig te achterhalen. Zeker omdat klanten vaak eigen custom workflows ontwikkelen. Deze posts bevatten wat informatie over workflow internals en hoe workflow te beheren als Sharepoint admin. Deze eerste post gaat voornamelijk over de structuur van een workflow.

Workflow 101

Een workflow is een reeks activiteiten die uitgevoerd moeten worden in bepaalde volgorde, op basis van bepaalde condities. Een simpel voorbeeld is een workflow die handtekeningen voor een nieuw document verzameld alvorens het te archiveren. Als iemand het document afkeurt halverwege, zal het document teruggestuurd worden naar de persoon die om goedkeuring vroeg.
Workflow komt in veel applicaties voor. Daarom is sinds het .NET framework 2.0 een engine opgenomen die gebruikt kan worden om dit te vergemakkelijken voor ontwikkelaars. Deze engine is onderdeel van de codetak binnen het .NET framework genaamd Windows Workflow Foundation.

De standaard (maar ook de meeste custom) workflows binnen sharepoint zijn gebaseerd op deze engine, welke wordt gehost binnen het worker process van de Web applicatie waar de workflow wordt gebruikt.

Windows Workflow Foundation maakt het mogelijk twee verschillende workflows te creëren, namelijk State Machine workflows (event-driven) en Sequential workflows. In essentie is het verschil dat een sequential workflow een van te voren bepaald pad volgt en een state machine workflow reageert op bepaalde events en dynamisch kan veranderen van status. Een workflow kan daardoor dus ook terugkomen op het startpunt doordat de status wijzigt naar de beginstatus. Met een sequentiële workflow kan dat dus niet. State Machine is dus veel meer een workflow die past bij binnen bedrijfsprocessen, waar sequentiële workflow meer past binnen procesautomatisering.

Workflow binnen Sharepoint

In Sharepoint worden gegevens gestructureerd en aangeboden via content types die het schema van de gegevens bepalen en de lists en libraries (library is in prinipe gewoon een geadvanceerde list, dus vanaf nu zal ik alleen list gebruiken) die de structuur bepalen. Een workflow werkt op verschillende niveau's. Hoe de workflow is ontwikkeld bepaald waaraan een workflow toegekend kan worden.

Een workflow kan ontwikkeld worden via Visual Studio of via Sharepoint Designer. Een workflow template via Visual Studio kan geassocieerd worden met een list of contenttype. Een workflow via Sharepoint Designer kan alleen met een list geassocieerd worden. Er wordt daarvoor een instance gecreëerd van een workflow voor elk item in de list.

Een workflow kan dus gestart worden voor een item in een list (bijvoorbeeld een document in een document library). Er wordt dus een instance gestart van de workflow voor een bepaald item. Bij de creatie van de instance gaat er een activiteit van start, welke wordt bijgehouden in een tasklist. Daarnaast hebben workflows meestal een history list waar het verloop van de workflow wordt bijgehouden. Dit zijn normale sharepoint lists.

Ik heb in principe nu al een aantal belangrijke termen genoemd. Template, Instance en Associatie.

Ik hou voorlopig even de focus op Visual Studio workflows, daar deze het meeste voorkomen en ook het meest complex zijn. Een workflow binnen Visual Studio wordt ontwikkeld tot een workflow template, welke via een feature wordt geactiveerd en meestal door een solution wordt uitgerold. Voor een beheerder is het niet zo zeer van belang om de structuur van een workflow feature te begrijpen, maar om er toch kort aandacht aan te besteden, bestaat een workflow feature in ieder geval uit een feature.xml en een workflow configuratie xml. Daarnaast kan de feature gebruik maken van 1 of meerdere ASPX pagina's of XSN forms, en 1 of meerdere binaries of XOML bestanden. Door de feature uit te rollen met een solution bepaal je in de solution waar deze bestanden zich gaan bevinden. Het kan zijn dat deze bestanden reeds bestaan op het filesysteem. Ze kunnen echter ook deel uitmaken van het feature.

De feature.xml moet aanwezig zijn in de feature directory (default = c:/Program Files/ Common Files/Microsoft Shared/web server extions/12/TEMPLATE/Feature). Het bevat de metadata van de feature. Een typisch feature.xml bestand zou er voor een workflow als volgt uitzien:

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Feature Id="<guid>" Title="Workflow" Description="My Custom Workflow" Scope="Site ReceiverAssembly="Microsoft.Office.Workflow.Feature, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c" ReceiverClass="Microsoft.Office.Workflow.Feature.WorkflowFeatureReceiver" xmlns="http://schemas.microsoft.com/sharepoint/">
     <ElementManifests>
          <ElementManifest Location="workflow.xml"/>
          <ElementFile Location="initiationform.xsn"/>
     </ElementManifests>
     <Properties>
              <Property Key="GloballyAvailable" Value="true" />
              <Property Key="RegisterForms" Value="*.xsn" />
     </Properties>
</Feature>
</Elements>

Het workflow configuratie bestand dient ook aanwezig te zijn in de feature directory (in deze feature workflow.xml) en bevat de metadata rondom de workflow en ziet er ongeveer zo uit:

<?xml version="1.0" encoding="utf-8" ?>
<Elements xmlns="http://schemas.microsoft.com/sharepoint/">
<Workflow Name="AdventureWorksWorkflow"
Description="Use this workflow to track sequential tasks of users."
Id="C6964BFF-BG8D-41ac-AC5E-B61EC111731C"
CodeBesideClass="AdventureWorks.Workflow1"
CodeBesideAssembly="AdventureWorks, Version=12.0.0.0, Culture=neutral, PublicKeyToken=71e3bce121e9429c"
TaskListContentTypeId="0x01080100C9C9515DE4E24001905074F980F93160"
AssociationUrl="myAssocPage.aspx"
InstantiationUrl="_layouts/IniWrkflIP.aspx"
ModificationUrl="myModPage.aspx">
<Categories/>
<AssociationData>

…

</AssociationData>
<MetaData> 
        <Instantiation_FormURN>urn:schemas-adventureworks-com:workflow:ReviewRouting-Init</Instantiation_FormURN>
</MetaData>
</Workflow>
</Elements>

Zoals je ziet in de workflow.xml staan er een aantal URL's (AssociationURL, InstantiationURL, ModificationURL en StatusPageURL) genoemd en is er ook een Instantiation_formURN benoemd. Deze waardes verwijzen naar webpagina's die getoond worden binnen de verschillende stadia van de workflow. Dus bij het associeren van de workflow met (toekennen aan) een list of content type, bij het starten van een nieuwe workflow (dus het instantieren van een geassocieerde workflow op een item) en bij het wijzigen van een lopende workflow. Je kunt hier ASPX pagina's of InfoPath forms voor gebruiken. ASPX pagina's geef je gewoon op in deze properties. Als je echter InfoPath forms wilt gebruiken moet je de volgende waardes gebruiken voor de verschillende fases waar je ze wilt gebruiken:

• AssociationUrl="_layouts/CstWrkflIP.aspx"
• InstantiationUrl="_layouts/IniWrkflIP.aspx"
• ModificationUrl="_layouts/ModWrkflIP.aspx"

Verder moet je in de MetaData scope opgeven welke forms je wilt gebruiken, door de URN op te geven. In het workflow.xml voorbeeld zie je een voorbeeld van een instantiatie formulier wat gebruikt wordt:

<MetaData>
       <Instantiation_FormURN>urn:schemas-adventureworks-com:workflow:ReviewRouting-Init</Instantiation_FormURN>
</MetaData>

De URN vind je door een form in InfoPath te openen in designer mode en via File > Properties het FormID veld te nemen.

Verder kan je voor de volgende fasen in een workflow een form opgeven.

• Associatie à Association_FormURN
• Instantiatie à Instantiation_FormURN
• Aanpassen workflow à Modification_FormURN
• Configuratie voor bepaalde taak in een workflow à Task<ID>_FormURN (Bijv: Task0_FormURN)

Verder zie je in de workflow.xml een assembly en classnaam genoemd. Dit is de code die uitgevoerd dient te worden binnen de workflow. Het is meestal een DLL die in de Global Assembly Cache is opgenomen. Echter er kan ook gewerkt worden met markup XOML files, wat via Extensible Application Markup Language logica beschrijft wat een workflow precies doet. Dit is identiek aan de Sharepoint Designer workflows and kan alleen worden toegepast op een List. Daarnaast kan er slechts gebruik gemaakt worden van een aantal activiteiten en condities. De XOML workflow wordt dus geïnterpreteerd gedurende runtime en is beperkt.

Als je de feature via een solution deployed hebt en geactiveerd hebt voor de site, kan je workflows gaan gebruiken. Je kunt ze handmatig starten via de GUI of automatisch via bijvoorbeeld via Events die getriggerd worden door gebruikersinteractie en afgehandeld worden door code via Eventhandlers in een custom feature.

In de volgende post zal ik dieper ingaan op het deployen van een workflow en het gebruik ervan….