Results Generation by the Jython Script

Each Jython script runs on a specific Trigger CI, and ends with results that are returned by the return value of the DiscoveryMain function.

The script result is actually a group of CIs and links that are to be inserted or updated in the CMDB. The script returns this group of CIs and links in the format of ObjectStateHolderVector.

The ObjectStateHolder class is a way to represent an object or link defined in the CMDB. The ObjectStateHolder object contains the CIT name and a list of attributes and their values. The ObjectStateHolderVector is a vector of ObjectStateHolder instances.

The ObjectStateHolder Syntax

This section explains how to build the DFM results into a UCMDB model.

Example of Setting Attributes on the CIs:

The ObjectStateHolder class describes the DFM result graph. Each CI and link (relationship) is placed inside an instance of the ObjectStateHolder class as in the following Jython code sample:

# siebel application server 1 appServerOSH = ObjectStateHolder('siebelappserver' ) 2 appServerOSH.setStringAttribute('data_name', sblsvrName) 3 appServerOSH.setStringAttribute ('application_ip', ip) 4 appServerOSH.setContainer(appServerHostOSH)
  • Line 1 creates a CI of type siebelappserver.

  • Line 2 creates an attribute called data_name with a value of sblsvrName which is a Jython variable set with the value discovered for the server name.

  • Line 3 sets a non-key attribute that is updated in the CMDB.

  • Line 4 is the building of containment (the result is a graph). It specifies that this application server is contained inside a host (another ObjectStateHolder class in the scope).

Note: Each CI being reported by the Jython script must include values for all the key attributes of the CI's CI Type.

Example of Relationships (Links):

The following link example explains how the graph is represented:

1 linkOSH = ObjectStateHolder('route') 2 linkOSH.setAttribute('link_end1', gatewayOSH) 3 linkOSH.setAttribute('link_end2', appServerOSH)
  • Line 1 creates the link (that is also of the ObjectStateHolder class. The only difference is that route is a link CI Type).

  • Lines 2 and 3 specify the nodes at the end of each link. This is done using the end1 and end2 attributes of the link which must be specified (because they are the minimal key attributes of each link). The attribute values are ObjectStateHolder instances. For details on End 1 and End 2, see Link.

Caution: A link is directional. You should verify that End 1 and End 2 nodes correspond to valid CITs at each end. If the nodes are not valid, the result object fails validation and is not reported correctly. For details, see CI Type Relationships.

Example of Vector (Gathering CIs):

After creating objects with attributes, and links with objects at their ends, you must now group them together. You do this by adding them to an ObjectStateHolderVector instance, as follows:

oshvMyResult = ObjectStateHolderVector()

For details on reporting this composite result to the Framework so that it can be sent to the CMDB server, see the sendObjects method.

Once the result graph is assembled in an ObjectStateHolderVector instance, it must be returned to the DFM Framework to be inserted into the CMDB. This is done by returning the ObjectStateHolderVector instance as the result of the DiscoveryMain() function.

Note: For details on creating OSH for common CITs, see

Sending Large Amounts of Data

Sending large amounts of data (usually more than 20 KB) is difficult to process in UCMDB. Data of this size should be split into smaller chunks before sending to UCMDB. In order for all the chunks to be correctly inserted to UCMDB, each chunk needs to contain required identification information for the CIs in the chunk. This is a common scenario when developing Jython integrations. The sendObjects method is used to send the results in chunks. If the Jython script sends a large number of results (the default value is 20,000, but this value can be configured in the File using the appilog.agent.local.maxTaskResultSize key) it should chunk the results according to their topology. This chunking should be performed taking into account identification rules so that the results are entered correctly in UCMDB. If the Jython script does not chunk the results, the probe attempts to chunk them; however, this can lead to poor performance for a large result set.

Note Chunking should be used for Jython integration adapters and not for regular discovery jobs. This is because discovery jobs usually discover information regarding a specific trigger and do not send large amounts of information. With Jython integrations, large amounts of data are discovered on the single trigger of the integration.

It is also possible to use chunking for a small number of results. In such a case, there is a relationship between CIs in different chunks and the developer of the Jython script has two options:

  • Send the entire CI and all of its identification information again in every chunk that contains a link to it.
  • Use the UCMDB ID of the CI. To do this, the Jython script has to wait for each chunk to be processed in the UCMDB server in order to get the UCMDB IDs. To enable this mode (called synchronous result sending), add the SendJythonResultsSynchronously tag to the adapter. This tag ensures that when you finish sending the chunk, the UCMDB IDs of the CIs in the chunk have already been received by the probe. The adapter developer can use the UCMDB IDs for generating the next chunk. To use the UCMDB IDs, use the framework API getIdMapping.

Example of Using getIdMapping

In the first chunk you send nodes. In the second chunk you send processes. The root container of the process is a node. Instead of sending the entire objectStateHolder of the node in the process root_container attribute, you can get the UCMDB ID of the node using the getIdMapping API and use only the node ID in the process root_container attribute to make the chunk smaller.

Parent topic: Create Jython Code