Best Practices für Workflows

Mit Workflows können Sie Dienste in Google Cloudkoordinieren und automatisieren. Wenn Sie empfohlene Architekturverfahren anwenden, können Sie die Zuverlässigkeit verbessern, die Ausführungskosten optimieren und stabile, wartungsfreundliche Orchestrierungen erstellen.

Diese Liste ist nicht vollständig und es werden keine Grundlagen zur Verwendung von Workflows vermittelt. 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 zwischen den folgenden Kommunikationsmustern wä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. Ein zentraler Orchestrator wie Workflows ermöglicht es Ihnen, die Kommunikation zwischen Diensten zu 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. Ebenso können Sie 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.

Hartcodierte 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-Payload 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. Oder Sie erstellen einen Workflow, der als Vorlage wiederverwendet und entsprechend separat verwalteter 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 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 beim Erstellen Variablenwerte 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, mit der mithilfe von Eingabevariablen Workflows für jede Umgebung erstellt werden.

    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 enthalten. Standardmäßig behandelt Workflows Schritte so, als ob sie sich in einer geordneten Liste befinden, und führt sie einzeln aus, bis alle Schritte ausgeführt wurden. Logischerweise sollten einige Schritte gruppiert werden. Sie können einen steps-Block verwenden, um eine Reihe von Schritten zu 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 umbrechen

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

${EXPRESSION}

Um Probleme beim YAML-Parsing zu vermeiden, können Sie Ausdrücke in Anführungszeichen setzen. Ausdrücke mit Doppelpunkten können beispielsweise zu unerwartetem Verhalten führen, wenn der Doppelpunkt als Definition einer Map 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 aus dem 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. Wenn Sie einen Dienst aufrufen, vermeiden Sie die Komplikationen zusätzlicher Aufrufe, zusätzlicher Abhängigkeiten und Dienste, die Dienste aufrufen. Erwägen Sie, Dienste ohne Geschäftslogik durch deklarative API-Aufrufe zu ersetzen und Workflows zu verwenden, um Komplexität zu abstrahieren.

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. Ein komplizierter Fall lässt sich in der Regel einfacher in Code implementieren, anstatt YAML oder JSON und die Workflows-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 Anrufe 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 Unterworkflows können Sie einen Logikabschnitt oder eine Reihe von Schritten definieren, die Sie mehrmals aufrufen möchten. So lässt sich die Workflowdefinition vereinfachen. Unterworkflows ä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 das Aufrufen von Diensten, da sie die Formatierung von Anfragen für Sie übernehmen und Methoden und Argumente bereitstellen, sodass Sie die Details einerGoogle Cloud API nicht kennen müssen. Connectors haben auch ein integriertes Verhalten für die Verarbeitung von Wiederholungen und Vorgängen mit langer Ausführungszeit. So müssen Sie nicht iterieren und auf den Abschluss von Aufrufen warten. Das übernehmen die Connectors 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 sehen, können Sie ihn anfordern.

Informationen zur Verwendung von Connectors und eine detaillierte Referenz der verfügbaren Connectors finden Sie in der Connector-Referenz.

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 robuste Workflows, die 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 Wiederholungsversuche hinzu, damit ein Fehler in einem Schritt nicht dazu führt, dass der gesamte Workflow fehlschlägt.

Einige Geschäftsvorgänge erstrecken sich über mehrere Dienste. Daher benötigen Sie einen Mechanismus, um dienstübergreifende Transaktionen zu implementieren. Das Saga-Designmuster ist eine Möglichkeit, die Datenkonsistenz über Mikrodienste hinweg in Szenarien mit verteilten Transaktionen zu verwalten. Eine Saga ist eine Folge von Transaktionen, die für jede Transaktion ein Ereignis veröffentlicht und 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. Tutorial zu Wiederholungen und Saga-Muster in Workflows auf GitHub

Callbacks zum Warten verwenden

Mit Callbacks können Workflow-Ausführungen darauf warten, dass ein anderer Dienst eine Anfrage an den Callback-Endpunkt sendet. Durch diese Anfrage wird die Ausführung des Workflows fortgesetzt.

Mit Callbacks können Sie Ihrem Workflow signalisieren, dass ein bestimmtes Ereignis eingetreten ist, und auf dieses Ereignis warten, ohne abzufragen. Sie können beispielsweise einen Workflow erstellen, der Sie benachrichtigt, wenn ein Produkt wieder auf Lager ist oder wenn ein Artikel versendet wurde. Sie können auch einen Workflow erstellen, der auf menschliche Interaktion wartet, z. B. um eine Bestellung zu prüfen oder eine Übersetzung zu bestätigen. Sie können auch mit Callbacks und Eventarc-Triggern auf Ereignisse warten.

Jobs mit langer Ausführungszeit 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 die 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 diesem Tutorial.

Cloud Run-Jobs werden verwendet, um Code auszuführen, der eine Aufgabe (einen Job) ausführt und bei Abschluss 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 die Erstellung der VM, die Ausführung 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 auf Zeitbeschränkungen stoßen. Sehen Sie sich die Anleitung Lang andauernde Container mit Workflows und Compute Engine auf GitHub an.

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. Das Ausführen von Build-Schritten ist analog zum Ausführen von Befehlen in einem Skript.

Die Google Cloud CLI enthält die Befehlszeilentools gcloud, bq und kubectl. Es gibt jedoch keine direkte Möglichkeit, gcloud CLI-Befehle aus 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 vorhersagbar 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 Unterworkflows aufruft, können Sie den Hauptworkflow und die Unterworkflows in separaten Dateien definieren und 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 einzelner Workflow bereitgestellt.

Workflow aus einem Git-Repository bereitstellen

Cloud Build verwendet Build-Trigger, um CI/CD zu automatisieren. Sie können Trigger so konfigurieren, dass sie auf eingehende Ereignisse warten, z. B. wenn ein neuer Commit in ein Repository übertragen oder eine Pull-Anfrage initiiert wird. Anschließend wird automatisch ein Build ausgeführt, wenn neue Ereignisse eingehen.

Mit einem Cloud Build-Trigger können Sie einen Build automatisch 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 an 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, möchten Sie möglicherweise eine Richtlinie, 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 die Anrufliste.

  • Informationen dazu, welche Vorgänge als Schritt gelten Vorgänge, die nicht als eigene Schritte gelten, werden gezählt, wenn sie in einem anwendbaren Schritt verwendet werden. Beispiel:

    - type_check:
    return: if(get_type((int("6"))) == integer, 1, 2)

    Wichtige Vorgänge, die auf das Limit für die maximale Anzahl von Schritten angerechnet werden und nicht, sind in der folgenden Tabelle aufgeführt:

    Kategorie Vorgang
    Zählt als Schritt
    • Datenvorgänge: Werte zuweisen und zurückgeben
    • Ablaufsteuerung: Sprünge (next), Switches, Start einer for-Schleife und jeder Durchlauf einer for-Schleife
    • Aufrufe: Aufrufen von sys.get_env oder einer anderen Standardbibliotheksfunktion, eines anderen Workflows oder eines Connectors
    • Nebenläufigkeit: Threads erstellen und parallel ausführen
    • Fehlerbehandlung: Jeder raise-, try-, retry- und except-Block wird als separater Schritt gezählt, auch wenn andere Vorgänge Teil desselben größeren Schritts sind.

      Ein Schritt, der einen try-Block mit einem Call-Vorgang enthält, zählt beispielsweise als drei Schritte: einer für den primären Schritt, einer für den Try und einer für den Call. Wenn Sie einen retry-Block hinzufügen, werden drei weitere Schritte hinzugefügt (einer für den Wiederholungsversuch, einer für den Versuch und einer für den Aufruf), sodass insgesamt sechs Schritte vorhanden sind.
    Wird nicht als Schritt gezählt

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