Pimcore Asset Experience Portal – Ihre Markenmedien, selbstständig abrufbar.

Ein Asset Experience Portal (AXP) ist die zweite Variante, die Pimcores enterprise-only Bundle Portal Engine ermöglicht (Schwesterprodukt zum Product Experience Portal, aber mit Assets statt Produkt-Data-Objects als Primärdaten). Zielgruppen sind Presse, Agenturen und Händler mit Medienbedarf: Sie sollen Bild-, Video- und Dokumentbestände selbst durchsuchen und in der passenden Auflösung oder Konvertierung herunterladen können.

Was ist ein Asset Experience Portal genau?

Ein AXP baut auf Pimcore als Digital Asset Management (DAM) auf: Assets, Metadaten-Schemata und Thumbnail-Renditions, die im System bereits gepflegt werden. Facetten für die Suche im Portal stammen aus Enterprise-Asset-Metadaten und System-Attributen wie Dateityp oder Erstelldatum. Der entscheidende Unterschied zu einem einfachen Datei-Sharing-Link: Downloads laufen über Format-Konvertierung: Original, benannte Thumbnail-Konfigurationen, individuelle Maße oder Metadaten-Exporte lassen sich direkt im Portal auswählen, ohne dass Ihr Team jede Anfrage manuell bearbeitet.

Berechtigungen, die auf Ihr Datenmodell abgestimmt sind

Asset-Pool-Permissions werden pro Workspace vergeben: Ansehen, Herunterladen, Bearbeiten, Aktualisieren, Erstellen, inklusive Upload mit optionalem Review-Routing –, Löschen, Unterordner verwalten oder die Einschränkung auf "nur eigene Assets". Ein Portal kann Asset- und Objekt-Pools kombinieren, etwa ein Markenportal, das Mediathek und Produktkatalog in einer Oberfläche zusammenführt, Details dazu auf der Seite zum Product Experience Portal.

Direct Edit als Companion für Kreativ-Workflows

Für Teams, die Assets direkt in Desktop-Anwendungen bearbeiten wollen, ergänzt ein Direct-Edit-Bundle das Portal: Assets öffnen sich über einen Client-Agent direkt in der lokalen Desktop-App, technisch vermittelt über Mercure. Das ist kein Ersatz für das Portal selbst, sondern eine Ergänzung für Kreativ-Workflows, in denen Öffnen-Bearbeiten-Speichern häufiger vorkommt als reines Durchsuchen und Herunterladen.

Technische Voraussetzungen

Wie beim Product Experience Portal gilt: Ohne den Generic Data Index mit OpenSearch (ab Version 2.7) oder Elasticsearch (ab Version 8.0) läuft kein AXP. Bei Multi-Node-Betrieb kommt eine weitere, oft übersehene Anforderung hinzu: geteilte Portal-Verzeichnisse für die Cart-ZIP-Assemblierung, damit Download-Carts über mehrere Server-Instanzen hinweg korrekt zusammengestellt werden.

Governance für rechtssichere Mediendistribution

Öffentliche Freigabelinks mit Ablaufdatum und optionaler Zustimmung zu Nutzungsbedingungen sind bei einem AXP kein Nice-to-have, sondern der Unterschied zwischen kontrollierter und unkontrollierter Markendistribution. Wer Pressebilder oder Handelspartner-Assets über zeitlich befristete, protokollierte Links statt über unbefristete Freigaben verteilt, hat im Streitfall eine belastbare Nachvollziehbarkeit: ein Argument, das in Markenrechts- und Compliance-Gesprächen regelmäßig unterschätzt wird.

Wo ein AXP an seine Grenzen stößt

Ein AXP ersetzt keine dedizierte Rights-Management- oder DRM-Lösung mit Lizenzverfolgung über Vertragslaufzeiten hinweg. Es ist ein Zugriffs- und Distributions-Portal auf Ihrem Pimcore-DAM, keine Rechteverwaltung im juristischen Sinn. Und wie beim Product Experience Portal gilt: Portal-Permissions schützen die Portal-Oberfläche, nicht automatisch die rohen Asset-URLs dahinter: eine zusätzliche Webserver-Sperre bleibt nötig, wenn Assets nicht direkt erreichbar sein sollen.

Warum wir Metadaten-Design vor die Portal-Konfiguration stellen

Ein Portal filtert ausschließlich über indexierte Metadaten. Wird das Metadaten-Schema erst während der Portal-Konfiguration nachträglich erweitert, entstehen doppelte Arbeit und Inkonsistenzen im bereits gepflegten Asset-Bestand. Wir bringen deshalb DAM-Tiefe, Metadaten-Schema, Thumbnail-Strategie, Facetten-Plan, und Portal-Konfiguration von Anfang an zusammen, statt sie nacheinander zu behandeln, so wie in jedem Enterprise-Daten & MDM-Projekt. Das ist der Punkt, an dem sich zeigt, ob ein Portal-Projekt sauber skaliert oder nach dem Launch ständig nachgebessert werden muss.