How to differentiate between K2 blackpearl error messages

  • 23 December 2010
  • 4 replies
  • 1 view

Badge +3

I'm trying to provide some friendly error messages based on the error codes returned from K2 errors. 


In particular I'd like to inform a user that the worklist item they have attempted to open has been completed previously by another user in the same destination group (not an error) and also inform them if they attempt to open a worklist item to which they don't have access (which is an error).


If a normal user attempts to open someone else's worklist item then the following message is displayed:


24411 K2:DOMAINUSER from <IP address>:<port> is not allowed to open the worklist item with SN=<serial number>


However if a user attempts to open a worklist item to which they do have access, but that has been completed by another user in the same destination group, the same error message is displayed.


Looking at the documentation, I would have expected to receive the following for a user attempting to open a completed worklist item:


26030 Worklist item <serial number> not found for K2:DOMAINUSER at <IP address>:<port>


How can I differentiate between the two scenarios and provide proper instructions to the end user if the error messages are identical?


Thanks in advance,


DaveC


4 replies

Badge +6

Before attempting this, I think you should consider preventing this by setting filters on the worklist. You shouldnt be showing other users tasks.


Explanation of the errors:



  • When a worklistitem is allocated (you are a destination user but someone else opened the shared task), you get this exception:

    • 26030 Worklist item 1124_48 not found for K2:DOMAINUser at 10.33.40.50:99


  • When opening a workitem and a user is not a destination user, you see this error:

    • 24411 K2: DOMAINUser from 10.33.40.50:8 is not allowed to open the worklist item with SN=1139_53


  • When opening a workitem but the workitem was completed and does not exist any longer, you see this error:

    • 24411 K2: DOMAINUser from 10.33.40.50:8 is not allowed to open the worklist item with SN=1139_53


Badge +3

Thanks for your response Sujeeth.  I accept that using the filtered K2 Worklist would clearly indicate to a user
which worklist items are outstanding but unfortunately Worklist and
Workspace are not being widely used in this organisation currently.


Some additional background: users receive a custom email notification which contains a link to a ASP.NET web page for their worklist item - they are not opening the item via the Worklist within Workspace or the Worklist Web Part within SharePoint.


Worklist items are not being allocated automatically when the user opens the worklist item, therefore the first error message you have listed (26030) will never be displayed.  (Experience has taught me that automatically allocating the worklist item causes too many problems with users being unaware that they now effectively 'own' the worklist item and that no-one else can complete it until they release it - but this is a separate issue :)).


So a user will receive the 24411 error message in both the circumstances you've listed in the second and third bullet points but these are two different scenarios and this is the whole point of my question: how can I let a user know whether the worklist item they are attempting to open has been completed by another user or that they are not permitted to open the worklist item?


I need to be able to differentiate between these in order to reassure a user that the task has been completed by a colleague and also provide a warning/error message to anyone attempting to game the system by completing a task assigned to another user.  I can't do this if the error reported by K2 is the same in both scenarios.


Again, any help is appreciated.


David.


 


 


 

Badge +11

 


 


 


 


 




 



 



 


if (oProc.Status1.ToString() == "Error"

)

{



 



 



 


ErrorLogCriteriaFilter errCriteria = new ErrorLogCriteriaFilter

();

errCriteria.AddRegularFilter(



 



 


ErrorLogFields.ProcInstID, Comparison

.Like, procInstID);

errCriteria.FilterCollection[0].ColumnName =



 



 


"[_ErrorLog].[ProcInstID]"

;

 



 



 


ErrorLogs wi = workflowServer.GetErrorLogs(workflowServer.GetErrorProfile("All"

).ID, errCriteria);

errorString = wi[0].Description;


errorType = wi[0].TypeID;



procInErrorState =



 



 


true

;




 


the error types are listed below


/*


LineRule 4


PrecedingRule 0


StartRule 1


DestinationRule 2


SucceedingRule 3


EscalationRule 8


EscalationAction 9


ServerEvent 5


ClientEvent 6


IPC 7


ProcessEscalationRule 10


ProcessEscalationAction 11


ProcessStartRule 12


ProcessFinishRule 13


EventEscalationRule 14


EventEscalationAction 15


*/


Badge +3

Thanks Bashar, but I'm not entirely sure how this helps me?  For the two scenarios I've described are there two different error types reported from those you've listed?

Reply