I’ve been looking at the new HTTP Worker feature from the Azure Functions team lately — see this post for an overview and getting started.

This post looks at writing non-http-triggered functions, in a language of your choice. We’ll look at a pretty common scenario: a function being triggered by a queue, then storing output in another queue and a cosmos collection.

See a working sample here: https://github.com/damoodamoo/azure-func-go-java.

What you need to do:

Create the function.json file to configure the bindings

file to configure the bindings Create an API endpoint to receive the input binding object

Do ‘something’ with the data we get (doesn’t matter what for our illustration)

Create a new output object to send back to the functions host.

We’ll do this in Java — but you can use a language of your choice.

Input and Output Bindings

When using the HTTP Worker, we don’t use any code annotations for bindings anymore, just json. You can find examples of all the supported bindings in the docs here.

function.json

Let’s look at a function.json which will cause a function to be triggered by a storage queue, and send its results to another queue and a cosmos collection:

Bindings -> Objects

With the HTTP Worker, all function input bindings are wrapped in an InvokeRequest object, and all output bindings sent back to the functions host need to be wrapped in the InvokeResponse object. These are plain objects that look like this:

InvokeRequest -> data coming into your function

{

"data": {... some data...}

"metadata": {...}

}

In Java this looks like:

InvokeRequest.java

Invoke Response -> Data flowing out of your function

Here’s the shape of the object the functions host is expecting back from you:

{

"outputs": {

"output1": {..some data..},

"output2": {..some data..},

},

"logs": {

"Log message 1",

"Log message 2",

},

"returnValue": {..some data..}

}

In Java this looks like:

Our API

Let’s now create our API endpoint to receive the InvokeRequest and return the InvokeResponse objects:

In the code above, we simply get the .Data payload given to us in the request (the queue item data), and we pass that to the output bindings (named output1 and output2 . Obviously you might want to actually *do* something with the data here :)

Notice how the output bindings relate to the function.json :

{

"name": "output1",

"type": "cosmosDB",

...

},

{ "name": "output2",

"type": "queue",

...

}

More Advanced HTTP Bindings

Since an HTTP response is also an output binding, you can use this approach to supply more customised responses. Note: if your function is http in and out, you don’t *need* to do this (you can return any arbitrary payload), but it does give you more control over things like status codes and responses.

Note in the above code we can now specify a status code and custom headers when returning HTTP.