Azure Function Anatomy

In this lesson, we’ll examine the components that are common to any Azure function type, regardless of the language and runtime configuration that the function is based on. It doesn’t matter whether our function is written in Java, Python, or C#. It will still run the code in the same type of process. The following diagram demonstrates the basic structure of any Azure function:

An Azure function runs in its own process. The process acts as a container for the executable code, whether it’s a compiled executable file, interpreted script, or a separate executable process. The process also contains a binding configuration that determines how the executable code is triggered. When a specific type of event occurs in a specific place that the function is configured to listen to via its binding configuration, the executable code of the function is triggered.

Azure function bindings configuration

Each Azure function has a function.json file that provides the configuration of a function trigger, inputs, and outputs. With compiled function types where such data is set in the code, this file is auto-generated when the function is compiled, so it doesn’t need to be a part of the repository. If we use a CSX script, this file needs to be included with the function script file. The content of this file looks as follows:

The top-most JSON element in this file is bindings, which contains a collection of objects that represents a function binding configuration. We have it in line 2 of the code block above. Each function supports one and only one trigger type. However, both the input and the output have their own binding configuration. This is why there are two objects in the collection.

Each of these objects supports a variety of fields, some of which are specific to a trigger type or direction. The following fields are always present in a binding configuration object:

• name: This is the name of the object that represents the input or output parameters in the function. If the function is represented by a method that returns a value, the name field for the output configuration will be set to $return, as can be seen in line 14 in the example above.

• type: This is the type of the function’s inner or outer binding. For example, the value of httpTrigger that we have in line 6 in the example above tells us that the function is bound to an HTTP trigger.

• direction: The value of in relates the configuration object to input binding. The value of out represents the output binding.

Azure function app

A function app is one or more functions that are deployed together. For compiled functions, it’s equivalent to a standard application. For example, the following project represents a single function app with two HTTP trigger functions:

The Function class has two executable functions, one represented by a method defined in line 18 and the other represented by a method defined in line 29. If we launch the application, we will be able to trigger either of these functions via their corresponding URL. The URLs are as follows:

• Base application URL followed by the /api/Function1 path for Function1

• Base application URL followed by the /api/Function2 path for Function2

The base URL can be found in the playground next to the “Your app can be found at” heading. The expected output for each function is as follows:

• Function1: It returns the “Function 1 triggered” message.

• Function2: It returns the “Function 2 triggered” message.

Host settings

The host settings in a function application are configured by the host.json file. We can see this file in the above project setup and it consists of the following content:

This file is typically included in the code repository of a function application and is version-controlled. The settings represented by these files are global settings of the Azure Functions host and not the settings for an individual function application.

Application settings

In a local development environment, the application-specific settings in an Azure function are represented by the local.setting.json file. This is what this file contains in the project above:

This file contains settings that can be accessed from the application code. Some of these settings are accessed by the underlying framework. For example, the LocalHttpPort setting in line 8, which happens to be inside the Host block, configures the local HTTP port that the function would be accessed on. Most application settings would be inserted into the Values block that we define in line 3.

This file is typically excluded from the code repository. Because these settings are specific to a single local development machine, there is no need to persist them in the codebase for everyone. This is why the name of the file is typically added to the .gitignore file if we use Git as our source control system.

Configuring application settings in Azure

The application settings are configured differently in Azure. Even though the setting keys would be the same as in the local setup, their values will probably be different. Typically, we would configure these settings in the “Configuration” section of the Azure resource. But there are multiple ways of applying those. We can apply them manually via Azure Portal. Or we can import them in bulk by using various files, templates, and deployment pipelines.

Azure Functions admin API

As well as having URL endpoints for HTTP-triggered functions, the function process itself has API endpoints that allow us to perform administrative tasks with the functions. Here is what these API endpoints are. The following addresses represent paths relative to the base address.

• GET /admin/host/status/: Returns the status of the function host, e.g. whether it’s running or not.

• POST /admin/host/status/: Used for ping requests that set the status to Running.

• POST /admin/host/logs/: Retrieves the logs from the function host.

• POST /admin/functions/{function name}: Used to manually trigger any function with any trigger type, except HTTP and Event Grid. The request body must contain the input data in the shape that the function expects.

There are some other admin endpoints in the admin API. However, they are reserved for special cases and are not commonly used.