DX NetOps

CA Spectrum Tuesday Tip by Michael S. Poller, CA Spectrum Infrastructure Manager Senior Support Engineer, December 15, 2011

Question:
What is the most effective method to change the eHealth server that is integrated with Spectrum? For example when moving from being integrated with a lab/QA eHealth environment to a Production environment?

Answer:
It is a fairly simple process. Follow the below instructions to reset the Spectrum eHealth integration or switch what eHealth environmnent Spectrum is integrated with.

1 - Log in to the SPECTRUM OneClick home page.

2 - Select Administration at the top of the page. The Administration Pages menu appears.

3 - Select eHealth Configuration. The eHealth Configuration window appears.

4 - Scroll down to the eHealth mapping utilities section.

5 - Click Clear Map.

6 - Delete the ehealth-config.xml file found in the following directory on the Spectrum OneClick web server:
$SPECROOT/custom/ehlth/config

7 - Stop and restart the OneClick Tomcat server
Windows: Open the Services view and Stop the Spectrum Tomcat service
Unix (Solaris/Linux): Run the stopTomcat.sh command from the $SPECROOT/tomcat/bin directory
8A – Using EventAdmin models to represent the eHealth servers integrated with:
In the OneClick client console if EventAdmin models were created to represent the eHealth servers delete them. Then create new ones to represent the new eHealth servers to be integrated with. Be sure to set the attributes SBG_AlertForwardingEnabled and map_trap_to_this_model_using_IP_header to Yes for the Live Health traps received to be processed correctly.

8B – Using SystemEDGE Host models to represent the eHealth servers integrated with:
If you wish to maintain monitoring of the existing SystemEDGE host models they can be left as is except for one change so they continue to be polled and alarmed against. If that is the case, you will want to set the attributes SBG_AlertForwardingEnabled and map_trap_to_this_model_using_IP_header to No. Then discover the new eHealth servers with SystemEDGE agents to create models for them to represent the eHealth servers. Next be sure to set the attributes SBG_AlertForwardingEnabled and map_trap_to_this_model_using_IP_header to Yes for the Live Health traps received to be processed correctly.

9 - Go back to the eHealth Configuration admin page and enter the eHealth server host information using the details of the new eHealth environment to be integrated with. Select Test to validate communication between the systems. Select Save on the page to save the new settings. That will recreate the XML file deleted at step 6.

10 - Run an Initial Mapping to map the models present in Spectrum to the elements present in the eHealth environment that is now integrated with Spectrum.

11 – If there are different eHealth Discovery Policies configured in the newly integrated eHealth environment, make sure the correct Discovery Policies are associated to the appropriate Spectrum Global Collections to ensure synchronized discovery processing continues to function as expected.

The process is now complete and the integration should now be up and running.

syeal01 wrote:

Pretty cool tip. Just two comments: (1) the step 6, is on OneClick server. (some newbie might start looking in SS box :D ).
and, (2), If you could, some time in future, expand on your Step 11, into a new Tip or a continuous of this Tip part II. This will be very useful.
Thanks.

Hi Mike,

What bout dropping the DB "eh_integ" and recreating it for active OneClick Servers? Seems, you have missed this. Before we integrate Spectrum with new eHealth server, don't we need to perform this?

On OneClick Server navigate to $SPECROOT/mysql/bin, perform the below steps.

On Windows:

./mysql -u root -p root password

On LINUX:

./mysql --defaults-file=../my-spectrum.cnf -uroot -proot

mysql> drop database eh_integ;
mysql> create database eh_integ;
mysql> exit

This will take care of DB cleanup as well. Please correct me if I am wrong.

Regards,

Rajashekar

Rajashekar,

Yes, that step can be taken, but I don't believe it is necessary. I suppose if the step isn't taken and the re-integration doesn't work properly, that step might be added to the reset process to see if it helps get past whatever issue was being observed.

Of course given that the last reply to this thread is 4 years and 11 months ago, further research and testing would be needed to validate the answer here.

Thanks,

Mike