Referência legada do Funções do Azure runtime 1.x

Importante

O suporte terminou para a versão 1.x do runtime do Funções do Azure a 14 de setembro de 2026. Migra as tuas aplicações para a versão 4.x para suporte total.

Este artigo preserva informações históricas chave e liga a referências detalhadas para aplicações de funções que ainda utilizam o runtime 1.x. Não uses o runtime 1.x para novas aplicações funcionais.

Âmbito de execução 1.x

O runtime do Funções do Azure 1.x terminou o suporte a 14 de setembro de 2026 e não é suportado para aplicações de funções novas ou existentes. O Runtime 1.x tinha as seguintes características:

  • Só funcionava no Windows.
  • Suportava aplicações C# direcionadas ao .NET Framework e aplicações JavaScript.
  • Aplicações C# corriam em processo. O runtime 1.x não suportava o modelo de trabalhador isolado.
  • Utilizava a versão 1.x do Funções do Azure Core Tools para desenvolvimento local. O Core Tools 1.x funciona apenas no Windows.
  • O runtime incluía as suas ligações suportadas. Versões posteriores em tempo de execução utilizam extensões de binding versionadas separadamente ou pacotes de extensões.

Versões do modelo em tempo de execução, extensão e programação

A versão de runtime do Funções do Azure não é a mesma que as versões usadas por extensões de binding, pacotes de extensões ou modelos de programação de linguagem. Um rótulo de versão noutro componente não indica que uma aplicação usa o runtime do Funções do Azure 1.x. Por exemplo:

  • Os modelos de programação Python v1 e v2 correm em tempo de execução 4.x.
  • Os modelos de programação Node.js v3 e v4 correm em runtime 4.x.
  • As versões do pacote de extensões e do pacote de extensão de binding são independentes da versão em tempo de execução.

Migrar para runtime 4.x

Para devolver uma aplicação ao suporte completo, migre-a do runtime 1.x para o runtime 4.x. O guia de migração cobre as seguintes tarefas:

  • Identifique aplicações que visam o tempo de execução 1.x.
  • Escolha um destino suportado para C# ou JavaScript.
  • Atualiza o projeto, as ligações, as definições da aplicação e host.json ficheiro.
  • Teste a aplicação localmente e atualize a aplicação de funções no Azure.

Não mudes apenas as FUNCTIONS_EXTENSION_VERSION definições da aplicação. As atualizações em tempo de execução podem exigir alterações de projeto, código, binding e configuração.

Definições da aplicação específicas para runtime 1.x

A configuração obsoleta AzureWebJobsDashboard é suportada apenas pelo runtime 1.x. Contém uma cadeia de ligação opcional de conta de armazenamento de uso geral, usada para armazenar registos e exibi-los no separador Monitor do portal Azure.

Key Valor da amostra
AzureWebJobsDashboard DefaultEndpointsProtocol=https;AccountName=...

O Runtime 1.x não suporta a AZURE_FUNCTIONS_ENVIRONMENT definição da aplicação.

O FUNCTIONS_EXTENSION_VERSION valor ~1 fixa uma aplicação de função no runtime 1.x. O armazenamento de chaves no sistema de ficheiros (AzureWebJobsSecretStorageType=files) é o predefinido.

A functionsRuntimeAdminIsolationEnabled propriedade do site não está disponível no runtime 1.x. A FUNCTIONS_V2_COMPATIBILITY_MODE definição não se aplica a aplicações em tempo de execução 1.x.

Project e diferenças linguísticas

Os projetos de bibliotecas de classes C# 1.x em tempo de execução tinham como alvo o .NET Framework e utilizavam a versão 1.x do Microsoft.NET.Sdk.Functions pacote. Podiam ser usados TraceWriter para exploração florestal. Para o modelo de projeto atual em C# e considerações de migração, consulte o guia para desenvolvedores da biblioteca de classes .NET e o guia de migração em tempo de execução 1.x.

Projetos de biblioteca da classe C#

O exemplo seguinte mostra as partes relevantes de um ficheiro de projeto 1.x em tempo de execução:

<PropertyGroup>
  <TargetFramework>net48</TargetFramework>
</PropertyGroup>
<ItemGroup>
  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.24" />
</ItemGroup>

As Microsoft.NET.Sdk.Functions dependências dos pacotes incluem triggers e bindings. Um projeto 1.x refere-se a triggers e bindings 1.x porque têm como alvo o .NET Framework. A embalagem também depende e Newtonsoft.Json indiretamente de WindowsAzure.Storage. Estas dependências garantem que o projeto utiliza versões compatíveis com o runtime das Funções alvo. Por exemplo, o tempo de execução Functions que direciona o .NET Framework 4.6.1 é compatível com a versão 9.0.1, não com Newtonsoft.Json a versão 11.

Runtime 1.x usado TraceWriter para registo do Application Insights. TraceWriter Não suporta registos estruturados.

O exemplo seguinte cria um TelemetryClient e usa TrackEvent, TrackMetric, e TrackDependency para registar telemetria personalizada. Também utiliza o contexto de execução da função para correlacionar a telemetria personalizada com a invocação atual.

Exemplo de telemetria personalizada

using System;
using System.Linq;
using System.Net.Http;
using System.Threading.Tasks;
using Microsoft.ApplicationInsights;
using Microsoft.ApplicationInsights.DataContracts;
using Microsoft.ApplicationInsights.Extensibility;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.Http;
using Microsoft.Extensions.Logging;

namespace functionapp0915
{
	public static class HttpTrigger2
	{
		private static string key = TelemetryConfiguration.Active.InstrumentationKey =
			Environment.GetEnvironmentVariable(
				"APPINSIGHTS_INSTRUMENTATIONKEY", EnvironmentVariableTarget.Process);

		private static TelemetryClient telemetryClient =
			new TelemetryClient() { InstrumentationKey = key };

		[FunctionName("HttpTrigger2")]
		public static async Task<HttpResponseMessage> Run(
			[HttpTrigger(AuthorizationLevel.Anonymous, "get", "post", Route = null)]
			HttpRequestMessage req, ExecutionContext context, ILogger log)
		{
			log.LogInformation("C# HTTP trigger function processed a request.");
			DateTime start = DateTime.UtcNow;
			string name = req.GetQueryNameValuePairs()
				.FirstOrDefault(q => string.Compare(q.Key, "name", true) == 0)
				.Value;
			dynamic data = await req.Content.ReadAsAsync<object>();
			name = name ?? data?.name;

			var evt = new EventTelemetry("Function called");
			UpdateTelemetryContext(evt.Context, context, name);
			telemetryClient.TrackEvent(evt);

			var metric = new MetricTelemetry("Test Metric", DateTime.Now.Millisecond);
			UpdateTelemetryContext(metric.Context, context, name);
			telemetryClient.TrackMetric(metric);

			var dependency = new DependencyTelemetry
			{
				Name = "GET api/planets/1/",
				Target = "swapi.co",
				Data = "https://swapi.co/api/planets/1/",
				Timestamp = start,
				Duration = DateTime.UtcNow - start,
				Success = true
			};
			UpdateTelemetryContext(dependency.Context, context, name);
			telemetryClient.TrackDependency(dependency);
		}

		private static void UpdateTelemetryContext(
			TelemetryContext context,
			ExecutionContext functionContext,
			string userName)
		{
			context.Operation.Id = functionContext.InvocationId.ToString();
			context.Operation.ParentId = functionContext.InvocationId.ToString();
			context.Operation.Name = functionContext.FunctionName;
			context.User.Id = userName;
		}
	}
}

O Runtime 1.x também suportava scripts C# (.csx) e funções JavaScript. O script C# não é específico para o runtime 1.x, por isso usa a referência do desenvolvedor do script C# para orientações gerais sobre scripts. Use o guia de migração para alterações específicas de tempo de execução.

Para exemplos da sintaxe C# anterior, veja os modelos de funções em tempo de execução 1.x.

Assemblies e pacotes de scripts C#

Nas funções de script C# 1.x em tempo de execução, podias referenciar as seguintes assemblies por simples nome:

  • Newtonsoft.Json
  • Microsoft.WindowsAzure.Storage
  • Microsoft.ServiceBus
  • Microsoft.AspNet.WebHooks.Receivers
  • Microsoft.AspNet.WebHooks.Common

O runtime 1.x usava um ficheiroproject.json para definir dependências. O exemplo seguinte adiciona o Microsoft.ProjectOxford.Face pacote NuGet:

{
	"frameworks": {
		"net46": {
			"dependencies": {
				"Microsoft.ProjectOxford.Face": "1.1.0"
			}
		}
	}
}

Pacotes de extensão não são suportados pelo runtime 1.x. Para usar um feed NuGet personalizado, especifique o feed num ficheiro NuGet.Config na pasta raiz da function app. Para obter mais informações, consulte Configurando o comportamento do NuGet.

Desenvolvimento local com Core Tools 1.x

A versão 1.x do Funções do Azure Core Tools está emparelhada com o runtime 1.x e funciona apenas no Windows. Para iniciar a execução, executaste func host start. Para orientações atuais sobre desenvolvimento local, consulte Develop Funções do Azure localmente usando Core Tools.

O Visual Studio armazenava as versões %USERPROFILE%\AppData\Local\Azure.Functions.Cli 1.x do Core Tools em tempo de execução e usava a versão mais recente armazenada ali. Pode ver a versão selecionada na saída da consola ao executar o projeto:

[3/1/2018 9:59:53 AM] Starting Host (HostId=contoso2-1518597420, Version=2.0.11353.0, ProcessId=22020, Debug=False, Attempt=0, FunctionsExtensionVersion=)

Runtime 1.x host.json referência

O esquemahost.json e as definições mudaram após a execução 1.x. Consulte a referência de execução 1.x host.json ao rever uma configuração existente e compare com a referência host.json atual durante a migração.

Monitorize aplicações de execução 1.x com Application Insights

O Runtime 1.x utiliza as seguintes categorias de registos do Application Insights:

Categoria Table Description
Function vestígios Logs gerados pelo usuário, que podem ser de qualquer nível de log.
Host.Aggregator customMetrics Contagens e médias de invocações de funções ao longo de um período configurável. O padrão é 30 segundos ou 1.000 resultados, o que acontecer primeiro. Esses logs são gravados no Information nível.
Host.Executor vestígios Função iniciada e concluída dos registos. Execuções bem-sucedidas usam Information, exceções usam Error, e condições como mensagens poison-queue usam Warning.
Host.Results pedidos Sucesso ou fracasso das execuções de funções. Esses logs são gravados no Information nível.

Configurar níveis de log

O runtime 1.x configura os níveis de log em logger.categoryFilterhost.json:

{
	"logger": {
		"categoryFilter": {
			"defaultLevel": "Warning",
			"categoryLevels": {
				"Host.Results": "Information",
				"Host.Aggregator": "Trace",
				"Function": "Information"
			}
		}
	}
}

Quando vários nomes de categorias começam com a mesma cadeia, a categoria mais específica é associada primeiro. O exemplo seguinte regista tudo exceto Host.Aggregator ao Error nível:

{
	"logger": {
		"categoryFilter": {
			"defaultLevel": "Information",
			"categoryLevels": {
				"Host": "Error",
				"Function": "Error",
				"Host.Aggregator": "Information"
			}
		}
	}
}

Configurar amostragem

A taxa máxima padrão de telemetria é de cinco itens por segundo. Runtime 1.x configura a amostragem em applicationInsights.sampling:

{
	"applicationInsights": {
		"sampling": {
			"isEnabled": true,
			"maxTelemetryItemsPerSecond": 5
		}
	}
}

O exemplo seguinte combina filtragem por categorias e amostragem:

{
	"logger": {
		"categoryFilter": {
			"defaultLevel": "Warning",
			"categoryLevels": {
				"Function": "Error",
				"Host.Aggregator": "Error",
				"Host.Results": "Information",
				"Host.Executor": "Warning"
			}
		}
	},
	"applicationInsights": {
		"sampling": {
			"isEnabled": true,
			"maxTelemetryItemsPerSecond": 5
		}
	}
}

O Runtime 1.x não suporta configuração por função.

Capacidades do Application Insights

O Runtime 1.x recolhia automaticamente pedidos, exceções e contadores de desempenho. Não recolhia automaticamente HTTP, Service Bus, Event Hubs ou dependências SQL. Suportava QuickPulse/Live Metrics sem um canal de controlo seguro e suportava amostragem, mas não suportava heartbeats, correlação Service Bus ou Event Hubs, nem recolha de telemetria totalmente configurável.

Funcionalidades e comportamento não suportados no runtime 1.x

  • As políticas de retentativas não são suportadas.
  • A monitorização dinâmica em escala dos gatilhos da rede virtual não é suportada.
  • Nos planos Premium e Dedicados, o tempo de execução da função padrão é ilimitado. No plano de Consumo, o tempo de espera padrão é de cinco minutos e o máximo é de 10 minutos.
  • Uma aplicação de funções que utiliza um pacote de deployment remoto não pode correr sem uma partilha Ficheiros do Azure.

Ligações incluídas em runtime 1.x

O runtime do Funções do Azure 1.x está retirado. Quando migrar para runtime 4.x, use extensões de binding atuais ou um pacote de extensões e reveja cada binding para alterações de configuração e tipo.

As seguintes ligações foram incluídas no runtime 1.x. A coluna do atributo C# mostra os nomes curtos usados no código. Os nomes das classes correspondentes têm um Attribute sufixo, como BlobTriggerAttribute. As funções de script C# definem ligações no ficheirofunction.json .

Tipo Trigger Entrada Output Atributos C#
Armazenamento de Blobs Yes Yes Yes [BlobTrigger] (gatilho)
[Blob] (entrada/saída)
Azure Cosmos DB Yes Yes Yes [CosmosDBTrigger] (gatilho)
[DocumentDB] (entrada/saída)
Grelha de Eventos Yes No No [EventGridTrigger]
Hubs de Eventos Yes No Yes [EventHubTrigger] (gatilho)
[EventHub] (saída)
HTTP e webhooks Yes No Yes [HttpTrigger]
Hub IoT Yes No No [EventHubTrigger]
Aplicações Móveis No Yes Yes [MobileTable]
Hubs de Notificação No No Yes [NotificationHub]
Armazenamento em Fila Yes No Yes [QueueTrigger] (gatilho)
[Queue] (saída)
SendGrid No No Yes [SendGrid]
Autocarro de serviço Yes No Yes [ServiceBusTrigger] (gatilho)
[ServiceBus] (saída)
Armazenamento de Tabelas No Yes Yes [Table]
Temporizador Yes No No [TimerTrigger]
Twilio No No Yes [TwilioSms]

Aplicações de funções que usam runtime 1.x referenciam automaticamente o pacote Microsoft.Azure. WebJobs NuGet (versão 2.x).

Os gatilhos e bindings Armazenamento de Blobs, Queue Storage e Table Storage utilizam a versão 7.2.1 do pacote NuGet do WindowsAzure.Storage. Se referenciares uma versão diferente do SDK de Armazenamento e associares a um tipo de SDK de Armazenamento na tua assinatura de função, o runtime das Funções pode reportar que não consegue associar-se a esse tipo. Certifique-se de que o seu projeto faz referência ao WindowsAzure.Storage 7.2.1.

Armazenamento de Blobs bindings em runtime 1.x

Tipos expostos em tempo de execução 1.x do extinto espaço de nomes Microsoft. WindowsAzure.Storage. Tipos mais recentes do Azure. Storage.Blobs requerem uma extensão posterior e um tempo de execução 4.x.

Vinculações de armazenamento em fila em tempo de execução 1.x

Tipos expostos em tempo de execução 1.x do extinto espaço de nomes Microsoft. WindowsAzure.Storage. Tipos mais recentes do Azure. Storage.Queues requerem uma extensão posterior e um tempo de execução 4.x.

Para as definições de vinculação de armazenamento em fila, consulte a secção de filas da referência de runtime 1.x host.json. Em tempo de execução 1.x, a maxPollingInterval definição é expressa em milissegundos. Em versões de execução posteriores, o seu tipo de dado é TimeSpan.

Vinculações de Armazenamento de Tabela em tempo de execução 1.x

O tempo de execução 1.x expus tipos do obsoleto Microsoft. WindowsAzure.Storage.Table. Tipos mais recentes do Azure. O Data.Tables requer a extensão e runtime 4.x do Azure Tables.

Exemplos de entrada

A função C# seguinte lê uma única linha de tabela. Para cada mensagem enviada para a fila, a função é acionada. O valor {queueTrigger} da chave de linha vincula a chave de linha aos metadados da mensagem, que é a cadeia de caracteres da mensagem.

public class TableStorage
{
	public class MyPoco
	{
		public string PartitionKey { get; set; }
		public string RowKey { get; set; }
		public string Text { get; set; }
	}

	[FunctionName("TableInput")]
	public static void TableInput(
		[QueueTrigger("table-items")] string input,
		[Table("MyTable", "MyPartition", "{queueTrigger}")] MyPoco poco,
		ILogger log)
	{
		log.LogInformation($"PK={poco.PartitionKey}, RK={poco.RowKey}, Text={poco.Text}");
	}
}

A função C# seguinte lê várias linhas de tabela onde a MyPoco classe deriva de TableEntity.

public class TableStorage
{
	public class MyPoco : TableEntity
	{
		public string Text { get; set; }
	}

	[FunctionName("TableInput")]
	public static void TableInput(
		[QueueTrigger("table-items")] string input,
		[Table("MyTable", "MyPartition")] IQueryable<MyPoco> pocos,
		ILogger log)
	{
		foreach (MyPoco poco in pocos)
		{
			log.LogInformation($"PK={poco.PartitionKey}, RK={poco.RowKey}, Text={poco.Text}");
		}
	}
}

Utilização da entrada

Para retornar uma entidade específica por chave, use um parâmetro de vinculação que deriva de TableEntity. Os específicos TableName, PartitionKey, e RowKey são usados para tentar obter uma entidade específica da tabela.

Para executar consultas que retornam várias entidades, vincule-se a um IQueryable<T> de um tipo que herda de TableEntity.

Utilização da saída

Os seguintes tipos são suportados para out parâmetros e tipos de retorno:

  • Um objeto CLR simples (POCO) que inclui as PartitionKey propriedades e RowKey . Você pode acompanhar essas propriedades implementando ITableEntity ou herdando TableEntity.
  • ICollector<T> ou IAsyncCollector<T> onde T inclui o PartitionKey e RowKey propriedades. Você pode acompanhar essas propriedades implementando ITableEntity ou herdando TableEntity.

Você também pode vincular a CloudTablepartir do SDK de armazenamento como um parâmetro de método. Em seguida, você pode usar esse objeto para gravar na tabela.

Ligações Event Hubs em runtime 1.x

O Runtime 1.x incluía a ligação aos Event Hubs e não exigia uma extensão separada. Expôs o tipo obsoleto Microsoft.Azure. EventHubs.EventData. Os disparadores dos Event Hubs suportam EventData, tipos serializáveis em JSON, string, e byte[] para um único evento, e EventData[] e string[] para um lote. Associações de saída suportadas EventData, tipos serializáveis em JSON, string, e byte[].

Para um disparo ou ligação de saída no Event Hubs emfunction.json, o runtime 1.x usa a path propriedade para o nome do event hub. Versões posteriores em tempo de execução usam eventHubName. Quando o nome do hub de eventos também está presente na cadeia de ligação, esse valor sobrepõe-se à propriedade em tempo de execução.

O ficheiro de host.json 1.x em tempo de execução utiliza um objeto de topo eventHub :

{
	"eventHub": {
		"maxBatchSize": 64,
		"prefetchCount": 256,
		"batchCheckpointFrequency": 1
	}
}
Property Default Description
maxBatchSize 64 A contagem máxima de eventos recebidos por loop de recebimento.
prefetchCount 300 A contagem de pré-busca padrão usada pelo .EventProcessorHost
batchCheckpointFrequency 1 O número de lotes de eventos a serem processados antes de criar um ponto de verificação do cursor dos Hubs de Eventos.

Para a referência completa de configuração, consulte a eventHub secção da referência de host.json 1.x em tempo de execução.

Ligações da grelha de eventos em tempo de execução 1.x

As versões da extensão Event Grid anteriores à 3.x não suportam o esquema CloudEvents. Para consumir este esquema, use um gatilho HTTP ou migre para o runtime 4.x e a extensão Event Grid 3.x.

A ligação de saída da Grelha de Eventos está disponível apenas para tempo de execução 2.x e posteriores.

Tipos de vinculação

A extensão de runtime 1.x suporta os seguintes tipos de parâmetros. Não suporta o esquema CloudEvents, que requer a extensão Event Grid 3.x.

Binding Tipos de parâmetros
Acionador do Event Grid Newtonsoft.Json.Linq.JObject
string

Ativação do uso

As funções da biblioteca de classes C# em processo suportam os seguintes tipos de gatilhos da Grelha de Eventos:

  • Newtonsoft.Json.Linq.JObject
  • System.String

Endpoint Webhook e chave do sistema

O endpoint do webhook hospedado para um gatilho de Grade de Eventos 1.x em tempo de execução utiliza o seguinte padrão de URL:

https://{functionappname}.azurewebsites.net/admin/extensions/EventGridExtensionConfig?functionName={functionname}&code={systemkey}

Para obter a chave do sistema Event Grid da API de administrador, use a chave mestra da function app no seguinte pedido:

https://{functionappname}.azurewebsites.net/admin/host/systemkeys/eventgridextensionconfig_extension?code={masterkey}

Para testes locais, o endpoint do gatilho da Grelha de Eventos utiliza o seguinte padrão de URL:

http://localhost:7071/admin/extensions/EventGridExtensionConfig?functionName={FUNCTION_NAME}

Ligações do Service Bus em tempo de execução 1.x

Runtime 1.x exposto tipos do espaço de nomes obsoleto da Microsoft. ServiceBus.Messenger. Tipos mais recentes do Azure. Mensaging.ServiceBus requer a extensão Service Bus 5.x ou posterior e runtime 4.x.

A 30 de setembro de 2026, as bibliotecas do SDK do Azure Service Bus WindowsAzure.ServiceBus, Microsoft.Azure. ServiceBus, e com.microsoft.Azure. ServiceBus serão retiradas. Estas bibliotecas não cumprem as diretrizes do SDK do Azure. O suporte ao Service Bus Messaging Protocol (SBMP) também terminará. Embora possa continuar a usar as bibliotecas mais antigas após a reforma, elas deixarão de receber suporte oficial nem atualizações da Microsoft. Para obter mais informações, consulte o anúncio de encerramento do suporte.

Ativação do uso

O disparador da mensagem de fila ou tópico suporta os seguintes tipos de parâmetros:

Nas bibliotecas de classes C#, o construtor do atributo assume o nome da fila ou o tópico e a subscrição. Também pode especificar os direitos de acesso da ligação. Se você não especificar direitos de acesso, o padrão será Manage.

Seleção de conta Service Bus

Use o ServiceBusAccountAttribute para especificar a conta do Service Bus. O construtor assume o nome de uma definição de aplicação que contém uma Service Bus cadeia de ligação. Aplica o atributo ao nível do parâmetro, método ou classe. O exemplo seguinte mostra atributos ao nível da classe e ao nível do método:

[ServiceBusAccount("ClassLevelServiceBusAppSetting")]
public static class AzureFunctions
{
	[ServiceBusAccount("MethodLevelServiceBusAppSetting")]
	[FunctionName("ServiceBusQueueTriggerCSharp")]
	public static void Run(
		[ServiceBusTrigger("myqueue", AccessRights.Manage)]
		string myQueueItem, ILogger log)
	{
		// ...
	}
}

A ordem seguinte determina qual conta do Service Bus utilizar:

  1. A ServiceBusTrigger propriedade do Connection atributo.
  2. O ServiceBusAccount atributo aplicado ao mesmo parâmetro que o ServiceBusTrigger atributo.
  3. O ServiceBusAccount atributo aplicado à função.
  4. O ServiceBusAccount atributo aplicado à classe.
  5. A AzureWebJobsServiceBus configuração do aplicativo.

Metadados da mensagem

As seguintes propriedades são membros das classes BrokeredMessage e MessageReceiver .

Property Tipo Description
ContentType string Um identificador de tipo de conteúdo usado pelo remetente e recetor para lógica específica da aplicação.
CorrelationId string O ID de correlação.
DeadLetterSource string A fonte sem saída.
DeliveryCount Int32 O número de entregas.
EnqueuedTimeUtc DateTime O tempo enfileirado em Tempo Universal Coordenado (UTC).
ExpiresAtUtc DateTime O tempo de expiração em UTC.
Label string O rótulo específico do aplicativo.
MessageId string Um valor definido pelo utilizador que o Service Bus pode usar para identificar mensagens duplicadas, se estiver ativado.
MessageReceiver MessageReceiver Receptor de mensagens do Service Bus. Pode ser usado para abandonar, completar ou fechar a mensagem.
MessageSession MessageSession Um recetor de mensagem especificamente para filas e tópicos habilitados para sessão.
ReplyTo string O endereço da fila de resposta.
SequenceNumber long O número exclusivo atribuído a uma mensagem pelo Service Bus.
To string O endereço de envio.
UserProperties IDictionary<string, object> Propriedades definidas pelo remetente.

Utilização da saída

Use o tipo BrokeredMessage ao enviar mensagens com metadados. Defina parâmetros como return atributos de tipo. Se o valor do parâmetro for nulo quando a função sai, Funções não cria uma mensagem.

Para function.json vincula, accessRights aceita manage ou listen e por defeito para manage. Se a cadeia de ligação não tiver permissão de gerir, defina accessRights para listen impedir que o runtime tente operações de gestão.

O tempo de execução cria a fila se esta não existir e definires accessRights para manage.

Configurações do host

Para Service Bus definições de binding, veja a referência de runtime 1.x host.json.

Ligações HTTP e webhook em tempo de execução 1.x

Uma função ativada por HTTP retorna HTTP 200 OK com o corpo vazio por defeito. Versões posteriores em tempo de execução retornam HTTP 204 No Content.

Para um gatilho HTTP em function.json, use a webHookType propriedade para configurar o gatilho para funcionar como um receptor webhook para o fornecedor especificado. Esta propriedade é específica do runtime 1.x.

O Runtime 1.x não suporta acesso à informação autenticada do cliente.

Modo Webhook

Os modelos de webhook fornecem validação extra para cargas úteis de webhook. A webHookType propriedade de binding mostra o fornecedor do webhook e controla a carga útil suportada:

Valor do tipo Description
genericJson Um ponto de extremidade webhook de uso geral sem lógica para um provedor específico. Esta configuração restringe os pedidos a HTTP POST com o tipo de application/json conteúdo.
github A função responde aos webhooks do GitHub. Não use a authLevel propriedade com webhooks do GitHub.
slack A função responde aos webhooks do Slack. Não use a authLevel propriedade com webhooks do Slack.

Quando definires webHookType, não definas a methods propriedade.

Para responder aos webhooks do GitHub, crie a função com um trigger HTTP, defina webHookType para github, e copie o seu URL e a chave API para a página Adicionar webhook do repositório GitHub.

O webhook do Slack gera um token, por isso configura uma chave específica de função com esse token.

O componente receptor do webhook trata da autorização do webhook. O mecanismo varia consoante o tipo de webhook, mas cada mecanismo depende de uma chave. Por defeito, é usada a tecla de função nomeada default . Para usar outra chave, configure o fornecedor do webhook para enviar o nome da chave de uma das seguintes formas:

  • No clientid parâmetro da cadeia de consulta, como https://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>?clientid=<KEY_NAME>.
  • No x-functions-clientid cabeçalho do pedido.

Para definições de ligação HTTP, veja a secção HTTP da referência de host.json runtime 1.x.

Gatilho de aquecimento no runtime 1.x

O runtime 1.x não suporta o gatilho de aquecimento.

SendGrid binding em runtime 1.x

Adicione a extensão ao seu projeto instalando o pacote NuGet, versão 2.x.

Para as definições de ligação SendGrid, veja a secção SendGrid da referência de runtime 1.x host.json.

Ligação Twilio em runtime 1.x

Adicione a extensão ao seu projeto instalando o pacote NuGet, versão 1.x.

Para o runtime 1.x, use as seguintes propriedades de configuração de binding no ficheirofunction.json :

propriedade function.json Description
type Definido como twilioSms.
direção Definido como out.
name Nome da variável usada no código de função para a mensagem de texto SMS Twilio.
accountSid Defina para o nome de uma definição de aplicação que guarda o Sid da sua Conta Twilio (TwilioAccountSid). Quando não está definido, o nome da configuração padrão do aplicativo é AzureWebJobsTwilioAccountSid.
authToken Defina para o nome de uma definição de aplicação que guarda o seu token de autenticação Twilio (TwilioAccountAuthToken). Quando não está definido, o nome da configuração padrão do aplicativo é AzureWebJobsTwilioAuthToken.
to Define para o número de telefone para onde a mensagem SMS é enviada.
from Define para o número de telefone de onde a mensagem SMS é enviada.
body Usa para codificar diretamente a mensagem SMS se não precisares de a definir dinamicamente no código para a tua função.

Use apenas a informação de ligação preservada neste artigo para compreender uma aplicação existente. Siga o guia de migração em tempo de execução e a documentação de ligação atual quando atualizar a aplicação.

Perguntas frequentes

O runtime do Funções do Azure 1.x ainda é suportado?

N.º O suporte para o runtime do Funções do Azure 1.x terminou a 14 de setembro de 2026. Migra as aplicações afetadas para runtime 4.x para suporte total.

Um modelo de programação Python v1 ou Node.js v4 usa runtime 1.x?

N.º As versões dos modelos de programação de linguagem são independentes da versão em tempo de execução. Os modelos de programação Python v1 e v2 e os modelos de programação Node.js v3 e v4 correm em tempo de execução 4.x.

  • Last updated on