Skip navigation

At times it is required to reset the Test Env. CDP or any other peer back to freshly installed state, to do that, follow these simple steps and take a backup file system before doing so.


  • Stop the CDP or Peer Service.
  • Removed files from KahaDB located at AO_HOME/server/.jms/activemq-data/ao-grid-framework-embedded-broker-<guid>/KahaDB
  • Removed log files located at AO_HOME/tomcat/logs


Reset Peer:

Removed following:

  • "server" folder located on AO_Home
  • "messages" folder located on AO_Home
  • all XML files in "config" folder except authentication.xml, tuning-config.xml and installation_audit.xml
  • all files in tomcat/work
  • all files in tomcat/temp

Then start peer service.  It will re-create all those files and directories, just like the first time it starts up.


NOTE: These steps are only for non production environment, do not try these step in production.




I quite often get this sort of scenario where customer have a requirement to deploy a Peer in a different network or in DMZ while keeping communication between CDP's and Peer in other network using NAT IP address.


Below is a high level overview of how this sort of deployment configuration which provides connectivity with an LAP located in a different network/DMZ using NAT IP address. This deployment minimizing the impact to the DMZ firewall rules. The grid is deployed in a high-availability configuration to provide redundancy for the processing peers. Inside the DMZ or Other network, a lightweight activity peers exist which can host required adapters.


Lets understand some basic concept of Peer Discover and Peer Communication which is associated with JMS broker.

Each peer is associated with a JMS broker which hosts a set of queues which is involved to send messages targeted to the respective peer.  A given broker may host queues for any number of peers. The combination of broker URI and topology queue is referred to as an "advertisement".


Each peer engage and contribute in the management grid "discovery" topology, along with a subset of the peers being designed to provide discovery services to the other peers. The advertisements associated with discovery peers are persisted with each peer in the environment. Upon startup, a peer registers the advertisements for its topology with the master in the discovery topology, and periodically requests advertisements matching topology in which the peer participates.


Non discovery advertisements are never persisted and are maintained only in memory. When a peer learns about a new discovery server (this occurs when an HA CDP is added to a grid), the associated advertisement is persisted with that peer.




Broker Config

Most JMS configuration files are located in $AO_HOME/server/.jms


The broker-config.xml file specifies the JMS broker configuration for individual peer.

The XML document can have below nodes

  • external - indicates whether the broker is hosted within this peer's VM or externally
  • uri - the broker URI. This specifies the protocol, IP (or host), port, and any ActiveMQ parameters associated with the broker.
  • port-upper-bound - if present, indicates that the broker port may range from the port specified in the uri up to the number provided in this element. Upon peer startup, the first available port in the range will be used
  • listen-addresses — if present, this would enforce the server to listen only on the addresses specified
  • advertise-addresses — if present, this would enforce the server to advertise only the addresses specified


activemq-data - a directory used by ActiveMQ

certificate- the certificate used for SSL JMS connections.

disco - a directory used to hold discovery advertisements (Ideally you will find only CDP and HACDP disco file here)



In the below mentioned example, I have a data-center in which I have a CDP, HACDP, REPO and Authentication System (AM/ASSO/RSSO) based on the version of the production in use.
My CDP 1 has an host IP Address of and its NAT IP address is, My CDP - 2  has an host IP address of and NAT IP Address as Rest of my BAO components are in the same data center as CDP's expect for one LAP which is located in different location or different data center or in DMZ.  My LAP has an Host IP address as


It is possible to specify an address to advertise which can be a NAT IP other than the CDP's host IP address.

CDP Broker-config.xml (located in $AOCDPHOME\server\.jms)



<uri>ssl://CDP-IP:<Peer Communication Port>?connectionTimeout=1000</uri>


   <address>NAT IP Address of CDP</address>

    <address>CDP-1 FQDN</address>




Note: that it is also possible to use "hostnames" in the advertise-addresses block. and further host file mapping for the hostname can be done in the individual peer.


One of the biggest challenge which customer face who upgrade from BAO 7.6.x to BAO 7.7 or 7.8 is that ASSO doesn't allow multiple WebApp URL, and if you try to use a CNAME, Alias, VIP or Loadbalancer (to avoid single point of failure) it will alway rewrite the URL back to registered WebApp URL, which might eventually cause a  request failure if the URL is not resolvable from out network or in some case in restricted internal network.


Below example is valid for scenario where a VIP or Loadbalancer are used to access the ORCA webservice to avoid single point of failure for ORCA web service.

Lets start with an example: Assume that I have BAO CDP server named "cdp.bao.local", it’s the same name which is used during installation and is been used in web app url of ASSO, I also have an HACDP and it has a name "hacdp.bao.local", I also have a loadbalancer in front of these two server to manage the ORCA requests and avoid single point of failure, LB has Alias/CNAME as "" which I used in my code or 3rd part application to access ORCA webservice from outside the network now if I want access ORCA webservice using external url I will use "" however when the request reaches the server ASSO automatically rewrite the to registered WebApp URL  which is internal url in this case i.e.  "https://cdp.bao.local:28080/baocdp/orca" or "
https://hacdp.bao.local:28080/baocdp/orca" (based on where LB direct the request) which may not be accessible from outside network irrespective of whether ORCA is added in excluded URL in SSO. This is the default behavior of Atrium SSO and cannot be changed to the best of my knowledge.

To solve this if we re-register ASSO agent with external name (CNAME or Alias) or LB Name, ORCA will start to work fine however base on the way your infra is been design or number of redirection in your network you may find your self stuck in a re-direction loop in browser whenever you try to access grid console using internal url which is "https://cdp.bao.local:28080/baocdp" or
"https://hacdp.bao.local:28080/baocdp"  since URL rewrite to "" or end with a message saying too many re-directions. The same happen if a CNAMEor VIP is used.


To resolve this problem we would have to tweak the system a bit with below mentioned trick.
What we need to do is use a Name/FQDN which is accessible internally (i.e. it can be resolved internally) and it should be accessible externally (i.e. name should be resolved to your loadbalancer IP address). Since for accessing Grid console we need a direct access so that we don't get stuck in redirect loop. however for ORCA It usually work irrespectively.


Below are the high level overview of the steps we will be performing.
1. Register the CDP ASSO agent with LB or CNAME FQDN lets say
2. Add a mapping for CDP IP to Loadbalancer FQDN in hosts file of the machine from which Grid Manager will be called and Administrate through those machine.




Apart from above there is alternative option

1. Continue to use CDP and HACDP name in ASSO agent. However make the calling system resolve the CDP and HACDP name to a IP address of LB.

2. Add a hostname mapping for CDP and HACDP name to Loadbalancer IP/ VIP in the external system which are calling ORCA web service.




Note :

1. This workaround would offer you kind of High Availability for ORCA webservice with single end point (for consuming in 3rd party application and custom codes) considering the fact that the requests reached the respective CDP nodes without any failure from Network and OS end, although product was not originally intended to offer High Availability for ORCA  webservices with single point to consume, as per the Product design HA grid configuration with the CDP and HA-CDP manages all CDP failures by election. That is, configuration will provides redundancy for job processing elements of the grid.


2. This problem has been addressed in BAO 7.9 release when RSSO will be introduce as a new authentication system since for a typical new installation RSSO will be using the same tomcat instance as BAO and there will be no URL rewrite in it.



New Workaround


Recent Development showed as that there is one more workaround which can be implemented by modifying the web.xml of the CDP's which will by pass the redirection for Orca, RESTful and Legacy web service. 


Below are the changes which we need to make in the CDP's web.xml located in ("<BAO_CDP_HOME>\tomcat\webapps\baocdp\WEB-INF\web.xml")

Change SSO agent URL pattern to /gm/* instead of /* in web.xml as shown below thereby preventing SSO JEE filter from redirecting or rewriting URL to register WebApp URL when ORCA, Legacy or Restful Web Services are called.





            <!-- SSOPrincipal -->





            <!-- SSOToken -->





            <!-- Identifier from SSOToken -->





            <!-- Name from SSOPrincipal -->













With this new workaround you don't have to making any further changes in the host file mapping and you would be able to use Alias, VIP and CNAME while calling webservice.

Filter Blog

By date:
By tag: