This document will provide you with an in-depth walkthrough on the upgrade process and the steps to identify and resolve conflicts.
The build upgrade must be carried out with caution, its impacts must be fully considered beforehand and the procedure must be completed with a high level of discipline. To ensure a successful upgrade, ensure that only expert users perform the steps outlined below. In addition, we strongly recommend getting in touch with Adobe Campaign Customer Care before starting any upgrade.
The following prerequisites are needed:
- Understanding of the Campaign Architecture
- Systems and server side knowledge
- Administrative rights and permissions
For hosted and hybrid instances, you must request the build upgrade to Adobe Technical Operations team. For more on this, refer to the Frequently Asked Questions section at the bottom if this page. Also consult the build upgrade FAQ article.
The build upgrade process requires the following resources:
- an Adobe architect - to understand the database structures (out-of-the-box schemas and any additional schemas that have been added, campaign designs, and any critical path functionality that must be started and tested in a specific order).
- a project manager - In the case where the build upgrade involves many different instances (production, staging, testing) and other third party servers and applications (databases, SFTP sites, messaging service providers), having a project manager to coordinate all of the testing is considered a best practice.
- an Adobe Campaign administrator - your administrator knows the server's configuration including but not limited to: security, folder layout, reporting, and import\export requirements. Please do not perform a build upgrade without your administrator.
- an Adobe Campaign operator (marketing user) - a successful upgrade relies upon the user's ability to perform their daily tasks successfully. For this reason, always include at least one of your daily operators in your testing of the upgraded servers.
Here are the key points on how to plan a build upgrade:
- Reserve at least 2 hours for the upgrade.
- Distribute contact details for Adobe and customer staff.
- For hosted instances: Adobe and customer staff will coordinate the time for the upgrade and who will execute.
- For on-premise instances: customer staff manages the entire process - if assistance in testing of customized workflows and delivery logic is needed, consulting services should be brought in.
- Determine and confirm which version of Adobe Campaign you want to upgrade to - consult the Adobe Campaign Classic release notes.
- Confirm possession of upgrade executables.
The build upgrade process requires the following people to be involved:
Adobe architect: for hosted or hybrid architectures, the architect must coordinate with Adobe Campaign Client Care.
- Project manager:
- for On Premise installations: the customer's internal Project Leader leads the upgrade and manages lifecycle tests.
- for Hosted installation: the hosting team will partner with the Adobe Campaign Client Care team and the customer to coordinate the upgrade timeline for all instances.
- Adobe Campaign Administrator:
- for On Premise installations: the administrator performs the upgrade.
- for Hosted installations: the hosting team performs the upgrade.
- Adobe Campaign operator\marketing user: the operator runs tests on development, test and production instances.
You also need to know all the useful command lines before starting a build upgrade:
- nlserver pdump: lists running processes
- nlserver pdump -who: lists active client sessions
- nlserver monitor -missing: lists missing properties
- nlserver start process@<instance>: starts a process
- nlserver stop process@<instance>: stops a process
- nlserver restart process@<instance>: restarts a process
- nlserver shutdown: stops all Campaign processes
- nlserver watchdog -svc: starts the watchdog (UNIX only)
Here is how you duplicate an Adobe Campaign environment, in order to restore a source environment to a target environment, resulting in two identical work environments. To do this, follow the steps below:
SELECT * FROM neolane.nmsdeliverypart;
SELECT iSate, count(*) FROM neolane.nmsdeliveryGroup By iProd;
SELECT iState, count (*) FROM neolane.xtkworkflowGROUP BY iState; SELECT iStatus, count (*) FROM neolane.xtkworkflowGROUP BY iStatus;
In order to replace all files with the new version, it is required that all instances of the nlserverservice are shut down.
The following services need to be restarted:
- Web services (IIS): issreset /start
- Adobe Campaign service: net start nlserver6
On the machine where the Adobe Campaign application server is installed (nlserverweb), download and copy the file:
Setup-client-7.xxxx.exe in [path of the application]\datakit\nl\en\jsp
The next time client consoles are connected, a window will inform users about the availability of a new update and offer them the possibility of downloading and installing it.
When Transactional Messaging (Message Center) is enabled on your Campaign instance, you need to perform these additional steps to upgrade:
- Update the Message Center production server to the chosen version.
- Run the postupgrade scripts.
- Run tests and ensure that the emails are successfully received through the Message Center production instance.
- Upgrade clients and clear cache.
- Export packages:
- Export packages using the client package export tool.
- Import schema package.
- Disconnect and reconnect client.
- Update database.
- Disconnect and reconnect.
- Import Admin package.
- Import Content package.
- Import Content Management package.
- Disconnect and reconnect.
- Perform a quick sanity check of workflows.
- Publish Message Center templates to ensure that the interface between servers and Message Center instance is working.
- Run tests to ensure that emails are successfully received through the Message Center production instance.
- Run workflow tests in production to ensure that deliveries are received.
In the context of a mid-sourcing environment, you need to perform these additional steps to upgrade:
- Contact Adobe Campaign Support to coordinate the upgrade of the Mid-Sourcing server.
- Validate that the version has been updated by running a test link. For example: http://[InsertServerURL]/r/test
The Mid-Sourcing server must always run the same version (or more recent) as for the marketing servers.
You need to check the synchronization result. This procedure is only performed by on-premise customers. For hosted customers, it is taken care by the hosting team. There are two ways to view the synchronization result:
In the command-line interface, errors are materialized by a triple chevron >>> and synchronization is stopped automatically. Warnings are materialized by a double chevron >> and must be resolved once synchronization is complete. At the end of the postupgrade, a summary is displayed in the command prompt. It can look like this:
YYYY-MM-DD HH:MM:SS.749Z 00002E7A 1 info log =========Summary of the update========== YYYY-MM-DD HH:MM:SS.749Z 00002E7A 1 info log <instance name> instance, 6 warning(s) and 0 error(s) during the update. YYYY-MM-DD HH:MM:SS.749Z 00002E7A 1 warning log The document with identifier 'mobileAppDeliveryFeedback' and type 'xtk:report' is in conflict with the new version. YYYY-MM-DD HH:MM:SS.749Z 00002E7A 1 warning log The document with identifier 'opensByUserAgent' and type 'xtk:report' is in conflict with the new version. YYYY-MM-DD HH:MM:SS.750Z 00002E7A 1 warning log The document with identifier 'deliveryValidation' and type 'nms:webApp' is in conflict with the new version. YYYY-MM-DD HH:MM:SS.750Z 00002E7A 1 warning log Document of identifier 'nms:includeView‘ and type 'xtk:srcSchema' updated in the database and found in the file system. You will have to merge the two versions manually.
If the warning concerns a conflict of resources, user attention is required to resolve it.
The postupgrade_<server version number>_<time of postupgrade>.log file contains the synchronization result. It is available by default in the following directory: <installation directory/var/<instance/postupgrade. Errors and warnings are indicated by the error and warning attributes.
Conflicts can be found within the postupgrade.log on the server in question or within the Campaign client interface (Administration > Configuration > Package management > Edit conflicts).
The document with identifier ‘stockOverview’ and type ‘nms:webApp’ is in conflict with the new version.
To resolve conflicts, apply the following process:
- In the Adobe Campaign explorer, go to Administration > Configuration > Package management > Edit conflicts.
- Select the conflict you want to resolve in the list.
There are three options to resolve conflicts: Accept the new version, Keep the current version, Merge the code (and declare as resolved), Ignore the conflict (not recommended).
- Only forms, reports and web applications can be merged.
- Some minor merges can be resolved without understanding the code.
- More complex merges should be performed by someone with the appropriate skills and ability.
- See Perform a merge.
There are different types of merges:
- Easy merge: custom and new elements are small and unrelated, and there is no coding required.
- No changes: accept new version, only last update date changed, only comments, tabs, spaces or new lines. Example: accidental save.
- Trivial changes: only one line changed. Example: xpathToLoad
- Complex merge: when coding is required. Development skills are required. See Complex merges.
- Built-in code is stored in XML files in the datakit folder. Find the XML file that matches the conflicting object. Example: <Adobe Campaign installation folder>\datakit\nms\fra\form\recipient.xml
- Retrieve the original version: from the Adobe Campaign Support page, via the download center link or another non-upgraded installation of the product.
- Retrieve the new version: from the Adobe Campaign Support page, via the download center link or the customer's installed files.
- Retrieve the custom version: retrieve the object's source code from within the Campaign client.
- Start from the custom version.
- Apply the changes.
- Resolve the conflict by declaring it as resolved.
- Check for non-regressions.
If you choose to resolve the conflict manually, proceed as follows:
- In the lower section of the window, search for the _conflict_ string to locate the entities with conflicts. The entity installed with the new version contains the new argument, the entity that matches the previous version contains the custom argument.
- Delete the version you don't want to keep. Delete the _conflict_argument_ string of the entity you are keeping.
- Go to the conflict you have resolved. Click the Actions icon and select Declare as resolved.
- Save your changes: the conflict is now resolved.
- Understand what the change does: reverse-engineer the changes, examine the change logs, follow up with Adobe Campaign experts.
- Decide what to do with the change: ask the customer.
- Understand what the customizations do: reverse-engineer the changes, ask the customer.
Here are the steps to perform a complex merge:
- Copy bits of code from the change set.
- Paste to the customized version.
- Test for non-regressions of customization.
- Test for function of changes.
- Ask for User Acceptance Testing by customer.
- Perform in test environment
Development skills are required.