Freigeben über

Beheben von CI/CD-, Azure DevOps- und GitHub-Problemen in Azure Data Factory und Synapse Analytics

GILT FÜR: Azure Data Factory Azure Synapse Analytics

Tipp

Testen Sie Data Factory in Microsoft Fabric, eine All-in-One-Analyselösung für Unternehmen. Microsoft Fabric deckt alle Aufgaben ab, von der Datenverschiebung bis hin zu Data Science, Echtzeitanalysen, Business Intelligence und Berichterstellung. Erfahren Sie, wie Sie kostenlos eine neue Testversion starten!

In diesem Artikel beschäftigen wir uns mit den gängigen Methoden zur Fehlerbehebung bei der Continuous Integration-Continuous Deployment (CI/CD), der Azure DevOps und den GitHub-Problemen in Azure Data Factory und Synapse Analytics.

Wenn Sie Fragen oder Probleme bei der Quellcodeverwaltung oder DevOps-Verfahren haben, können die folgenden Artikel nützlich sein:

Häufige Fehler und Meldungen

Fehler bei der Verbindungsherstellung mit Git-Repository aufgrund eines anderen Mandanten

Problem

Zuweilen können Authentifizierungsprobleme auftreten, beispielsweise der HTTP-Statusfehler 401. Das Ganze kann ziemlich kompliziert werden – insbesondere dann, wenn Sie über mehrere Mandanten mit Gastkonto verfügen.

Ursache

Das Token wurde vom ursprünglichen Mandanten abgerufen, aber der Dienst befindet sich im Gastmandanten und versucht, das Token zum Zugreifen auf DevOps im Gastmandanten zu verwenden. Diese Art des Tokenzugriffs entspricht nicht dem erwarteten Verhalten.

Empfehlung

Sie sollten das vom Gastmandanten ausgestellte Token verwenden. Beispielsweise müssen Sie dieselbe Microsoft Entra ID-Instanz als Gastmandant und DevOps-Ressource zuweisen, damit das Tokenverhalten korrekt festgelegt und der richtige Mandant verwendet werden kann.

Vorlagenparameter in der Parameterdatei sind nicht gültig

Problem

Wenn Sie einen Trigger im Entwicklungsbranch löschen, der bereits mit derselben Konfiguration (z. B. Häufigkeit und Intervall) im Test- oder Produktionsbranch verfügbar ist, kann die Releasepipeline erfolgreich bereitgestellt werden, und der entsprechende Trigger wird in den jeweiligen Umgebungen gelöscht. Wenn jedoch unterschiedliche Konfigurationen (z. B. für Häufigkeit und Intervall) für Trigger in Test- und Produktionsumgebungen vorliegen und Sie diesen Trigger in der Entwicklungsumgebung löschen, tritt bei der Bereitstellung ein Fehler auf.

Ursache

Bei der CI/CD-Pipeline tritt der folgende Fehler auf:

2020-07-20T11:19:02.1276769Z ##[error]Deployment template validation failed: 'The template parameters 'Trigger_Salesforce_properties_typeProperties_recurrence_frequency, Trigger_Salesforce_properties_typeProperties_recurrence_interval, Trigger_Salesforce_properties_typeProperties_recurrence_startTime, Trigger_Salesforce_properties_typeProperties_recurrence_timeZone' in the parameters file are not valid; they are not present in the original template and can therefore not be provided at deployment time. The only supported parameters for this template are 'factoryName, PlanonDWH_connectionString, PlanonKeyVault_properties_typeProperties_baseUrl

Empfehlung

Der Fehler tritt auf, weil häufig ein Trigger gelöscht wird, der parametrisiert ist. Daher sind die Parameter in der Azure Resource Manager-Vorlage (ARM) nicht verfügbar (weil der Trigger nicht mehr vorhanden ist). Da sich die Parameter nicht mehr in der ARM-Vorlage befinden, müssen die überschriebenen Parameter in der DevOps-Pipeline aktualisiert werden. Andernfalls müssen Parameter bei jeder Änderung in der ARM-Vorlage die überschriebenen Parameter in der DevOps-Pipeline aktualisieren (im Bereitstellungstask).

Aktualisierung des Eigenschaftstyps nicht unterstützt

Problem

Bei der CI/CD-Releasepipeline tritt der folgende Fehler auf:

2020-07-06T09:50:50.8716614Z There were errors in your deployment. Error code: DeploymentFailed.
2020-07-06T09:50:50.8760242Z ##[error]At least one resource deployment operation failed. Please list deployment operations for details. Please see https://aka.ms/DeployOperations for usage details.
2020-07-06T09:50:50.8771655Z ##[error]Details:
2020-07-06T09:50:50.8772837Z ##[error]DataFactoryPropertyUpdateNotSupported: Updating property type is not supported.
2020-07-06T09:50:50.8774148Z ##[error]DataFactoryPropertyUpdateNotSupported: Updating property type is not supported.
2020-07-06T09:50:50.8775530Z ##[error]Check out the troubleshooting guide to see if your issue is addressed: https://learn.microsoft.com/azure/devops/pipelines/tasks/deploy/azure-resource-group-deployment#troubleshooting
2020-07-06T09:50:50.8776801Z ##[error]Task failed while creating or updating the template deployment.

Ursache

Dieser Fehler ist auf eine Integration Runtime mit dem gleichen Namen in der Zieldienstinstanz, jedoch mit einem anderen Typ zurückzuführen. Die Integration Runtime muss bei der Bereitstellung vom gleichen Typ sein.

Empfehlung

  • Beachten Sie die bewährten Methoden für CI/CD.

  • Integration Runtimes ändern sich nicht häufig und sind in allen CI/CD-Phasen gleich. Daher erwartet der Dienst, dass Sie in allen Phasen von CI/CD eine Integration Runtime mit demselben Namen und demselben Typ verwenden. Wenn sich die Namen, Typen und Eigenschaften unterscheiden, sollten Sie sicherstellen, dass Sie die Quell- und Zielkonfigurationen der Integration Runtime abgleichen und erst dann die Releasepipeline bereitstellen.

  • Wenn Sie Integration Runtimes über alle Stufen hinweg freigeben möchten, können Sie eine ternäre Factory verwenden, die nur die freigegebenen Integration Runtimes enthält. Diese freigegebene Factory können Sie in allen Umgebungen als verknüpften Integration Runtime-Typ verwenden.

Fehler bei Dokumenterstellung oder -aktualisierung aufgrund eines ungültigen Verweises

Problem

Beim Versuch, Änderungen zu veröffentlichen, erhalten Sie die folgende Fehlermeldung:

"error": { "code": "BadRequest", "message": "The document creation or update failed because of invalid reference '<entity>'.", "target": "/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/<rgname>/providers/Microsoft.DataFactory/factories/<datafactory>/pipelines/<pipeline>", "details": null }

Ursache

Sie haben die Git-Konfiguration getrennt und mit ausgewähltem Flag „Import resources“ erneut eingerichtet. Damit wird der Dienst auf „synchron“ festgelegt. Dies bedeutet keine Änderung während der Veröffentlichung.

Lösung

Trennen Sie die Git-Konfiguration, und richten Sie sie erneut ein. Stellen Sie sicher, dass Sie das Kontrollkästchen zum Importieren vorhandener Ressourcen NICHT aktivieren.

Fehler beim Verschieben der Data Factory von einer Ressourcengruppe in eine andere

Problem

Sie können Data Factory nicht von einer Ressourcengruppe in eine andere verschieben. Folgender Fehler tritt auf: { "code": "ResourceMoveProviderValidationFailed", "message": "Resource move validation failed. Please see details. Diagnostic information: timestamp 'xxxxxxxxxxxxZ', subscription id 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx', tracking id 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx', request correlation id 'xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx'.", "details": [ { "code": "BadRequest", "target": "Microsoft.DataFactory/factories", "message": "One of the resources contain integration runtimes that are either SSIS-IRs in starting/started/stopping state, or Self-Hosted IRs which are shared with other resources. Resource move is not supported for those resources." } ] }

Lösung

Sie können die SSIS-IR und Shared IRs löschen, um den Verschiebevorgang zu ermöglichen. Wenn Sie die Integration Runtimes nicht löschen möchten, empfiehlt es sich, die Anweisungen im Dokument zum Kopieren und Klonen zu befolgen und anschließend die alte Data Factory zu löschen.

Exportieren und Importieren von ARM-Vorlagen nicht möglich

Problem

Eine ARM-Vorlage kann nicht exportiert und importiert werden. Im Portal wurde kein Fehler angezeigt, aber in der Stapelüberwachung des Browsers bemerken Sie folgenden Fehler:

Failed to load resource: the server responded with a status code of 401 (Unauthorized)

Ursache

Sie haben als Benutzer*in eine Kundenrolle erstellt und verfügten nicht über die erforderliche Berechtigung. Beim Laden der Benutzeroberfläche werden mehrere Steuerelementwerte überprüft, die verfügbar gemacht werden. In diesem Fall fehlt der Zugriffsrolle der Benutzer*innen die Berechtigung für den Zugriff auf die queryFeaturesValue-API. Für den Zugriff auf diese API ist das Feature für globale Parameter deaktiviert. Der Codepfad für den ARM-Vorlagenexport basiert zum Teil auf dem Feature für globale Parameter.

Lösung

Um dieses Problem zu lösen, müssen Sie Ihrer Rolle die folgende Berechtigung hinzufügen: Microsoft.DataFactory/factories/queryFeaturesValue/action. Diese Berechtigung ist standardmäßig in der Rolle Mitwirkender von Data Factory für Data Factory und in der Rolle Mitwirkender für Synapse Analytics enthalten.

Automatisierung der Veröffentlichung für CI/CD nicht möglich

Ursache

Bis vor Kurzem war es nur möglich, eine Pipeline durch Klicken in der Benutzeroberfläche des Portals für Bereitstellungen zu veröffentlichen. Dieser Prozess kann jetzt automatisiert werden.

Lösung

Der CI/CD-Prozess wurde erweitert. Die automatisierte Veröffentlichungsfunktion übernimmt, validiert und exportiert alle ARM-Vorlagenfunktionen aus der Benutzeroberfläche. Sie macht die Logik über ein öffentlich verfügbares npm-Paket @microsoft/azure-data-factory-utilities nutzbar. Diese Methode ermöglicht es Ihnen, diese Aktionen programmgesteuert auszulösen, anstatt auf die Oberfläche zuzugreifen und eine Schaltfläche auszuwählen. Mit dieser Methode erhalten Ihre CI/CD-Pipelines eine authentische kontinuierliche Integrationserfahrung. Weitere Informationen finden Sie im Artikel zum automatisierten Veröffentlichen für Continuous Integration und Delivery.

Veröffentlichung aufgrund von 4-MB-Grenzwert für ARM-Vorlagen nicht möglich

Problem

Die Bereitstellung ist nicht möglich, da Sie den Azure Resource Manager-Grenzwert von 4 MB Gesamtvorlagengröße erreicht haben. Sie benötigen eine Lösung für die Bereitstellung nach dem Erreichen dieses Grenzwerts.

Ursache

Azure Resource Manager beschränkt die Vorlagengröße auf 4 MB. Begrenzen Sie die Größe der Vorlage auf 4 MB und die jeder Parameterdatei auf 64 KB. Die 4-MB-Beschränkung gilt für den endgültigen Status der Vorlage, nachdem sie durch iterative Ressourcendefinitionen und Werte für variables und Parameter erweitert wurde. Sie haben den Grenzwert aber überschritten.

Lösung

Bei kleinen bis mittelgroßen Lösungen lässt sich eine Einzelvorlage einfacher verstehen und verwalten. Sie können alle Ressourcen und Werte in einer einzelnen Datei anzeigen. In erweiterten Szenarien können Sie mithilfe verknüpfter Vorlagen die Lösung in Zielkomponenten unterteilen. Befolgen Sie die Best Practice bei der Verwendung von verknüpften und verschachtelten Templates.

DevOps API-Grenzwert von 20 MB bewirkt, dass der ADF-Trigger statt einmal mindestens zweimal ausgelöst wird.

Problem

Beim Veröffentlichen von Ressourcen wird die Azure-Pipeline nicht nur einmal, sondern zweimal oder öfter ausgelöst.

Ursache

Für Azure DevOps gilt ein Grenzwert von 20 MB für die REST-API. Wenn die ARM-Vorlage diese Größe überschreitet, teilt ADF die Vorlagendatei intern in mehrere Dateien mit verknüpften Vorlagen auf, um dieses Problem zu beheben. Als Nebeneffekt kann diese Aufteilung dazu führen, dass die Trigger eines Kunden mehr als einmal ausgeführt werden.

Lösung

Verwenden Sie die ADF-Methode für die automatische Veröffentlichung (bevorzugt) oder den manuellen Trigger für die einmalige (statt der mehrmaligen) Auslösung.

Verbindung mit GIT Enterprise kann nicht hergestellt werden

Problem

Aufgrund von Berechtigungsproblemen können Sie keine Verbindung mit Git Enterprise herstellen. Ein Fehler wie 422 – Einheit kann nicht bearbeitet werden. wird angezeigt.

Ursache

  • Sie haben OAuth nicht für den Dienst konfiguriert.
  • Ihre URL ist falsch konfiguriert. repoConfiguration muss vom Typ FactoryGitHubConfiguration sein.

Lösung

Gewähren Sie zuerst OAuth-Zugriff auf den Dienst. Anschließend müssen Sie durch Angabe der richtigen URL eine Verbindung mit Git Enterprise herstellen. Die Konfiguration muss auf die Kundenorganisation(en) festgelegt werden. Zum Beispiel versucht es der Dienst zunächst mit https://hostname/api/v3/search/repositories?q=user%3<Kundenanmeldeinformationen>...., was zu einem Fehler führt. Dann versucht er es mit https://hostname/api/v3/orgs/<org>/<repo>..., und der Vorgang ist erfolgreich.

Wiederstellung aus einer gelöschten Instanz nicht möglich

Problem

Eine Instanz des Diensts oder die Ressourcengruppe, in der die Instanz enthalten war, wurde gelöscht und muss wiederhergestellt werden.

Ursache

Die Instanz kann nur wiederhergestellt werden, wenn die Quellcodeverwaltung für die Instanz mit DevOps oder Git konfiguriert wurde. Diese Aktion stellt alle zuletzt veröffentlichten Ressourcen wieder her, aber keine unveröffentlichte Pipelines, Datasets oder verknüpfte Dienste. Wenn keine Quellcodeverwaltung vorhanden ist, ist das Wiederherstellen einer gelöschten Instanz aus dem Azure-Back-End nicht möglich, da die Instanz ohne Sicherung für immer gelöscht wird, sobald der Dienst den Löschbefehl empfängt.

Lösung

Führen Sie zum Wiederherstellen einer gelöschten Dienstinstanz, für die die Quellcodeverwaltung konfiguriert ist, die folgenden Schritte aus:

  • Erstellen Sie eine neue Instanz des Diensts.

  • Konfigurieren Sie Git mit denselben Einstellungen neu. Vergewissern Sie sich aber, dass vorhandene Ressourcen in das ausgewählte Repository importiert werden, und wählen Sie „Neuer Branch“ aus.

  • Erstellen Sie einen Pull Request zum Mergen der Änderungen in den Kollaborationsbranch und zum Veröffentlichen.

  • Wenn eine selbstgehostete Integration Runtime in einer gelöschten Data Factory oder einem Synapse-Arbeitsbereich vorhanden ist, muss eine neue Instanz der IR in einer neuen Factory oder einem neuen Arbeitsbereich erstellt werden. Die IR-Instanz des lokalen oder virtuellen Computers muss deinstalliert und neu installiert werden. Weiterhin muss ein neuer Schlüssel abgerufen werden. Nachdem die Einrichtung der neuen IR abgeschlossen wurde, muss der verknüpfte Dienst aktualisiert werden, sodass er auf die neue IR verweist, und die Verbindung muss erneut getestet werden. Andernfalls wird der Fehler gemeldet, dass der Verweis ungültig ist.

Die Bereitstellung auf einer anderen Stufe mit der automatischen Veröffentlichungsmethode ist nicht möglich.

Problem

Der Kunde hat alle notwendigen Schritte wie die Installation des NPM-Pakets und das Einrichten einer höheren Stufe mit Azure DevOps befolgt, die Bereitstellung schlägt aber weiterhin fehl.

Ursache

npm-Pakete können zwar auf verschiedene Weise genutzt werden, aber einer der Hauptvorteile ist die Nutzung über Azure Pipelines. Bei jedem Merge in den Kollaborationsbranch kann eine Pipeline ausgelöst werden, die zuerst den gesamten Code überprüft und dann die ARM-Vorlage in ein Buildartefakt exportiert, das von einer Releasepipeline verwendet werden kann. In der Starter-Pipeline sollte die YAML-Datei gültig und vollständig sein.

Lösung

Der folgende Abschnitt ist ungültig, da der Ordner „package.json“ ungültig ist.

- task: Npm@1
  inputs:
    command: 'custom'
    workingDir: '$(Build.Repository.LocalPath)/<folder-of-the-package.json-file>' #replace with the package.json folder
    customCommand: 'run build validate $(Build.Repository.LocalPath) /subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/testResourceGroup/providers/Microsoft.DataFactory/factories/yourFactoryName'
  displayName: 'Validate'

Es sollte DataFactory im customCommand enthalten, wie z.B. 'run build validate $(Build.Repository.LocalPath)/DataFactory/subscriptions/xxxxxxxx-xxxx-xxxx-xxxx-xxxxxxxxxxxx/resourceGroups/testResourceGroup/providers/Microsoft.DataFactory/factories/yourFactoryName‘ . Stellen Sie sicher, dass die erzeugte YAML-Datei für die höhere Stufe die erforderlichen JSON-Artefakte enthalten sollte.

Zusätzliche öffnende eckige Klammern ([) in der veröffentlichten JSON-Datei

Problem

Bei der Bereitstellung mit DevOps wird eine zusätzliche öffnende eckige Klammer ([) angezeigt. Der Dienst fügt in DevOps automatisch eine weitere öffnende eckige Klammer ([) in einer ARM-Vorlage hinzu. In der JSON-Datei wird ein Ausdruck wie [[ angezeigt.

Ursache

Da [ ein reserviertes Zeichen für ARM-Vorlagen ist, wird automatisch eine zusätzliche öffnende eckige Klammer ([) hinzugefügt, um [ umgehen.

Lösung

Dieses Verhalten ist während des Veröffentlichungsprozesses für CI/CD normal.

Ausführen von CI/CD während der Status-/Warteschlangenstufe der Pipelineausführung

Problem

Sie möchten CI/CD während der Status-/Warteschlangenstufe der Pipelineausführung durchführen.

Ursache

Wenn die Pipeline auf der Status-/Warteschlangenstufe ist, müssen Sie zunächst die Pipeline und die Aktivitäten überwachen. Anschließend können Sie entscheiden, ob Sie warten möchten, bis die Pipeline abgeschlossen ist, oder ob Sie die Ausführung der Pipeline abbrechen.

Lösung

Sie können die Pipeline auch per SDK, Azure Monitor oder Monitor überwachen. Anschließend können Sie die bewährten Methoden für CI/CD befolgen.

Ausführen von KOMPONENTENTESTS während der Entwicklung und Bereitstellung

Problem

Sie möchten Komponententests während der Entwicklung und Bereitstellung Ihrer Pipelines durchführen.

Ursache

Möglicherweise möchten Sie während der Entwicklungs- und Bereitstellungszyklen Komponententests für Ihre Pipeline ausführen, bevor Sie die Pipeline manuell oder automatisch veröffentlichen. Mithilfe der Testautomatisierung können Sie mehr Tests in weniger Zeit und mit garantierter Wiederholbarkeit ausführen. Das automatische erneute Testen aller Pipelines vor der Bereitstellung bietet Ihnen einen gewissen Schutz vor Regressionsfehlern. Automatisierte Tests sind ein wichtiger Aspekt von Ansätzen zur CI/CD-Softwareentwicklung: Die Einbeziehung automatisierter Tests in CI/CD-Bereitstellungspipelines kann die Qualität erheblich verbessern. Langfristig werden getestete Pipelineartefakte wiederverwendet und sparen damit Kosten und Zeit.

Lösung

Da die Anforderungen der Kunden an Komponententests sehr unterschiedlich sein können und verschiedene Skillsets erfordern, sollten Sie in der Regel die folgenden Schritte befolgen:

  1. Richten Sie ein Azure DevOps-CI/CD-Projekt ein, oder entwickeln Sie eine SDK-gesteuerte Teststrategie für .NET/Python/REST.
  2. Erstellen Sie für CI/CD ein Buildartefakt, das alle Skripts enthält, und stellen Sie Ressourcen in einer Releasepipeline bereit. Entwickeln Sie für einen SDK-basierten Ansatz Testeinheiten mit PyTest in Python, Nunit in C# mit dem .NET SDK usw.
  3. Führen Sie Komponententests als Teil der Releasepipeline oder unabhängig mit dem ADF-SDK für Python/PowerShell/.NET/REST aus.

Sie können beispielsweise Duplikate in einer Datei löschen und dann die zusammengestellte Datei als Tabelle in einer Datenbank speichern. Um die Pipeline zu testen, richten Sie mithilfe von Azure DevOps ein CI/CD-Projekt ein. Richten Sie eine Testphase für die Pipeline ein, in der Sie Ihre entwickelte Pipeline bereitstellen. Sie konfigurieren die Testphase zum Ausführen von Python-Tests, um sicherzustellen, dass die Tabellendaten Ihren Erwartungen entsprechen. Wenn Sie CI/CD nicht verwenden, können Sie bereitgestellte Pipelines mithilfe von Nunit mit den gewünschten Tests auslösen. Sobald Sie mit den Ergebnissen zufrieden sind, können Sie die Pipeline abschließend in einer Produktionsinstanz veröffentlichen.

Bei Pipelineausführungen tritt nach der CI/CD-Bereitstellung oder Erstellungsupdates vorübergehend ein Fehler auf

Problem

Nach einiger Zeit werden neue Pipelineausführungen ohne Benutzeraktionen nach vorübergehenden Fehlern erfolgreich ausgeführt.

Ursache

Es gibt mehrere Szenarien, die dieses Verhalten auslösen können. Bei allen Szenarien wird eine neue Version einer abhängigen Ressource von der alten Version der übergeordneten Ressource aufgerufen. Angenommen, eine vorhandene untergeordnete Pipeline, die von „Execute Pipeline“ aufgerufen wird, wird aktualisiert, damit sie die erforderlichen Parameter erhält, und die vorhandene übergeordnete Pipeline wird aktualisiert, um diese Parameter zu übergeben. Wenn die Bereitstellung während der Ausführung einer übergeordneten Pipeline, aber vor der Aktivität Pipeline ausführen erfolgt, ruft die alte Version der Pipeline die neue Version der untergeordneten Pipeline auf, sodass die erwarteten Parameter nicht übergeben werden. Dies führt dazu, dass die Pipeline mit einem UserError fehlschlägt. Dies kann auch bei andersartigen Abhängigkeiten auftreten, z. B. wenn während einer Pipelineausführung, die auf einen verknüpften Dienst verweist, eine Breaking Change am verknüpften Dienst vorgenommen wird.

Lösung

Neue Ausführungen der übergeordneten Pipeline werden automatisch erfolgreich ausgeführt, sodass normalerweise keine Aktion erforderlich ist. Um diese Fehler zu vermeiden, sollten Kunden jedoch beim Erstellen und Planen von Bereitstellungen darauf achten, dass es bei Abhängigkeiten nicht zu Breaking Changes kommt.

Integration Runtime im verknüpften Dienst kann nicht parametrisiert werden

Problem

Notwendigkeit der Parametrisierung der verknüpften Dienstintegration zur Laufzeit

Ursache

Diese Funktion wird nicht unterstützt.

Lösung

Sie müssen manuell auswählen und eine Integrationslaufzeit festlegen. Sie können auch die PowerShell-API zum Ändern verwenden. Diese Veränderung kann nachgelagerte Auswirkungen haben.

Aktualisierung/Änderung der Integrationslaufzeit während CI/CD.

Problem

Ändern des Namens der Integrationslaufzeit während der CI/CD-Bereitstellung.

Ursache

Die Parametrisierung einer Entitätsreferenz (Integration Runtime in verknüpftem Dienst, Dataset in Aktivität, verknüpfter Dienst in Dataset) wird nicht unterstützt. Das Ändern des Namens der Runtime während der Bereitstellung führt dazu, dass die abhängige Ressource (Ressource, die die Integration Runtime referenziert) mit einem ungültigen Verweis versehen wird.

Lösung

Data Factory erfordert, dass Sie in allen Phasen von CI/CD denselben Namen und Typ der Integrationslaufzeit verwenden.

ARM-Vorlagenbereitstellung schlägt mit dem Fehler DataFactoryPropertyUpdateNotSupported fehl

Problem

Bei der Bereitstellung der ARM-Vorlage tritt ein Fehler wie dieser auf: „DataFactoryPropertyUpdateNotSupported: Das Aktualisieren des Eigenschaftstyps wird nicht unterstützt.“

Ursache

Das ARM-Template-Bereitstellung versucht, den Typ einer bestehenden Integrationslaufzeit zu ändern. Dies ist nicht zulässig und führt zu einem Bereitstellungsfehler, da die Data Factory in allen CI/CD-Stages denselben Namen und Typ der Integration Runtime erfordert.

Lösung

Wenn Sie Integration Runtimes über alle Stufen hinweg freigeben möchten, können Sie eine ternäre Factory verwenden, die nur die freigegebenen Integration Runtimes enthält. Diese freigegebene Factory können Sie in allen Umgebungen als verknüpften Integration Runtime-Typ verwenden. Weitere Informationen finden Sie unter Continuous Integration und Continuous Delivery in Azure Data Factory.

Die Git-Veröffentlichung schlägt aufgrund von PartialTempTemplates-Dateien möglicherweise fehl

Problem

Wenn sich im Ordner „PartialTemplates“ Tausende von alten temporären JSON-Dateien für ARM-Vorlagen befinden, kann die Veröffentlichung fehlschlagen.

Ursache

Bei der Veröffentlichung ruft ADF jede Datei in jedem Ordner im Kollaborationsbranch ab. In der Vergangenheit wurden bei der Veröffentlichung zwei Ordner im Branch für die Veröffentlichung generiert: PartialArmTemplates und LinkedTemplates. PartialArmTemplates-Dateien werden nicht mehr generiert. Da sich jedoch viele alte Dateien (Tausende) im Ordner „PartialArmTemplates“ befinden können, kann dies dazu führen, dass bei der Veröffentlichung viele Anforderungen an GitHub gestellt werden und das Ratenlimit erreicht wird.

Lösung

Löschen Sie den Ordner „PartialTemplates“, und führen Sie die Veröffentlichung erneut durch. Sie können auch die temporären Dateien in diesem Ordner löschen.

Option zum Einbeziehen globaler Parameter in ARM-Vorlagen funktioniert nicht

Problem

Wenn Sie eine alte Standardvorlage für die Parametrisierung verwenden, funktioniert die neue Methode zum Einbeziehen globaler Parameter von Manage Hub nicht.

Ursache

Die Standardparametervorlage sollte alle Werte der globalen Parameterliste enthalten.

Lösung

  • Verwenden Sie die aktualisierte Standardparametervorlage für die einmalige Migration zu einer neuen Methode zum Einbeziehen globaler Parameter. Diese Vorlage verweist auf alle Werte der globalen Parameterliste. Sie müssen auch die Bereitstellungsaufgabe in der Releasepipeline aktualisieren, wenn Sie die Vorlagenparameter bereits dort überschreiben.
  • Aktualisieren Sie die Vorlagenparameternamen in der CI/CD-Pipeline, wenn Sie die Vorlagenparameter dort bereits außer Kraft setzen (für globale Parameter).

Fehlercode: InvalidTemplate

Problem

Meldung: Der Aus kann nicht analysiert werden. Der im dynamischen Inhalt einer Aktivität übergebene Ausdruck wird aufgrund eines Syntaxfehlers nicht korrekt verarbeitet.

Ursache

Der dynamische Inhalt ist nicht den Anforderungen der Ausdruckssprache entsprechend geschrieben.

Lösung

  • Überprüfen Sie zur Debugausführung die Ausdrücke in der Pipeline im aktuellen Git-Branch.
  • Zur Triggerausführung überprüfen Sie die Ausdrücke in der Pipeline im Livemodus.

Zugehöriger Inhalt

Weitere Hilfe zur Problembehandlung finden Sie in den folgenden Ressourcen: