Skapa och publicera arkitekturöversikt

På den här sidan beskrivs följande ämnen:

• Introduktion till publiceringsservrar
• Arkitektöversikt
• Registreringsprocess

Förutsättningar

Innan du börjar med författare och publiceringsservrar bör du ha kunskap om:

• AEM Topology
• Skapa och hantera AEM Screens Project
• Enhetsregistreringsprocess

Introduktion

AEM Screens arkitektur liknar en traditionell AEM Sites-arkitektur. Innehållet skapas på en AEM författarinstans och sedan vidarebefordras till flera publiceringsinstanser. AEM Screens-enheter kan nu ansluta till en AEM publiceringsgrupp via belastningsutjämnaren. Det går att lägga till flera AEM publiceringsinstanser för att fortsätta att skala publiceringsgruppen.

En AEM Screens-innehållsförfattare skapar till exempel ett kommando i redigeringssystemet för en viss enhet som är konfigurerad att interagera med en publiceringsgrupp eller en AEM Screens-innehållsförfattare som hämtar information om enheter som är konfigurerade att interagera med publiceringsgrupper.

I följande diagram visas författarmiljön och publiceringsmiljön.

Arkitektur

Det finns fem arkitektoniska komponenter som underlättar denna lösning:

• Replikera innehåll från författare till publicering för visning på enheter

• Återge replikering av binärt innehåll från publicering (mottaget från enheter) till författare

• Skicka kommandon från författaren till publicering via särskilda REST API:er

• Meddelanden mellan publiceringsinstanser för att synkronisera uppdateringar och kommandon för enhetsinformation

• Avfrågning från författaren av publiceringsinstanser för att få enhetsinformation via specifika REST API:er

Replikering (framåt) av innehåll och konfigurationer

Standardreplikeringsagenter används för att replikera skärmens kanalinnehåll, platskonfigurationer och enhetskonfigurationer. Detta gör det möjligt för författare att uppdatera innehållet i en kanal och eventuellt gå igenom något slags godkännandearbetsflöde innan kanaluppdateringar publiceras. En replikeringsagent måste skapas för varje publiceringsinstans i publiceringsgruppen.

I följande diagram visas replikeringsprocessen:

Skärmreplikeringsagenter och kommandon

Specifika replikeringsagenter för anpassade skärmar skapas för att skicka kommandon från författarinstansen till AEM Screens-enheten. AEM Publish-instanserna fungerar som en mellanhand för att vidarebefordra dessa kommandon till enheten.

Detta gör att författare kan fortsätta att hantera enheten, till exempel skicka enhetsuppdateringar och ta skärmbilder från redigeringsmiljön. AEM Screens replikeringsagenter har en anpassad transportkonfiguration, som vanliga replikeringsagenter.

Meddelanden mellan publiceringsinstanser

I många fall är det bara meningen att ett kommando ska skickas till en enhet en gång. I en belastningsutjämnad publiceringsarkitektur är det dock okänt vilken publiceringsinstans enheten ansluter till.

Därför skickar författarinstansen meddelandet till alla publiceringsinstanser. Sedan bör bara ett meddelande vidarebefordras till enheten. För att meddelandet ska bli korrekt måste viss kommunikation ske mellan publiceringsinstanser. Detta uppnås med Apache ActiveMQ Artemis. Varje publiceringsinstans placeras i en löst kopplad topologi med hjälp av Oak-baserad Sling-identifieringstjänst och ActiveMQ har konfigurerats så att varje publiceringsinstans kan kommunicera och skapa en enda meddelandekö. Enheten Skärmar avsöker publiceringsgruppen via belastningsutjämnaren och hämtar kommandot från köns övre del.

Omvänd replikering

I många fall, efter ett kommando, förväntas något svar från skärmenheten vidarebefordras till författarinstansen. För att uppnå detta AEM Omvänd replikering används.

• Skapa en omvänd replikeringsagent för varje publiceringsinstans, precis som standardsreplikeringsagenterna och skärmreplikeringsagenterna.
• En arbetsflödeskonfiguration lyssnar efter noder som ändrats på publiceringsinstansen och utlöser i sin tur ett arbetsflöde för att placera enhetens svar i publiceringsinstansens utkorg.
• En omvänd replikering i det här sammanhanget används bara för binära data (till exempel loggfiler och skärmbilder) som tillhandahålls av enheterna. Icke-binära data hämtas genom avsökning.
• Omvänd replikering som avfrågas från AEM författarinstans hämtar svaret och sparar det i författarinstansen.

Avsökning av publiceringsinstanser

Författarinstansen måste kunna avfråga enheterna för att få pulsslag och veta hälsostatusen för en ansluten enhet.

Enheter som pingar belastningsutjämnaren och dirigeras till en publiceringsinstans. Enhetens status visas sedan av publiceringsinstansen via ett publicerings-API (api/screens-dcc/devices/static) för alla aktiva enheter och api/screens-dcc/devices/<device_id>/status.json för en enskild enhet.

Författarinstansen avsöker alla publiceringsinstanser och sammanfogar enhetsstatussvaren till en enda status. Det schemalagda jobbet som avfrågar författaren är com.adobe.cq.screens.impl.jobs.DistributedDevicesStatiUpdateJob och kan konfigureras baserat på ett cron-uttryck.

Registrering

Registreringen fortsätter att ha sitt ursprung i AEM författarinstans. AEM Screens Device hänvisas till författarinstansen och registreringen är klar.

När en enhet har registrerats i redigeringsmiljön replikeras enhetskonfigurationen och tilldelningarna av kanaler/scheman till AEM publiceringsinstanser. AEM Screens-enhetskonfigurationen uppdateras sedan så att den pekar på belastningsutjämnaren framför AEM publiceringsgrupp. Detta är avsett att vara en engångskonfiguration, och när skärmenheten har anslutits till publiceringsmiljön kan den fortsätta att ta emot kommandon från författarmiljön och du behöver aldrig ansluta skärmenheten direkt till redigeringsmiljön.

Nästa steg

När du har lärt dig den arkitektoniska designen för författaren och publiceringsinställningarna i AEM Screens finns mer information i Configuring Author and Publish for AEM Screens.

Resurser för Business.Adobe.com

Auto Form Fill Targeted Content Asset Collections Web Content Management Dynamic Forms Content Management System