You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Orchestrator functions should be able to be triggered by HTTP requests directly rather than needing to write a boilerplate "start" function (or copying the "starter" http trigger which exists in the samples).
Motivation
The main motivation is to reduce the amount of work required to trigger new orchestrations. In particular, we want to be able to more easily integrate with other services like LogicApps, which know how to securely invoke HTTP triggers using a function key.
Design (Proposal)
The code for this would be implemented in HttpApiHandler just like the other HTTP APIs. The basic idea is:
1. Create new instance with a random ID
Request template
POST /runtime/webhooks/durabletask/orchestrators/{functionName}
The implementation should match the HttpStart sample here, but with improved robustness (for example, it should work even if Content-Type: application/json isn't specified) and with friendlier error messages (e.g. friendly HTTP 400 response if the function doesn't exist).
2. Create new instance with specified ID
Request template
POST /runtime/webhooks/durabletask/orchestrators/{functionName}/{instanceId}
This should use the sample implementation as the previous, except that the caller specifies instanceId explicitly.
REVIEW: Should this be PUT instead of POST?
3. Create new instance and wait for it to complete
Request template
POST /runtime/webhooks/durabletask/orchestrators/{functionName}[/{instanceId}]?timeout={timeoutInSeconds}&pollingInterval={intervalInSeconds}
The implementation should match the HttpStartSync sample here but without the /wait segment (that was a workaround for ASP.NET routing limitations) and with an implementation that borrows logic from the previous two API scenarios. Note that this would support both a randomly generated instance ID and a user-specified instance ID.
The text was updated successfully, but these errors were encountered:
Hi @kashimiz, now that the code work has been done, we also need the documentation to be updated. I think it's just the HTTP API doc which needs updating:
Summary
Orchestrator functions should be able to be triggered by HTTP requests directly rather than needing to write a boilerplate "start" function (or copying the "starter" http trigger which exists in the samples).
Motivation
The main motivation is to reduce the amount of work required to trigger new orchestrations. In particular, we want to be able to more easily integrate with other services like LogicApps, which know how to securely invoke HTTP triggers using a function key.
Design (Proposal)
The code for this would be implemented in
HttpApiHandler
just like the other HTTP APIs. The basic idea is:1. Create new instance with a random ID
Request template
The implementation should match the HttpStart sample here, but with improved robustness (for example, it should work even if
Content-Type: application/json
isn't specified) and with friendlier error messages (e.g. friendly HTTP 400 response if the function doesn't exist).2. Create new instance with specified ID
Request template
This should use the sample implementation as the previous, except that the caller specifies
instanceId
explicitly.3. Create new instance and wait for it to complete
Request template
The implementation should match the HttpStartSync sample here but without the
/wait
segment (that was a workaround for ASP.NET routing limitations) and with an implementation that borrows logic from the previous two API scenarios. Note that this would support both a randomly generated instance ID and a user-specified instance ID.The text was updated successfully, but these errors were encountered: