Currently, the /signals/trigger endpoint that is invoked by generated signal token URLs only triggers the SignalReceived activity,
But if we include the activity type from where one generates the token (e.g. WitingOnTaskCompletion in below sample custom activity) then the endpoint that the URL points to can read the activity type and trigger that one instead of SignalReceived.
Which is great, because it simplifies implementing custom "signal" activities such as your example tremendously!
public class WaitingOnTaskCompletion : Activity
{
protected override IActivityExecutionResult OnExecute(ActivityExecutionContext context)
{
var signalUrl = context.GenerateSignalUrl("Done");
return Suspend();
}
}
This idea originates from a conversation I had with TedDBarr on Discord.
Currently, the
/signals/trigger
endpoint that is invoked by generated signal token URLs only triggers theSignalReceived
activity,But if we include the activity type from where one generates the token (e.g.
WitingOnTaskCompletion
in below sample custom activity) then the endpoint that the URL points to can read the activity type and trigger that one instead ofSignalReceived
.Which is great, because it simplifies implementing custom "signal" activities such as your example tremendously!