Komma igång med AEM Headless as a Cloud Service getting-started

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

Story hittills story-so-far

I det tidigare dokumentet om AEM resa utan rubriker Lär dig mer om CMS Headless Development lärde du dig grunderna i vad ett headless CMS är och du bör nu:

Den här artikeln bygger vidare på dessa grunder 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-koncept.

Författarinstans author

AEM består av en författarinstans och en publiceringsinstans som fungerar tillsammans för att skapa, hantera och publicera ditt 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.

Förhandsgranskningstjänst preview

Innan du publicerar till publiceringsinstansen kan du även publicera ditt innehållsfragment till förhandsgranskningstjänsten för testning och granskning. Detta görs från konsolen Innehållsfragment.

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 rätt behörighet publicerar innehåll.

AEM Basics Summary aem-basics-summary

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

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

Grundläggande om AEM Headless aem-headless-basics

AEM headless-funktioner 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. Med dem kan du förbereda innehåll som är klart 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å robusta API:er för att ändra ert innehåll utan problem.

Du lär dig mer om dessa API:er och hur du använder dem i en senare del av AEM resa utan att behöva ta hjälp av resurser. Du kan också läsa avsnittet ytterligare resurser nedan om du vill ha 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 en CMS. AEM erbjuder dock 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örstå headless-koncept fokuserar AEM Headless Developer Journey på den rena headless-modellen så att du kommer igång så fort som möjligt utan kodning i AEM.

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

Du har redan en extern förbrukning av headless-innehåll som ett SPA-program (Single page application). 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, som gör att skribenterna kan skapa innehåll i AEM och leverera det utan problem till valfritt antal externa tjänster med GraphQL eller redigera det 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 Content Fragments. Återgivning och interaktion med innehållet delegeras till det uppladdande externa programmet, ofta ett SPA-program (single page application).

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.

Denna nivå har fördelen att man på ett flexibelt sätt kan skapa innehåll i AEM med sitt innehåll presenterat i sitt sammanhang med en inbyggd extern SPA, samtidigt som innehållet fortfarande 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 av det externa SPA-innehållet inom AEM.

Du har ännu inte någon extern konsument av det Headless-innehåll som ett SPA-program (single page application). 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-ramverk.

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

Krav och krav requirements-prerequisites

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

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 förse ditt upplevelseprogram med innehåll som skapas, lagras och hanteras i AEM med toppmoderna 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-dokumentationen och hitta det avsnitt som passar bättre för det du vill uppnå.

Roller och ansvarsområden roles-responsibilities

Rollerna för enskilda projekt varierar, men det är viktigt att tänka på följande när det gäller innehållet i AEM headless Development:

Administratör administrator

Administratören ansvarar för systemets grundkonfiguration och konfiguration. Administratören kan t.ex. konfigurera din organisation i Adobe användarhanteringssystem, 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 få tillgång till 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 så att innehållsförfattare kan skapa och uppdatera innehåll, och utvecklare kan 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 det material som levereras headless av AEM. Innehållsförfattare använder AEM-funktioner som redigeraren för innehållsfragment och olika konsoler 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 denna process?

Din innehållshierarki kan användas för att göra översättningen enklare.

I avsnittet ytterligare resurser finns mer information om AEM-arbetsflöden och översättningsverktyg, inklusive länkar till AEM Headless Translation Journey.

Utnyttja innehållshierarkin content-hierarchy

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

AEM möjliggör 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 är beroende av 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 alla kanaler så att ni kan 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.

Mer information om namngivningskonventioner för AEM-sidor finns i avsnittet ytterligare resurser.

Öka inte innehållets kapsling content-nesting

Innehållsfragment används i AEM för att skapa rubrikfritt 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 Content Fragment Models i 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 i AEM med konsumenten, som ofta kan vara ett SPA-program (single page application), progressiv webbapp (PWA), webshop eller någon annan tjänst utanför AEM.

GraphQL är"limmet" mellan AEM och konsumenterna av headless-innehåll. GraphQL är det språk som används för att fråga AEM om nödvändigt innehåll.

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

För en vanlig headless-implementering med AEM behöver utvecklaren ingen kodkunskap om AEM.

Prestandakrav performance-requirements

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

Ni måste förstå era kunders/besökares förväntningar och design för 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ållsarkitekterna när de utformar modeller för ditt 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 bör du:

Du bör fortsätta din resa utan AEM genom att nästa gång granska dokumentet Path to Your First Experience Using AEM Headless där du får lära dig hur du konfigurerar 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 dokumentets sökväg till din första upplevelse med AEM Headless, men följande är ytterligare, valfria resurser som gör en djupdykning i vissa koncept som nämns i det här dokumentet, men de behöver inte fortsätta på den headless-resan.