När resurser migreras till Adobe Experience Managerfinns det flera steg att tänka på. Extrahering av resurser och metadata från det aktuella hemmet ligger utanför det här dokumentets omfång eftersom det varierar mycket mellan implementeringar, men i det här dokumentet beskrivs hur du överför dessa resurser till Experience Manager, använda sina metadata, generera renderingar och aktivera dem för publiceringsinstanser.
Granska och implementera vägledningen i Prestandajusteringstips för resurser. Många av stegen, som att konfigurera maximalt antal samtidiga jobb, förbättrar i hög grad serverns stabilitet och prestanda vid inläsning. Andra steg, som att konfigurera ett fildatalager, är mycket svårare att utföra efter att systemet har lästs in med resurser.
Följande verktyg för resursmigrering ingår inte Experience Manager och stöds inte av Adobe:
Programvaran är öppen källkod och täcks av Apache v2-licensen. Om du vill ställa en fråga eller rapportera ett problem går du till GitHub Issues for ACS AEM Tools eller ACS AEM Commons.
Migrera resurser till Experience Manager kräver flera steg och bör visas som en process i flera steg. Flyttningsfaserna är följande:
Inaktivera startprogrammet för DAM Update Asset arbetsflöde. Det är bäst att importera alla resurser till systemet och sedan köra arbetsflödena gruppvis. Om du redan är aktiv under migreringen kan du schemalägga att dessa aktiviteter körs på ledig tid.
Du kanske redan har en tagg-taxonomi på plats som du tillämpar på dina bilder. Medan verktyg som CSV-resursimporteraren och Experience Manager stöd för metadataprofiler kan automatisera processen att lägga till taggar i resurser, taggarna måste läsas in i systemet. The ACS AEM Tools Tag Maker kan du fylla i taggar med hjälp av ett Microsoft Excel-kalkylblad som läses in i systemet.
Prestanda och stabilitet är viktiga frågor när du ska hämta in resurser i systemet. Eftersom du läser in en stor mängd data i systemet bör du se till att systemet fungerar så bra som möjligt för att minimera tidsåtgången och undvika att överbelasta systemet, vilket kan leda till att systemet kraschar, särskilt i system som redan är i produktion.
Det finns två sätt att läsa in resurser i systemet: en push-baserad metod med HTTP eller en pull-baserad metod med JCR API:erna.
Adobe Managed Services-team använder ett verktyg som heter Glutton för att läsa in data i kundmiljöer. Glutton är ett litet Java-program som läser in alla resurser från en katalog till en annan katalog på en Experience Manager distribution. I stället för Glutton kan du också använda verktyg som Perl-skript för att publicera resurserna i databasen.
Det finns två nackdelar med att använda metoden att gå igenom https:
Det andra sättet att importera resurser är att hämta resurser från det lokala filsystemet. Om du inte kan få en extern enhet eller nätverksresurs monterad på servern för att utföra en pull-baserad metod är det bästa alternativet att publicera resurserna via HTTP.
The ACS AEM Tools CSV Asset Importer hämtar resurser från filsystemet och metadata för resurser från en CSV-fil för resursimporten. Experience Manager Asset Manager API används för att importera resurserna till systemet och använda de konfigurerade metadataegenskaperna. Resurser monteras helst på servern via en nätverksfilmontering eller via en extern enhet.
Eftersom resurser inte behöver överföras via ett nätverk förbättras prestandan avsevärt, och den här metoden anses generellt vara det mest effektiva sättet att läsa in resurser i databasen. Eftersom verktyget har stöd för metadatainmatning kan du dessutom importera alla resurser och metadata i ett enda steg i stället för att skapa ett andra steg för att använda metadata via ett separat verktyg.
När du har läst in resurserna i systemet måste du bearbeta dem via DAM Update Asset arbetsflöde för att extrahera metadata och generera återgivningar. Innan du utför det här steget måste du duplicera och ändra DAM Update Asset arbetsflöde som passar dina behov. Det färdiga arbetsflödet innehåller många steg som kanske inte är nödvändiga för dig, till exempel Dynamic Media PTIFF-generering eller InDesign Server integrering.
När du har konfigurerat arbetsflödet efter dina behov finns det två alternativ:
För distributioner som har en publiceringsnivå måste du aktivera resurserna i publiceringsgruppen. Adobe rekommenderar att du kör mer än en publiceringsinstans, men det är mest effektivt att replikera alla resurser till en publiceringsinstans och sedan klona den instansen. När du aktiverar ett stort antal resurser kan du behöva ingripa efter att ha aktiverat ett träd. Därför: När aktiveringar utlöses läggs objekt till i kön för Samling-jobb/händelse. När storleken på den här kön börjar bli över cirka 40 000 objekt tar det dramatiskt lång tid att bearbeta. När storleken på den här kön överstiger 100 000 objekt börjar systemstabiliteten försämras.
Du kan lösa det här problemet genom att använda Snabb Action Manager för att hantera resursreplikering. Detta fungerar utan att använda Sling-köerna, vilket sänker overheadkostnaderna samtidigt som arbetsbelastningen begränsas för att förhindra att servern blir överbelastad. Ett exempel på hur du använder FAM för att hantera replikering visas på funktionens dokumentationssida.
Andra alternativ för att hämta resurser till publiceringsgruppen är bland annat att använda vlt-rcp eller oak-run, som ingår i Jackrabbit. Ett annat alternativ är att använda ett verktyg som bygger på öppen källkod för Experience Manager infrastruktur anropad Grabbit, som sägs ha snabbare prestanda än Valt.
För någon av dessa metoder är caveat att resurserna i författarinstansen inte visas som aktiverade. Om du vill hantera flaggning av dessa resurser med rätt aktiveringsstatus måste du också köra ett skript som markerar resurserna som aktiverade.
Adobe stöder inte Grabbit.
När resurserna har aktiverats kan du klona publiceringsinstansen och skapa så många kopior som behövs för distributionen. Det är ganska enkelt att klona en server, men det finns några viktiga steg att komma ihåg. Så här klonar du publiceringen:
crx-quickstart/launchpad/felix
for sling.id
. Ta bort den här filen.repository-XXX
filer.crx-quickstart/install/org.apache.jackrabbit.oak.plugins.blob.datastore.FileDataStore.config
och crx-quickstart/launchpad/config/org/apache/jackrabbit/oak/plugins/blob/datastore/FileDataStore.config
för att peka på platsen för datalagret i den nya miljön.När vi är klara med migreringen är startarna för DAM Update Asset arbetsflödena bör återaktiveras för att stödja generering av återgivningar och extrahering av metadata för den dagliga systemanvändningen.
Även om det inte är nästan lika vanligt måste du ibland migrera stora mängder data från en Experience Manager distribuera till en annan, till exempel när du utför en Experience Manager uppgradera, uppgradera din maskinvara eller migrera till ett nytt datacenter, till exempel med en AMS-migrering.
I det här fallet är dina resurser redan ifyllda med metadata och återgivningar har redan genererats. Du kan helt enkelt fokusera på att flytta resurser från en instans till en annan. Vid migrering mellan Experience Manager utför du följande steg:
Inaktivera arbetsflöden: Eftersom du migrerar återgivningar tillsammans med våra resurser, vill du inaktivera arbetsflödets startprogram för DAM Update Asset arbetsflöde.
Migrera taggar: Eftersom du redan har taggar inlästa i källan Experience Manager kan du bygga dem i ett innehållspaket och installera paketet på målinstansen.
Migrera resurser: Det finns två verktyg som rekommenderas för att flytta resurser från ett Experience Manager distribution till en annan:
Aktivera resurser: Följ instruktionerna för aktivera resurser dokumenteras för den första migreringen till Experience Manager.
Klona publicering: Precis som med en ny migrering är det effektivare att läsa in en enda publiceringsinstans och klona den än att aktivera innehållet på båda noderna. Se Klonar publicering.
Aktivera arbetsflöden: När du har slutfört migreringen aktiverar du startprogrammet för DAM Update Asset arbetsflöde som stöder generering av renderingar och extrahering av metadata för löpande systemanvändning.