DCO uses the standard web services to query Data Center Expert for device and sensor related data.
To get device information, this information from the DCE web interface /integration/services/ISXCentralDeviceService_v2_0?wsdl is used:
The supplemental string is mandatory to understand the nature of the device.
For example, for power related devices, phase and bank information is present in the supplemental string used in DCO to create an object of the device.
Example of PDU with 1 phase and 2 banks:
A number of sensors are also used from the DCE web service interface /integration/services/ISXCentralSensorService_v2_0?wsdl
To create an object to be used for the sensors, use:
Index is being used to identify which module and phase are reporting data.
That means index must be unique across sensorType on a given device
It is NOT allowed to have e.g. 2 sensors of the same sensorType reporting same index. For example a single phase rack PDU with 2 banks and reporting phase information as well. Same sensorType having same index:
This is NOT allowed
To get the above example right, the phase output power should be reported as OUTPUT_POWER_TOTAL_WATTS (which does not use index).
Single phase devices with no banks should only use the OUTPUT_POWER_TOTAL_WATTS sensorType.
From the ISXCSensorType, a subset of the sensors are mapped in DCO for temperature, humidity, and power.
MODULE_OUTPUT_POWER or MODULE_BREAKER_POWER
The SensorType is ignored when using sensor mapping functionality at PDU level.
Power sensors used for Modular PDU / Branch Circuit Monitoring
For a modular PDU/Branch Circuit Monitoring, the MODULE_OUTPUT_POWER or MODULE_BREAKER_POWER are the sensors used to get power data from the device.
An example of a modular PDU with 3 phases and 24 breaker modules:
At device level, the "supplemental" string is used to specify number of phases and breaker modules.
The data collected from DCE via the power sensors is Peak and Average data. Peak and Average power data is queried for an interval of one day, 1 time/day. Additionally, peak power data is queried every 5 minutes since last time queried.
We store the data and calculate Peak and Average values based on a setting in the DCO server (10, 20, 30 days).
The expected values used to specify and map the device in DCO:
|ISXCDevice - Supplemental||ISXCSensor|
|1||>1||1 digit = Bank number||OUTPUT_POWER_WATTS||rack PDU with banks|
|3||1||1 digit = Phase number||OUTPUT_POWER_WATTS||UPS or (RM)PDU|
|3||>1||2 digit = Module, Phase||MODULE_OUTPUT_POWER||Modular PDU|
|3||-||1 digit = Phase number||OUTPUT_POWER_WATTS|
Supplemental is mandatory and must include phase information
PhaseCount references InputPhaseCount and OutputPhaseCount which is expected to be the same number.
DCE exposes information through various web services.
For device information, DCO uses:
For sensor information and data, DCO uses:
Verifying DDFs with Soap-UI
The walkthrough below is done with SoapUI 5.4.0. You can download the latest version here: https://www.soapui.org/
When setting up a new project, chose the SOAP project type.
The initial WSDL link should be
http://X.X.X.X/integration/services/ISXCentralDeviceService_v2_0?wsdl for the device endpoint.
http://X.X.X.X/integration/services/ISXCentralSensorService_v2_0?wsdl. for the sensor endpoint.
Where X.X.X.X is ip address for the DCE server.
When prompted for the username and password, provide those used for logging into the DCE server.
Running a request against the DCE server
When running a request against the endpoint, first choose the endpoint in the list, and fold out so you can see the sample request.
Before running the request, you need to setup authentication:
- Chose 'Basic'
- Enter in the username and password for the DCE server
Then press play to run the request.
Dependent on the request it might be necessary to fill in a number of parameters.
When you have identified the correct device use the sensor end point to ensure that sensors with the correct type are available.
Running requests to verify sensors with the correct type are available
Getting the sensors for a specific device.
Several of the end point are of interest, this is just an example on one why to do the verification.
Given an ID for a device, all the sensors for the device can be gathered with the getSensorsForDevice request.
Fill in the ID for the device
Check that sensors with the types mentioned in the first part of this document are present. One example for the OUTPUT_POWER_WATTS sensor type is shown below.