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 ?