Page tree
Skip to end of metadata
Go to start of metadata

Product versions:
BusinessObjects Enterprise XI R2
BusinessObjects Enterprise XI 3.1


When considering the Monitoring Probes for a monitoring solution, the question of persistence and reporting comes very often. Where will I store the probes output ? And how will I report off it ? There are lots of options available with all sorts of tools, technology and a wide cost range.
This article details the implementation of a simple solution where the output is persisted on the file system and we use a XML based data provider for Crystal Reports.

The final result

Ultimately, you will be able to run Crystal Reports that display information about the last execution of monitoring probes. It can be a detailed and / or graphical view of one or several probes. Here are examples :

How to do it

  1. persist probes output in output folder
    Create a subfolder "output" in the monitoring folder : <boe_home>/monitoring/output

    Schedule the probes to dump the execution output in a file located in that new output folder. Each probe should have its own output file :
  2. copy xsd schema to reporting folder
    Create a file named proberesult.xsd with the content below and copy it to a new folder <boe_home>/monitoring/reporting :
    <?xml version="1.0" encoding="UTF-8"?>
    <xs:schema xmlns:xs="">
    	<xs:simpleType name="paramValueType">
    		<xs:restriction base="xs:string">
    			<xs:enumeration value="boolean"/>
    			<xs:enumeration value="java.lang.String"/>
    			<xs:enumeration value="int"/>
    	<xs:simpleType name="authenticationType">
    		<xs:restriction base="xs:string">
    			<xs:enumeration value="secEnterprise"/>
    			<xs:enumeration value="secLDAP"/>
    			<xs:enumeration value="secWinAD"/>
    			<xs:enumeration value="secWinNT"/>
    	<xs:simpleType name="classnameType">
    		<xs:restriction base="xs:string">
    			<xs:pattern value="com.businessobjects.monitoring.probes.([a-zA-Z0-9])*"/>
    	<xs:complexType name="paramType">
    		<xs:attribute name="type" type="paramValueType" use="required"/>
    		<xs:attribute name="value" type="xs:string" use="required"/>
    	<xs:complexType name="probeconfigType">
    			<xs:element name="param" type="paramType" minOccurs="0" maxOccurs="4"/>
    			<xs:element name="connector" type="xs:string"/>
    		<xs:attribute name="user" type="xs:string" use="required"/>
    		<xs:attribute name="system" type="xs:string" use="required"/>
    		<xs:attribute name="authtype" type="authenticationType" use="required"/>
    		<xs:attribute name="classname" type="classnameType" use="required"/>
    	<xs:complexType name="resultType">
    		<xs:attribute name="success" type="xs:boolean" use="required"/>
    		<xs:attribute name="startdatetime" type="xs:string" use="required"/>
    		<xs:attribute name="error" type="xs:string" use="required"/>
    		<xs:attribute name="duration" type="xs:integer" use="required"/>
    	<xs:complexType name="probeType">
    			<xs:element name="probeconfig" type="probeconfigType"/>
    			<xs:element name="result" type="resultType"/>
    		<xs:attribute name="name" type="xs:string" use="required"/>
    		<xs:attribute name="description" type="xs:string" use="required"/>
    	<xs:element name="probe" type="probeType"/>
  3. create a new XML connection in Crystal Reports
  4. create one report per probe
  5. create one global report with sub reports

Pros and Cons

The main advantage of this solution is its ease (hence, cost) of implementation. You don't need any database and can fully leverage the BOE platform and / or basic operating system tools to schedule the probes and run the reports.
The main disadvantage of using the BOE platform is that you rely on the same infrastructure that you are monitoring (when it is down, your monitoring solution is down too...).

  • No labels