Pimcore Product Experience Portal – Produktdaten selbstständig zugänglich machen.

Ein Product Experience Portal (PXP) ist eine der beiden Portal-Varianten, die Pimcores enterprise-only Bundle Portal Engine ermöglicht, unter dem Marketing-Namen "Experience Portals". Primärdaten sind hier Data Objects, also Produkte, mit den zugehörigen Assets. Zielgruppe sind Händler, Vertrieb und Partner, die Produktdaten browsen, filtern und exportieren sollen, ohne dafür einen Pimcore-Backend-Zugang zu bekommen.

Was ist ein Product Experience Portal genau?

Ein PXP baut auf Ihrem bestehenden Pimcore-Datenmodell auf: Produkt-Data-Objects mit ihren Attributen liefern die Facetten für die Suche, verknüpfte Assets liefern Bilder und Dokumente. Aufgebaut wird das Portal config-getrieben: Data Pools, Permission-Sets im Workspace-Konzept (organisiert nach Ordnerstruktur), Navigation, Filter und Theming entstehen als Konfigurationsdokumente im Backend, ergänzt um optionale Code-Anpassungen. Das unterscheidet ein PXP von einer klassischen Individualentwicklung: Der Großteil der Arbeit ist Konfiguration, kein Neubau eines Frontends von Grund auf.

Portal-Nutzer sind keine Backend-Nutzer

Ein zentrales, oft missverstandenes Detail: Portal-Nutzer sind eigene Data Objects vom Typ PortalUser, authentifiziert gegen eine eigene Portal-Firewall, keine regulären Pimcore-Backend-User. "10.000 Händler-Logins" berühren die Backend-Nutzerverwaltung deshalb überhaupt nicht: Portal-Zugänge bleiben vollständig vom Pimcore-Backend getrennt, ein Sicherheits- und Verwaltungsvorteil, keine Lizenzfrage (Pimcore kennt ohnehin kein nutzerbasiertes Lizenzmodell). Single Sign-on läuft über eine OpenID-Connect-Anbindung, kompatibel mit gängigen Identity-Providern wie Entra ID, Keycloak oder Okta.

Technische Voraussetzungen, die oft übersehen werden

Ein PXP hat harte Infrastruktur-Voraussetzungen, die vor Projektstart geklärt sein müssen: den Generic Data Index mit OpenSearch ab Version 2.7 oder Elasticsearch ab Version 8.0, dazu in der Regel Enterprise Asset Metadata und Statistics Explorer. Ohne laufenden Suchcluster gibt es kein funktionsfähiges Portal. Das ist der häufigste Grund, warum Portal-Projekte bereits in der Infrastruktur-Phase ins Stocken geraten, wenn das im Vorfeld nicht eingeplant wurde.

Features, die im Alltag den Unterschied machen

Faceted Search über indexierte Produktattribute, Download-Carts, die mehrere Produkte als ZIP zusammenfassen, öffentliche Token-Links mit Ablaufdatum und optionaler Zustimmung zu Nutzungsbedingungen, sowie Guest- oder offene Portale, auch diese bleiben über Guest-User und Berechtigungsregeln (PQL-Preconditions) permissioniert, nicht offen im Sinne von ungeschützt.

Wo Portal Engine an seine Grenzen stößt

Portal Engine ist ein konfigurierbares Produkt, kein Headless-Framework für pixelgenaues, komplett individuelles Design. Wer eine bespoke Frontend-Erfahrung ohne die Konventionen der Portal-Engine-Konfiguration braucht, ist mit einem eigenen Frontend auf Datahub oder dem Generic Data Index besser bedient. Ebenso wichtig: Portal-Permissions schützen die Portal-Oberfläche, nicht automatisch die rohen Asset-URLs dahinter. Ohne zusätzliche Webserver-Sperre bleiben direkte Asset-Links öffentlich erreichbar: ein Punkt, den wir in jedem Portal-Projekt explizit mitdenken, statt ihn stillschweigend vorauszusetzen.

Der Workshop vor der Konfiguration

Der häufigste Grund für Zeit- und Budgetüberschreitungen bei Portal-Projekten ist nicht die Konfiguration selbst, sondern ein übersprungener Requirements-Workshop: Welche Zielgruppen gibt es, welche Datenpools sehen sie, welche Permission-Matrix gilt pro Gruppe? Wir führen diesen Workshop bewusst vor der ersten Konfigurationszeile durch, nicht parallel dazu, derselbe Grundsatz wie in unserer Leistung Enterprise-Daten & MDM. Das kostet am Anfang etwas mehr Zeit und erspart im Projektverlauf genau die Nacharbeiten, die sonst entstehen, wenn eine Zielgruppen-Anforderung erst mitten in der Konfigurationsphase auftaucht.