Trvalost a serializace dat v Durable Functions pro Azure Functions

Important

Support pro model v procesu skončí 10. listopadu 2026. Důrazně doporučujeme migrovat aplikace do izolovaného modelu pracovních procesů pro plnou podporu.

Modul runtime Durable Functions automaticky zachovává parametry funkce, návratové hodnoty a další stav do centra task hub za účelem zajištění spolehlivého provádění. Množství a frekvence dat uchováných v trvalém úložišti ale může mít vliv na výkon aplikace a náklady na transakce úložiště. V závislosti na typu dat, která vaše aplikace ukládá, může být potřeba zvážit také zásady uchovávání dat a ochrany osobních údajů.

Tento článek vysvětluje, jaká data se zachovají, jak zpracovávat velké datové části a citlivá data a jak přizpůsobit serializaci pro každý podporovaný jazyk.

V tomto článku:

• Obsah centra úloh – Jaká data jsou uložená a jak
• Udržujte vstupy a výstupy malé – strategie správy velikosti datové části
• Práce s citlivými daty – Ochrana tajných kódů a identifikovatelných osobních údajů
• Zabezpečení úložiště centra úloh – Ochrana back-endu úložiště před neoprávněným přístupem
• Přizpůsobení serializace a deserializace – možnosti serializace specifické pro jazyk

Obsah centra úloh

Centra úloh ukládají aktuální stav instancí a všechny čekající zprávy:

• Stavy instancí ukládají aktuální stav a historii instancí. Pro instance orchestrace tento stav zahrnuje stav modulu runtime, historii orchestrace, vstupy, výstupy a vlastní stav. V případě instancí entit zahrnuje stav entity.
• Zprávy ukládají vstupy nebo výstupy funkcí, datové části událostí a metadata, která se používají pro interní účely, jako je směrování a kompletní korelace.

Zprávy se po zpracování odstraní, ale stavy instancí se zachovají, pokud je aplikace nebo operátor explicitně nesmažou. Zejména historie orchestrace zůstává v úložišti i po dokončení orchestrace.

Příklad toho, jak stavy a zprávy představují průběh orchestrace, najdete v příkladu provedení centra úloh.

Kde a jak jsou stavy a zprávy reprezentovány v úložišti , závisí na poskytovateli úložiště. Používejte Durable Task Scheduler , protože poskytuje spravovaný backend pro task huby a spravuje za vás základní úložiště stavů. Nicméně Azure Storage zůstává solidní volbou pro stávající pracovní zátěže a aplikace, které chtějí spravovat své úložné zdroje samy.

Poskytovatel úložiště	Jak je stav uložen	Doporučené použití
Plánovač úloh Durable	Orchestrace a stav entity jsou uloženy v backendu spravovaného plánovače za zdrojem task hubu.	Preferovaná volba pro nové aplikace Durable Functions a spravované nasazení.
Azure Storage	Stav a zprávy jsou reprezentovány ve frontách, tabulkách a blobech v účtu Azure Storage.	Dobře se hodí pro stávající aplikace nebo nasazení, která už spoléhají na Azure Storage.

Typy dat serializovaných a trvalých

Následující seznam ukazuje různé typy dat, které budou serializovány a zachovány při použití funkcí Durable Functions:

• Všechny vstupy a výstupy funkcí orchestrátoru, aktivity a entit, včetně všech ID a neošetřených výjimek
• Názvy funkcí orchestrátoru, aktivit a entit
• Názvy externích událostí a jejich obsahy
• Vlastní zatížení stavu orchestrace
• Zprávy o ukončení orchestrace
• Datové části trvalých časovačů
• Trvalé adresy URL požadavků a odpovědí HTTP, hlavičky a datové části
• Datové části entit a volání signálu
• Datová náplň stavu entity

Pokyny ke správě velikosti užitečného zatížení a ochraně citlivých položek v tomto seznamu najdete v následujících oddílech.

Udržujte vstupy a výstupy Durable Functions malé

Pokud zadáte velké vstupy a výstupy do a z rozhraní API Durable Functions, můžete narazit na problémy s pamětí. Vstupy a výstupy jsou serializovány do historie orchestrace, což znamená, že velké zátěže mohou v průběhu času výrazně přispět k neomezenému růstu historie. Toto zvýšení rizik způsobuje výjimky paměti během opakovaného přehrávání.

Pokud chcete zmírnit dopad velkých vstupů a výstupů, můžete:

• Delegujte práci na dílčí orchestrátory, aby vyrovnávali zatížení paměti historie napříč několika orchestrátory a udržovali tak malé nároky na paměť jednotlivých historie.
• Ukládejte velká data do externího úložiště (například Azure Blob Storage) a předejte zjednodušené identifikátory, které umožňují v případě potřeby načíst tato data uvnitř funkcí aktivit.

Pro Durable Task Scheduler použijte podporu velkých payloadů k přesunu větších payloadů do Azure Blob Storage. U nových aplikací se tento vzor doporučuje v případech, kdy orchestrace musí mezi trvalými operacemi předávat velké datové objemy. Pokud používáte poskytovatele Azure Storage, můžete i nadále použít vzor claim-check popsaný v následující části a mezi operacemi předávat odlehčené reference.

Tip

Osvědčeným postupem při práci s velkými daty je zachovat je v externím úložišti a materializovat tato data pouze uvnitř aktivit v případě potřeby.

Předávejte reference na velké datové zátěže

Vyberte si vzor, který odpovídá vašemu poskytovateli skladování.

Plánovač úloh Durable

Pokud používáte Durable Task Scheduler, povolte podporu velkých payloadů, aby runtime zapisoval větší payloady do Azure Blob Storage a posílal malou referenci přes plánovač. Typická konfigurace je uvedena v dokumentaci plánovače:

{
  "version": "2.0",
  "extensions": {
    "durableTask": {
      "storageProvider": {
        "type": "azureManaged",
        "connectionStringName": "DTS_CONNECTION_STRING",
        "payloadStorageEnabled": true,
        "payloadStorageThresholdBytes": 262144
      },
      "hubName": "%TASKHUB_NAME%"
    }
  }
}

Azure Storage

S poskytovatelem Azure Storage můžete použít vzorec Claim Check, aby historie orchestrace zůstala malá a zároveň bylo možné zpracovávat rozsáhlá data. Orchestrátor předává lehkou referenci, která obsahuje blob kontejner a název blobu, a aktivita podle potřeby čte nebo zapisuje payload z Azure Blob Storage.

Následující příklady předpokládají, že už máte blob ve svém úložném účtu. Spusťte orchestraci pomocí odkazu, například {"container":"large-payloads","blobName":"input/job-123.json"}. Aktivita v případě potřeby vytvoří výstupní kontejner processed-payloads. Krok zpracování vzorku zkopíruje vstupní bajty beze změny; Nahraďte to logikou aplikace.

Important

Nikdy neuvádějte v referenci přihlašovací údaje pro ukládání nebo sdílený přístupový podpis (SAS). Systém uchovává referenci v historii orchestrace. Tyto příklady používají nastavení aplikace pojmenované PAYLOAD_STORAGE_CONNECTION_STRING tak, aby byl kód úložiště stručný. Pro produkční pracovní zátěže použijte Microsoft Entra ID k autorizaci přístupu k blob datům.

C# (Samostatný)

Tento příklad vyžaduje Azure. Storage.Blobs NuGet balíček.

using System;
using System.Threading.Tasks;
using Azure.Storage.Blobs;
using Microsoft.Azure.Functions.Worker;
using Microsoft.DurableTask;

public record BlobReference(string Container, string BlobName);

public static class LargePayloadFunctions
{
    [Function("ProcessLargePayload")]
    public static async Task<BlobReference> RunOrchestrator(
        [OrchestrationTrigger] TaskOrchestrationContext context)
    {
        BlobReference inputReference = context.GetInput<BlobReference>()
            ?? throw new InvalidOperationException("A blob reference is required.");

        return await context.CallActivityAsync<BlobReference>(
            nameof(ProcessLargePayloadActivity), inputReference);
    }

    [Function(nameof(ProcessLargePayloadActivity))]
    public static async Task<BlobReference> ProcessLargePayloadActivity(
        [ActivityTrigger] BlobReference inputReference)
    {
        string connectionString =
            Environment.GetEnvironmentVariable("PAYLOAD_STORAGE_CONNECTION_STRING")
            ?? throw new InvalidOperationException("Payload storage is not configured.");
        BlobServiceClient service = new BlobServiceClient(connectionString);

        BlobClient inputBlob = service
            .GetBlobContainerClient(inputReference.Container)
            .GetBlobClient(inputReference.BlobName);
        BinaryData inputData = (await inputBlob.DownloadContentAsync()).Value.Content;

        BlobContainerClient outputContainer =
            service.GetBlobContainerClient("processed-payloads");
        await outputContainer.CreateIfNotExistsAsync();

        string outputName = $"processed/{Guid.NewGuid():N}.json";
        await outputContainer.GetBlobClient(outputName)
            .UploadAsync(inputData, overwrite: true);

        return new BlobReference(outputContainer.Name, outputName);
    }
}

C# (InProc)

Tento příklad vyžaduje Azure. Storage.Blobs NuGet balíček.

using System;
using System.Threading.Tasks;
using Azure.Storage.Blobs;
using Microsoft.Azure.WebJobs;
using Microsoft.Azure.WebJobs.Extensions.DurableTask;

public class BlobReference
{
    public string Container { get; set; } = string.Empty;
    public string BlobName { get; set; } = string.Empty;
}

public static class LargePayloadFunctions
{
    [FunctionName("ProcessLargePayload")]
    public static async Task<BlobReference> RunOrchestrator(
        [OrchestrationTrigger] IDurableOrchestrationContext context)
    {
        BlobReference inputReference = context.GetInput<BlobReference>()
            ?? throw new InvalidOperationException("A blob reference is required.");

        return await context.CallActivityAsync<BlobReference>(
            "ProcessLargePayloadActivity", inputReference);
    }

    [FunctionName("ProcessLargePayloadActivity")]
    public static async Task<BlobReference> RunActivity(
        [ActivityTrigger] BlobReference inputReference)
    {
        string connectionString =
            Environment.GetEnvironmentVariable("PAYLOAD_STORAGE_CONNECTION_STRING")
            ?? throw new InvalidOperationException("Payload storage is not configured.");
        BlobServiceClient service = new BlobServiceClient(connectionString);

        BlobClient inputBlob = service
            .GetBlobContainerClient(inputReference.Container)
            .GetBlobClient(inputReference.BlobName);
        BinaryData inputData = (await inputBlob.DownloadContentAsync()).Value.Content;

        BlobContainerClient outputContainer =
            service.GetBlobContainerClient("processed-payloads");
        await outputContainer.CreateIfNotExistsAsync();

        string outputName = $"processed/{Guid.NewGuid():N}.json";
        await outputContainer.GetBlobClient(outputName)
            .UploadAsync(inputData, overwrite: true);

        return new BlobReference
        {
            Container = outputContainer.Name,
            BlobName = outputName,
        };
    }
}

JavaScript

Tento příklad vyžaduje balíček npm @azure/storage-blob .

const { randomUUID } = require("crypto");
const { BlobServiceClient } = require("@azure/storage-blob");
const df = require("durable-functions");

df.app.orchestration("processLargePayload", function* (context) {
    const inputReference = context.df.getInput();
    return yield context.df.callActivity(
        "processLargePayloadActivity", inputReference);
});

df.app.activity("processLargePayloadActivity", {
    handler: async (inputReference) => {
        const connectionString =
            process.env.PAYLOAD_STORAGE_CONNECTION_STRING;
        if (!connectionString) {
            throw new Error(
                "PAYLOAD_STORAGE_CONNECTION_STRING is not set.");
        }

        const service = BlobServiceClient.fromConnectionString(
            connectionString);

        const inputBlob = service
            .getContainerClient(inputReference.container)
            .getBlockBlobClient(inputReference.blobName);
        const inputData = await inputBlob.downloadToBuffer();

        const outputContainer =
            service.getContainerClient("processed-payloads");
        await outputContainer.createIfNotExists();

        const outputName = `processed/${randomUUID()}.json`;
        await outputContainer.getBlockBlobClient(outputName)
            .uploadData(inputData);

        return {
            container: outputContainer.containerName,
            blobName: outputName,
        };
    },
});

Python

Tento příklad vyžaduje balíček azure-storage-blob . Přidejte to do requirements.txt.

import os
import uuid

import azure.functions as func
import azure.durable_functions as df
from azure.core.exceptions import ResourceExistsError
from azure.storage.blob import BlobServiceClient

app = df.DFApp(http_auth_level=func.AuthLevel.ANONYMOUS)


@app.orchestration_trigger(context_name="context")
def process_large_payload(context: df.DurableOrchestrationContext):
    input_reference: dict = context.get_input()
    return (yield context.call_activity(
        "process_large_payload_activity", input_reference))


@app.activity_trigger(input_name="input_reference")
def process_large_payload_activity(input_reference: dict) -> dict:
    connection_string = os.getenv("PAYLOAD_STORAGE_CONNECTION_STRING")
    if not connection_string:
        raise ValueError(
            "PAYLOAD_STORAGE_CONNECTION_STRING is not set.")

    service = BlobServiceClient.from_connection_string(connection_string)

    input_blob = service.get_blob_client(
        container=input_reference["container"],
        blob=input_reference["blobName"])
    input_data = input_blob.download_blob().readall()

    output_container = service.get_container_client("processed-payloads")
    try:
        output_container.create_container()
    except ResourceExistsError:
        pass

    output_name = f"processed/{uuid.uuid4()}.json"
    output_container.upload_blob(
        name=output_name, data=input_data, overwrite=True)

    return {
        "container": output_container.container_name,
        "blobName": output_name,
    }

PowerShell

Tento příklad vyžaduje modul Az.Storage . Přidejte to do requirements.psd1 a ujistěte se, že spravované závislosti jsou povoleny v host.json.

Orchestrátor run.ps1:

param($Context)

$OutputReference = Invoke-DurableActivity `
    -FunctionName 'ProcessLargePayloadActivity' `
    -Input $Context.Input

return $OutputReference

Aktivita run.ps1:

param($InputReference)

if ([string]::IsNullOrEmpty(
        $env:PAYLOAD_STORAGE_CONNECTION_STRING)) {
    throw 'The PAYLOAD_STORAGE_CONNECTION_STRING app setting is not configured.'
}

$StorageContext = New-AzStorageContext `
    -ConnectionString $env:PAYLOAD_STORAGE_CONNECTION_STRING
$InputFile = New-TemporaryFile

try {
    Get-AzStorageBlobContent `
        -Container $InputReference.container `
        -Blob $InputReference.blobName `
        -Destination $InputFile.FullName `
        -Context $StorageContext `
        -Force | Out-Null

    # Process $InputFile here. This example uploads it unchanged.
    $OutputContainer = 'processed-payloads'
    New-AzStorageContainer `
        -Name $OutputContainer `
        -Context $StorageContext `
        -ErrorAction SilentlyContinue | Out-Null

    $OutputName = "processed/$([guid]::NewGuid()).json"
    Set-AzStorageBlobContent `
        -File $InputFile.FullName `
        -Container $OutputContainer `
        -Blob $OutputName `
        -Context $StorageContext `
        -Force | Out-Null

    return @{
        container = $OutputContainer
        blobName = $OutputName
    }
}
finally {
    Remove-Item $InputFile.FullName -Force
}

Používejte standardní orchestrationTrigger a activityTrigger vazby popsané v Durable Functions bindings.

Java

Tento příklad vyžaduje balíčky com.azure:azure-storage-blob a com.microsoft:durabletask-azure-functions Maven.

import com.azure.core.util.BinaryData;
import com.azure.storage.blob.BlobContainerClient;
import com.azure.storage.blob.BlobServiceClient;
import com.azure.storage.blob.BlobServiceClientBuilder;
import com.microsoft.azure.functions.annotation.FunctionName;
import com.microsoft.durabletask.TaskOrchestrationContext;
import com.microsoft.durabletask.azurefunctions.DurableActivityTrigger;
import com.microsoft.durabletask.azurefunctions.DurableOrchestrationTrigger;

import java.util.Objects;
import java.util.UUID;

public class LargePayloadFunctions {
    public static class BlobReference {
        public String container;
        public String blobName;

        public BlobReference() {
        }

        public BlobReference(String container, String blobName) {
            this.container = container;
            this.blobName = blobName;
        }
    }

    @FunctionName("ProcessLargePayload")
    public BlobReference runOrchestrator(
            @DurableOrchestrationTrigger(name = "ctx")
            TaskOrchestrationContext ctx) {
        BlobReference inputReference = Objects.requireNonNull(
            ctx.getInput(BlobReference.class),
            "A blob reference is required.");
        return ctx.callActivity(
            "ProcessLargePayloadActivity",
            inputReference,
            BlobReference.class).await();
    }

    @FunctionName("ProcessLargePayloadActivity")
    public BlobReference runActivity(
            @DurableActivityTrigger(name = "inputReference")
            BlobReference inputReference) {
        String connectionString = Objects.requireNonNull(
            System.getenv("PAYLOAD_STORAGE_CONNECTION_STRING"),
            "PAYLOAD_STORAGE_CONNECTION_STRING is not configured.");
        BlobServiceClient service = new BlobServiceClientBuilder()
            .connectionString(connectionString)
            .buildClient();

        BinaryData inputData = service
            .getBlobContainerClient(inputReference.container)
            .getBlobClient(inputReference.blobName)
            .downloadContent();

        BlobContainerClient outputContainer =
            service.getBlobContainerClient("processed-payloads");
        outputContainer.createIfNotExists();

        String outputName =
            "processed/" + UUID.randomUUID() + ".json";
        outputContainer.getBlobClient(outputName)
            .upload(inputData, true);

        return new BlobReference(
            outputContainer.getBlobContainerName(), outputName);
    }
}

Pokud paralelní aktivity přinášejí více velkých výsledků, vraťte seznam odkazů a tento seznam předejte konečné agregační aktivitě. Agregační aktivita by měla načíst a sloučit užitečné zatížení a poté napsat jeden finální výstupní blob. Nenačítej ani nespojuj velké výsledky v orchestrátoru.

Práce s citlivými daty

Vstupy a výstupy (včetně výjimek) do a z rozhraní API Durable Functions jsou trvale uloženy u vašeho poskytovatele úložiště dle výběru. Pokud tyto vstupy, výstupy nebo výjimky obsahují citlivá data (například tajné kódy, připojovací řetězce nebo identifikovatelné osobní údaje), může je získat kdokoli s přístupem ke čtení k prostředkům poskytovatele úložiště.

Pokud chcete bezpečně zpracovávat citlivá data, načtěte tato data pomocí funkcí aktivity z Azure Key Vault nebo proměnných prostředí a nikdy tato data přímo neposílejte orchestrátorům ani entitám. Tento přístup pomáhá zabránit úniku citlivých dat do prostředků úložiště.

Podobně musí být oprávnění k zápisu do prostředků úložiště striktně kontrolováno, protože pozměněná data v úložišti by mohla změnit chování orchestrace. Další informace o zabezpečení úložiště centra úloh najdete v tématu Zabezpečení úložiště centra úloh.

Tip

Tyto pokyny platí také pro rozhraní API orchestrátoru CallHttp , které uchovává datové části požadavků a odpovědí v úložišti. Pokud vaše cílové koncové body HTTP vyžadují ověřování, implementujte volání HTTP uvnitř aktivity nebo použijte podporu předdefinované spravované identity nabízené metodou CallHttp, která neuchovává přihlašovací údaje do úložiště.

Note

Vyhněte se protokolování dat obsahujících tajné kódy jako kdokoli, kdo má ke svým protokolům přístup pro čtení (například v Application Insights), může tyto tajné kódy získat.

Šifrování v klidu

Při použití poskytovatele služby Azure Storage se všechna neaktivní uložená data automaticky šifrují. Každý, kdo má přístup k účtu úložiště, ale může číst data v nezašifrované podobě. Pokud potřebujete silnější ochranu citlivých dat, zvažte nejprve šifrování dat pomocí vlastních šifrovacích klíčů, aby se data zachovala v předšifrované podobě.

Alternativně .NET uživatelé mají možnost implementovat vlastní zprostředkovatele serializace, kteří poskytují automatické šifrování. Příklad vlastní serializace s šifrováním najdete v ukázce na GitHubu.

Note

Pokud se rozhodnete implementovat šifrování na úrovni aplikace, mějte na paměti, že orchestrace a entity mohou existovat po neomezenou dobu. Záleží na tom, když nastane čas pro rotaci šifrovacích klíčů, protože entity nebo orchestrace můžou běžet déle než vaše zásady rotace klíčů. Pokud k obměně klíčů dojde, klíč použitý k šifrování dat už nemusí být k dispozici k jeho dešifrování při příštím spuštění orchestrace nebo entity. Vlastní šifrování se proto doporučuje jenom v případě, že se očekává, že se orchestrace a entity budou spouštět po relativně krátkou dobu.

Zabezpečení úložiště centra úloh

Úložný backend, který hostuje váš hub úloh, představuje kritickou hranici důvěry. Durable Task Framework důvěřuje datům, která čte z úložiště během přehrávání orchestrace a zpracování zpráv. Každý, kdo má přístup k zápisu do úložiště centra úloh, může manipulovat se stavem orchestrace, čekajícími zprávami nebo uloženými datovými částmi. To může změnit chování aplikace, aktivovat nezamýšlené akce nebo dosáhnout vzdáleného spuštění kódu v kontextu vaší aplikace funkcí.

Important

Nezpřístupňujte přihlašovací údaje k úložišti centra úloh ani neudělujte přístup k zápisu nedůvěryhodným stranám. Přístup k zápisu do úložiště centra úloh lze použít ke změně chování aplikace, včetně aktivace libovolného spuštění kódu.

Společná odpovědnost

Zabezpečení back-endu úložiště je vaše odpovědnost, stejně jako zabezpečení jakékoli databáze, která ukládá stav aplikace nebo kód. Durable Task Framework neprovádí ověřování integrity uložených dat, takže spoléhá na řízení přístupu vrstvy úložiště, aby se zabránilo neoprávněným úpravám.

Backend	Bezpečnostní odpovědnost	Guidance
Plánovač úloh Durable	Microsoft spravuje základní úložiště. Spravujete identity, přístup k task hubům a zabezpečení na úrovni aplikací.	Preferovaný výchozí režim pro nové aplikace Durable Functions.
Azure Storage a další poskytovatelé BYO	Spravujete účet úložiště nebo databázi a její bezpečnostní kontroly.	Dobře se hodí pro stávající pracovní zátěže nebo nasazení, která už závisí na Azure Storage.

Note

Nesdílejte jedno centrum úloh mezi nedůvěryhodnými tenanty. Centrum úloh nevynucuje hranice přístupu mezi svými uživateli, takže každý tenant, který může číst nebo zapisovat do centra úloh, může ovlivnit všechny orchestrace a entity v něm. Podobně nespoléhejte na samostatná centra úloh ve stejném back-endu jako hranice zabezpečení. Zatímco Durable Task Scheduler podporuje řízení přístupu na základě rolí omezené na jednotlivá centra úloh, síťová omezení, jako jsou seznamy povolených IP adres a privátní koncové body, se uplatňují pouze na úrovni plánovače, takže centra úloh v rámci plánovače nepředstavují hranici bezpečnostní izolace. Totéž platí pro poskytovatele úložiště BYO – každý klient s přístupem k účtu úložiště nebo databázi může přistupovat ke všem centrům úloh v daném backendu. Pokud potřebujete izolaci zabezpečení mezi tenanty, zřiďte pro každého tenanta samostatnou infrastrukturu: samostatné účty úložiště nebo databáze pro poskytovatele BYO nebo samostatné instance Plánovače úloh Durable.

Kontrolní seznam pro posílení zabezpečení úložiště

Při ochraně úložiště centra úloh použijte následující osvědčené postupy:

• Pro backend, který si vyberete, používejte připojení založená na identitě.

  • S Durable Task Scheduler využívejte spravované identity a RBAC pro plánovač a centra úloh.
  • U Azure Storage a dalších BYO poskytovatelů preferujte, pokud je to možné, spravovanou identitu před spojovacími řetězci.

  Viz Konfigurování spravované identity pro Durable Functions.

• Použijte role RBAC s minimálními oprávněními Udělujte pouze nezbytně nutná oprávnění. Vyhněte se širokému přístupu k úložišti uživatelům nebo službám, které ho nepotřebují.

• Omezte přístup k síti k vašemu úložnému účtu nebo nasazení plánovačů pomocí soukromých koncových bodů nebo servisních koncových bodů. Toto omezení pomáhá zabránit neoprávněnému přístupu na úrovni sítě k datům z task hubu.

• Monitorujte přístup k úložišti povolením protokolování prostředků Azure Monitor pro svůj účet úložiště, zejména kategorie protokolů StorageWrite. Směrujte tyto protokoly do cíle mimo monitorovaný účet úložiště, například Log Analytics, aby se s těmito protokoly nešlo manipulovat. Viz protokoly úložiště.

• Pravidelně obměňujte přihlašovací údaje , pokud používáte připojovací řetězce. Zacházejte s klíči účtu úložiště se stejnou opatrností jako s jinými přihlašovacími údaji s vysokými oprávněními.

• Zvažte back-end spravovaného úložiště. Durable Task Scheduler automaticky zajišťuje bezpečnost úložiště, včetně autentizace, RBAC a izolace sítě, zatímco Azure Storage nabízí explicitní kontrolu úložiště.

Přizpůsobení serializace a deserializace

Možnosti přizpůsobení serializace se liší podle jazyka. Výběrem karty jazyka zobrazíte dostupné možnosti.

C# (Samostatný)

Izolované prostředí .NET a System.Text.Json

Durable Functions spuštěné v procesu .NET Isolated worker process používají stejný serializátor objektů, který je globálně nakonfigurovaný pro vaši aplikaci Azure Functions (viz WorkerOptions). Tento serializátor je ve výchozím nastavení System.Text.Json, nikoli Newtonsoft.Json. Veškeré změny v WorkerOptions.Serializer se nepřímo vztahují i na Durable Functions.

Další informace o integrované podpoře serializace JSON v .NET naleznete v JSON serializace a deserializace v .NET přehledové dokumentaci.

C# (InProc)

Výchozí logika serializace

Durable Functions pro .NET používá interně Json.NET k serializaci dat orchestrace a entit do JSON. Výchozí Json.NET nastavení jsou:

Vstupy, výstupy a stav:

JsonSerializerSettings
{
    TypeNameHandling = TypeNameHandling.None,
    DateParseHandling = DateParseHandling.None,
}

Výjimky:

JsonSerializerSettings
{
    ContractResolver = new ExceptionResolver(),
    TypeNameHandling = TypeNameHandling.Objects,
    ReferenceLoopHandling = ReferenceLoopHandling.Ignore,
}

Podrobnější dokumentaci JsonSerializerSettingsnajdete tady.

Přizpůsobení serializace pomocí atributů .NET

Během serializace Json.NET hledá různé atributy na třídách a vlastnostech, které určují, jak jsou data serializována a deserializována z JSON. Pokud vlastníte zdrojový kód pro datový typ předaný rozhraním API Durable Functions, zvažte přidání těchto atributů do typu pro přizpůsobení serializace a deserializace.

Jak přizpůsobit serializaci pomocí vkládání závislostí

Aplikace funkcí, které cílí na .NET a běží v modulu runtime Functions V3, můžou používat Dependency Injection (DI) k přizpůsobení způsobu serializace dat a výjimek. Následující ukázkový kód ukazuje, jak pomocí DI přepsat výchozí nastavení json.NET serializace pomocí vlastních implementací rozhraní služby IMessageSerializerSettingsFactory a IErrorSerializerSettingsFactory.

using Microsoft.Azure.Functions.Extensions.DependencyInjection;
using Microsoft.Azure.WebJobs.Extensions.DurableTask;
using Microsoft.Extensions.DependencyInjection;
using Newtonsoft.Json;
using System.Collections.Generic;

[assembly: FunctionsStartup(typeof(MyApplication.Startup))]
namespace MyApplication
{
    public class Startup : FunctionsStartup
    {
        public override void Configure(IFunctionsHostBuilder builder)
        {
            builder.Services.AddSingleton<IMessageSerializerSettingsFactory, CustomMessageSerializerSettingsFactory>();
            builder.Services.AddSingleton<IErrorSerializerSettingsFactory, CustomErrorSerializerSettingsFactory>();
        }

        /// <summary>
        /// A factory that provides the serialization for all inputs and outputs for activities and
        /// orchestrations, as well as entity state.
        /// </summary>
        internal class CustomMessageSerializerSettingsFactory : IMessageSerializerSettingsFactory
        {
            public JsonSerializerSettings CreateJsonSerializerSettings()
            {
                // Return your custom JsonSerializerSettings here
            }
        }

        /// <summary>
        /// A factory that provides the serialization for all exceptions thrown by activities
        /// and orchestrations
        /// </summary>
        internal class CustomErrorSerializerSettingsFactory : IErrorSerializerSettingsFactory
        {
            public JsonSerializerSettings CreateJsonSerializerSettings()
            {
                // Return your custom JsonSerializerSettings here
            }
        }
    }
}

JavaScript

Logika serializace a deserializace

Aplikace Node v Azure Functions používají JSON.stringify() pro serializaci a JSON.Parse() pro deserializaci. Většina typů by měla bez problémů serializovat a deserializovat. V případech, kdy výchozí logika není dostatečná, definování toJSON() metody na objektu přepíše logiku serializace. Pro deserializaci objektů však neexistuje žádný analog.

Pro úplné přizpůsobení serializace/deserializačního kanálu zvažte zpracování serializace a deserializace vlastním kódem a předávání dat jako řetězců.

PowerShell

Logika serializace a deserializace

Aplikace Durable Functions v PowerShellu používají výchozí zpracování JSON v PowerShellu pro datové části orchestrace a aktivit. Ve většině případů se obyčejné objekty kompatibilní s JSON serializují a deserializují správně bez nutnosti dodatečné konfigurace.

Pokud potřebujete vlastní chování pro tvar payloadu, serializujte nebo deserializujte data sami ve svých funkcích a výsledné hodnoty kompatibilní s JSON předávajte mezi orchestratory, aktivitami a entitami. Tento přístup udržuje datový formát explicitní a vyhýbá se závislosti na API pro přizpůsobení serializátoru, které není pro PowerShell přístupné.

Pro složitější scénáře zvažte reprezentaci dat jako jednoduchých řetězců, polí nebo hashovacích tabulek a převod mezi formáty uvnitř funkčního kódu.

Python

Logika serializace a deserializace

Aby bylo zajištěno, že Durable Functions správně serializuje a deserializuje vaše data, doporučuje se používat typové anotace. Přestože je mnoho předdefinovaných typů zpracováváno automaticky, některé předdefinované datové typy vyžadují anotace typů, aby se typ zachoval během deserializace.

Pro vlastní datové typy umožníte serializaci a deserializaci JSON definováním metod to_json a from_json ve třídě vašeho datového typu. Všimněte si, že tyto metody nejsou volána na návratovou hodnotu z funkce orchestrátoru, což znamená, že návratová hodnota musí být nativně serializovatelná ve formátu JSON. Další informace naleznete v tématu Vazby.

Pokud chcete ověřit deserializované payloady podle očekávaného typu a volitelně zapnout striktní režim se zvýšeným zabezpečením, viz Migrate to type-safe serialization in Durable Functions for Python.

Java

Java používá knihovny Jackson v2.x pro serializaci a deserializaci datových částí. K přizpůsobení chování serializace můžete použít jacksonové poznámky na typech POJO.

Další kroky

• centra úloh v Durable Functions
• poskytovatelé úložiště Durable Functions
• Durable Functions vazby