BPPM 9.5 Quick Start - Part 3: Name convention

When you implement BPPM 9.5, you will need to name many different components.  It is easy to keep them organized and consistent across the entire enterprise if you take some time to set up a name convention before starting the implementation. 

What components do you need to name during BPPM 9.5 implementation?

1. Cell

By default BPPM will name the cell using the hostname.  In general hostname is not a good choice for a cell name as it doesn't tell anything about what the cell is used for or what environment the cell is located.  In addition, in a high-availability environment, the cell running on the primary host and the cell running on the secondary host should have the same name. 

As a best pratice, you should never name two cells with the same name across your entire enterprise.   Name your cell to reflect its event source, its environment, and its type.  For example, name DEV_ISN_PATROL1 for the cell running on the first integration service node receiving PATROL events in your dev environment.  Name PRD_CHD_BPPM1 for the cell running on the first child BPPM server in your production environment.  Name QA_EXT_SCOM for the cell receiving external events from SCOM in your QA environment.

2. Integration Service

If you have just one instance of integration service running on an integration service node (ISN), you can simply use the hostname as the integration service name. However if you have two instances of integration service running on two different ports of the same ISN, you will need to decide how to name them.  Perhaps you can use <hostname>-1 and <hostname>-2 or <hostname>-<portnumber>.

3. ISN Cluster

If you are going to implement high availability on ISN, you will need to create an ISN cluster.  Since we also have a pair of H/A cells running on an ISN cluster, I prefer to use the cell name as the ISN cluster name to tie a pair of H/A cells and a pair of H/A integration service instances together.  But you can use other names just to make sure they are meaningful and consistent.

4. CMA Policy Tag

A CMA policy tag is defined in CMA and referenced by PATROL agents in their pconfig variable.  When the tag referenced by an agent's pconfig variable matches the policy tag defined in CMA, the configurations defined in the policy will be automatically applied to the PATROL agent.  Consider including OS, KM, environment, and server group in your CMA policy tag names so that they are meaningful and consistent.  For example, use Oracle_HR_Prd for Oracle KM configurations running on HR server group in production environment.  Use UNIX_Report_QA for UNIX KM configurations running on Reporting server group in QA environment.  CMA policy tags are case sensitive.