Get (Native)ActivityContext of the parent activity

Question

Hi all,

most of our activities derive from a custom activity base class which implements duration monitoring and exception handling, e.g. when an exception occurs in an activity, you can send someone a mail. The mail title, body etc are InArgument<string> on the activity base class, so then can contain VB expressions. The point is, you need the (Native)ActivityContext of the activity to evaluate the InArguments.

In the exception handling settings, we want the user to be able to specify "merge with parent exception handling settings", so when a child activity encounters an exception, it's exception handling is carried out, but it's also possible to surplus this with the exception handling on the parent activity.

We've already figured out how the child activity can have access to the parent activity (in fact, it's the top-level root activity) using WorkflowApplication Extensions.

However, we do not know how to get to the (Native)ActivityContext of the root activity. When the execute of the root activity is executed before the excute of the child activities it can also be passed using an Extension or so, but when the workflow is resumed after hibernation, the execute method of the root activity was never called, so we never can get our hands on this (Native)ActivityContext.

Is there a possibility of serialising a (Native)ActivityContext? Or is there a possiblity to construct one given the Activity?

Thanks for any suggestions,

Paul D'hertoghe

Answer 1

The activity context is more of a handle provided to the workflow by the runtime, which uses it to access the runtime's features- it's not really a data object that can be serialized.

What features of the activity context do you need access to?

Answer 2

Hi Patrick,

we need the ActivityContext to resolve the VisualBasicExpressions (see original post: The mail title, body etc are InArgument<string> on the activity base class, so then can contain VB expressions. The point is, you need the (Native)ActivityContext of the activity to evaluate the InArguments).

Answer 3

>We've already figured out how the child activity can have access to the parent activity (in fact, it's the top-level root activity) using WorkflowApplication Extensions.

Instead of accessing the parent activity and trying to read its arguments, which doesn't work, how about just access the exception handling settings - which you can conveniently make the parent store on the same extension?
Tim

Answer 4

Hello Tim,

we tought about that too, but it limits the flexibility, let me explain: when the parent activity (it's actually a custom flowchart-like activity) passes the Exception handling settings to the children through a WorkflowApplication Extension, that means that the properties are evaluated at the time the parent activity runs and not at the time the child activity runs. Knowing that these are long-running (several days, sometimes months) invoice approval workflows, it's important that the VisualBasicExpressions in the parent's exception handling properties (InArguments) are evaluated at the time the child encounters an exception. The exception can happen in a resume from hibernation function, long after the original start execution of the activity.

I'll give 2 examples:

* The mail addressee for exception handling can be configured in the database and is fetched using a VisualBasicExpression operating on a business object. It's quite possible that within a month, the mail must be sent to someone else who is responsible for resolving workflow exceptions (i.e. the mail addressee in the database has changed in the meantime).

* Exception handling puts a different "due date" on the workflow activity and makes it a kind of end-user task (which required input from a GUI). The parent activity can also influence this due date (e.g. a VisualBasicExpression containing DateTime.Now.AddDays(1)). This due date (now+24 hours) must be calculated "Now" (when the exception occurs on the child activity, when it resumes from hibernation) and NOT at the moment the parent activity runs (one month ago), nor when the child activity started execution (could be days ago).

Hopefully this sheds some light on the how and why

Answer 5

Thanks for explaining the scenario. Unfortunately ActivityContext is really not designed to be used from any activity other than the currently executing one. Perhaps you could consider letting the child activities return control the the parent activity with a completion callback. Then the parent activity gets its own ActivityContext back, can use it to evaluate expressions, and make the results available to the child activities. This is approximately how flowchart manages using expressions in flowswitch etc to control its child activity execution.
Tim

Answer 6

Hello Tim,

thanks for your suggestions. Can you point me to an example/documentation how to implement "letting the child activities return control the the parent activity with a completion callback" ?

Thanks in advance,

Paul D'hertoghe

Answer 7

Hello Tim,

thanks for your suggestions. Can you point me to an example/documentation how to implement "letting the child activities return control the the parent activity with a completion callback" ?

Thanks in advance,

Paul D'hertoghe

Use an overload such as NativeActivityContext.ScheduleActivity(Activity, CompletionCallback, FaultCallback)
Tim

Answer 8

Hello Tim,

thanks for all your help and suggestions, but it's not an ideal solution because the child activity is aborted and cannot be resumed (only restarted) and all InArguments are evaluated again.

I think it might be a solution if the parent activity is not "called" for executing the exception handling, but that the parent activity "hands over" an "Exception handling activity" to each child activity. That way the parent decides what exception handling is actually doing, but it is scheduled by the child activity when it encounters an exception.

Paul