持続的オーケストレーションDurable Orchestrations

Durable Functions は Azure Functions の拡張機能です。Durable Functions is an extension of Azure Functions. オーケストレーター関数を使用すると、関数アプリ内の他の持続的関数の実行を調整できます。You can use an orchestrator function to orchestrate the execution of other Durable functions within a function app. オーケストレーター関数には次のような特性があります。Orchestrator functions have the following characteristics:

  • オーケストレーター関数では、手続き型コードを使用して関数のワークフローが定義されています。Orchestrator functions define function workflows using procedural code. 宣言型スキーマまたはデザイナーは必要ありません。No declarative schemas or designers are needed.
  • オーケストレーター関数では、他の持続的関数を同期および非同期のどちらでも呼び出すことができます。Orchestrator functions can call other durable functions synchronously and asynchronously. 呼び出された関数からの出力を、ローカル変数に確実に保存できます。Output from called functions can be reliably saved to local variables.
  • オーケストレーター関数は持続性と信頼性を備えています。Orchestrator functions are durable and reliable. 関数で "await" または "yield" が実行されると、実行の進行状況に自動的にチェックポイントが設定されます。Execution progress is automatically checkpointed when the function "awaits" or "yields". プロセスがリサイクルされるときや VM が再起動されるときに、ローカルの状態が失われることがありません。Local state is never lost when the process recycles or the VM reboots.
  • オーケストレーター関数は長時間実行される可能性があります。Orchestrator functions can be long-running. "オーケストレーション インスタンス" の全体的な継続時間は、秒、日、月の単位になる場合、またはいつまでも終了しない場合があります。The total lifespan of an orchestration instance can be seconds, days, months, or never-ending.

この記事では、オーケストレーター関数の概要と、オーケストレーター関数によってアプリ開発のさまざまな課題を解決する方法について説明します。This article gives you an overview of orchestrator functions and how they can help you solve various app development challenges. Durable Functions アプリで使用可能な関数の種類をまだよく理解していない場合は、最初に Durable Functions の種類に関する記事をご覧ください。If you are not already familiar with the types of functions available in a Durable Functions app, read the Durable Function types article first.

オーケストレーション IDOrchestration identity

オーケストレーションの各 "インスタンス" にはインスタンス ID あります ("インスタンス ID" とも呼ばれます)。Each instance of an orchestration has an instance identifier (also known as an instance ID). 既定では、各インスタンス ID は自動生成される GUID です。By default, each instance ID is an autogenerated GUID. ただし、ユーザーが生成した文字列値をインスタンス ID にすることもできます。However, instance IDs can also be any user-generated string value. 各オーケストレーション インスタンス ID は、タスク ハブ内で一意である必要があります。Each orchestration instance ID must be unique within a task hub.

インスタンス ID に関するいくつかのルールを次に示します。The following are some rules about instance IDs:

  • インスタンス ID は、1 から 256 文字にする必要があります。Instance IDs must be between 1 and 256 characters.
  • インスタンス ID の先頭文字を @ にすることはできません。Instance IDs must not start with @.
  • インスタンス ID に、/\#? の各文字を含めることはできません。Instance IDs must not contain /, \, #, or ? characters.
  • インスタンス ID に、制御文字を含めることはできません。Instance IDs must not contain control characters.

注意

一般に、可能な限り自動生成されたインスタンス ID を使用することをお勧めします。It is generally recommended to use autogenerated instance IDs whenever possible. ユーザー生成のインスタンス ID は、オーケストレーション インスタンスと、外部アプリケーション固有のエンティティ (注文書やドキュメントなど) との間に一対一のマッピングが存在するシナリオのためのものです。User-generated instance IDs are intended for scenarios where there is a one-to-one mapping between an orchestration instance and some external application-specific entity, like a purchase order or a document.

ほとんどのインスタンス管理操作で、オーケストレーション インスタンス ID は必須のパラメーターです。An orchestration's instance ID is a required parameter for most instance management operations. また、トラブルシューティングや分析を目的とする Application Insights でのオーケストレーション追跡データによる検索などの診断にも重要です。They are also important for diagnostics, such as searching through orchestration tracking data in Application Insights for troubleshooting or analytics purposes. このため、生成されたインスタンス ID は、後で簡単に参照できる外部の場所 (データベースやアプリケーション ログなど) に保存することをお勧めします。For this reason, it is recommended to save generated instance IDs to some external location (for example, a database or in application logs) where they can be easily referenced later.

[信頼性]Reliability

オーケストレーター関数は、イベント ソーシング設計パターンを使用して、この関数の実行状態を確実に管理します。Orchestrator functions reliably maintain their execution state by using the event sourcing design pattern. Durable Task Framework では、オーケストレーションの現在の状態を直接格納する代わりに、追加専用ストアを使用して、関数オーケストレーションによって実行されるすべてのアクションが記録されます。Instead of directly storing the current state of an orchestration, the Durable Task Framework uses an append-only store to record the full series of actions the function orchestration takes. 追加専用ストアには、実行時のすべての状態の "ダンプ" に比べて、多くのメリットがあります。An append-only store has many benefits compared to "dumping" the full runtime state. メリットには、パフォーマンス、スケーラビリティ、および応答性の向上が含まれます。Benefits include increased performance, scalability, and responsiveness. トランザクション データの最終的な一貫性、完全な監査証跡、および監査履歴も取得できます。You also get eventual consistency for transactional data and full audit trails and history. 監査証跡では、信頼性の高い補正アクションがサポートされます。The audit trails support reliable compensating actions.

Durable Functions では、イベント ソーシングが透過的に使用されます。Durable Functions uses event sourcing transparently. バックグラウンドで、オーケストレーター関数内の await (C#) または yield (JavaScript/Python) 演算子によって、オーケストレーター スレッドの制御が Durable Task Framework ディスパッチャーに戻ります。Behind the scenes, the await (C#) or yield (JavaScript/Python) operator in an orchestrator function yields control of the orchestrator thread back to the Durable Task Framework dispatcher. 次に、このディスパッチャーは、オーケストレーター関数がスケジュールした新しいアクション (1 つ以上の子関数を呼び出す、永続タイマーをスケジュールする、など) をストレージにコミットします。The dispatcher then commits any new actions that the orchestrator function scheduled (such as calling one or more child functions or scheduling a durable timer) to storage. この透過的なコミット アクションが、オーケストレーション インスタンスの実行履歴に追加されます。The transparent commit action appends to the execution history of the orchestration instance. この履歴はストレージ テーブルに格納されます。The history is stored in a storage table. 次に、このコミット アクションはキューにメッセージを追加して実際の作業をスケジュールします。The commit action then adds messages to a queue to schedule the actual work. この時点では、メモリからオーケストレーター関数をアンロードできます。At this point, the orchestrator function can be unloaded from memory.

オーケストレーション関数にさらに処理すべき作業 (応答メッセージの受信や永続タイマーの終了など) が与えられると、オーケストレーターが起動し、関数全体が始めから再実行され、ローカルの状態が再構築されます。When an orchestration function is given more work to do (for example, a response message is received or a durable timer expires), the orchestrator wakes up and re-executes the entire function from the start to rebuild the local state. このリプレイ中にコードが関数を呼び出そうとする (または他の非同期作業を行おうとする) と、Durable Task Framework によって現在のオーケストレーションの実行履歴が確認されます。During the replay, if the code tries to call a function (or do any other async work), the Durable Task Framework consults the execution history of the current orchestration. アクティビティ関数が既に実行され、いくつかの結果が生成されていることがわかった場合は、関数の結果をリプレイし、オーケストレーター コードの実行を続行します。If it finds that the activity function has already executed and yielded a result, it replays that function's result and the orchestrator code continues to run. リプレイは、関数コードが完了するまで、または新しい非同期作業がスケジュールされるまで続行されます。Replay continues until the function code is finished or until it has scheduled new async work.

注意

リプレイ パターンが正常かつ確実に動作するためには、オーケストレーター関数のコードが "決定論的" である必要があります。In order for the replay pattern to work correctly and reliably, orchestrator function code must be deterministic. オーケストレーター関数のコードの制限について詳しくは、オーケストレーター関数のコードの制約に関するトピックをご覧ください。For more information about code restrictions for orchestrator functions, see the orchestrator function code constraints topic.

注意

オーケストレーター関数によってログ メッセージを出力される場合、リプレイ動作によって重複するログ メッセージが生成される可能性があります。If an orchestrator function emits log messages, the replay behavior may cause duplicate log messages to be emitted. この動作が発生する理由とそれを回避する方法の詳細については、ログ記録に関するセクションをご覧ください。See the Logging topic to learn more about why this behavior occurs and how to work around it.

オーケストレーションの履歴Orchestration history

Durable Task Framework のイベント ソーシング動作は、記述したオーケストレーター関数のコードと密接に結び付けられています。The event-sourcing behavior of the Durable Task Framework is closely coupled with the orchestrator function code you write. 次のオーケストレーター関数のような、アクティビティ チェーン オーケストレーター関数があるものとします。Suppose you have an activity-chaining orchestrator function, like the following orchestrator function:

[FunctionName("E1_HelloSequence")]
public static async Task<List<string>> Run(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    var outputs = new List<string>();

    outputs.Add(await context.CallActivityAsync<string>("E1_SayHello", "Tokyo"));
    outputs.Add(await context.CallActivityAsync<string>("E1_SayHello", "Seattle"));
    outputs.Add(await context.CallActivityAsync<string>("E1_SayHello", "London"));

    // returns ["Hello Tokyo!", "Hello Seattle!", "Hello London!"]
    return outputs;
}

Durable Task Framework では、await (C#) または yield (JavaScript/Python) ステートメントごとに、関数の実行状態のチェックポイントが、持続的なストレージ バックエンド (通常は Azure Table Storage) に記録されます。At each await (C#) or yield (JavaScript/Python) statement, the Durable Task Framework checkpoints the execution state of the function into some durable storage backend (typically Azure Table storage). この状態は、"オーケストレーションの履歴" と呼ばれます。This state is what is referred to as the orchestration history.

履歴テーブルHistory table

一般的に、Durable Task Framework は、チェックポイントごとに次の処理を実行します。Generally speaking, the Durable Task Framework does the following at each checkpoint:

  1. 実行履歴を Azure Storage テーブルに保存します。Saves execution history into Azure Storage tables.
  2. オーケストレーターが起動する必要がある関数のメッセージをエンキューします。Enqueues messages for functions the orchestrator wants to invoke.
  3. オーケストレーター自体のメッセージ — たとえば、持続的タイマー メッセージをエンキューします。Enqueues messages for the orchestrator itself — for example, durable timer messages.

チェックポイントが完了したら、さらに多くの作業が必要になるまで、オーケストレーター関数をメモリから自由に削除できるようになります。Once the checkpoint is complete, the orchestrator function is free to be removed from memory until there is more work for it to do.

注意

Azure Storage では、Table Storage へのデータ保存とキューへのデータ保存の間で、トランザクションが保証されません。Azure Storage does not provide any transactional guarantees between saving data into table storage and queues. エラーを処理するために、Durable Functions ストレージ プロバイダーでは "最終的な一貫性" パターンが使用されます。To handle failures, the Durable Functions storage provider uses eventual consistency patterns. こうしたパターンにより、チェックポイントの途中でクラッシュまたは接続の切断が発生しても、データが失われることはありません。These patterns ensure that no data is lost if there is a crash or loss of connectivity in the middle of a checkpoint.

完了すると、Azure Table Storage の上記の関数の履歴は次の表のようになります (わかりやすくするために一部省略されています)。Upon completion, the history of the function shown earlier looks something like the following table in Azure Table Storage (abbreviated for illustration purposes):

PartitionKey (InstanceId)PartitionKey (InstanceId) EventTypeEventType TimestampTimestamp 入力Input 名前Name 結果Result StatusStatus
eaee885beaee885b ExecutionStartedExecutionStarted 2017-05-05T18:45:28.852Z2017-05-05T18:45:28.852Z nullnull E1_HelloSequenceE1_HelloSequence
eaee885beaee885b OrchestratorStartedOrchestratorStarted 2017-05-05T18:45:32.362Z2017-05-05T18:45:32.362Z
eaee885beaee885b TaskScheduledTaskScheduled 2017-05-05T18:45:32.670Z2017-05-05T18:45:32.670Z E1_SayHelloE1_SayHello
eaee885beaee885b OrchestratorCompletedOrchestratorCompleted 2017-05-05T18:45:32.670Z2017-05-05T18:45:32.670Z
eaee885beaee885b TaskCompletedTaskCompleted 2017-05-05T18:45:34.201Z2017-05-05T18:45:34.201Z """Hello Tokyo!""""""Hello Tokyo!"""
eaee885beaee885b OrchestratorStartedOrchestratorStarted 2017-05-05T18:45:34.232Z2017-05-05T18:45:34.232Z
eaee885beaee885b TaskScheduledTaskScheduled 2017-05-05T18:45:34.435Z2017-05-05T18:45:34.435Z E1_SayHelloE1_SayHello
eaee885beaee885b OrchestratorCompletedOrchestratorCompleted 2017-05-05T18:45:34.435Z2017-05-05T18:45:34.435Z
eaee885beaee885b TaskCompletedTaskCompleted 2017-05-05T18:45:34.763Z2017-05-05T18:45:34.763Z """Hello Seattle!""""""Hello Seattle!"""
eaee885beaee885b OrchestratorStartedOrchestratorStarted 2017-05-05T18:45:34.857Z2017-05-05T18:45:34.857Z
eaee885beaee885b TaskScheduledTaskScheduled 2017-05-05T18:45:34.857Z2017-05-05T18:45:34.857Z E1_SayHelloE1_SayHello
eaee885beaee885b OrchestratorCompletedOrchestratorCompleted 2017-05-05T18:45:34.857Z2017-05-05T18:45:34.857Z
eaee885beaee885b TaskCompletedTaskCompleted 2017-05-05T18:45:34.919Z2017-05-05T18:45:34.919Z """Hello London!""""""Hello London!"""
eaee885beaee885b OrchestratorStartedOrchestratorStarted 2017-05-05T18:45:35.032Z2017-05-05T18:45:35.032Z
eaee885beaee885b OrchestratorCompletedOrchestratorCompleted 2017-05-05T18:45:35.044Z2017-05-05T18:45:35.044Z
eaee885beaee885b ExecutionCompletedExecutionCompleted 2017-05-05T18:45:35.044Z2017-05-05T18:45:35.044Z "[""Hello Tokyo!"",""Hello Seattle!"",""Hello London!""]""[""Hello Tokyo!"",""Hello Seattle!"",""Hello London!""]" 完了Completed

列の値に関する注意点:A few notes on the column values:

  • PartitionKey:オーケストレーションのインスタンス ID が含まれます。PartitionKey: Contains the instance ID of the orchestration.
  • EventType:イベントの種類を表します。EventType: Represents the type of the event. 次のいずれかの種類です。May be one of the following types:
    • OrchestrationStarted:オーケストレーター関数が await から再実行されました。または初回実行中です。OrchestrationStarted: The orchestrator function resumed from an await or is running for the first time. Timestamp 列は、CurrentUtcDateTime (.NET)、currentUtcDateTime (JavaScript)、および current_utc_datetime (Python) API の決定論的な値を設定するために使用されます。The Timestamp column is used to populate the deterministic value for the CurrentUtcDateTime (.NET), currentUtcDateTime (JavaScript), and current_utc_datetime (Python) APIs.
    • ExecutionStarted:オーケストレーター関数は初めて実行を開始しました。ExecutionStarted: The orchestrator function started executing for the first time. このイベントには、Input 列の関数入力も含まれています。This event also contains the function input in the Input column.
    • TaskScheduled:アクティビティ関数がスケジュールされました。TaskScheduled: An activity function was scheduled. アクティビティ関数の名前は Name 列でキャプチャされます。The name of the activity function is captured in the Name column.
    • TaskCompleted:アクティビティ関数が完了しました。TaskCompleted: An activity function completed. 関数の結果は Result 列に含まれます。The result of the function is in the Result column.
    • TimerCreated:持続的タイマーが作成されました。TimerCreated: A durable timer was created. FireAt 列には、タイマーが期限切れになるスケジュールされた UTC 時間が含まれます。The FireAt column contains the scheduled UTC time at which the timer expires.
    • TimerFired:持続的タイマーが開始されました。TimerFired: A durable timer fired.
    • EventRaised:外部イベントがオーケストレーション インスタンスに送信されました。EventRaised: An external event was sent to the orchestration instance. Name 列は、イベントの名前をキャプチャし、Input 列は、イベントのペイロードをキャプチャします。The Name column captures the name of the event and the Input column captures the payload of the event.
    • OrchestratorCompleted:オーケストレーター関数が待機状態になりました。OrchestratorCompleted: The orchestrator function awaited.
    • ContinueAsNew:オーケストレーター関数が完了し、新しい状態で再実行されました。ContinueAsNew: The orchestrator function completed and restarted itself with new state. Result 列には、再起動されたインスタンスで入力として使用される値が含まれます。The Result column contains the value, which is used as the input in the restarted instance.
    • ExecutionCompleted:オーケストレーター関数が実行され、完了 (または失敗) しました。ExecutionCompleted: The orchestrator function ran to completion (or failed). 関数またはエラーの詳細の出力は Result 列に格納されます。The outputs of the function or the error details are stored in the Result column.
  • [タイムスタンプ] : 履歴イベントの UTC タイムスタンプ。Timestamp: The UTC timestamp of the history event.
  • Name:呼び出された関数の名前。Name: The name of the function that was invoked.
  • 入力:関数の JSON 形式の入力。Input: The JSON-formatted input of the function.
  • Result:関数の出力、つまり、戻り値。Result: The output of the function; that is, its return value.

警告

これはデバッグ ツールとしては便利ですが、このテーブルにあまり依存しないようにしてください。While it's useful as a debugging tool, don't take any dependency on this table. Durable Functions 拡張機能の刷新に伴って変更される可能性があります。It may change as the Durable Functions extension evolves.

await (C#) または yield (JavaScript/Python) から関数が再実行されるたびに、Durable Task Framework は、オーケストレーター関数をゼロから再実行します。Every time the function resumes from an await (C#) or yield (JavaScript/Python), the Durable Task Framework reruns the orchestrator function from scratch. 再実行のたびに、実行履歴が調べられて、現在の非同期操作が実行されているかどうかが確認されます。On each rerun, it consults the execution history to determine whether the current async operation has taken place. 操作が実行されている場合、フレームワークはその操作の出力をすぐに再生し、次の await (C#) または yield (JavaScript/Python) に移動します。If the operation took place, the framework replays the output of that operation immediately and moves on to the next await (C#) or yield (JavaScript/Python). 履歴全体がリプレイされるまで、このプロセスが続けられます。This process continues until the entire history has been replayed. 現在の履歴がリプレイされると、ローカル変数が以前の値に復元されます。Once the current history has been replayed, the local variables will have been restored to their previous values.

機能とパターンFeatures and patterns

次のセクションでは、オーケストレーター関数の機能とパターンについて説明します。The next sections describe the features and patterns of orchestrator functions.

サブオーケストレーションSub-orchestrations

オーケストレーター関数では、アクティビティ関数を呼び出すことができますが、別のオーケストレーター関数を呼び出すこともできます。Orchestrator functions can call activity functions, but also other orchestrator functions. たとえば、オーケストレーター関数のライブラリから大規模なオーケストレーションを作成できます。For example, you can build a larger orchestration out of a library of orchestrator functions. つまり、オーケストレーター関数の複数のインスタンスを並列で実行できます。Or, you can run multiple instances of an orchestrator function in parallel.

詳細と例については、サブオーケストレーションに関する記事をご覧ください。For more information and for examples, see the Sub-orchestrations article.

持続的タイマーDurable timers

オーケストレーションでは、持続的タイマーをスケジュールして、遅延を実装したり、非同期アクションに対するタイムアウト処理を設定したりすることができます。Orchestrations can schedule durable timers to implement delays or to set up timeout handling on async actions. オーケストレーター関数の持続的タイマーは、Thread.Sleep および Task.Delay (C#)、または setTimeout() および setInterval() (JavaScript)、または time.sleep() (Python) の代わりに使用します。Use durable timers in orchestrator functions instead of Thread.Sleep and Task.Delay (C#), or setTimeout() and setInterval() (JavaScript), or time.sleep() (Python).

詳細と例については、持続的タイマーに関する記事をご覧ください。For more information and for examples, see the Durable timers article.

外部イベントExternal events

オーケストレーター関数は、オーケストレーション インスタンスを更新するために、外部イベントを待ち受けできます。Orchestrator functions can wait for external events to update an orchestration instance. Durable Functions のこの機能は、多くの場合、人による操作または他の外部コールバックを処理するときに便利です。This Durable Functions feature often is useful for handling a human interaction or other external callbacks.

詳細と例については、外部イベントに関する記事をご覧ください。For more information and for examples, see the External events article.

エラー処理Error handling

オーケストレーター関数では、プログラミング言語のエラー処理機能を使用できます。Orchestrator functions can use the error-handling features of the programming language. オーケストレーションのコードでは、try/catch のような既存のパターンがサポートされています。Existing patterns like try/catch are supported in orchestration code.

オーケストレーター関数では、呼び出されるアクティビティまたはサブオーケストレーター関数に再試行ポリシーを追加することもできます。Orchestrator functions can also add retry policies to the activity or sub-orchestrator functions that they call. アクティビティまたはサブオーケストレーター関数が例外で失敗した場合、指定した再試行ポリシーによって自動的に遅延し、指定した回数まで実行を再試行できます。If an activity or sub-orchestrator function fails with an exception, the specified retry policy can automatically delay and retry the execution up to a specified number of times.

注意

オーケストレーター関数でハンドルされない例外が発生した場合、オーケストレーションのインスタンスは Failed 状態で完了します。If there is an unhandled exception in an orchestrator function, the orchestration instance will complete in a Failed state. 失敗したオーケストレーションのインスタンスを再試行することはできません。An orchestration instance cannot be retried once it has failed.

詳細と例については、エラー処理に関する記事をご覧ください。For more information and for examples, see the Error handling article.

重要なセクション (Durable Functions 2.x、現在 .NET のみ)Critical sections (Durable Functions 2.x, currently .NET only)

オーケストレーションのインスタンスはシングルスレッドであるため、オーケストレーションの "内部" の競合状態について考慮する必要はありません。Orchestration instances are single-threaded so it isn't necessary to worry about race conditions within an orchestration. ただし、オーケストレーションから外部システムとやりとりする場合、競合状態が発生する可能性があります。However, race conditions are possible when orchestrations interact with external systems. 外部システムと相互作用するときの競合状態を軽減するため、オーケストレーター関数では .NET の LockAsync メソッドを使用して "クリティカル セクション" を定義できます。To mitigate race conditions when interacting with external systems, orchestrator functions can define critical sections using a LockAsync method in .NET.

次のサンプル コードで示すオーケストレーター関数では、クリティカル セクションが定義されています。The following sample code shows an orchestrator function that defines a critical section. クリティカル セクションに入るには、LockAsync メソッドを使用します。It enters the critical section using the LockAsync method. このメソッドでは、持続的にロック状態を管理する持続エンティティへの 1 つ以上の参照を渡す必要があります。This method requires passing one or more references to a Durable Entity, which durably manages the lock state. クリティカル セクション内のコードを実行できるこのオーケストレーションのインスタンスは、一度に 1 つだけです。Only a single instance of this orchestration can execute the code in the critical section at a time.

[FunctionName("Synchronize")]
public static async Task Synchronize(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    var lockId = new EntityId("LockEntity", "MyLockIdentifier");
    using (await context.LockAsync(lockId))
    {
        // critical section - only one orchestration can enter at a time
    }
}

LockAsync では、持続的ロックが取得されて、破棄されたときにクリティカル セクションが終了する IDisposable が返されます。The LockAsync acquires the durable lock(s) and returns an IDisposable that ends the critical section when disposed. この IDisposable の結果を using ブロックと共に使用して、クリティカル セクションの構文表現を取得できます。This IDisposable result can be used together with a using block to get a syntactic representation of the critical section. オーケストレーター関数がクリティカル セクションに入ると、1 つのインスタンスだけがそのコード ブロックを実行できます。When an orchestrator function enters a critical section, only one instance can execute that block of code. 他のインスタンスがそのクリティカル セクションに入ろうとしても、前のインスタンスがそのクリティカル セクションを終了するまでブロックされます。Any other instances that try to enter the critical section will be blocked until the previous instance exits the critical section.

クリティカル セクションの機能は、持続性エンティティに対する変更を調整する場合にも役立ちます。The critical section feature is also useful for coordinating changes to durable entities. クリティカル セクションについて詳しくは、持続性エンティティの "エンティティ調整" に関するトピックをご覧ください。For more information about critical sections, see the Durable entities "Entity coordination" topic.

注意

クリティカル セクションは Durable Functions 2.0 以降で使用できます。Critical sections are available in Durable Functions 2.0 and above. 現在、この機能が実装されているのは .NET オーケストレーションだけです。Currently, only .NET orchestrations implement this feature.

HTTP エンドポイントの呼び出し (Durable Functions 2.x)Calling HTTP endpoints (Durable Functions 2.x)

オーケストレーター関数のコードの制約に関する記事で説明されているように、オーケストレーター関数は I/O を行うことを許可されていません。Orchestrator functions aren't permitted to do I/O, as described in orchestrator function code constraints. この制限に対する一般的な回避策は、I/O を行う必要があるすべてのコードをアクティビティ関数内にラップすることです。The typical workaround for this limitation is to wrap any code that needs to do I/O in an activity function. 外部システムとのやりとりが頻繁に行われるオーケストレーションでは、アクティビティ関数を使用して、HTTP の呼び出しを行い、その結果をオーケストレーションに返します。Orchestrations that interact with external systems frequently use activity functions to make HTTP calls and return the result to the orchestration.

この一般的なパターンを簡略化するため、オーケストレーター関数では、CallHttpAsync メソッドを使用して、HTTP API を直接呼び出すことができます。To simplify this common pattern, orchestrator functions can use the CallHttpAsync method to invoke HTTP APIs directly.

[FunctionName("CheckSiteAvailable")]
public static async Task CheckSiteAvailable(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    Uri url = context.GetInput<Uri>();

    // Makes an HTTP GET request to the specified endpoint
    DurableHttpResponse response = 
        await context.CallHttpAsync(HttpMethod.Get, url);

    if (response.StatusCode >= 400)
    {
        // handling of error codes goes here
    }
}

基本的な要求と応答のパターンのサポートに加えて、このメソッドでは、一般的な非同期 HTTP 202 ポーリング パターンの自動処理がサポートされており、マネージド ID を使用した外部サービスによる認証もサポートされています。In addition to supporting basic request/response patterns, the method supports automatic handling of common async HTTP 202 polling patterns, and also supports authentication with external services using Managed Identities.

詳細と例については、HTTP 機能に関する記事をご覧ください。For more information and for detailed examples, see the HTTP features article.

注意

オーケストレーター関数からの HTTP エンドポイントの直接呼び出しは、Durable Functions 2.0 以降で使用できます。Calling HTTP endpoints directly from orchestrator functions is available in Durable Functions 2.0 and above.

複数のパラメーターを渡すPassing multiple parameters

アクティビティ関数に複数のパラメーターを直接渡すことはできません。It isn't possible to pass multiple parameters to an activity function directly. オブジェクトの配列または複合オブジェクトを渡すことをお勧めします。The recommendation is to pass in an array of objects or composite objects.

.NET では、ValueTuples オブジェクトを使用することもできます。In .NET you can also use ValueTuples objects. 次の例では、C# 7 に追加された ValueTuples の新機能を使用しています。The following sample is using new features of ValueTuples added with C# 7:

[FunctionName("GetCourseRecommendations")]
public static async Task<object> RunOrchestrator(
    [OrchestrationTrigger] IDurableOrchestrationContext context)
{
    string major = "ComputerScience";
    int universityYear = context.GetInput<int>();

    object courseRecommendations = await context.CallActivityAsync<object>(
        "CourseRecommendations",
        (major, universityYear));
    return courseRecommendations;
}

[FunctionName("CourseRecommendations")]
public static async Task<object> Mapper([ActivityTrigger] IDurableActivityContext inputs)
{
    // parse input for student's major and year in university
    (string Major, int UniversityYear) studentInfo = inputs.GetInput<(string, int)>();

    // retrieve and return course recommendations by major and university year
    return new
    {
        major = studentInfo.Major,
        universityYear = studentInfo.UniversityYear,
        recommendedCourses = new []
        {
            "Introduction to .NET Programming",
            "Introduction to Linux",
            "Becoming an Entrepreneur"
        }
    };
}

次のステップNext steps