Kom igång med AEM Headless getting-started

I den här delen av AEM Headless Developer Journey läs mer om vad som krävs för att ditt eget projekt ska komma igång med AEM Headless.

Story hittills story-so-far

I det föregående dokumentet om den AEM resan utan headless Läs om CMS Headless Development du lärde dig den grundläggande teorin om vad ett headless CMS är och du bör nu:

Den här artikeln bygger på dessa grundläggande funktioner så att du förstår hur du kan använda AEM för att implementera en headless-lösning.

Syfte objective

Det här dokumentet hjälper dig att förstå AEM Headless i ditt projekt. När du har läst bör du:

AEM Basics aem-basics

Innan du kan definiera ett headless-projekt i AEM är det viktigt att du förstår några grundläggande AEM.

Författarinstans author

AEM består av en författarinstans och en publish instance som tillsammans skapar, hanterar och publicerar ert innehåll.

Innehållet börjar på författarinstansen. Här skapar innehållsförfattare sitt innehåll. I författarmiljön finns olika verktyg som författare kan använda för att skapa, ordna och återanvända sitt innehåll.

Publiceringsinstans publish

När innehållet har skapats i författarinstansen måste det publiceras för att vara tillgängligt för andra tjänster att använda. En publiceringsinstans innehåller allt innehåll som har publicerats.

Replikering replication

Replikering innebär att överföra innehåll från författarinstansen till publiceringsinstansen. Detta görs automatiskt av AEM när en författare eller annan användare med lämplig behörighet publicerar innehåll.

Sammanfattning av AEM aem-basics-summary

På den enklaste nivån krävs följande steg för att skapa digitala AEM:

AEM Headless bygger vidare på denna tekniska grund med kraftfulla verktyg för att hantera headless-innehåll som som beskrivs i nästa avsnitt.

AEM utan rubriker - Grunderna aem-headless-basics

De headless-funktionerna i AEM bygger på några viktiga funktioner. Dessa förklaras i detalj i senare delar av resan. Det är nu bara viktigt att veta vad de gör och vad de kallas.

Modeller för innehållsfragment content-fragment-models

Modeller för innehållsfragment definierar strukturen för data och innehåll som du skapar och hanterar i AEM. De fungerar som en sorts ställningar för ert innehåll. När du väljer att skapa innehåll väljer författarna bland de innehållsfragmentsmodeller du definierar, som vägleder dem när de skapar innehåll.

Innehållsfragment content-fragments

Med Content Fragments kan du utforma, skapa, strukturera och publicera sidoberoende innehåll. De gör att du kan förbereda innehåll för användning på flera platser och i flera kanaler.

Innehållsfragment innehåller strukturerat innehåll och kan levereras i JSON-format.

API:er för GraphQL och REST apis

AEM erbjuder två kraftfulla API:er för att ändra ert innehåll utan problem.

Du kommer att lära dig mer om dessa API:er och hur du använder dem i en senare del av den AEM resan utan headless. Eller se ytterligare resurser för mer information.

Headless Integration Levels integration-levels

AEM har stöd för både den fullständiga headless-modellen och den traditionella fullstacksmodellen eller headful-modellen i ett CMS-system. AEM erbjuder inte bara dessa två exklusiva alternativ, utan även möjligheten att stödja hybridmodeller som kombinerar fördelarna med båda, vilket ger unik flexibilitet för ditt headless-projekt.

För att du ska få en förståelse för headless-koncept fokuserar den här AEM Headless Developer Journey på den rena headless-modellen så att du kommer igång så fort som möjligt utan att behöva skriva någon kod i AEM.

Du bör dock vara medveten om de extra hybridmöjligheterna som är öppna för dig när du väl förstår AEM headless-funktioner. Dessa fall beskrivs nedan för att du ska vara medveten om dem. I slutet av resan kommer du att få en mer detaljerad introduktion till dessa koncept om en sådan flexibilitet krävs för ditt projekt.

Du har redan en extern förbrukning av headless-innehåll som ett program på en sida (SPA). already-have-a-spa

Låt oss anta att ditt grundläggande krav är åtminstone att leverera innehåll från AEM till en befintlig, extern tjänst.

Nivå 1: Integrering av innehållsfragment - traditionell Headless-modell level-1

Den här integreringsnivån är den traditionella headless-modellen och gör det möjligt för innehållsförfattare att skapa innehåll i AEM och leverera det helhjärtat till valfritt antal externa tjänster med GraphQL eller redigera dem från externa tjänster med Assets API. Ingen kodning krävs i AEM.

I den här modellen används AEM bara för att skapa och leverera innehåll med AEM innehållsfragment. Återgivning och interaktion med innehållet delegeras till det uppladdande externa programmet, ofta ett ensidigt program (SPA).

Nivå 2: Bädda in SPA i AEM - hybridmodell level-2

Den här integreringsnivån bygger på den första nivån, men tillåter även att det externa programmet (SPA) bäddas in i AEM så att innehållsförfattarna kan visa innehållet i det externa programmet i AEM. Programmet har även stöd för begränsad redigering av det externa programmet i AEM.

Den här nivån har fördelen att innehållsförfattare kan skapa innehåll på ett flexibelt sätt i AEM med sitt innehåll som presenteras i sitt sammanhang med en inbäddad extern SPA, samtidigt som innehållet levereras utan problem.

Nivå 3: Bädda in och aktivera SPA fullständigt i AEM - hybridmodell level-3

Denna nivå av integration bygger på nivå två genom att göra det möjligt att redigera det mesta innehållet i det externa SPA i AEM.

Du har ännu inte någon extern konsument av det Headless-innehåll som ett program med en enda sida (SPA). do-not-have-a-spa

Om målet är att skapa en SPA som konsumerar innehåll i bakgrunden från AEM kan du använda funktioner som Content Fragments för att hantera ditt headless-innehåll och även skapa en SPA med AEM SPA Editor-ramverket.

Med SPA Editor konsumerar SPA inte bara innehåll från AEM, utan kan även redigeras i AEM av innehållsförfattarna, vilket ger dig både flexibiliteten med headless-leverans och kontextredigering inom AEM.

Krav och krav requirements-prerequisites

Det finns flera krav innan du börjar ditt AEM.

Kunskap knowledge

verktyg tools

Definiera ditt projekt defining-your-project

För varje framgångsrikt projekt är det viktigt att tydligt definiera inte bara projektets krav, utan även roller och ansvar.

Omfång scope

Det är viktigt att ha ett tydligt definierat utrymme för projektet. Med Omfång får du information om acceptanskriterier och du kan definiera det du gjort.

Den första frågan du måste ställa är"Vad försöker jag uppnå med AEM Headless?" Svaret bör i allmänhet vara att du har eller kommer att ha i framtiden ett upplevelseprogram som du har skapat med dina egna utvecklingsverktyg, inte med AEM. Det här upplevelseprogrammet kan vara en mobilapp, en webbplats eller någon annan kundupplevelseapplikation som vänder sig till slutanvändaren. Målet med AEM Headless är att mata in ditt upplevelseprogram med innehåll som skapas, lagras och hanteras i AEM med avancerade API:er som anropar AEM Headless för att hämta innehåll eller till och med fullständigt CRUD-innehåll direkt från ditt upplevelseprogram. Om detta inte är vad du vill göra, vill du antagligen gå tillbaka till AEM och hitta det avsnitt som bättre passar det du vill åstadkomma.

Roller och ansvarsområden roles-responsibilities

Rollerna för enskilda projekt varierar, men viktiga är de som ska beaktas i innehållet AEM headless Development:

Administratör administrator

Administratören ansvarar för systemets grundkonfiguration och konfiguration. Administratören kan t.ex. konfigurera din organisation i användarhanteringssystemet Adobe, som det hänvisas till Identity Management System (IMS). Administratören är den första användaren i organisationen som får en e-postinbjudan från Adobe när din organisation har skapats av Adobe i IMS. Administratören kan logga in på IMS och lägga till användare från andra profiler.

När användarna har konfigurerats av administratören får de behörighet att komma åt alla AEM resurser för att kunna utföra sitt arbete som medarbetare på att leverera upplevelseprogrammet med AEM Headless.

Administratören ska vara den användare som konfigurerar AEM och förbereder körningsmiljön för att aktivera innehållsförfattare att skapa och uppdatera innehåll och utvecklare för att använda API:er som hämtar eller ändrar innehåll för sina upplevelseprogram.

Innehållsförfattare content-author

Innehållsförfattare skapar och hanterar innehåll som levereras utan problem av AEM. Innehållsförfattare använder AEM funktioner som Content Fragments och Assets Console för att hantera sitt innehåll.

Innehållsförfattare bör ha följande i åtanke:

Översättningsplan translation

Planera för översättning i början av projektet. Se"Översättningsspecialist" som en separat person vars ansvar är att definiera vilket innehåll som ska översättas och vad som inte ska översättas, och vilket översatt innehåll som kan ändras av regionala eller lokala innehållsproducenter.

Skapa en plan för vilken innehållsöversättning du behöver.

Var tydlig med arbetsflödet för innehållsuppdatering. Vilken godkännandeprocess måste systemet stödja? Kan AEM arbetsflöden användas för att automatisera den här processen?

Observera att innehållshierarki kan användas för att underlätta översättning.

Se ytterligare resurser för ytterligare dokumentation om AEM arbetsflöden och översättningsverktyg, inklusive länkar till den AEM Headless Translation Journey.

Utnyttja innehållshierarkin content-hierarchy

Mapphierarkin kan hantera två viktiga problem när det gäller innehållshantering:

AEM ger en flexibel innehållsstruktur och en hierarki kan vara godtyckligt stor. Det är dock viktigt att komma ihåg att ändringar i mappstrukturen kan få oönskade konsekvenser för befintliga frågor som förlitar sig på innehållssökvägen. Därför kan en väldefinierad hierarki som är tydligt angiven i förväg vara till hjälp för innehållsförfattarna.

Mappar kan även begränsas till att endast tillåta vissa typer av innehåll (baserat på modeller för innehållsfragment). Vi rekommenderar att du alltid uttryckligen anger vilka modeller som tillåts för alla mappar i hierarkin. Ange tillåtet innehåll för en viss mapp:

Genom att skapa en lämplig innehållsstruktur blir det enklare att samordna redigering av headless-innehåll i olika kanaler för att maximera återanvändningen av innehåll. Genom att utnyttja innehåll i flera kanaler blir innehållsproduktionen effektivare och ändringshanteringen effektivare.

Upprätta praktiska namnkonventioner naming-conventions

Namn på innehållsfragment måste vara beskrivande för innehållsförfattare. AEM hanterar på ett genomskinligt sätt flytning och/eller trunkering av de namn som används i ID:n på databasnivå. Därför bör de logiska namn som tillhandahålls av innehållsförfattarna alltid vara läsbara och representera innehållet.

Se ytterligare resurser om du vill ha mer information om AEM namngivningskonventioner.

Öka inte innehållets kapsling content-nesting

Innehållsfragment används i AEM för att skapa headless-innehåll. AEM stöder upp till tio nivåer av innehållkapsling för innehållsfragment. Det är dock viktigt att komma ihåg att AEM måste tolka varje referens som definieras i det överordnade innehållsfragmentet iterativt och sedan kontrollera om det finns några underordnade referenser i alla jämställda. De här åtgärderna kan snabbt bli ett prestandaproblem.

Som en allmän tumregel får inte Content Fragment-referenser kapslas över fem nivåer.

Innehållsarkitekt content-architect

Innehållsarkitekterna analyserar kraven för de data som måste levereras utan problem och definierar strukturen för dessa data. Dessa strukturer kallas Modeller för innehållsfragment AEM. Modeller för innehållsfragment används som bas för de innehållsfragment som innehållsförfattarna skapar.

Ett användbart sätt att definiera modeller för innehållsfragment är att skapa modeller som mappar till UX-komponenterna i de program som använder innehållet.

Eftersom innehållsförfattarna interagerar med modellerna kontinuerligt när de skapar nytt innehåll kan man genom att anpassa modellerna till användargränssnittet visualisera den digitala upplevelsen. Om du går ett steg längre kan du tilldela ikoner till de modeller för innehållsfragment som representerar UX-elementet så att författarna intuitivt kan välja rätt modell baserat på visuella tecken.

Developer developer

Utvecklarna ansvarar för att sammanfoga det material som skapas direkt AEM till konsumenten, som ofta kan vara ett ensidigt program (SPA), ett progressivt webbprogram (PWA), en webbshop eller en annan tjänst som inte är AEM.

GraphQL fungerar som ett"glimt" mellan AEM och konsumenterna av headless-innehåll. GraphQL är det språk som AEM efter det nödvändiga innehållet.

Utvecklare bör tänka på några grundläggande rekommendationer när de planerar sina frågor:

För typisk headless-implementering med AEM, utvecklaren inte behöver ha någon kunskap om AEM.

Prestandakrav performance-requirements

För att ett projekt ska lyckas måste prestanda beaktas innan något innehåll skapas.

Se till att ni förstår vad era användare/besökare förväntar sig och hur ni utformar dem. Ange servicenivåmål (SLO) och mät dem för att förstå om du uppfyller användarens förväntningar.

Trafikmönster traffic-patterns

Att förstå trafik- och trafikmönster börjar med att samla det ni vet från det förflutna och sedan projicera till den förväntade tillväxten under de närmaste åren. Några av de viktigaste variablerna att tänka på:

Uppdateringsfrekvens update-frequency

Olika delar av upplevelsen har ofta olika frekvens för innehållsuppdateringar. Att förstå detta är viktigt för att kunna finjustera CDN och cachekonfigurationer. Detta är också viktigt för Innehållsarkitekter när de utformar modeller för att representera ert innehåll. Fundera:

What's Next what-is-next

Nu när du är klar med den här delen av AEM Headless Developer Journey ska du:

Du bör fortsätta den AEM resan utan trassel genom att nästa gång du granskar dokumentet Vägen till din första upplevelse med AEM utan headless där du får lära dig hur du ställer in de verktyg som behövs och hur du börjar fundera på att modellera data i AEM.

Ytterligare resurser additional-resources

Vi rekommenderar att du går vidare till nästa del av den headless-utvecklingsresan genom att granska dokumentet Vägen till er första upplevelse med AEM Headless, Nedan följer ytterligare, valfria resurser som gör en djupdykning i vissa koncept som nämns i det här dokumentet, men som inte behöver fortsätta på den headless-resan.