Power Pages Enterprise-Suche: React, Dataverse, Server Logic
Architektur einer Power Pages Enterprise-Suche mit React, Server Logic und Dataverse. Zuständigkeiten, Datenverträge und Sicherheitsgrenzen im Überblick.
Inhalt
- Wie ist eine Power Pages Enterprise-Suche aufgebaut?
- React in Power Pages mit Web Templates und JSON einbinden
- Wie verwaltet React Suchzustand und Filter in Power Pages?
- React und Power Pages über typisierte Schnittstellen verbinden
- Warum Power Pages Server Logic die Sicherheitsgrenze bildet
- Wie erzeugt Power Pages Server Logic sichere OData-Filter?
- Wie validiert React Dataverse-Antworten sicher?
- Power Pages Suchfilter mit URL, React und Browserhistorie synchronisieren
- React-Suchergebnisse in Power Pages mit CustomEvents entkoppeln
- Auto-Suggest in Power Pages mit React robust umsetzen
- Power Pages Detailsuche mit GUID und Liquid aufbauen
- Power Pages Favoriten mit mehreren GUIDs laden
- Alle Beiträge der Power Pages Enterprise-Suche
- Häufige Fragen zur Power Pages Enterprise-Suche
- Warum darf React in einer Power Pages Enterprise-Suche die Autorisierung nicht übernehmen?
- Wie schützt Power Pages Server Logic die Enterprise-Suche?
- Wie synchronisiert React Suchfilter in Power Pages mit URL und Browserhistorie?
- Wie funktioniert Auto-Suggest in Power Pages mit React?
- Wie lädt Power Pages Details anhand einer GUID?
- Wie lädt eine Power Pages Favoritenseite mehrere GUIDs?
- Power Pages Enterprise-Suche: Architektur und Projektkontext
Wie ist eine Power Pages Enterprise-Suche aufgebaut?
Eine komplexe Suche in Power Pages besteht nicht nur aus einem Eingabefeld und einer Ergebnisliste. Sie verbindet Seitentemplates, React Zustand, Browser Navigation, HTTP Requests, serverseitige Geschäftsregeln und Dataverse Verträge.
Ich habe diese Architektur für eine Enterprise-Suche umgesetzt. Die Anwendung verarbeitet Suchtext, Flächen, Standorttypen, Branchen, Ebenen und betriebliche Kennzahlen. Sie läuft auf einer Landingpage und auf einer Ergebnisseite mit unterschiedlichem Verhalten.
Der sichtbare React Teil ist wichtig. Die schwierigeren Entscheidungen liegen aber an den Grenzen zwischen den Systemen.
Welche Daten darf der Browser senden? Wer bestimmt die Autorisierung? Wie bleibt ein Suchzustand über Vor und Zurück erhalten? Wie erhalten andere Komponenten Ergebnisse, ohne Teil derselben React Anwendung zu werden?
Diese Serie dokumentiert jede dieser Entscheidungen einzeln. Dieser Beitrag bildet den gemeinsamen Architekturüberblick.
Die Architektur trennt drei Verantwortungsbereiche. React steuert die Bedienung. Server Logic kontrolliert die Sicherheitsgrenze. Die Dataverse Custom API verarbeitet nur die kontrollierte Anfrage.
Der Datenfluss verläuft vom Power Pages Host über React und den Controller zur Transport-Schicht. Server Logic bildet die autoritative Sicherheitsgrenze. Dataverse erhält nur geprüfte Parameter. Die typisierten Response Parser führen Such- und Suggestion-Ergebnisse zurück in das React Widget.
Komponente | Verantwortung | Besitzt nicht |
|---|---|---|
Power Pages Host | Mount Point, Bundle Pfad und kleiner Laufzeitvertrag | React Zustand und Backend-Regeln |
React Widget | Bedienung, Filterzustand, URL und sichtbare Fehler | Verbindliche Autorisierung |
Transport Adapter | Power Pages AJAX, Promises und Übergabe an Response Parser | Fachliche Filterentscheidungen |
Server Logic | Request-Prüfung, Nutzerkontext, Allowlists und OData Aufbau | Vertrauen in Browserwerte |
Dataverse Custom API | Fachliche Datenverarbeitung mit kontrollierten Parametern | Direkten Zugriff auf React oder Browserzustand |
Ergebnis-Consumer | Eigene Darstellung geprüfter Suchergebnisse | Interne Hooks und Context des Suchwidgets |
React in Power Pages mit Web Templates und JSON einbinden
Power Pages rendert den Host für das React Widget. Das Web Template besitzt den Mount Point, den Bundle Pfad und eine kleine JSON-Konfiguration.
Die aufrufende Seite entscheidet nur über das Verhalten. Eine Landingpage nutzt den Modus navigate. Eine Ergebnisseite nutzt update-url.
Die technische Umsetzung dieses Vertrags beschreibe ich im Beitrag zur modularen React Einbindung mit Web Templates und JSON-Konfiguration.
Diese Trennung hält kundenspezifische Sitemarker und Liquid Objekte aus dem React Projekt heraus. Das Bundle arbeitet nur mit einem geprüften Laufzeitvertrag.
Der Vertrag unterscheidet beide Seiten bewusst über den Laufzeitmodus:
type SearchSubmitBehavior =
| {
readonly type: 'navigate';
readonly targetUrl: string;
}
| {
readonly type: 'update-url';
readonly historyMode: 'push';
readonly eventName?: string;
};navigate wechselt nach der Filterprüfung zur Ergebnisseite. update-url hält den Zustand auf der Ergebnisseite in der URL und erweitert die Browserhistorie.
Aspekt | navigate | update-url |
|---|---|---|
Seite | Landingpage | Ergebnisseite |
Submit | Navigiert zur konfigurierten Ziel-URL | Erweitert URL und Browserhistorie |
Initialer Zustand | Lokaler Formularzustand | Aus Query-Parametern wiederhergestellt |
Vollständige Suche | Erst auf Ergebnisseite | Nach akzeptierter Zustandsänderung |
Browserhistorie | Normale Seitennavigation |
|
Wie ich zusätzlich editierbare Branchen-Gruppen als gemeinsames JSON bereitstelle, in React und JavaScript unabhängig prüfe und von der serverseitigen Allowlist trenne, zeigt der Beitrag über Power Pages React JSON Konfiguration.
Power Pages Web Templates bilden dafür die Plattformgrundlage. Microsoft beschreibt sie als wiederverwendbare Liquid Inhalte, die in andere Templates eingebunden werden können. Die Dokumentation zu Power Pages Web Templates erklärt dieses Modell.
Wie verwaltet React Suchzustand und Filter in Power Pages?
Nach dem Bootstrap übernimmt React die Bedienung.
Das Widget besitzt Komponenten für Suchtext, Flächen, Branchen und erweiterte Filter. Der Ablauf trennt vier konkrete Aufgaben:
- Die Komponenten halten den bearbeitbaren Formularzustand.
- Der Controller prüft die Eingaben und erzeugt normalisierte Filter, Query String und Backend Payload.
- Der Service ergänzt die Operation für Suche oder Vorschläge.
- Das Repository übergibt den fertigen Request an den Transport.
Diese Schichten sind keine allgemeine Pflicht für jede Power Pages Anpassung. Sie sind sinnvoll, weil dieselbe Suche mehrere Laufzeitmodi, viele Filter und verschiedene Ergebnisverbraucher unterstützt.
React trifft dabei keine serverseitige Sicherheitsentscheidung.
Der Browser darf Werte normalisieren, ungültige URL Parameter entfernen und verständliche Fehlermeldungen anzeigen. Diese Prüfungen verbessern die Bedienung. Sie ersetzen keine serverseitige Kontrolle.
Der Beitrag über typisierte React und Dataverse Schnittstellen zeigt die Aufgaben dieser Schichten im Code. Der Deep Dive zu URL und Browserhistorie erklärt, wie derselbe vorbereitete Vertrag Query String und Backend Payload zusammenhält.
React und Power Pages über typisierte Schnittstellen verbinden
Die React Anwendung kommuniziert nicht direkt mit einer Dataverse Tabelle. Sie nutzt ein kleines Transport Interface.
interface SearchTransport {
submitSearchFilters(request: SearchRequest): Promise<SearchResponse>;
fetchSuggestions(request: SuggestRequest): Promise<readonly Suggestion[]>;
}Die konkrete Implementierung verwendet webapi.safeAjax. Repository, Service und Controller kennen keine jQuery Details und keine Callback Struktur des Portals.
Dieser Adapter hält eine wichtige Grenze stabil. Die Anwendungsschichten arbeiten mit Promises und typisierten Verträgen. Nur der Transport kennt die Power Pages Laufzeit.
Wie Controller, Service, Repository, Transport und Laufzeitparser diesen Vertrag durchgängig halten, zeige ich im Beitrag über typisierte React und Dataverse Schnittstellen.
Jeder HTTP Request enthält eine ausdrückliche Operation. search startet eine vollständige Suche. suggest fordert nur Vorschläge an. getPortalCatalogDetails lädt bekannte Center- oder Area-GUIDs für Detail- und Favoritenansichten.
Das bestehende React Suchwidget konsumiert die ersten beiden Operationen. Der gemeinsame Endpoint-Vertrag typisiert alle drei Anwendungsfälle.
Die zentrale Server Logic bedient mehrere Einstiegspunkte über einen gemeinsamen Vertrag. Sie prüft und transformiert Requests, wählt die passende Operation und ruft Custom API sowie Plugin auf. Anschließend liefert sie je nach Anwendungsfall einen passenden JSON-Vertrag zurück.
Aspekt | search | suggest | getPortalCatalogDetails |
|---|---|---|---|
Auslöser | Ausdrückliche Suchaktion | Gültige Texteingabe nach Debounce | Favoritenseite oder bekannter GUID-Batch |
Request | Suchtext, Locale und unterstützte Filter | Locale und erforderlicher Suchtext | Entitätstyp, Sprache und 1 bis 50 IDs |
Ergebnis | Vollständiger Suchvertrag | Kleine geprüfte Vorschlagsliste | Aufgelöste Center- oder Area-DTOs mit Teilfehlerlisten |
URL Wirkung | Navigation oder Aktualisierung der Ergebnisseiten-URL | Keine Änderung | Keine Änderung durch den Endpoint selbst |
Auswahlverhalten | Angewendete Filter bestimmen Ergebnisse | Vorschlag setzt nur Suchtext | Aufrufer rendert gefundene Favoriten und behandelt fehlende IDs |
Warum Power Pages Server Logic die Sicherheitsgrenze bildet
Der Transport sendet den Request an Power Pages Server Logic.
Server Logic prüft den Body erneut. Die Implementierung akzeptiert nur JSON Objekte innerhalb einer festgelegten Größe. Sie erlaubt nur bekannte Operationen und normalisiert jeden unterstützten Filter unabhängig.
Die Autorisierung kommt nicht aus React. Server Logic leitet sie aus dem aktuellen Portalnutzer ab.
Damit kann ein manipulierter Browser keinen Wert wie isauthorized: true erzwingen. Der Browser übermittelt fachliche Filter. Der Server bestimmt den Sicherheitskontext.
Microsoft beschreibt Server Logic als serverseitige JavaScript Erweiterung für kontrollierte Datenoperationen und Integrationen. Die Übersicht zu Power Pages Server Logic nennt Webrollen, Tabellenberechtigungen und den serverseitigen Schutz vor direkter Einsicht im Browser.
Requests aus dem Browser benötigen außerdem einen CSRF Token. Die Dokumentation zum Aufruf von Server Logic zeigt dafür shell.safeAjax. Im bestehenden Portal stellt die globale Power Pages Abhängigkeit den verwendeten Wrapper als webapi.safeAjax bereit.
Wie Request-Größe, Operations Allowlist, serverseitige Autorisierung, OData Escaping und sichere Logs zusammenspielen, dokumentiere ich im Deep Dive zur Power Pages Server Logic Sicherheitsgrenze.
Wie erzeugt Power Pages Server Logic sichere OData-Filter?
Nach der Sanitization übersetzt Server Logic erlaubte Filter in die Parameter der Dataverse Custom API.
Das ist in dieser Architektur notwendig, weil der Vertrag der Custom API OData-Ausdrücke in objectfilter, areafilter und levelfilter verarbeitet. React sendet dagegen nur fachliche Werte wie Suchtext, Optionswerte und Zahlenbereiche. Server Logic übernimmt die kontrollierte Übersetzung zwischen beiden Verträgen.
Der entscheidende Teil der Implementierung sieht gekürzt und mit neutralisiertem Dataverse-Feldnamen so aus:
const objectClauses = [];
if (browserPayload.searchText) {
objectClauses.push(buildSearchTextClause(browserPayload.searchText));
}
addRangeClauses(objectClauses, 'dataverse_shop_count', browserPayload.shopCount);
if (objectClauses.length > 0) {
apiPayload.objectfilter = '$filter=' + objectClauses.join(' and ');
}Server Logic besitzt damit die Feldnamen, Operatoren und Verknüpfungen. Der Browser liefert nur zuvor geprüfte Kandidatenwerte. Mehrere Werte derselben Auswahl werden mit or gruppiert. Unterschiedliche Filtergruppen werden mit and verbunden.
Suchtext, Standorttypen und Kennzahlen werden so zu einem kontrollierten objectfilter. Flächengrenzen werden getrennt verarbeitet. Lokalisierte Ebenen erhalten einen eigenen Filtervertrag.
Zeichenketten werden vor der Verwendung in OData Literalen maskiert. Optionswerte kommen aus serverseitigen Allowlists. Numerische Werte werden gegen bekannte Domänen geprüft.
Ein wichtiger Grundsatz bleibt erhalten. Ein Filter wird nicht an die Custom API weitergegeben, solange sein akzeptierter Vertrag nicht bestätigt ist.
So bleiben Browserauswahl, serverseitige Prüfung und Dataverse Filter auf denselben Vertrag abgestimmt.
Der Deep Dive Power Pages Suchfilter validieren und OData sicher erzeugen zeigt den vollständigen Weg von der Support-Matrix über die Sanitization bis zur Zuordnung der drei OData-Parameter.
Wie validiert React Dataverse-Antworten sicher?
Die Custom API liefert eine verschachtelte Antwort. Power Pages Server Logic gibt einen Operationsvertrag zurück. Darin liegt die Antwort der Custom API. Deren Content enthält wiederum serialisiertes JSON.
Die React Anwendung vertraut auch diesem Rückweg nicht ungeprüft.
Parser kontrollieren:
- Die erwartete Operation
- Den Server Logic Datenumschlag
- Den Erfolgswert der Custom API
- Den Typ des
ContentFelds - Die benötigten Ergebnislisten
Eine falsche Datenform wird nicht in ein leeres erfolgreiches Ergebnis umgewandelt. Der Fehler bleibt sichtbar.
Der Parser bricht bereits beim falschen Operationsnamen oder einem fehlenden Inhaltsfeld ab:
const { data } = parseServerLogicOperationResult(value, 'search');
if (typeof data['Content'] !== 'string') {
throw new Error('Custom API data does not contain a string Content.');
}
return {
IsSucceeded: data['IsSucceeded'],
Content: parsePortalSearchResponse(data['Content']),
};Diese Entscheidung ist besonders wichtig, wenn mehrere Teams an Power Pages, Server Logic und Dataverse arbeiten. Ein stiller Ersatzwert würde Vertragsfehler verbergen.
Power Pages Suchfilter mit URL, React und Browserhistorie synchronisieren
Auf der Ergebnisseite lebt der Suchzustand in der URL.
Eine neue Suche verwendet pushState. Vor und Zurück lösen popstate aus. Das Widget liest die Filter erneut, bereinigt ungültige Werte und startet genau eine passende Suche.
Teilweise ungültige URLs bleiben nutzbar. Gültige Filter werden erhalten. Ungültige Werte werden entfernt. Die bereinigte URL ersetzt den aktuellen History Eintrag mit replaceState.
Fremde Query Parameter bleiben bestehen.
Dadurch lassen sich Suchzustände teilen, neu laden und über die Browser Navigation wiederherstellen.
Der Deep Dive Power Pages Suchfilter mit URL, React und Browserhistorie trennt Landing Navigation, neue Suchvorgänge, URL-Bereinigung und die Wiederherstellung durch popstate.
React-Suchergebnisse in Power Pages mit CustomEvents entkoppeln
Das Suchwidget muss nicht jede Ergebnisansicht selbst rendern.
Nach einer akzeptierten Suchänderung veröffentlicht es ein Browser Event mit Ursache, Filtern, Query String und URL. Nach einer erfolgreichen Antwort folgt ein zweites Event mit dem geprüften Ergebnisvertrag.
Vanilla JavaScript, jQuery oder eine weitere React Anwendung können diese Events abonnieren.
Das Suchwidget kennt dadurch keine konkrete Kartenansicht, Tabellenansicht oder Ergebnisliste. Die Consumer kennen keine internen Hooks und keinen React Context des Suchwidgets.
Der Zustandsvertrag bleibt klein und versionsfähig:
window.dispatchEvent(
new CustomEvent('ece:search-changed', {
detail: {
version: 1,
cause,
filters,
queryString,
url,
},
})
);Diese Entkopplung ist für Power Pages besonders nützlich. Bestehende Web Templates und neue React Anwendungen können denselben Ergebnisvertrag nutzen.
Der Deep Dive Power Pages React CustomEvents: Suchergebnisse entkoppeln trennt Zustandsänderung und Ergebnislieferung und zeigt Consumer in JavaScript, jQuery und React.
Auto-Suggest in Power Pages mit React robust umsetzen
Auto-Suggest nutzt denselben Server Logic Endpunkt, aber nicht denselben Ablauf wie eine vollständige Suche.
Nach drei Zeichen wartet die Oberfläche 300 Millisekunden. Eine neue Eingabe macht ältere Requests wirkungslos. Leere Vorschläge und technische Fehler bleiben unterschiedliche Zustände.
Die Auswahl eines Vorschlags setzt nur den Suchtext. Sie startet keine Navigation und keine vollständige Suche.
Diese Trennung verhindert versteckte Seiteneffekte. Freitext bleibt gültig, auch wenn kein Vorschlag gewählt wird.
Der Deep Dive Power Pages Auto-Suggest mit React: Debounce und Requests zeigt Debounce, Sequenzschutz, UI-Zustände, Suggestion-Gruppen und die getrennte Server-Operation im Detail.
Power Pages Detailsuche mit GUID und Liquid aufbauen
Eine Ergebnisliste kennt bereits die GUID eines Centers oder einer Fläche. Die Detailseite braucht trotzdem einen eindeutigen Vertrag.
Das Web Template liest id aus der URL und ergänzt entityType sowie die aktive Sprache. Der benannte Liquid Aufruf getPortalCatalogDetail prüft diese Werte, erzeugt den passenden Center- oder Area-Filter und ruft danach die Dataverse Custom API auf.
Server Logic gibt nicht den normalisierten Dataverse Antwortgraphen an Liquid weiter. Sie löst Ebenen, Merkmale, Flächen und Parent-Center vorher auf. Das Web Template kann dadurch direkte DTO-Eigenschaften verwenden.
Der Deep Dive Power Pages Detailsuche mit GUID, Server Logic und Liquid zeigt Einzelabruf, DTO-Auflösung und die drei Liquid Ergebniszustände.
Power Pages Favoriten mit mehreren GUIDs laden
Eine Favoritenseite besitzt mehrere bekannte IDs. Einzelrequests würden denselben Server Logic und Dataverse Ablauf für jede GUID wiederholen.
getPortalCatalogDetails akzeptiert deshalb einen Batch mit bis zu 50 Center- oder Area-IDs. Gültige GUIDs werden normalisiert und dedupliziert. Ungültige Werte und nicht gefundene Datensätze bleiben in getrennten Listen sichtbar.
Der Batch ist die dritte diskriminierte Operation des gemeinsamen HTTP Endpunkts. Liquid kann dieselbe fachliche Funktion über einen benannten Server Logic Aufruf verwenden.
Der Deep Dive Power Pages Favoriten mit Batch-GUIDs und Server Logic dokumentiert Request-Vertrag, OData Filter, Ergebnisreihenfolge und Teilfehler.
Alle Beiträge der Power Pages Enterprise-Suche
Die folgenden Beiträge dokumentieren Architektur, Implementierung und unabhängige technische Grenzen:
- Power Pages Enterprise-Suche: React, Dataverse, Server Logic
- Power Pages React Web Templates mit JSON-Konfiguration
- Power Pages Server Logic: React und Dataverse sicher verbinden
- Power Pages React und Dataverse typisiert verbinden
- Power Pages Suchfilter: URL, React und Browserhistorie
- Power Pages React CustomEvents: Suchergebnisse entkoppeln
- Power Pages Auto-Suggest mit React: Debounce und Requests
- Power Pages Suchfilter validieren und OData sicher erzeugen
- Power Pages JSON-Konfiguration: Liquid, React, JavaScript
- Power Pages Detailsuche mit GUID, Server Logic und Liquid
- Power Pages Favoriten mit Batch-GUIDs und Server Logic
Der gemeinsame Serientag Power Pages Enterprise-Suche bündelt alle Beiträge zur Architektur und ihren technischen Bausteinen.
Häufige Fragen zur Power Pages Enterprise-Suche
Warum darf React in einer Power Pages Enterprise-Suche die Autorisierung nicht übernehmen?
React läuft im Browser und kann von Portalnutzern verändert oder umgangen werden. Autorisierung muss deshalb aus dem aktuellen Portalnutzer und den serverseitig geltenden Berechtigungen abgeleitet werden. React darf Eingaben prüfen und verständliche Fehler anzeigen, ersetzt aber keine Server Logic.
Wie schützt Power Pages Server Logic die Enterprise-Suche?
Server Logic begrenzt Request-Größe und Operationen, normalisiert Filter, prüft Werte gegen Allowlists und erstellt erst danach kontrollierte Dataverse Parameter. Zusätzlich wird der Request mit einem CSRF Token abgesichert. Ungültige Daten werden als Fehler behandelt und nicht als leere Erfolgsliste ausgegeben.
Wie synchronisiert React Suchfilter in Power Pages mit URL und Browserhistorie?
Die Ergebnisseite speichert den Suchzustand in der URL. Neue Suchvorgänge verwenden pushState. Vor und Zurück lösen popstate aus. Der Parser entfernt ungültige Werte, erhält gültige Filter und ersetzt eine bereinigte URL mit replaceState.
Wie funktioniert Auto-Suggest in Power Pages mit React?
Auto-Suggest hat andere Anforderungen als eine vollständige Suche. Debounce, Request-Sequenzen, leere Vorschläge und technische Fehler benötigen eigene Zustände. Eine Auswahl setzt zunächst nur den Suchtext. Navigation und vollständige Suche bleiben getrennte Abläufe.
Wie lädt Power Pages Details anhand einer GUID?
Ein Web Template liest die GUID aus der URL und ergänzt entityType sowie Sprache. Die benannte Server Logic Funktion prüft den Vertrag, verwendet für Center objectfilter und für Flächen areafilter und liefert danach ein aufgelöstes DTO an Liquid.
Wie lädt eine Power Pages Favoritenseite mehrere GUIDs?
Der HTTP Endpunkt verwendet getPortalCatalogDetails als dritte Operation. Ein Request verarbeitet bis zu 50 IDs eines Entitätstyps. Die Antwort trennt gefundene DTOs, gültige aber fehlende IDs und syntaktisch ungültige Werte.
Power Pages Enterprise-Suche: Architektur und Projektkontext
Diese Serie basiert auf einer implementierten Enterprise-Suche in Power Pages.
Die ECE Fallstudie zur Enterprise-Suche zeigt den Projektkontext und den technischen Umfang. Die technischen Beiträge bleiben bewusst generalisiert.
Für den allgemeinen Einstieg erklärt mein Beitrag zur React Frontend Architektur in Power Pages, wann ein isoliertes React Widget sinnvoll ist.
Die Bereitstellung des gebauten Bundles dokumentiere ich getrennt im Beitrag zum automatisierten React Deployment mit PAC CLI.
Du arbeitest an einem Power Pages Workflow, der mehr als Standardformulare, Listen und einfache JavaScript Anpassungen benötigt? Im Power Pages Pro-Code Bereich zeige ich, wie ich Architektur, Sicherheitsgrenzen und Umsetzungsrisiken vor der Entwicklung kläre.
