Massenmigrierung von Assets assets-migration-guide

Beim Migrieren von Assets nach Adobe Experience Manager sind verschiedene Schritte zu berücksichtigen. Das Extrahieren von Assets und Metadaten aus ihrem aktuellen Speicherort würde den Rahmen dieses Dokuments sprengen, da es zwischen den verschiedenen Implementierungen große Abweichungen gibt. In diesem Dokument wird jedoch beschrieben, wie diese Assets in Experience Manager übernommen, Metadaten zugewiesen, Ausgabedarstellungen generiert und für Veröffentlichungsinstanzen aktiviert werden.

Voraussetzungen prerequisites

Bevor Sie einen Schritt dieser Methodik tatsächlich ausführen, lesen Sie sich die Anleitungen in den Tipps zur Assets-Leistungsoptimierung durch und setzen Sie diese um. Viele der Schritte, z. B. die Konfiguration der maximalen Anzahl gleichzeitiger Aufträge, verbessern die Stabilität und Leistung des Servers unter Last erheblich.  Andere Schritte, wie das Konfigurieren eines Dateidatenspeichers, sind nach dem Laden des Systems mit Assets viel schwieriger durchzuführen.

Migrieren nach Experience Manager migrating-to-aem

Die Migration von Assets nach Experience Manager erfolgt in mehreren Schritten und sollte als stufenweises Verfahren angesehen werden. Die Migrationsphasen lauten wie folgt:

Deaktivieren von Workflows disabling-workflows

Deaktivieren Sie vor der Migration die Starter für den Workflow DAM-Update-Asset. Optimalerweise führen Sie die Workflows nach der Aufnahme aller Assets im System in Stapeln aus. Wenn Sie während der Migration bereits aktiv sind, können Sie diese Aktivitäten so planen, dass sie außerhalb der Arbeitszeiten ausgeführt werden.

Laden von Tags loading-tags

Womöglich verfügen Sie bereits über eine Tag-Taxonomie für Ihre Bilder. Zwar kann die Anwendung von Tags auf Assets mit Tools wie CSV Asset Importer und durch Experience Manager-Unterstützung für Metadatenprofile automatisiert werden, die Tags müssen dazu aber in das System geladen werden. Mit Tag Maker von ACS AEM-Tools können Sie Tags mithilfe einer in das System geladenen Microsoft Excel-Tabelle auffüllen.

Aufnehmen von Assets ingesting-assets

Bei der Aufnahme von Assets in das System sind Leistung und Stabilität von großer Bedeutung. Da Sie eine große Menge an Daten in das System laden, sollten Sie sicherstellen, dass das System gut funktioniert, um die erforderliche Zeit zu minimieren und eine Überlastung des Systems zu vermeiden, welche zu einem Systemabsturz führen kann, insbesondere bei Systemen, die bereits in Produktion sind.

Es gibt zwei Ansätze zum Laden der Assets in das System: einen Push-basierten Ansatz mit HTTP oder einen Pull-basierten Ansatz mit den JCR-APIs.

Senden über HTTP pushing-through-http

Das Managed Services-Team von Adobe lädt Daten mit einem Tool namens Glutton in Kundenumgebungen. Glutton ist eine kleine Java-Anwendung, die alle Assets von einem Verzeichnis in ein anderes Verzeichnis einer Experience Manager-Bereitstellung lädt. Statt Glutton können Sie auch Tools wie Perl-Skripts zum Posten der Assets in das Repository verwenden.

Der Push-basierte Ansatz mit HTTP hat zwei wesentliche Nachteile:

Der andere Ansatz bei der Aufnahme von Assets besteht darin, Assets aus dem lokalen Dateisystem abzurufen. Wenn Sie jedoch kein externes Laufwerk und keine Netzwerkfreigabe für einen Pull-basierten Ansatz auf dem Server bereitstellen können, ist die Veröffentlichung der Assets über HTTP die beste Option.

Abrufen aus dem lokalen Dateisystem pulling-from-the-local-filesystem

CSV Asset Importer von ACS AEM-Tools ruft Assets aus dem Dateisystem sowie Asset-Metadaten aus einer CSV-Datei zwecks Asset-Import ab. Die Experience Manager Asset Manager-API dient zum Importieren der Assets in das System und zum Anwenden der konfigurierten Metadateneigenschaften. Idealerweise werden Assets über eine Netzwerkdateibereitstellung oder über ein externes Laufwerk auf dem Server bereitgestellt.

Da Assets nicht über ein Netzwerk übertragen werden müssen, verbessert sich die Gesamtleistung erheblich, und diese Methode wird im Allgemeinen als die effizienteste Methode zum Laden von Assets in das Repository betrachtet. Da das Tool die Metadatenaufnahme unterstützt, können Sie alle Assets und Metadaten in einem Schritt importieren, anstatt einen zweiten Schritt zu erstellen, um die Metadaten über ein separates Tool anzuwenden.

Verarbeiten von Ausgabedarstellungen processing-renditions

Nachdem Sie die Assets in das System geladen haben, müssen Sie sie über den Workflow DAM-Update-Asset verarbeiten, um Metadaten zu extrahieren und Ausgabedarstellungen zu generieren. Vor diesem Schritt müssen Sie den Workflow DAM-Update-Asset duplizieren und an Ihre Anforderungen anpassen. Der vorkonfigurierte Workflow enthält möglicherweise eine Reihe von Schritten, die Sie nicht benötigen, so etwa die Dynamic Media PTIFF-Generierung oder die InDesign Server-Integration.

Wenn Sie den Workflow den Anforderungen entsprechend konfiguriert haben, stehen Ihnen zwei Optionen zur Ausführung zur Verfügung:

Aktivieren von Assets activating-assets

Bei Bereitstellungen mit einer Veröffentlichungsebene müssen Sie die Assets in der Veröffentlichungs-Farm aktivieren. Adobe empfiehlt zwar, mehr als eine Veröffentlichungsinstanz auszuführen, es ist jedoch am effizientesten, alle Assets in einer Veröffentlichungsinstanz zu replizieren und diese Instanz dann zu klonen. Wenn Sie eine große Anzahl von Assets aktivieren, müssen Sie nach dem Auslösen einer Strukturaktivierung möglicherweise eingreifen. Der Grund: Beim Auslösen von Aktivierungen werden Elemente der Sling-Auftrags-/Even-Warteschlange hinzugefügt. Wenn die Größe dieser Warteschlange etwa 40.000 Elemente überschreitet, verlangsamt sich die Verarbeitung drastisch. Wenn die Größe dieser Warteschlange 100.000 Elemente überschreitet, leidet die Systemstabilität.

Um dieses Problem zu umgehen, können Sie den Fast Action Manager zur Verwaltung der Asset-Replikation einsetzen. Dies funktioniert ohne die Sling-Warteschlangen. So wird der Overhead verringert und gleichzeitig die Arbeitslast reduziert, sodass eine Server-Überlastung verhindert wird. Ein Beispiel für die Verwendung des FAM zur Verwaltung der Replikation finden Sie auf der Dokumentationsseite der Funktion.

Zu weiteren Optionen zum Übertragen von Assets in die Veröffentlichungsfarm gehören u. a. vlt-rcp und oak-run, die als Tools mit Jackrabbit bereitgestellt werden. Eine andere Möglichkeit ist zudem Grabbit, ein Open-Source-Tool für Ihre Experience Manager-Infrastruktur, das schneller sein soll als vlt.

Bei jedem dieser Ansätze besteht der Nachteil darin, dass die Assets in der Autoreninstanz nicht als aktiviert angezeigt werden. Für die Kennzeichnung dieser Assets mit dem korrekten Aktivierungsstatus müssen Sie ein Skript ausführen, um die Assets als aktiviert zu markieren.

Klonen der Veröffentlichungsinstanz cloning-publish

Wenn die Assets aktiviert sind, können Sie Ihre Veröffentlichungsinstanz klonen, um so viele Kopien zu erstellen wie für die Bereitstellung erforderlich. Das Klonen eines Servers ist relativ einfach, es gibt jedoch einige wichtige Schritte, die zu berücksichtigen sind. So klonen Sie die Veröffentlichungsinstanz:

Aktivieren von Workflows enabling-workflows

Nach abgeschlossener Migration sollten die Starter für die Workflows DAM-Update-Asset neu aktiviert werden, um die Ausgabegenerierung und Metadatenextraktion für die laufende, tagtägliche Systemnutzung zu unterstützen.

Migrieren zwischen zwei Experience Manager-Bereitstellungen migrating-between-aem-instances

Wenn es auch nicht so häufig vorkommt, müssen dennoch manchmal große Datenmengen zwischen zwei Experience Manager-Bereitstellungen migriert werden, etwa wenn Sie ein Experience Manager- bzw. Hardware-Upgrade durchführen oder auf ein neues Rechenzentrum migrieren, wie bei der AMS-Migration.

In diesem Fall sind die Assets schon mit Metadaten aufgefüllt und Ausgabedarstellungen sind bereits generiert. Sie können sich einfach darauf konzentrieren, Assets von einer Instanz in eine andere zu verschieben. Führen Sie beim Migrieren zwischen zwei Experience Manager-Bereitstellungen die folgenden Schritte aus: