Develop > Developer Reference > Creating Discovery and Integration Adapters > Mapping Consumer-Provider Dependencies > Search Connection Strings > Search connection strings from configuration documents

Search connection strings from configuration documents

The following example demonstrates the content of a configuration signature file used to search connection strings from configuration documents.

<TextFile name="${filename}*.loc">
    <FileLocations>
        <Path>${pluginPath}</Path>
        <Path os="win" includeSub="true">C:\Windows\System*</Path>
    </FileLocations>
	...
</TextFile>
<XmlFile name=">plugin.xml" collect="true">
    <FileContent>${fileContent}</FileContent>
	...
</XmlFile>

To search connection strings from configuration documents, configuration signature uses several elements to define rules:

  • <TextFile>: get strings from a generic text configuration document.
  • <PropertyFile>: get strings from a property file by using specified property key.
  • <XmlFile>: get strings from an XML-format configuration document.
  • <CustomFile>: get strings from a file by using a custom script.

Each of these “File” elements requires a file name, which can use variables. When the collect attribute is set to true (which is by default false), the file will be reported to UCMDB as a ConfigurationDocument CI with file name, full path, and file content. It is useful for troubleshooting. The first child element of a “File” element should be either <FileLocations> or <FileContent>.

Closed<FileLocations>

The <FileLocations> element can contain one or more file paths, which indicate the full paths to search the specified configuration documents. The <FileLocations> element supports the use of wildcard variables with multiple values for file names or file paths, and the processor will try to find all resolved paths and file names in the destination file system.

The <Path> element can use the os attribute as the <CommandLine> element to filter result by operation system. Another optional attribute of the <Path> element is includeSub. When this attribute is set to true, the processor will search the specified file in the specified path and all subdirectories.

In the above example, if the filename and pluginPath variables are not in the same variable group and both variables have two saved values, and the destination operation system is Windows. The processor will try to search following configuration documents:

<pluginPath1>/<filename1>*.loc
<pluginPath2>/<filename2>*.loc
<pluginPath1>/<filename2>*.loc
<pluginPath2>/<filename1>*.loc
C:\Windows\System*\<filename1>*.loc
C:\Windows\System*\<filename2>*.loc

If the two variables are grouped and the destination operation system is not Windows, only the first two paths will be searched.

Closed<FileContent>

Unlike the <FileLocations> element, the <FileContent> element does not read the configuration document from file system. Instead, it directly specifies the content to be search for by using expressions. In this case, wildcard is not allowed in the file name attribute. Usually, the <FileContent> element is used when the result of the shell command defined in an <Execute> element is a property or XML file.

Closed<TextFile>

The <TextFile> element is a basic “File” element. You can use this element to parse any type of configuration document. This element only supports the <Regex> sub element to get connection strings by using a regular expression, as shown in the following example:

<TextFile name="text file">
    <FileLocations> or <FileContent>
    <Regex expr='(.*)\plugin-cfg.xml'>
        <Variable name="pluginHome" group="1"/>
    </Regex>
</TextFile>
Closed<PropertyFile>

The <PropertyFile> element is used to parse property files, which save configuration in the "<key>=<value>" format. This element supports three types of sub elements:

  • <Property>: get strings from a specified key, and then use the embedded Regex element to get values.
  • <PropertyVariable>: directly assign the value for specified key to a variable.
  • <Regex>: regular expressions are also supported for a property file.

The following example demonstrates the content of the <PropertyFile> element:

<PropertyFile name="file.properties">
    <FileLocations> or <FileContent>
    <Property name="url" key="remoteUrl">
        <Regex expr="(https?)//(.*)">
            <Variable name="protocol" group="1"/>
            <Variable name="hostname" group="2"/>
        </Regex>
    </Property>
    <PropertyVariable name="port" key="serverPort" defaultValue="80"/>
    <Regex expr="…">
       ...
    </Regex>
</PropertyFile>
Closed<XmlFile>

The <XmlFile> element is used to parse an XML-format configuration documents. This element supports XPath 2.0 expressions and regular expressions by using the following sub elements respectively:

  • <XPath>: get XML element by XPath, and then use relative XPath and regular expressions to get values.
  • <XPathVariable>: directly assign the value of an XPath expression to a variable.

The following example demonstrates the content of the <XmlFile> element:

<XmlFile name="config.xml">
    <FileLocations> or <FileContent>
    <Xpath xpath="//datasources/datasource/connectionUrl">
        <Variable name="datasourceName" relativePath="../@name"
        <Regex expr='jdbc:oracle:(thin|oci)://([\w.]*):?(\d*)>
            <Variable name="protocol" group="1"/>
            <Variable name="hostname" group="2"/>
            <Variable name="port" group="3" defaultValue="1521"/>
        </Regex>
    </XPath>
</XmlFile>
Closed<CustomFile>

The <CustomFile> element is used to parse those non-standard configuration documents (such as httpd.conf of Apache) by using Jython script.

The following example demonstrates the content of the <CustomFile> element:

<CustomFile name="httpd.conf" plugin="config_parser_apache">
    <FileLocations>
        <Path>${home}/conf/</Path>
        <Path>${home}/httpd/conf/</Path>
    </FileLocations>
</CustomFile>

The plugin attribute specifies the Jython script name. The file extension .py can be omitted. The script should be deployed as a normal job scripts under the discoveryScripts folder of a package. The script should define a method as follows:

def parseConfigFile(shell, configfilePath, configFileName, fileContent, variableResolver)

ClosedParameters

  • shell: the shell utility instance, which can execute commands by remote shell. It has the following methods:

    • execCmd(cmdLine): execute command line by shell, and returns its result.
    • getOsType(): get the operation system type.
    • isWinOs(): check if the destination operation system is Windows.
    • getOsVersion(): get the version of the operation system.
    • getOsLanguage(): get the language of the operation system.
    • getCommandSeparator(): get the command line separator of the operation system.

    For more information, see the content of shellUtils.py, which is available under UCMDB UI > Data Flow Management > Adapter Management > Packages > AutoDiscoveryContent > Scripts.

  • configFilePath: the full path of the configuration document to parse.
  • configFileName: the file name of the configuration document.
  • fileContent: the full content of the configuration file as string.

  • variableResolver: the variable utility instance, which is used to assign value to variables and get values from existing variables. It has the following methods:

    • add(name,value): add the value to the variable with the specified name.
    • addGroup(names, values): add values to the variables with the specified names as a variable group. Names and values should be iterable and should have the same length.
    • get(name): get the values of the variable with the given name. Always returns the result as a list. If the variable is not defined, the method will return an empty list.

Send Help Center feedback