Issue
When starting a discovery of a service map, discovery stops immediately and the java.lang.NullPointerException error can be seen in the log.
Troubleshooting
The NullPointerException error is thrown during recomputation of the business service. The most common reason for this error during recomputation is an existing duplicate dependencies in cmdb_rel_ci table. Having an NPE (NullPointerException) in such cases is not desirable; however, the recomputation logic behavior was completely updated in Kingston and such errors are not likely to happen in Kingston and newer releases.
To find the root cause for the issue you need to (short term):
- Find the CI that the recomputation was processing when the error happened
- Look for duplicate relationships for the device and remove them
For a long-term solution, you need to determine what caused the duplicate relationships.
Finding the CI
To find the CI, navigate to System Definition > Scripts - Background and run the following script. The output will be logged to the screen.
Note – Replace empty in gr.get('empty') with the sys_id for the business service.
gs.setProperty("glide.cmdb.logger.source.service_mapping.coordinator","info,warn,error,*");
gs.setProperty("glide.cmdb.logger.source.service_mapping.template", "info,warn,error,*");
gs.setProperty("glide.cmdb.logger.source.service_mapping.matching", "info,warn,error,*");
gs.setProperty('glide.transaction.max_logs', 200*10000);
var gr = new GlideRecord('cmdb_ci_service_discovered');
gr.get('empty'); // <This line must be updated with service sys_id
var layerId= gr.layer;
var layerGr= new GlideRecord('svc_layer');
layerGr.get(layerId);
var env= sn_svcmod.ServiceContainerFactory.loadEnvironment(layerGr.environment);
var allLayers= env.layers();
for (var i= 0 ; i< allLayers.length; i++) {
var layer = allLayers[i];
layer.markRecomputationNeeded();
}
SNC.ServiceMappingFactory.recomputeLayer(layerGr);
gs.setProperty('glide.transaction.max_logs', 200*1000);
gs.setProperty("glide.cmdb.logger.source.service_mapping.coordinator","info,warn,error");
gs.setProperty("glide.cmdb.logger.source.service_mapping.template", "info,warn,error");
gs.setProperty("glide.cmdb.logger.source.service_mapping.matching", "info,warn,error");
The CI with the duplicate relationship should be the last CI seen in the output before the NPE error. In the following example output snippet, the CI would be 567bcdb49179390020e5db5405e32514.
service_mapping.template :>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>## UPDATE: convertRecordIntoElements: (CI:cmdb_ci_win_server:9667 # 567bcdb49179390020e5db5405e32514) => (cmdb_ci_win_server:9668)
service_mapping.coordinator : Attempting to process layer Template on environment bb5e3069dbbb4304fc1cf9961d9619bb resulted in an exception:: no thrown error
service_mapping.coordinator : >> java.lang.NullPointerException: no thrown error
service_mapping.coordinator : : no thrown error
In this example, it was found that the CI had multiple "hosted on:hosts" relationship records to the same CI. For different CI records, there will be different relationship types that might cause the error. Once the CI is found, relationships in the cmdb_rel_ci table can be filtered for "parent = CI or child = CI", CI found in script output, to look for duplicate relationships.
Identification rules
Very often such duplicate relationship/CI(s) are created due to identification rules that should be dependent but are set to independent. To look for such identification rules, navigate to System Definition > Scripts - Background and run the following script to find identifiers that are set to independent and should not be.
var gr = new GlideRecord('cmdb_identifier');
gr.addQuery('independent', 1);
gr.query();
while (gr.next()) {
if (GlideDBObjectManager.get().isInstanceOf(gr.applies_to, 'cmdb_ci_appl') ||
GlideDBObjectManager.get().isInstanceOf(gr.applies_to, 'cmdb_ci_lb_service')) {
gs.print("Application " + gr.applies_to + " has an independent identifier rule");
}
}
Once these steps are followed (duplicate relationships are found and removed), the business service map discovery can be run again without the NPE error.
Background scripts, to search for duplicate application and cluster relationships
// find an application that runs on more than one host (wrong identifier).
var gr = new GlideAggregate('cmdb_rel_ci');
gr.addQuery('type', '60bc4e22c0a8010e01f074cbe6bd73c3'); // runs on relation
gr.addQuery('child.sys_class_name','INSTANCEOF','cmdb_ci_server' );
gr.addQuery('parent.sys_class_name','INSTANCEOF','cmdb_ci_appl' );
gr.addAggregate('COUNT'); gr.groupBy('parent'); gr.query();
gs.print('*** Affected Applicataions: ***');
while (gr.next()) {
if (gr.getAggregate('COUNT') > 1) {
gs.print(gr.parent + ":" + gr.parent.name);
}
}
// find servers that are hosted on more then one cluster node
var gr = new GlideAggregate('cmdb_rel_ci');
gr.addQuery('type', '5f985e0ec0a8010e00a9714f2a172815');
gr.addQuery('child.sys_class_name', 'cmdb_ci_win_server');
gr.addQuery('parent.sys_class_name', 'cmdb_ci_win_cluster_node');
gr.addAggregate('COUNT');
gr.groupBy('child');
gr.query();
gs.print('*** Affected Servers: ***');
while (gr.next()) {
if (gr.getAggregate('COUNT') > 1) {
gs.print(gr.child + ":" + gr.child.name);
}
}