locked
Resuming an idle workflow via a Bookmark is completing the workflow prematurely RRS feed

  • Question

  • I've come across an issue that I can't seem to figure out the reason it's happening ... it has to do with the resuming of a persisted workflow.  So I execute the workflow and run through a couple activities.  Then the workflow is halted, a bookmark is created and the dialog is closed.  When I resume that same workflow via the "ResumeBookmark" method, it loads initially fine, resuming at the same place.  I can then run through ONE more activity and then the workflow immediately completes.  It always seems to be one more activity ... and then the abrupt completion of the workflow, even it has a few more activities left to complete.

    Is there any reason this might be happening? 

    Tuesday, March 8, 2011 12:35 AM

Answers

  • Hmm..
    I still can't see anything which the framework is doing that looks weird based on what is posted above. Maybe it's better if we focus on the question of 'why is the behavior unexpected'.

    Somehow you must have verified that there is outstanding work which should block the workflow from completing, in terms of the workflow scheduler.

    e.g. By setting breakpoints? Emitting tracking data to show that further activities were schedule? You should be proving that there was a call to ScheduleActivity, or something similar, which should prevent the workflow from completing, and yet it completes anyway?
    Tim

    • Marked as answer by Andrew_Zhu Monday, March 14, 2011 2:45 AM
    Wednesday, March 9, 2011 7:25 PM

All replies

  • What sort of application is your host application? Is there any possibility that your host application is completing after resuming the bookmark, and therefore interrupting the completion of the workflow (this is common with starter console type applications that are sometimes used when prototyping).

    By abruptly completing, are the Completed or Aborted handlers being invoked, and if so is there any exception information, or does it just suddenly stop.

    If you enable tracking, what does that show?

    Please let me know what type of workflow host you are using and if you have any additional information and we can take a deeper look.

    Thanks,

    Steve Danielson [Microsoft]
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

    Tuesday, March 8, 2011 9:28 PM
  • So the host is a WorkflowApplication.  It actually calls the Completed handler, but with no exceptions ... the strange thing is that it completes one more activity successfully after resuming and then immediately after moving to the next activity it completes (and calls the completed handler), even though it hasn't run it's course through the workflow.

    I should note that we are essentially "stepping" through a workflow (from a UI), activity by activity using Next and Previous buttons to completion.  The code for our next button click is like this:

        private void MoveNext()
        {
          if (CurrentActivityInstance != null)
            CurrentActivityInstance.Save();
    
          NavigationInfo.NavigationDirection = NavigationEnum.Next;
          mWFAppInstance.ResumeBookmark(NavigationInfo.LastBookmarkName, null);
    
          // We can set the IsActivityCompleted property to true for the current activity
          // since we are now moving onto the next one
          this.CurrentActivityInstance.IsActivityCompleted = true;
        }
    

     

     

    Tuesday, March 8, 2011 9:58 PM
  • Are there some custom native activities involved in this? Is it possible that you have a bug in your custom native activity in which it forgets to schedule the next activity execution?
    Tim
    Tuesday, March 8, 2011 10:22 PM
  • What type is CurrentActivityInstance? Is that just some sort of internal tracking or is that a reference to a workflow type? Do you have any exception handling in the workflow, like a root TryCatch?

    If you enable tracing/tracking, is there any unusual things appearing? http://msdn.microsoft.com/en-us/library/ee513992.aspx?appId=Dev10IDEF1&l=EN-US&k=k(MICROSOFT.TEAMFOUNDATION.BUILD.WORKFLOW.ACTIVITIES.COPYDIRECTORY.UI);k(DEFAULTWORKFLOWDESIGNER.UI)&rd=true

    Steve Danielson [Microsoft]
    This posting is provided "AS IS" with no warranties, and confers no rights.
    Use of included script samples are subject to the terms specified at http://www.microsoft.com/info/cpyright.htm

     

    Tuesday, March 8, 2011 10:23 PM
  • We do have some tracking going on, but I don't see anything unusual as far as the tracking records that are getting thrown into the DB.  Here's a snippet of some tracking being done in the Execute method of a custom NativeActivity:

            //track settings
            CustomTrackingRecord TrackingRecord = new CustomTrackingRecord("UI Activity");
            TrackingRecord.Data.Add("Required", IsRequired.ToString());
            TrackingRecord.Data.Add("UserControlToShow", UserControlToShow.ToString());
            executionContext.Track(TrackingRecord);
    
            //create a new bookmark
            string bookMarkName = windowControl.WorkflowInstanceID.ToString();
            navInfo.LastBookmarkName = bookMarkName;
            executionContext.CreateBookmark(bookMarkName, ActivityExecutionResumed, BookmarkOptions.MultipleResume);
    
    The CurrentActivityInstance you asked about is just a way for us to internally keep track of the current activity instance that before the "next" button is pressed to move forward through the workflow.
    Wednesday, March 9, 2011 12:35 AM
  • Bookmark creation looks fine, but what happens in ActivityExecutionResumed? Are you scheduling something? Creating other bookmarks? How are you keeping track of which activites are not completed yet?

    Wednesday, March 9, 2011 1:48 AM
  • The ActivityExecutionResumed looks like this:

        protected virtual void ActivityExecutionResumed(NativeActivityContext context, Bookmark bookmark, object value)
        {
          context.RemoveAllBookmarks();
          
          //if we got a passed in value, that means that the workflow itself was resumed
          //in that case, we want to re-execute the current control to keep the user on the screen they were on 
          //when they quit the workflow
          if (value != null)
          {
            this.Execute(context);
          }
          
        }
    

     

    We're using a class we created called NavigationInformation which stores the current activity ID ... so when we resume the bookmark, we just iterate through all the activities in the flowchart (we're always dealing with flowcharts) and find the next activity to execute after the current activity that matches the ID.

     

    Wednesday, March 9, 2011 3:24 PM
  • Hmm..
    I still can't see anything which the framework is doing that looks weird based on what is posted above. Maybe it's better if we focus on the question of 'why is the behavior unexpected'.

    Somehow you must have verified that there is outstanding work which should block the workflow from completing, in terms of the workflow scheduler.

    e.g. By setting breakpoints? Emitting tracking data to show that further activities were schedule? You should be proving that there was a call to ScheduleActivity, or something similar, which should prevent the workflow from completing, and yet it completes anyway?
    Tim

    • Marked as answer by Andrew_Zhu Monday, March 14, 2011 2:45 AM
    Wednesday, March 9, 2011 7:25 PM