AEM as a Cloud Service SDK

Den AEM as a Cloud Service SDK består av följande artefakter:

• QuickStart JAR - AEM som används för lokal utveckling
• Java API Jar - Java Jar/Maven Dependency som visar alla Java API:er som kan användas för att utveckla mot AEM som Cloud Service. Tidigare kallad Uberjar
• Javadoc Jar - javadocs för Java API Jar
• Dispatcher Tools - Den uppsättning verktyg som används för att utveckla mot Dispatcher lokalt. Separata artefakter för unix och windows

Dessutom kommer vissa kunder som tidigare har distribuerats med AEM 6.5 eller tidigare att använda artefakterna nedan. Om den lokala kompileringen inte fungerar med Quickstart-behållaren och du misstänker att den beror på gränssnitt som har tagits bort från AEM as a Cloud Service, kontaktar du kundsupporten för att avgöra om du behöver åtkomst. Detta kräver ändringar i serverdelen.

• 6.5 Java API JAR har tagits bort - ytterligare en uppsättning gränssnitt som har tagits bort sedan AEM 6.5
• 6.5 Javadoc Jar har tagits bort - Javadocs för den ytterligare uppsättningen gränssnitt

Building for the SDK

AEM as a Cloud Service SDK används för att skapa och distribuera anpassad kod. Mer information finns i AEM Project Archetype-dokumentation. På en hög nivå utförs följande steg:

• Kompilera kod. Som förväntat kompileras källkoden och de resulterande innehållspaketen genereras
• Skapa artefakter. Artefakter skapas under den här processen
• Analysera paket. Paketen analyseras med Maven analyzer-pluginen som söker efter problem i Maven-projektet, till exempel saknade beroenden
• Distribuera artefakter. Artefakter distribueras till den lokala servern.

Samma steg utförs av Cloud Manager när du distribuerar till molnmiljöer. När du utför byggen lokalt kan du utveckla och testa lokalt så att utvecklarna effektivt kan identifiera kod- eller strukturproblem innan de bestämmer sig för källkontroll och utlöser driftsättningar i Cloud Manager, vilket kan ta längre tid.

Åtkomst till AEM as a Cloud Service SDK

• Du kan kolla den AEM Admin Console Om Adobe Experience Manager om du vill ta reda på vilken version av AEM du använder i produktionen.
• Verktygen quickstart jar och Dispatcher kan laddas ned som en zip-fil från Programdistributionsportal. Observera att åtkomsten till SDK-listorna är begränsad till dem som använder AEM Managed Services eller AEM as a Cloud Service miljöer.
• Java API Jar och Javadoc Jar kan laddas ned via maven-verktygen, antingen kommandoraden eller med den IDE du föredrar.
• Maven project poms ska referera till följande API Jar-paket. Det här beroendet ska också refereras i alla delpaketets omgångar.

<dependency>
  <groupId>com.adobe.aem</groupId>
  <artifactId>aem-sdk-api</artifactId>
  <version>2019.11.3006.20191108T223635Z-191201</version>
  <scope>provided</scope>
</dependency>

Uppdatera ett lokalt projekt med en ny SDK-version

När rekommenderas att det lokala projektet uppdateras med ett nytt SDK?

Det är rekommenderas att uppdatera den minst efter en månadsvis underhållsrelease.

Det är valfri för att uppdatera den efter en daglig underhållsrelease. Kunderna informeras när deras produktionsinstans har uppgraderats till en ny AEM. För de dagliga underhållsreleaserna förväntas inte att det nya SDK-värdet kommer att ha ändrats avsevärt, om något alls. Vi rekommenderar dock att du ibland uppdaterar den lokala AEM utvecklingsmiljön med den senaste SDK:n och sedan återskapar och testar det anpassade programmet. Den månatliga underhållsreleasen innehåller vanligtvis mer omfattande ändringar och utvecklare bör därför omedelbart uppdatera, återskapa och testa.

Nedan beskrivs den rekommenderade proceduren för uppdatering av en lokal miljö:

1. Se till att allt användbart innehåll antingen är implementerat i projektet i källkontrollen eller tillgängligt i ett ändringsbart innehållspaket för senare import
2. Lokalt utvecklingstestinnehåll måste lagras separat så att det inte distribueras som en del av molnhanterarens pipeline-bygge. Detta beror på att det bara behöver användas för lokal utveckling
3. Stoppa snabbstart som körs
4. Flytta crx-quickstart till en annan mapp för säker förvaring
5. Observera den nya AEM-versionen som beskrivs i Cloud Manager (används för att identifiera den nya QuickStart Jar-versionen som du kan ladda ned ytterligare)
6. Ladda ned QuickStart JAR vars version matchar Production AEM-versionen från Software Distribution Portal
7. Skapa en helt ny mapp och placera den nya QuickStart Jar i
8. Starta den nya QuickStart med de önskade körningslägena (antingen ändra namn på filen eller skicka i körningslägen via -r).
   • Kontrollera att det inte finns någon kvar av den gamla snabbstarten i mappen.
9. Bygg AEM
10. Distribuera AEM till lokala AEM via PackageManager
11. Installera alla ändringsbara innehållspaket som behövs för lokal miljötestning via PackageManager
12. Fortsätt med utvecklingen och distribuera ändringarna efter behov

Om det finns innehåll som ska installeras med varje ny AEM snabbstartversion, inkluderar du det i ett innehållspaket och i projektets källkontroll. Installera det sedan varje gång.

Rekommendationen är att uppdatera SDK ofta (t.ex. varannan vecka) och ta bort hela lokala tillstånd varje dag för att inte vara beroende av tillståndskänsliga data i programmet.

Om du är beroende av CryptoSupport (antingen genom att konfigurera autentiseringsuppgifterna för CloudServices eller SMTP Mail-tjänsten i AEM eller genom att använda CryptoSupport API i ditt program) krypteras de krypterade egenskaperna av en nyckel som genereras automatiskt första gången en AEM startas. Molnkonfigurationen tar hand om automatisk återanvändning av den miljöspecifika CryptoKey, men du måste injicera kryptonyckeln i den lokala utvecklingsmiljön.

Som standard är AEM konfigurerad att lagra nyckeldata i en mapps datamapp, men för att underlätta återanvändning under utvecklingen kan AEM initieras vid första starten med "-Dcom.adobe.granite.crypto.file.disable=true". Detta genererar krypteringsdata på "/etc/key".

För att kunna återanvända innehållspaket som innehåller de krypterade värdena måste du följa dessa steg:

• När du startar den lokala quickstart.jar ska du lägga till parametern nedan: "-Dcom.adobe.granite.crypto.file.disable=true". Vi rekommenderar att du alltid lägger till det, men det är valfritt.
• Första gången du startar en instans skapar du ett paket som innehåller ett filter för roten/etc/key". Detta håller hemligheten att återanvändas i alla miljöer som du vill att de ska återanvändas för
• Exportera muterbart innehåll som innehåller hemligheter eller leta upp krypterade värden via /crx/de för att lägga till det i paketet som ska återanvändas i alla installationer
• När du skapar en ny instans (antingen för att ersätta med en ny version eller för att flera utvecklingsmiljöer ska dela inloggningsuppgifterna för testning) installerar du paketet som skapats i steg 2 och 3 för att kunna återanvända innehållet utan att behöva konfigurera om det manuellt. Detta beror på att nu är kryptonyckeln synkroniserad.

Resurser för Business.Adobe.com