specified Activity in Workflow 4 RC
so I have this requirement to kick off Activities provided to me at run-time. To facilitate this, I have set up a WorkflowService that receives Activities as Xaml, hydrates them, and kicks them off.
Sounds simple enough ...
... this is my WorkflowService in Xaml
<Activity
x:Class="Workflow.Services.WorkflowService.WorkflowService"
...
xmlns:local1="clr-namespace:Workflow.Activities" >
<Sequence sap:VirtualizedContainerService.HintSize="277,272">
<Sequence.Variables>
<Variable x:TypeArguments="local:Workflow" Name="Workflow" />
</Sequence.Variables>
<sap:WorkflowViewStateService.ViewState>
<scg3:Dictionary x:TypeArguments="x:String, x:Object">
<x:Boolean x:Key="IsExpanded">True</x:Boolean>
</scg3:Dictionary>
</sap:WorkflowViewStateService.ViewState>
<p:Receive CanCreateInstance="True" DisplayName="ReceiveSubmitWorkflow" sap:VirtualizedContainerService.HintSize="255,86" OperationName="SubmitWorkflow" ServiceContractName="IWorkflowService">
<p:ReceiveParametersContent>
<OutArgument x:TypeArguments="local:Workflow" x:Key="workflow">[Workflow]</OutArgument>
</p:ReceiveParametersContent>
</p:Receive>
<local1:InvokeActivity Activity="[ActivityXamlServices.Load(New System.IO.StringReader(Workflow.Xaml))]" sap:VirtualizedContainerService.HintSize="255,22" />
</Sequence>
</Activity>
... which, except for repetitive use of "Workflow" is pretty straight forward. In fact, it's just a Sequence with a Receive and [currently] a custom Activity called InvokeActivity . Get to that in a bit.
Receive Activity accepts a custom type,
[DataContract]
public class Workflow
{
[DataMember]
public string Xaml { get; set; }
}
which contains a string whose contents are to be interpreted as Xaml. You can see the VB expression that then converts this Xaml to an Activity and passes it on.
Now this second bit, the custom InvokeActivity is where I have questions.
First question:
1) given an arbitrary task, provided at runtime [as described above] is it possible to kick off this Activity using Activities that ship with WF4RC, out of the box? I'm fairly new, and thought I did a good job going through the API and existing documentation, but may as well ask :)
Second:
2) my first attempt at implementing a custom InvokeActivity looked like this
public sealed class InvokeActivity : NativeActivity
{
private static readonly ILog _log =
LogManager.GetLogger (typeof (InvokeActivity));
public InArgument<Activity> Activity { get; set; }
public InvokeActivity ()
{
_log.DebugFormat ("Instantiated.");
}
protected override void Execute (NativeActivityContext context)
{
Activity activity = Activity.Get (context);
_log.DebugFormat ("Scheduling activity [{0}]...", activity.DisplayName);
// throws exception to lack of metadata! :(
ActivityInstance instance =
context.ScheduleActivity (activity, OnComplete, OnFault);
_log.DebugFormat (
"Scheduled activity [{0}] with instance id [{1}].",
activity.DisplayName,
instance.Id);
}
protected override void CacheMetadata (NativeActivityMetadata metadata)
{
// how does one add InArgument<T> to metadata? not easily
// is my first guess
base.CacheMetadata (metadata);
}
// private methods
private void OnComplete (
NativeActivityContext context,
ActivityInstance instance)
{
_log.DebugFormat (
"Scheduled activity [{0}] with instance id [{1}] has [{2}].",
instance.Activity.DisplayName,
instance.Id,
instance.State);
}
private void OnFault (
NativeActivityFaultContext context,
Exception exception,
ActivityInstance instance)
{
_log.ErrorFormat (
@"Scheduled activity [{0}] with instance id [{1}] has faulted in state [{2}]
{3}",
instance.Activity.DisplayName,
instance.Id,
instance.State,
exception.ToStringFullStackTrace ());
}
}
Which attempts to schedule the specified Activity within the current context. Unfortunately, however, this fails. When I attempt to schedule said Activity, the runtime returns with the following exception
The provided activity was not part of this workflow definition when its metadata was being processed. The problematic activity named 'DynamicActivity' was provided by the activity named 'InvokeActivity'.
Right, so the "dynamic" Activity provided at runtime is not a member of InvokeActivity s metadata. Googled and came across this. Couldn't sort out how to specify an InArgument<Activity> to metadata cache, so my second question is, naturally, how does one address this issue? Is it ill advised to use context.ScheduleActivity (...) in this manner?
Third and final,
3) I have settled on this [simpler] solution for the time being,
public sealed class InvokeActivity : NativeActivity
{
private static readonly ILog _log =
LogManager.GetLogger (typeof (InvokeActivity));
public InArgument<Activity> Activity { get; set; }
public InvokeActivity ()
{
_log.DebugFormat ("Instantiated.");
}
protected override void Execute (NativeActivityContext context)
{
Activity activity = Activity.Get (context);
_log.DebugFormat ("Invoking activity [{0}] ...", activity.DisplayName);
// synchronous execution ... a little less than ideal, this
// seems heavy handed, and not entirely semantic-equivalent
// to what i want. i really want to invoke this runtime
// activity as if it were one of my own, not a separate
// process - wrong mentality?
WorkflowInvoker.Invoke (activity);
_log.DebugFormat ("Invoked activity [{0}].", activity.DisplayName);
}
}
Which simply invokes specified task synchronously within its own runtime instance thingy [use of WF4 vernacular is certainly questionable]. Eventually, I would like to tap into WF's tracking and possibly persistance facilities. So my third and final question is, in terms of what I would like to do [ie kick off arbitrary workflows inbound from client applications] is this the preferred method?
Alright, thanks in advance for your time and consideration :)
The provided activity was not part of this workflow definition when its metadata was being >processed. The problematic activity named 'DynamicActivity' was provided by the activity >named 'InvokeActivity'.
Workflow 4.0 only allows you to schedule children which were part of the tree before you started execution.
This rule probably exists because the tree so built is re-usable by multiple worklfow instances. If instance A were to modify the tree while instance B is still running, the results would give the runtime team horrible headaches.
In practice this means the only way you can do what you want with scheduling the child dynamically at runtime is to kick off an entirely new workflow (and optionally wait for that to complete).
链接地址: http://www.djcxy.com/p/95870.html上一篇: 运行时显示工作流程
下一篇: 在工作流程4 RC中指定的活动