0

I want to create a Durable Function that calls an Activity Function, and then returns a value using dotnet core in a v2 function app. The function will of course validate its input, so may return a successful value or it may return an invalid error: a 200 or a 400 in HTTP terms. My activity function will be something like this:

[FunctionName("MyFunc")]
public static async Task<object> Run(
        [ActivityTrigger] string input,
        ILogger log)
{
    // return something like
    return new { Status = "OK", Content = content };
}

What return type should I use for this? Should make my own DTO that would be a valid response, or is there a way of returning HttpResponse objects to the orchestrator?

Aidan
  • 4,783
  • 5
  • 34
  • 58
  • Functions ships with `OkObjectResult` and `BadRequestObjectResult` where you can pass in an object, if that would fit yout needs? – Mark C. Jan 29 '19 at 20:38
  • Yes, I think it would, so I suppose that the return type would just be ActionResult. – Aidan Jan 30 '19 at 12:03

1 Answers1

3

I think there may be a simpler solution here. Have you considered returning a simple value if your verification passes, and throwing an exception handled by the orchestrator if your verification fails?

The ActivityTrigger binding handles both input and output. Per the docs on error handling, an activity function can return any sort of JSON-serializable object to the orchestrator, and unhandled exceptions thrown by an activity function are marshalled back to the orchestrator, where they can be handled by catch blocks.

Activity-orchestrator communication doesn't use HTTP requests and responses; it uses Azure Storage tables to record history events and Azure Storage queues to trigger activities to perform async work or wake up the orchestrator once some activity's async work has completed, respectively. Unless you specifically need an HttpResponse object somewhere in your orchestration, there's no need to wrap your activity's return value in one.

Katy Shimizu
  • 1,051
  • 5
  • 9
  • I have considered that, although was reluctant as I tend to think of exceptions as for exceptional circumstances and not really as message senders. I am aware that Activity functions are abstractions over storage queues, but I like the fact that developers are extremely comfortable with HTTP status codes so my code would be clearer if it handled "Bad Request" rather than "ArgumentException" – Aidan Jan 30 '19 at 12:02
  • Thanks for clarifying. I had made the assumption that valid data was considered a precondition of your function that it checked for, and you were asking about the best way to relay errors back to the orchestrator. This becomes more of a general function design question, then. Personally I would go with a DTO - to me HttpResponse objects imply an HTTP request had been made, as do HTTP status codes, and seeing them used otherwise would be confusing. Additionally, the HTTP response classes (ex. OkObjectResult) contain additional fields that would be de/serialized, adding unnecessary overhead. – Katy Shimizu Jan 30 '19 at 19:08
  • Actually, you are right - the more natural place to validate the input would be the orchestrator function, not the activity function and then just use a simple DTO to return. Thanks for your input! – Aidan Jan 31 '19 at 10:09