From the XML API CHM file:

Configuring and starting the XML API Server on the Control Station

Both XML API Servlet and XML API Server share a set of configuration parameters. All parameters are located in the properties file, $NAS_DB/sys/xml_api.conf, which typically resolves to /nas/sys/xml_api.conf. Client application developers can change some of these parameters. After changing parameters that affect the servlet, the Tomcat server on the Control Station needs to be restarted. If the parameters affect the XML API Server, it needs to be restarted as well. Among the list of properties, there are some debug flags. EMC assumes the current release is intended for the application development and not deployment, so many of the flags are set to true (debug mode).

Properties of interest and a short explanation follow:

•   xml.api.server.log – The location of the XML API Server log relative to the $NAS_DB (usually set to /nas) directory. Currently the value is set to log/cel_api.log, which normally results in the log file being recorded in the /nas/log/cel_api.log file. The value of this property affects XML API Server. 

• xml.api.servlet.log – The location of the XML API Servlet log relative to the $NAS_DB directory. Currently the value is set to log/webui/cel_api.log, which normally results in the log file being recorded in the /nas/log/webui/cel_api.log file. The value of this property affects Tomcat server.

• xml.api.servlet.logmask – Switches on and off certain servlet log profiles. The default value for the mask is zero, which means that the servlet does not log anything. You should not change this value, unless you do it temporarily at the request from EMC Support engineers and then reset to zero upon completion of the tests. The value of this property affects Tomcat server.

• xml.api.user.request.validation.flag – If true, performs a full user request validation before parsing. In the case of improperly formatted request packets, it returns more meaningful diagnostic messages to the user. This property is set to true in the current release, but EMC suggests you set it to false when the application is deployed because it adds to CPU and memory overhead and slightly increases the response time. The value of this property affects XML API Server.

• xml.api.enable.indications.ext –  If true, user applications can receive indications for configuration changes. Indications on task completions and statistics are always delivered (regardless of the value of the flag). This property is set to true in the current release and in the future it will be eliminated and the above indications will always be delivered (when the client application subscribes to them). The value of this property affects XML API Server.

• xml.api.trace.apl.calls – Logs APL requests and responses in the XML API server log (property xml.api.server.log). This property is set to true, however, at the time of application deployment, it should be set to false. The value of this property affects XML API Server.

• xml.api.trace.apl.indications – Logs APL indications in the XML API server log (property xml.api.server.log). This property is set to true, however, at the time of application deployment, it should be set to false. The value of this property affects XML API Server.

• xml.api.trace.user.requests – Records user application requests in the XML API server log (property xml.api.server.log). This property is set to true, however, at the time of application deployment it should be set to false. The value of this property affects XML API Server.

• xml.api.quota.poll.offset – Affects the exact time of the poll. B default, the tree quota cache is populated once a day. The time is specified in minutes, starting at midnight (Control Station local time) when the poll starts. The current value is 120, which means that the poll starts at 2 a.m. every night. The value -240, for example, defines that the poll starts at 8 p.m. The value of this property affects the XML API Server.

Starting the XML API Server

By default the XML API is disabled. To start the XML API server, do the following:

As root, use a text editor to uncomment the following entry in /nas/sys/nas_mcd.cfg:

daemon "XML API Server"
    executable "/nas/sbin/start_xml_api_server"
    optional yes
    canexit yes
    autorestart yes
    ioaccess no

Restart nas services with the following command:

# service nas start

The XML API is now started and is controlled by the master control daemon.

Naren,

did that help ?

Rainer

That helped... Thanks a lot Rainer...

You're very welcome.

Were you able to get that chm file?

Rainer

Yes, Thanks

Where did you find the CHM file ? Been looking for it all morning.

I have a generic question on the API and admittedly I am new to XML API programming but I am looking for a way to expose performance stats to a remote monitoring system. The XML API seems to be the right fit. 

Rainer,  this is related to my post a few years ago. We now have VNX,VMAX and VG8's and a NMS that supports XML, SNMP, WMI, trap and syslog styles of reporting and trending data. I am looking for a solution/recommendations to expose performance stats across these platforms without writing custom scripts. 

The NMS is Science Logic. Supports clientless monitoring and reporting.  SOAP/REST/XML/SNMP etc...

I have VNX M&R installed and it does not fit that need. We already have a management console and I am trying to connect our storage infrastructure into it. VMAX,VG8 and VNX

I think there is a download for it in the EDN section

The CHM file has the same content as the Programmers guide in PDF – just easier to use

Which NMS ?

The XML API will only get you so far – its only VNX and the file side – it doesn’t have block info and little file performance info

Plus it’s not simple to integrate into a monitoring app – you are looking at some serious programming

I would suggest you start with evaluating VNX M&R – download from support.emc.com complete with Eval license

If that contains the kind of data you are looking for then ask your EMC sales rep about the full Watch4Net suite

That contains the same info as M&R for the VNX – plus it has report packs for VMAX and other devices

It also has facilities to customize it and to send data from it to other systems like your NMS

What info is it that you are missing from VNX M&R ?

1. It's not addressing the core requirement of integrating into our or any other NMS.
2. If you try the product it's broke out of the box and only trends data for the first two DM's SR number 55089660
3. The product isn't doing anything more than running nas commands to collect stats in a csv. Not sure why a customer would pay for that.
4. No VMAX integration.

Is everyone else out there writing on off scripts to collect stats on their investments or paying for a feature that should be there out of the box ?

I don't understand why EMC thinks it's ok to hold performance stats ho$tage. Cico, NetApp, Oracle, Linix, Windows all provide mibs, API's and hooks to monitor performance. Yes they also sell feature rich products that layer on top of this with proprietary intellectual data modeling but users are not forced back door their way into basic performance trending.

There are API's to get performance data and they are open to customers, partners and 3rd party developers.

yes for most of it it is not through SNMP - but there is NAR, CLI, SMI-S, XML

see the EMC Developer Network forum here on ESN

There is also an EMC Technology Partner Program to help partners integrate with our products.

Quite a number of companies have released products that integrate with EMC products.

If your NMS vendor wants to he can join here https://community.emc.com/community/partner/etp

Rainer

Hi, I am trying to connect to EMC VNX and i am using XML API Programmer Guide for VNX for reference.

I was trying to login to create a session  as mentioned in the above document.

Below is the perl script i wrote to connect to vnx storage center:-

use strict;

use warnings;

use MIME::Base64;

use REST::Client;

# Set the request parameters

my $host = 'http://10.10.10.10';

my $client = REST::Client->new(host => $host);

$client->GET("/Login HTTP/1.1",

   {'user' => 'myusername',

   'password' => 'mypassword',

   'Login' => 'Login',

    'Content-Type' => 'application/x-www-form-urlencoded'});

print 'Response: ' . $client->responseContent() . "\n";

print 'Response status: ' . $client->responseCode() . "\n";

foreach ( $client->responseHeaders() ) {

print 'Header: ' . $_ . '=' . $client->responseHeader($_) . "\n";

}

The response was:-

Response:

Found

The document has moved https://10.10.10.10/Login%20HTTP/1.1">here

>.

Response status: 302

Header: Connection=close

Header: Date=Thu, 08 Jun 2017 08:56:32 GMT

Header: Location=https://10.10.10.10/Login%20HTTP/1.1

Header: Server=Apache

Header: Content-Length=220

Header: Content-Type=text/html; charset=iso-8859-1

Header: Client-Date=Thu, 08 Jun 2017 12:19:55 GMT

Header: Client-Peer=10.10.10.10

Header: Client-Response-Num=1

Header: Title=302 Found

Header: X-Frame-Options=SAMEORIGIN

I dont know why i am not getting response 200 and in which document will i find all the resource URLs which i require to get storage usage data and performance data on the vnx devices .Please help or correct if i am doing any mistake.

Please help me with an example to login to vnx devices and extract storage usage data atleast.