+3
It appears one of the performance enhancements in 0803 was to no longer load process instance data fields on worklist items. When calling OpenWorklist and iterating through a worklist, WorklistItem.ProcessInstance.DataFields is empty. Can someone verify? I have a detailed SPGridView task list in SharePoint 2007 that no longer works since upgrading. I have an easier, more effecient workaround querying SQL directly, but I'm trying to stick to the API as much as possible.
Thanks!
+6
Hi there,
I guess that the "nodata" flag is by default set to not return data. You can change it in the Worklistcriteria object.
HTH,
+3
+3
Doesn't seem to work...
Regardless of the NoData value, item.ProcessInstance.DataFields.Count is 0:
using
(SourceCode.Workflow.Client.Connection BlackpearlConnection = new SourceCode.Workflow.Client.Connection()){
);BlackpearlConnection.Open("K2Server"
SourceCode.Workflow.Client.
WorklistCriteria criteria = new SourceCode.Workflow.Client.WorklistCriteria();
{
Page.Response.Write(item.ProcessInstance.DataFields.Count.ToString());
}
}
+9
I believe the criteria.NoData not working is a known issue.
As a workaround you should be able to add one line of code (highlighted in bold below):
foreach (WorklistItem item in worklist)
{
item.OpenWorklistItem();
Page.Response.Write(item.ProcessInstance.DataFields.Count.ToString());
}
+3
I don't have an OpenWorklistItem method available for the WorklistItem instance.
Even with a similar method, that seems very inefficient. Is that how it functioned before 0803? Was each worklist item loaded separately? That would make sense that it's disabled now. We have users with 100+ tasks assigned to them. That would kill performance.
I have a simple sproc that pulls back the worklist item, process/activity instance details, datafields, and xml fields in one nicely bundled row. I think I'll avoid the API and multiple round trips to the database for this one.
+9
Opps, that's what I get for using Notepad for this code sample.
The correct code is:
foreach (WorklistItem item in worklist)
{
item.Open();
Page.Response.Write(item.ProcessInstance.DataFields.Count.ToString());
}
As for your sproc, please be advised that direct database access is not supported nor guaranteed to be compatible with future K2 releases (in case the DB schema changes).
+11
Food for thought: when you create a stored proc against the internal K2 databases, you are making the assumption that they will remain relatively constant over time as new features are added and changes are made.
+3
It's really just a trade-off. I know the database will change over time, but so will our code. We went live with BlackPearl last August; long before it was stable. We had to program around the missing functionality and performance issues. We basically created our own BlackPearl API. Each K2 update is tested rigorously in our dev and staging environments. As those updates are released, functionality added, and code optimized, we repoint our API to use the K2 API where possible. We just needed certain functionality from K2 that wasn't available (and still isn't in some cases).
+3
NOTE: Call WorklistItem.Open(false) to only load the data. Make sure WorklistItem.Status == WorklistStatus.Open when calling WorklistItem.Open() or you'll receive 26030 Worklist item 0 not found for ...
+9
Just to highlight this but the requirement for the additional Open() call has caused existing applications to break.
This has been logged as a bug and will be fixed in hotfix documented in KB000257 (soon to be released).
If anybody needs the fix urgently, please contact your local K2 support.
Enter your username or e-mail address. We'll send you an e-mail with instructions to reset your password.