Consent-Service-Registry in Power Pages aufbauen
Eine Consent-Service-Registry verbindet consentmanager mit Power Pages und React. Vendor-IDs, Snapshots und Events steuern jeden Dienst getrennt.
Inhalt
- Warum einzelne Skripte keinen gemeinsamen Einwilligungszustand haben
- Welche Konfiguration das Web Template vorgibt
- Wie die Registry Entscheidungen veröffentlicht
- Wie consentmanager die Registry synchronisiert
- Wann setConsent eine Entscheidung speichern darf
- Was bei Fehlern und später Registrierung geschieht
Warum einzelne Skripte keinen gemeinsamen Einwilligungszustand haben
Ich verbinde consentmanager und Power Pages über window.consentServices. Das Web Template ordnet jeden Dienst einer Vendor-ID zu. Die CMP Bridge synchronisiert die Einwilligungsdaten mit der Registry. React und normales JavaScript lesen denselben Snapshot mit Boolean-Werten, während jeder Dienst seinen eigenen Lifecycle behält.
Wenn jedes Script den CMP-Zustand selbst abfragt, entstehen getrennte Prüfungen in Liquid, Browser-JavaScript und React. Ein gemeinsamer Vertrag reduziert diese Kopplung. Die Architekturübersicht für Power Pages und React ordnet die Registry in die übrigen Zuständigkeiten ein.
Welche Konfiguration das Web Template vorgibt
Das Web Template hält die Zuordnung zwischen Registry-Schlüssel und Vendor-ID außerhalb des React Bundles. Die folgenden IDs sind anonymisierte Beispiele:
window.__CONSENT_SERVICES_CONFIG__ = {
applicationInsights: { vendorId: 'vendor-analytics' },
googleMaps: { vendorId: 'vendor-maps' },
};Die Power Pages React Web Template Konfiguration beschreibt den Host-Vertrag. Die Consent-Konfiguration bleibt davon getrennt.
Der Schlüssel applicationInsights benennt den Dienst im Browservertrag. Die vendorId verweist auf den zugehörigen Eintrag in consentmanager. Die CMP-Zuordnung von Vendoren und Cookies zu Zwecken ist eine getrennte Konfiguration. Die Dokumentation zur Vendor-Konfiguration in consentmanager beschreibt diese CMP-Seite.
Nach dem Inline-Kontext lädt das Web Template die drei Webfiles in dieser Reihenfolge:
<script src="~/consent-services.js"></script>
<script src="~/application-insights-consent.js"></script>
<script src="~/consentmanager-bridge.js"></script>Die Registry registriert zuerst konfigurierte Dienste. Der Application Insights Adapter ergänzt danach seine Lifecycle-Callbacks. Erst anschließend startet die Bridge die CMP-Synchronisierung.
Wie die Registry Entscheidungen veröffentlicht
Ein Adapter registriert seine Zuständigkeit über die Registry. Dieses Beispiel verwendet neutrale Konfiguration aus dem Web Template:
window.consentServices.registerService({
key: 'applicationInsights',
vendorId: window.__CONSENT_SERVICES_CONFIG__.applicationInsights.vendorId,
enable: window.initializeTelemetry,
disable: window.unloadTelemetry,
});getSnapshot() liefert einen eingefrorenen Boolean Snapshot für alle registrierten Dienste. Das eigene consentserviceschange Ereignis enthält den vollständigen Snapshot in event.detail. Fehlende oder noch nicht gelesene Vendor-Einwilligungen gelten als false. Die Registry kann das Ereignis auch bei einem unveränderten Snapshot erneut senden. Consumer sollten deshalb ihren Zustand aus event.detail ersetzen, statt bei jedem Ereignis einen Wert umzuschalten.
Ein Callback steuert den technischen Lifecycle. Der Snapshot beschreibt dagegen nur die Einwilligung. Ein Wert von true bestätigt nicht, dass ein SDK geladen wurde oder ein Dienst aktiv ist.
Die ECE Fallstudie zur Power Pages Enterprise-Suche ordnet die entwickelte Consent-Service-Registry in das umgebende Portal ein. Die Vendor-IDs in diesem Beitrag bleiben anonymisierte Beispiele.
Wie consentmanager die Registry synchronisiert
Die CMP Bridge wartet mit einem Intervall von 100 Millisekunden auf window.__cmp. Sie hat keinen Timeout. Sobald die öffentliche API verfügbar ist, registriert die Bridge Listener für settings und consent und startet eine erste Synchronisierung. Die Event-Dokumentation von consentmanager beschreibt diese Listener und Ereignisse. Die öffentliche JavaScript API von consentmanager dokumentiert __cmp und die verfügbaren Befehle.
Bei der ersten Synchronisierung und bei späteren Events ruft die Bridge einmal window.__cmp("getCMPData") auf und übergibt das Ergebnis an window.consentServices.synchronize(cmpData). Die Registry prüft vendorConsents[vendorId] === true, veröffentlicht sofort den vollständigen Snapshot und wartet danach auf die Lifecycle-Callbacks.
Die Grafik zeigt den initialen Sync nach der Listener-Registrierung und denselben Ablauf für spätere CMP-Events. Ein fehlender Vendor-Wert bleibt false. Das veröffentlichte true ist weiterhin nur Einwilligungsstatus. Es belegt nicht, dass ein SDK gestartet ist.
Wann setConsent eine Entscheidung speichern darf
setConsent() ist für eine ausdrückliche Nutzeraktion vorgesehen. Rufe die Methode erst auf, nachdem eine Person eine Einwilligungsoption gewählt hat. Ein automatischer Aufruf beim Seitenstart würde die Entscheidung nicht mehr an diese Aktion binden.
Die Registry ruft dafür setVendorConsent über die öffentliche __cmp API auf. Sie übergibt Vendor-ID und 1 oder 0, liest anschließend window.__cmp("getCMPData") erneut und synchronisiert die Registry. Ein manuell ausgelöstes consentserviceschange Ereignis speichert keine CMP-Entscheidung und ist kein Ersatz für setConsent().
Was bei Fehlern und später Registrierung geschieht
Ungültige Registrierungen, unbekannte Dienstschlüssel und ungültige CMP-Daten führen zu Fehlern. Schlägt ein Lifecycle-Callback fehl, protokolliert die Registry den Fehler in der Konsole. Sie ändert deshalb nicht die CMP-Entscheidung. Ein Snapshot kann also true bleiben, obwohl der Dienst nicht läuft.
Wird ein Dienst registriert, nachdem die Bridge bereits CMP-Daten gelesen hat, wertet die Registry ihn mit diesen aktuellen Daten erneut aus. So können später geladene React Widgets denselben Vertrag nutzen. Der Beitrag zu Google Maps in Power Pages mit React und Web Templates zeigt, wie die React-Anwendung und das JavaScript auf einer Detailseite diesen Status ohne Registry-Lifecycle-Callbacks nutzen.
Diese Aufteilung gibt jedem Team eine klare Schnittstelle, ohne CMP-Abfragen und Dienst-Lifecycles in jeder Komponente zu wiederholen. Im nächsten Deep Dive beschreibe ich den Application Insights Lifecycle und den Widerruf. Du erweiterst ein Power Pages Portal um externe Dienste? Lass uns die Zuständigkeiten gemeinsam prüfen.