Editing/Mapping Deployed SharePoint Integrated Workflow via Thick Client to Different List/Library with Start Rule Causes Orphaned Event Receiver as well as P&D Issues
kbt131495
PRODUCTK2 blackpearl
This article was created in response to a support issue logged with K2. The content may include typographical errors and may be revised at any time without notice. This article is not considered official documentation for K2 software and is provided "as is" with no warranties.
Issue
The issue is that when you edit a workflow via thick client that is mapped to a list/library that is tied to an event receiver via start rule, and the end-user decides to change the start rule to map to a different list/library thus creating a second event-receiver mapped to the new list, the entries from the original deployment are orphaned in the db which can cause inadvertent workflows to fire as well as issues when deploying. The root cause are the orphaned items in the db. The two tables that are affected are [Integration].[ProcessSharePointWorkflow] and [Integration].[ProcessSharePointWorkflowEvent].You can reproduce this behavior by creating a process ie. 'theGreatProject heGreatProcess' that fires when an item is added to 'Doc Lib A' and then map to a document event that moves the document from 'Doc Lib A' to 'Doc Lib B' and deploy. Drill into the process and then edit the start rule to fire when a document is added to 'Doc Lib B' and edit the move document event to move the document from 'Doc Lib B' to 'Doc Lib A', and then redeploy.
Run the following query...
select pwf.WorkflowName, ps.ListDisplayName, pswe.Event, pse.Name
from [Integration].ProcessSharePointWorkflow pwf
inner join [Integration].ProcessSharePointSetting ps
on pwf.ListID = ps.ListID
inner join [Integration].ProcessSharePointWorkflowEvent pswe
on pwf.ID = pswe.WorkflowID
inner join [Integration].ProcessSharePointEvent pse
on pswe.Event = pse.ID
where pwf.WorkflowName = 'theGreatProject heGreatProcess';
You'll see the orphaned entry with the start rules etc. If you want to see the inadvertent process fire open up the K2 application event logs and start the process by adding a document to 'Doc Lib B'. Refresh after a minute or so and you will see the second process kick off.
The deploy issue is that when if the process is deployed to a source environment the process will be mapped to the original doc lib. You can see this behavior by firing of the .ps1 against a .kspx that contains the process...
Write-DeploymentConfig 'C: heFolder hePackage.kspx' 'C: heFolder heExtensiveMarkupLanguage.xml'
Drill into the xml and look at the wfevent and notice it's mapped to the original list/library.
