[Endast lokal/hybrid]{class="badge yellow" title="Gäller endast lokala och hybrida driftsättningar"}
Duplicera miljöer duplicating-environments
Introduktion introduction
Översikt overview
Adobe Campaign kräver installation och konfigurering av en eller flera miljöer: utveckling, testning, förproduktion, produktion osv.
Varje miljö innehåller en Adobe Campaign-instans och varje Adobe Campaign-instans är länkad till en eller flera databaser. Programservern kan köra en eller flera processer: nästan alla har direkt åtkomst till instansdatabasen.
I det här avsnittet beskrivs de processer som ska användas för att duplicera en Adobe Campaign-miljö, dvs. för att återställa en källmiljö till en målmiljö, vilket resulterar i två identiska arbetsmiljöer.
Gör så här:
-
Skapa en kopia av databaserna för alla instanser i källmiljön,
-
Återställ dessa kopior i alla instanser av målmiljön,
-
Kör autentiseringsskriptet nms:ezeInstance.js i målmiljön innan du startar det.
Den här processen påverkar inte servrarna och deras konfiguration.
note note NOTE I Adobe Campaign-sammanhang kombinerar en autentisering åtgärder som gör att du kan stoppa alla processer som interagerar med utsidan: loggar, spårning, leveranser, kampanjarbetsflöden osv.
Detta steg är nödvändigt för att undvika att leverera meddelanden flera gånger (en gång från den nominella miljön och en gång från den duplicerade miljön).note important IMPORTANT En miljö kan innehålla flera instanser. Varje instans av Adobe Campaign omfattas av ett licensavtal. Se licensavtalet för att se hur många miljöer du kan ha.
Med proceduren nedan kan du överföra en miljö utan att det påverkar antalet miljöer och instanser som du har installerat.
Innan du börjar before-you-start
För att den här processen ska fungera måste käll- och målmiljöerna ha samma antal instanser, samma syfte (marknadsinstans, leveransinstans) och liknande konfigurationer. Den tekniska konfigurationen måste uppfylla programvarukraven. Samma komponenter måste installeras i båda miljöerna.
Implementering implementation
Överföringsförfarande transfer-procedure
I det här avsnittet får du hjälp med att förstå de steg som krävs för att överföra en källmiljö till en målmiljö via en fallstudie: här återställer vi en produktionsmiljö (prod -instans) till en utvecklingsmiljö (dev -instans) så att den fungerar i ett sammanhang som är så nära den aktiva plattformen som möjligt.
Följande steg måste utföras med stor försiktighet: vissa processer kanske fortfarande pågår när källmiljöns databaser kopieras. Verifiering (steg 3 nedan) förhindrar att meddelanden skickas två gånger och upprätthåller datakonsekvensen.
- Följande procedur gäller för PostgreSQL-språk. Om SQL-språket är ett annat (till exempel Oracle) måste SQL-frågorna anpassas.
- Nedanstående kommandon används i kontexten för en prod -instans och en dev -instans under PostgreSQL.
Steg 1 - Säkerhetskopiera källmiljödata step-1---make-a-backup-of-the-source-environment--prod--data
Kopiera databaserna
Börja med att kopiera alla källmiljödatabaser. Åtgärden beror på databasmotorn och är databasadministratörens ansvar.
Under PostgreSQL är kommandot:
pg_dump mydatabase > mydatabase.sql
Steg 2 - Exportera målmiljökonfigurationen (dev) step-2---export-the-target-environment-configuration--dev-
De flesta konfigurationselement är olika för varje miljö: externa konton (mellanleverantörer, routning osv.), tekniska alternativ (plattformsnamn, databas-ID, e-postadresser och standard-URL:er osv.).
Innan du sparar källdatabasen i måldatabasen måste du exportera dev-konfigurationen (target environment). Det gör du genom att exportera innehållet i de här två tabellerna: xtkoption och nmsextaccount.
Med den här exporten kan du behålla dev-konfigurationen och bara uppdatera dev-data (arbetsflöden, mallar, webbprogram, mottagare osv.).
Det gör du genom att utföra en paketexport för följande två element:
- Exportera tabellen xtk:option till en 'options_dev.xml'-fil, utan posterna med följande interna namn: 'WdbcTimeZone', 'NmsServer_LastPostUpgrade' och 'NmsBroadcast_RegexRules'.
- I en 'extaccount_dev.xml'-fil exporterar du tabellen nms:extAccount för alla poster vars ID inte är 0 (@id <> 0).
Kontrollera att antalet exporterade alternativ/konton är lika med antalet rader som ska exporteras i varje fil.
Steg 3 - Stoppa målmiljön (dev) step-3---stop-the-target-environment--dev-
Du måste stoppa Adobe Campaign-processer på alla målmiljöservrar. Den här åtgärden beror på operativsystemet.
Du kan stoppa alla processer, eller bara de som skriver till databasen.
Om du vill stoppa alla processer använder du följande kommandon:
-
I Windows:
code language-none net stop nlserver6
-
I Linux:
code language-none /etc/init.d/nlserver6 stop
Använd följande kommando för att kontrollera att alla processer har stoppats:
nlserver pdump
Du kan även kontrollera att inga systemprocesser fortfarande körs.
Gör så här:
- I Windows: öppna Aktivitetshanteraren och kontrollera att det inte finns några nlserver.exe-processer.
- I Linux: kör ps aux | grep nlserver och kontrollera att det inte finns några nlserver -processer.
Steg 4 - Återställ databaserna i målmiljön (dev) step-4---restore-the-databases-in-the-target-environment--dev-
Använd följande kommando för att återställa källdatabaserna i målmiljön:
psql mydatabase < mydatabase.sql
Steg 5 - Skapa målmiljön automatiskt (dev) step-5---cauterize-the-target-environment--dev-
För att undvika felfunktioner får de processer som är länkade till leverans och körning av arbetsflöden inte köras automatiskt när målmiljön aktiveras.
Kör följande kommando för att göra detta:
nlserver javascript nms:freezeInstance.js -instance:<dev> -arg:run
Steg 6 - Kontrollera auktorisering step-6---check-cauterization
-
Kontrollera att den enda leveransen är den vars ID är inställt på 0:
code language-none SELECT * FROM neolane.nmsdeliverypart;
-
Kontrollera att leveransstatusuppdateringen är korrekt:
code language-none SELECT iState, count(*) FROM neolane.nmsdelivery GROUP BY iState;
-
Kontrollera att statusuppdateringen för arbetsflödet är korrekt:
code language-none SELECT iState, count(*) FROM neolane.xtkworkflow GROUP BY iState; SELECT iStatus, count(*) FROM neolane.xtkworkflow GROUP BY iStatus;
Steg 7 - Starta om webbprocessen för målmiljön (dev) step-7---restart-the-target-environment-web-process--dev-
Starta om Adobe Campaign-processerna för alla servrar i målmiljön.
Kör följande kommando för att starta webbprocessen:
nlserver start web
Använd följande kommando för att kontrollera att bara webbprocessen har startat:
nlserver pdump
Kontrollera åtkomsten till klientkonsolfunktionerna.
Steg 8 - Importalternativ och externa konton i målmiljön (dev) step-8---import-options-and-external-accounts-into-the-target-environment--dev-
Kontrollera framför allt värdena för flera rader i filerna innan du importerar (till exempel: 'NmsTracking_Pointer' för alternativtabellen och leverans- eller mellanleverantörskonton för den externa kontotabellen)
Så här importerar du konfigurationen från målmiljödatabasen (dev):
-
Öppna administrationskonsolen för databasen och rensa de externa konton (tabell nms:extAccount) vars ID är 0 (@id <> 0).
-
I Adobe Campaign-konsolen importerar du det options_dev.xml-paket som tidigare skapats via importpaketsfunktionen.
Kontrollera att alternativen verkligen har uppdaterats i noden Administration > Platform > Options.
-
I Adobe Campaign-konsolen importerar du den extaccount_dev.xml som tidigare skapats via importpaketsfunktionen
Kontrollera att externa databaser verkligen har importerats i Administration > Platform > External accounts.
Steg 9 - Starta om alla processer och ändra användare (dev) step-9---restart-all-processes-and-change-users--dev-
Så här startar du Adobe Campaign-processerna:
-
I Windows:
code language-none net start nlserver6
-
I Linux:
code language-none /etc/init.d/nlserver6 start
Använd följande kommando för att kontrollera att processerna har startats:
nlserver pdump
Byt användare för att hitta de användare som redan fanns på dev-plattformen.