FetchXML Abfragegenerator

<FetchXmlBuilder> bearbeitet eine FetchXML-Abfrage, ohne dass jemand FetchXML schreibt. Es deckt die Teile der Sprache ab, auf die die Menschen tatsächlich zugreifen – die Tabelle, die zurückgegebenen Spalten, wie die Zeilen sortiert sind, und einen Filterbaum mit Bedingungen und verschachtelten Gruppen – und fügt zugehörige Tabellen hinzu, Aggregate und führt das aus, was es gebaut hat.

Nur reagieren, vorerst

Diese Komponente existiert nur auf dem React-Stack – es gibt noch kein Blazor-Äquivalent. Ein Blazor-Portal, das eine FetchXML-Abfrage speichern muss, kann dies dennoch tun; was es nicht hat, ist dieser Editor zum Erstellen eines solchen Stacks.

Probier es mal

Die eigentliche Komponente im Vergleich zu den Metadaten dieser Umgebung. Wähle eine Tabelle, füge eine Spalte oder eine Bedingung hinzu, joine eine zugehörige Tabelle und beobachte, wie das FetchXML-Panel Schritt hält – dann drücke Ausführen, um zu sehen, was die Abfrage übereinstimmt.

React-Beispiel
React TypeScript

Nicht dasselbe wie FetchXMLBuilder

Diese Seite handelt von der Komponente. FetchXMLBuilder ist die C#-Klasse, die dasselbe XML im Code zusammensetzt, für einen serverseitigen Aufrufer, der eine Abfrage manuell erstellt. Sie erzeugen das Gleiche und keiner benötigt den anderen.

Metadaten sind erforderlich, nicht optional

Jede Tabelle, Spalte und Beziehung wird aus dem ausgewählt, was die Umgebung tatsächlich hat. Das ist beabsichtigt: Ein logischer Name, der von Hand getippt wird, erzeugt FetchXML, das perfekt analysiert wird und dann gegen Dataverse fehlschlägt, was die schlimmste Art von Fehler ist, die man jemandem geben kann. Der usePowerPortalsProFetchXmlMetadata Haken verbindet den Builder mit den zwischengespeicherten Metadaten-Endpunkten des Frameworks, sodass die Picker alles teilen, was die Raster auf derselben Seite bereits abgerufen haben.

Die Abfrage-Roundtrips

Der Builder parst FetchXML in ein Dokumentmodell und schreibt es wieder heraus. Alles, wofür er keinen Editor hat – ein Attribut einer neueren Plattformversion, ein von einem anderen Tool geschriebenes Element – wird unberührt durchgetragen, anstatt beim Laden fallen zu lassen, sodass das Öffnen einer Abfrage im Editor und das Speichern eines Abschnitts nie einen Teil davon kostet.

Was das für eine gespeicherte Abfrage bedeutet

Die Formatierung bleibt nicht erhalten. Einzug und Attributquotierung werden beim Herausgehen normalisiert, sodass eine im Builder erneut gespeicherte Abfrage dieselbe Anfrage ist und nicht derselbe Text.

Bereitstellung einer Anfrage

Es gibt drei Zugänge, und alle drei laufen über denselben Leser:

  • Die Propeller value . Liefern Sie sie onChange für eine kontrollierte Komponente oder verwenden defaultValue Sie sie und lassen Sie den Bauherren über ihren Zustand verfügen.
  • Das GetchXML-Panel. Füge eine Abfrage ein oder tippe sie ein, und der Editor baut sich etwa eine Sekunde nach dem Tippen wieder auf.
  • Eine gespeicherte Ansicht. Starte mit einer Ansicht im Filter-Header, listet die Ansichten der Tabelle auf und übernimmt die gesamte Abfrage von der gewählten Ansicht. Es ist eine Kopie – nichts wird zurück in die Ansicht geschrieben.

Was auch immer eintrifft, wird zuerst überprüft. Fehlgeformtes XML wird mit Zeile und Spalte gemeldet, ebenso alles, was den Editor dazu bringen würde, etwas anderes anzuzeigen als das, was geschrieben wurde – einen Operator oder Linktyp, den er nicht kennt, eine Abfrage, die keine Tabelle nennt. Diese werden komplett abgelehnt und die bereits auf dem Bildschirm befindliche Abfrage bleibt unverändert. Alles andere wird gemeldet und weiterhin angewendet: ein falsch geschriebenes Element oder Attribut, zwei Tabellen mit gemeinsamem Alias, eine Bedingung, die von einem Alias liest, nichts deklariert.

Verwandte Tabellen

Ein Join wird vom Beziehungspicker hinzugefügt, sodass die from Spalten und to aus der Beziehung stammen und nicht aus dem Speicher. Was ein Join dann beitragen kann, hängt von seinem Typ ab:

  • Zurückgebende Typeninner, und matchfirstrowusingcrossapply outer — bringen die Spalten der zugehörigen Tabelle zurück, sodass ihre Spalten projiziert, sortiert und verglichen werden können.
  • Filtertypenexists, , inany, und not any all — geben die Zeile höchstens einmal zurück und keine der zugehörigen Spalten. Der Editor lässt den Alias fallen, wenn man zu einem Alias, sodass der Name für einen weiteren Beitritt frei ist.
  • Hat keine zugehörige Zeile und ist ein Preset statt eines Linktyps: FetchXML hat keine dafür, daher schreibt der Editor den äußeren Join und den Null-Test auf dem von der Plattform erwarteten joined-Schlüssel und hält beide Schritt beieinander.

Über "alle"

FetchXML bedeutet nicht das, was sein Name vermuten lässt – es ordnet Zeilen ab, die verwandte Zeilen all haben , von denen keine den Filter erfüllt, und not all wird als äquivalent zu anydokumentiert. Jeder Typ wird nach seiner Funktion und nicht nach seinem Namen beschriftet, und eine Invert conditions-Aktion in einer Filtergruppe drückt die Lesung aus, die die Leute normalerweise wollen.

Aggregierte Abfragen

Schalten Sie im Abschnitt Spalten Aggregate ein, und jede Spalte gibt an, was sie beiträgt – ein Wert, der über die Zeilen berechnet wird, oder das Element, nach dem sie gruppiert sind. Die angebotenen Funktionen verengen sich auf den Typ der Spalte, Aliase werden benötigt und werden für Sie ausgefüllt, eine gruppierte Datumsspalte erhält einen Datumsteil, und das Sortieren wechselt zu den Aliasen, weil die Zeilen einer aggregierten Abfrage Gruppen und berechnete Werte ohne Spalten zum Sortieren sind.

allowAggregate={false} zieht den Switch zurück, für einen Host, der Zeilen statt Totalen liest – eine Regel, die jeweils einen Datensatz bewertet, ein gespeicherter Filter, überall dort, wo eine einzelne Zeile berechneter Werte aussieht, wäre keine Antwort. Sie ist abwesend und nicht deaktiviert, da keine Änderung der Abfrage sie zurückbringen würde. Die eine Ausnahme ist eine Abfrage, die bereits aggregiert: Sie behält ihre Kontrollen, wie auch immer der Prop gesetzt ist, sodass eine, die in das FetchXML-Panel eingefügt wurde, weiterhin in eine gewöhnliche Abfrage zurückbearbeitet werden kann.

Montage eines Teils davon

Jeder Abschnitt kann ausgeschaltet werden, und die Abschnitte werden einzeln exportiert für ein Layout, das sie woanders benötigt – mounten <FetchXmlBuilderProvider> und platzieren Sie die FetchXml*Section Komponenten selbst. Das Weglassen eines Abschnitts entfernt dessen Benutzeroberfläche, niemals das zugrundeliegende FetchXML: Die Spalten einer Abfrage überleben unberührt mit columns: false.

Einschränkung der Tabellen

allowedTables schränkt den Tabellenwähler auf die logischen Namen ein, die du auflistest – für eine Oberfläche, die keine Aufgabe hat, die gesamte Umgebung abzufragen, wie ein Report Builder über die wenigen Tabellen, die ein Portal offenstellt. Lässt man es weg, wird jede Tabelle angeboten. Es schränkt ein, was ausgewählt werden kann, nicht was gezeigt werden kann: Eine Abfrage, die bereits eine Tabelle außerhalb der Liste nennt, behält sie, anstatt still umgeschrieben zu werden, und eine verwandte Tabelle wird immer noch nach ihrem Anzeigenamen benannt, wo ein Join sie erwähnt. Joins selbst sind nicht eingeschränkt, da sie Beziehungen folgen – eine Eigenschaft der bereits gewählten Tabelle.

Ausführung der Abfrage

Liefere renderResults und der Entwickler baut ein Ergebnispanel mit einem Ausführen-Button auf und entscheidet, wann es gedrückt werden darf. Das Anzeigen von Zeilen erfordert einen Daten-Client, von dem der Entwickler absichtlich keinen hat, sodass ein Ergebnis dein Aussehen ist – auf einem Portal, das normalerweise bedeutet, <MainGrid> dass das Framework über die zurückgegebene Abfrage steht. Lass den Prop aus, und das Panel ist nicht mehr da.

API