Activate multiple editions of the same application concurrently
when you are validating before production, piloting an application to a select
group of users, or rolling out a branch when an application upgrade requires
a corresponding change on identifiable branches of client machines.
Before you begin
You must have at least two editions of the same application installed.
For example, the
my_application application edition
1.0 is
installed the
dynamic_cluster_1 dynamic cluster, and edition
2.0 is
installed on the
dynamic_cluster_2 dynamic cluster.
Privileges
for the application edition manager differ, depending on the various roles.
Roles include monitor, operator, configurator, and administrator. If you are
a user with either a monitor or an operator role, you can only view the application
edition manager information. If you have the role of configurator or administrator,
you have all the configuration privileges for the application edition manager.
About this task
Each edition must be active on a separate deployment target. When
multiple editions of the same application are concurrently available to users
in the same environment, the on demand router (ODR) cannot differentiate between
the active editions without some information available to disambiguate the
request and route it to the intended edition. You can use routing rules or
unique interfaces for each edition to prevent this ambiguity.
Procedure
- Activate the application editions. Click Applications
> Edition control center > application_name. Select the inactive
edition and click Activate. For example, select the my_application application
and activate edition 2.0.
- Create routing policies for each application edition.
- Navigate to the routing policies for the application.
Click Applications > Enterprise applications >application_name Click
the Routing policies tab. For example, select the my_application application.
- Expand Work classes for HTTP requests. Because
no routing rules are specified, all requests are routed to the edition displayed
on this page. For example, all requests are routed to application
edition my_application-edition2.0.
- Click Rule builder.
- From the rule list, select a rule. For example,
select Client host (clienthost) and click Add.
- Select criteria for the rule. For example, select
an operator of Equals (=) and type a value of your client host name.
Click OK.
- Click OK again.
- Expand Work classes for HTTP requests.
- Set the action associated with the new rule. For
example, requests from the host route to edition my_application-edition1.0.
Select the corresponding action from the Then list and click Apply to
save the rule.
- From the top of the Routing policies tab, click Apply.
- Save the changes to the configuration repository and synchronize
the nodes.
- Verify that the ODR is running. Click Servers > On
demand routers. To route requests, the status must be Started.
- Test the concurrent access to application editions. Select
the two application editions by selecting the application servers associated
with the two dynamic clusters BTDC1 and BTDC2 and
clicking Start.
Results
When requests are sent to the ODR from the client with host name you
provide, the requests are serviced by edition 1.0, while
requests from all other clients are serviced by edition 2.0.
Example
For example, to run a pre-production test of an application edition
in the production environment with a selected set of users, you can clone
the deployment target, including its resource and security definitions, and
activate the target edition on the cloned environment. Use routing rules to
direct the ODR to divert a selected subset of users to the edition.
Additionally,
to pilot your application, you can use routing rules to separate the pilot
users on edition 2.0 from the general users on edition 1.0.
In the case
of branch rollout, use routing rules to direct each branch to the appropriate
edition. As the client code at each successive branch updates, the server-side
routing rules can be updated to qualify the clients from the newly updated
branch to be sent to the appropriate edition.
For cases where the routing
rules are insufficient to differentiate user requests or where the user prefers
an alternative to routing rules, each edition can be given its own unique
URI and Enterprise JavaBeans (EJB) Java Naming and Directory Interface (JNDI)
name. Unlike routing rules, unique interfaces for each edition are exposed
to the application users. Therefore, you must choose the appropriate name
to drive the appropriate edition.