14.2. Getting Started

14.2.1. Understanding objects hierarchy in SysOrb

There are a lot of objects in SysOrb, below gives an overview of how it is structured and explain which object can currently be accessed via the Web API.

Figure 14-1.

Figure 1: SysOrb Objects Hierarchy

14.2.1.1. Domain

Domains are a logical way of distinguishing between separate parts of the network.

Properties:

Table 14-1.

Name Type Editable Default Description
id string     Object id
version string     Object version
name string +   Object name
siblingName string     Internal name
treeLabel string   "name" Composed using "label" property and "name".
longLabel string   "name" Composed using "label" property and "name".
stationLocale uint   Null Id of satellite assigned to this domain.
dependsOn object set     The list of objects from which this domain depends
alertGroup object + Null Alert Group assigned to this Domain
infoUrl string + Null Link to the external resource for this Domain
comment string + Null Any additional comment
label string +   Description of Domain
maxTotalNodes uint + Null The maximum number of nodes that are allowed in this domain including subdomains.
maxNetCheckNodes uint + Null The maximum number of nodes that can have NetCheck configured on them, excluding nodes that may use NetChecks as add-on to AgentChecks or SnmpChecks.
maxSnmpCheck10Nodes uint + Null The maximum number of nodes that can have between 1 and 10 SnmpChecks configured, excluding nodes that may use SnmpChecks as add-on to AgentChecks. (Such nodes may also have an unlimited number of NetChecks.)
maxSnmpCheckUnlimitedNodes uint + Null The maximum number of nodes that can have 11 or more SnmpChecks configured, excluding nodes that may use SnmpChecks as add-on to AgentChecks. (Such nodes may also have an unlimited number of NetChecks.)
maxAgentCheckNodes uint + Null The maximum number of nodes that can have AgentChecks configured. Whenever a key has been negotiated for a Node it is considered a AgentCheck node. A key is automatically negotiated for a Node the first time a SysOrb Agent checks in to the SysOrb server. In order to free the key again, go to the configuration page of the node and click the 'release key' button. If no such button is visible then the node has no key assigned. It is not possible to perform any AgentChecks without a key assigned to the node. (AgentCheck'ed nodes may also have an unlimited number of SnmpChecks and NetChecks.)
maxLeechingStations uint + Null The maxinum number of satellites allowed in this domain.
maxAgentLimitNodes uint + Null The maximum number of nodes that can have an agent with a limited number of AgentChecks configured. Whenever a key has been negotiated for a Node it is considered a agent checked node. The number of checks active on the node, determines whether the node counts as a regular AgentChecked node or as an AgentLimited node. A key is automatically negotiated for a Node the first time a SysOrb Agent checks in to the SysOrb server. In order to free the key again, go to the configuration page of the node and click the 'release key' button. If no such button is visible then the node has no key assigned. It is not possible to perform any AgentChecks without a key assigned to the node. (AgentLimited nodes may also have an unlimited number of SnmpChecks and NetChecks.)
maxEsxiNodes uint + Null The maximum number of Esxi nodes.
countNetChecks uint     The current number of configured NetChecks.
countAgentCheckNodes uint     The current number of nodes with AgentChecks configured
countAgentChecks uint     The current number of configured AgentChecks
countSnmpChecks uint     The current number of configured SnmpChecks
countNodes uint     The current number of Nodes in this domain including subdomains.
countNetCheckNodes uint     The current number of Nodes with configured NetChecks.
countSnmpCheck10Nodes uint     The current number of Nodes with configured number of SnmpChecks less than 10.
countLeechingStations uint     The current number of configured satellites.
countAgentLimitNodes uint     The current number of AgentLimitNodes
countEsxiNodes uint     The current number of Nodes with configured EsxiChecks.
countEsxiChecks uint     The current number of configured EsxiChecks.

14.2.1.2. Node

Node represents a single machine/host/device in the network.

Properties

Table 14-2.

Name Type Editable Default Description
id string     Object id
version string     Object version
parentId string     Object parent
name string +   Object name
siblingName string     Internal name
treeLabel string   "name" Full name: "label (name)"
longLabel string   "name" Full name: "label (name)"
stationLocale uint   Null Id of satellite assigned to this node.
dependsOn object set     The list of objects from which this node depends
checkinFrequency uint + Null In case of Agent installed on the Node determine the frequency Agent will check in to the server.
alertGroup object + Null Alert Group assigned to this Domain
checkinScore int + -5 If an agent has been configure on this node then as long as it is checking in on time the score of the node will be decreased by this amount every five seconds. Per default this is set to -5 which means that as long as the node checks in it will decrease the score by 5 every five seconds.
missedCheckinScore int + 10 f an agent has been configure on this node then as long as it is not checking in the score of the node will be increased by this amount every five seconds. Per default this is set to 10 which means that as long as the node does not check in it will increase the score by 10 every five seconds.
warn int + 200 If the score associated with the node exceeds the number specified here, a warning will be sent to the AlertGroup specified for the node. The score of the node can be in- and decreased by the checkin/no-checking settings for the node. Each check of this node also have a AlertGroup setting, and its own score and scorekeeper parameters. If a check is in a warn or alert state, this check will be included in the alert message.
warnCeiling int + 300 The score associated with the node or scores associated with checks on this node cannot exceed the number specified here by a warning score increment but only by an alert score increment (as specified in the misc. check configurations). The score of the node can be in- and decreased by the checkin/no-checking settings for the node or by the scorekeeper parameters for each check.
alert int + 1000 If the score associated with the node exceeds the number specified here, an alert will be sent to the AlertGroup specified for the node. The score of the node can be in- and decreased by the checkin/no-checking settings for the node. Each check of this node also have a AlertGroup setting, and its own score and scorekeeper parameters. If a check is in a alert state, this check will be included in the alert message.
alertCeiling int + 1100 The score associated with the node or scores associated with checks on this node cannot exceed the number specified here. The score of the node can be in- and decreased by the checkin/no-checking settings for the node or by the scorekeeper parameters for each check.
snmpCommunity string + public SNMP Community for device. Default value is "public".
smnpVersion enum (SnmpVersion) + Autodetect Version of SNMP protocol to communicate with device
snmpPort uint + 161 Port SysOrb should use to communicate with device
snmpScanInProgress bool   false The mark that snmp scan on this node is in progress
snmpScanned bool   false 'True' means that snmp scan on this node was finished
nodeClasses object set     List of NodeClasses of this node
resetScore     Null This property used to reset score on the node. Doesn't supported by current version of API
resetAllScores     Null This property used to reset all score on the node. Doesn't supported by current version of API
esxiEndPoint string + sdk EndPoint string to connect to the ESXi server.
esxiUser string +   Username to access the ESXi server
esxiPassword string +   User password to access the ESXI server
esxiPort uint + 443 Port SysOrb should use to communicate with ESXi server
alertStrategy enum (AlertStrategy) + Immediate Scorekeeper strategy will keep a score for the node, that is always larger that 0 and is in-/decreased by the state of the monitored checks/node. Only if the score reaches some configurable threshold an alert will be sent. Immediate strategy will send a alert immediately when a monitored check/node is in a bad state. ScoreKeeper is best used for checks that should have some kind of fuzzy thresholds, like ping check where a couple of failed pings is usually not of any concern. Immediate is used for something like LogChecks where a log file in a bad state should be alerted immediately.
infoUrl string + Null Link to the external resource for this Node
comment string + Null Any additional comment
acknowledgeAlerts bool   false If this option is selected, each alert have to be acknowledged by a SysOrb user before the associated check/node is considered in a good state again. This is useful for ensuring that all alerts is handled by a user. It is especially useful for LogChecks where a bad log entry line should always signal a bad log, ie. a good log entry line read sometime after the bad one should not signal that the LogCheck is in a good state again.
lastAcknowledge timestamp   Null The time this node was acknowledged.
label string +   Extra description for this Node
countNetChecks uint   0 The number of active NetChecks
countAgentChecks uint   0 The number of active AgentChecks
countSnmpChecks uint   0 The number of active SnmpChecks
countEsxiChecks uint   0 The number of active EsxiChecks

14.2.1.3. CheckGroup

CheckGroups are objects that cannot be created or modified by the user, and used to organize checks into hierarchy.

Each node has 4 predefined CheckGroups one for each check type:

  • NetCheckGroup (id is 1.XXX.0)

  • AgentCheckGroup (1.XXX.1)

  • SnmpCheckGroup (1.XXX.2)

  • EsxiCheckGroup (1.XXX.3)

14.2.1.4. Check

There are three different types of checks in SysOrb with own set of properties:

  • Continuous - is the checks that have numeric data results such as response time, disk free space, CPU usage, etc.

  • Enumeration - such checks has a results in a number of cases, such as process (present, absent), RAID (OK, degraded, failed) etc.

  • Incident - these checks have a text line as a result (LogChecks).

Properties below are common for all checks in SysOrb:

Table 14-3.

Name Type Editable Default Description
id string     Object id
version string     Object version
parentId string     Object parent
name string +   Object name
siblingName string     Internal name
treeLabel string   "name" Full name: "label (name)"
longLabel string   "name" Full name: "label (name)"
stationLocale uint   Null The Grid Station that should perform the check. Default value uses the setting from the node containing this check.
inherits object   Null The id of the check configured in the NodeClass this check was inherited from.
hasInherits bool   false Shows if the check has inherited properties
dependsOn object set     The list of objects from which this check depends
anyOverriden bool   false Shows if the check has overriden properties
isContinuous bool   true 'True' if check is of type Continuous
resetScore       Uset to reset score on the check
infoUrl string + Null Link to the external resource for this Check
comment string + Null Any additional comment
alertGroup object + 0.2 Alert Group assigned to this Check
alertStrategy enum (AlertStrategy) + ScoreKeeper Scorekeeper strategy will keep a score for the node, that is always larger that 0 and is in-/decreased by the state of the monitored checks/node. Only if the score reaches some configurable threshold an alert will be sent. Immediate strategy will send a alert immediately when a monitored check/node is in a bad state. ScoreKeeper is best used for checks that should have some kind of fuzzy thresholds, like ping check where a couple of failed pings is usually not of any concern. Immediate is used for something like LogChecks where a log file in a bad state should be alerted immediately.
acknowledgeAlerts bool + false If this option is selected, each alert have to be acknowledged by a SysOrb user before the associated check/node is considered in a good state again. This is useful for ensuring that all alerts is handled by a user. It is especially useful for LogChecks where a bad log entry line should always signal a bad log, ie. a good log entry line read sometime after the bad one should not signal that the LogCheck is in a good state again.
lastAcknowledge timestamp   Null The time this check was acknowledged.
goodScore int + -5 The amount that the score associated with the node should be decreased when this check is in a good state. The default of -5 will decrease the score by 5. The Node configuration page is used for specifying when alerts should be sent. Notice that this value is only used for ScoreKeeper alert strategy.
warnScore int + 6 The amount that the score associated with the node should be increased when this check is in a warn state. The default of 6 will increase the score by 6. The Node configuration page is used for specifying when alerts should be sent. Notice that this value is only used for ScoreKeeper alert strategy.
alertScore int + 20 The amount that the score associated with the node should be increased when this check is in a alert state. The default of 20 will increase the score by 20. The Node configuration page is used for specifying when alerts should be sent. Notice that this value is only used for ScoreKeeper alert strategy.
remedyId object set   Null Note that once the automatically execution of the selected action is carried out the whole node will be set into 5 min. downtime. This is done in order to avoid alarms from other checks which might arise because of the action being executed.
forecastEnabled bool + false When forecasts are enabled you can get warnings on predicted failures.
warnOnForecast bool + false Once a forecast is generated, the forecaster can look through the forecast values and warn administrators of any potential future problems the forecast may indicate.
forecastAlertTime enum (ForecastAlerttime) + 1 hour Depending on the nature of the data that are forecast, forecasts will turn out to be reliable for longer or shorter periods of time. You may find, that forecasts for certain checks are only reliable for, say, two hours. Other forecasts may be reliable for days. Using this option you can specify how long into the future you want the forecaster to look for conditions that may result in a warning condition. Specifying "1 Hour" means, that while the forecast may be generated for several days into the future, only the first hour of the forecast will be examined for conditions that can result in a warning being sent to the administrators.
forecastAlertEstError enum (ForecastEsterror) + 5% The forecaster can estimate the error margin on the forecast data, based on simulations on past observations. This option lets you specify the maximal error estimate that a forecast can have, in order to be used as basis for forecast warnings. For example, if you specify "5%", a forecast with an estimated error of "7%" cannot result in warnings being sent to administrators. Any forecast with an error above the threshold set here, will be deemed unfit for use as basis for forecast warnings.
frequency uint + 30 Time in seconds between check executions
active bool     'True' indicates that check is active

Properties common for Continuous checks:

Table 14-4.

Name Type Editable Default Description
plotMin real + Null The minimum value on the Y axis that should be plotted on graphs for this check.
plotMax real + Null The maximum value on the Y axis that should be plotted on graphs for this check.
warnIfAbove real + 500 The threshold when check results should be interpreted as in warning
alertIfAbove real + 1000 The threshold when check results should be interpreted as in alerting
supportsMultiCheck bool   true Determines if this check can be used in multicheck configurations. Not supported in the current API.
unit string     Unit that is used to measure the check. Default value depends on check type
preferredUnit string     The preferred unit is used in alert notifications, graph viewing etc. instead of the unit that is used to measure the check. E.g. if the check is performed and results in a bytes/sec value, the displayed value can be changed to bits/sec by using this property

Properties common for Enumeration checks:

Table 14-5.

Name Type Editable Default Description
noStates uint     Determines the number of states of this check.
XXXX enum (StateAction)     Determines the status (Good, Warn, Alert, Unknown) for each state of the check. It noStates = 3, there are 3 properties: stateAction0, stateAction1, stateAction2
XXXX string     Determines the text description for each state of the check.

14.2.1.4.1. NetChecks

These checks can be performed without a SysOrb Agent being installed.

NetChecks on services are performed by using one of these 8 protocols:

  • DNS - Asks a DNS-server to translate a hostname to an IP-address, and matches the returned IP-address with a user specified list of valid IP's.

  • FTP - Tries to log on the node's FTP-server with a specified username and password. If no username is specified, it is only checked that the FTP-banner is returned.

  • HTTP - Connects to an HTTP server on the node and tries to retrieve an URL defined as part of the check.

  • ICMP - Sends an ICMP PING to the node and listens for a reply. This is basicly the same as the ping-program does.

  • IMAP - Connect to the node and examines whether the IMAP server is running or not. This is done by logging in and logging out again.

  • POP3 - Connect to the node and examines whether the POP3 server is running or not. This is done by logging in and logging out again.

  • SMTP - Connects to the node and examines whether there is an SMTP server running there or not.

  • Generic TCP - This simply tries to make a TCP connection to the specified port on the node. If a connection can be opened this check is considered successful.

Common properties for all NetChecks:

Table 14-6.

Name Type Editable Default Description
remoteName string     Internal name of netcheck

Properties for HTTP checks:

Table 14-7.

Name Type Editable Default Description
remoteType enum (RemcheckType)   HTTP The type of NetCheck
port uint + 80 The port SysOrb should send request
httpUrl string + Null When SysOrb performs a check on an HTTP service it will issue a simple GET request for this URL.
httpStatusRegex string + ^2.. After SysOrb has issued a GET request for the URL specified, the web server should return a HTTP status string consisting of three digits. In this field you can specify a pattern that the status must match for the check to be considered OK. This pattern is a POSIX regular expression. For information about regular expressions, please consult:
httpContentRegex string +   This field is used for specifying a pattern that must match the content of the retrieved document. The pattern is a POSIX regular expression. For information about regular expressions, please consult:
httpVersion enum (HttpVersion) + 1.1 This is the HTTP protocol version that SysOrb will use to query the web server.
useSsl bool + false Determines if this check should establish an SSL-tunnel before performing the check. This is necessary when checking e.g. secure HTTP servers
httpUserAgent string + Null If specified, this is the value of the HTTP User-Agent header that SysOrb will send with the request. If you need, for some reason, to send an empty User-Agent header you can achieve this by entering a single space in the input field. The string you specify should conform to the rules of RFC 2616 section 14.43 (

Properties for DNS checks:

Table 14-8.

Name Type Editable Default Description
remoteType enum (RemcheckType)   DNS The type of NetCheck
port uint + 53 The port SysOrb should send request
dnsHost string + Null Host to lookup
dnsIp string + Null The IP address that the host name lookup should resolve to.

Properties for FTP checks:

Table 14-9.

Name Type Editable Default Description
remoteType enum (RemcheckType)   FTP The type of NetCheck
port uint + 21 The port SysOrb should send request
user string + Null User name to login to FTP server
checkPassword string + Null User password to login to FTP server

Properties for Generic TCP check:

Table 14-10.

Name Type Editable Default Description
remoteType enum (RemcheckType)   Generic TCP The type of NetCheck
port uint + 0 The port SysOrb should send request
connClose bool + false Enable this option if the check should wait for the other end to close the connection.

Properties for ICMP checks:

Table 14-11.

Name Type Editable Default Description
remoteType enum (RemcheckType)   ICMP The type of NetCheck
checkAttempts uint + 1 Ping attempts specifies the number of times the ICMP checker is allowed to send an ECHO REQUEST packet to the node, in order to get a successful ECHO REPLY message back. The default is 1 attempt, but for congested networks or busy nodes, it can be beneficial to increase this number in order to avoid false alarms.

Properties for IMAP checks:

Table 14-12.

Name Type Editable Default Description
remoteType enum (RemcheckType)   IMAP The type of NetCheck
checkPassword string + Null Password used to access IMAP server
port uint + 143 The port SysOrb should send request
useSsl bool + false Determines if this check should establish an SSL-tunnel before performing the check. This is necessary when checking e.g. secure HTTP servers
user string + Null User name to access IMAP server

Properties for POP3 checks:

Table 14-13.

Name Type Editable Default Description
remoteType enum (RemcheckType)   POP3 The type of NetCheck
checkPassword string + Null Password used to access POP3 server
port uint + 110 The port SysOrb should send request
useSsl bool + false Determines if this check should establish an SSL-tunnel before performing the check. This is necessary when checking e.g. secure HTTP servers
user string + Null User name to access POP3 server

Properties for SMTP checks:

Table 14-14.

Name Type Editable Default Description
remoteType enum (RemcheckType)   Generic TCP The type of NetCheck
port uint + 25 The port SysOrb should send request
smtpExecuteVrfy bool + false Should or not execute VERIFY command

14.2.1.4.2. AgentChecks

Properties:

Table 14-15.

Name Type Editable Default Description
agentId string     The id of agent
checkType enum     The type of the check. See AgnetCheckType in Enumeration secion
executeAction object     Action assigned to this check (in case of AgentAction check)
descriptionGood string     Check 'good' status description
descriptionWarn string     Check 'warn' status description
descriptionAlert string     Check 'alert' status description
warnIfBelow real +   The bottom threshold of the check value when Warning should be triggered
alertIfBelow real +   The bottom threshold of the check value when Alert should be triggered
warnIfAbovePct real +   The top threshold (in percent) of the check value when Warning should be triggered
alertIfAbovePct real +   The top threshold (in percent) of the check value when Alert should be triggered
warnIfBelowPct real +   The bottom threshold (in percent) of the check value when Warning should be triggered
alertIfBelowPct real +   The bottom threshold (in percent) of the check value when Alert should be triggered
rangeMin real +   The max value to draw in SysOrb graphs
rangeMax real +   The min value to draw in SysOrb graphs
separatorRegex string + \\r?\\n Log entries are identified by looking for this log entry separator. In many cases a newline is the separator. The separator is specified using POSIX regular expressions. For information about regular expressions, please consult:
separatorInclusion enum     This field specifies if the separator should be a part of the log entry. You can choose to include it in the log entry before the separator, in the log entry after the separator or to discard the separator.
silenceWarn uint     The number of seconds the logcheck may be silent before a warning is sent. The LogCheck is considered silent as long as no rules with a 'log' target is matched.
silenceAlert uint     The number of seconds the logcheck may be silent before an alert is sent. The LogCheck is considered silent as long as no rules with a 'log' target is matched.
parasiteOn id     If you set this field, this LogCheck will leech its entries from the given LogCheck, only if no rules in this check matches an entry will it be returned to the original LogCheck, for processing using its rules. This is mostly useful when configuring LogChecks using NodeClasses.
parasitePattern string   '.*' If you have chosen this check to be a parasite on another LogCheck, then the entries "leeched" from the other LogCheck will be restricted to the ones matching this pattern.

14.2.1.4.3. SnmpChecks

Properties:

Table 14-16.

Name Type Editable Default Description
mibObject string     Id of the object that contain SNMP OID

14.2.1.4.4. EsxiChecks

Properties:

Table 14-17.

Name Type Editable Default Description
esxiType enum     The type of esxi check.

14.2.1.5. User

Properties:

Table 14-18.

Name Type Editable Default Description
id string     Object id
version string     Object version
parentId string     Object parent
name string +   Object name
siblingName string     Internal name
treeLabel string   "name" Full name: "label (name)"
longLabel string   "name" Full name: "label (name)"
realName string + "name" Full name
password string + Null User password. When requested always contain Null value.
capAck bool + false Enabling this allows the the user to set downtime, acknowledge alerts and reset scores on both nodes and checks, but not otherwise change any node or check settings.
capAction bool + false This capability allows the user to start an AgentAction on a node.
capChecks bool + false Allows the user to configure what checks should run on the different nodes in the accessible domains. The user is also allowed to create and edit NodeViews on all accessible nodes. Lastly, it allows the user to acknowledge alerts, reset scores and configure downtime for checks.
capClusterConf bool + false

This capability only affects SysOrb users in the root domain. When this is enabled the user will be able to setup some server/cluster-wide parameters of the SysOrb server, currently only which Custom AlertPaths will be available, and what command to execute.

Security warning: Enabling this capability effectively allows the user to execute abitrary shell commands on the SysOrb server (through Custom AlertPaths).
capDomains bool + false Allows the user to edit or add new subdomains to his or her Origin Domain. It also allows the user to create or edit QuickLinks and Report headers/footers in his Origin Domain and all subdomains to this. If the user is located in the root domain, it also allows him/her to import MIB-files into the SysOrb Server.
capGridConf bool + false Allows the user to create stations, links, mount points and exports.

Note: This capability only affects users in the root domain.

capGroups bool + false Lets the user administer groups and assign alert paths to these in the accessible domains.
capNodes bool + false Lets the user configure nodes in his or her Origin Domain and all the subdomains. It also allows the user to edit and configure NodeClasses created in the Origin domain or one of its subdomains. This option also allows the user to acknowledge alerts, reset scores, and configure downtime, but only for nodes.
capRead bool + true Allows the user to view information
capReports bool + false Lets the user create templates for reports and generate reports from them. Without this option, the user is not allowed to generate or edit reports, even if they have "Public Editable" set.
capSelf bool + true Allows the user to edit his or her own information, including his or her password, and to delete the user account. This does
capSetCap bool + false Lets the user change anything in the domain and its subdomains. This is effectively a way of giving the user full administrative rights in a domain.

Note: No amount of capabilities can allow a user to access higher level domains. It is therefore perfectly safe to give customers logins with administrative privileges in their own domain.

Security warning: Enabling this capability for a user in the root domain will allow that user to give himself Server setup capability, which will allow him to run arbitrary shell commands on the SysOrb server.

capUsers bol + false

A user with this capability can also create new users, but without the "capSetCap" capability, the created users will only have the rights to "capRead", and to "capSelf".

Furthermore, this capability together with "capSelf", will allow the user to edit and view other users Views. Without the capability to "capSelf", other users private views can be seen, but not edited.

In combination with to "capReports", this capability allows the user to view and edit the private reports of other users.

However, the user is only allowed to edit a private view or report, if the owner of the view or report is from the same domain or a subdomain of the users domain. E.g. if a user from the Root domain creates a private report in the Customer.A domain, then a user with all capabilities enabled, will not be able to edit this report. This can only happen if the view or report has "Public edit" enabled.

14.2.1.6. StatusInfo

Properties:

Table 14-19.

Name Type Editable Default Description
checkin enum (Status)     Current checkin status
countAlert uint     The number of checks in Alert state
countOk uint     The number of checks in Ok state
countWarn uint     The number of checks in Warning state
network enum (Status)     Overall status of Network Checks
system enum (Status)     Overall status of Agent Checks
worst enum (Status)     The worst status of the Domain
worstDomain* string     The id of Domain in worst state
worstNode* string     The id of Node in worst state

Note: Properties marked with "*" only for Domain status info

14.2.1.7. ScoreInfo

Properties:

Table 14-20.

Name Type Editable Default Description
enteredAlert timestamp     The time Node/Check had entered Alert state
enteredWarn timestamp     The time Node/Check had entered Warning state
state enum     The current state of the Node/Check
status enum (Status)     The current status of the Node/Check

14.2.1.8. NodeSummary

Properties:

Table 14-21.

Name Type Editable Default Description
badChecks object set     List of checks id with bad results
lastCheckin timestamp   Null The time of agent last checkin
lastEsxi timestamp   Null The time of ESXi last check
lastEsxiRef id   Null The id of ESXi last check
lastService timestamp   Null The time of netcheck last check
lastServiceRef id   Null The time of netcheck last check
lastSnmp timestamp   Null The time of SNMP last check
lastSnmpRef id   Null The time of SNMP last check
nextCheckin timestamp   Null The time of next agent checkin
tag string     Internal
unknownChecks object set     The list of objects in Unknown state

14.2.1.9. CheckSummary

Properties:

Table 14-22.

Name Type Editable Default Description
explanation string   No data present Description of check result
lastAlert timestamp   Null The time of last alert state
lastCheck timestamp   Null The time of last check execution
lastGood timestamp   Null The time of last good stat
lastWarn timestamp   Null The time of last warning state
nextCheck timestamp   Null The time of next check execution
result string   No data present Check result
tag string   Null Internal

14.2.1.10. Enumeration

Table 14-23.

Type Name Value Text
65537 AlertMethod 0 HTML e-mail
    1 SMS via. e-mail gateway
    2 Num. Pager
    3 Direct SMS
    4 Plaintext e-mail
    5 Custom
65538 StateAction 0 Good
    1 Warn
    2 Alert
65540 RemcheckType 1 HTTP
    2 ICMP
    3 DNS
    4 SMTP
    5 POP3
    6 Generic TCP
    7 FTP
    8 IMAP
    9 NTP
    10 NNTP
    11 NFS
    12 NIS
    13 PORTMAP
    14 RPC
    15 Custom
65541 Status 0 N/A
    1 Good
    2 (Good)down
    3 (Good)depend
    4 (Unknown)down
    5 (Unknown)depend
    6 (Warning)down
    7 (Warning)depend
    8 (Alert)down
    9 (Alert)depend
    10 Uninitialized
    11 Unknown
    12 Warning
    13 Alert
65546 ReportPeriod 1 Yesterfday
    2 Last week
    3 Last month
    4 Last year
    5 All time
    6 Last quarter
    7 Last 12 Hours
65548 AlertStrategy 0 Immediate
    1 ScoreKeeper
65550 DownNotify 0 None
    1 People receiving warnings
    2 People receiving alerts
65551 ForecastAlerttime 0 1 hour
    1 2 hour
    2 6 hour
    3 12 hour
    4 1 day
    5 2 day
65552 ForecastEsterror 0 5%
    1 10%
    2 15%
    3 20%
    4 25%
65553 RecurrenceDay 0 Never
    1 Day
    2 Week day
    3 Month day
    4 Last day of month
    5 Last day of quarter
65554 AgnetCheckType 0 Integer Continuous Check
    1 Process Presence Check
    2 Raid Check
    3 Boolean Check
    4 Uptime check
    5 SMART Status Check
    6 Log Check
    7 Floating Point Continuous Check
    8 Agent Action
    9 Advanced Log Check
    10 SAF-TE Slot
    11 SAF-TE Fan Check
    12 SAF-TE Power Supply Check
65556 SnmpVersion 0 Autodetect
    1 SNMPv1
    2 SNMPv2
65560 LogCheckSeparatorInclusion 0 Append to previous entry
    1 Prepend to next entry
    2 Discard the separator
65561 Period 0 1 year
    1 6 months
    2 3 months
    3 1 month
    4 1 week
    5 1 day
    7 1 hour
65562 RuleType 0 FTP Greeting
    1 SMTP Greeting
    2 POP3 Greeting
    3 HTTP reply header
    4 SNMP OID Prefix
    5 Is Pingable (ICMP)
    6 Has a DNS service
    7 IMAP Greeting
    8 Can connect to port
    9 Node info match
    10 HTTPs reply header
    11 POP3S Greeting
    12 IMAPS Greeting
65563 MinDelayScope 0 Per node
    1 Per check
65564 YesNoDefault 0 Yes
    1 No
    2 Default
65566 ReportType 1 System availability
    2 Incidents
    3 Response time
    4 Current licenses
    5 Current configuration
65568 HttpVerion 0 1.0
    1 1.1

14.2.1.11. Timeseries

All check results (timeseries) stored in database in DataInterval objects. There are 3 types of timeseries, depending on check type: Continuous, Enumeration and Incident.

In common case each 2 sequent DataIntervals should be connected (in case of drawing). But in some cases (server was down or check had no results for some period) DataIntervals shouldn't be connected. For that cases SysOrb has special rule:

Consider four data segments, where A, B, C and D is a record in this functions input vector:

A1 - A2 B1 - B2 C1 - C2 D1 - D2

(B2 - C1) is a hole if:

|C1B2| > 2.5 * (|A2B1|)

AND

|C1B2| > 2.5 * (|D1C2|)

If segment A or segment D is missing, the corresponding expression in the above is simply not considered. If we have less than three segments to consider, they will not be connected.

14.2.1.11.1. Contimuous

Properties:

Table 14-24.

Name Type Editable Default Description
timestart timestamp     Start of data interval
timeend timestamp     End of data interval
ngood int     Number of check results in this interval in a good state
nbad int     Number of check results in this interval in a bad state
min real     Minimum value of check result in the given interval
avg real     Average value of check result in the given interval
max real     Maximum value of check result in the given interval

14.2.1.11.2. Enumeration

Properties:

Table 14-25.

Name Type Editable Default Description
timestart timestamp     Start of data interval
timeend timestamp     End of data interval
ngood int     Number of check results in this interval in a good state
nbad int     Number of check results in this interval in a bad state
mask int     State mask according to the statuses of the check

14.2.1.11.3. Incident

Properties:

Table 14-26.

Name Type Editable Default Description
time timestamp     Time when incident was stored
severity int     Incident severity
message string     Incident message

14.2.2. Configuring SysOrb Web Service

By default SysOrb WebAPI service is disabled. To enable it locate an option "wapi_enabled" in the config file, set it to "true" and restart SysOrb. Other configuration options:

wapi_port - port used by Web service to serve requests.

wapi_use_ssl - set to "true" to enable ssl.

wapi_threads - the number of threads used by web service to serve requests.

wapi_ssl_cert_path - the path to ssl certificate files.

ios_cert_path - the path to iOS certificate files to allow push notifications.

14.2.3. Retrieving access token

This API requires access token in the Authorization header in all functions. To get this token call GET /token function:

Example 14-1. Request access token

// uname is the user name
// upass is the user password
// udom is the user domain
var auth = btoa(uname + ":" + upass + ":" + udom); // build authentication string in Base64 encoding
var url = 'localhost:8080/token';
request = new XMLHttpRequest();
 
request.open('GET', url, true);
request.setRequestHeader('authorization', 'Basic ' + auth);
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      // Process XML to extract user domain id and access token
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(null);

Web Service makes token invalid after 90 minutes of user inactivity.

14.2.3.1. Signing off

Call delete /token function to gracefully close session:

Example 14-2. Sign off

// utoken is the access token
 
var api_url = 'localhost:8080/token';
request = new XMLHttpRequest();
 
request.open('DELETE', api_url, true);
request.setRequestHeader('authorization', 'Basic ' + utoken);
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      // User signed off successfully
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(null);

14.2.4. Working with Domains

14.2.4.1. Iterate through Domains hierarchy

Use GET /domains function to get all subdomains one level below of the domain passed to a function. As a start point use domain id from token request - this is the Domain user logged in. Then using object ids from the response it is possible to request other subdomains and so on.

Example 14-3. Get a list of subdomains

// udom - is the Domain id which we want to get subdomains
// utoken - access token
 
//
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
// Call domains function with udom parameter
request.open('GET', api_url + '/domains/' + udom, true);
request.setRequestHeader('authorization', 'Basic ' + utoken);
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      // We got xml which contain a list of domains with their object id,
      // version and label, parse it.
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(null);

14.2.4.2. Get a list of Domains with StatusInfo

StatusInfo object shows current state of Domain.

Example 14-4. Get Domain StatusInfo

// udom - is the Domain id which we want to get subdomains with StatusInfo objects
// utoken - access token
 
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
// URL to StatusInfo function
var si_url = '/domains/' + udom + '/statusinfo';
 
// Call get statusinfo function with udom parameter
request.open('GET', api_url + si_url, true);
request.setRequestHeader('authorization', 'Basic ' + utoken);
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      // We got xml which contain a list of domains with StatusInfo object,
      // parse it.
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(null);

14.2.4.3. Create a new Domain

To create a new domain first of all ask for domain template. Domain template is the object that contain a list of properties can be edited by the user.

Example 14-5. Get Domain template

// udom - is the Domain where we want to create a new one
// utoken - access token
 
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
// URL to template function
var template_url = '/domains/' + udom + '/template';
 
request.open('GET', api_url + template_url, true);
request.setRequestHeader('authorization', 'Basic ' + utoken);
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      // We got xml which contain a list of editable properties,
      // parse it.
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(null);

Once received editable properties, fill the request xml to create a domain.

On success status code 201 Created returned. Read the object id in the 'location' header and version in the 'content-version' header.

Example 14-6. Create a new Domain

// udom - is the Domain where we want to create a new one
// utoken - access token
// req_xml is xml that contain a list of properties with values
 
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
// URL to the function
var func_url = '/domains/' + udom;
 
request.open('POST', api_url + func_url, true);
request.setRequestHeader('authorization', 'Basic ' + utoken);
request.setRequestHeader('content-type', 'text/xml');
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 201) {
      // Domain was created, it's id is in the 'location' header
      // and version is in the 'content-version'
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(req_xml);

14.2.4.4. Update a Domain

To update properties of the existing domain get domain template like described in Create a new Domain section.

Then fill the request xml with properties should be changed and call PUT domains function.

On success a new version of the domain is returned in the 'content-version' header.

Example 14-7. Edit domain properties

// domain_id - is the domain we want to edit
// version - current version of the domain
// utoken - access token
// req_xml is the xml that contain a list of properties we want to change
 
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
// URL to the function
var func_url = '/domains/' + domain_id;
 
request.open('PUT', api_url + func_url, true);
 
// Setup required headers
request.setRequestHeader('authorization', 'Basic ' + utoken);
request.setRequestHeader('content-version', version);
request.setRequestHeader('content-type', 'text/xml');
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      // Domain was updated, the new version is in the 'content-version'header
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(req_xml);

14.2.4.5. Delete a Domain

Example 14-8. Delete a Domain

// domain_id - is the domain we want to delete
// version - current version of the domain
// utoken - access token
 
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
// URL to the function
var func_url = '/domains/' + domain_id;
 
request.open('DELETE', api_url + func_url, true);
 
// Setup required headers
request.setRequestHeader('authorization', 'Basic ' + utoken);
request.setRequestHeader('content-version', version);
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      // Domain was deleted
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(null);

14.2.5. Working with Nodes

14.2.5.1. Get a list of Nodes

Example 14-9. Get a list of Nodes

// udom - is the Domain id which we want to get Nodes
// utoken - access token
 
//
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
// Call nodes function with udom parameter
request.open('GET', api_url + '/nodes/' + udom, true);
request.setRequestHeader('authorization', 'Basic ' + utoken);
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      // We got xml which contain a list of nodes with their object id,
      // version and label, parse it.
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(null);

14.2.5.2. Create a new Node

To create a new node first of all ask for node template. Node template is the object that contain a list of properties can be edited by the user.

Example 14-10. Get Node template

// udom - is the Domain where we want to create a new Node
// utoken - access token
 
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
// URL to template function
var template_url = '/nodes/' + udom + '/template';
 
request.open('GET', api_url + template_url, true);
request.setRequestHeader('authorization', 'Basic ' + utoken);
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      // We got xml which contain a list of editable properties,
      // parse it.
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(null);

Once received editable properties, fill the request xml to create a node.

On success status code 201 Created returned. Read the object id in the 'location' header and version in the 'content-version' header.

Example 14-11. Create a new Node

// udom - is the Domain where we want to create a new node
// utoken - access token
// req_xml is xml that contain a list of properties with values
 
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
// URL to the function
var func_url = '/nodes/' + udom;
 
request.open('POST', api_url + func_url, true);
request.setRequestHeader('authorization', 'Basic ' + utoken);
request.setRequestHeader('content-type', 'text/xml');
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 201) {
      // Node was created, it's id is in the 'location' header
      // and version is in the 'content-version'
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(req_xml);

14.2.5.3. Update a Node

To update properties of the existing node get node template like described in Create a new Node section.

Then fill the request xml with properties should be changed and call PUT nodes function.

On success a new version of the node is returned in the 'content-version' header.

Example 14-12. Update Node properties

// node_id - is the id of node we want to edit
// version - current version of the node
// utoken - access token
// req_xml is the xml that contain a list of properties we want to change
 
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
// URL to the function
var func_url = '/nodes/' + node_id;
 
request.open('PUT', api_url + func_url, true);
 
// Setup required headers
request.setRequestHeader('authorization', 'Basic ' + utoken);
request.setRequestHeader('content-version', version);
request.setRequestHeader('content-type', 'text/xml');
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      // Node was updated, the new version is in the 'content-version' header
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(req_xml);

14.2.5.4. Delete a Node

Example 14-13. Delete a Node

// node_id - is the id of node we want to delete
// version - current version of the node
// utoken - access token
 
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
// URL to the function
var func_url = '/nodes/' + domain_id;
 
request.open('DELETE', api_url + func_url, true);
 
// Setup required headers
request.setRequestHeader('authorization', 'Basic ' + utoken);
request.setRequestHeader('content-version', version);
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      // Node was deleted
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(null);

14.2.6. Working with CheckGroups and Checks

14.2.6.1. Iterate through CheckGoups hierarchy

There are four predefined groups of checks in SysOrb: Network Checks, Agent Checks, SNMP Checks ans ESXi checks. These groups hierarchically are right under the Node object, so to start traverse the check groups use node id as entry point. Then using object ids from the response it is possible to request other check groups/checks and so on.

Example 14-14. Read the check groups

// node_id - entry point to start traversing the checks tree
// utoken - access token
 
//
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
request.open('GET', api_url + '/subtree/' + node_id, true);
request.setRequestHeader('authorization', 'Basic ' + utoken);
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      // We got xml which contain a list of checkgroup/check objects with their
      // object id, version and label
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(null);

14.2.6.2. Get a list of active checks

Previous function returns all checks - active and inactive.

To get only active checks use GET /ckecks/<filter> function. This function accepts a filter string which helps to sort out different types of check: e.q. if you need to get all active network checks use 'type=netchecks' as a filter. Refer to XXX to get detailed info. As a result service returns a list of active network checks with their CheckSummary object. CheckSummary object shows detailed information about check status, such as check result with explanation string, time of last checks and time when next check scheduled, etc.

Example 14-15. Get all active checks

// node_id - this function requires node id to apply filter
// utoken - access token
 
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
// Notice that we don't specify filter - by default function returns all active checks
request.open('GET', api_url + '/checks/' + node_id, true);
request.setRequestHeader('authorization', 'Basic ' + utoken);
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      // We got xml which contain a list of active checks with CheckSummary
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(null);

Also this function accepts optional parameter 'status', with values 'alert' and 'warn'. For example 'status=alert' will return a list of active checks in ALERT status.

Note: if parameter 'status' is used function return ScoreInfo object instead of CheckSummary in previous example.

ScoreInfo object shows the current status of the check and time when check entered that status.

Example 14-16. Get active ESXi checks in WARNING state

// node_id - this function requires node id to apply filter
// utoken - access token
 
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
// Get active ESXi checks that are in WARN state
var filter = '/type=esxichecks&status=warn';
request.open('GET', api_url + '/checks/' + node_id + filter, true);
request.setRequestHeader('authorization', 'Basic ' + utoken);
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      // We got xml which contain a list of active checks with ScoreInfo
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(null);

14.2.6.3. Create a Check

As usually you need to get check template first. But mention that depending on check type (Network Check and others) you need to pass SiblingName (for Network Checks), because Network Checks are not created initially. Let's demonstrate this in examples below.

Example 14-17. Request a check template for Network Check

// check_grp - notice that we need to pass a Network Checks group.
// utoken - access token
// sibling - is the sibling name of the check we want to get template.
// Use 'get /subtree' to get a full list of network checks with their SiblingNames
 
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
// URL to template function
var template_url = '/checks/' + check_grp + '/template/' + sibling;
 
request.open('GET', api_url + template_url, true);
request.setRequestHeader('authorization', 'Basic ' + utoken);
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      // We got xml which contain a list of editable properties,
      // parse it.
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(null);
Now, using given template we can create a check.

Example 14-18. Create a check

// id - parent check group id
// utoken - access token
// req_xml is xml that contain a list of properties with values
// sibling - is the sibling name of the check we want to create
 
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
// URL to the function
var func_url = '/checks/' + id + '/template/' + sibling;
 
request.open('POST', api_url + func_url, true);
request.setRequestHeader('authorization', 'Basic ' + utoken);
request.setRequestHeader('content-type', 'text/xml');
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 201) {
      // Check was created, it's id is in the 'location' header
      // and version is in the 'content-version'
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(req_xml);

14.2.6.4. Update a Check

Once created (by Scan process, or as described above) any check can be updated. As usually you need to get a list of editable properties:

Example 14-19. Get a lis of editable properties of the given check

// check_id - id of check we want to get a list of editable properties.
// utoken - access token
 
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
// URL to template function
var template_url = '/checks/' + check_id + '/template/';
 
request.open('GET', api_url + template_url, true);
request.setRequestHeader('authorization', 'Basic ' + utoken);
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      // We got xml which contain a list of editable properties,
      // parse it.
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(null);

Example 14-20. Update a check

// check_id - is the id of check we want to edit
// version - current version of the check
// utoken - access token
// req_xml is the xml that contain a list of properties we want to change
 
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
// URL to the function
var func_url = '/checks/' + check_id;
 
request.open('PUT', api_url + func_url, true);
 
// Setup required headers
request.setRequestHeader('authorization', 'Basic ' + utoken);
request.setRequestHeader('content-version', version);
request.setRequestHeader('content-type', 'text/xml');
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      // Check was updated, the new version is in the 'content-version' header
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(req_xml);

14.2.6.5. Delete a Check

Example 14-21. Delete a Check

// check_id - check we want to delete
// version - current version of the check
// utoken - access token
 
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
// URL to the function
var func_url = '/checks/' + check_id;
 
request.open('DELETE', api_url + func_url, true);
 
// Setup required headers
request.setRequestHeader('authorization', 'Basic ' + utoken);
request.setRequestHeader('content-version', version);
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      // Check was deleted
      ....
    } else if (request.status == 202) {
      // Check was made inactive - new version is in content-version header
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(null);
Note: This function delete permanently only checks that was created from CheckTemplate objects. All other checks are made inactive.

14.2.7. Managing Users in SysOrb

14.2.7.1. Get a list of Users of a Domain

Use get /users function to get all Users in the Domain

Example 14-22. Get a list of Users

// domain_id - Domain we want to get a Users list
// utoken - access token
 
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
request.open('GET', api_url + '/users/' + domain_id, true);
request.setRequestHeader('authorization', 'Basic ' + utoken);
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      // We got xml which contain a list of users registered in the domain
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(null);
To get user permissions use get /object function (only if user have capability to view/change user capabilities).

14.2.7.2. Create a new User

To create a new user first of all ask for user template. User template is the object that contain a list of properties can be edited by the user.

Example 14-23. Get User template

// udom - is the Domain where we want to create a new User
// utoken - access token
 
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
// URL to template function
var template_url = '/users/' + udom + '/template';
 
request.open('GET', api_url + template_url, true);
request.setRequestHeader('authorization', 'Basic ' + utoken);
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      // We got xml which contain a list of editable properties,
      // parse it.
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(null);
Once received editable properties, fill the request xml to create a new user.

On success status code 201 Created returned. Read the object id in the 'location' header and version in the 'content-version' header.

Example 14-24. Create a new User

// udom - is the Domain where we want to create a new user
// utoken - access token
// req_xml is xml that contain a list of properties with values
 
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
// URL to the function
var func_url = '/users/' + udom;
 
request.open('POST', api_url + func_url, true);
request.setRequestHeader('authorization', 'Basic ' + utoken);
request.setRequestHeader('content-type', 'text/xml');
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 201) {
      // USer was created, it's id is in the 'location' header
      // and version is in the 'content-version'
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(req_xml);

14.2.7.3. Update a User

To update properties of the existing user get user template like described in Create a new User section.

Then fill the request xml with properties should be changed and call PUT users function.

On success a new version of the user is returned in the 'content-version' header.

Example 14-25. Update a User

// user_id - is the id of user we want to edit
// version - current version of the user
// utoken - access token
// req_xml is the xml that contain a list of properties we want to change
 
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
// URL to the function
var func_url = '/users/' + node_id;
 
request.open('PUT', api_url + func_url, true);
 
// Setup required headers
request.setRequestHeader('authorization', 'Basic ' + utoken);
request.setRequestHeader('content-version', version);
request.setRequestHeader('content-type', 'text/xml');
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      // User was updated, the new version is in the 'content-version' header
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(req_xml);

14.2.7.4. Delete a User

Example 14-26. Delete a User

// user_id - is the id of user we want to delete
// version - current version of the user
// utoken - access token
 
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
// URL to the function
var func_url = '/users/' + domain_id;
 
request.open('DELETE', api_url + func_url, true);
 
// Setup required headers
request.setRequestHeader('authorization', 'Basic ' + utoken);
request.setRequestHeader('content-version', version);
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      // User was deleted
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(null);

14.2.8. Enumerations in SysOrb

14.2.9. Common functions applied to most objects in SysOrb

14.2.9.1. Reading the object's properties

To get complete list of properties for any object in SysOrb use get /objects function.

Example 14-27. Get object properties

// id - opject id want to get a list of properties
// utoken - access token
 
var api_url = 'localhost:8080';
request = new XMLHttpRequest();
 
request.open('GET', api_url + '/objects/' + id, true);
request.setRequestHeader('authorization', 'Basic ' + utoken);
 
request.onreadystatechange = function() {
  if (request.readyState == 4) {
    if (request.status == 200) {
      // We got xml which contain a list of properties of the object
      ....
    }
    else {
      // Handle errors
      ....
    }
  }
};
 
request.send(null);