Azure-functions-durable-extension: Yield values from a long-lived orchestrator function

Created on 14 Mar 2018  路  4Comments  路  Source: Azure/azure-functions-durable-extension

Scenario:

I have an application, and I want to strategically prompt users to share the application with their friends. In order to increase the chance of success and not annoy my users, I want to target a specific set of users based on their engagement/other behavior over a long period of time (multiple days), and only show the prompt when I think it will not disrupt them.
Modeling this interaction flow using durable functions seems like an intuitive choice. Based on some initial trigger, I can start up an orchestrator function, have the client send interaction events, and complete the orchestrator function with a directive to take an action (show the prompt) or not. The orchestrator function encapsulates all of the logic on the server side, and the client-server interaction is generic, meaning I can try out variations on the scenario as the need arises without having to update client code, and I can create multi-platform scenarios very easily.

Problem:

At any given time, the client only needs to notify the orchestrator function of a few specific events (ones that are relevant to the current state of the interaction flow). I'd like to avoid having clients send every possible event, since that would result in a lot of unnecessary network requests.
From the client perspective, after the initial triggering, the ideal would be to call an API that takes an event and associated payload as input and comes back with 1) the next set of events to send and 2) any intermediate actions that the client should take.
The orchestrator function knows what those specific events and actions are, but how can it communicate them to the client? The HTTP API doesn't allow arbitrary data to be passed back in the status response. The best that I can think of is to create an HTTP-triggered activity function that does the following:

  1. The activity calls StartNewAsync on a short-lived orchestrator Messenger.
  2. Messenger calls RaiseEventAsync on the main orchestrator function.
  3. The main orchestrator function sends a message back to Messenger with RaiseEventAsync with information about the next set of events and actions for the client.
  4. Messenger completes with the payload from the main orchestrator function.
  5. The activity, which has been waiting for Messenger to finish (#110), returns the response to the client.

Is there a more straightforward way to accomplish this?

Most helpful comment

Right now we're aiming for the first week of April as part of our RC release. You can track the status of the release here: https://github.com/Azure/azure-functions-durable-extension/milestone/4

All 4 comments

I think what you may be looking for is this: https://github.com/Azure/azure-functions-durable-extension/issues/96, but with a little more richness than a simple string.

Essentially, it allows an orchestration to expose arbitrary data to the outside world while it is still running. You can imagine the orchestrator function would have a context.SetCustomStatus(data) method where data is some arbitrary payload which gets exposed to clients as JSON. Clients can then read this custom status data by making calls to get the orchestrator status. When using the HTTP status query API, it would look something like this:

Request:
This is the existing status query API:

GET /admin/extensions/DurableTaskExtension/instances/instance123

Response
Note the new customStatus field in the response payload and that the orchestration is still running.

{
  "runtimeStatus": "Running",
  "input": null,
  "customStatus": { "nextActions": ["A", "B", "C"], "foo": 42 },
  "output": null,
  "createdTime": "2017-10-06T18:30:24Z",
  "lastUpdatedTime": "2017-10-06T19:40:30Z"
}

If you don't want to use the built-in HTTP APIs, you can get the same information using the DurableOrchestrationClient.GetStatusAsync(instanceId) method from within another function.

I'm actually coding it up and testing it now, and expect to have it available for the next release. Do you think this would work for your scenario?

An arbitrary JSON-serializable version of #96 would be great!
When do you expect the release to be ready?

Right now we're aiming for the first week of April as part of our RC release. You can track the status of the release here: https://github.com/Azure/azure-functions-durable-extension/milestone/4

This work is done and will go out with the next release. See the linked PR for details.

Was this page helpful?
0 / 5 - 0 ratings