| Oracle® Enterprise Manager Cloud Control Administrator's Guide 12c Release 1 (12.1.0.1) Part Number E24473-01 |
|
|
PDF · Mobi · ePub |
| Oracle® Enterprise Manager Cloud Control Administrator's Guide 12c Release 1 (12.1.0.1) Part Number E24473-01 |
|
|
PDF · Mobi · ePub |
This chapter provides detailed information on the management and implementation of custom configuration specifications, and how they use parsers to transform and store configuration data. The chapter serves as a reference for the suite of parsers that ships with the application, and includes examples of how parsers and rules work together to align configuration data in operations such as comparisons.
Custom configurations are stored in and managed from the Custom Configurations library. To access the library, from the Enterprise menu, select Configuration, then select Custom. A list of all available specifications appears by default. Use search criteria to find a specific custom configuration.
Use the following actions to manage custom configurations:
| Action | Description |
|---|---|
| Create | Create a new custom configuration. See "Create or Edit a Custom Configuration" for more information. |
| Create Like | Create a new custom configuration based on the selected specification. See "Create or Edit a Custom Configuration" for more information. |
| Edit | Make edits to the selected specification. See "Create or Edit a Custom Configuration" for more information. |
| View Details | View the make-up of the selected specification. See "View a Custom Configuration" for more information. |
| Delete | Delete the selected specification. See "Delete a Custom Configuration" for more information. |
| Enable Facet Synchronization | Synchronize the selected specification with facets in the Compliance Library for real-time facet monitoring. See "Enable Facet Synchronization" for more information. |
| Export | Save the selected specification as an XML file. See "Export a Custom Configuration" for more information. |
| Import | Import a specification as an XML file from the local file system. See "Import a Custom Configuration" for more information. |
| Deploy | Indicate the monitored target from which to collect configuration data based on the specification. See "Deploy and Undeploy Custom Configurations" for more information. |
To perform these actions, click the respective button, or select a specification in the table and click the button, as appropriate.
Use the instructions below to create, create like, or edit a custom configuration.
Given appropriate privileges, you can edit a custom configuration and save the edited version, in which case, the version number increases. You might also edit and save as a draft, or edit a draft for publishing. Note that when you edit a custom configuration, you cannot change the target type, as this would cause the underlying metadata to be incompatible with existing deployments of the custom configuration.
See the section "About Custom Configurations and Privileges" for information on privileges required to perform various actions on custom configurations.
Note:
When you edit a deployed custom configuration, it is automatically redeployed upon saving. This does not apply to saving as draft.In the Custom Configurations library, click the Create button; or, select an existing specification in the library and click Create Like or Edit.
On the Create Custom Configuration page, enter a name for the custom configuration and an optional description. The create like action requires minimally that you rename the specification.
Select a target type. If no currently defined target type satisfies your requirements, click the Create Custom Target Type button to the right of the target type drop-down list. Type a name and click OK. The new type now appears in the drop-down list of target types.
To create a new target type, ensure that the administrator has installed a software library (Setup > Provisioning and Patching > Software Library). This must be done once, after Enterprise Manager installation.
Optionally, set up a sample target. A sample target resides on the host from which you intend to collect configuration data. If you do not set up a sample target, you cannot browse the file system or use the preview feature in entering your specifications. You can select an existing target instance as a sample, or add a new one. Typically, you would add a new target instance to match a custom target type added in Step 4.
To select an existing target instance, click the appropriate link. A dialog opens containing known instances of the target type. Use the filtering criteria as necessary to locate the instance you want and then click Select.
To add a new target instance, click the appropriate link. As instructed in the dialog that opens, you must first select an agent to monitor the target you are adding. Next, click Add Target. In the dialog that opens, provide target properties appropriate to the instance target type. Minimally, provide values for required properties (denoted by an asterisk). For a new target instance that matches a custom target type, the pertinent target property is the path to install home, as this is the likely location of configuration files relevant to the custom target type.
See "Files & Commands Tab" for instructions on how to complete the tab.
See "SQL Tab" for instructions on how to complete the tab.
After you complete the specification definition and have mapped credentials to the target type, use the preview feature to validate your entries, in particular, to ensure the parsed view is what you expect.
Save the new or edited specification. Remember that custom configurations are in the public domain. Use the save-as-draft feature to keep the specification private while you test and refine it. See "About Save, Save As, and Versioning" for more information on the ramifications of save actions.
If you are editing a draft, the buttons change as follows:
Publish implies that you are making the draft public.
Save implies that you are creating the next version of the draft.
When done, you can begin collecting configuration data by deploying the custom configuration to target instances. See "Deploy and Undeploy Custom Configurations" for more information.
Files & Commands Tab
Create file and command specifications as follows:
Click the search icon to browse to a default base directory location. This is where the configuration files reside, or where the commands you specify are to execute.
Click the Use Property button to open a dialog where you can select a target property to include as part of the directory path. These properties serve as variables, denoted by curly braces, to be substituted with actual values at runtime. You can type additional text in the box to supplement your selection. So, for example, you might select OracleHome and append a directory–{OracleHome}/config–to collect files on the target located in the config subdirectory under the Oracle Home path. Note that the target type definition determines available target properties. User-defined properties do not appear in the list, as they are not available at the agent.
Click Advanced Settings to specify the following:
An alternate base directory for the sample target.
The encoding to use in collecting the data at the agent. Configuration data is stored in UTF-8 format in the repository. Oracle Default means use UTF-8 for XML files and the locale encoding of the target for all other file types; Target Locale means store all file types including XML in the locale encoding of the target; otherwise, select an encoding from the drop-down list. Selecting directly from the list automatically selects the accompanying radio button.
Whether to use the agent credentials (file specification only) or some other predefined credential set to access data on the target. If the customized credential set does not appear in the drop-down list, click Create to identify the credential set to use. Note that you must then specify the credentials that map to the credential set name you create. If you don't know a mapped name, you can specify a credential set when you open the Remote File Browser to add files as described in Step 3. See "Set Up Credentials" for more information.
Click Add and select file or command as the specification type.
For a file specification, enter a file name in the space provided or browse the base directory to select a file on the target. Use of wildcards (* and **) is allowed, where ** indicates 0 or more subdirectories. In using wildcards (and as a general caveat), ensure that collections do not result in too many (or too large) files, and that the files collected be configuration-related, that is, files under administrative control that change relatively rarely, so as not to overload Enterprise Manager.
For a command specification, enter command syntax in the space provided or browse the base directory to a script. You must assign a unique alias to the command. The alias you assign appears in the configuration browser as a link when viewing the custom configuration hierarchy. When you click the link, it opens the command specification in the tab on the right. The same caveats as mentioned for files apply to command output; that is, that their results are constrained in number and size, and to configuration-related data.
Select a parser to convert the configuration file or command output into a standard format for storing in the repository. There is no default. If you do not specify a parser, only the raw data format is stored and available for viewing. See "About Parsers" for more information.
Optional. Specify post-parser rules to align tree nodes. See"Set Up Rules"for information on entering rules.
Repeat Step 3 to specify additional files or commands.
Return to the section "Create or Edit a Custom Configuration" and resume with Step 8.
SQL Tab
Create SQL query specifications as follows:
Select credentials to use to connect to the database. If the customized credential set does not appear in the drop-down list, click Create to identify the credential set to use. Note that you must then specify the credentials that map to the credential set name you create. Custom configurations only support database credentials with NORMAL roles, not those with SYSDBA, SYSOPER, or other roles.
Specify a JDBC connection to an Oracle database from which to extract data via an SQL query. The connection string can be either a URL or an abstraction of database target properties. It cannot be a combination of the two; that is, partial URL and some target properties.
The URL must contain the name of the target database host, applicable port number, and the Oracle Service name (SID); for example, mydatabase.us.oracle.com:1521:ORCL.
If you want to use target properties, leave the field blank. At runtime the application will substitute values for these target properties— {MachineName}{Port}{SID}—to make the connection.
Click Add and type or paste a SQL query in the provided text box. Ensure that the query is sufficiently selective to return only pertinent configuration-related data of manageable size and scope.
You must assign a unique alias to the query. The alias you assign appears in the configuration browser as a link when viewing the custom configuration hierarchy. When you click the link, it opens the SQL query in the tab on the right.
Database Query Parser should be preselected in the drop-down list.
Optional. Specify post-parser rules to align tree nodes. See"Set Up Rules"for information on entering rules.
Repeat Step 3 to specify additional SQL queries.
Return to the section "Create or Edit a Custom Configuration" and resume with Step 8.
Set Up Credentials
If you create a credential set while creating a custom configuration, you have to specify the credentials that make up the credential set. To do this, you have to return to the Custom Configurations library and proceed as follows:
From the Setup menu (top right of the page next to the Help menu), select Security, then select Monitoring Credentials.
Select the applicable target type in the table and click Manage Monitoring Credentials.
Select the row with the credential set name you created during the custom configuration definition for the given target type and click Set Credentials.
Enter the username and password for the credential set and click Save (or Test and Save for database credentials).
Return to the "Files & Commands Tab" or "SQL Tab" description.
Set Up Rules
Use rules to differentiate nodes in the parsed representation that have the same name. This is particularly important in comparisons and change history when trying to match nodes in the parsed tree, or when expressing SQL queries to verify compliance. Rules resolve to an identifier that is appended in square brackets to node text in the tree as a way of uniquely identifying the node. An operation such as a comparison will then use the combination of node text and bracketed identifier for evaluation purposes.
A rule consists of a condition and an expression, both of which must be valid XPath expressions. The condition resolves to a node that requires the identifier. The expression resolves to a string computation for the identifier. You can use a special case SKIP expression to bypass the node specified in the condition; this is a convenient way to eliminate "noise." In other words, for purposes of comparison, ignore the node the condition resolves to.
Some parsers have default parser rules already defined. They execute automatically on the parsed representation. You can elect to use a subset of default rules, edit them, or override them with custom rules that you define.
The number in the Rules column is significant. Initially, the number is zero (0). A whole number greater than zero indicates the number of custom rules defined. Zero also appears for a parser that has default parser rules. So the appearance of a whole number in the column stipulates an override of default parser rules, if any, with the custom rules the number represents.
Set up rules as follows:
Click the Parser Rules button. The Edit Parser Rules page displays.
To define a custom rule, click Add. In the table row that appears, enter a condition and an expression as valid XPath expressions.
You can define multiple rules; they are applied to the parsed content in the order specified. Click Return when you are done.
Select a table row to delete a custom rule.
To manipulate default rules, click Add Default Rules.
Rules appear in table rows, provided the parser you selected has default parser rules. Edit and delete default rules as appropriate to your purposes. Remember that you are working with a copy of these rules; the originals remain safely intact.
Note that if you delete all rules, you are merely removing the copies you imported. Default parser rules will still fire unless overridden by custom rules.
Return to the "Files & Commands Tab" or "SQL Tab" description.
You can view a custom configuration in read-only mode to get an idea of the make-up of a specification. Perhaps, for example, to see if it is a likely candidate on which to base a new specification.
In the Custom Configurations library, select the specification table row and click View Details.
Peruse the settings and rules on the various tabs.
You can synchronize a custom configuration specification with real-time monitoring facets to monitor real-time changes to the configuration files and queries that make up the custom configuration. Real-time monitoring enables you to know such things as when files and database settings change, who made the change, whether observations were automatically reconciled, whether the actions observed were authorized, and so forth.
When you synchronize custom configurations with real-time monitoring facets, future changes to custom configurations automatically propagate to corresponding facets, which means configurations are not only collected, compared, tracked, and so forth, but also are monitored for authorized real-time changes. Note that to associate a custom configuration with a facet and to subsequently edit a custom configuration synchronized with a facet requires the additional role of EM_COMPLIANCE_DESIGNER.
In the Custom Configurations library, select the specification table row and click Enable Facet Synchronization.
The Facet Synchronization column displays a Use Facet link in the custom configuration table row. Click the link to go to the Real-time Monitoring Facets tab in the Compliance Library where you can manage the synchronization of facets with the custom configuration.
About Real-time Monitoring Rules and Facets
A real-time monitoring rule monitors operating system and database level entities that store configuration data. The rule defines the entities to monitor, user actions to watch, and any types of filters to apply to the monitoring, including when changes occurred, who made the changes, and what process made the changes. The real-time monitoring rule definition includes facets that are used to determine what is important to monitor for a given target type, target properties, and entity type.
A facet is a collection of patterns that make up one attribute of a target type. For example, you may choose to define a facet that lists all of the critical configuration files for the host target type. These are the files that, if changed, would most likely result in host instability. Another facet might be one that lists all DBA users.
For a given target type, you can create any number of facets. A target type might have a facet that identifies critical configuration files, another facet that identifies log files, another that identifies executable files, another that identifies database tables with sensitive configuration data, and so forth. The sum of all of these facets for a given target type constitutes what is important to monitor for the given target type in terms of compliance.
A facet that is specific to a target type can also include a combination of target type properties. A facet for a host target type on Windows is different from a facet for a host target type on Linux. If no target type criteria are set, a facet is assumed to apply to all criteria (any target of this type).
You can export a custom configuration as an XML file that can subsequently be imported into the same or another system.
In the Custom Configurations library, select the specification table row and click Export.
Browse to a file system location where you want to save the specification as an XML file. The saved file takes the name of the custom configuration by default.
Given appropriate privileges, you can import a custom configuration that was previously exported as an XML file.
In the Custom Configurations library, select the specification table row and click Import.
Browse to the file location. Select the file and click the Import button on the dialog.
The imported specification appears in the Custom Configurations library.
You must be the owner or otherwise have sufficient privileges to delete a custom configuration. Note that there are dependencies that potentially impact deletion, including deployments, job schedules, existing collections, and so forth.
In the Custom Configurations library, select the specification table row and click Delete.
The system validates permissions and otherwise checks for dependencies that might prevent the deletion, although some dependencies cannot be verified until a job submission involving the custom configuration.
Deployment of a custom configuration means to direct the specification to a target where a monitoring agent will collect configuration data based on the specification's definition. A custom configuration can be deployed to multiple targets. You must have sufficient privileges to deploy and undeploy custom configurations.
To deploy a custom configuration:
In the Custom Configurations library, select the specification table row and click Deploy.
On the Deployments page, click Add. In the dialog that opens, search for and select targets of the specified target type where you want to deploy the custom configuration.
When you close the dialog (click Select), a new column appears denoting a pending action of Deploy and the status becomes Selected for deployment.
Proceed as follows:
Click Apply to confirm the action while remaining on the Deployments page. The action column disappears, and the status becomes Deployment job in progress.
Click OK to schedule the deployment and return to the library.
Click Cancel to void the request and return to the library.
Click Refresh Status on the Deployments page to confirm a successful outcome.
If you update a deployed custom configuration, redeployment occurs automatically.
To undeploy a custom configuration:
Select the deployment in the table.
Click Remove. A new column appears denoting a pending action of Undeploy; status remains Deployed.
Proceed as follows:
Click Apply to confirm the action while remaining on the Deployments page. The action column disappears, and the status becomes Undeployment job in progress.
Click OK to schedule the undeployment and return to the library.
Click Cancel to void the request and return to the library.
Click Refresh Status on the Deployments page to confirm a successful outcome.
When viewing custom configurations in the library, a green check mark in the Deployments column denotes a currently deployed custom configuration. Click the check mark to open the Deployments page.
Edit a Deployment
In the Custom Configurations library, locate the appropriate table row and click the deployments link.
On the Deployments page, select the deployment in the table and click Edit.
The type of custom configuration, that is, file/command-based or SQL-based, determines the make-up of the dialog that opens. Specify a base directory to override the default base directory currently in effect, or change the JDBC URL, as appropriate.
Proceed as follows:
Click Apply to confirm the action while remaining on the Deployments page. The action column disappears, and the status becomes Redeployment job in progress.
Click OK to schedule the redeployment and return to the library.
Click Cancel to void the request and return to the library.
Click Refresh Status on the Deployments page to confirm a successful outcome.
Note that the edit applies to the deployment of the specification; it does change the custom configuration definition.
View a Configuration Collection
You must have sufficient privileges to view a custom configuration's collected data.
In the Custom Configurations library, locate the appropriate table row and click the deployments link.
On the Deployments page, select the deployment in the table and click View Configuration.
In the configuration browser popup window, peruse details of the custom configuration by selecting nodes in the tree hierarchy on the left:
The root node represents the target instance being monitored. The right pane displays target properties and immediate relationships.
The next level down in the tree represents a template for the specification. The right pane displays specification details such as configurations being collected and the base directory from which they are collected.
The remaining leaf nodes in the tree represent the configuration data collected. The right pane displays the configuration data in both parsed and raw format.
When you create a custom configuration, you have options to save or save as draft. A normal save action makes the specification publicly available to the general user community. A save as draft action keeps the specification private to you. How you use these actions when creating and editing specifications influences the mechanics of versioning. Consider the following scenarios:
You create and save a custom configuration; this is public version 1. You subsequently edit public1 and save as a draft; this becomes draft1. Public1 is still generally available. You edit draft1 and publish; this becomes public2. Note that in parallel, someone else with the proper permissions can also edit public1 and save as a draft to create version 1 of draft2.
You create and save a custom configuration as a draft; this is version1 of draft1. You edit and save again; this becomes version 2 of draft1. Repeat the edit-and-save operation; this becomes version 3 of draft1. Edit version 3 of draft1 and publish; this becomes public version 1.
Working with custom configurations requires privileges specific to the given operation you want to perform.
| Operation | Required Privilege (Role) |
|---|---|
| Create new target type | EM_PLUGIN_OMS_ADMIN
To create a new target type, ensure that the administrator has installed a software library (Setup > Provisioning and Patching > Software Library). This must be done once, after Enterprise Manager installation. |
| Create new target instance | EM_PLUGIN_AGENT_ADMIN |
| Create or import custom configuration | "Manage custom configurations owned by user" (or the more powerful "Manage custom configurations owned by any user") |
| Associate custom configuration with an auto-synchronized real-time monitoring facet | EM_COMPLIANCE_DESIGNER |
| Edit or delete custom configuration | Differs, depending on the specific activity within the realm of editing:
|
| Deploy or undeploy custom configuration on a target | "Manage target metrics" privilege on the target instance; "Create" privilege for Job System resource type (to schedule deployment/undeployment;) EM_PLUGIN_AGENT_ADMIN (to deploy a plug-in to an agent) |
| Create a new credential set | Superuser |
| View custom configuration definition | None |
| View custom configuration collected data | Regular "target instance view" privilege |
Note that editing an imported custom configuration may be restricted to edits that do not change the version, depending on options set during export. One such permissible edit would be to credential set information.
A Parser takes raw configuration data and parses it into a nested attribute structure. This structure is a tree hierarchy where nodes are containers and leaves are name value pairs of attributes, or properties. The structure is well-suited to representation in a graphical user interface.
Cloud Control includes a host of parsers out-of-box. Each parser consists of a base parser and, in many cases, parser parameters. Some parsers also contain post-parsing rules. A base parser refers to a parser category that is capable of parsing data of a particular format. Parser parameters provide a way to tailor the base format to accommodate variations in data formatting. Post-parsing rules are a mechanism for aligning nodes in the tree that otherwise have no distinct identity. This is important when comparing configurations and tracking change history to avoid flagging "false positive" differences. It also aids in specifying search criteria and crafting SQL queries used in compliance rules.
There are four base parser varieties:
XML
Format-specific
Columnar
Properties
Some parsers have out-of-box default rules. These rules address well-known instances where nodes need additional clarifying information, or, in some cases, to be skipped altogether (ignored) . Specifically, the WebLogic and WebSphere parsers contain default rules to address such instances. You can leave these rules as is, execute a subset of them, or replace them with your own custom rules.
While creating, editing, or viewing custom configurations, you can peruse the list of available parers, their default parameters, and post-parser rules, if applicable. Parser parameters dictate formatting such as comment character, delimiters, start and end characters, and so forth. You cannot edit these parameters, but you can export a parser as an XML file, edit the file, and import it back into the application under a new name. Some parsers also have default rules that serve to align nodes in the parsed tree for purposes of comparison, for example.
While working with a custom configuration, click Manage Parsers. A list of available parsers appears in a table. The column on the right (Base Parsers) denotes a general parser category, Properties for example, which implies file types that contain name/value pairs.
Select a parser and click Details. This dialog also shows default rules, if any.
Click the Parameters tab to see the parameter defaults in effect. You can then judge if you need to edit the parser to conform with your file format conventions.
Click the Default Rules tab to see the post-parsing rules that ship with certain parsers. This is a good way to get exposure to rules formation.
Assume you want to change the delimiter character in a given parser.
With the parser selected in the table, click Export.
In the dialog that opens click Save and navigate to a file system location. Save the XML file with an appropriate name.
In making your edits, be sure to change the parser ID and parser name in the XML, as you are creating a customized version of an out-of-box parser.
Assume you edited a shipped parser and now want to import it for use in creating custom configurations.
With the Parsers table open, click Import.
In the dialog that opens, browse to the file location where you edited the exported parser file. Select it and click Import on the dialog.
The edited parser file now appears in the Parsers table where it can be used in custom configuration creation.
Note:
The parser you edit must be one of the base parsers. For a complete list of supported parsers and details about parser parameters, see Enterprise Manager reference documentation.Cloud Control has two XML parsers: a default (attribute-keyed) XML parser and a generic XML parser.
XML elements with no XML attributes or child elements become parsed attributes; all other elements become containers.
XML attributes become parsed attributes.
Element text content becomes a parsed attribute, with its name dependent on whether or not the tag contains any XML attributes. If the tag contains XML attributes, the parsed attribute name takes the value specified in the STORE_CONTENT_AS parameter; otherwise, the parsed attribute name takes the tag name.
The default XML parser accepts the following parameters:
| Parameter | Description |
|---|---|
MULTIKEY_DELIMITER |
Delimiter that separates a list of XML attribute names in the CONTAINER_NAME parameter; default is tilde (~) |
STORE_CONTENT_AS |
Name to give to parsed attributes derived from element text content, where the element contains XML attributes; default is text_value |
CONTAINER_NAME |
A list of XML attribute names delimited by the value of the MULTIKEY_DELIMITER parameter. If an attribute name in this list appears in a tag in the original file, the tag becomes a container named for the value of the XML attribute. All other XML attributes become parsed attributes as usual. The tag name itself is discarded.
For example, the list includes attribute names Moe and Larry in this order. The original file contains an XML tag Stooges that has attributes Moe, Larry, and Curly. As Moe appears first in the delimited list, its value, leader, becomes the parsed container name; Larry and Curly become parsed attributes. The tag name Stooges is discarded. The original XML fragment might be as follows: <?xml version="1.0" encoding="UTF-8"?> <Comedy> <Stooges Moe="leader", Larry="zany", Curly="bald"> </Stooges> </Comedy> |
Cloud Control provides an out-of-box attribute-keyed parser specifically designed to parse the WebLogic config.xml file. It has the same parameters as the default XML parser and comes with 26 default post-parsing rules to uniquely identify nodes with the same name.
Cloud Control provides several out-of-box attribute-keyed parsers designed to parse specific WebSphere configuration files. Each parser has the same parameters as the default XML parser and comes with a set of default post-parsing rules to uniquely identify nodes with the same name. There are parsers for the following WebSphere configuration files:
node.xml (1 default post-parsing rule)
plugin-cfg.xml (7 default post-parsing rules)
resource.xml (9 default post-parsing rules)
server.xml (13 default post-parsing rules)
variables.xml (1 default post-parsing rule)
All XML elements become containers.
All XML attributes become parsed attributes.
Element text content becomes a parsed attribute that takes the name text_value, where the text content becomes the parsed attribute value.
The generic XML parser accepts no parameters.
This section contains three XML parser examples:
As parsed using the default XML parser, with out-of-box parameter values
As parsed using the default XML parser, with modified parameter values
As parsed using the generic XML parser
Parsed examples derive from the following original XML file:
<?xml version="1.0" encoding="UTF-8"?> <Application> <AppName>foo</AppName> <Server name="ajax" os="linux">production</Server> </Application>
Default XML Parser (Out-of-Box Parameter Values)
When parsed using the default XML parser with out-of-box parameter values, the parsed version appears as follows:
Application
AppName = foo
Server
name = ajax
os = linux
text_value = production
Note the following about this parsed version:
The element contents of the AppName and Server tags become parsed attributes.
Since the AppName tag contains no XML attributes, the parsed attribute name takes the tag name.
Contrast with the Server tag, which has XML attributes (name and os). This results in a container named for the tag (Server), with three parsed attributes, one for each of the XML attributes, and a third for the text content of the Server tag, which is set to the value of the STORE_CONTENT_AS parameter (text_value).
Default XML Parser (Modified Parameter Values)
To modify parameter values, you have to create a new parser by exporting the default XML parser, modifying the exported XML file, and importing the modified parser, using a new name and parser ID.
Assume you followed this process, making the following modifications:
Set the STORE_CONTENT_AS parameter to the value myVal
Set the CONTAINER_NAME parameter to the value name
When parsed using the default XML parser with modified parameter values, the parsed version appears as follows:
Application
AppName = foo
ajax
os = linux
myVal = production
Note the following about this parsed version:
The AppName tag remains the same; that is, it has no XML attributes so it becomes a parsed attribute.
Since the Server tag has an XML attribute that matches the value of CONTAINER_NAME, the container takes the value of the attribute (ajax), obviating the name=ajax parsed attribute. Remember that the out-of-box CONTAINER_NAME parameter has a placeholder but no actual default value; thus, the difference in this version of the parsed representation.
The remaining Server tag attribute (os) becomes a parsed attribute as usual, and the text content associated with the tag becomes the value of the attribute myVal, per the edited STORE_CONTENT_AS parameter.
Generic XML Parser
When parsed using the generic XML parser (the one that takes no parameters), the parsed version appears as follows:
Application
AppName
text_value = foo
Server
name = ajax
os = linux
text_value = production
Refer to the generic XML parser description for a reminder of how parsing occurs.
Format-specific base parsers are applicable only to a particular data format. Format-specific parsers run the gamut from having no parameters to a few to many with which to tailor formatting.
| Parser | Description |
|---|---|
| Blue Martini DNA | Parser for Blue Martini DNA files (no parameters). |
| Connect:Direct | Parser for Connect:Direct .cfg files (no parameters). |
| Database Query (see Sample SQL Query Parsing and Rule Application for an example) | Parser for custom configuration database query output. Enterprise Manager automatically transforms query results into a format the parser accepts, organizing results into sections similar to a Windows .ini file. Each section represents one record; each line in a section contains a table column name and a value. See Database Query Parser Parameters. |
| Db2 | Parser for the output of the DB2 GET DATABASE CONFIGURATION command (no parameters). |
| Directory | Parser for files containing multiple name value pairs on the same line, where each line may have varying numbers of pairs. For example, the first line might be a=b j=k, the second line c=d m=n y=z, and so forth. See Directory Parser Parameters. |
| E-Business Suite | Parser for E-Business Suite .drv files. The parser converts IF...THEN...ELSE structures in the file into containers in the parsed representation, and the rest of the lines into a container with a fixed number of parsed attributes. These lines can be of two types: directory specifications, whose parsed attribute names are specified in the DIR_HEADER parser parameter; configuration file specifications, whose parsed attribute names are specified in the HEADER parser parameter. See E-Business Suite Parser Parameters. |
| Galaxy CFG | Parser for Galaxy .cfg files. See Galaxy CFG Parser Parameters. |
| Introscope | Parser for Introscope files (no parameters). |
| MQ-Series | Parser for MQ-Series files. See MQ-Series Parser Parameters. |
| Odin | Parser for Odin files (no parameters). |
| Oracle ORA | Parser for Oracle .ora files, such as tnsnames.ora (no parameters). |
| Siebel | Parser for Siebel siebns files. The parser creates a container for each unique path in the file, and attributes for name value pairs, except where a line contains the string Type=empty, in which case the parser does not create a parsed attribute for the line. See Siebel Parser Parameters. |
| UbbConfig | Parser for BEA Tuxedo files (no parameters). The parser converts sections prefixed with an asterisk (*), and names in double quotes at the start of a new line, into containers. It converts all other data into attributes. |
| Unix Installed Patches | Parser for Unix installed patches data. The parser creates one container per (non-comment) line of the file. It treats every field ending with a colon (:) on each line as a property name field and the value following, if any, as the property value. Note that a property does not have to have a value. See Unix Installed Patches Parser Parameters. |
| Unix Recursive Directory List | Parser for output of Unix recursive directory listing (ls -l -R). The parser converts each subdirectory line into a container, and each file information line into a container with a fixed set of attributes. SeeUnix Recursive Directory List Parser Parameters. |
Remember, to modify a format-specific parser, you have to create a new parser by exporting the particular parser, modifying the exported XML file, and importing the modified parser, using a new name and parser ID.
Database Query Parser Parameters
The following table describes the parameters with which you can customize the Database Query parser:
| Parameter | Description |
|---|---|
CELL_DELIMITER |
Character that separates name value pairs; default is =. |
PROPERTY_DELIMITER |
Character that separates the length of a name or value from the value itself; default is _. |
COMMENT |
Character that tells the parser to ignore the line that follows; default is #. |
SECTION_START |
Character that denotes the start of a section; default is \[ (backslash is escape character). |
SECTION_END |
Character that denotes the end of a section; default is \] (backslash is escape character). |
USE_INI_SECTION |
Flag that tells the parser to use Windows .ini type sections; default is true. |
Directory Parser Parameters
The following table describes the parameters with which you can customize the Directory parser:
| Parameter | Description |
|---|---|
CELL_DELIMITER |
Character that separates one property from another; default is a space. |
EXTRA_DELIMITER |
Character that separates a property name from its value; default is =. |
COMMENT |
Character that tells the parser to ignore the line that follows; default is #. |
E-Business Suite Parser Parameters
The following table describes the parameters with which you can customize the E-Business Suite parser:
| Parameter | Description |
|---|---|
DIR_HEADER |
A tilde-delimited list of attribute names for directory specifications. |
STRUCTURE_START |
A tilde-delimited list of regular expressions denoting the start of a structure. |
CELL_DELIMITER |
A tilde-delimited list of regular expressions denoting name value pair delimiters. |
HEADER |
A tilde-delimited list of attribute names for file specifications. |
COMMENT |
A tilde-delimited list of regular expressions denoting comments. |
STRUCTURE_END |
A tilde-delimited list of regular expressions denoting the end of a structure. |
LAST_FREE_FORM |
Flag that tells the parser to ignore cell delimiters in the last value of a directory or file specification; default is true. |
ELEMENT_FIELD |
A tilde-delimited list of file specification attribute names. The parser concatenates values of the specified attributes to form the name of the container associated with the file specification. |
DIR_ELEMENT_FIELD |
A tilde-delimited list of directory specification attribute names the parser uses to determine the name of the container associated with the directory specification. |
Galaxy CFG Parser Parameters
The following table describes the parameters with which you can customize the Galaxy CFG parser:
| Parameter | Description |
|---|---|
COMMENT |
Character that tells the parser to ignore the line that follows; default is !. |
ADD_SUFFIX |
Names of attributes whose values to append to a container name. |
MONO_PROP_SECTION |
Names of sections that have a single property. |
MULTI_PROP_SECTION |
Names of sections that have multiple properties. |
NODES_SECTION |
Names of section start and end elements |
MQ-Series Parser Parameters
The MQ-Series parser has a single parameter that you can customize: COMMENT, which defaults to *.
Siebel Parser Parameters
The following table describes the parameters with which you can customize the Siebel parser:
| Parameter | Description |
|---|---|
LINES_TO_SKIP |
Tells the parser the number of lines to ignore at the beginning of the file; default is 4. |
CELL_DELIMITER |
A tilde-delimited list of regular expressions denoting name value pair delimiters. |
COMMENT |
A tilde -delimited list of regular expressions denoting comments. |
SECTION_START |
A tilde-delimited list of regular expressions denoting the start of a unique path specification section. |
SECTION_END |
A tilde-delimited list of regular expressions denoting the end of a unique path specification section. |
USE_INI_SECTION |
Flag that tells the parser to use Windows .ini type sections; default is true. |
Unix Installed Patches Parser Parameters
The following table describes the parameters with which you can customize the Unix Installed Patches parser:
| Parameter | Description |
|---|---|
CELL_DELIMITER |
Character that separates name value pairs; default is a space. |
EXTRA_DELIMITER |
Character that separates a property name from its value; default is :. |
COMMENT |
Character that tells the parser to ignore the line that follows; default is #. |
Unix Recursive Directory List Parser Parameters
The following table describes the parameters with which you can customize the Unix Recursive Directory List parser:
| Parameter | Description |
|---|---|
LINES_TO_SKIP |
Tells the parser the number of lines to ignore at the beginning of the file; default is 4. |
CELL_DELIMITER |
A tilde-delimited list of regular expressions denoting name value pair delimiters. |
COMMENT |
A tilde-delimited list of regular expressions denoting comments. |
HEADER |
A tilde-delimited list of attribute names. |
LAST_FREE_FORM |
Flag that tells the parser to ignore cell delimiters in the last value of a line; default is true. |
SECTION_START |
A tilde-delimited list of regular expressions denoting the start of a subdirectory section. |
SECTION_END |
A tilde-delimited list of regular expressions denoting the end of a subdirectory section. |
ELEMENT_FIELD |
A tilde-delimited list of attribute names. The parser concatenates values of the specified attributes to form the name of the container associated with the line. |
Columnar parsers are inherently flexible owing to the parameters they can accept to tailor formatting. All columnar parsers use a subset of the same parameters.
This section describes all columnar base parser parameters. Although the base parser can accept values for any of these parameters, a given parser specification does not necessarily need to provide values for all of them. All parameters have default values, which are used in the absence of a specified value, although in some cases, parameters have explicit values.
Use quotes when delimiters or other special text such as comment characters or new lines are part of some value. The QUOTE_DELIMITER determines the character value to use. Prefix the quote delimiter with a backslash (\) if you need to escape the character. Use a backslash to escape the backslash character itself (\\) in quoted strings.
| Parameter | Description |
|---|---|
COMMENT |
A tilde-delimited list of regular expressions that denote comment characters or sequences. For example, #[^\r\n]* specifies that everything on a line following the # character is a comment. Default is an empty list; that is, parse all file contents. |
LINES_TO_SKIP |
The number of initial lines (excluding blank or comment lines) to ignore for parsing purposes, treating them in effect as comments. Default is 0; that is, skip no lines. |
CELL_DELIMITER |
A tilde-delimited list of regular expressions that delimit line values. Default is an empty list; that is, no delimiters (it is unusual to use the default). |
QUOTE_DELIMITER |
A tilde-delimited list of regular expressions that define how quoted values begin and end (usually either a single or double quote character). The beginning and end quote delimiter must be the same. Default is an empty list; that is, parser does not recognize quoted values. |
PROPERTY_DELIMITER |
A tilde-delimited list of regular expressions that delimit property names and values. Default is an empty list; that is, no property delimiters.
Rarely, a columnar file may contain name value pairs of the syntax a=b. |
RESERVED_DIRECTIVES |
A tilde-delimited list of property keywords. Some crontab files contain lines of simple name value pairs, separated by a delimiter (foo=bar), thus violating the requirement that each line have the same number of fields. This parameter provides a workaround to specify property keywords. In the example, the property keyword would be foo. This says, in effect, parse any line beginning with this keyword as a parsed attribute name value pair under the root container. Default is an empty list; that is, no property keywords. |
ALTERNATE_DELIMITER |
An alternate delimiter for property names and values. Default is '/' (used only if ALTERNATE_FIELD parameter is nonempty). |
ALTERNATE_FIELD |
A tilde-delimited list of fields separated by alternate delimiters. Default is an empty list; that is, no alternate delimiters. |
HEADER_FLAG |
A flag specifying whether or not the file has a header line that specifies the column names. Default is false. |
HEADER |
A tilde-delimited list of column names to use if there is no header line. Default is an empty list; that is, no column names (it is unusual to use the default). |
ELEMENT_FIELD |
A tilde-delimited list of column names whose values the parser concatenates to create the container name associated with a line. Default is an empty list; that is, no column names (it is unusual to use the default). |
IGNORE_FIELD |
A tilde-delimited list of column names to ignore. No parsing of values in these columns occurs. Default is an empty list; that is, ignore nothing. |
LAST_FREE_FORM |
A flag that specifies whether the last column is free form. The parser ignores all delimiters in a free form column value. Default is false. |
USE_LINE_COMMENT |
A flag that specifies whether to treat end of line comments as a value to appear in the parsed representation of the data. Default is false. |
Properties parsers are inherently flexible owing to the parameters they can accept to tailor formatting and handle disparate organizational elements. All properties parsers use the same set of basic and advanced parameters, as well as advanced constructs.
This section describes basic properties parser parameters that are required to parse simple property data formats. Simple property data formats specify a property as a name value pair, usually with a defined delimiter separating the name and the value: foo=bar. The basic data format is a list of properties, one property to a line, together with optional comments; a java.properties file, for example. All parameters have default values, which are used in the absence of a specified value.
Use quotes when delimiters or other special text such as comment characters or new lines are part of some value. The QUOTE_DELIMITER determines the character value to use. Prefix the quote delimiter with a backslash (\) if you need to escape the character. Use a backslash to escape the backslash character itself (\\) in quoted strings.
A comment character such as the pound sign (#), or a particular character sequence (//) usually denotes a comment. Special sequences such as a C style comment (/*….*/) might denote the beginning and end of a comment. Some files might have generic informational content in the first couple of lines. In this case, a parameter is available to tell the parser to ignore these lines.
| Parameter | Description |
|---|---|
COMMENT |
A tilde-delimited list of regular expressions that denote comment characters or sequences. For example, #[^\r\n]* specifies that everything on a line following the # character is a comment. Default is an empty list; that is, parse all file contents. |
LINES_TO_SKIP |
The number of initial lines (excluding blank or comment lines) to ignore for parsing purposes, treating them in effect as comments. Default is 0; that is, skip no lines. |
CELL_DELIMITER |
A tilde-delimited list of regular expressions that delimit line values. Default is an empty list; that is, no delimiters (it is unusual to use the default). |
QUOTE_DELIMITER |
A tilde-delimited list of regular expressions that define how quoted values begin and end (usually either a single or double quote character). The beginning and end quote delimiter must be the same. Default is an empty list; that is, parser does not recognize quoted values. |
ALLOW_NAME_ONLY_PROPERTIES |
A flag that indicates whether the parser allows property names without a delimiter or a value. Default: false. |
REVERSE_PROPERTY |
A flag that indicates whether the parser allows the value to come before the delimiter and property name. Default: false. |
This section describes advanced properties parser parameters that are required to parse more complex property data formats. All parameters have default values, which are used in the absence of a specified value.
| Parameter | Description |
|---|---|
PROPERTY_DELIMITER |
A tilde-delimited list of regular expressions denoting property delimiters. For example, the text "a=b : x=y" could be interpreted in either of two ways:
If a colon (:) is the property delimiter, the parsing engine interprets the text as containing two separate properties. Default is an empty list; that is, parser does not recognize property delimiters. |
LINE_END_DELIMITER |
A tilde-delimited list of regular expressions denoting line end sequences. When the parser encounters a line end delimiter, it assumes a new property or construct starts on the next line. Default is an empty list; that is, parser does not recognize line end delimiters. |
CONTINUE_LINE |
A tilde-delimited list of regular expressions denoting continue line sequences. When the parser encounters a continue line pattern, it interprets data on the following line as a continuation of the construct or property on the previous line, as opposed to interpreting the new line as the beginning of a new property or construct. For example, the parser must encounter a line continuation pattern to recognize property values that span multiple lines. Default is an empty list; that is, parser does not recognize line continuation patterns. |
SECTION_START |
A tilde-delimited list of regular expressions denoting the beginning of a section. Sections cannot be nested. Default is an empty list; that is, parser does not recognize sections. |
SECTION_END |
A tilde-delimited list of regular expressions denoting the end of a section. Default is an empty list. |
STRUCTURE_START |
A tilde-delimited list of regular expressions denoting the beginning of a structure. Structures can be nested. Default is an empty list; that is, parser does not recognize structures. |
STRUCTURE_END |
A tilde-delimited list of regular expressions denoting the end of a structure. Default is an empty list. |
XML_STYLE_TAG |
A flag that indicates whether structures in the file are XML style tags. Default: false. |
USE_INI_SECTION |
A flag that indicates whether INI style sections are present. Default: false. |
RESERVED_DIRECTIVES |
A tilde-delimited list of reserved names indicating the start of a reserved directive. Default is an empty list; that is, parser does not recognize reserved directives. |
RESERVED_FUNCTIONS |
A tilde-delimited list of reserved names indicating the start of a reserved function. Default is an empty list; that is, parser does not recognize reserved functions. |
DIRECTIVE_PROPERTIES |
A tilde-delimited list of reserved directive- implicit property names. Default is an empty list. |
FUNCTION_PROPERTIES |
A tilde-delimited list of required reserved function-explicit property names. Default is an empty list. |
SECTION_PROPERTIES |
A tilde-delimited list of section-implicit property names. Default is an empty list. |
STRUCTURE_PROPERTIES |
A tilde-delimited list of structure-implicit property names. Default is an empty list. |
ELEMENT_FIELD |
A keyword to be ignored by the parser when parsing properties. This typically applies to data formats that specify a keyword before a name value pair; "set a=b" for example. Default is an empty list; that is, parser ignores nothing. |
ALLOW_ELEMENT_CELL |
A flag that indicates whether the file format supports element cell structures. Default: false. |
SECTION_EXPLICIT_PROPERTIES |
A flag that indicates whether sections support explicit properties. Default: false. |
STRUCTURE_EXPLICIT_PROPERTIES |
A flag that indicates whether structures support explicit properties. Default: false. |
NEWLINE_CONTINUE_LIN |
A flag that indicates whether newlines can be line continuation sequences. Default: false. |
KEYWORD_FIELD |
A tilde-delimited list of regular expressions denoting keywords that precede properties that use a whitespace delimiter. Default is an empty list; that is, parser does not recognize keywords. |
Properties files come in variety of file formats. To accommodate the widest possible range of formats, the generic properties base parser uses combinations of constructs found in most files.
The constructs fall into two categories:
Container constructs, which can be reserved functions, reserved directives, XML structures, structures, delimited structures, INI sections, delimited sections, sections, and element cells
Property constructs, which can be simple properties, reverse properties, keyword properties, keyword name properties, bracket properties, implicit properties and explicit properties
Of the element constructs, section constructs cannot be nested, but can contain any other construct. Structure constructs can be nested, and can contain any construct except a section. Element cells can be nested, but can only contain element cells and simple properties. Reserved directives and reserved functions cannot be nested, nor can they contain any other constructs.
The rest of this section describes the constructs the base properties parser supports.
Simple Property
A simple property consists of a property name, cell delimiter, property value, and newline sequence, in that order. A simple property may take up more than one line, although properties that span multiple lines usually contain a line continuation character or sequence. The parser ignores whitespace such as tabs and spaces, unless a parameter specifies whitespace as having some significance (cell delimiter, for example).
Example: name=value_that_wraps_to_next_line_/, where the forward slash serves as a line continuation character. A Java Properties file typifies this data format.
Keyword Property
This construct is the same as a simple property, only with a keyword in front, which the parser ignores.
Example: set name=value, where set is the ignored keyword. A Unix System file typifies this data format.
Keyword Name Property
This construct is a simple property where the property name matches a regular expression specified in the KEYWORD_FIELD parser parameter. This is a special case property type specific to the Unix XINETD parser. The XINETD file uses an equal sign (=) as a cell delimiter except when the property begins with the keyword "include" or "includedir", in which case the cell delimiter is whitespace.
While added specifically for XINETD files, the property can be used for other file types where appropriate.
Example: includedir /etc, where includedir is the parser parameter regular expression and whitespace is the cell delimiter.
Explicit Property
An explicit property consists of a property name, a delimiter, and a property value. Unlike a simple or keyword property, an explicit property is bound to a container construct such as a section or a structure; an XML tag attribute, for example.
Examples:
[SectionName p1=v1 p2=v2] <StructureName p1=v1 p2=v2> ... </StructureName>
In these constructs, the name value pairs p1 v1 and p2 v2 are explicit properties. A Sun ONE Obj file typifies this data format.
Implicit Property
An implicit property is a property value without an associated property name. Like an explicit property, an implicit property is bound to a container construct, usually a reserved directive. The DIRECTIVE_PROPERTIES parser parameter contains the property names of implicit properties.
Examples:
[SectionName myName myPath]
<StructureName myName myPath> ... </StructureName>
In these constructs, the implicit properties have the values myName and myPath, with the presumed property names name and path, as declared in the DIRECTIVE_PROPERTIES parser parameter. An Apache HTTPD file typifies this data format.
Reserved Function
A reserved function is a keyword followed by one or more explicit properties. The RESERVED_FUNCTIONS parser parameter specifies keywords that denote reserved functions.
Example: Error fn="query-handler" type="forbidden", where Error is the reserved function keyword specified in the RESERVED_FUNCTIONS parser parameter. A Sun ONE Magnus file typifies this data format.
Reserved Directive
A reserved directive is a keyword followed by one or more implicit properties. The RESERVED_DIRECTIVES parser parameter specifies keywords that denote reserved directives.
Example: LoadModule cgi_module "/bin/modules/std/cgi", where LoadModule is the reserved function keyword specified in the RESERVED_DIRECTIVES parser parameter. An Apache HTTPD file typifies this data format.
XML Structure
An XML structure is a standard XML tag that can contain a name only, a name followed by explicit properties, or a name followed by implicit properties.
Examples:
<Name> ... </Name> <Name p1=v1 p2=v2> ... </Name> <Name "implicit_property1" "implicit_property2"> ... </Name>
A WebAgent file typifies this data format.
Delimited Structure
A delimited structure consists of the following (in the specified order):
Structure name
Delimiter
Start structure character or character sequence
Structure contents
End structure character or character sequence
Example:
StructureName = {
...
}
Explicit and implicit properties are not allowed. Java Policy and Custom CFG files typify this data format.
Structure
A structure consists of the following (in the specified order):
Structure name
Start structure character or character sequence
Structure contents
End structure character or character sequence
The only difference between a delimited structure and a structure is the delimiter; that is, a structure does not require a delimiter between the structure name and the start structure indicator.
Example:
StructureName {
...
}
Explicit and implicit properties are not allowed. A Unix XINETD file typifies this data format.
INI Section
And INI section resembles a section heading in a Windows .ini file, characterized by:
Section start character or character sequence
Section name
Optional (explicit and implicit) properties
Section end character or character sequence
Examples:
[SectionName] [SectionName p1=v1 p2=v2] [SectionName "implicit_property1" "implicit_ property2"]
SmWalker and Sectioned Properties files typify this data format.
Delimited Section
A delimited section is a line that begins with a common pattern, but otherwise resembles a simple property.
Examples:
HKEY_LOCAL_MACHINE\SOFTWARE\A\B\C=789 HKEY_LOCAL_MACHINE\SOFTWARE\X\Y\Z=123
These are two delimited section headings where the common pattern is HKEY_. SiteMinder Registry and LDAP files typify this data format.
Element Cell
An element cell consists of an element cell name and a property name value pair of the form A = B = C. Element cells typically use line continuation sequences and nesting to clarify the structure. An element cell that has multiple properties uses a property delimiter to separate them.
Example 1:
EC = \
B = C, D = F
This example is an element cell named EC with two property name value pairs, B = C and D = F, separated by a comma. The structure uses the backslash character (\) to indicate line continuation. The advanced properties parser parameters PROPERTY_DELIMITER and CONTINUE_LINE define the respective format characters.
Example 2:
EC = \
EC2 = \
A = B, \
C = D
This example is an element cell named EC that has a nested element cell named EC2 that contains two property name value pairs, A = B and C = D. This example uses the same delimiter and line continuation characters.
A collected configuration file is stored in raw form and, if a parser is specified, in a tree structure of nodes, or containers, and attributes, or properties. The file also is generated internally in XML format for the purpose of applying post-parsing rules, which consist of XPath conditions and expressions. Note that even non-XML files are generated in this internal format. Since the internal format must accommodate other file types, it introduces an additional root node in the XML to compensate for files such as Java properties files that have only attribute names and values.
Examples of how files are parsed and displayed, and the effects of post-parsing rules help to clarify:
Consider the following simple XML file:
<dir name="/a/b/c">
<file name="file1" size=120/>
<file name="file2" size=350/>
</dir>
Its parsed form, using the default XML parser, appears in the user interface in the following tree structure:
dir
name = /a/b/c
file
name = file1
size = 120
file
name = file2
size = 350
Notice that two containers have the same name (file), which makes it impossible to distinguish between the two, at the container level, at least. Thus, this file is a candidate for a post-parsing rule. As mentioned, there is a special internal XML format against which to apply a rule's XPath condition and expression. This format treats nodes and attributes as XML elements, and converts attribute values into corresponding element text content. It also adds a root element that doesn't appear in the original file:
<root>
<dir>
<name>/a/b/c</name>
<file>
<name>file1</name>
<size>120</size>
</file>
<file>
<name>file2</name>
<size>350</size>
</file>
</dir>
</root>
Given the problem in the parsed form of having two containers with the same name, a rule resolution might consist of the following:
/root/dir/filename/text()Effectively, this says: for each file evaluate name/text() to produce an identifier that distinguishes one file from another within the dir node.
After applying the post-parsing rule, the parsed tree structure appears as follows:
dir
name = /a/b/c
file[file1]
name = file1
size = 120
file[file2]
name = file2
size = 350
The rule resolves to an identifier appended in square brackets to the container name. The combination (file [file1], for example) enables various operations such as compare, search, change history, and so forth, to distinguish between file containers.
Consider the following simple ORA file:
acme=
(DESCRIPTION=
(SOURCE_ROUTE=yes)
(ADDRESS=(PROTOCOL=tcp)(HOST=host1)(PORT=1630))
(ADDRESS_LIST=
(FAILOVER=on)
(LOAD_BALANCE=off)
(ADDRESS=(PROTOCOL=tcp)(HOST=host2a)(PORT=1630))
(ADDRESS=(PROTOCOL=tcp)(HOST=host2b)(PORT=1630)))
(ADDRESS=(PROTOCOL=tcp)(HOST=host3)(PORT=1630))
(CONNECT_DATA=(SERVICE_NAME=Sales.us.acme.com)))
Its parsed form, using the Oracle ORA parser, appears in the user interface in the following tree structure:
acme
DESCRIPTION
SOURCE_ROUTE yes
ADDRESS
PROTOCOL tcp
HOST host1
PORT 1630
ADDRESS_LIST
FAILOVER on
LOAD_BALANCE off
ADDRESS
PROTOCOL tcp
HOST host2a
PORT 1630
ADDRESS
PROTOCOL tcp
HOST host2b
PORT 1630
ADDRESS
PROTOCOL tcp
HOST host3
PORT 1630
CONNECT_DATA
SERVICE_NAME Sales.us.acme.com
Notice that the ADDRESS_LIST address containers are indistinguishable. Thus, this file is a candidate for a post-parsing rule. As mentioned, there is a special internal XML format against which to apply a rule's XPath condition and expression. This format treats nodes and attributes as XML elements, and converts attribute values into corresponding element text content. It also adds a root element that doesn't appear in the original file:
<root>
<acme>
<DESCRIPTION>
<SOURCE_ROUTE>yes</SOURCE_ROUTE>
<ADDRESS>
<PROTOCOL>tcp</PROTOCOL>
<HOST>host1</HOST>
<PORT>1630</PORT>
</ADDRESS>
<ADDRESS_LIST>
<FAILOVER>on</FAILOVER>
<LOAD_BALANCE>off</LOAD_BALANCE>
<ADDRESS>
<PROTOCOL>tcp</PROTOCOL>
<HOST>host2a</HOST>
<PORT>1630</PORT>
</ADDRESS>
<ADDRESS>
<PROTOCOL>tcp</PROTOCOL>
<HOST>host2b</HOST>
<PORT>1630</PORT>
</ADDRESS>
</ADDRESS_LIST>
<ADDRESS>
<PROTOCOL>tcp</PROTOCOL>
<HOST>host3</HOST>
<PORT>1630</PORT>
</ADDRESS>
<CONNECT_DATA>
<SERVICE_NAME>Sales.us.acme.com</SERVICE_NAME>
</CONNECT_DATA>
</DESCRIPTION>
</acme>
</root>
Given the problem in the parsed form of having two containers with the same name, a rule resolution might consist of the following:
//ADDRESS_LIST/ADDRESS/HOST/text()Effectively, this says: for each address in the address list evaluate /HOST/text() to extract the host name as the address identifier.
After applying the post-parsing rule, the parsed tree structure appears as follows:
acme
DESCRIPTION
SOURCE_ROUTE yes
ADDRESS
PROTOCOL tcp
HOST host1
PORT 1630
ADDRESS_LIST
FAILOVER on
LOAD_BALANCE off
ADDRESS[host2a]
PROTOCOL tcp
HOST host2a
PORT 1630
ADDRESS[host2b]
PROTOCOL tcp
HOST host2b
PORT 1630
ADDRESS
PROTOCOL tcp
HOST host3
PORT 1630
CONNECT_DATA
SERVICE_NAME Sales.us.acme.com
The rule resolves to an identifier appended in square brackets to the container name. The combination (ADDRESS [host2a], for example) enables various operations such as compare, search, change history, and so forth, to distinguish between address containers.
Consider the following three-column database table SERVER_DETAILS:
| SERVER_NAME | ENVIRONMENT | HOSTED_APPLICATIONS |
|---|---|---|
| webserver-100 | QA | 5 |
| webserver-200 | PERFORMANCE | 6 |
| webserver-500 | PRODUCTION | 3 |
The SQL query expressed as part of the custom configuration creation is as follows:
select * from SERVER_DETAILS
This query returns the following raw output:
[row] 11_SERVER_NAME=13_ webserver-100 11_ENVIRONMENT=2_ QA 19_HOSTED_APPLICATIONS=1_5 [row] 11_SERVER_NAME=13_ webserver-200 11_ENVIRONMENT=11_ PERFORMANCE 19_HOSTED_APPLICATIONS=1_6 [row] 11_SERVER_NAME=13_ webserver-500 11_ENVIRONMENT=10_ PRODUCTION 19_HOSTED_APPLICATIONS=1_3
The Configuration Browser Source tab renders the data the same way.
Its parsed form, using the Database Query parser, appears in the user interface in the following tree structure:
row
SERVER_NAME=webserver-100
ENVIRONMENT=QA
HOSTED_APPLICATIONS=5
row
SERVER_NAME=webserver-200
ENVIRONMENT=PERFORMANCE
HOSTED_APPLICATIONS=6
row
SERVER_NAME=webserver-500
ENVIRONMENT=PRODUCTION
HOSTED_APPLICATIONS=3
Notice that the row containers are indistinguishable. Thus, this query result is a candidate for a post-parsing rule. As mentioned, there is a special internal XML format against which to apply a rule's XPath condition and expression. This format treats nodes and attributes as XML elements, and converts attribute values into corresponding element text content. It also adds a root element that doesn't appear in the original file:
<root>
<row>
<SERVER_NAME>webserver-100</SERVER_NAME>
<ENVIRONMENT>QA</ENVIRONMENT>
<HOSTED_APPLICATIONS>5</HOSTED_APPLICATIONS>
</row>
<row>
<SERVER_NAME>webserver-200</SERVER_NAME>
<ENVIRONMENT>PERFORMANCE</ENVIRONMENT>
<HOSTED_APPLICATIONS>6</HOSTED_APPLICATIONS>
</row>
<row>
<SERVER_NAME>webserver-500</SERVER_NAME>
<ENVIRONMENT>PRODUCTION</ENVIRONMENT>
<HOSTED_APPLICATIONS>3</HOSTED_APPLICATIONS>
</row>
</root>
Given the problem in the parsed form of having three containers with the same name, a rule resolution might consist of the following:
/root/row/SERVER_NAMESERVER_NAME/text()Effectively, this says: for each row evaluate SERVER_NAME/text() to produce an identifier that distinguishes one row from another within the tree structure.
After applying the post-parsing rule, the parsed tree structure appears as follows:
row[webserver-100]
SERVER_NAME=webserver-100
ENVIRONMENT=QA
HOSTED_APPLICATIONS=5
row[webserver-200]
SERVER_NAME=webserver-200
ENVIRONMENT=PERFORMANCE
HOSTED_APPLICATIONS=6
row[webserver-500]
SERVER_NAME=webserver-500
ENVIRONMENT=PRODUCTION
HOSTED_APPLICATIONS=3
The rule resolves to an identifier appended in square brackets to the container name. The combination (row[webserver-100], for example) enables various operations such as compare, search, change history, and so forth, to distinguish between row containers.
|
 Copyright © 2011, Oracle and/or its affiliates. All rights reserved. Legal Notices |
|