Best Practices für Workflows

Sie können sich bei der Orchestrierung Ihrer Dienste an die hier aufgeführten Best Practices orientieren. mit Workflows.

Dies ist keine vollständige Liste von Empfehlungen und enthält keine Informationen zu den zur Verwendung von Workflows. In diesem Dokument wird davon ausgegangen, dass Sie bereits ein allgemeines Verständnis der Google Cloud-Umgebung und von Workflows haben. Weitere Informationen finden Sie in der Google Cloud-Architektur-Framework und das Workflowübersicht.

Das optimale Kommunikationsmuster auswählen

Beim Entwerfen einer Mikrodienstarchitektur für die Bereitstellung mehrerer Dienste aus den folgenden Kommunikationsmustern auswählen:

  • Direkte Service-zu-Dienst-Kommunikation

  • Indirekte ereignisgesteuerte Kommunikation (auch als Choreografie bezeichnet)

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

Berücksichtigen Sie die Vor- und Nachteile der einzelnen Optionen und wählen Sie ein optimales Muster für Ihren Anwendungsfall aus. Zum Beispiel Die Dienst-zu-Dienst-Kommunikation ist möglicherweise einfacher zu implementieren als andere. Optionen, aber Ihre Dienste sind eng miteinander verbunden. Im Gegensatz dazu ereignisgesteuerte Architektur Sie Ihre Dienste lose verknüpfen. Monitoring und Fehlerbehebung können jedoch komplizierter machen. Schließlich können Sie mit einem zentralen Orchestrator wie Workflows die Kommunikation zwischen Diensten koordinieren, ohne die enge Kopplung der direkten Dienst-zu-Dienst-Kommunikation oder die Komplexität choreografierter Ereignisse.

Sie können auch Kommunikationsmuster kombinieren. In einer ereignisgesteuerten Orchestrierung, eng verwandte Dienste in einer Orchestrierung gemanagt werden, durch ein Ereignis ausgelöst werden. In ähnlicher Weise könnten Sie ein System entwerfen, in dem eine Orchestrierung einer Pub/Sub-Nachricht an eine andere orchestrierten System.

Allgemeine Tipps

Wenn Sie sich für die Verwendung von Workflows als Dienstorchestrierung entschieden haben, beachten Sie die folgenden hilfreichen Tipps.

Hartcodierung von URLs vermeiden

Sie können Workflows unterstützen, die in mehreren Umgebungen übertragbar sind einfacher zu verwalten, da hartcodierte URLs vermieden werden. Sie können dies in der auf folgende Arten:

  • Definieren Sie URLs als Laufzeitargumente.

    Dies kann hilfreich sein, wenn Ihr Workflow über eine Clientbibliothek oder die API verwenden. Das funktioniert jedoch nicht, wenn Ihr Workflow durch ein Ereignis von Eventarc ausgelöst wird und das einzige Argument, das übergeben werden kann, die Ereignisnutzlast 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. Beispiel:

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

  • Umgebungsvariablen verwenden und Workflow erstellen, der je nach Umgebung dynamisch konfiguriert wird für die sie bereitgestellt werden. Oder erstellen Sie einen Workflow, der später als und entsprechend der separat verwalteten Umgebung konfiguriert Variablen.

  • Mit einer Ersetzungsmethode einen einzelnen Workflow erstellen Definitionsdatei und stellen Sie Varianten mithilfe eines Tools bereit, das Platzhalter in Ihrem Workflow. So können Sie zum Beispiel Cloud Build verwenden, um einen Workflow bereitstellen und in der Cloud Build-Konfigurationsdatei ein 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']

    Sie können dann Variablenwerte ersetzen. Beispiel:

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

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

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

    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 im Stammmodul Ihrer Konfiguration Variablen deklariert sind, können sie zugewiesene Werte in vielerlei Hinsicht nutzen. Beispiel:

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

  • Secret Manager-Connector verwenden um URLs sicher in Secret Manager zu speichern und abzurufen.

Verschachtelte Schritte verwenden

Jeder Workflow muss mindestens einen Schritt enthalten. Standardmäßig werden Schritte in Workflows so behandelt, als wären sie in einer sortierten Liste, und werden nacheinander ausgeführt, bis alle Schritte ausgeführt wurden. Logischerweise sollten einige Schritte gruppiert werden. Sie können einen steps-Block verwenden, um eine eine Reihe von Schritten. Das ist praktisch, weil Sie so auf den richtigen atomaren 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 expressions müssen mit beginnen $ und in geschweiften Klammern eingeschlossen:

${EXPRESSION}

Um Probleme beim YAML-Parsen zu vermeiden, können Sie Ausdrücke in Anführungszeichen setzen. Beispiel: Ausdrücke, die Doppelpunkte enthalten kann zu unerwartetem Verhalten führen, wenn der Doppelpunkt als Definition einer Karte 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 mehrere Zeilen umfassen. Beispielsweise müssen Sie eine SQL-Abfrage in Anführungszeichen setzen, wenn Sie den BigQuery-Connector für Workflows 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 gesamte 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 analysieren und Eingaben für andere verbundene Dienste erstellen. Durch das Aufrufen eines Dienstes vermeiden Sie die Komplikationen zusätzlicher Aufrufe, zusätzliche 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 die Komplexität zu abstrahieren.

Sie sollten jedoch Dienste für alle Arbeiten erstellen, die zu komplex sind. für Workflows; z. B. die Implementierung wiederverwendbarer Geschäftslogik, komplexe Berechnungen oder Transformationen, die von Workflowausdrücke und ihre Standardbibliothek. Komplizierte Fälle lassen sich in der Regel einfacher in Code implementieren, YAML oder JSON und die Workflow-Syntax.

Nur speichern, was du brauchst

Halten Sie den Speicherverbrauch unter Kontrolle, damit Sie Ressourcenlimits oder ein Fehler, der z. B. ResourceLimitError, MemoryLimitExceededError oder ResultSizeLimitExceededError

Wählen Sie sorgfältig aus, was Sie speichern. Variablen festlegen, indem Sie nach und und speichern Sie nur das, was Sie brauchen. Gibt ein Dienst eine zu große Nutzlast zurück, verwenden Sie eine separate Funktion, um den Aufruf für Sie zu starten und nur das zurückzugeben, was erforderlich ist.

Sie können Arbeitsspeicher freigeben, indem Sie Variablen löschen. Zum Beispiel möchten Sie vielleicht der für die nachfolgenden Schritte benötigt wird. Oder Sie haben Anrufe mit Ergebnisse, die Ihnen nicht wichtig sind, und können diese Ergebnisse ganz weglassen.

Sie können eine Variable löschen, indem Sie null zuweisen. In YAML können Sie auch ein leerer Wert oder ~ in eine Variable. Damit wird ein Arbeitsspeicher identifiziert, der sicher zurückgefordert.

Beispiel

  - step:
      assign:
        - bigVar:

Untergeordnete und externe Workflows verwenden

Mit subworkflows können Sie eine Logik oder eine Reihe von Schritten definieren, die Sie mehrmals aufrufen möchten, eine vereinfachte Workflow-Definition. Untergeordnete Workflows ähneln einer Funktion oder Programmiersprache. Sie können Parameter akzeptieren und Werte zurückgeben, und so komplexere Workflows mit einer größeren Palette von Anwendungen erstellen können.

Beachten Sie, dass untergeordnete Workflows lokal für Ihre Workflowdefinition gelten und nicht wiederverwendet werden können. in anderen Workflows. Sie können jedoch Anruf-Workflows aus anderen Workflows. Die Workflows-Connectors können Ihnen dabei helfen. Weitere Informationen finden Sie in den Connector-Übersichten für die Workflow Executions API und der Workflows API.

Workflows-Connectors verwenden

Workflows bietet eine Reihe von Connectors, , um auf andere Google Cloud-Produkte in einem Workflow zuzugreifen. Anschlüsse das Aufrufen von Diensten zu vereinfachen, da sie die Formatierung von Anfragen für Sie übernehmen. Methoden und Argumente, sodass Sie die Details einer Google Cloud API Connectors haben auch ein integriertes Verhalten für die Verarbeitung Wiederholungen und lang andauernden Vorgängen Iteration und das Warten auf den Abschluss von Aufrufen; „Connectors“ übernimmt 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 keine für ein Google Cloud-Produkt haben, können Sie anfordern.

Informationen zum Verwenden eines Connectors Eine detaillierte Referenz der verfügbaren Connectors finden Sie in der Connector-Referenz

Workflowschritte parallel ausführen

In Workflows können Schritte nacheinander ausgeführt werden, aber Sie können auch unabhängige Schritte parallel ausführen. In einigen Fällen kann dieser Vorgang Ihre Workflow-Ausführung. Weitere Informationen finden Sie unter Workflowschritte parallel ausführen

Wiederholungsversuche und Saga-Muster anwenden

Gestalten Sie Workflows, die stabil sind und sowohl vorübergehende als auch dauerhafte Daten verarbeiten können. Störungen. Fehler für Workflows können beispielsweise durch fehlgeschlagene HTTP-Anfragen, Funktionen, Connectors oder über Ihren eigenen Workflow generierte Code. Fügen Sie eine Fehlerbehandlung und Wiederholungen hinzu, damit ein Fehler bei einem Schritt nicht zum Absturz des gesamten Workflows führt.

Da einige Geschäftstransaktionen mehrere Dienste umfassen, benötigen Sie einen Mechanismus, Implementierung von Transaktionen, die Dienste umfassen. Das Designmuster der Saga ist eine Möglichkeit, Datenkonsistenz in Mikrodiensten in verteilten Transaktionsszenarien zu verwalten. Eine Saga ist eine Abfolge von Transaktionen, bei der für jede Transaktion und die die nächste Transaktion auslöst. Wenn eine Transaktion fehlschlägt, Saga führt Kompensationstransaktionen aus, die den vorherigen Fehlern entgegenwirken in der Sequenz an. Testen Sie die Anleitung für Wiederholungsversuche und Saga-Muster in Workflows auf GitHub.

Mit Callbacks warten

Workflow zum Zulassen von Callbacks mit denen darauf gewartet wird, dass ein anderer Dienst eine Anfrage an den Callback-Endpunkt setzt diese Anfrage 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 Abfrage warten. Sie können beispielsweise einen Workflow erstellen, der Sie benachrichtigt, wenn ein Produkt wieder verfügbar ist. auf Lager oder wenn ein Artikel versendet wurde; oder dass wartet darauf, dass menschliche Interaktionen z. B. um einen Auftrag oder eine Übersetzung zu überprüfen. Sie können auch mit Callbacks und Eventarc-Triggern auf Ereignisse warten.

Lang andauernde Jobs orchestrieren

Wenn Sie langlaufende Batchverarbeitungen 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 sowie die effiziente Bereitstellung und Orchestrierung des gesamten Prozesses.

Batch ist ein vollständig verwalteter Dienst, mit dem Sie Batch-Arbeitslasten in der virtuellen Compute Engine-Umgebung planen, in die Warteschlange stellen und ausführen VM-Instanzen. Sie können die Workflows-Connector für Batch zum Planen und Ausführen eines Batch-Jobs. Weitere Informationen finden Sie in der Anleitung.

Cloud Run-Jobs werden verwendet, um Code auszuführen, der Arbeit (einen Job) ausführt und beendet, wenn die Arbeit erledigt ist. Mit Workflows können Sie Cloud Run-Jobs als Teil eines Workflows zum Ausführen komplexerer Daten bestehende Jobs zu verarbeiten oder zu orchestrieren. Testen Anleitung, die zeigt, wie mit Workflows ein Cloud Run-Job.

Lang andauernde Aufgaben containerisieren

Sie können die Ausführung eines Containers mit langer Laufzeit automatisieren, Workflows und Compute Engine. So können Sie zum Beispiel eine lang andauernde Aufgabe containerisieren, damit sie überall ausgeführt werden kann, und anschließend den Container auf einer Compute Engine-VM für die maximale Dauer eines Workflows Ausführung (ein Jahr).

Mit Workflows können Sie die Erstellung der VM, der das Ausführen des Containers auf der VM und das Löschen der VM. So können Sie einen Server verwenden und einen Container ausführen, aber die Komplexität der Verwaltung beider wird abstrahiert. Das kann hilfreich sein, wenn Sie bei der Verwendung eines Dienstes wie Cloud Run-Funktionen oder Cloud Run auf Zeitbeschränkungen stoßen. Testen Sie die Lang andauernde Container mit Workflows und Compute Engine auf GitHub.

Befehlszeilentools über Workflows ausführen

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

Die Google Cloud CLI enthält gcloud, bq und kubectl-Befehlszeilentools, aber es gibt keine direkte Möglichkeit, die gcloud CLI auszuführen. aus Workflows. Cloud Build stellt Container-Images bereit, die die gcloud CLI enthalten. Sie können gcloud-Kommandozeilenbefehle in diesen Containern aus einem Cloud Build Sie können diesen Schritt in Workflows mithilfe der Methode Cloud Build-Connector.

Beispiel

Führen Sie gcloud in einem Workflow aus:

# 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. zum Erstellen, Ändern und Verbessern Ihrer Cloud-Infrastruktur mit Code.

Sie können einen Workflow mithilfe von Terraform definieren und bereitstellen. google_workflows_workflow . Weitere Informationen finden Sie unter Workflow mit Terraform erstellen

Um Sie bei der Verwaltung und Pflege großer Workflows zu unterstützen, können Sie Ihren Workflow erstellen. in einer separaten YAML-Datei erstellen und diese Datei mithilfe der templatefile-Funktion die eine Datei in einem bestimmten Pfad liest und ihren Inhalt als Vorlage rendert.

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 templatefile, um sie zu 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 für die Fehlerbehebung in einem Workflow auf Zeilennummern verweisen, Über die Terraform-Konfigurationsdatei importierte YAML-Dateien werden zusammengeführt und die als einzelner Workflow bereitgestellt werden.

Workflow aus einem Git-Repository bereitstellen

Cloud Build verwendet Trigger erstellen, um die CI/CD-Automatisierung zu aktivieren Sie können Konfigurieren Sie Trigger, um eingehende Ereignisse zu erfassen, z. B. wenn ein neuer Commit ausgeführt wird. an ein Repository gesendet oder eine Pull-Anfrage initiiert wird. automatisch einen Build ausführen, wenn neue Ereignisse eingehen.

Sie können einen Cloud Build-Trigger verwenden, um einen Build automatisch zu starten und einen Workflow aus einem Git-Repository bereitstellen. Sie können den Trigger so konfigurieren, Stellen Sie Ihren Workflow bei jeder Änderung am Quell-Repository bereit oder stellen Sie das wenn die Änderung bestimmte Kriterien erfüllt.

Dieser Ansatz kann Ihnen bei der Verwaltung des Bereitstellungslebenszyklus helfen. Zum Beispiel haben Sie kann Änderungen an einem Workflow in einer Staging-Umgebung bereitstellen, Tests für und diese Änderungen schrittweise in den in der Produktionsumgebung erstellt werden kann. 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 hohen Volumennutzung zu erhöhen, wenden Sie die folgenden Richtlinien an, um die Nutzung zu optimieren und die Kosten zu senken:

  • Anstatt benutzerdefinierte Domains zu verwenden, sollten Sie darauf achten, dass alle Aufrufe an Google Cloud Dienste verwenden *.appspot.com, *.cloud.goog, *.cloudfunctions.net oder *.run.app, damit Ihnen interne und keine externen Schritte in Rechnung gestellt werden.

  • Benutzerdefinierte Wiederholungsrichtlinie anwenden das Ihre Latenz- und Zuverlässigkeitsanforderungen mit den Kosten in Einklang bringt. Häufigere die Latenz senken und die Zuverlässigkeit erhöhen, aber auch die Kosten steigen lassen.

  • Wenn Sie Connectors verwenden, die auf Vorgänge mit langer Ausführungszeit warten, legen Sie eine benutzerdefinierte Abfragerichtlinie zur Kostenoptimierung der Latenz. Wenn Sie z. B. erwarten, dass ein Vorgang können Sie mit einer Richtlinie festlegen, die die Abfrage anfangs nach einer Minute im und dann alle 15 Minuten.

  • Zuweisungen kombinieren in einem Schritt zusammengefasst.

  • Vermeiden Sie die übermäßige Verwendung von sys.log Schritten. Sie können stattdessen Anrufprotokolle verwenden.

Zusammenfassung der Best Practices

In der folgenden Tabelle sind die allgemeinen Tipps und Best Practices in diesem Dokument.

Allgemeine Tipps
Best Practices

Nächste Schritte