Deploy a probe using the RESTful webservices API (webservices

Products

DX Unified Infrastructure Management (Nimsoft / UIM) CA Unified Infrastructure Management On-Premise (Nimsoft / UIM) CA Unified Infrastructure Management SaaS (Nimsoft / UIM)

Issue/Introduction

Similar to using command line arguments in DX UIM server's nimsoft/bin directory, or using LUA scripts, customers can deploy probes via RESTful web services after the webservices_rest probe is deployed to a wasp probe on a Unified Management Portal (UMP)/Operator Console server without needing either the Infrastructure Management client or Admin Console.

RESTful Web Services

Probe Calls

Environment

Ensure that you are using compatible versions of the webservices_rest probe with your versions of DX UIM server.
There are a few options to deploy via REST calls. This techdoc assumes the end user is familiar with RESTful web service calls and the choice of tools to send RESTful statements.i.e. SOAPUI or any thick client, or REST client browser plugin.
Usage of REST clients is outside the scope of this techdoc. The example given was built using SOAPUI.

Cause

Guidance

Resolution

A properly formatted API request to deploy a probe requires name, type, and value.
The below example will deploy a logmon v3.90 probe to a robot that resides in the same domain as the Primary hub.

NOTE: The webservices_rest probe can be deployed to the wasp on the primary hub that also hosts the adminconsoleapp for ease of troubleshooting in the event that the request fails. This way there are fewer points of failure to investigate.

Make sure you read and understand the section on setting up RESTful webservices in our probe documentation for clarity.

Method: POST
Endpoint: http://UMPserver-hosting-webservices_rest_probe:port
Resource: /rest/probe/primary-hub-domain/primary-hub/primary-robot/distsrv/callback/job_add
Media Type: application/xml

BODY

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<callbackrequest>
    <timeout>30000</timeout>
    <parameters>
        <name>job_id</name>
        <type>String</type>
        <value></value>
    </parameters>
    <parameters>
        <name>job_description</name>
        <type>String</type>
        <value></value>
    </parameters>
    <parameters>
        <name>version</name>
        <type>String</type>
        <value>3.90</value>
    </parameters>
    <parameters>
        <name>package</name>
        <type>String</type>
        <value>logmon</value>
    </parameters>
    <parameters>
        <name>robot</name>
        <type>String</type>
        <value>primary-hub-domain/primary-hub/destination-robot</value>
    </parameters>
    <parameters>
        <name>update</name>
        <type>Integer</type>
        <value>0</value>
    </parameters>
    <parameters>
        <name>start_at</name>
        <type>Integer</type>
        <value>0</value>
    </parameters>
</callbackrequest>

END

You are free to use either xml or json for the message body. This is considered user preference.

This is the expected output:

HTTP/1.1 200 OK
Content-Type: application/xml
Content-Length: 251
Date: Tue, 11 Jul 2017 22:30:19 GMT
Server: wasp

<?xml version="1.0" encoding="UTF-8" standalone="yes"?><pds><entry datatype="string" name="job_id"><value xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" xmlns:xs="http://www.w3.org/2001/XMLSchema" xsi:type="xs:string">job#</value></entry></pds>

You should then see a logmon probe running on the destination robot with default values.