The English version of quarkus.io is the official project site. Translated sites are community supported on a best-effort basis.

Azure Functions with RESTEasy Reactive, Undertow, or Reactive Routes

The quarkus-azure-functions-http extension allows you to write microservices with RESTEasy Reactive (our Jakarta REST implementation), Undertow (servlet), Reactive Routes, or Funqy HTTP and make these microservices deployable to the Azure Functions runtime. In other words, this extension is a bridge from the Azure Functions HttpTrigger and the Quarkus family of HTTP APIs. One azure function deployment can represent any number of Jakarta REST, servlet, Reactive Routes, or Funqy HTTP endpoints.

This technology is considered preview.

In preview, backward compatibility and presence in the ecosystem is not guaranteed. Specific improvements might require changing configuration or APIs, and plans to become stable are under way. Feedback is welcome on our mailing list or as issues in our GitHub issue tracker.

For a full list of possible statuses, check our FAQ entry.

Por el momento, sólo se admiten los tipos de medios basados en texto, ya que Azure Functions HTTP Trigger para Java no admite un formato binario

Requisitos previos

To complete this guide, you need:

Solución

This guide walks you through running a maven project that can deploy a Resteasy Reactive endpoint to Azure Functions. While only Jakarta REST is provided as an example, you can easily replace it with the HTTP framework of your choice.

Creating the Maven/Gradle Project

You can generate the example code from Quarkus’s online application generator at this link.

You can also generate this example with the Quarkus CLI:

quarkus create app --extension=quarkus-azure-functions-http

Add the --gradle switch if you want to generate a gradle project.

Iniciar sesión en Azure

If you don’t log in to Azure you won’t be able to deploy.

az login

Quarkus dev mode

Quarkus dev mode works by just running your application as a HTTP endpoint. In dev mode there is no special interaction with the Azure Functions local runtime.

./mvnw clean package quarkus:dev

Examining the project

If you open the pom.xml or build.gradle build file of the generated project you’ll see that the project is similar to any other Quarkus project. The quarkus-azure-functions-http extension is the integration point between Quarkus and Azure Functions.

The current implementation of the quarkus-azure-functions-http extension no longer requires the azure-functions-maven-plugin or gradle equivalent. Local development and Azure Functions packaging and deployment is now all done by Quarkus.

Build configuration is now all within application.properties. The only required configuration switch is quarkus.azure-functions.app-name.

Descriptores de despliegue de Azure

The Azure Functions host.json deployment descriptor is automatically generated, but if you need to override it, declare it in the root directory of the project and rerun the build when you are ready.

Configuración de las rutas de acceso a la raíz

The default route prefix for an Azure Function is /api. All of your Jakarta REST, Servlet, Reactive Routes, and Funqy HTTP endpoints must explicitly take this into account. In the generated project this is handled by the quarkus.http.root-path switch in application.properties

Iniciar sesión en Azure

If you don’t log in to Azure you won’t be able to deploy.

az login

Quarkus dev mode

Quarkus dev mode does not work currently with Azure Functions.

Run locally in Azure Functions local environment

If you want to try this example within the local Azure Functions environment, you can use this command

./mvnw quarkus:run

or

./gradlew --info --no-daemon quarkusRun

Gradle is a bit quirky with process management, so you need the --no-daemon switch or control-c will not destroy the process cleanly and you’ll have open ports.

Note that you must have the Azure Functions Core Tools installed for this to work!

The URL to access the example would be:

Quarkus Integration Testing

You can implement integration tests using @QuarkusIntegrationTest functionality. When these integration tests run, the local Azure Functions environment will be spun up for the duration of integration testing.

For maven:

./mvnw -DskipITs=false verify

Make sure any integration tests you execute with maven use the *IT.java file pattern so that regular builds do not execute the test.

For Gradle:

./gradlew --info quarkusIntTest

Make sure any integration tests you execute with Gradle are located within src/integrationTest/java. Integration tests that exist in src/test will run with normal build and fail.

Deploy to Azure

The quarkus-azure-functions-http extension handles all the work to deploy to Azure. By default, Quarkus will use the Azure CLI in the background to authenticate and deploy to Azure. If you have multiple subscriptions associated with your account, you must set the quarkus.azure-functions.subscription-id property in your application.properties file to the subscription you want to use. For other authentication mechanisms and deployment options see our config properties here.

To run the deploy, after you build your project execute:

./mvnw quarkus:deploy

or

./gradlew --info deploy

If deployment is a success, Quarkus will output the endpoint URL of the example function to the console For Gradle, you must use the --info switch to see this output!

i.e.

[INFO] HTTP Trigger Urls:
[INFO] 	 HttpExample : https://{appName}.azurewebsites.net/api/{*path}

The URL to access the service would be something like