locked
Resumed workflow..but external host event not working? RRS feed

  • Question

  • Hello,

    Environment : WF 4.5

    Here is the interface to send message to the host.

    public interface IHostNotification
    {
            void Notify(String message);
    }

    public MyNotifyHost : CodeActivity {

    ....

      ..Execute(..) {

          IHostNotification  notify.. = context.GetExtension..

          notify.Notify(...)

    }

    In the host, IHostNotification  has been implemented and added like..

    wfApp.Extensions.Add(extension);

    extension is the object of IHostNotification implementation.

    Everything works fine, but...once the workflow persisted..then later resumed....strangely, the host is not getting the notification sent by MyTestWorkflow workflow..

    Here is how I loaded the workflow from the persisted one. (InstanceID is the persisted workflow instance id)

     WorkflowApplicationInstance instance = WorkflowApplication.GetInstance(instanceID, store);
     string assemblyPath = @"MyWorkflow.dll";
     Assembly aly = Assembly.LoadFile(assemblyPath);
     WorkflowApplication wfApp = new WorkflowApplication(aly.CreateInstance("WorkflowLibrary.MyTestWorkflow") as Activity,instance.DefinitionIdentity);

    wfApp.Extensions.Add(extension)

    Any idea why my resumed workflow is not sending the message back to the host?

    Thanks,


    • Edited by T J Monday, January 11, 2016 4:34 PM
    Monday, January 11, 2016 4:32 PM

Answers

  • T J,

    From what I can tell, it looks like you are handling the workflow definition versioning correctly. You are doing a dynamic load of the V1 dll to create an instance of the V1 workflow definition if the persisted workflow uses the V1 WorkflowIdentity.

    However, there is one thing that may be causing your problem.

    The V1 workflow definition has a "hard" reference to the IHostNotification type, which is defined in the V1 assembly. However, when you fire up your host, I suspect you are creating the MyNotifyHost object with "new", which would use the type from the V2 assembly. So the type of the object in the extensions collection for the WorkflowApplication is IHostNotification (V2). This type will not match the what the workflow definition (V1) is looking for.

    If this is the case, you have a couple of options:

    1) When you are about to load a V1 workflow instance, create the MyNotifyHost (V1) using the dynamically loaded assembly and add that to your extensions collection in the WorkflowApplication.

    2) Assuming your MyNotifyHost and IHostNotification definitions aren't changing, put those two types in a separate assembly from your workflow definition. Then those types won't change and your host instance will be using the same version as the V1 and V2 workflow definitions.

    Jim

    Wednesday, January 13, 2016 6:29 PM

All replies

  • T J,

    I have a couple of questions to make sure I have the full picture.

    1) What is causing the workflow to persist and unload?

    2) Is there a MyNotifiyHost activity somewhere in the workflow definition that is reached AFTER the persist/unload point?

    3) In your hosting application, after doing the Load of the workflow, what did you do to cause the workflow instance to continue executing? Loading the workflow is only the first step to making the workflow continue to execute. You need to do some sort of ResumeBookmark on the bookmark the workflow instance is waiting for in order to get the instance to continue executing.

    Jim

    Monday, January 11, 2016 10:33 PM
  • Jim,


    1. Bookmark

    2. Yes..Oh..I guess maybe this is the reason...my activity persisted by the bookmark, then I called

    wfApp.ResumeBookmark("MyBookmark",mydata) at some point;  Then depending on my logic, MyNotifiyHost is being called after resuming the bookmark, which is the persist point...

    Hum...if this was the reason why I was not seeing my message notified by my workflow, then what would be proper solution to solve this?

    Thanks,

    Tuesday, January 12, 2016 12:42 PM
  • T J,

    Sorry, I am a little confused by the end of your response.

    Were you previously not doing the ResumeBookmark, but now you are and your workflow is behaving as expected?

    Were you previously calling ResumeBookmark without first loading the workflow from persistence?

    It sounds to me that you have an activity that creates the bookmark, then has the activity that tries to use your MyNotifyHost extension. When the "bookmark activity" is executed, it creates the bookmark and causes the instance to go idle and unload. At that point, your host needs to create a new WorkflowApplication object using the same root Activity (the workflow definition), call WorkflowApplication.Load providing the instance id Guid, and then call WorkflowApplication.ResumeBookmark on that new WorkflowApplication object. This will cause the "bookmark activity" to complete and allow the workflow to continue execution on to the activity that invokes your MyNotifyHost extension.

    Jim

    Tuesday, January 12, 2016 8:47 PM
  • Jim,

    No, it is not working currently, but your description is exactly right the way how it currently is working.

    BTW, I forgot one information I gave you.

    If I use current new version, that works fine. However, if I load the old version of persisted workflow, then the host is not getting event.

    OK..here is how I load the persisted workflow.

    if(currentworkflowinstance.Equals(newversion...)) {

       wfApp =
                    new WorkflowApplication(new MyTestWorkflow(), currentworkflowinstance.DefinitionIdentity);

    }

    else {

        wfApp = create WorkflowApplication  instance like I posted previously...by using CreateInstance from old dll

    }

    The behavior I am seeing is that I don't see any expected one, only if the wfApp instance created from the old dll.

    Any clue?

    Thanks,


    • Edited by T J Wednesday, January 13, 2016 12:41 PM
    Wednesday, January 13, 2016 12:36 PM
  • T J,

    From what I can tell, it looks like you are handling the workflow definition versioning correctly. You are doing a dynamic load of the V1 dll to create an instance of the V1 workflow definition if the persisted workflow uses the V1 WorkflowIdentity.

    However, there is one thing that may be causing your problem.

    The V1 workflow definition has a "hard" reference to the IHostNotification type, which is defined in the V1 assembly. However, when you fire up your host, I suspect you are creating the MyNotifyHost object with "new", which would use the type from the V2 assembly. So the type of the object in the extensions collection for the WorkflowApplication is IHostNotification (V2). This type will not match the what the workflow definition (V1) is looking for.

    If this is the case, you have a couple of options:

    1) When you are about to load a V1 workflow instance, create the MyNotifyHost (V1) using the dynamically loaded assembly and add that to your extensions collection in the WorkflowApplication.

    2) Assuming your MyNotifyHost and IHostNotification definitions aren't changing, put those two types in a separate assembly from your workflow definition. Then those types won't change and your host instance will be using the same version as the V1 and V2 workflow definitions.

    Jim

    Wednesday, January 13, 2016 6:29 PM
  • Jim,

    Great..That was it. I appreciate your help!.

    Thanks,

    Thursday, January 14, 2016 8:34 PM