Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Built-in support for triggering new orchestration instances from HTTP #61

Closed
cgillum opened this issue Sep 13, 2017 · 3 comments
Closed
Assignees
Labels

Comments

@cgillum
Copy link
Member

cgillum commented Sep 13, 2017

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

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.

@gled4er

This comment has been minimized.

@cgillum
Copy link
Member Author

cgillum commented Oct 11, 2018

I updated this issue just now with a high-level design proposal.

@kashimiz kashimiz self-assigned this Oct 17, 2018
kashimiz added a commit to kashimiz/azure-functions-durable-extension that referenced this issue Oct 20, 2018
@cgillum
Copy link
Member Author

cgillum commented Nov 5, 2018

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:

I emailed @ggailey777 to ask about the best way for us to stage this docs.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

3 participants