Error in Escalation rule

  • 22 September 2009
  • 2 replies
  • 2 views
A
Badge +9

I have an activity which has an escalation set up that sends an email to a list of email addresses stored in a process level field.

This escalation has been causing the following error everytime the escalation fires:

ActivityInstanceDestination property not available on given context.

I have checked the process level field which contains the email address, and it appears to be valid.

I have tried going to process management to repair this, however when I open up the process from the Process Management tool in VS2005, I get the following error:



One or more errors encountered while loading the designer. The errors are listed below. Some errors can be fixed by rebuilding your project, while others may require code changes.


Specified cast is not valid.
Hide    


at VSLangProj.Reference.get_SourceProject()
at Microsoft.Workflow.VSDesigner.TypeProviderCreator.TypeProviderHost.ReferenceEntry..ctor(TypeProvider typeProvider, Reference reference)
at Microsoft.Workflow.VSDesigner.TypeProviderCreator.TypeProviderHost.VSLangProj._dispReferencesEvents.ReferenceAdded(Reference pReference)
at Microsoft.Workflow.VSDesigner.TypeProviderCreator.TypeProviderHost..ctor(IServiceProvider provider, IVsHierarchy hierarchy)
at Microsoft.Workflow.VSDesigner.TypeProviderCreator.GetTypeProviderHostForObject(Object obj)
at Microsoft.Workflow.VSDesigner.TypeProviderCreator.GetTypeProvider(Object obj)
at Microsoft.Workflow.VSDesigner.VSWorkflowDesignerLoader.Initialize()
at System.ComponentModel.Design.Serialization.BasicDesignerLoader.BeginLoad(IDesignerLoaderHost host)
at System.ComponentModel.Design.DesignerHost.BeginLoad(DesignerLoader loader)


I have a couple of questions in regard to this:
1. Has anyone encountered the original error (ActivityInstanceDestination property not available on given context.
), and if so, any ideas on what causes it, and how to fix it?
2. Has anyone encountered the error that I get from the Process Management tool in Visual Studio, and if so, any ideas on how to fix it so that I can debug and repair this process?
3. Looking at the view flow for the process instance that is in error, it doesn't actually appear to be in error. Will an error in an escalation rule stop the process from continuing? or will the process continue on, ignoring the error in the escalation rules?? ie if I ignore these processes in error, will the process be able to continue on?


Thanks in advance for any assistance on this!

2 replies

M
Badge +4

Hi,


It was reported a while back as a bug. Please let us what version of K2 are you using? I am not sure the latest version will fix it and we should test it out and report it.


The escalation works on a different process, so it may not appear to directly linked with the K2 process instance from the workspace error profile.


To workaround it, please point to a data-field instead of the K2 workflow context field. (for your email content)


I am not sure how to repair it as the processs management is aimed to repair the process instance itself.


We may have to delete the escalation manually in the database and run the process in new instances.


Sorry for the inconvenience.


 Regards, 


 


 


 


 

A
Badge +9

for the benefit of anyone else who encounters this problem:

The problem was caused by inserting a reference to the ActivityDestInstanceStartDate field into the body of an escalation email. The escalation was set at the Activity level. The explanation given was that this field is out of context at the activity level.

The best way to avoid this it seems is to put the escalation on the client event itself, rather than on the activity.

I was able to get the processes to continue by doing the following:
Deploy a new version of the process that removed the reference to the field that was out of context
opening the Process Management in Visual Studio, click the process you want to fix, and click "Retry".
Choose the new (fixed) version of the process as the version to use

From the K2 guys:
TAKE CARE !!! …You should under no circumstance makes changes to the Schema of the Process when using this method to repair Instances . ie : Do not Create or Delete Events/Activities , move Lines , Add/Remove InfoPath templates as this will break the Instance being repaired and could put it in an unrecoverable state . Feel free to make changes to existing Events/Wizards/Server Code however .



This made the processes retry with the repaired version, so they were able to continue on.

This was all logged under ticket 23521.

Hope this helps someone down the track - as usual, the K2 support was exceptional!

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings