Data Flow Management Concepts

The Data Flow Probe is the main component responsible for requesting tasks from the server, scheduling and executing discovery and integration tasks, and sending the results back to the UCMDB Server. You define a range of network addresses for a specific, installed Data Flow Probe. Each Data Flow Probe is identified by its name, chosen during the Data Flow Probe installation process.

A probe cluster is a logical container for a number of Data Flow Probes. You define a network range for a cluster. The cluster is responsible for calculating how to distribute the overall set of IP address ranges between the Probes in the cluster evenly. The split of the network range is done purely based on the potential number of IP addresses available in the IP address ranges, not on the actual number of active IP addresses available in the ranges.

If your remote managed data repositories are accessible from the UCMDB server machine, you can use the UCMDB Integration Service (installed on the UCMDB Server) instead of a Data Flow Probe, to run non-Jython-based integrations.

This enables running non-Jython-based integrations without the need for using Data Flow Probe resources, leaving the Data Flow Probe resources available for other discovery tasks.

A passive discovery probe is an  Real User Monitor (RUM) probe that is configured to integrate with a Data Flow Probe to provide passive, real-time discovery and monitoring of traffic in a given environment. This is known as Just-in-Time discovery.

Discovery of the IT infrastructure components uses protocols such as SNMP, WMI, JMX, Telnet, and so on for communication. For details about each protocol, see the UCMDB Discovery and Integrations Content Guide - Supported Content.

To collect inventory information, you can deploy Universal Discovery agents (UD agents) on client or server machines. The UD agent provides a secured communication channel between the Data Flow Probe and the nodes being discovered. After setting up the secure communication channel, Universal Discovery deploys and activates scanners onto the nodes being discovered. The Scanners scan the nodes for inventory information and store the scanned results in scan files which are downloaded to the Data Flow Probe through the secured communication channel established with the UD agent.

When the UD agent is installed, collection of software utilization information is enabled. The UD agent also enables you to benefit from the Call Home feature. Call Home is useful in the case where a node was unavailable for scanning for a long period. It enables the UD agent to notify the Data Flow Probe that the node is currently available for scanning.

Although agentless discovery does not require the installation of dedicated agents on the servers that are to be discovered, it does depend on native OS or standard agents that are already installed such as SNMP, WMI, TELNET, SSH, NETBIOS, and others. Other discovery capabilities are based on application-specific protocols such as SQL, JMX, SAP, Siebel, and so on. For details on supported protocols, see the UCMDB Discovery and Integrations Content Guide - Supported Content.

Adapters on which discovery jobs and integrations are based.

• Jython Adapter. An adapter based on a set of Jython scripts that are executed sequentially.
• Java Adapter. An adapter based on Java code that implements the various DFM interfaces and is wrapped in a JAR file.
• Generic DB Adapter. An adapter that uses SQL queries and maps database tables to CIs and relationships by using an ORM file.
• Generic Push Adapter. An adapter that uses a mapping file and Jython scripts to push data to an external data repository.

The adapters themselves do not contain information about the target to which they are to connect and from which they are to retrieve information. For data flow to be configured correctly, adapters require further context information, which can include an IP address, port information, credentials, and so on.

For discovery adapters (adapters used for performing discovery), the additional information is brought from the Trigger CIs associated with the discovery jobs; for integration adapters, the information is manually fed when creating the integration or taken from the selected Trigger CI.

For details on making adapter changes, see Adapter Management Window. For details on creating adapters, see Adapter Development and Writing.

The module is a grouping of discovery jobs that logically belong together, can be operated and managed together, and so on. This helps to reduce clutter in the main view when many jobs need to be written, and can also offer better manageability.

When creating a job, you should add it to a module or create a new module. If you are creating several jobs, the best practice is to split them into logical groups and assign them to modules accordingly.

Discovery Modules support a hierarchy of folders, to facilitate easy finding of the relevant discovery capability.

A Management Zone is a region in the network defined by a collection of IP ranges. A region of an organization’s infrastructure should be defined as a Management Zone when you want to discover all the managed objects of the region using the same scheduling policy and parameters.

You can set up multiple Management Zones to run different instances of a discovery activity in different data centers in your enterprise.

For information, see Zone-based Discovery.

The latest discovery and integration content for UCMDB are installed in a Content Pack during the installation of UCMDB. Updates to the Content Pack are available for download via the ITOM Marketplace. For details on downloading and installing Content Pack updates, see the Universal Discovery Community.

Integration points are entities used to set up UCMDB integrations. Each integration point is created with a selected integration adapter and the additional configuration information required to set up the integration. For details on creating integration points, see Integration Studio.

A job enables reuse of a discovery adapter for multiple discovery process flows. Jobs enable scheduling the same adapter differently over different sets of triggered CIs and also supplying different parameters to each set. You can launch a discovery by activating the relevant set of discovery jobs that must be run. Relevant trigger CIs are automatically added to the activated discovery jobs based on their trigger queries.

You use discovery activities within Management Zones to discover infrastructure (IPs, nodes), basic software (shallow running software including application servers, databases, and web servers), deep database configuration, and inventory ( for example, CPUs, installed and virtualized software, logical volumes), among other information.

Each adapter is assigned an input query that is used as follows:

• The input query defines a minimal set of requirements for every Trigger CI included in a discovery job or integration point that triggers this adapter. (This is true even when no trigger query is associated with the job.)

  For example, an input query can query for IPs related to nodes with an SNMP agent installed and discovered on them, that is, only IPs with installed SNMP agents can trigger this adapter. This prevents the case where a user could manually create a Trigger CI that adds all IPs as triggers to an adapter.

• An input query defines how to retrieve data information from the CMDB . Destination data information, even if it is not included in a Trigger CI, can be retrieved by the input query. The input query defines how to retrieve the information.

  For example, you can define a relationship between a Trigger CI (a node with the node name of SOURCE) and the target CI and then can refer to the target CI according to this node name.

For details on using input queries when writing adapters, see Step 1: Create an Adapter.

A trigger CI is a CI in the CMDB that activates a discovery job. Every time a job is activated, the job may discover additional CIs, which in turn are used as triggers for other jobs. This process continues until the entire IT infrastructure is discovered and mapped.

A trigger query associated with a job is a subset of the input query, and defines which specific CIs should automatically trigger a job. That is, if an input query queries for IPs running SNMP, a trigger query queries for IPs running SNMP in the range 195.0.0.0-195.0.0.10.