Der generische Wildcard-Fix ist klar: Sie ersetzen Webapi/<tabelle>/fields = * durch eine explizite Spaltenliste, bevor Microsoft am 14. September 2026 die Unterstützung für den Wildcard-Wert entfernt. Bei einer einzigen Tabelle widerspricht dieser Rat Microsofts eigener Dokumentation.
msdyn_richtextfile, die Attachment-Tabelle hinter dem Rich-Text-Editor-Control, hat ein Tutorial, das Ihnen genau den Wert empfiehlt, den die Deprecation-Notiz entfernt. Dieser Beitrag zeigt, warum diese Anweisung nicht einfach veraltet ist, was eine unvollständige Feldliste stillschweigend zerstört, und die vollständige Liste, falls Sie sie trotzdem enumerieren wollen.
Microsofts eigenes Tutorial sagt: Wildcard verwenden
Schritt 3.2 von "Configure the rich text editor control on Power Pages" listet die Site Settings, die für das Speichern von Bildern über den Rich-Text-Editor nötig sind:
| Site-Setting-Name | Wert |
|---|---|
| Webapi/msdyn_richtextfile/enabled | true |
| Webapi/msdyn_richtextfile/fields | * |
Kein Deprecation-Hinweis auf dieser Seite, kein alternativer Wert genannt. Gleichzeitig sagt der Deprecation-Artikel, der Wildcard-Wert lege alle Spalten offen und werde überall entfernt. Bei den meisten Tabellen ist das in der Praxis kein Widerspruch, weil Ihr eigener Code entscheidet, welche Spalten er liest und schreibt, und Sie genau diese auflisten können. msdyn_richtextfile ist anders: Der Konsument ist ein Closed-Source-PCF-Control, das je nach Aktion unterschiedliche Spalten anfragt. Ein Bild-Upload ist eine andere Anfrage als ein Datei-Upload, und Lesen ist eine andere Anfrage als Schreiben.
Hinweis: Dieser Beitrag beruht auf einer echten Fehlerbehebung, durchgeführt in einer produktiven Kundenumgebung im Rahmen der allgemeinen Wildcard-Bereinigung, kein Gedankenexperiment. Die Feldliste unten ist das, was den Fall behoben hat, verifiziert gegen die Dataverse-Metadaten, nicht aus dem Symptom geraten.
Zwei Blob-Spalten, zwei unterschiedliche Aufgaben
msdyn_richtextfile speichert Anhänge des Rich-Text-Editor-Controls über zwei getrennte Blob-Spalten:
msdyn_imageblob
Base64-Bildinhalt, direkt im Create-Payload gesetzt. Das nutzt ein eingefügtes oder per Drag-and-Drop abgelegtes PNG, JPG oder GIF.
msdyn_fileblob
Eine Datei-Spalte, in den Dataverse-Metadaten schreibgeschützt (IsValidForCreate: false, IsValidForUpdate: false). Hoch- und heruntergeladen über einen eigenen PUT/GET .../$value-Vorgang, nicht über den normalen Create-Body.
Genau dieser zweite Teil ist die Falle. msdyn_fileblob taucht nie als setzbares Feld in einem Create- oder Update-Payload auf, also fehlt es in einer Feldliste, die aus dem tatsächlichen Schreibverhalten des Controls abgeleitet wurde. Trotzdem muss die Spalte in Webapi/msdyn_richtextfile/fields stehen, weil der Datei-Spalten-Vorgang selbst anhand dieser Liste erlaubt oder blockiert wird, unabhängig davon, ob die Spalte über den normalen Payload schreibbar ist.
Was eine naheliegende Feldliste zerstört
Der generische Wildcard-Fix, angewendet ohne das obige Wissen, führt meist zu einer Feldliste, die aus dem sichtbaren Anwendungsfall abgeleitet ist, den Bild-Anhängen:
Webapi/msdyn_richtextfile/fields → msdyn_imageblob,msdyn_parentidBild-Anhänge, eingefügt oder per Drag-and-Drop als PNG, JPG oder GIF, funktionieren weiter. Bestehende Datei-Anhänge, PDF, XLSX, ZIP, lassen sich nicht mehr lesen. Neue lassen sich ebenfalls nicht anlegen, und beide Fehler stammen aus unterschiedlichen Code-Pfaden mit demselben Fehlercode:
Das ist der Lese-Pfad, auf msdyn_fileblob. Der Anlege-Pfad scheitert auf dieselbe Weise an einer anderen Spalte, msdyn_parententityname, die die verkürzte Liste ebenfalls ausließ. Zwei fehlende Felder, zwei Fehlermeldungen, beide mit dem HTTP-Fehlercode 90040101, beide aus demselben Site Setting.
Warnung: Dass Bild-Anhänge nach der Änderung weiterlaufen, ist keine Bestätigung, dass der Fix vollständig ist. Es sagt nur, dass der Bild-Pfad die entfernten Spalten nicht brauchte. Datei-Anhänge sind eine eigenständige, stille Regression, bis jemand versucht, eine zu öffnen.
Die vollständige Feldliste
Die schreibbaren Spalten von msdyn_richtextfile, laut Dataverse-Entity-Reference, plus die schreibgeschützte Datei-Spalte, die das Control trotzdem in der Liste braucht:
msdyn_richtextfileid,msdyn_name,msdyn_imageblob,msdyn_fileblob,msdyn_parententityname,msdyn_parententity_fieldname,msdyn_parentid,statecode,statuscodeDiese Liste deckt beide Anhang-Arten und beide Operationen ab, Lesen und Anlegen. Im beschriebenen Fall angewendet, funktionierten Bild- und Datei-Anhänge anschließend wieder in beiden Richtungen. Es ist auch kein Einzelfund: Dasselbe Muster einer verkürzten Liste tauchte bei einem zweiten, unabhängigen Portal wieder auf, mit einer zusätzlichen Falle, dort existierte die Tabelle als zwei separate Site-Setting-Datensätze mit unterschiedlichen GUIDs. Leicht zu übersehen, wenn Sie bei der Deprecation-Bereinigung nach Tabellennamen statt nach Site-Setting-Zeilen zählen.
Hinweis: Systemspalten wie OwnerId sind hier bewusst ausgeschlossen. Der Client setzt sie nie selbst, deshalb gehören sie nicht in eine Feldliste, die auf das begrenzt ist, was Ihr Code tatsächlich liest oder schreibt.
Wenn Sie es selbst herleiten wollen
Die Liste oben ist für das aktuelle Rich-Text-Editor-Control verifiziert, aber "Closed-Source-PCF-Control" bedeutet, dass Microsoft in einem künftigen Release ändern kann, was das Control anfragt, ohne es anzukündigen. Übernehmen Sie die Liste nicht blind, wenn Sie sie live prüfen können:
- Fragen Sie
EntityDefinitions(LogicalName='msdyn_richtextfile')/Attributesgegen die Dataverse Web API ab und lesen Sie schreibbare gegenüber schreibgeschützten Spalten direkt aus den Metadaten, statt aus einem Blogbeitrag. - Testen Sie beide Anhang-Pfade real: einen Bild-Anhang und einen Datei-Anhang, jeweils gelesen und neu angelegt. Vier Prüfungen, nicht zwei, weil Lesen und Anlegen unabhängig voneinander scheitern.
- Prüfen Sie auf doppelte Site-Setting-Datensätze für exakt denselben Tabellennamen, bevor Sie davon ausgehen, dass die Einstellung überall behoben ist.
- Wenn Sie sich beim Ergebnis nicht sicher sind: Lassen Sie
*für diese eine Tabelle bewusst als dokumentierte Ausnahme stehen, statt eine unvollständige Liste auszuliefern. Microsofts eigenes Tutorial deckt diese Entscheidung für genau diese Einstellung.
Dieser letzte Punkt zählt, weil die allgemeine Regel und diese Ausnahme gleichzeitig richtig sind, aus unterschiedlichen Gründen. Die generelle Wildcard-Entfernung schließt eine reale Angriffsfläche bei gewöhnlichen Tabellen. Diese eine Tabelle hat einen einzigen, Closed-Source-Konsumenten mit variablem Feldbedarf je nach Szenario, genau der Fall, den der allgemeine Rat nicht gut abdeckt.
Warum meine Care-Kunden das schon wussten
Der Fall hinter diesem Beitrag stammt aus genau dieser Art Fehlerbehebung: eine Tabelle einmal unvollständig fixiert, dann sauber korrigiert, nachdem der tatsächliche Feldbedarf gegen die Metadaten geprüft wurde statt angenommen. Genau diesen Unterschied macht eine systematische Prüfung, und das gehört jeden Monat zu Power Pages Care, nicht erst, wenn etwas sichtbar kaputt ist.
Ich kümmere mich um Ihr Portal, damit Sie es nicht müssen. Das ist kein Support-Vertrag mit einem Stundenkontingent. Vier Dinge passieren jeden Monat, unabhängig davon, ob gerade etwas los ist.
01 Sicherheits- und Konfigurationsprüfung
Table Permissions, Web Roles, Site Settings und Identitätskonfiguration systematisch geprüft.
02 Microsoft-Release-Check mit klarer Einschätzung
Ich lese die Release Notes und Deprecation-Hinweise, Sie bekommen die Einschätzung: Was Ihr Portal betrifft, was zu tun ist, was Sie ignorieren können.
03 Schriftlicher Monatsbericht
Status, Befunde, Empfehlungen, offene Punkte, in einer Form, die auch für Audit und Compliance funktioniert.
04 Kleinere Anpassungen inklusive
Ein Bugfix, eine Berechtigungsanpassung, eine Formularänderung. Größeres wird vorab abgestimmt.
Care kostet 1.290 Euro netto im Monat, mit 48 Stunden Reaktionszeit an Werktagen und Anpassungen bis zu zwei Stunden im Monat. Care Plus kostet 2.490 Euro netto und ergänzt einen vierteljährlichen Deep-Dive, der jeweils einen Audit-Bereich abdeckt, 24 Stunden Reaktionszeit, bei Sicherheitsvorfällen noch am selben Tag, und Anpassungen bis zu fünf Stunden. Mindestlaufzeit drei Monate, danach monatlich kündbar.
Sie wissen immer, wen Sie anrufen. Onepager und Konditionen unter powerportals.de. Fragen gehen direkt an [email protected].
Verwandte Artikel
Wildcard im Web API: Was am 14. September bricht und wie Sie es jetzt fixen
Der generische Fix: was das Setting macht, was bricht, und ein 10-Minuten-Selbstcheck für jede Tabelle Ihrer Website.
Artikel lesen → DevelopmentLiquid FetchXML vs. Web API in Power Pages
Ein Entscheidungsbaum, Performance-Vergleich und Security-Muster zwischen den zwei Datenzugriffs-Wegen in Power Pages.
Artikel lesen →Quellen
- Tutorial: Configure the rich text editor control on Power Pages, Schritt 3.2, Web-API-Site-Setting-Werte
- Rich Text Attachment (msdyn_richtextfile) table/entity reference, schreibbare Spalten
- Rich Text Attachment (msdyn_richtextfile) table/entity reference, schreibgeschützte Spalten, inklusive msdyn_fileblob
- Important upcoming changes and deprecations in Power Pages, Abschnitt "Wildcard value (*) in Web API field configuration"
- Compose HTTP requests and handle errors for the portals Web API, Fehlercode-Tabelle, Code 90040101
