Experimenting with Memory for AutoStart SPWorkflow

When a SharePoint workflow is started through the Web client, the workflow is loaded in the memory of w3wp.exe until the workflow becomes idle and dehydrates to the SharePoint database.  When the same workflow instance is rehydrated again, it is loaded in owstimer.exe.  A SharePoint workflow can be started manually or it can be automatically started when an item is added or an existing item is changed in a list or a document library.  Regardless of how a workflow is started, I always thought the memory management for loading a SharePoint workflow should be similar to what is stated above.

Some time ago, one of my colleagues, Jonas Nilsson, asked me that if a console application adds an item to a list, could the automatically started workflow on that list get loaded in the console application’s memory?  My first reaction was that this wouldn’t be possible because the console application is not hosting the workflow, but is simply adding items to the list.  I was counting on the timer service to load and run the workflow in this case.  Well, experimentation showed that the timer service is not the hard working fellow in this case.

I wrote a few lines in a console application to add a file to a shared documents library which automatically started a workflow when an item was added to the library:

string destUrl = "http//somesite";
 
site = new SPSite(destUrl).OpenWeb();
te[] contents = new te[1];
contents[0] = 0;
SPFileCollection sfc = site.GetFolder("Shared Documents").Files;
destUrl = sfc.Folder.Url + "/" + "test1.txt";
 
sfc.Add(destUrl, contents,true);

 

The result?  The item was added to the list, but the workflow was not triggered.

I then modified the code adding a line, Console.ReadLine(), at the end to pause the console application until some user input had been received:

string destUrl = "http//somesite";
 
site = new SPSite(destUrl).OpenWeb();
te[] contents = new te[1];
contents[0] = 0;
SPFileCollection sfc = site.GetFolder("Shared Documents").Files;
destUrl = sfc.Folder.Url + "/" + "test2.txt";
 
sfc.Add(destUrl, contents,true);
 
Console.ReadLine();   // this is added to pause the console application.

The result?  If the user does not type any input into the application, the item is added, the workflow is triggered, and begins running.

 

The SharePoint log file logged two entries in the second experienment:

11/17/2010 22:51:30.73     ConsoleAddFileToList.vshost.exe (0x030C) 0x1390 SharePoint Foundation                Monitoring                        b4ly   High          Leaving Monitored Scope (FireWorkflowStartingEvent). Execution Time=1.61752401492368 

 

11/17/2010 22:51:37.26     ConsoleAddFileToList.vshost.exe (0x030C) 0x1390 SharePoint Foundation                Monitoring                        b4ly   High          Leaving Monitored Scope (Event Receiver (Microsoft.SharePoint, Version=14.0.0.0, Culture=neutral, PublicKeyToken=71e9bce111e9429c, Microsoft.SharePoint.Workflow.SPWorkflowAutostartEventReceiver)). Execution Time=8071.44958367614     

 

As you can see, the firing of the workflow start event and event receiver all happened in the console application’s process.

In addition, Visual Studio showed that the workflow template dll was indeed loaded in the console application’s memory:

 

Conclusion: When writing a console application or other short-lived process to add or change an item in a SharePoint list or document library, be aware that the automatically started workflow may not have a chance to start because the process it is supposed to be loaded into may have finished running too quickly.  I am starting to wonder whether some of the event firing and event receivers in SharePoint follow a similar memory process.


SharePoint

Applications

SharePoint apps are stand-alone applications that perform specific tasks on a SharePoint site. Apps can perform functions such as managing a discussion board or knowledge base, performing project management or time tracking tasks, or doing other workflow operations.

SharePoint

Product Suites

Experience greater power and savings by bundling our SharePoint apps and web parts.


Essentials


Essentials Plus


Bamboo Premier


Project Management Suite


Knowledge Management Suite


External User Manager


SharePoint

Web Parts

Extend SharePoint beyond its out-of-the-box capabilities by tailoring it to your requirements with Bamboo Solution’s growing portfolio of Web Parts. Web Parts are the building blocks of pages on a SharePoint site that can be used to customize the user interface and content of a site page. 

SharePoint

Product Suites

Experience greater power and savings by bundling our SharePoint apps and web parts.


Essentials


Essentials Plus


Bamboo Premier


Project Management Suite


Knowledge Management Suite


External User Manager


Office 365

Cloud Parts

Cloud Parts are functional components that extend your SharePoint environment whether it’s hosted, on-premises, or part of Microsoft Office 365. More than mere ports of existing software to the cloud, our Cloud Parts have been built from the ground up to take advantage of the best that the cloud has to offer.

SharePoint

Product Suites

Experience greater power and savings by bundling our SharePoint apps and web parts.


Cloud Parts Suite for O365/SP Onl.


Featured Services

SharePoint Health Check

A SharePoint Health Check will identify the causes of issues and risks associated with your specific environment, and is custom tailored to provide you with the best recommendations to optimize your SharePoint environment.

SQL Health Check

Document recommendations relating to performance, stability, availability, or a specific focus you request of your SQL Server database instances.

My SharePointXperts

The truth is that each SharePoint skill may not be a full time job for many organizations, and it is nearly impossible for one person to do everything you need – so augment your team with SharePointXperts; providing the skill sets you need when you need them!