Blueprint Management › Blueprint Element Reference

Blueprint Element Reference

The topics in this section provide a reference to the various blueprint elements that can be used to discover and manage software components.

This section contains the following topics:

Understanding the Structure and Contents of a Component Blueprint

Category Descriptions

Filter Descriptions

POSIX 1003.2-1992 Pattern Matching

Variable Substitution

Interpret As Descriptions

Support for multiple Relationships

Regular Expressions

Java Plug-ins Supplied with CA Configuration Automation

Understanding and Using the Tabular Data Parser

Understanding the Structure and Contents of a Component Blueprint

The ability to view, add, or modify a Component Blueprint or Component Blueprint elements depends on the CA Configuration Automation roles assigned to your user account or group. See the CA Configuration Automation Implementation Guide for detailed information about CA Configuration Automation roles and privileges.

All Component Blueprints are presented in a standardized tree view, consisting of the following organizational folder elements:

Nesting
Indicators
Managed
Parameters
Configuration
Diagnostics
Documentation
Runtime
Utilities

Each element is described in a section that follows.

Nesting

The nesting element lets you emphasize the relationship between components. When, for example, a software component uses and depends on several subordinate components, and those components are installed within the primary component's file system root, nesting can be used to enforce the parent-child relationship between them.

Oracle databases, for example, normally install a Java Runtime Engine and an Apache Web server within their installation directory. The relationship between the utility components and the Oracle database is expressed by nesting the JRE and Apache components within the Oracle component.

Indicators

The Indicators primary folder defines where to look for and how to identify a component on a server.

Because component discovery has been extended to servers without CA Configuration Automation Agents installed, and CA Configuration Automation does not have the registry and file systems available for this kind of discovery, you need to define different sets of indicators to find components on servers with installed agents and to find components on servers without installed agents.

On servers with CCA Agents, component discovery uses file indicators to search the file system for a specific set of files and directories that indicates the presence of a component, and then determines the corresponding root directory under which the managed files for the component are located.
For Windows servers, you can alternatively define registry entries as indicators. Note that if you use registry entries as indicators, you must specify the component's root directory in the parameters primary folder.

Note: While both file system and registry indicators can be used on Windows platforms, we recommend that you define one or the other, not both. You can, however, define more than one set of indicator type, which allows multiple pattern matching to extend the same Component Blueprint across multiple platforms. A good strategy for building an indicator set is to define two to three files/directories or registry keys/values that have a known position relative to one another as defined in Depth From Root or Path From Root. Defining too many indicators can produce undesirable and incorrect results.
On servers without CCA Agents, component discovery uses network probes to scan TCP ports, collect responses from those ports, and compare the responses against expected expressions to determine the type of service active on that port.

Indicators are not always sufficient to determine the existence of installed components or cannot distinguish the differences between two components with similar indicators. The verification directives folder contains directives that are used to discard components that are partially installed, of the wrong version, or not of interest to a particular service.

Note: Because of the order in which verification directives are executed in component discovery, database and configuration file parameters may not be available.

Adding Indicator Elements

To Add a...	Access and Procedure
File Search Option	Click on the files folder, then click the Add Search Options button.
Directory Indicator	Click on the files > / (file root) folder, then click the Add Directory button.
File Indicator	Click on the files > / (file root) folder, then click the Add File button.
Registry Search Option	Click on the registry folder, then click the Add Search Options button.
Registry Key Indicator	Click on the registry > \ (registry root) folder, then click the Add Key button.
Registry Value Indicator	Click on the registry > \ (registry root) folder, then click the Add Value button.
Network Probes	Click on the service folder, then click the Add Network Probe button.
Verification Directive	Click on the verification directives folder, then click the Add Directive button.

Managed

The Managed primary folder defines important files, registry entries, and database elements that are associated with the managed component.

If the managed folder contains no files or registry entries, the application manages all files under the component root directory and registry entries under the registry root. If a component has a limited number of files or registry entries, it makes sense to let all such elements under the root be managed. However, for a complex component with many files, it can be more useful to identify only the files and registry entries on which to focus. Identifying specific files and registry entries lets you refine the view of the managed component.

The File System Overlay and Registry Overlay folders let you (optionally) customize specific file and registry elements. For example, you can assign the categories, filters, or weights, or you can attach notes and rules to an element.

The data folder provides the database connection information and lets you:

Define a database to reference elsewhere in the Component Blueprint
Manage the database metadata, including table definitions and indexes

Important! Include any file that is referenced in the configuration, documentation, or run-time primary folders as a managed file.

Adding Managed Elements

To Add a...	Access and Procedure
Directory	Click on the files > $(Root) folder, then click the Add Directory button.
File	Click on the files > $(Root) folder, then click the Add File button.
File System Overlay Directory	Click on the file system overlay > $(Root) folder, then click the Add Directory button.
File System Overlay File	Click on the file system overlay > $(Root) folder, then click the Add File button.
Registry Key	Click on the registry > $(RegistryRoot) folder, then click the Add Key button.
Registry Value	Click on the registry > $(RegistryRoot) folder, then click the Add Value button.
Registry Overlay Key	Click on the registry overlay > $(RegistryRoot) folder, then click the Add Key button.
Registry Overlay Value	Click on the registry overlay > $(RegistryRoot) folder, then click the Add Value button.
Database	Click on the data folder, then click the Add Database button.
Database Table	Click on a database in the data folder, then click the Add Table button.

Parameters

The Parameters primary folder contains a Directives subfolder that defines and displays details that are critical for locating and identifying the component, such as the file system or registry root, component version, vendor, and database connection information.

Discovery determines the file system root and registry root of a Component Blueprint and displays these parameters in the discovered service tree view. Special Version and NameQualifier parameters, if defined in the Component Blueprint, are displayed after the name in the discovered service tree view. The Component Blueprint parameter NameQualifier is defined as $(Product Name) SP$(Service Pack) and parameter Version is defined as $(RegistryRoot)\Windows NT\CurrentVersion\CurrentVersion.

Parameter directives can be used for variable substitution into diagnostics, utilities, and the definition of rules and other parameters. Wherever the string $(ParameterName) is entered as a value, the actual value of that parameter is substituted.

Adding Parameter Elements

To Add a...	Access and Procedure
Parameter Directive	Click on the directives folder, then click the Add Directive button.

Configuration

The Configuration primary folder defines how to find and interpret the component configuration information. You can find the configuration information in managed files or databases or you can derive it from the output of executables.

The Structure Classes folder defines how to interpret the configuration files, database queries, and executables. The information includes the semantics of each potential value in the configuration data set:

Data typing
Default values
Enumerated values
Qualifiers
Categories
Filters
Weights
Rules

Think of a structure class as the metadata.

The application locates, parses, and interprets for viewing and comparative analysis the files that the Configuration Files folder identifies.

The data folder identifies the queries or stored procedures to run to extract configuration data and how to interpret the results for comparative analysis.

The executables folder defines scripts and directives that can extract the configuration information from a server and how to interpret the results for comparative analysis.

Adding Configuration Elements

To Add a...	Access and Procedure
Structure Classes Class	Click on the structure classes folder, then click the Add Class button.
Structure Classes Parameter	Click on a class under the structure classes folder, then click the Add Parameter button.
File	Click on the files > $(Root) folder, then click the Add File button.
Structure Classes Group	Click on a class under the structure classes folder, then click the Add Group button. You can add additional groups and parameters to a group using the Add Group and Add Parameter buttons that display when you select a group. You can also make a copy of a group and all of its associated parameters using the Group Copy button.
Database	Click on the data folder, then click the Add Database button.
Database Query	Click on a database under the data folder, then click the Add Query button.
Executable Directive	Click on the executables folder, then click the Add Directive button.

Utilities

The Utilities primary folder contains executable files, macros, and scripts that can be used to perform common administrative tasks, for example, programs or scripts that start or stop the component or that provide additional information about a server or service, such as viewing system information, memory statistics, or disk volume statistics.

Adding Utility Elements

To Add a...	Access and Procedure
File	Click the file's $(Root) folder, then click the Add File button.
File Usage	Click a file in the file's $(Root) folder, then click the Add File Usage button.
Macro	Click on the macros folder, then click the Add Macro button.
Macro Step	Click on a macro under the macros folder, then click the Add Step button.

Diagnostics

The Diagnostics primary folder defines executable files and macros used for diagnosing, troubleshooting, and fixing component problems.

Any executable, script, or batch file that can run on a server can be defined here and made available to CA Configuration Automation users with the appropriate access control role. Macros provide a way to include frequently used scripts and troubleshooting tools that can help diagnose problems specific to the servers containing the data being managed by its Component Blueprint.

Adding Diagnostic Elements

To Add a...	Access and Procedure
File	Click on the files > $(Root) folder, then click the Add File button.
File Usage	Click on a file in the files > $(Root) folder, then click the Add File Usage button.
Macro	Click on the macros folder, then click the Add Macro button.
Macro Step	Click on a macro under the macros folder, then click the Add Step button.

Runtime

The Runtime primary folder defines component run-time files and helps you locate and view them quickly. The run-time files (for example, log files) typically change frequently. To exclude the file contents from comparative analysis, define the files in the Runtime primary folder.

Adding Runtime Elements

To Add a...	Access and Procedure
File	Click on the files > $(Root) folder, then click the Add File button.

Documentation

The Documentation primary folder defines how to find the component's managed documentation files (for example, readme files, PDF files, or HTML versions of the product manuals). The Documentation folder also lets you add explicit URL links to additional sources of component information or documentation, such as company intranets or vendor support sites.

Note: Access to referenced URLs is determined by your network configuration.

Adding Documentation Elements

To Add a...	Access and Procedure
File	Click on the files > $(Root) folder, then click the Add File button.
URL	Click on the URLs folder, then click the Add URL button.

Category Descriptions

The Category field lets you organize Component Blueprint elements.

Category	Description
Administration	Administrative settings that have to do with the general availability and management of the component. Examples of administrative settings would be how to back up, when to flush a cache, or how many times to retry something.
Configuration	Configuration settings for the component, except for those that are better described by Administration, Log and Debug, Network, or Performance. Examples of configuration settings would be a component alias name or default web page.
Documentation	Elements that document the component behavior or act as a guide to users, for example manuals, readme files, FAQs, or online help pages.
Log And Debug	Elements that have to do with setting up such things as log locations, log levels, debug output, or diagnostic variable types.
Network	Elements that represent or indicate a network-related setting for the component. An example would be the port settings for SNMP. If an element can be categorized as both Network and Security (for example, enabling LDAP Authentication), use Security as the category.
Other	CA internal use only.
Performance	Settings that are known to seriously impact performance and are generally a specific subset of configuration parameters. Examples of performance settings would be number of threads or number of concurrent users.
Product Info	General (and usually static) information about the product. Examples of static component information would be licensing, installation location, vendor, or module name.
Resources	Component resources. Examples of component resources would be storage, memory and cache allocation or size, or CPU. Note that this static resource category is different than the Transient category, which relates more to real-time information.
Security	Elements that represent security-related settings and are generally a specific subset of configuration parameters. Examples of security settings would be authentication types, enabling authentication, encryption settings, directory browsing, SSL, or HTTPS.
Transient	Elements that change with some regularity. Examples of transient elements would be server states (for example, up, down, running, or stopped), current number of connected clients, current number of threads, or current disk utilization.
Versioning and Patches	Elements that indicate the version or patch levels of the product.

Filter Descriptions

The Filter field lets you mark Component Blueprint elements for exclusion from key CA Configuration Automation operations and results like Change Detection and Rule Compliance.

Filter	Description
Component Specific	Identifies an element that is specific to a single component instance, for example, installation root and Service Server Name. The purpose is to identify and exclude certain component-specific elements, which are already known to be different, from Change Detection operations and results.
Service Specific	Identifies an element that is specific to a service, for example server names and installation roots. The purpose is to identify and exclude certain service-specific elements, which are already known to be different, from Change Detection operations and results.
Server Specific	Identifies an element that is specific to a single server, for example Server name and IP address. The purpose is to identify and exclude certain server-specific elements, which are already known to be different, from Change Detection operations and results.
Never Run Change Detection	Identifies an element that should be permanently excluded from all types of Change Detection operations and results. A temporary directory, log files in the managed folder, or anything that is known to be transient are examples of elements that you want to identify and always exclude from Change Detection operations and results.
Never Run Rule Compliance	Identifies an element that should be permanently excluded from all types of Rule Compliance operations and results due to their inconsequential or variable nature. A temporary directory, a known old configuration file, a template, or an example file are examples of elements you want to identify and always exclude from Rule Compliance operations and results.
Time Variant	Identifies an element that is known to change over time, but not necessarily across servers or across services, for example, log files, process start times, and registry event counters. The purpose is to identify and exclude parameters that are time variant, which are already known to be different, from Change Detection operations and results.

POSIX 1003.2-1992 Pattern Matching

POSIX pattern matching expressions are descriptions that help you find files and directories when the exact file or directory name is not known. CA Configuration Automation uses POSIX pattern matching expressions to search for files and directories during discovery and during refresh operations.

Syntax of POSIX Pattern Matching Expressions


File Name Matching Expression	Description
Characters
unicodeChar	Matches any identical Unicode character.
?	Matches any single character.
*	Matches any string, including the null string (zero length).
Character Classes
[abc]	Matches any character listed within the square brackets (simple character class).
[a-zA-Z]	Matches any range of characters listed within the square brackets (character class with ranges).
[^abc]	Matches any range of characters except those listed within the square brackets (negated character class).
Standard POSIX Character Classes
[:alnum:]	Matches alphanumeric characters
[:alpha:]	Matches alphabetic characters
[:blank:]	Matches space and tab characters
[:cntrl:]	Matches control characters
[:digit:]	Matches numeric characters
[:graph:]	Matches characters that are printable and visible. (A space is printable but not visible, while an a is both.)
[:lower:]	Matches lowercase alphabetic characters
[:print:]	Matches printable characters (characters that are not control characters)
[:punct:]	Matches punctuation marks (characters that are not letters, digits, control characters, or space characters)
[:space:]	Matches characters that create space, such as tab, space, and formfeed
[:upper:]	Matches uppercase alphabetic characters
[:xdigit:]	Matches characters that are hexadecimal digits

Variable Substitution

Variable substitution allows the value of any element managed by CA Configuration Automation to be used as a parameter within a Component Blueprint directive. CA Configuration Automation defines an expression syntax to identify elements in the blueprint. Once identified, the element's value is extracted and used in place of the expression when the directive is executed. Substitution can be applied to any attribute of a directive. These include values, default values, paths, file names, parameters, environment variables, regular expressions, queries, and column names.

Managed elements whose values are addressable by variable substitution syntax include:

Discovery parameters
Registry variables
Configuration values (file, database, or executable)
File and directory attributes
Managed data elements (schema metadata)
Service and component attributes