Azure Functions runtime 1.x legacy reference

Ten artykuł zachowuje kluczowe informacje historyczne oraz linki do szczegółowych odniesień dotyczących aplikacji funkcyjnych, które nadal korzystają z runtime 1.x. Nie używaj runtime 1.x do nowych aplikacji funkcyjnych.

Zakres uruchomienia 1.x

Azure Functions runtime 1.x zakończył wsparcie 14 września 2026 roku i nie jest wspierany dla nowych ani istniejących aplikacji Function. Runtime 1.x miał następujące cechy:

• Działał tylko na Windows.
• Wspierał aplikacje C# skierowane do .NET Framework i aplikacji JavaScript.
• Aplikacje C# działały w trakcie pracy. Runtime 1.x nie obsługiwał modelu izolowanego pracownika.
• Do lokalnego rozwoju używał wersji 1.x Azure Functions Core Tools. Core Tools 1.x działa tylko na Windows.
• Runtime zawierał obsługiwane przypisania. Późniejsze wersje wykonawcze używają osobno wersjonowanych rozszerzeń wiązań lub pakietów rozszerzeniowych.

Wersje modeli w czasie rzeczywistym, rozszerzeniach i programowaniu

Wersja Azure Functions działająca nie jest taka sama jak wersje używane przez bindingi rozszerzeń, pakiety rozszerzenia czy modele programowania językowego. Etykieta wersji na innym komponencie nie oznacza, że aplikacja korzysta z Azure Functions runtime 1.x. Przykład:

• Modele programowania Python v1 i v2 działają na runtime 4.x.
• Modele programistyczne Node.js v3 i v4 działają na runtime 4.x.
• Pakiety rozszerzenia i pakiety wiążące pakiety rozszerzenia są niezależne od wersji wykonawczej.

Migracja do runtime 4.x

Aby przywrócić aplikację do pełnego wsparcia, przenieś ją z runtime 1.x na runtime 4.x. Przewodnik migracyjny obejmuje następujące zadania:

• Zidentyfikuj aplikacje celujące w runtime 1.x.
• Wybierz wspierany cel dla C# lub JavaScript.
• Zaktualizuj projekt, przypisania, ustawienia aplikacji i host.json plik.
• Przetestuj aplikację lokalnie i zaktualizuj aplikację function w Azure.

Nie zmieniaj tylko FUNCTIONS_EXTENSION_VERSION ustawień aplikacji. Aktualizacje w czasie uruchomienia mogą wymagać zmian w projekcie, kodzie, bindingu i konfiguracji.

Ustawienia aplikacji specyficzne dla runtime 1.x

To AzureWebJobsDashboard przestarzałe ustawienie jest obsługiwane tylko przez runtime 1.x. Zawiera opcjonalny ogólny string konta pamięci masowej, używany do przechowywania logów i wyświetlania ich w zakładce Monitor w portalu Azure.

Runtime 1.x nie obsługuje AZURE_FUNCTIONS_ENVIRONMENT ustawień aplikacji.

Wartość ~1 przypina FUNCTIONS_EXTENSION_VERSION aplikację funkcyjną do runtime 1.x. Domyślne jest przechowywanie kluczy w systemie plików (AzureWebJobsSecretStorageType=files).

Własność functionsRuntimeAdminIsolationEnabled strony nie jest dostępna w runtime 1.x. FUNCTIONS_V2_COMPATIBILITY_MODE To ustawienie nie dotyczy aplikacji w runtime 1.x.

Projekt i różnice językowe

Projekty bibliotek klas C# w czasie uruchomieniowym 1.x były skierowane na framework .NET i korzystały z wersji 1.x pakietuMicrosoft.NET.Sdk.Functions. Mogliby się przydać TraceWriter do wycinki. Aktualny model projektu C# i rozważania dotyczące migracji można znaleźć w przewodniku dla deweloperów biblioteki klasy .NET oraz przewodniku po migracji w czasie rzeczywistym 1.x.

Projekty biblioteczne klasy C#

Poniższy przykład pokazuje odpowiednie części pliku projektu runtime 1.x:

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

Zależności Microsoft.NET.Sdk.Functions pakietów obejmują wyzwalacze i powiązania. Projekt 1.x odnosi się do wyzwalaczy i wiązań 1.x, ponieważ celują one w framework .NET. Pakiet zależy również od Newtonsoft.Json i pośrednio od WindowsAzure.Storage. Te zależności zapewniają, że projekt korzysta z wersji zgodnych z docelowym środowiskiem wykonawczym Functions. Na przykład środowisko wykonawcze Functions skierowane do .NET Framework 4.6.1 jest kompatybilne z Newtonsoft.Json 9.0.1, a nie z wersją 11.

Runtime 1.x używany TraceWriter do logowania Application Insights. TraceWriter Nie obsługuje strukturalnego logowania.

Poniższy przykład tworzy a TelemetryClient i używa TrackEvent, TrackMetric, oraz do TrackDependency zapisu niestandardowej telemetrii. Wykorzystuje także kontekst wykonania funkcji do powiązania niestandardowej telemetrii z aktualnym wywołaniem.

Przykład niestandardowej telemetrii

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;
		}
	}
}

Runtime 1.x obsługiwał także skrypty C# (.csx) oraz funkcje JavaScript. Skrypt C# nie jest specyficzny dla runtime 1.x, więc skorzystaj z referencji programisty skryptów C# jako ogólnych wskazówek dotyczących skryptów. Korzystaj z przewodnika migracji do zmian specyficznych dla czasu uruchomienia.

Przykłady wcześniejszej składni C# można znaleźć w szablonach funkcji 1.x w czasie rzeczywistym.

Asemblery i pakiety skryptów C#

W skryptach skryptowych 1.x w czasie rzeczywistym C# można było odwoływać się do następujących asembli pod prostą nazwą:

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

Runtime 1.x używał pliku project.json do definiowania zależności (Runtime). Poniższy przykład dodaje Microsoft.ProjectOxford.Face pakiet NuGet:

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

Pakiety rozszerzeniowe nie są obsługiwane przez runtime 1.x. Aby użyć niestandardowego kanału NuGet, określ go w pliku NuGet.Config w folderze root aplikacji function. Aby uzyskać więcej informacji, zobacz Konfigurowanie zachowania narzędzia NuGet.

Rozwój lokalny z Core Tools 1.x

Wersja 1.x Azure Functions Core Tools jest sparowana z runtime 1.x i działa tylko na Windows. Na początek czasu pracy uruchomiłeś func host start. Aktualne lokalne wskazówki dotyczące rozwoju można znaleźć w artykule Develop Azure Functions locally using Core Tools.

Visual Studio przechowywało wersje %USERPROFILE%\AppData\Local\Azure.Functions.Cli Core Tools 1.x w czasie rzeczywistym i korzystało z najnowszej wersji tam przechowywanej. Wybraną wersję można było zobaczyć w wyjściu konsoli podczas uruchamiania projektu:

[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 odniesienia

Schemat i ustawieniahost.json zmieniły się po uruchomieniu 1.x. Sprawdź host.json referencję w runtime 1.x podczas przeglądu istniejącej konfiguracji i porównaj ją z aktualną host.json referencją podczas migracji.

Monitoruj aplikacje w runtime 1.x za pomocą Application Insights

Runtime 1.x wykorzystuje następujące kategorie dzienników Application Insights:

Konfigurowanie poziomów dziennika

Runtime 1.x konfiguruje poziomy logów w host.jsonlogger.categoryFilter :

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

Gdy wiele nazw kategorii zaczyna się od tego samego ciągu, najpierw dopasowuje się bardziej konkretną kategorię. Poniższy przykład rejestruje wszystko oprócz Host.Aggregator poziomu Error :

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

Skonfiguruj próbkowanie

Domyślna maksymalna prędkość telemetrii to pięć przedmiotów na sekundę. Runtime 1.x konfiguruje próbkowanie według :applicationInsights.sampling

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

Poniższy przykład łączy filtrowanie kategorii i próbkowanie:

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

Runtime 1.x nie obsługuje konfiguracji dla każdej funkcji.

Możliwości Application Insights

Runtime 1.x automatycznie zbierał żądania, wyjątki i liczniki wydajności. Nie zbierał automatycznie zależności HTTP, Service Bus, Event Hubs ani SQL. Wspierał QuickPulse/Live Metrics bez bezpiecznego kanału sterowania i obsługiwał próbkowanie, ale nie obsługiwał korelacji z uderzeniami serca, korelacji Service Bus czy Event Hubs ani w pełni konfigurowalnego zbierania telemetrii.

Nieobsługiwane funkcje i zachowanie w czasie rzeczywistym 1.x

• Polityki powtórek nie są wspierane.
• Dynamiczne monitorowanie wyzwalaczy sieci wirtualnej nie jest obsługiwane.
• W planach Premium i dedykowanych domyślny limit czasu wykonania funkcji jest nieograniczony. W planie Consumption domyślny czas na przerwę to pięć minut, a maksymalnie 10 minut.
• Aplikacja funkcjonalna korzystająca z pakietu zdalnego wdrożenia nie może działać bez udostępnienia Azure Files.

Przypisania zawarte w runtime 1.x

Azure Functions runtime 1.x jest wycofany. Podczas migracji do runtime 4.x użyj aktualnych rozszerzeń wiązań lub pakietu rozszerzeniowego i przejrzyj każde powiązanie pod kątem zmian konfiguracji i typu.

Następujące przypisania zostały dołączone do runtime 1.x. Kolumna atrybutów C# pokazuje krótkie nazwy używane w kodzie. Odpowiadające im nazwy klas mają Attribute sufiks, na przykład .BlobTriggerAttribute Funkcje skryptowe C# zamiast tego definiują przypisania w pliku function.json .

Aplikacje funkcjonalne korzystające z runtime 1.x automatycznie odwołują się do pakietu Microsoft.Azure. WebJobs NuGet (wersja 2.x).

Wyzwalacze i powiązania Blob Storage, Queue Storage oraz Table Storage wykorzystują wersję 7.2.1 pakietu WindowsAzure.Storage NuGet. Jeśli odniesiesz się do innej wersji SDK pamięci i powiesz ją do typu SDK pamięci w sygnaturze funkcji, środowisko uruchomienia Functions może zgłosić, że nie może się powiązać z tym typem. Upewnij się, że Twój projekt odnosi się do WindowsAzure.Storage 7.2.1.

Powiązania Blob Storage w runtime 1.x

Runtime 1.x ujawnił typy z przestarzałego Microsoft. WindowsAzure.Storage przestrzeń nazw. Nowsze typy z Azure. Storage.Blobs wymagają późniejszego rozszerzenia i runtime 4.x.

Powiązania Queue Storage w czasie rzeczywistym 1.x

Runtime 1.x ujawnił typy z przestarzałego Microsoft. WindowsAzure.Storage przestrzeń nazw. Nowsze typy z Azure. Storage. Kolejki wymagają późniejszego rozszerzenia i uruchomienia 4.x.

Aby poznać ustawienia wiązania Queue Storage, zobacz sekcję kolejek w runtime 1.x host.json referencji. W runtime 1.x maxPollingInterval ustawienie wyraża się w milisekundach. W późniejszych wersjach uruchomieniowych jego typ danych to TimeSpan.

Powiązania Table Storage w czasie rzeczywistym 1.x

Runtime 1.x ujawnił typy z przestarzałego Microsoft. Przestrzeń nazw WindowsAzure.Storage.Table. Nowsze typy z Azure. Data.Tables wymagają rozszerzenia Azure Tables i uruchomienia 4.x.

Przykłady danych wejściowych

Następująca funkcja C# odczytuje pojedynczy wiersz tabeli. Dla każdej wiadomości wysyłanej do kolejki funkcja jest wyzwalana. Wartość {queueTrigger} klucza wiersza wiąże klucz wiersza z metadanymi komunikatu, czyli ciągiem komunikatu.

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}");
	}
}

Następująca funkcja C# odczytuje wiele wierszy tabeli, z których klasa MyPoco pochodzi z .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}");
		}
	}
}

Wykorzystanie wejścia

Aby zwrócić określoną jednostkę według klucza, użyj parametru powiązania pochodzącego z tabeli TableEntity. Specyficzne TableName, PartitionKey, i RowKey są używane do próby uzyskania konkretnej jednostki z tabeli.

Aby wykonać zapytania zwracające wiele jednostek, powiąż z typem IQueryable<T> , który dziedziczy z tabeli TableEntity.

Wykorzystanie wydruku

Następujące typy są obsługiwane w przypadku out parametrów i typów zwracanych:

• Zwykły obiekt CLR (POCO), który zawiera PartitionKey właściwości i RowKey . Te właściwości można towarzyszyć przez zaimplementowanie ITableEntity lub dziedziczenie TableEntity.
• ICollector<T> lub IAsyncCollector<T> gdzie T zawiera PartitionKey właściwości i RowKey . Te właściwości można towarzyszyć przez zaimplementowanie ITableEntity lub dziedziczenie TableEntity.

Można również powiązać z CloudTablezestawem SDK usługi Storage jako parametrem metody. Następnie możesz użyć tego obiektu do zapisania w tabeli.

Powiązania Event Hubs w czasie rzeczywistym 1.x

Runtime 1.x zawierał powiązanie Event Hubs i nie wymagał osobnego rozszerzenia. Ujawnił przestarzały typ Microsoft.Azure. EventHubs.EventData. Obsługiwane EventDatasą wyzwalacze Event Hubs , typy serializowane JSON- string, , oraz byte[] dla pojedynczego zdarzenia, oraz EventData[] i string[] dla partii. Wiązania wyjściowe obsługiwane EventData, typy serializowalne przez JSON, string, oraz byte[].

Dla wyzwalacza lub wiązania wyjścia Event Hubs w function.json, runtime 1.x używa path tej właściwości nazwy centrum zdarzeń. Późniejsze wersje wykonawcze używają eventHubName. Gdy nazwa centrum zdarzeń jest również obecna w parametry połączenia, ta wartość nadpisuje tę właściwość w czasie wykonywania.

Plik host.json w czasie rzeczywistym 1.x wykorzystuje obiekt najwyższego poziomu eventHub :

{
	"eventHub": {
		"maxBatchSize": 64,
		"prefetchCount": 256,
		"batchCheckpointFrequency": 1
	}
}

Pełną referencję konfiguracyjną można eventHub znaleźć w sekcji host.json czasie wykonywania 1.x.

Powiązania Event Grid w czasie wykonywania 1.x

Wersje rozszerzenia Event Grid starsze niż 3.x nie obsługują schematu CloudEvents. Aby wykorzystać ten schemat, użyj wyzwalacza HTTP lub przenieś się do czasów uruchomieniowych 4.x i rozszerzenia Event Grid 3.x.

Wiązanie wyjściowe Event Grid jest dostępne tylko dla czasów uruchomieniowych 2.x i nowszych.

Typy powiązań

Rozszerzenie 1.x w czasie rzeczywistym obsługuje następujące typy parametrów. Nie obsługuje schematu CloudEvents, który wymaga rozszerzenia Event Grid 3.x.

Użycie wyzwalacza

Funkcje biblioteki klas C# w trakcie procesu obsługują następujące typy wyzwalaczy Event Grid:

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

Punkt końcowy Webhook i klucz systemowy

Hostowany endpoint webhook dla wyzwalacza Event Grid 1.x w czasie rzeczywistym korzysta z następującego wzoru URL:

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

Aby uzyskać klucz systemowy Event Grid z API administratora, użyj klucza głównego aplikacji function w następującym żądaniu:

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

Do testów lokalnych endpoint wyzwalacza Event Grid używa następującego wzorca URL:

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

Powiązania Service Bus w czasie wykonywania 1.x

Runtime 1.x ujawnił typy z przestarzałego Microsoft. ServiceBus.Messaging przestrzeń nazw. Nowsze typy z Azure. Messaging.ServiceBus wymaga rozszerzenia Service Bus 5.x lub nowszego oraz runtime 4.x.

30 września 2026 roku biblioteki SDK Azure Service Bus będą zawierać WindowsAzure.ServiceBus, Microsoft.Azure. ServiceBus oraz com.microsoft.azure. Servicebus zostanie wycofany. Te biblioteki nie spełniają wytycznych Azure SDK. Wsparcie dla Service Bus Messaging Protocol (SBMP) również się zakończy. Chociaż po przejściu na emeryturę można nadal korzystać ze starszych bibliotek, nie będą one już otrzymywać oficjalnego wsparcia i aktualizacji od Microsoft. Aby uzyskać więcej informacji, zobacz ogłoszenie o wycofaniu pomocy technicznej.

Użycie wyzwalacza

Wyzwalacz wiadomości kolejka lub tematu obsługuje następujące typy parametrów:

• BrokeredMessage dostarcza zdeserializowaną wiadomość metodą BrokeredMessage.GetBody<T>().
• MessageReceiver odbiera i potwierdza wiadomości z kontenera wiadomości. Ten typ jest wymagany, gdy autoComplete jest ustawiony na .false

W bibliotekach klas C# konstruktor atrybutu przyjmuje nazwę kolejki lub tematu oraz subskrypcję. Możesz też określić prawa dostępu do połączenia. Jeśli nie określisz praw dostępu, wartość domyślna to Manage.

Wybór konta Service Bus

Użyj atrybutu ServiceBusAccountAttribute do określenia konta Service Bus. Konstruktor przyjmuje nazwę ustawienia aplikacji, które zawiera Service Bus parametry połączenia. Zastosuj atrybut na poziomie parametrów, metody lub klasy. Poniższy przykład pokazuje atrybuty na poziomie klasy i metody:

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

Poniższa kolejność określa, którego konta Service Bus użyć:

1. ServiceBusTrigger Właściwość atrybutuConnection.
2. Atrybut ServiceBusAccount zastosowany do tego samego parametru ServiceBusTrigger co atrybut.
3. Atrybut ServiceBusAccount zastosowany do funkcji.
4. Atrybut ServiceBusAccount zastosowany do klasy.
5. Ustawienie AzureWebJobsServiceBus aplikacji.

Metadane komunikatu

Poniższe właściwości należą do klas BrokeredMessage i MessageReceiver .

Wykorzystanie wydruku

Użyj typu BrokeredMessage podczas wysyłania komunikatów z metadanymi. Zdefiniuj parametry jako atrybuty return typu. Jeśli wartość parametru jest null, gdy funkcja kończy działalność, Funkcje nie tworzą komunikatu.

Dla function.json wiązań akceptuje accessRightsmanage lub listen i domyślnie przyjmuje .manage Jeśli parametry połączenia nie ma uprawnień Zarządzaj, ustaw accessRights tak, listen aby uniemożliwić uruchomieniu przez środowisko uruchomieniowe próby operacji zarządzania.

Runtime tworzy kolejkę, jeśli nie istnieje i ustawiasz accessRights na manage.

Ustawienia hosta

Ustawienia Service Bus bindingu znajdziesz w runtime 1.x host.json referencji.

Wiązania HTTP i webhook w czasie uruchomienia 1.x

Funkcja wyzwalana przez HTTP domyślnie zwraca HTTP 200 OK z pustym ciałem. Późniejsze wersje wykonawcze powracają HTTP 204 No Content.

Dla wyzwalacza HTTP w function.json, użyj webHookType tej właściwości, aby skonfigurować wyzwalacz jako odbiornik webhooka dla określonego dostawcy. Ta własność jest specyficzna dla runtime 1.x.

Runtime 1.x nie obsługuje dostępu do uwierzytelnionych informacji klienta.

Tryb Webhook

Szablony Webhooków zapewniają dodatkową weryfikację dla ładunków webhook. Właściwość wiązania webHookType pokazuje dostawcę webhooka i kontroluje obsługiwany ładunek danych:

Gdy ustawiasz webHookType, nie ustawiaj methods właściwości.

Aby odpowiedzieć na webhooki GitHub, stwórz funkcję z wyzwalaczem HTTP, ustaw webHookType na github, i skopiuj jej adres URL oraz klucz API na stronę Dodaj webhook w repozytorium GitHub.

Webhook Slack generuje token, więc konfiguruj z tym tokenem klucz specyficzny dla funkcji.

Komponent odbiornika webhooka obsługuje autoryzację webhooków. Mechanizm różni się w zależności od typu webhooka, ale każdy mechanizm opiera się na kluczu. Domyślnie używany jest klawisz funkcyjny o nazwie default . Aby użyć innego klucza, skonfiguruj dostawcę webhooka tak, aby wysyłał nazwę klucza w jeden z następujących sposobów:

• W parametrze clientid zapytania, takim jak https://<APP_NAME>.azurewebsites.net/api/<FUNCTION_NAME>?clientid=<KEY_NAME>.
• W nagłówku x-functions-clientid żądania.

Aby poznać ustawienia wiązania HTTP, zobacz sekcję HTTP w środowisku uruchomieniowym 1.x host.json referencji.

Wyzwalacz rozgrzewki w czasie uruchomienia 1.x

Runtime 1.x nie obsługuje wyzwalacza rozgrzewki.

Powiązanie SendGrid w czasie uruchomieniowym 1.x

Dodaj rozszerzenie do projektu, instalując pakiet NuGet w wersji 2.x.

Aby poznać ustawienia wiązania SendGrid, zobacz sekcję SendGrid w środowisku uruchomieniowym 1.x host.json źródła.

Binding Twilio w runtime 1.x

Dodaj rozszerzenie do projektu, instalując pakiet NuGet w wersji 1.x.

Dla runtime 1.x użyj następujących właściwości konfiguracji wiązania w pliku function.json :

Korzystaj z zachowanych informacji o wiążeniu z tego artykułu tylko do zrozumienia istniejącej aplikacji. Stosuj się do przewodnika migracji w czasie rzeczywistym oraz aktualnej dokumentacji wiązającej przy aktualizacji aplikacji.

Często zadawane pytania

Czy Azure Functions w runtime 1.x jest nadal obsługiwany?

Nie. Wsparcie dla Azure Functions runtime 1.x zakończyło się 14 września 2026 roku. Migruj dotknięte aplikacje do runtime 4.x, aby zapewnić pełne wsparcie.

Czy model programistyczny Python v1 lub Node.js v4 korzysta z runtime 1.x?

Nie. Wersje modeli programowania językowego są niezależne od wersji wykonawczej. Modele programistyczne Python v1 i v2 oraz modele Node.js v3 i v4 działają na runtime 4.x.

Powiązane zasoby

• Compare runtime versions Azure Functions
• Azure Functions runtime 1.x support announcement
• Migrate apps from Azure Functions runtime 1.x to 4.x