Verwende statt der “Item”-Ressource die “File”-Ressource, um deine Dateien zu finden. Dies stellt sicher, dass die zurückgegebenen IDs mit dem Download-Vorgang kompatibel sind.
Ersetze deinen ersten Node:
Ressource: File
Vorgang: List
Konfiguriere den Ordner:
Im “List”-Vorgang kannst du den Ordnerpfad oder die ID angeben. Da du /Shared Documents/Dana verwenden möchtest, stelle sicher, dass du auf diesen spezifischen Ordner abzielst.
Die Ausgabe:
Die id, die von Ressource: File → Vorgang: List zurückgegeben wird, ist die DriveItem ID.
Der Download-Node:
Übergib diese id direkt an Ressource: File → Vorgang: Download. Dies wird den 400 Bad Request-Fehler nun beheben.
Falls der integrierte “File → List”-Vorgang dir nicht die genaue Filterung gibt, die du benötigst, kannst du die Microsoft Graph API direkt verwenden. Dies ist oft zuverlässiger für tiefe Ordnerstrukturen.
Schritt 1: Dateien im Ordner auflisten Verwende einen HTTP Request Node:
@dana_bida die ID von Item → Get Many ist die List-Item-ID, aber Download erwartet die driveItem-ID, daher dein 400er-Fehler. Die einfachste Lösung ist, den Download-Node ganz zu überspringen – der Graph-children-Aufruf gibt dir bereits einen vorsignierten Download-Link pro Datei, daher einfach GET aufrufen, keine ID-Manipulation nötig:
SETZ_ID gegen die parentReference.siteId ersetzen, die du bereits in deiner Ausgabe siehst, verwen deine bestehenden SharePoint-OAuth-Anmeldedaten beim ersten Node wiederverwendet und die Auth beim Download-Node auf „Keine
Nachdem Sie die Dateiliste erhalten haben, fügen Sie einen Filter-Knoten hinzu, um Dateien zu filtern, die in der Antwort vorhanden sind (d. h. {{ $json.file }} ist nicht leer), um automatisch Unterordner aus Ihrer Schleife auszuschließen. Andernfalls schlägt der Download-Schritt bei Ordnerelementen fehl, die sich in die Antwort der untergeordneten Elemente einschleichen.