Die vorliegende Übersetzung wurde maschinell erstellt. Im Falle eines Konflikts oder eines Widerspruchs zwischen dieser übersetzten Fassung und der englischen Fassung (einschließlich infolge von Verzögerungen bei der Übersetzung) ist die englische Fassung maßgeblich. # Funktionen zur Datentransformation Jede der unten aufgeführten Funktionen wird beschrieben, was sie ist, wie sie funktioniert, welche Unterschiede zwischen C-CDA CSV-Quellen bestehen und wann sie verwendet werden sollten. + [Transformationsprofile und Versionierung](#data-transformation-profiles) + [KI-Agent für Datentransformation](#data-transformation-ai-agent) + [Synchrone (Echtzeit-) Transformation und Vorschau](#data-transformation-sync) + [(asynchrone) Massentransformationsaufträge](#data-transformation-bulk-jobs) + [Validierung](#data-transformation-validation) + [OID-to-URI Kartierung](#data-transformation-oid-mapping) + [Herkunft](#data-transformation-provenance) + [Erkennung von Abweichungen](#data-transformation-drift-detection) + [MCP-Zugriff](#data-transformation-mcp) ## Transformationsprofile und Versionierung Ein Transformationsprofil ist die wiederverwendbare Definition dafür, wie ein Quellformat in FHIR R4 konvertiert wird. Es enthält die Konvertierungslogik (Velocity-Vorlagen für C-CDA, eine YAML-Mapping-Konfiguration für CSV) und wird einmal erstellt und für alle Datenspeicher und Transformationsjobs in Ihrem Konto wiederverwendet. Wenn Sie die Definition (das Profil) von der Ausführung (Job) trennen, erstellen und testen Sie eine Konvertierung einmal und wenden dann dieselbe veröffentlichte Version auf eine beliebige Anzahl von Jobs an. ### Erstellen eines -Profils Sie können ein Profil auf eine von drei Arten erstellen: + Von einem Start- oder Basisprofil aus: Beginnen Sie mit einem Arbeitsprofil und nicht mit einem leeren. Denn C-CDA das AWS Starter-Profil ist ein vorgefertigtes AWS-defined Profil, das gängige C-CDA Dokumentenformate sofort verarbeitet. Für CSV stellen Sie bei der Erstellung des Profils Beispieldateien in Amazon S3 bereit und rufen dann den AI-Agenten auf, um sie zu analysieren und eine YAML-Mapping-Konfiguration zu generieren. + Durch Klonen: Klonen Sie ein vorhandenes Profil als Ausgangspunkt für ein neues. + Aus einem Roh-Mapping: Stellen Sie Velocity-Vorlagen (C-CDA) oder ein YAML-Mapping (CSV) direkt bereit. Dies ist der Pfad für die Bereitstellung versionskontrollierter Profile über eine CI/CD Pipeline (siehe). [Erste Schritte mit dem SDK und AWS CLI](data-transformation-getting-started-cli.md) **Wichtig** Beim Erstellen eines CSV-Profils wird der Beispielspeicherort SampleData registriert, der AI-Agent wird jedoch nicht ausgeführt. Um das YAML-Mapping zu generieren, müssen Sie es UpdateProfileWithAgent nach der Erstellung aufrufen. Zu diesem Zeitpunkt analysiert der Agent Ihre Beispieldateien und erstellt das Basisprofil. ### Der Versionslebenszyklus Ein Profil kann höchstens einen Entwurf und bis zu 99 veröffentlichte Versionen haben: + Ein neues Profil beginnt als Entwurf (Version 0): eine veränderbare Arbeitskopie, die Sie frei bearbeiten können. + Durch die Veröffentlichung des Entwurfs wird eine unveränderliche, nummerierte Version erstellt (v1, v2 usw., bis zu v99). Veröffentlichte Versionen ändern sich nie. + Transformationsaufträge werden immer für die neueste veröffentlichte Version ausgeführt. Da es sich bei dem Entwurf um einen separaten Entwurf handelt, können Sie die Bearbeitung fortsetzen, während die Produktionsaufträge für die zuletzt veröffentlichte Version ausgeführt werden: In Bearbeitung befindliche Änderungen wirken sich nie auf laufende Konvertierungen aus. + Ein Profil mit einer veröffentlichten Version und neueren unveröffentlichten Änderungen befindet sich in dem Status „Unveröffentlichte Änderungen“. Die veröffentlichte Version bleibt aktiv, bis Sie erneut veröffentlichen. ### Vergleich und Rollback Da jede veröffentlichte Version beibehalten wird, können Sie genau sehen, wie sich die Konvertierungslogik im Laufe des Versionsverlaufs geändert hat. Beim Rollback wird nichts gelöscht: Es erstellt eine neue Version aus einem vorherigen Snapshot, sodass der vollständige Verlauf und der Prüfpfad erhalten bleiben. ### Wann sollte die Versionierung verwendet werden Veröffentlichen Sie eine Version, bevor Sie einen Produktionsauftrag ausführen, damit der Job an die überprüfte Logik angeheftet ist. Verwenden Sie Rollback, wenn eine Änderung zu unerwarteten Ergebnissen führt, und vergleichen Sie, um zu überprüfen, was durch eine Änderung tatsächlich geändert wurde. ## KI-Agent für Datentransformation Mit dem Data Transformation AI-Agent entfällt der manuelle Aufwand für die Erstellung und Pflege von FHIR-Mappings. Anstatt die Konvertierungslogik von Hand zu schreiben, beschreiben Sie das gewünschte Ergebnis und der Agent erstellt oder aktualisiert die zugrunde liegende Logik: Velocity-Vorlagen für C-CDA, eine YAML-Mapping-Konfiguration für CSV. Der Agent ist in den Profileditor im eingebettet AWS-Managementkonsole und steht auch über die UpdateProfileWithAgent API und als MCP-Tool zur Verfügung, sodass Sie ihn im AWS-Managementkonsole, im Code oder in einer MCP-compatible IDE verwenden können. ### Was macht der Agent + Generiert Konvertierungslogik aus Ihren Daten. Bei CSV analysiert der Agent die Beispieldateien, die Sie bei der Profilerstellung bereitgestellt haben, und erstellt ein Basisprofil. Dabei werden die FHIR-Zielressourcen und -Felder abgeleitet, sodass Sie mit einem funktionierenden Entwurf und nicht mit einem leeren Profil beginnen. Denn C-CDA es passt das AWS Starter-Profil an Ihre Dokumente an. + Bearbeitet die Konvertierungslogik in natürlicher Sprache. Beschreiben Sie eine Änderung in einfacher Sprache und der Agent aktualisiert die zugrunde liegende Vorlage oder Zuordnung. Beispiel: + „Fügen Sie eine Zuordnung für die Medikamentenressource hinzu.“ + „Ordnen Sie die bevorzugte Sprache des Patienten im Bereich Sprache/Kommunikation zu.“ + „Stellen Sie Washington als Standardstatus für Patientenressourcen ein.“ + „Ordnen Sie die Spalte RACE\_CD einer FHIR-Erweiterung zu.“ + „Überspringt Datensätze, bei denen der Status fehlerhaft eingegeben wurde.“ + Erläutert und überprüft, bevor Sie sich bewerben. Der Mitarbeiter präsentiert Ihnen die vorgeschlagene Änderung als Abwandlung der betroffenen Vorlage oder Zuordnung zur Überprüfung und wendet sie erst an, nachdem Sie sie akzeptiert haben. Am veröffentlichten Profil ändert sich nichts im Hintergrund, der Agent nimmt nur Änderungen an der Entwurfsversion vor. + Verfeinert iterativ. Arbeiten Sie mit dem Agenten über mehrere Runden hinweg zusammen, um ein Mapping anzupassen, bis die konvertierte Ausgabe korrekt ist. Mit der Sync-Transform-API können Sie zwischen den Zügen eine Vorschau der Ergebnisse anhand der Beispieldaten anzeigen. ### C-CDA Arbeitsablauf (Velocity-Vorlagen) Der Agent bearbeitet die Velocity-Vorlagen, die definieren, wie C-CDA Abschnitte den FHIR-Ressourcen zugeordnet werden. Bitten Sie ihn, eine Ressourcenzuordnung hinzuzufügen, die Interpretation eines Abschnitts zu ändern, Standardwerte festzulegen oder eine Dokumentvariante zu behandeln, und er aktualisiert die Vorlagen und gibt einen Unterschied zurück. Vor der Veröffentlichung können Sie anhand von C-CDA Beispieldokumenten eine Vorschau der Konvertierung anzeigen. ### CSV-Workflow (YAML-Mapping) Wenn Sie ein CSV-Profil mit Beispieldateien erstellen und dann den Agenten aufrufen, analysiert er die Header, Beispielwerte und Datenmuster aus Ihren Dateien und schlägt dann eine YAML-Mapping-Konfiguration vor, die Folgendes umfasst: + Zuordnungen von Spalten zu FHIR-Feldern, + Erkennung von Datumsformaten und Neuformatierung in FHIR-Formate, date/time + Übersetzungen von Werten (zum Beispiel M → männlich, STATIONÄR → IMP), + primary/foreign-Schlüsselbeziehungen zwischen Tabellen, + Aggregationsregeln, die Zeilen untergeordneter Tabellen in FHIR-Arrays auf der übergeordneten Ressource zusammenfassen, + alle Annahmen, die der Agent getroffen hat, und alle Fragen, die er zu Ihren Daten hat. Sie akzeptieren, lehnen jede vorgeschlagene Zuordnung ab oder verfeinern sie und können den Agenten um weitere Anpassungen bitten. Der Agent leitet das Mapping anhand einer Stichprobe Ihrer Dateien und nicht anhand des vollständigen Datensatzes ab. Stellen Sie also Stichproben bereit, die für Ihre Daten repräsentativ sind, und überprüfen Sie das vorgeschlagene Mapping, bevor Sie es maßstabsgetreu konvertieren. ### Eingaben, die der Agent akzeptiert Sie können mit dem Agenten in natürlicher Sprache kommunizieren. Zu einigen Kombinationen gehören: + Anweisungen, + Beispielquelldaten (C-CDA Abschnitte oder CSV-Schemas), + Schema-Dokumentation, + FHIR-Validierungsfehler aus einer früheren Konvertierung. ### Manuelle Bearbeitung Sie müssen den Agenten nicht verwenden. Sie können Velocity-Vorlagen und YAML-Mappings jederzeit direkt bearbeiten und manuelle Änderungen mit von Agenten erstellten Änderungen auf demselben Profil kombinieren. ## Synchrone (Echtzeit-) Transformation und Vorschau Die synchrone Transformation konvertiert eine einzelne Eingabe und gibt sofort das FHIR-Ergebnis zurück, anstatt einen asynchronen Job über Amazon S3 auszuführen. Es dient zwei Zwecken: zum Testen eines Profils, während Sie es erstellen, und zum Ausführen kleiner, interaktiver Transformationen in einem Flow. request/response ### Funktionsweise + Sie reichen eine Eingabe (ein C-CDA Dokument oder eine Reihe von CSV-Dateien) anhand eines Profils ein und erhalten in der Antwort die konvertierten FHIR-Ressourcen als FHIR-Bundle. + Der Vorgang ist nur über die REST-API verfügbar: Er wird nicht als AWS CLI oder SDK-Befehl bereitgestellt. Siehe [Zugreifen auf den Data Transformation Agent](data-transformation.md#data-transformation-accessing). + Sie können die Drift-Erkennung bei einem Sync-Aufruf aktivieren, indem Sie den Wert auf true setzen DriftDetectionEnabled , um in der Antwort zu sehen, welche Quellenelemente ein Profil noch nicht erfasst. Dies ist nützlich bei der Iteration eines Mappings. ### Größenbeschränkungen Die synchrone Transformation akzeptiert C-CDA Eingaben bis zu 1 MB und kombinierte CSV-Eingaben bis zu 1 MB pro Anfrage. Verwenden Sie für größere Datensätze einen Massentransformationsjob. ### Vorschau im AWS-Managementkonsole Beim Erstellen eines Profils in der aktiviert die AWS-Managementkonsole synchrone Transformation die Live-Vorschau: Sie sehen die Quelle auf der einen Seite und die konvertierte FHIR-Ausgabe auf der anderen Seite, und die Vorschau wird aktualisiert, wenn Sie das Mapping verfeinern. Verwenden Sie diese Option, um vor der Veröffentlichung zu überprüfen, ob die Ausgabe korrekt ist. ### Wann sollte Sync statt Bulk verwendet werden Verwenden Sie die synchrone Transformation, um ein Profil anhand repräsentativer Dokumente zu validieren und latenzempfindliche Konvertierungen auf Anfrage durchzuführen, z. B. einen Live-Feed, der Dokumente konvertiert, sobald sie ankommen. Verwenden Sie einen Massentransformationsauftrag (unten) für große Datensätze und für die direkte Aufnahme in einen Datenspeicher. HealthLake ## (asynchrone) Massentransformationsaufträge Ein Massentransformationsauftrag konvertiert einen großen Datensatz aus Amazon S3 mithilfe eines veröffentlichten Profils und wird asynchron ausgeführt, während Sie den Fortschritt überwachen. Dies ist der Produktionspfad für Migrationen und für das Laden von Daten in einen Datenspeicher. HealthLake Informationen zur Einrichtung von IAM-Berechtigungen finden Sie [auf dieser Seite](https://docs.aws.amazon.com/healthlake/latest/devguide/getting-started-setting-up.html). ### Funktionsweise + Verweisen Sie einen Job auf ein Amazon S3 S3-Präfix von Quelldateien, wählen Sie ein veröffentlichtes Profil und wählen Sie ein Ausgabeziel aus. Der Job scannt die Eingabe, konvertiert jede Datei (C-CDA) oder jede Gruppe von Zeilen (CSV) und schreibt die Ergebnisse. + Es muss keine Infrastruktur bereitgestellt werden: Der Job wird automatisch skaliert. ### Ausgabemodi + Eigenständig: schreibt konvertiertes FHIR an einen Amazon S3 S3-Speicherort. Verwenden Sie die StartDataTransformationJob API. + Zusammengesetzt (konvertieren und aufnehmen): Konvertiert Quelldateien und nimmt die resultierenden FHIR-Ressourcen in einem einzigen Schritt direkt in einen HealthLake Datenspeicher auf, sodass die Daten sofort abgefragt werden können. Verwenden Sie die StartFHIRImportJob API mit den Parametern, und optional. ProfileId InputFormat DriftDetectionEnabled Der Datenspeicher muss sich im Status ACTIVE befinden. Ein vollständiges Beispiel finden Sie unter Schritt 7: Konvertieren und in einen HealthLake Datenspeicher aufnehmen. ### Reibungslose Fehlerbehandlung Fehlerhafte Eingaben werden übersprungen und protokolliert, anstatt dass der Batch fehlschlägt. Eine einzige fehlerhafte Datei verhindert also nie einen großen Job. Fehlgeschlagene Eingaben werden als JSON-Fehlerdateien mit dem Pfad der Eingabedatei und der Fehlermeldung geschrieben, sodass Sie sie überprüfen und erneut verarbeiten können. ### Ausgabelayout Der Service erstellt unter Ihrer Amazon S3-Ausgabe-URI unter Verwendung der Job-ID einen Ordner für den Auftragsbereich. In diesem Ordner: + konvertiert/: FHIR NDJSON-Ausgabedateien (eine pro Eingabedatei, z. B. -record.ndjson). converted/patient + ERROR/: Fehlerdetails für fehlgeschlagene Eingaben (JSON-Dateien mit den Feldern InputFile und errorMessage, z. B.). ERROR/bad-file.json + Manifest.json: Jobzusammenfassung mit aggregierten Kennzahlen (gescannte, konvertierte, fehlgeschlagene Dateien, generierte Ressourcen). + JobLevelDriftResult.json: der aggregierte Drift-Bericht für den Job, falls die Drift-Erkennung aktiviert war. + driftDetectionPerFileResults/: Für C-CDA Jobs mit aktivierter Drift-Erkennung werden Drift-Berichte pro Datei erstellt (z. B. driftDetectionPerFileResults/patient -record\_driftMetrics.json), sodass Sie die Abdeckung für eine einzelne Quelldatei überprüfen können und nicht nur für das Aggregat auf Jobebene. ### Überwachen Verfolgen Sie einen laufenden Job über die AWS-Managementkonsole Jobdetailseite oder die DescribeDataTransformationJob API: Status, verarbeitete Dateien (Zeilen für CSV), generierte Ressourcen und Fehler. Job-Metriken und Logs sind auch bei Amazon verfügbar CloudWatch. ## Validierung Der Data Transformation Agent validiert an mehreren Stellen im Konvertierungszyklus, sodass Probleme erkannt werden, bevor sie zu fehlgeschlagenen Konvertierungen oder nicht konformen Ergebnissen führen. + Quellenvalidierung: Überprüft, ob die C-CDA Eingaben wohlgeformt sind und der Spezifikation entsprechen. C-CDA Zu den Fehlern gehören Angaben zum Standort und Anleitungen zur Problembehebung, sodass Sie Probleme mit der Ursache beheben können, bevor Sie einen großen Auftrag ausführen. Der ValidateSource Vorgang ist über die REST-API verfügbar, sodass Eingaben im Voraus überprüft werden können. + Validierung von Vorlagen und Mappings: validiert die Velocity-Vorlagen (C-CDA) oder das YAML-Mapping (CSV) eines Profils unabhängig von Daten, sodass Sie überprüfen können, ob die Konvertierungslogik korrekt ist, bevor Sie einen Job veröffentlichen oder ausführen. + Ausgabe-FHIR-Validierung: Überprüft, ob die generierten Ressourcen FHIR R4 entsprechen, sodass nachgelagerte FHIR-APIs und Datenspeicher die Ausgabe akzeptieren. Zusammengenommen bedeutet dies, dass ein Job aus vermeidbaren Gründen seltener fehlschlägt: Bei der Quellenvalidierung werden fehlerhafte Eingaben erkannt, bei der Zuordnungsvalidierung wird schlechte Logik erkannt und bei der Ausgabevalidierung wird bestätigt, dass das Ergebnis standardkonform ist. ## OID-to-URI Kartierung C-CDA Dokumente identifizieren Codesysteme mithilfe von OIDs (Object Identifiers), d. h. älteren numerischen Identifikatoren wie `2.16.840.1.113883.6.1` (LOINC). FHIR erwartet moderne System-URIs wie. `http://loinc.org` Wenn OIDs ohne Zuordnung übertragen werden, sind die resultierenden Systemwerte nicht interoperabel und nachgeschaltete FHIR-Tools können die Codes nicht auflösen. Der Data Transformation Agent ordnet sie während der Konvertierung zu. + **Pre-built Zuordnungen**: Zuordnungen für gängige OIDs im Gesundheitswesen (z. B. LOINC, SNOMED CT, ICD-10, RxNorm) werden automatisch und ohne Konfiguration angewendet. + **Benutzerdefinierte Zuordnungen**: Fügen Sie Ihre eigenen OID-to-URI Zuordnungen für Codesysteme hinzu, die für Ihre Quellen spezifisch sind, damit proprietäre oder lokale Systeme korrekt aufgelöst werden. Dies gilt für C-CDA Quellen, bei denen OIDs die systemeigene Methode zur Identifizierung von Codesystemen sind. ## Herkunft Regulierte Arbeitsabläufe im Gesundheitswesen müssen die Frage beantworten, „woher diese Daten stammen und wie wurden sie produziert?“ für jede Ressource. Wenn Provenance für einen Job aktiviert ist, generiert der Data Transformation Agent für jede Konvertierung eine FHIR-Provenance-Ressource, sodass jede Ausgaberessource eine vollständige, abfragbare Herkunft zurück zu ihrer Quelle erhält. ### Die Provenienzkette Herkunft → DocumentReference → Quelldatei. Die Provenance-Ressource verweist auf a DocumentReference, das den Amazon S3 S3-URI der Quelldatei und eine SHA-1 Prüfsumme aufzeichnet. Mit der Prüfsumme können Sie nachweisen, dass die Ausgabe aus einer bestimmten, unveränderten Quelldatei abgeleitet wurde. Falls diese Informationen erforderlich sind, wird auch eine Geräteressource bereitgestellt, die die AWS HealthLake Datentransformation als Einheit darstellt. ### Record-level Locators Provenance gibt nicht nur die Quelldatei an, sondern auch die genaue Position darin, und der Locator unterscheidet sich je nach Quellformat: + **C-CDA**: ein XPath, der auf das Quellelement zeigt, von dem die Ressource abgeleitet wurde. + **CSV**: der Tabellenname, der Primärschlüssel und die Zeilennummer des Quelldatensatzes. ### Erfasste Felder Jede Provenance-Ressource zeichnet den URI und die Prüfsumme der Quelldatei, die für die Konvertierung verwendete Profilversion, einen Zeitstempel und den Locator auf Datensatzebene auf. ### Konformität und Verwendung Die Ressourcen für die Herkunft entsprechen dem zentralen Herkunftsprofil der USA, sodass sie mit den US-Tools zusammenarbeiten. Core-aware Aktivieren Sie die Herkunft, wenn Sie Prüfbarkeit zur Einhaltung von Vorschriften benötigen oder wenn Sie eine fragwürdige Ausgangsressource genau bis zu dem Quellelement zurückverfolgen müssen, aus dem sie stammt. Provenance ist standardmäßig aktiviert; setzen Sie sie ProvenanceEnabled auf False, um sie zu deaktivieren. ## Erkennung von Abweichungen Eine Konvertierung kann erfolgreich sein, wenn Quelldaten, denen ein Profil noch nicht zugeordnet ist, im Hintergrund gelöscht werden. Die Drifterkennung deckt diese Lücke auf. Es handelt sich um einen Bericht: Wenn diese Option aktiviert ist, vergleicht er, was die Quelle enthält, mit dem, was das Profil tatsächlich erzeugt hat, und zeichnet auf, was zurückgelassen wurde. ### Was der Bericht enthält + Die Gesamtabdeckungsrate für die Konvertierung. + Eine Rangfolge von Quellabschnitten und -elementen, die noch nicht zugeordnet wurden, sodass Sie die Lücken mit den größten Auswirkungen priorisieren können. + Alle erwarteten Ressourcen, die nicht produziert wurden. + Vollständige Rückverfolgbarkeit bis zur Quelldatei und zum Speicherort des Elements (Dateiname und OID für C-CDA, Zeile für CSV). ### Wie benutzt man die Drifterkennung Die Drifterkennung ist in beiden Konvertierungsmodi verfügbar, sodass Sie sie unabhängig davon verwenden können, ob Sie an einer einzelnen Datei iterieren oder einen vollständigen Datensatz validieren: + Synchronisieren (in Echtzeit): Wird bei einer TransformData Anfrage auf „true“ gesetzt DriftDetectionEnabled , um die Drifterkennung für eine einzelne Datei auszuführen und die Ergebnisse in der API-Antwort zurückzubekommen. Dies ist die schnellste Methode, um die Abdeckung zu überprüfen, während Sie ein Profil erstellen: konvertieren Sie ein repräsentatives Dokument, sehen Sie genau, was dem Profil entgangen ist, verfeinern Sie die Zuordnung und versuchen Sie es erneut. + Bulk (asynchron): Aktivieren Sie die Drifterkennung bei einem Transformationsjob, um die Abdeckung des gesamten Datensatzes zu messen. Der Bericht wird als Job LevelDriftResult.json in den Amazon S3 S3-Ausgabespeicherort des Jobs geschrieben. Bei C-CDA Aufträgen werden Drift-Berichte pro Datei ebenfalls in den Ordner driftDetectionPerFileResults/geschrieben, sodass Sie Deckungslücken in einer einzelnen Quelldatei lokalisieren können. ## MCP-Zugriff Das Model Context Protocol (MCP) stellt den Data Transformation Agent IDE-based KI-Agenten als aufrufbare Tools zur Verfügung, sodass ein Entwickler Profile erstellen, Konvertierungen durchführen und Fehler von einem Assistenten in seiner IDE untersuchen kann: ohne zum. AWS-Managementkonsole + Profil- und Job-Management-APIs: Alle Profil- und Job-Management-APIs von Data Transformation Agent sind als MCP-Tools verfügbar, sodass Sie Jobs von jedem Client aus erstellen, bearbeiten, veröffentlichen und ausführen können. MCP-compatible + Jeder MCP-Client: funktioniert mit MCP-compatible IDEs und Assistenten, einschließlich Kiro und Cursor. + Dauerhafte Sitzungen: Unterstützt Multi-Turn-Sitzungen, sodass eine Debugging- oder Autorenkonversation kontextbezogen ist. **Anmerkung** Der Synchronisierungsvorgang (TransformData) und die Quellenvalidierung (ValidateSource) sind MCP-Tools REST-only und werden möglicherweise nicht als solche angezeigt. Ihr Agent kann die REST-Aufrufe in Ihrem Namen erstellen und ausführen: Informationen zum Anforderungsformat finden Sie unter Schritt 3: Testen mit Synchronkonvertierung. Da MCP dieselbe API-Oberfläche wie die SDKs AWS CLI und die SDKs für Profil- und Auftragsoperationen verwendet, besteht für diese Workflows keine Funktionslücke zwischen der Arbeit in Ihrer IDE und der Bearbeitung von Code oder dem. AWS-Managementkonsole Informationen [Erste Schritte mit MCP](data-transformation-getting-started-mcp.md) zur Einrichtung und ein Beispiel für einen Arbeitsablauf finden Sie unter.