Just when you think you’ve seen it all, you run into something that makes you challenge what you think you know. Today’s SharePoint Workflow challenge was a bit of code that was behaving badly — but for reasons that didn’t make any sense. When I dug into it I found that my invoked method for a OnTaskChanged activity was null. In order to understand the importance of this fact I have to do a quick review.

In simple workflows the design time model and the run time model are the same. So you can have an activity named Foo and you can reference it with Foo in your code. That’s easy. The problem is when you introduce a loop, a replicator, or anything else that might cause activities to be replicated — and therefore you runtime model and your design time model no longer match. As soon as this happens you can’t use the activity name. You have to start referencing things based on the sender that your event receives as its first parameter.

I’m working on a parallel approval workflow which uses a custom sequence activity to hold the instance data for each instance of a replicator. To get to my instance information I walk up the tree from my sender to find my specific sequence activity which I know is the parent — and the activity that holds my instance data. This works great right up and until I don’t get my sending activity in the sender parameter. Without it I’m completely lost as to where I am in the workflow.

The solution is to add a code activity after OnTaskChanged and use the ExecuteCode event on the code event. This event will get its sender and can therefore locate itself in the hierarchy.