Azure Functions C# developer reference (Azure Functions C# 開発者向けリファレンス)Azure Functions C# developer reference

この記事では、.NET クラス ライブラリの C# を使用した Azure Functions 開発の概要を示します。This article is an introduction to developing Azure Functions by using C# in .NET class libraries.

Azure Functions では、C# および C# スクリプト プログラミング言語をサポートします。Azure Functions supports C# and C# script programming languages. Azure Portal での C# の使用に関するガイダンスを探している場合は、C# スクリプト (.csx) 開発者向けリファレンスをご覧ください。If you're looking for guidance on using C# in the Azure portal, see C# script (.csx) developer reference.

この記事では、既に次の記事に目を通していることを前提とします。This article assumes that you've already read the following articles:

関数クラス ライブラリ プロジェクトFunctions class library project

Visual Studio では、Azure Functions プロジェクト テンプレートは、次のファイルを含む C# クラス ライブラリ プロジェクトを作成します。In Visual Studio, the Azure Functions project template creates a C# class library project that contains the following files:

  • host.json - ローカルまたは Azure 内で実行される場合に、プロジェクト内のすべての関数に影響を及ぼす構成設定を格納します。host.json - stores configuration settings that affect all functions in the project when running locally or in Azure.
  • local.settings.json - ローカルで実行される場合に使用されるアプリ設定および接続文字列を格納します。local.settings.json - stores app settings and connection strings that are used when running locally.

重要

ビルド処理では、関数ごとに function.json ファイルが作成されます。The build process creates a function.json file for each function. この function.json ファイルに対しては、直接編集は行われません。This function.json file is not meant to be edited directly. このファイルを編集して、バインド構成を変更したり、関数を無効にしたりすることはできません。You can't change binding configuration or disable the function by editing this file. 関数を無効にするには、Disable 属性を使用します。To disable a function, use the Disable attribute. たとえば、ブール値アプリ設定 MY_TIMER_DISABLED を追加し、[Disable("MY_TIMER_DISABLED")] を関数に適用します。For example, add a Boolean app setting MY_TIMER_DISABLED, and apply [Disable("MY_TIMER_DISABLED")] to your function. アプリ設定を変更して有効と無効を切り替えることができます。You can then enable and disable it by changing the app setting.

関数として認識されるメソッドMethods recognized as functions

クラス ライブラリでは、次の例に示すように 関数は FunctionName を使用した静的メソッドです。In a class library, a function is a static method with a FunctionName and a trigger attribute, as shown in the following example:

public static class SimpleExample
{
    [FunctionName("QueueTrigger")]
    public static void Run(
        [QueueTrigger("myqueue-items")] string myQueueItem, 
        TraceWriter log)
    {
        log.Info($"C# function processed: {myQueueItem}");
    }
} 

FunctionName 属性は、関数のエントリ ポイントとしてメソッドをマークします。The FunctionName attribute marks the method as a function entry point. 名前はプロジェクト内で一意であり、文字で始まり、英数字、_、および - のみが含まれ、127 文字以下にする必要があります。The name must be unique within a project, start with a letter and only contain letters, numbers, _ and -, up to 127 characters in length. プロジェクト テンプレートでは、多くの場合、Run という名前のメソッドが作成されますが、有効な C# メソッド名であればメソッド名として使用できます。Project templates often create a method named Run, but the method name can be any valid C# method name.

トリガー属性は、トリガーの種類を指定し、メソッド パラメーターに入力データをバインドします。The trigger attribute specifies the trigger type and binds input data to a method parameter. 例の関数は 1 つのクエリ メッセージによってトリガーされ、そのクエリ メッセージは myQueueItem パラメーターでメソッドに渡されます。The example function is triggered by a queue message, and the queue message is passed to the method in the myQueueItem parameter.

メソッド シグネチャのパラメーターMethod signature parameters

メソッド シグネチャには、トリガー属性で使用されているもの以外のパラメーターが含まれる場合があります。The method signature may contain parameters other than the one used with the trigger attribute. 以下に、含めることができる追加のパラメーターの一部を示します。Here are some of the additional parameters that you can include:

関数シグネチャのパラメーターの順序は関係ありません。The order of parameters in the function signature does not matter. たとえば、トリガー パラメーターは、他のバインドの前後に配置できます。また、ロガー パラメーターは、トリガー パラメーターまたはバインド パラメーターの前後に配置できます。For example, you can put trigger parameters before or after other bindings, and you can put the logger parameter before or after trigger or binding parameters.

出力バインドの例Output binding example

次の例では、出力キュー バインドを追加することで、前の属性を変更しています。The following example modifies the preceding one by adding an output queue binding. この関数は、関数をトリガーするキュー メッセージを、異なるキュー内の新しいキュー メッセージに書き込みます。The function writes the queue message that triggers the function to a new queue message in a different queue.

public static class SimpleExampleWithOutput
{
    [FunctionName("CopyQueueMessage")]
    public static void Run(
        [QueueTrigger("myqueue-items-source")] string myQueueItem, 
        [Queue("myqueue-items-destination")] out string myQueueItemCopy,
        TraceWriter log)
    {
        log.Info($"CopyQueueMessage function processed: {myQueueItem}");
        myQueueItemCopy = myQueueItem;
    }
}

バインドの参照についての記事 (たとえば「Storage キュー」) では、トリガー、入力、または出力のバインド属性で、どのパラメーターの種類を使用できるかを説明しています。The binding reference articles (Storage queues, for example) explain which parameter types you can use with trigger, input, or output binding attributes.

バインド式の例Binding expressions example

次のコードでは、アプリ設定から監視するキューの名前を取得し、insertionTime パラメーターで、キュー メッセージの作成時刻を取得しています。The following code gets the name of the queue to monitor from an app setting, and it gets the queue message creation time in the insertionTime parameter.

public static class BindingExpressionsExample
{
    [FunctionName("LogQueueMessage")]
    public static void Run(
        [QueueTrigger("%queueappsetting%")] string myQueueItem,
        DateTimeOffset insertionTime,
        TraceWriter log)
    {
        log.Info($"Message content: {myQueueItem}");
        log.Info($"Created at: {insertionTime}");
    }
}

自動生成される function.jsonAutogenerated function.json

ビルド処理では、ビルド フォルダー内の関数フォルダーに function.jsonファイルを作成します。The build process creates a function.json file in a function folder in the build folder. 前述のとおり、このファイルに対しては直接編集が行われません。As noted earlier, this file is not meant to be edited directly. このファイルを編集して、バインド構成を変更したり、関数を無効にしたりすることはできません。You can't change binding configuration or disable the function by editing this file.

このファイルの目的は、従量課金プランに関する決定事項を評価する際に使用するスケール コントローラーに、情報を提供することです。The purpose of this file is to provide information to the scale controller to use for scaling decisions on the consumption plan. このため、ファイルはトリガー情報だけを含み、入力または出力バインドは含まれません。For this reason, the file only has trigger info, not input or output bindings.

生成された function.json ファイルには、function.json 構成ではなく、バインドの .NET 属性を使用するようにランタイムに指示する configurationSource プロパティが含まれます。The generated function.json file includes a configurationSource property that tells the runtime to use .NET attributes for bindings, rather than function.json configuration. 次に例を示します。Here's an example:

{
  "generatedBy": "Microsoft.NET.Sdk.Functions-1.0.0.0",
  "configurationSource": "attributes",
  "bindings": [
    {
      "type": "queueTrigger",
      "queueName": "%input-queue-name%",
      "name": "myQueueItem"
    }
  ],
  "disabled": false,
  "scriptFile": "..\\bin\\FunctionApp1.dll",
  "entryPoint": "FunctionApp1.QueueTrigger.Run"
}

Microsoft.NET.Sdk.FunctionsMicrosoft.NET.Sdk.Functions

function.json ファイルの生成は、NuGet パッケージ (Microsoft.NET.Sdk.Functions) によって実行されます。The function.json file generation is performed by the NuGet package Microsoft.NET.Sdk.Functions.

Functions ランタイムのバージョン 1.x と 2.x では同じパッケージが使用されます。The same package is used for both version 1.x and 2.x of the Functions runtime. 1.x プロジェクトと 2.x プロジェクトの違いはターゲット フレームワークです。The target framework is what differentiates a 1.x project from a 2.x project. 次に示すのは .csproj ファイルの関連する部分で、ターゲット フレームが異なっていることと、Sdk パッケージが同じであることがわかります。Here are the relevant parts of .csproj files, showing different target frameworks and the same Sdk package:

Functions 1.xFunctions 1.x

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

Functions 2.xFunctions 2.x

<PropertyGroup>
  <TargetFramework>netstandard2.0</TargetFramework>
  <AzureFunctionsVersion>v2</AzureFunctionsVersion>
</PropertyGroup>
<ItemGroup>
  <PackageReference Include="Microsoft.NET.Sdk.Functions" Version="1.0.8" />
</ItemGroup>

Sdk パッケージ間の依存関係はトリガーとバインドです。Among the Sdk package dependencies are triggers and bindings. 1.x のトリガーとバインドの対象は .NET Framework であるため、1.x プロジェクトは 1.x のトリガーとバインドを参照します。一方、2.x のトリガーとバインドの対象は .NET Core です。A 1.x project refers to 1.x triggers and bindings because those target the .NET Framework, while 2.x triggers and bindings target .NET Core.

Sdk パッケージも、Newtonsoft.Json に依存しており、間接的に WindowsAzure.Storage に依存します。The Sdk package also depends on Newtonsoft.Json, and indirectly on WindowsAzure.Storage. これらの依存関係により、ユーザーのプロジェクトでは、必ずそのプロジェクト用の Functions ランタイム バージョンで動作するパッケージ バージョンが使用されます。These dependencies make sure that your project uses the versions of those packages that work with the Functions runtime version that the project targets. たとえば、Newtonsoft.Json のバージョンが .NET Framework 4.6.1 用のバージョン 11 だとします。ところが、.NET Framework 4.6.1 を対象とする Functions ランタイムは Newtonsoft.Json 9.0.1 としか互換性がありません。For example, Newtonsoft.Json has version 11 for .NET Framework 4.6.1, but the Functions runtime that targets .NET Framework 4.6.1 is only compatible with Newtonsoft.Json 9.0.1. この場合は、そのプロジェクトの関数コードも Newtonsoft.Json 9.0.1 を使用する必要があります。So your function code in that project also has to use Newtonsoft.Json 9.0.1.

Microsoft.NET.Sdk.Functions のソース コードは、GitHub リポジトリ (azure-functions-vs-build-sdk) で利用できます。The source code for Microsoft.NET.Sdk.Functions is available in the GitHub repo azure-functions-vs-build-sdk.

ランタイム バージョンRuntime version

Visual Studio では、Azure Functions Core Tools を使用して、Functions プロジェクトを実行します。Visual Studio uses the Azure Functions Core Tools to run Functions projects. Core Tools は、Functions ランタイム用のコマンド ライン インターフェイスです。The Core Tools is a command-line interface for the Functions runtime.

npm を使用して Core Tools をインストールする場合、これは Visual Studio で使用される Core Tools バージョンには影響しません。If you install the Core Tools by using npm, that doesn't affect the Core Tools version used by Visual Studio. Functions ランタイム バージョン 1.x の場合、Visual Studio は Core Tools のバージョンを %USERPROFILE%\AppData\Local\Azure.Functions.Cli に格納し、そこに格納されている中で最も新しいバージョンを使用します。For the Functions runtime version 1.x, Visual Studio stores Core Tools versions in %USERPROFILE%\AppData\Local\Azure.Functions.Cli and uses the latest version stored there. Functions 2.x の場合、Core Tools は Azure Functions と Web ジョブ ツールの拡張機能に含まれます。For Functions 2.x, the Core Tools are included in the Azure Functions and Web Jobs Tools extension. 1.x と 2.x の両方について、使用されているバージョンは、Functions プロジェクトを実行するときに、コンソール出力で確認できます。For both 1.x and 2.x, you can see what version is being used in the console output when you run a Functions project:

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

バインドでサポートされる型Supported types for bindings

各バインドには独自にサポートされる型があります。たとえば、BLOB トリガー属性は文字列パラメーター、POCO パラメーター、CloudBlockBlob パラメーター、またはサポートされるその他の複数の型のいずれかに適用できます。Each binding has its own supported types; for instance, a blob trigger attribute can be applied to a string parameter, a POCO parameter, a CloudBlockBlob parameter, or any of several other supported types. BLOB バインディングのバインド リファレンスに関する記事に、サポートされるすべてのパラメーター型の一覧が示されています。The binding reference article for blob bindings lists all supported parameter types. 詳細については、トリガーとバインドに関する記事と、各バインドの種類に対応するバインド リファレンス ドキュメントをご覧ください。For more information, see Triggers and bindings and the binding reference docs for each binding type.

ヒント

HTTP または webhook のバインディングを使用する予定がある場合は、不適切な HttpClient のインスタンス化によって生じるおそれのあるポートの枯渇を防止してください。If you plan to use the HTTP or WebHook bindings, plan to avoid port exhaustion that can be caused by improper instantiation of HttpClient. 詳細については、「How to manage connections in Azure Functions」(Azure Functions で接続を管理する方法) を参照してください。For more information, see How to manage connections in Azure Functions.

メソッドの戻り値へのバインドBinding to method return value

出力バインドのメソッドの戻り値を使用するには、属性をメソッドの戻り値に適用します。You can use a method return value for an output binding, by applying the attribute to the method return value. 例については、トリガーとバインディングに関するページを参照してください。For examples, see Triggers and bindings.

正常な関数の実行によって、常に戻り値が出力バインドに渡される場合のみ、戻り値を使用してください。Use the return value only if a successful function execution always results in a return value to pass to the output binding. それ以外の場合は、次のセクションに示すように ICollector または IAsyncCollector を使用してください。Otherwise, use ICollector or IAsyncCollector, as shown in the following section.

複数の出力値の書き込みWriting multiple output values

1 つの出力バインドに複数の値を書き込むため、または正常な関数の呼び出しによって出力バインドに渡される値がない場合、ICollector または IAsyncCollector 型を使用してください。To write multiple values to an output binding, or if a successful function invocation might not result in anything to pass to the output binding, use the ICollector or IAsyncCollector types. これらの型は、メソッド完了時に出力バインドに書き込まれる、書き込み専用接続です。These types are write-only collections that are written to the output binding when the method completes.

この例では、ICollector を使用して複数のキュー メッセージを同じキューに書き込みます。This example writes multiple queue messages into the same queue using ICollector:

public static class ICollectorExample
{
    [FunctionName("CopyQueueMessageICollector")]
    public static void Run(
        [QueueTrigger("myqueue-items-source-3")] string myQueueItem,
        [Queue("myqueue-items-destination")] ICollector<string> myDestinationQueue,
        TraceWriter log)
    {
        log.Info($"C# function processed: {myQueueItem}");
        myDestinationQueue.Add($"Copy 1: {myQueueItem}");
        myDestinationQueue.Add($"Copy 2: {myQueueItem}");
    }
}

ログの記録Logging

出力を C# のストリーミング ログにログ記録するために、TraceWriter 型の引数を含めます。To log output to your streaming logs in C#, include an argument of type TraceWriter. これの名前を logにすることをお勧めします。We recommend that you name it log. Azure Functions では Console.Write を使用しないでください。Avoid using Console.Write in Azure Functions.

TraceWriterAzure Web ジョブ SDK で定義されます。TraceWriter is defined in the Azure WebJobs SDK. TraceWriter のログ レベルは、host.json で構成できます。The log level for TraceWriter can be configured in host.json.

public static class SimpleExample
{
    [FunctionName("QueueTrigger")]
    public static void Run(
        [QueueTrigger("myqueue-items")] string myQueueItem, 
        TraceWriter log)
    {
        log.Info($"C# function processed: {myQueueItem}");
    }
} 

注意

TraceWriter の代わりに使用できる新しいログ記録フレームワークについては、Azure Functions の監視に関する記事にある、C# 関数でのログの書き込みについての説明をご覧ください。For information about a newer logging framework that you can use instead of TraceWriter, see Write logs in C# functions in the Monitor Azure Functions article.

非同期Async

関数を非同期にするには、async キーワードを使用して Task オブジェクトを返します。To make a function asynchronous, use the async keyword and return a Task object.

public static class AsyncExample
{
    [FunctionName("BlobCopy")]
    public static async Task RunAsync(
        [BlobTrigger("sample-images/{blobName}")] Stream blobInput,
        [Blob("sample-images-copies/{blobName}", FileAccess.Write)] Stream blobOutput,
        CancellationToken token,
        TraceWriter log)
    {
        log.Info($"BlobCopy function processed.");
        await blobInput.CopyToAsync(blobOutput, 4096, token);
    }
}

非同期関数では out パラメーターを使用できません。You can't use out parameters in async functions. 出力バインドには、代わりに関数の戻り値またはコレクター オブジェクトを使用します。For output bindings, use the function return value or a collector object instead.

キャンセル トークンCancellation tokens

関数は CancellationToken パラメーターを受け付けることができます。これにより、オペレーティング システムは、その関数をいつ終了しようとしているかをコードに通知できます。A function can accept a CancellationToken parameter, which enables the operating system to notify your code when the function is about to be terminated. この通知を使用すれば、関数が予期せず終了してデータが不整合な状態になることを防止できます。You can use this notification to make sure the function doesn't terminate unexpectedly in a way that leaves data in an inconsistent state.

次の例は、関数の終了が迫っているかどうかを確認する方法を示しています。The following example shows how to check for impending function termination.

public static class CancellationTokenExample
{
    public static void Run(
        [QueueTrigger("inputqueue")] string inputText,
        TextWriter logger,
        CancellationToken token)
    {
        for (int i = 0; i < 100; i++)
        {
            if (token.IsCancellationRequested)
            {
                logger.WriteLine("Function was cancelled at iteration {0}", i);
                break;
            }
            Thread.Sleep(5000);
            logger.WriteLine("Normal processing for queue message={0}", inputText);
        }
    }
}

環境変数Environment variables

環境変数またはアプリ設定値を取得するには、次のコード例のように、 System.Environment.GetEnvironmentVariableを使用します。To get an environment variable or an app setting value, use System.Environment.GetEnvironmentVariable, as shown in the following code example:

public static class EnvironmentVariablesExample
{
    [FunctionName("GetEnvironmentVariables")]
    public static void Run([TimerTrigger("0 */5 * * * *")]TimerInfo myTimer, TraceWriter log)
    {
        log.Info($"C# Timer trigger function executed at: {DateTime.Now}");
        log.Info(GetEnvironmentVariable("AzureWebJobsStorage"));
        log.Info(GetEnvironmentVariable("WEBSITE_SITE_NAME"));
    }

    public static string GetEnvironmentVariable(string name)
    {
        return name + ": " +
            System.Environment.GetEnvironmentVariable(name, EnvironmentVariableTarget.Process);
    }
}

アプリ設定は、ローカルでの開発中と Azure での実行中の両方で、環境変数から読み取ることができます。App settings can be read from environment variables both when developing locally and when running in Azure. ローカルでの開発時、アプリ設定は local.settings.json ファイルの Values コレクションから取得します。When developing locally, app settings come from the Values collection in the local.settings.json file. ローカルと Azure の両方の環境において、GetEnvironmentVariable("<app setting name>") は名前付きアプリ設定の値を取得します。In both environments, local and Azure, GetEnvironmentVariable("<app setting name>") retrieves the value of the named app setting. たとえば、ローカルでの実行中、local.settings.json ファイルに { "Values": { "WEBSITE_SITE_NAME": "My Site Name" } } が含まれている場合は、"My Site Name" が返されます。For instance, when you're running locally, "My Site Name" would be returned if your local.settings.json file contains { "Values": { "WEBSITE_SITE_NAME": "My Site Name" } }.

System.Configuration.ConfigurationManager.AppSettings プロパティは、アプリ設定値を取得するための代替 API ですが、次に示すように GetEnvironmentVariable を使用することをお勧めします。The System.Configuration.ConfigurationManager.AppSettings property is an alternative API for getting app setting values, but we recommend that you use GetEnvironmentVariable as shown here.

実行時のバインドBinding at runtime

C# および他の .NET 言語では、属性の宣言型のバインドではなく命令型のバインド パターンを使用できます。In C# and other .NET languages, you can use an imperative binding pattern, as opposed to the declarative bindings in attributes. 命令型のバインドは、設計時ではなくランタイム時にバインド パラメーターを計算する必要がある場合に便利です。Imperative binding is useful when binding parameters need to be computed at runtime rather than design time. このパターンを使用すると、サポートされている入力バインドと出力バインドに関数コード内でバインドできます。With this pattern, you can bind to supported input and output bindings on-the-fly in your function code.

次のように命令型のバインドを定義します。Define an imperative binding as follows:

  • 必要な命令型のバインドの関数署名に属性を含めないでください。Do not include an attribute in the function signature for your desired imperative bindings.
  • 入力パラメーター Binder binder または IBinder binder を渡します。Pass in an input parameter Binder binder or IBinder binder.
  • 次の C# パターンを使用してデータ バインドを実行します。Use the following C# pattern to perform the data binding.

    using (var output = await binder.BindAsync<T>(new BindingTypeAttribute(...)))
    {
        ...
    }
    

    BindingTypeAttribute はバインドを定義する .NET 属性、T はそのバインドの種類でサポートされている入力または出力の型です。BindingTypeAttribute is the .NET attribute that defines your binding, and T is an input or output type that's supported by that binding type. Tout パラメーター型 (out JObject など) にすることはできません。T cannot be an out parameter type (such as out JObject). たとえば、Mobile Apps テーブルの出力バインドは 6 種類の出力をサポートしますが、強制バインドに使用できるのは ICollector または IAsyncCollector のみです。For example, the Mobile Apps table output binding supports six output types, but you can only use ICollector or IAsyncCollector with imperative binding.

単一属性の例Single attribute example

次のコード例は、実行時に BLOB パスが定義された Storage Blob の出力バインドを作成し、この BLOB に文字列を書き込みます。The following example code creates a Storage blob output binding with blob path that's defined at run time, then writes a string to the blob.

public static class IBinderExample
{
    [FunctionName("CreateBlobUsingBinder")]
    public static void Run(
        [QueueTrigger("myqueue-items-source-4")] string myQueueItem,
        IBinder binder,
        TraceWriter log)
    {
        log.Info($"CreateBlobUsingBinder function processed: {myQueueItem}");
        using (var writer = binder.Bind<TextWriter>(new BlobAttribute(
                    $"samples-output/{myQueueItem}", FileAccess.Write)))
        {
            writer.Write("Hello World!");
        };
    }
}

BlobAttributeStorage Blob の入力バインドまたは出力バインドを定義します。TextWriter はサポートされている出力バインドの種類です。BlobAttribute defines the Storage blob input or output binding, and TextWriter is a supported output binding type.

複数属性の例Multiple attribute example

前の例では、関数アプリのメイン ストレージ アカウント接続文字列 (AzureWebJobsStorage) のアプリ設定を取得します。The preceding example gets the app setting for the function app's main Storage account connection string (which is AzureWebJobsStorage). ストレージ アカウントに使用するカスタム アプリ設定を指定するには、StorageAccountAttribute を追加し、属性の配列を BindAsync<T>() に渡します。You can specify a custom app setting to use for the Storage account by adding the StorageAccountAttribute and passing the attribute array into BindAsync<T>(). IBinderではなく、Binder パラメーターを使用します。Use a Binder parameter, not IBinder. 例: For example:

public static class IBinderExampleMultipleAttributes
{
    [FunctionName("CreateBlobInDifferentStorageAccount")]
    public async static Task RunAsync(
            [QueueTrigger("myqueue-items-source-binder2")] string myQueueItem,
            Binder binder,
            TraceWriter log)
    {
        log.Info($"CreateBlobInDifferentStorageAccount function processed: {myQueueItem}");
        var attributes = new Attribute[]
        {
        new BlobAttribute($"samples-output/{myQueueItem}", FileAccess.Write),
        new StorageAccountAttribute("MyStorageAccount")
        };
        using (var writer = await binder.BindAsync<TextWriter>(attributes))
        {
            await writer.WriteAsync("Hello World!!");
        }
    }
}

トリガーとバインドTriggers and bindings

次の表は、Azure Functions の 2 つのメジャー バージョンのランタイムでサポートされているバインディングを示します。The following table shows the bindings that are supported in the two major versions of the Azure Functions runtime.

typeType 1.x1.x 2.x2.x トリガーTrigger 入力Input 出力Output
Blob StorageBlob Storage 11
Cosmos DBCosmos DB
Event GridEvent Grid
Event HubsEvent Hubs
外部ファイル 2External File2
外部テーブル 2External Table2
HTTPHTTP 11
Microsoft Graph
Excel テーブル
Microsoft Graph
Excel tables
Microsoft Graph
OneDrive ファイル
Microsoft Graph
OneDrive files
Microsoft Graph
Outlook メール
Microsoft Graph
Outlook email
Microsoft Graph
Events
Microsoft Graph
Events
Microsoft Graph
Auth トークン
Microsoft Graph
Auth tokens
Mobile AppsMobile Apps
Notification HubsNotification Hubs
Queue StorageQueue storage 11
SendGridSendGrid
Service BusService Bus
Table StorageTable storage 11
TimerTimer
TwilioTwilio
WebhookWebhooks

1 2.x では、HTTP、Timer、および Azure Storage を除くすべてのバインドを登録する必要があります。1 In 2.x, all bindings except HTTP, Timer, and Azure Storage must be registered. バインディング拡張機能を登録する」を参照してください。See Register binding extensions.

2 実験的 — サポート対象外で、将来破棄される可能性があります。2 Experimental — not supported and might be abandoned in the future.

次の手順Next steps