![[AIX Solaris HP-UX Linux Windows]](../images/dist.gif)
![[z/OS]](../images/ngzos.gif)
Validating an edition
Validating an edition is the process of determining if a new edition is available and ready to move into production and replace the current edition. You can install and validate a new edition under realistic conditions while your production application edition continues to serve requests.
Before you begin
- Ensure that all of the modules for your application are deployed to the same deployment targets.
- Define unique routing rules for edition 2.0. Routing rules enable editions to run concurrently and hypertext transfer protocol (HTTP) requests for the validation edition to correctly route to the validation target without interfering with edition 1.0. For this scenario, use the my_application application. Install both application editions, 1.0 and 2.0, on the dynamic_cluster_1 dynamic cluster. For more information about routing rules, read about creating routing policies for application editions.
- To set the operational mode of the cloned validation cluster to
a different mode from the production cluster, create the VALIDATION_OPERATIONALMODE custom
property in the administrative console. Otherwise, the validation
cluster is set to the same operational mode as the production cluster
after it is created. Set the value to automatic, manual,
or supervised. If you specify any other value
or you do not specify a value, the validation dynamic cluster is set
to manual mode.Restriction: Only two cluster members can be used or created in validation mode. You can map routing and service policies to the validation mode application, but no more than two cluster members are started to maintain the work. You can overwrite this setting after the validation cluster is created by changing the minimum and maximum number of dynamic cluster instances.
- If you are a user with either a monitor or an operator role, then you can only view the application edition manager information. If you have the role of configurator or administrator, then you have all the configuration privileges for the application edition manager.


About this task
Consider the following scenario as an example of how validation is performed on an edition: Edition 1.0 of an application is installed, active, and running on a dynamic cluster. Edition 2.0 is the candidate validation edition and is installed on the same deployment target in the inactive state. Validating edition 2.0 clones the edition 2.0 deployment target. For example, the validation might create a new dynamic cluster, such as the DC-Validation dynamic cluster, and map edition 2.0 to this new cluster. The cloned cluster uses the existing cluster members as the server template for the creation of the cloned servers.
After the validation clone target is created, edition 2.0 is activated, and the routing rules are defined, you can start, stop, and reconfigure the edition.
Procedure
What to do next
- To replace edition 1.0 with edition 2.0:
- Stop the validation target, for example, dynamic_cluster_1-Validation.
- Delete the routing rules that are specific to edition 2.0 to route all requests for the application to a single edition.
- Save your changes and synchronize the nodes.
- Perform rollout to the new edition. Click Rollout. During the rollout, edition 2.0 is retargeted to its original deployment target, for example, dynamic_cluster_1. The edition state transitions from validation to active. . Select edition 2.0 and click
- If edition 2.0 has errors, you can cancel validation mode and move edition 2.0 back to its original inactive state. As a result, the duplicate dynamic cluster that was created for validation is removed. For more information about cancelling the validation mode, read about canceling an application validation.