Best Practices für Workflows

Sie können sich an den hier aufgeführten Best Practices orientieren, wenn Sie Ihre Dienste mit Workflows orchestrieren.

Diese Liste ist nicht vollständig und es werden auch nicht die Grundlagen der Verwendung von Workflows erläutert. In diesem Dokument wird davon ausgegangen, dass Sie bereits ein allgemeines Verständnis der Google Cloud Landschaft und von Workflows haben. Weitere Informationen finden Sie im Google Cloud Well-Architected Framework und in der Übersicht über Workflows.

Optimales Kommunikationsmuster auswählen

Beim Entwerfen einer Mikrodienste-Architektur für die Bereitstellung mehrerer Dienste können Sie aus den folgenden Kommunikationsmustern auswählen:

  • Direkte Dienst-zu-Dienst-Kommunikation

  • Indirekte ereignisgesteuerte Kommunikation (auch als Choreografie bezeichnet)

  • Automatisierte Konfiguration, Koordination und Verwaltung (auch als Orchestrierung bezeichnet)

Berücksichtigen Sie die Vor- und Nachteile der einzelnen Optionen und wählen Sie ein optimales Muster für Ihren Anwendungsfall aus. Die direkte Kommunikation zwischen Diensten ist beispielsweise möglicherweise einfacher zu implementieren als andere Optionen, aber sie führt zu einer engen Kopplung Ihrer Dienste. Bei einer ereignisgesteuerten Architektur können Sie Ihre Dienste dagegen lose koppeln. Das Monitoring und Debugging kann jedoch komplizierter sein. Schließlich können Sie mit einem zentralen Orchestrator wie Workflows die Kommunikation zwischen Diensten koordinieren, ohne dass die enge Kopplung der direkten Dienst-zu-Dienst-Kommunikation oder die Komplexität choreografierter Ereignisse erforderlich ist.

Sie können auch Kommunikationsmuster kombinieren. Bei der ereignisgesteuerten Orchestrierung werden beispielsweise eng verwandte Dienste in einer Orchestrierung verwaltet, die durch ein Ereignis ausgelöst wird. Sie können auch ein System entwerfen, in dem eine Orchestrierung zu einer Pub/Sub-Nachricht an ein anderes orchestriertes System führt.

Allgemeine Tipps

Wenn Sie sich für Workflows als Dienst-Orchestrator entschieden haben, sollten Sie die folgenden hilfreichen Tipps beachten.

Hartcodierung von URLs vermeiden

Sie können Workflows unterstützen, die in mehreren Umgebungen portierbar und einfacher zu verwalten sind, indem Sie hartcodierte URLs vermeiden. Das lässt sich auf folgende Weise erreichen:

  • Definieren Sie URLs als Laufzeitargumente.

    Das kann hilfreich sein, wenn Ihr Workflow über eine Clientbibliothek oder die API aufgerufen wird. Das funktioniert jedoch nicht, wenn Ihr Workflow durch ein Event von Eventarc ausgelöst wird und das einzige Argument, das übergeben werden kann, die Event-Nutzlast ist.

    Beispiel

    main:
  params: [args]
  steps:
    - init:
        assign:
          - url1: ${args.urls.url1}
          - url2: ${args.urls.url2}

    Wenn Sie den Workflow ausführen, können Sie die URLs angeben, z. B.:

    gcloud workflows run multi-env --data='{"urls":{"url1": "URL_ONE", "url2": "URL_TWO"}}'

  • Umgebungsvariablen verwenden und einen Workflow erstellen, der je nach Umgebung, in der er bereitgestellt wird, dynamisch konfiguriert wird. Alternativ können Sie einen Workflow erstellen, der als Vorlage wiederverwendet und gemäß separat verwalteten Umgebungsvariablen konfiguriert werden kann.

  • Verwenden Sie eine Substitutionstechnik, mit der Sie eine einzelne Workflow-Definitionsdatei erstellen, aber Varianten bereitstellen können. Dazu verwenden Sie ein Tool, das Platzhalter in Ihrem Workflow ersetzt. Sie können beispielsweise Cloud Build verwenden, um einen Workflow bereitzustellen, und in der Cloud Build-Konfigurationsdatei einen Schritt hinzufügen, um Platzhalter-URLs im Workflow zu ersetzen.

    Beispiel

    steps:
‐ id: 'replace-urls'
  name: 'gcr.io/cloud-builders/gcloud'
  entrypoint: bash
  args:
    - -c
    - |
      sed -i -e "s~REPLACE_url1~$_URL1~" workflow.yaml
      sed -i -e "s~REPLACE_url2~$_URL2~" workflow.yaml
‐ id: 'deploy-workflow'
  name: 'gcr.io/cloud-builders/gcloud'
  args: ['workflows', 'deploy', 'multi-env-$_ENV', '--source', 'workflow.yaml']

    Anschließend können Sie Variablenwerte zum Build-Zeitpunkt ersetzen. Beispiel:

    gcloud builds submit --config cloudbuild.yaml \
    --substitutions=_ENV=staging,_URL1="URL_ONE",_URL2="URL_TWO"

    Weitere Informationen finden Sie unter Build über die Befehlszeile und die API senden.

    Alternativ können Sie Terraform verwenden, um Ihre Infrastruktur bereitzustellen und eine Konfigurationsdatei zu definieren, die mit Eingabevariablen Workflows für jede Umgebung erstellt.

    Beispiel

    variable "project_id" {
  type = string
}

variable "url1" {
  type = string
}

variable "url2" {
  type = string
}

locals {
  env = ["staging", "prod"]
}

# Define and deploy staging and production workflows
resource "google_workflows_workflow" "multi-env-workflows" {
  for_each = toset(local.env)

  name            = "multi-env-${each.key}"
  project         = var.project_id
  region          = "us-central1"
  source_contents = templatefile("${path.module}/workflow.yaml", { url1 : "${var.url1}-${each.key}", url2 : "${var.url2}-${each.key}" })
}

    Wenn Variablen im Root-Modul Ihrer Konfiguration deklariert werden, können ihnen auf verschiedene Arten Werte zugewiesen werden. Beispiel:

    terraform apply -var="project_id=PROJECT_ID" -var="url1=URL_ONE" -var="url2=URL_TWO"

  • Secret Manager-Connector verwenden: Mit dem Secret Manager-Connector können Sie URLs sicher in Secret Manager speichern und abrufen.

Verschachtelte Schritte verwenden

Jeder Workflow muss mindestens einen Schritt haben. Standardmäßig werden Schritte in Workflows so behandelt, als ob sie in einer sortierten Liste enthalten sind. Sie werden einzeln ausgeführt, bis alle Schritte durchlaufen wurden. Logischerweise sollten einige Schritte gruppiert werden. Mit einem steps-Block können Sie eine Reihe von Schritten verschachteln. Das ist praktisch, da Sie so auf den richtigen atomaren Schritt verweisen können, um eine Reihe von Schritten zu verarbeiten.

Beispiel

main:
    params: [input]
    steps:
    - callWikipedia:
        steps:
        - checkSearchTermInInput:
            switch:
                - condition: ${"searchTerm" in input}
                  assign:
                    - searchTerm: ${input.searchTerm}
                  next: readWikipedia
        - getCurrentDate:
            call: http.get
            args:
                url: https://timeapi.io/api/Time/current/zone?timeZone=Europe/Amsterdam
            result: currentDate
        - setFromCallResult:
            assign:
                - searchTerm: ${currentDate.body.dayOfWeek}
        - readWikipedia:
            call: http.get
            args:
                url: https://en.wikipedia.org/w/api.php
                query:
                    action: opensearch
                    search: ${searchTerm}
            result: wikiResult
    - returnOutput:
            return: ${wikiResult.body[1]}

Ausdrücke umschließen

Alle Ausdrücke müssen mit einem $ beginnen und in geschweifte Klammern gesetzt werden:

${EXPRESSION}

Um Probleme beim Parsen von YAML zu vermeiden, können Sie Ausdrücke in Anführungszeichen setzen. Beispielsweise können Ausdrücke mit Doppelpunkten unerwartetes Verhalten verursachen, wenn der Doppelpunkt als Definition einer Zuordnung interpretiert wird. Sie können dieses Problem beheben, indem Sie den YAML-Ausdruck in einfache Anführungszeichen setzen:

'${"Name: " + myVar}'

Sie können auch Ausdrücke verwenden, die sich über mehrere Zeilen erstrecken. Beispielsweise müssen Sie möglicherweise eine SQL-Abfrage in Anführungszeichen setzen, wenn Sie den Workflows-BigQuery-Connector verwenden.

Beispiel

- runQuery:
    call: googleapis.bigquery.v2.jobs.query
    args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        body:
            useLegacySql: false
            useQueryCache: false
            timeoutMs: 30000
            # Find top 100 titles with most views on Wikipedia
            query: ${
                "SELECT TITLE, SUM(views)
                FROM `bigquery-samples.wikipedia_pageviews." + table + "`
                WHERE LENGTH(TITLE) > 10
                GROUP BY TITLE
                ORDER BY SUM(VIEWS) DESC
                LIMIT 100"
                }
    result: queryResult

Die vollständige Workflowdefinition finden Sie unter Mehrere BigQuery-Jobs parallel ausführen.

Deklarative Aufrufe verwenden

Mit Workflows können Sie Dienste über den Workflow selbst aufrufen und die Ergebnisse verarbeiten sowie einfache Aufgaben wie HTTP-Aufrufe ausführen. Workflows können Dienste aufrufen, Antworten parsen und Eingaben für andere verbundene Dienste erstellen. Durch den Aufruf eines Dienstes können Sie die Komplikationen zusätzlicher Aufrufe, zusätzlicher Abhängigkeiten und Dienste, die Dienste aufrufen, vermeiden. Ersetzen Sie Dienste, die keine Geschäftslogik enthalten, durch deklarative API-Aufrufe und verwenden Sie Workflows, um die Komplexität zu reduzieren.

Sie sollten jedoch Dienste erstellen, um alle Aufgaben auszuführen, die für Workflows zu komplex sind, z. B. die Implementierung von wiederverwendbarer Geschäftslogik, komplexen Berechnungen oder Transformationen, die von Workflows-Ausdrücken und der zugehörigen Standardbibliothek nicht unterstützt werden. Komplizierte Fälle lassen sich in der Regel einfacher im Code implementieren, anstatt YAML oder JSON und die Workflow-Syntax zu verwenden.

Nur das speichern, was Sie wirklich brauchen

Halten Sie den Arbeitsspeicherverbrauch im Rahmen, damit Sie nicht auf Ressourcenlimits oder einen Fehler stoßen, der darauf hinweist, z. B. ResourceLimitError, MemoryLimitExceededError oder ResultSizeLimitExceededError.

Speichern Sie nur die Daten, die Sie wirklich benötigen, in Variablen. Wenn ein Dienst eine zu große Nutzlast zurückgibt, verwenden Sie eine separate Funktion, um den Aufruf für Sie auszuführen und nur das zurückzugeben, was erforderlich ist.

Sie können Speicherplatz freigeben, indem Sie Variablen löschen. Möglicherweise möchten Sie beispielsweise Speicherplatz freigeben, der für nachfolgende Schritte benötigt wird. Oder Sie haben Aufrufe mit Ergebnissen, die Sie nicht interessieren, und Sie können diese Ergebnisse ganz weglassen.

Sie können eine Variable löschen, indem Sie null zuweisen. In YAML können Sie einer Variablen auch einen leeren Wert oder ~ zuweisen. Dadurch wird Speicher identifiziert, der gefahrlos freigegeben werden kann.

Beispiel

  - step:
      assign:
        - bigVar:

Untergeordnete und externe Workflows verwenden

Mit untergeordneten Workflows können Sie einen Logikabschnitt oder eine Reihe von Schritten definieren, die Sie mehrmals aufrufen möchten. So wird die Workflowdefinition vereinfacht. Unterarbeitsabläufe ähneln einer Funktion oder Routine in einer Programmiersprache. Sie können Parameter akzeptieren und Werte zurückgeben, sodass Sie komplexere Workflows mit einem breiteren Anwendungsbereich erstellen können.

Untergeordnete Workflows sind lokal für Ihre Workflow-Definition und können nicht in anderen Workflows wiederverwendet werden. Sie können jedoch Workflows aus anderen Workflows aufrufen. Dabei können Ihnen die Workflows-Connectors helfen. Weitere Informationen finden Sie in den Connector-Übersichten für die Workflow Executions API und die Workflows API.

Workflows-Connectors verwenden

Workflows bietet eine Reihe von Connectors, die den Zugriff auf andere Google Cloud Produkte in einem Workflow erleichtern. Connectors vereinfachen den Aufruf von Diensten, da sie die Formatierung von Anfragen für Sie verarbeiten und Methoden und Argumente bereitstellen. Sie müssen also die Details einerGoogle Cloud API nicht kennen. Connectors haben auch ein integriertes Verhalten für die Verarbeitung von Wiederholungsversuchen und lang andauernden Vorgängen. So müssen Sie nicht iterieren und auf den Abschluss von Aufrufen warten. Connectors übernehmen das für Sie.

Wenn Sie eine Google Cloud API aufrufen müssen, prüfen Sie zuerst, ob ein Workflows-Connector dafür vorhanden ist. Wenn Sie keinen Connector für ein Google Cloud -Produkt finden, können Sie ihn anfordern.

Informationen zur Verwendung eines Connectors und eine detaillierte Referenz zu den verfügbaren Connectors finden Sie in der Referenz zu Connectors.

Workflowschritte parallel ausführen

Workflows können Schritte zwar sequenziell ausführen, aber Sie können auch unabhängige Schritte parallel ausführen. In einigen Fällen kann dies die Ausführung Ihres Workflows erheblich beschleunigen. Weitere Informationen finden Sie unter Workflow-Schritte parallel ausführen.

Wiederholungsversuche und das Saga-Muster anwenden

Entwerfen Sie Workflows, die stabil sind und sowohl vorübergehende als auch dauerhafte Dienstausfälle bewältigen können. Fehler für Workflows können beispielsweise durch fehlgeschlagene HTTP-Anfragen, Funktionen, Connectors oder durch Ihren eigenen Workflow-Code ausgelöst werden. Fügen Sie Fehlerbehandlung und Wiederholungen hinzu, damit ein Fehler in einem Schritt nicht dazu führt, dass der gesamte Workflow fehlschlägt.

Einige Geschäftsvorgänge umfassen mehrere Dienste. Daher benötigen Sie einen Mechanismus zum Implementieren von dienstübergreifenden Transaktionen. Das Saga-Entwurfsmuster ist eine Möglichkeit, die Datenkonsistenz über Mikrodienste hinweg in Szenarien mit verteilten Transaktionen zu verwalten. Eine Saga ist eine Folge von Transaktionen, bei der für jede Transaktion ein Ereignis veröffentlicht wird, das die nächste Transaktion auslöst. Wenn eine Transaktion fehlschlägt, führt die Saga Ausgleichstransaktionen aus, die den vorherigen Fehlern in der Sequenz entgegenwirken. Anleitung zu Wiederholungen und Saga-Muster in Workflows auf GitHub ausprobieren

Mit Callbacks warten

Callbacks ermöglichen es Workflow-Ausführungen, zu warten, bis ein anderer Dienst eine Anfrage an den Callback-Endpunkt sendet. Diese Anfrage setzt die Ausführung des Workflows fort.

Mit Callbacks können Sie Ihrem Workflow signalisieren, dass ein bestimmtes Ereignis aufgetreten ist, und auf dieses Ereignis ohne Polling warten. Sie können beispielsweise einen Workflow erstellen, um Sie zu benachrichtigen, wenn ein Produkt wieder auf Lager ist oder wenn ein Artikel versendet wurde. Oder Sie erstellen einen Workflow, der eine Pause macht, um menschliche Interaktion zu ermöglichen, z. B. die Überprüfung eines Auftrags oder die Validierung einer Übersetzung. Sie können auch mit Callbacks und Eventarc-Triggern auf Ereignisse warten.

Lange laufende Jobs orchestrieren

Wenn Sie lang andauernde Batchverarbeitungs-Arbeitslasten ausführen müssen, können Sie Batch oder Cloud Run-Jobs verwenden. Mit Workflows können Sie die Dienste verwalten. So können Sie Vorteile kombinieren und den gesamten Prozess effizient bereitstellen und orchestrieren.

Batch ist ein vollständig verwalteter Dienst, mit dem Sie Batcharbeitslasten auf Compute Engine-VM-Instanzen planen, in die Warteschlange stellen und ausführen können. Mit dem Workflows-Connector für Batch können Sie einen Batch-Job planen und ausführen. Weitere Informationen finden Sie in der Anleitung.

Cloud Run-Jobs werden verwendet, um Code auszuführen, der Arbeit (einen Job) ausführt und nach Abschluss der Arbeit beendet wird. Mit Workflows können Sie Cloud Run-Jobs als Teil eines Workflows ausführen, um eine komplexere Datenverarbeitung durchzuführen oder ein System vorhandener Jobs zu orchestrieren. In dieser Anleitung wird gezeigt, wie Sie mit Workflows einen Cloud Run-Job ausführen.

Lang andauernde Aufgaben containerisieren

Sie können die Ausführung eines lang andauernden Containers mit Workflows und Compute Engine automatisieren. Sie können beispielsweise eine zeitaufwendige Aufgabe in einem Container ausführen, damit sie überall ausgeführt werden kann. Anschließend können Sie den Container auf einer Compute Engine-VM für die maximale Dauer einer Workflowausführung (ein Jahr) ausführen.

Mit Workflows können Sie das Erstellen der VM, das Ausführen des Containers auf der VM und das Löschen der VM automatisieren. So können Sie einen Server verwenden und einen Container ausführen, ohne sich um die Verwaltung beider kümmern zu müssen. Das kann hilfreich sein, wenn Sie bei der Verwendung eines Dienstes wie Cloud Run-Funktionen oder Cloud Run Zeitbeschränkungen haben. Anleitung für lang andauernde Container mit Workflows und Compute Engine auf GitHub

Befehlszeilentools über Workflows ausführen

Cloud Build ist ein Dienst, der Ihre Builds auf Google Cloud als eine Reihe von Build-Schritten ausführt, wobei jeder Build-Schritt in einem Docker-Container ausgeführt wird. Build-Schritte werden genauso wie Befehle in einem Skript aufgerufen.

Die Google Cloud CLI enthält die Befehlszeilentools gcloud, bq und kubectl. Es gibt jedoch keine direkte Möglichkeit, gcloud CLI-Befehle über Workflows auszuführen. Cloud Build bietet jedoch Container-Images, die die gcloud CLI enthalten. Sie können gcloud CLI-Befehle in diesen Containern über einen Cloud Build-Schritt ausführen und diesen Schritt in Workflows mit dem Cloud Build-Connector erstellen.

Beispiel

gcloud in einem Workflow ausführen:

# This example shows how to execute gcloud commands from Workflows
# using Cloud Build and returns the output

main:
  steps:
  - execute_command:
      call: gcloud
      args:
          args: "workflows list"
      result: result
  - return_result:
      return: ${result}

gcloud:
  params: [args]
  steps:
  - create_build:
      call: googleapis.cloudbuild.v1.projects.builds.create
      args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        parent: ${"projects/" + sys.get_env("GOOGLE_CLOUD_PROJECT_ID") + "/locations/global"}
        body:
          serviceAccount: ${sys.get_env("GOOGLE_CLOUD_SERVICE_ACCOUNT_NAME")}
          options:
            logging: CLOUD_LOGGING_ONLY
          steps:
          - name: gcr.io/google.com/cloudsdktool/cloud-sdk
            entrypoint: /bin/bash
            args: ${["-c", "gcloud " + args + " > $$BUILDER_OUTPUT/output"]}
      result: result_builds_create
  - return_build_result:
      return: ${text.split(text.decode(base64.decode(result_builds_create.metadata.build.results.buildStepOutputs[0])), "\n")}

Run kubectl in a workflow:

# This example shows how to execute kubectl commands from Workflows
# using Cloud Build and returns the output

main:
  steps:
  - execute_command:
      call: kubectl
      args:
          args: "--help"
      result: result
  - return_result:
      return: ${result}

kubectl:
  params: [args]
  steps:
  - create_build:
      call: googleapis.cloudbuild.v1.projects.builds.create
      args:
        projectId: ${sys.get_env("GOOGLE_CLOUD_PROJECT_ID")}
        parent: ${"projects/" + sys.get_env("GOOGLE_CLOUD_PROJECT_ID") + "/locations/global"}
        body:
          serviceAccount: ${sys.get_env("GOOGLE_CLOUD_SERVICE_ACCOUNT_NAME")}
          options:
            logging: CLOUD_LOGGING_ONLY
          steps:
          - name: gcr.io/cloud-builders/kubectl
            entrypoint: /bin/bash
            args: ${["-c", "kubectl " + args + " > $$BUILDER_OUTPUT/output"]}
      result: result_builds_create
  - return_build_result:
      return: ${text.split(text.decode(base64.decode(result_builds_create.metadata.build.results.buildStepOutputs[0])), "\n")}

Workflow mit Terraform erstellen

Terraform ist ein Infrastruktur-als-Code-Tool, mit dem Sie Ihre Cloud-Infrastruktur mithilfe von Code vorhersehbar erstellen, ändern und verbessern können.

Sie können einen Workflow mit der Terraform-Ressource google_workflows_workflow definieren und bereitstellen. Weitere Informationen finden Sie unter Workflow mit Terraform erstellen.

Um die Verwaltung und Wartung großer Workflows zu erleichtern, können Sie Ihren Workflow in einer separaten YAML-Datei erstellen und diese Datei mit der Funktion templatefile in Terraform importieren. Diese Funktion liest eine Datei an einem bestimmten Pfad und rendert ihren Inhalt als Vorlage.

Beispiel

  # Define a workflow
  resource "google_workflows_workflow" "workflows_example" {
    name            = "sample-workflow"
    region          = var.region
    description     = "A sample workflow"
    service_account = google_service_account.workflows_service_account.id
    # Import main workflow YAML file
    source_contents = templatefile("${path.module}/workflow.yaml",{})
  }

Wenn Sie einen Hauptworkflow haben, der mehrere untergeordnete Workflows aufruft, können Sie den Hauptworkflow und die untergeordneten Workflows in separaten Dateien definieren und sie mit der Funktion templatefile importieren.

Beispiel

  # Define a workflow
  resource "google_workflows_workflow" "workflows_example" {
    name            = "sample-workflow"
    region          = var.region
    description     = "A sample workflow"
    service_account = google_service_account.workflows_service_account.id
    # Import main workflow and subworkflow YAML files
    source_contents = join("", [
      templatefile(
        "${path.module}/workflow.yaml",{}
      ),

      templatefile(
        "${path.module}/subworkflow.yaml",{}
      )])
  }

Wenn Sie beim Debuggen eines Workflows auf Zeilennummern verweisen, werden alle YAML-Dateien, die über die Terraform-Konfigurationsdatei importiert wurden, zusammengeführt und als ein einzelner Workflow bereitgestellt.

Workflow aus einem Git-Repository bereitstellen

Cloud Build verwendet Build-Trigger, um die CI/CD-Automatisierung zu aktivieren. Sie können Trigger konfigurieren, um eingehende Ereignisse zu überwachen, z. B. wenn ein neuer Commit an ein Repository übertragen oder eine Pull-Anfrage initiiert wird, und dann automatisch einen Build ausführen, wenn neue Ereignisse eingehen.

Mit einem Cloud Build-Trigger können Sie automatisch einen Build starten und einen Workflow aus einem Git-Repository bereitstellen. Sie können den Trigger so konfigurieren, dass Ihr Workflow bei jeder Änderung am Quell-Repository bereitgestellt wird, oder nur, wenn die Änderung bestimmten Kriterien entspricht.

So können Sie den Bereitstellungslebenszyklus besser verwalten. Sie können beispielsweise Änderungen an einem Workflow in einer Staging-Umgebung bereitstellen, Tests für diese Umgebung ausführen und die Änderungen dann schrittweise in der Produktionsumgebung einführen. Weitere Informationen finden Sie unter Workflow aus einem Git-Repository mit Cloud Build bereitstellen.

Nutzung optimieren

Die Kosten für die Ausführung eines Workflows sind minimal. Bei einer hohen Nutzung sollten Sie jedoch die folgenden Richtlinien anwenden, um die Nutzung zu optimieren und die Kosten zu senken:

  • Achten Sie darauf, dass bei allen Aufrufen von Google Cloud-Diensten *.appspot.com, *.cloud.goog, *.cloudfunctions.net oder *.run.app verwendet wird, damit Ihnen interne und nicht externe Schritte in Rechnung gestellt werden.

  • Wenden Sie eine benutzerdefinierte Richtlinie für Wiederholungsversuche an, die Ihre Anforderungen in Bezug auf Latenz und Zuverlässigkeit mit den Kosten in Einklang bringt. Häufigere Wiederholungsversuche verringern die Latenz und erhöhen die Zuverlässigkeit, können aber auch die Kosten erhöhen.

  • Wenn Sie Connectors verwenden, die auf Vorgänge mit langer Ausführungszeit warten, legen Sie eine benutzerdefinierte Polling-Richtlinie fest, die die Latenz für die Kosten optimiert. Wenn Sie beispielsweise erwarten, dass ein Vorgang länger als eine Stunde dauert, sollten Sie eine Richtlinie verwenden, die bei einem sofortigen Fehler zuerst nach einer Minute und dann alle 15 Minuten abfragt.

  • Zuweisungen in einem Schritt zusammenfassen.

  • Vermeiden Sie die übermäßige Verwendung von sys.log-Schritten. Verwenden Sie stattdessen Anruflisten.

Zusammenfassung der Best Practices

In der folgenden Tabelle sind die allgemeinen Tipps und Best Practices zusammengefasst, die in diesem Dokument empfohlen werden.

Allgemeine Tipps
Best Practices

Nächste Schritte