Szybki start: Użyj filtrowania zadań z SDK Durable Task

Wymagania wstępne

Przed rozpoczęciem:

• Zainstaluj zestaw .NET 10 SDK lub nowszy.
• Zainstaluj platformę Docker na potrzeby uruchamiania emulatora.
• Zainstaluj interfejs wiersza polecenia dla deweloperów platformy Azure.
• Klonuj repozytorium Durable Task Scheduler z GitHub.

Przygotowywanie projektu

Azure-Samples/Durable-Task-Scheduler W katalogu głównym przejdź do przykładowego katalogu:

cd samples/scenarios/WorkItemFilteringSplitActivities

Uruchamianie lokalnie za pomocą emulatora

1. Ściąganie obrazu emulatora:

   docker pull mcr.microsoft.com/durable-task/emulator:latest
   

2. Uruchom emulator:

   docker run -d --name dts-emulator -p 8080:8080 -p 8082:8082 mcr.microsoft.com/durable-task/emulator:latest
   

3. Skompiluj przykład:

   dotnet build
   

4. Uruchom każdego worker'a w osobnym terminalu:

   Terminal 1 — proces roboczy programu Orchestrator

   dotnet run --project src/OrchestratorWorker
   

   Terminal 2 — pracownik walidacji

   dotnet run --project src/ValidatorWorker
   

   Terminal 3 — pracownik nadawcy

   dotnet run --project src/ShipperWorker
   

5. W czwartym terminalu uruchom klienta:

   dotnet run --project src/Client
   

6. Otwórz pulpit nawigacyjny emulatora pod adresem , http://localhost:8082 aby monitorować aktywność orkiestracji.

./run-local.sh

Oczekiwane dane wyjściowe z filtrowania elementów roboczych

Klient planuje uruchomienie zestawu trzech orkiestracji co 30 sekund i powtarza ten proces przez około 10 minut. Na wszystkich terminalach widzisz:

• Klient planuje partie orkiestracji i czeka na zakończenie każdej partii. Ukończona partia rejestruje 3 completed, 0 failed.
• Proces roboczy programu Orchestrator wysyła wywołania działań ValidateOrder i ShipOrder.
• Pracownik Validatora obsługuje wyłącznie ValidateOrder zadania związane z aktywnością.
• Pracownik Transportera zajmuje się wyłącznie ShipOrder zadaniami dotyczącymi czynności.

To zachowanie potwierdza, że filtrowanie elementów roboczych kieruje elementy tylko do pracowników, którzy zarejestrowali pasujące typy zadań.

Gdy zobaczysz przynajmniej jeden raport 3 completed, 0 failedpartii, próbka działa zgodnie z oczekiwaniami. Nie musisz czekać na zakończenie pełnej pętli – naciśnij Ctrl+C w każdym terminalu, aby zatrzymać klienta i pracowników. Jeśli pozwolisz klientowi działać do końca, wyświetli końcowe podsumowanie wyników, a następnie pozostanie uruchomiony, dopóki nie zatrzymasz go za pomocą Ctrl+C.

Wypróbuj: eksperyment dotyczący routingu ścisłego

Aby zobaczyć, że routing jest rygorystyczny (brak powrotu do innych procesów roboczych):

1. Zatrzymaj proces Shipper worker (Ctrl+C w terminalu 3).
2. Uruchom ponownie klienta, aby zaplanować nowe aranżacje.
3. Zwróć uwagę, że:
   • Proces roboczy programu Orchestrator pobiera i uruchamia aranżacje.
   • Pracownik walidacji uzupełnia ValidateOrder dla każdego zamówienia.
   • ShipOrder zadania pozostają w trakcie oczekiwania – pracownicy Validatora i Orchestratora ich nie otrzymują.
   • Orkiestracje pozostają w statusie "Działa", czekając na ShipOrder zakończenie.
4. Uruchom ponownie proces roboczy Shipper — oczekujące ShipOrder elementy pracy są dostarczane natychmiast, a orkiestracje zostają ukończone.

Ten eksperyment pokazuje, że zadania są kierowane tylko do pracowników z pasującymi filtrami. Nie ma żadnej alternatywy.

Wdrażanie przy użyciu interfejsu wiersza polecenia dla deweloperów platformy Azure

1. Uwierzytelnianie przy użyciu Azure (jeśli jeszcze tego nie zrobiono):

   azd auth login
   

2. Z samples/scenarios/WorkItemFilteringSplitActivities uruchom polecenie:

   azd up
   

3. Po wyświetleniu monitu w terminalu podaj następujące parametry:

   Parameter	Opis
   Nazwa środowiska	Prefiks grupy zasobów utworzony do przechowywania wszystkich zasobów platformy Azure.
   Lokalizacja platformy Azure	Lokalizacja Azure dla Twoich zasobów.
   Subskrypcja platformy Azure	Subskrypcja platformy Azure dla twoich zasobów.

Polecenie azd up aprowizuje zasoby platformy Azure i wdraża cztery konteneryzowane usługi z tej próbki: klient, pracownik orkiestratora, pracownik weryfikatora i pracownik wysyłki.

Potwierdzanie pomyślnego wdrożenia

1. W danych wyjściowych azd up skopiuj nazwę grupy zasobów.

2. W witrynie Azure Portal otwórz grupę zasobów.

3. Dla każdej wdrożonej aplikacji kontenera (client, orchestrator-worker, validator-worker, shipper-worker), otwórz Monitorowanie>przepływ dziennika.

4. Sprawdź, czy każda aplikacja rejestruje tylko oczekiwane elementy robocze:

   • orchestrator-worker: proces orkiestracji.
   • validator-worker: ValidateOrder działanie.
   • shipper-worker: ShipOrder działanie.

Zrozum kod filtrowania zadań w C #

Orkiestracja wywołuje dwie aktywności jedna po drugiej. Planista kieruje każdy element roboczy procesu do pracownika, który go zarejestrował.

public override async Task<string> RunAsync(TaskOrchestrationContext context, string orderId)
{
    string validationResult = await context.CallActivityAsync<string>("ValidateOrder", orderId);
    string shippingResult = await context.CallActivityAsync<string>("ShipOrder", orderId);

    return $"Order '{orderId}' => Validation: [{validationResult}], Shipping: [{shippingResult}]";
}

Każdy pracownik rejestruje tylko swoje zadania lokalne. SDK automatycznie generuje filtry elementów roboczych na podstawie rejestru zadań, więc nie musisz jawnie włączać tej funkcji.

builder.Services.AddDurableTaskWorker()
    .AddTasks(registry =>
    {
        // Only this worker's tasks are registered.
        // Work item filters are auto-generated from the registry, so this
        // worker only receives matching work items.
        registry.AddAllGeneratedTasks();
    })
    .UseDurableTaskScheduler(connectionString);

Przykład:

• OrchestratorWorkerrejestrujeOrderProcessingOrchestration.
• ValidatorWorkerrejestrujeValidateOrder.
• ShipperWorkerrejestrujeShipOrder.

Gdy pracownik nawiązuje połączenie z usługą Durable Task Scheduler, zestaw SDK wysyła listę filtrów. Planista tworzy kolejki przypisane do filtru i przekierowuje każde zadanie robocze do odpowiedniej kolejki. Pracownicy nigdy nie otrzymują typów elementów roboczych, których nie zarejestrowali.

Uprzątnij zasoby

1. Zatrzymaj lokalny kontener emulatora.

   docker rm -f dts-emulator
   

2. Jeśli wdrożono na platformie Azure, zidentyfikuj nazwę grupy zasobów:

   • Skopiuj je z outputu azd up.
   • Możesz także użyć globalnego pola wyszukiwania w portalu Azure u góry i wyszukać prefiks nazwy środowiska lub jego nazwę.

3. Otwórz grupę zasobów z wyników wyszukiwania.

4. Wybierz pozycję Usuń grupę zasobów, wprowadź nazwę grupy zasobów, aby potwierdzić, a następnie wybierz pozycję Usuń.

Następne kroki

• Dowiedz się więcej o automatycznym skalowaniu harmonogramu zadań Durable Task Scheduler w usłudze Azure Container Apps.
• Zapoznaj się ze wskazówkami dotyczącymi rozwiązywania problemów.

Wymagania wstępne

Przed rozpoczęciem:

• Java 21 lub nowsza.
• Docker do uruchamiania emulatora.
• Azure Developer CLI
• Klonuj repozytorium Durable Task Scheduler z GitHub.

Przygotowywanie projektu

Z katalogu Azure-Samples/Durable-Task-Scheduler głównego przejdź do przykładowego katalogu:

cd samples/scenarios/WorkItemFilteringSplitActivitiesJava

Uruchamianie lokalnie za pomocą emulatora

1. Pobierz obraz emulatora.

   docker pull mcr.microsoft.com/dts/dts-emulator:latest
   

2. Uruchom emulator.

   docker run -d --name dts-emulator -p 8080:8080 -p 8082:8082 mcr.microsoft.com/dts/dts-emulator:latest
   

3. Skompiluj przykład.

   ./gradlew build
   

4. Uruchom każdego worker'a w osobnym terminalu:

   Terminal 1 — proces roboczy programu Orchestrator

   ./gradlew :orchestrator-worker:run
   

   Terminal 2 — pracownik walidacji

   ./gradlew :validator-worker:run
   

   Terminal 3 — pracownik nadawcy

   ./gradlew :shipper-worker:run
   

5. W czwartym terminalu uruchom klienta.

   ./gradlew :client:run
   

6. Otwórz pulpit nawigacyjny emulatora pod adresem , http://localhost:8082 aby monitorować aktywność orkiestracji.

Oczekiwane dane wyjściowe z filtrowania elementów roboczych

Klient planuje uruchomienie zestawu trzech orkiestracji co 30 sekund i powtarza ten proces przez około 10 minut. Na wszystkich terminalach widzisz:

• Klient planuje partie orkiestracji i czeka na zakończenie każdej partii. Ukończona partia rejestruje 3 completed, 0 failed.
• Proces roboczy programu Orchestrator wysyła wywołania działań ValidateOrder i ShipOrder.
• Pracownik Validatora obsługuje wyłącznie ValidateOrder zadania związane z aktywnością.
• Pracownik Transportera zajmuje się wyłącznie ShipOrder zadaniami dotyczącymi czynności.

To zachowanie potwierdza, że filtrowanie elementów roboczych kieruje elementy tylko do pracowników, którzy zarejestrowali pasujące typy zadań.

Gdy zobaczysz przynajmniej jeden raport 3 completed, 0 failedpartii, próbka działa zgodnie z oczekiwaniami. Nie musisz czekać na zakończenie pełnej pętli – naciśnij Ctrl+C w każdym terminalu, aby zatrzymać klienta i pracowników. Jeśli pozwolisz klientowi działać do końca, wyświetli końcowe podsumowanie wyników, a następnie pozostanie uruchomiony, dopóki nie zatrzymasz go za pomocą Ctrl+C.

Wypróbuj: eksperyment dotyczący routingu ścisłego

Aby zobaczyć, że routing jest rygorystyczny (brak powrotu do innych procesów roboczych):

1. Zatrzymaj proces Shipper worker (Ctrl+C w terminalu 3).
2. Uruchom ponownie klienta, aby zaplanować nowe aranżacje.
3. Zwróć uwagę, że:
   • Proces roboczy programu Orchestrator pobiera i uruchamia aranżacje.
   • Pracownik walidacji uzupełnia ValidateOrder dla każdego zamówienia.
   • ShipOrder zadania pozostają w trakcie oczekiwania – pracownicy Validatora i Orchestratora ich nie otrzymują.
   • Orkiestracje pozostają w statusie "Działa", czekając na ShipOrder zakończenie.
4. Uruchom ponownie proces roboczy Shipper — oczekujące ShipOrder elementy pracy są dostarczane natychmiast, a orkiestracje zostają ukończone.

Ten eksperyment pokazuje, że zadania są kierowane tylko do pracowników z pasującymi filtrami. Nie ma żadnej alternatywy.

Wdrażanie przy użyciu interfejsu wiersza polecenia dla deweloperów platformy Azure

1. Uwierzytelnianie przy użyciu Azure (jeśli jeszcze tego nie zrobiono):

   azd auth login
   

2. Z samples/scenarios/WorkItemFilteringSplitActivitiesJava uruchom polecenie:

   azd up
   

3. Po wyświetleniu monitu w terminalu podaj następujące parametry:

   Parameter	Opis
   Nazwa środowiska	Prefiks grupy zasobów utworzony do przechowywania wszystkich zasobów platformy Azure.
   Lokalizacja platformy Azure	Lokalizacja Azure dla Twoich zasobów.
   Subskrypcja platformy Azure	Subskrypcja platformy Azure dla twoich zasobów.

Polecenie azd up aprowizuje zasoby platformy Azure i wdraża cztery konteneryzowane usługi z tej próbki: klient, pracownik orkiestratora, pracownik weryfikatora i pracownik wysyłki.

Potwierdzanie pomyślnego wdrożenia

1. W danych wyjściowych azd up skopiuj nazwę grupy zasobów.

2. W witrynie Azure Portal otwórz grupę zasobów.

3. Dla każdej wdrożonej aplikacji kontenera (client, orchestrator-worker, validator-worker, shipper-worker), otwórz Monitorowanie>przepływ dziennika.

4. Sprawdź, czy każda aplikacja rejestruje tylko oczekiwane elementy robocze:

   • orchestrator-worker: proces orkiestracji.
   • validator-worker: ValidateOrder działanie.
   • shipper-worker: ShipOrder działanie.

Zrozum kod filtrowania zadań w Javi

Orkiestracja wywołuje dwie aktywności jedna po drugiej. Planista kieruje każdy element roboczy procesu do pracownika, który go zarejestrował.

String validationResult = ctx.callActivity("ValidateOrder", orderId, String.class).await();
String shippingResult = ctx.callActivity("ShipOrder", orderId, String.class).await();

String combined = String.format("Order '%s' => Validation: [%s], Shipping: [%s]",
        orderId, validationResult, shippingResult);
ctx.complete(combined);

Każdy komputer roboczy rejestruje jedynie swoje lokalne zadania i wywołuje useWorkItemFilters(), aby wyrazić zgodę na filtrowanie. Następnie zestaw SDK generuje filtry elementów roboczych z rejestru zadań.

DurableTaskGrpcWorker worker = DurableTaskSchedulerWorkerExtensions
        .createWorkerBuilder(connectionString)
        .addActivity(new TaskActivityFactory() {
            // ...
        })
        .useWorkItemFilters() // auto-generate from registered tasks
        .build();

Przykład:

• OrchestratorWorkerrejestrujeOrderProcessingOrchestration.
• ValidatorWorkerrejestrujeValidateOrder.
• ShipperWorkerrejestrujeShipOrder.

Gdy pracownik nawiązuje połączenie z usługą Durable Task Scheduler, zestaw SDK wysyła listę filtrów. Planista tworzy kolejki przypisane do filtru i przekierowuje każde zadanie robocze do odpowiedniej kolejki. Pracownicy nigdy nie otrzymują typów elementów roboczych, których nie zarejestrowali.

Aby podać jawnie określone filtry zamiast generować je automatycznie z rejestru, przekaż WorkItemFilter do useWorkItemFilters():

WorkItemFilter filter = WorkItemFilter.newBuilder()
        .addOrchestration("OrderProcessingOrchestration")
        .addActivity("ValidateOrder")
        .build();

builder.useWorkItemFilters(filter);

Uprzątnij zasoby

1. Zatrzymaj lokalny kontener emulatora.

   docker rm -f dts-emulator
   

2. Jeśli wdrożono na platformie Azure, zidentyfikuj nazwę grupy zasobów:

   • Skopiuj je z outputu azd up.
   • Możesz także użyć globalnego pola wyszukiwania w portalu Azure u góry i wyszukać prefiks nazwy środowiska lub jego nazwę.

3. Otwórz grupę zasobów z wyników wyszukiwania.

4. Wybierz pozycję Usuń grupę zasobów, wprowadź nazwę grupy zasobów, aby potwierdzić, a następnie wybierz pozycję Usuń.

Następne kroki

• Dowiedz się więcej o automatycznym skalowaniu harmonogramu zadań Durable Task Scheduler w usłudze Azure Container Apps.
• Zapoznaj się ze wskazówkami dotyczącymi rozwiązywania problemów.

Wymagania wstępne

Przed rozpoczęciem:

• Python 3.10 lub nowsza.
• Docker do uruchamiania emulatora.
• Azure CLI jeśli używasz wdrożonego harmonogramu Durable Task Scheduler.
• Klonuj repozytorium Durable Task Scheduler z GitHub.

Przygotowywanie projektu

Z katalogu Azure-Samples/Durable-Task-Scheduler głównego przejdź do przykładowego katalogu:

cd samples/durable-task-sdks/python/work-item-filtering

Uruchamianie lokalnie za pomocą emulatora

1. Pobierz obraz emulatora.

   docker pull mcr.microsoft.com/dts/dts-emulator:latest
   

2. Uruchom emulator.

   docker run -d --name dts-emulator -p 8080:8080 -p 8082:8082 mcr.microsoft.com/dts/dts-emulator:latest
   

   Próbka korzysta z domyślnych ustawień emulatora (endpoint http://localhost:8080 i task hub default), więc nie musisz ustawiać żadnych zmiennych środowiskowych.

3. (Opcjonalne) Stwórz i aktywuj środowisko wirtualne Python.

   python -m venv venv
   source venv/bin/activate  # On Windows, use: venv\Scripts\activate
   

4. Zainstaluj wymagane pakiety.

   pip install -r requirements.txt
   

5. Uruchom każdego worker'a w osobnym terminalu:

   Terminal 1 - Pracownik A (powitanie)

   python worker_a.py
   

   Terminal 2 - Pracownik B (matematyka)

   python worker_b.py
   

6. W trzecim terminalu uruchom klienta.

   python client.py
   

7. Otwórz pulpit nawigacyjny emulatora pod adresem , http://localhost:8082 aby monitorować aktywność orkiestracji.

Oczekiwane dane wyjściowe z filtrowania elementów roboczych

Klient planuje orkiestrację powitalną i matematyczną, a następnie czeka na zakończenie obu zadań. Na wszystkich terminalach widzisz:

• Pracownik A przetwarza jedynie orkiestrację powitania i jej say_hello aktywność.
• Pracownik B przetwarza jedynie orkiestrację matematyczną i jej add_numbers aktywność.
• Klient drukuje wynik z każdej orkiestracji.

To zachowanie potwierdza, że filtrowanie elementów roboczych kieruje elementy tylko do pracowników, którzy zarejestrowali pasujące typy zadań.

Zrozum kod filtrowania zadań w Pythonie

Każdy komputer roboczy rejestruje jedynie swoje lokalne zadania i wywołuje use_work_item_filters(), aby wyrazić zgodę na filtrowanie. SDK generuje filtry zadań z zarejestrowanych zadań.

worker.add_orchestrator(greeting_orchestrator)
worker.add_activity(say_hello)
worker.use_work_item_filters()  # Auto-generate from the registry

Przykład:

• Pracownik A rejestruje greeting_orchestrator i say_hello.
• Pracownik B rejestruje math_orchestrator i add_numbers.

Gdy pracownik nawiązuje połączenie z usługą Durable Task Scheduler, zestaw SDK wysyła listę filtrów. Planista tworzy kolejki przypisane do filtru i przekierowuje każde zadanie robocze do odpowiedniej kolejki. Pracownicy nigdy nie otrzymują typów elementów roboczych, których nie zarejestrowali.

Aby dostarczyć filtry jawne zamiast automatycznie generować je z rejestru, należy przejść WorkItemFilters:

from durabletask.worker import WorkItemFilters, OrchestrationWorkItemFilter, ActivityWorkItemFilter

worker.use_work_item_filters(WorkItemFilters(
    orchestrations=[
        OrchestrationWorkItemFilter(name="greeting_orchestrator"),
    ],
    activities=[
        ActivityWorkItemFilter(name="say_hello"),
    ],
))

Uprzątnij zasoby

Zatrzymaj lokalny kontener emulatora.

docker rm -f dts-emulator

Następne kroki

• Dowiedz się więcej o automatycznym skalowaniu harmonogramu zadań Durable Task Scheduler w usłudze Azure Container Apps.
• Zapoznaj się ze wskazówkami dotyczącymi rozwiązywania problemów.