We have a routing slip that contains several dynamically generated activities. We receive a RoutingSlipFaulted
event when any of these activities fault - this is the documented default and perfectly fine for most of our requirements.
We now have a case where each of these activities might fail and the execution of the subsequent activities in the routing slip should continue. The documentation says about this:
By default, if an activity throws an exception, it will be faulted and a RoutingSlipFaulted event will be published (unless a subscription changes the rules).
But how exactly do you "change the rules" on the subscription?
We're using a RoutingSlipBuilder
instance to create the routing slip, adding activities and a subscription like this:
public virtual RoutingSlip BuildRoutingSlip()
{
var builder = new RoutingSlipBuilder(Id);
// add activities
foreach (var activity in _activities)
{
[...]
builder.AddActivity(activity.Name, endpointAddress, argumentsObject);
}
// add monitoring subscription
builder.AddSubscription(Endpoints.GetEndpoint<Transaction>(),
RoutingSlipEvents.Completed | RoutingSlipEvents.Faulted | RoutingSlipEvents.ActivityCompleted | RoutingSlipEvents.ActivityFaulted,
RoutingSlipEventContents.All);
return builder.Build();
}
Where and how would we configure the subscription to continue the routing slip execution when an activity fails?
If an activity failing should not fault the routing slip, that activity should not throw an exception. It must call Completed
regardless of what happens inside the activity (exceptions, or otherwise).
The subscription has nothing to do with the routing slip execution behavior, it's purely for delivering routing slip events.