Home | Skip to Content | Skip to Search | Skip to Navigation | Skip to Footer |
Worldwide [change] |Register |About Cisco
Guest

Hierarchical Navigation

Cisco Unified Communications Manager (CallManager)

Cisco CallManager 4.1(3) AXL Serviceability Programming Interface Guide

Downloads

Table Of Contents

Cisco CallManager 4.1(3) AXL Serviceability API Programming Guide

Contents

Introduction

Data Model

Soap Binding

Character Encoding

Binding Style

Transport

Encoding Rule

Request

SOAP Action Header

Port

SOAP Header

Response

Fault

Namespaces

Highly Isolated IIS Service

Components and Dependency

AXL-Serviceability APIs Ports

PerfmonPort

PerfmonListCounter

PerfmonListInstance

PerfmonQueryCounterDescription

PerfmonOpenSession

PerfmonAddCounter

PerfmonRemoveCounter

PerfmonCollectSessionData

PerfmonCloseSession

PerfmonCollectCounterData

Real-Time Information (RisPort)

Selecting Cisco CallManager Real-Time Information

Response Format

Choosing CTI Real-Time Information

Response format

Interface to Get Server Names and Cluster Name

Authentication

Basic

Secure

Authorization

Rate Control

Obtaining Documentation

Cisco.com

Ordering Documentation

Documentation Feedback

Obtaining Technical Assistance

Cisco Technical Support Website

Submitting a Service Request

Definitions of Service Request Severity

Obtaining Additional Publications and Information


Cisco CallManager 4.1(3) AXL Serviceability API Programming Guide

This document describes the implementation of AXL-Serviceability APIs that are based on version 3.3.0.1 or higher. Cisco CallManager Real-Time information, Performance Counters, and Database information exposure occurs through an AXL-Serviceability Interface that confirms to the World Wide Web Consortium (W3C) standard. The Web Service Description Language (WSDL) files provide interface definitions.

To access all AXL API downloads and AXL requests and responses found in this document, refer to the following URL:

http://www.cisco.com/pcgi-bin/dev_support/access_level/product_support

Contents

This document covers the following topics:

•Introduction

•Data Model

•Namespaces

•AXL-Serviceability APIs Ports

•Real-Time Information (RisPort)

•Interface to Get Server Names and Cluster Name

•Authentication

•Rate Control

•Obtaining Documentation

•Documentation Feedback

•Obtaining Technical Assistance

•Obtaining Additional Publications and Information

Introduction

By exposing Cisco CallManager real-time information, performance counter, and database information, customers can write customized applications. AXL-Serviceability APIs, an extensible SOAP-based XML web service, conforms to the SOAP Spec 1.1 [1] and the WSDL Spec 1.1 [2]. AXL-Serviceability APIs represent one server component of the Cisco Serviceability product.

AXL-Serviceability APIs provides RPC-style operations for the clients. Clients of AXL-Serviceability APIs can run in different OS platforms and can communicate with AXL-Serviceability APIs through the standard SOAP protocol. The AXL-Serviceability APIs includes a goal to provide access to the core Cisco Serviceability functionalities through an open and standard transport protocol and data model.

The following list gives the Serviceability services that are exposed via AXL-Serviceability APIs:

•Windows 2000 Perfmon Data Collection.

•Cisco CallManager Device RIS Search

The AXL-Serviceability APIs gets implemented as an ISAPI component of the IIS. AXL-Serviceability APIs as an extensible service allows external implementation of SOAP ports that are to be plugged in through the SOAP port extension dll. This document describes the implementation of AXL-Serviceability APIs that are based on version 3.3.0.1 or higher. The latest implementation of AXL-Serviceability APIs supports only the Perfmon Data Collection functionality and Real-Time information. Cisco plans to add more Serviceability functionalities to the AXL-Serviceability APIs in the near future.

Data Model

AXL-Serviceability APIs are based on SOAP with XML request and response messages. They must conform to the structure of a SOAP Envelope element. Although SOAP is a standard protocol, many of its data model aspects are left open for flexibility reasons. For example, it permits different transport protocols such as SMTP, FTP, or HTTP to carry SOAP messages. The implementation of a SOAP service must specify the bindings of the data model to constitute a concrete wire protocol specification.

WSDL 1.1[2] provides the mechanism to describe the complete SOAP bindings that AXL-Serviceability APIs use.

The following Cisco CallManager server file contains perfmon SOAP requests service definitions:

http://ASTSERVERNAME/soap/AstService.wsdl

The following file contains Cisco CallManager and CTI manager SOAP real-time information requests definitions:

http://ASTSERVERNAME/soap/risport.wsdl

To know what services are available, how to form the request message, and to interpret the response message properly, you must download these files. Basically, the WSDL file has everything that you need to know about AXL-Serviceability APIs. You can get the WSDL file as a static XML page.

ASTSERVERNAME refers to the server on which the AXL-Serviceability APIs is running.

Soap Binding

The binding section of the Serviceability SOAP WSDL files well specifies AXL-Serviceability APIs SOAP binding information. Binding specifications apply to both request and response messages. SOAP Binding covers the following aspects.

Character Encoding

AXL-Serviceability APIs use UTF-8 to encode the data stream in both request and response SOAP messages. The encoding attribute of the XML declaration specifies UTF-8 encoding. AXL-Serviceability APIs also sets "text/xml; charset='utf-8'" as the value of the Content-Type response header field. Internally, AXL-Serviceability APIs processes the data by using UCS-2 Unicode code page.

Binding Style

AXL-Serviceability APIs uses RPC binding style. In SOAP, the word operation refers to method or function. Each AXL-Serviceability APIs operation call gets modeled as a remote procedure call that is encapsulated in SOAP messages. The HTTP request carries the RPC calls while the HTTP response carries the call returns. The call information is modeled as a structure. The member elements of the body entry represent the accessor elements which represent the input parameters. Similar to the request, the response data structure is also modeled as a structure with accessors that correspond to output parameters. Parameters that are both input and output must appear in both the request and response message.

Transport

SOAP allows different transport protocols to carry SOAP messages. AXL-Serviceability APIs use the standard HTTP as its transport. The clients use the POST verb to send request to AXL-Serviceability APIs.

Note AXL-Serviceability APIs do not use the M-POST method as defined in the HTTP Extension Framework.

Encoding Rule

AXL-Serviceability APIs follow the recommended data model and serialization/encoding rules as defined in Section 5.1 of SOAP Spec 1.1[1] for both the request and response messages. SOAP simple types are based on the built-in data types that are defined in XML Schema Part 2[4]. AXL-Serviceability APIs define its own data types, which are derived from the built-in types. The schemas element of the AXL-Serviceability APIs WSDL file specifies AXL-Serviceability APIs that are derived data types. AXL-Serviceability APIs use both simple and compound data types, such as arrays and structures. All operations in AXL-Serviceability APIs pass parameters by value.

For performance reasons, AXL-Serviceability APIs do not specify the size of the array elements in the response message. It leaves the size as [], which means that no particular size is specified, but the clients can determine the size by enumerating the actual number of elements that are inside the array. Point 8 of section 5.1 of SOAP Spec 1.1 [1] specifies this.

The following target namespace URL for AXL-Serviceability APIs data types schema applies:
xmlns:axl =http://www.cisco.com/AXL/API/1.0

AXL-Serviceability APIs qualifies the first body entry in the response, which represents the call-return, with this target namespace. Similarly, clients of AXL-Serviceability APIs also need to qualify the first body entry in the request, which represents the call, with this namespace.

Request

This section describes the SOAP protocol specifications that are relevant only to the request message. With RPC-style SOAP binding, the request SOAP message contains the operation call information that is encoded as a struct. The call struct appears as the first body entry in the request message. The call struct basically contains the name of the operation and the input parameters. The name of the top-level element gets set to be the operation name. The struct contains accessor element members that represent the input parameters. Operation that takes no parameters will have no members in the struct. The names of the accessor elements get set to be the same as the names of the input parameters. The values of the accessor elements represent the values of the input parameters. The order of the accessor elements must match the order of the input parameters as specified in the signature of the operation.

SOAP Action Header

AXL-Serviceability APIs requires SOAP clients to include the SOAP Action HTTP header field in the request message. The Simple Object Access Protocol (SOAP) 1.1 specification does not place any restrictions on the format of this header. For AXL-Serviceability APIs, the soapAction attribute of the SOAP element, which is defined under the binding section of the Serviceability SOAP API WSDL files, specifies the format of the SOAP Action header. All AXL-Serviceability APIs operations use the following URI format: 


http://schemas.cisco.com/ast/soap/action/#PortName#OperationName"

Note Because enclosing double-quote characters are part of the URI, the header must include them.

PortName acts as a placeholder that refers to the name of the port. AXL-Serviceability APIs must support the port. OperationName represents a placeholder that refers to the name of the intended operation within the specified port. This name must match the operation name in the request body, which is specified as the name of the first body entry element. The SOAPAction header gets used to indicate the intent of the SOAP request without having to parse the body of the request. A SOAP server can check the value of this header first and determine whether to fail the operation before it proceeds with the XML parsing of the body. This gives some efficiency edge on the server side. This scheme also allows non-SOAP-aware intermediary HTTP servers or proxies to determine the intent of the payload.

Port

A SoapPort basically represents an instantiation of a SoapBinding with a specific network address. Because AXL-Serviceability APIs use HTTP as the transport protocol, the network address in this case specifies an HTTP request URL. SoapPortType, with specific binding rules added to it, provide a basis for the definition of SoapBinding. The service section of the WSDL file defines the request URL for all AXL-Serviceability APIs operations as follows: 


http://ASTSERVERNAME/soap/astsvc.dll

ASTSERVERNAME refers to the server name on which the Serviceability SOAP service is running. Every request for the AXL-Serviceability APIs operations must use this URL. The word SOAP refers to the virtual root on which "astsvc.dll" gets placed.

SOAP Header

As previously explained, the SOAP header provides a general way to add features to SOAP messages in a decentralized fashion with no prior contract between the sender and recipient. AXL-Serviceability APIs do not use this feature, so no Header element is expected in the envelope and gets ignored. If the Header element gets included with the mustUnderstand attribute set to 1, AXL-Serviceability APIs reply with a fault and fault code value that is set to MustUnderstand.

The following example shows AXL-Serviceability APIs SOAP request message with the HTTP header information:

Example 

POST /soap/astsvc.dll HTTP/1.1

Host: nozomi

Content-Type: text/xml; charset=utf-8

Content-Length: xxx

SOAPAction: "http://schemas.cisco.com/ast/soap/action/#PerfmonPort#PerfmonOpenSession"


<?xml version="1.0" encoding="utf-8" ?> 

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

	xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

	xmlns:xsd="http://www.w3.org/2001/XMLSchema">

		<soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

			<q1:PerfmonOpenSession xmlns:q1="http://schemas.cisco.com/ast/soap/" /> 

		</soap:Body>

</soap:Envelope>

Response

This section describes the SOAP protocol specifications that are relevant only to the response message.

For a successful operation call, the call-return gets encoded as a structure. The structure appears as the first body entry of the response. The call-return basically contains the output parameters or return values of the call. The name of the structure top-level element has no significance, and Simple Object Access Protocol (SOAP) 1.1 specification does not place any restriction on the name. The structure contains accessor member elements, which represent the output parameters of the call. The names of the accessor elements are the same as the names of the output parameters. The contents of the accessor elements represent the values of the output parameters. The order of the accessor elements must match the order of output parameters as specified in the operation signatures. Operation, which does not return any value, contain no member elements in the call-return struct. AXL-Serviceability APIs use the following naming conventions for its call-return top-level element: 


OperationNameResponse

OperationName represents a placeholder that refers to the name of the operation that is specified in the corresponding request message. This format is specific only for AXL-Serviceability APIs implementation.

The target namespace that is described in the Encoding Rule section, qualifies the call-return. AXL-Serviceability APIs returns HTTP status 200 when the operation succeeds.

For a failed operation call, AXL-Serviceability APIs includes the SOAP fault element in the response body. Similar to call-return, the fault element also appears as the first body entry. AXL-Serviceability APIs sets HTTP 500 status when sending fault message.

Fault

When AXL-Serviceability APIs process a request and detect that an error occurred, it replies with a SOAP fault element in the response. The fault element appears as the first response body entry. The fault element comprises the following four subelements:

•Fault Code

•FaultString

•FaultActor

•Detail

Fault Code

AXL-Serviceability APIs uses the following standard fault code values as defined in Section 4.4.1 of the Simple Object Access Protocol (SOAP) 1.1 specification.

VersionMismatch

This fault code gets set when the namespace URL of the request envelope does not match xmlns:axl =http://www.cisco.com/AXL/API/1.0.

MustUnderstand

This fault code gets set when the clients include the Header element in the envelope along with the mustUnderstand attribute set to 1. AXL-Serviceability APIs do not use the Header element. See the SOAP Header section for details.

Client

This fault code gets set when AXL-Serviceability APIs encounters errors that are related to the clients.

Server

This fault code gets set when AXL-Serviceability APIs encounter errors that are related to the service itself.

The faultcode value gets qualified with xmlns:axl =http://www.cisco.com/AXL/API/1.0 namespace. This subelement always exists in the fault element as the Simple Object Access Protocol (SOAP) 1.1 specification specifies. This represents a general classification of errors.

FaultString

AXL-Serviceability APIs set a short error description in the faultstring element that is intended for human reading. Similar to faultcode, this subelement remains always present as required by the Simple Object Access Protocol (SOAP) 1.1 specification requires. The string value of the FaultString is specific only to the AXL-Serviceability APIs.

FaultActor

AXL-Serviceability APIs does not set this subelement. Note that a proxy or intermediary server must include this subelement if it generates a fault message.

Detail

If AXL-Serviceability APIs parse and process the request body and determine that an error occurs afterwards, it includes the detailed error information in the detail subelement.

If AXL-Serviceability APIs do not include the detail subelement in the fault element, the error does not relate to the request body. Data types that are defined in the AXL-Serviceability APIs. WSDL files specify the encoding rule for the detail element. The following fragments of the file describe the types: 


    64	<complexType name='CallInfoType'>

    65		<sequence>

    66			<element name='FileName' 			type='xsd:string'/>

    67			<element name='LineNo' 			type='xsd:int'/>

    68			<element name='ErrorCode' 			type='xsd:unsignedInt'/>

    69			<element name='Function' 			type='xsd:string'/>

    70			<element name='Params' 			type='xsd:string'/>

    71		</sequence>

    72	</complexType>

    73	

    74	<complexType name='ErrorInfoType'>

    75		<sequence>

    76			<element name='Version' 			type='xsd:string'/>

    77			<element name='Time' 				type='xsd:time'/>

    78			<element name='ProcId' 			type='xsd:unsignedInt'/>

    79			<element name='ThreadId' 			type='xsd:unsignedInt'/>

    80			<element name='ArrayOfCallInfo' 	type='tns:ArrayOfCallInfoType'/>

    81		/sequence>

82	</complexType>


   128	<complexType name='ArrayOfCallInfoType'>

   129		<complexContent>

   130			<restriction base='SOAP-ENC:Array'>

   131				<sequence>

   132					<element name='CallInfo'

   133						type='tns:CallInfoType' minOccurs='1' maxOccurs='unbounded'/>

   134				</sequence>

   135			</restriction>

   136		</complexContent>

   137	</complexType>

AXL-Serviceability APIs name the detail entry element as ErrorInfo and the type as ErrorInfoType. This type provides a structure with several accessor elements. The Version accessor contains the build version of the astsvc.dll. The Time accessor denotes the time when the error occurs. The ProcId accessor contains the process ID of the AXL-Serviceability APIs, and, in this case, it should be the same process as the inetinfo.exe (IIS process). The ThreadId accessor contains the thread ID that generates the fault. The ArrayOfCallInfo accessor contains an array of CallInfo elements.

The type for CallInfo specifies CallInfoType and also represents a structure. CallInfoType contains detailed information that describes where the error occurs in the codes. It also includes the returned error code of the function, and the parameter data. The CallInfoType design allows capturing as much information as needed, so it is easy and fast to track down and investigate a problem. Depending on the implementation of the operation, several CallInfo elements can exist in the array.

The following example shows a successful AXL-Serviceability APIs SOAP response message with HTTP headers:

Example 

HTTP/1.1 200 OK

Content-Type: text/xml; charset=utf-8

Content-Length: xxx


<?xml version="1.0" encoding="UTF-8" standalone="no" ?> 

<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

	xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

	xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">

	<SOAP-ENV:Body>

		<m:PerfmonOpenSessionResponse xmlns:m="http://schemas.cisco.com/ast/soap/">

			<SessionHandle>{01944B7E-183F-44C5-977A-F31E3AE59C4C}</SessionHandle> 

		</m:PerfmonOpenSessionResponse>

	</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

The following example shows a failed AXL-Serviceability APIs SOAP response message with HTTP headers:

Example 

HTTP/1.1 500 OK

Content-Type: text/xml; charset=utf-8

Content-Length: xxx


<?xml version="1.0" encoding="UTF-8" standalone="no" ?> 

<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

	xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

	xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">

	<SOAP-ENV:Body>

		<SOAP-ENV:Fault>

			<faultcode>SOAP-ENV:Server</faultcode> 

			<faultstring>Perfmon error occurs</faultstring> 

			<detail>

				<m:ErrorInfo xmlns:m="http://schemas.cisco.com/ast/soap/">

					<Version>3.2.0.2</Version> 

					<Time>07/16/2001 - 00:00:24</Time> 

					<ProcId>1200</ProcId> 

					<ThreadId>300</ThreadId> 

					<ArrayOfCallInfo SOAP-ENC:arrayType="m:CallInfoType[]">

						<CallInfo>

							<FileName>perfmon.cpp</FileName> 

							<LineNo>396</LineNo> 

							<ErrorCode>3221228473</ErrorCode> 

							<Function>AddCounter</Function> 

							<Params>\\nozomi\tcp\Bad Counter Name</Params> 

						</CallInfo>

					</ArrayOfCallInfo>

				</m:ErrorInfo>

			</detail>

		</SOAP-ENV:Fault>

	</SOAP-ENV:Body>

</SOAP-ENV:Envelope>


Perfmon error codes can be refered form Microsoft site.  Above error 3221228473 code refer 
to

0xC0000BB9			The specified counter could not be found.	PDH_CSTATUS_NO_COUNTER


http://msdn.microsoft.com/library/default.asp?url=/library/en-us/perfmon/base/pdh_error_co
des.asp

Namespaces

AXL-Serviceability APIs uses the following XML namespaces:

•xmlns:axl =http://www.cisco.com/AXL/API/1.0

This represents the namespace URI for SOAP envelope.

•xmlns:axl =http://www.cisco.com/AXL/API/1.0

This represents the namespace for the SOAP-recommended encoding rule that is based on XML Schema.

•xmlns:axl =http://www.cisco.com/AXL/API/1.0

This represents the namespace URL for AXL-Serviceability APIs data types as defined in the WSDL file.

Highly Isolated IIS Service

In this release, SOAP moves to highly isolated process that does not run as part of IIS thread. Faults on SOAP service, therefore, will not affect IIS process.

Components and Dependency

AXL-Serviceability APIs comprises the following module:

•Astsvc.dll provides the base implementation of SOAP Serviceability APIs.

•AstService.wsdl and RisPort.wsdl represents XML files that describe the web service.

•Real-time information server (Cisco RIS Data Collector).

AXL-Serviceability APIs Ports

This section explains in full details the interface of SOAP service built-in ports.

PerfmonPort

PerfmonPort comprises several operations that allow clients to do the following perfmon-related tasks:

•Collect perfmon counter data.

AXL-Serviceability APIs provides two ways to collect perfmon data: session-based and single-transaction.

•Get the list of all perfmon object and counters names that are installed in a particular host.

•Get the list of current instances of a perfmon object.

•Get textual description of a perfmon counter.

The 'perfport.dll' SOAP extension implements PerfmonPort. For a short overview of Perfmon Monitoring in Windows 2000, refer to following links:

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/perfmon/base/performance_objects_and_counters.asp

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/perfmon/base/performance_data.asp

PerfmonListCounter

This operation returns the list of Perfmon objects and counters in a particular host.

Request Format

The PerfmonListCounter operation takes a single parameter:

Parameter
Type
Derived From
Description

Host

xsd:string

xsd:string

Contains the name or address of the target server from which to get the counter information.


The following example shows a PerfmonListCounter request:

Example 

<?xml version="1.0" encoding="utf-8" ?> 

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

	xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

	xmlns:xsd="http://www.w3.org/2001/XMLSchema">

	<soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

		<q1:PerfmonListCounter xmlns:q1="http://schemas.cisco.com/ast/soap/">

			<Host xsi:type="xsd:string">nozomi</Host> 

		</q1:PerfmonListCounter>

	</soap:Body>

</soap:Envelope>

Response Format

PerfmonListCounter returns with information that describes the hierarchical structures of the Perfmon objects and counters. The body entry includes an ArrayOfObjectInfo element. The following fragments from the AXL-Serviceability APIs .WSDL file describe the types that this response uses: 


   106		<complexType name='ArrayOfObjectInfoType'>

   107			<complexContent>

   106				<restriction base='SOAP-ENC:Array'>

   109					<sequence>

   110						<element name='ObjectInfo'

   111							type='tns:ObjectInfoType' minOccurs='1' maxOccurs='unbounded'/>

   112					</sequence>

   113				</restriction>

   114			</complexContent>

115	</complexType>

The ArrayOfObjectInfo element comprises an array of ObjectInfo elements that have the following type: 


    56		<complexType name='ObjectInfoType'>

    57			<sequence>

    58				<element name='Name' type='tns:ObjectNameType'/>

    59				<element name='MultiInstance' type='xsd:boolean'/>

    60				<element name='ArrayOfCounter' type='tns:ArrayOfCounterType'/>

    61			</sequence>

62	</complexType>



    24		<simpleType name='ObjectNameType'>

    25			<restriction base='string'/>

    26		</simpleType>

The Name element, whose type is derived from string, describes the name of the object. MultiInstance element indicates whether the object has more than one instance. The ArrayOfCounter element acts as a container for an array of Counter elements that have the following types: 


    44		<complexType name='CounterType'>

    45			<sequence>

    46				<element name='Name' type='tns:CounterNameType'/>

    47			</sequence>	

48	</complexType>

    32		<simpleType name='CounterNameType'>

    33			<restriction base='string'/>

    34		</simpleType>

The Name element, whose type is derived from xsd:string, describes the name of the counter.

Example 

<?xml version="1.0" encoding="UTF-8" standalone="no" ?> 

<SOAP-ENV:Envelope

	SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

	xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 

	xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">

	<SOAP-ENV:Body>

		<m:PerfmonListCounterResponse xmlns:m="http://schemas.cisco.com/ast/soap/">

			<ArrayOfObjectInfo SOAP-ENC:arrayType="m:ObjectInfoType[]">

				<ObjectInfo>

					<Name>.NET CLR Memory</Name> 

					<MultiInstance>true</MultiInstance> 

					<ArrayOfCounter SOAP-ENC:arrayType="m:CounterType[]">

						<Counter>

							<Name># Gen 0 Collections</Name> 

						</Counter>

						<Counter>

							<Name># Gen 1 Collections</Name> 

						</Counter>

						...

					</ArrayOfCounter>

				</ObjectInfo>

				<ObjectInfo>

					<Name>.NET CLR LocksAndThreads</Name> 

					<MultiInstance>true</MultiInstance> 

					<ArrayOfCounter SOAP-ENC:arrayType="m:CounterType[]">

						<Counter>

							<Name>Total # of Contentions</Name> 

						</Counter>

						<Counter>

							<Name>Contention Rate / sec</Name> 

						</Counter>

						<Counter>

							<Name>Current Queue Length</Name> 

						</Counter>

						...

					</ArrayOfCounter>

				</ObjectInfo>

				...

			</ArrayOfObjectInfo>

		</m:PerfmonListCounterResponse>

	</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

PerfmonListInstance

This operation returns the list of instances of a perfmon object in a particular host. Instances of an object can dynamically come and go, and this operation returns the most recent list of instances.

Request Format

The PerfmonListIntance operation takes the following parameters:

Parameter
Type
Derived From
Description

Host

xsd:string

xsd:string

Contains the address of the target server on which the object resides.

Object

xsd:string

xsd:string

Contains the name of the object.


The following example shows the PerfmonListInstance request with nozomi host and Process object parameters.

Example 

<?xml version="1.0" encoding="utf-8" ?> 

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

	xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

	xmlns:xsd="http://www.w3.org/2001/XMLSchema">

	<soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

		<q1:PerfmonListInstance xmlns:q1="http://schemas.cisco.com/ast/soap/">

			<Host xsi:type="xsd:string">nozomi</Host> 

			<Object xsi:type="xsd:string">Process</Object> 

		</q1:PerfmonListInstance>

	</soap:Body>

</soap:Envelope>

Response Format

PerfmonListInstance returns an element named ArrayOfInstance. The type for this element specifies ArrayOfInstanceType, which is an array of Instance elements. The following fragments from AXL-Serviceability APIs .WSDL file explain the types that this response uses: 


    84	<complexType name='ArrayOfInstanceType'>

    85		<complexContent>

    86			<restriction base='SOAP-ENC:Array'>

    87				<sequence>

    88					<element name='Instance'

    89						type='tns:InstanceType' minOccurs='0' maxOccurs='unbounded'/>

    90				</sequence>

    91			</restriction>

    92		</complexContent>

93	</complexType>

Note ArrayOfInstanceType can have 0 (zero) Instance element, in which case the requested object is not of a multi-instance object. 


    50	<complexType name='InstanceType'>

    51		<sequence>

    52			<element name='Name' type='tns:InstanceNameType'/>

    53		</sequence>	

54	</complexType>

The type for Instance element specifies InstanceType. It represents a structure with a single-element member: Name. 


    28	<simpleType name='InstanceNameType'>

    29		<restriction base='string'/>

    30	</simpleType>

The Name element, whose type is InstanceNameType, which is derived from xsd:string, contains the name of the instance of the requested object.

The following example shows the response to the request in the previous example:

Example 

<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

	xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

	xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">

	<SOAP-ENV:Body>

		<m:PerfmonListInstanceResponse xmlns:m="http://schemas.cisco.com/ast/soap/">

			<ArrayOfInstance SOAP-ENC:arrayType="m:InstanceType[]">

				<Instance>

					<Name>Idle</Name> 

				</Instance>

				<Instance>

					<Name>System</Name> 

				</Instance>

				<Instance>

					<Name>SMSS</Name> 

				</Instance>

				<Instance>

					<Name>CSRSS</Name> 

				</Instance>

				<Instance>

					<Name>WINLOGON</Name> 

				</Instance>

				<Instance>

					<Name>SERVICES</Name> 

				</Instance>

				<Instance>

					<Name>_Total</Name> 

				</Instance>

				...

			</ArrayOfInstance>

		</m:PerfmonListInstanceResponse>

	</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

PerfmonQueryCounterDescription

This operation returns the help text of a particular counter.

Request Format

PerfmonQueryCounterDescription takes the following parameter:

Parameter
Type
Derived From
Description

Counter

CounterNameType

xsd:string

Contains the name of the counter.


The following example shows the PerfmonQueryCounterDescription request:

Example 

<?xml version="1.0" encoding="utf-8" ?> 

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

	xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

	xmlns:xsd="http://www.w3.org/2001/XMLSchema">

	<soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

		<q1:PerfmonQueryCounterDescription

			xmlns:q1="http://schemas.cisco.com/ast/soap/">

			<Counter xsi:type="xsd:string">\\nozomi\Server\Files Open</Counter> 

		</q1:PerfmonQueryCounterDescription>

	</soap:Body>

</soap:Envelope>

Response Format

PerfmonQueryCounterDescription returns an element named HelpText that is of the xsd:string type. It contains the help text of the requested counter.

The following example shows the response to the request in the previous example.

Example 

<?xml version="1.0" encoding="UTF-8" standalone="no" ?> 

<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

	xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

	xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">

	<SOAP-ENV:Body>

		<m:PerfmonQueryCounterDescriptionResponse

			xmlns:m="http://schemas.cisco.com/ast/soap/">

			<HelpText>The number of files currently opened in the server. Indicates 
current server 

activity.

</HelpText> 

		</m:PerfmonQueryCounterDescriptionResponse>

	</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

PerfmonOpenSession

Client program submits this operation to get a session handle from the AXL-Serviceability APIs. The client needs a session handle to do the session-based perfmon counter data collection. The session handle represents a universally unique identifier that gets used only once. This guarantees that no duplicate handles exist. AXL-Serviceability APIs keep the opened handles in the cache. If no activity occurs on a handle for the last 25 hours, AXL-Serviceability APIs remove the handle and render it invalid.

In a session-based perfmon data collection, use the following related operations:

•PerfmonOpenSession

•PerfmonAddCounter

•PerfmonRemoveCounter

•PerfmonCollectSessionData

•PerfmonCloseSession

After a client gets a session handle, it normally proceeds to submit the PerfmonAddCounter operation call and then follows with the PerfmonCollectSessionData operation. PerfmonCollectSessionData specifies the main operation that does the collection of the perfmon data for the clients. When the client no longer needs the session handle, it should submit PerfmonCloseSession, so the AXL-Serviceability APIs can remove the handle from cache. Clients can dynamically add new counters to the session handle and remove some from it while the session handle is still open. The PerfmonRemoveCounter operation does counter removal.

Request Format

The PerfmonOpenSession operation takes no parameter.

The following example shows the PerfmonOpenSession request:

Example 

<?xml version="1.0" encoding="utf-8" ?> 

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

	xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

	xmlns:xsd="http://www.w3.org/2001/XMLSchema">

		<soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

			<q1:PerfmonOpenSession xmlns:q1="http://schemas.cisco.com/ast/soap/" /> 

		</soap:Body>

</soap:Envelope>

Response Format

PerfmonOpenSession returns a single element that is named SessionHandle. Its type specifies SessionHandleType, which is derived from xsd:string, and it contains the guide for the session handle.

The following example shows the PerfmonOpenSession response:

Example 

<?xml version="1.0" encoding="UTF-8" standalone="no" ?> 

<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

	xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

	xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">

	<SOAP-ENV:Body>

		<m:PerfmonOpenSessionResponse xmlns:m="http://schemas.cisco.com/ast/soap/">

			<SessionHandle>{01944B7E-183F-44C5-977A-F31E3AE59C4C}</SessionHandle> 

		</m:PerfmonOpenSessionResponse>

	</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

PerfmonAddCounter

This operation adds an array of counters to a session handle.

Request Format

PerfmonAddCounter takes the following parameters:

Parameter
Type
Derived From
Description

SessionHandle

SessionHandleType

xsd:string

Contains the session handle that the PerfmonOpenSession operation previously opened

ArrayOfCounter

ArrayOfCounterType

an array of Counter elements

Contains the name of the counter to be added to the session handle


The following fragments from AXL-Serviceability APIs describe the types that this request uses: 


    95	<complexType name='ArrayOfCounterType'>

    96		<complexContent>

    97			<restriction base='SOAP-ENC:Array'>

    98				<sequence>

    99					<element name='Counter'

   100						type='tns:CounterType' minOccurs='1' maxOccurs='unbounded'/>

   101				</sequence>

   102			</restriction>

   103		</complexContent>

104	</complexType>

Note ArrayOfCounterType expects at least one Counter element in the array. 


    44	<complexType name='CounterType'>

    45		<sequence>

    46			<element name='Name' type='tns:CounterNameType'/>

    47		</sequence>	

48	</complexType>

CounterType represents a structure, and it has a single element member: Name. 


    32	<simpleType name='CounterNameType'>

    33		<restriction base='string'/>

34	</simpleType>

The Name element that is of string-derived type contains the name of the counter.

The following example shows the PerfmonAddCounter request with two counters. This example uses a single-reference accessor.

Example 

<?xml version="1.0" encoding="utf-8" ?> 

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

	xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

	xmlns:tns="http://tempuri.org/"

	xmlns:types="http://tempuri.org/encodedTypes"

	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

	xmlns:xsd="http://www.w3.org/2001/XMLSchema">

	<soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

		<q1:PerfmonAddCounter xmlns:q1="http://schemas.cisco.com/ast/soap/">

			<SessionHandle xsi:type="xsd:string">

				{1A490F1E-D82C-403F-9CF0-C4D4ABD6FF3E}

			</SessionHandle> 

			<ArrayOfCounter soapenc:arrayType="q1:CounterType[2]"> 

				<Counter>

					<Name>\\nozomi\process(inetinfo)\handle count</Name>

				</Counter>

				<Counter>

					<Name>\\nozomi\process(csrss)\handle count</Name>

				</Counter>

			</ArrayOfCounter>

</q1:PerfmonAddCounter">

	</soap:Body>

</soap:Envelope

The following shows an example of the PerfmonAddCounter request with three counters in the ArrayOfCounter parameter.

Note This example uses multi-reference accessors.

Example 

<?xml version="1.0" encoding="utf-8" ?> 

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

	xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

	xmlns:xsd="http://www.w3.org/2001/XMLSchema">

	<soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

		<q1:PerfmonAddCounter xmlns:q1="http://schemas.cisco.com/ast/soap/">

			<SessionHandle xsi:type="xsd:string">

				{1A490F1E-D82C-403F-9CF0-C4D4ABD6FF3E}

			</SessionHandle> 

			<ArrayOfCounter href="#id1"/> 

		</q1:PerfmonAddCounter>

		<soapenc:Array id="id1"

			xmlns:q2="http://schemas.cisco.com/ast/soap/"

			soapenc:arrayType="q2:CounterType[3]">

			<Item href="#id2" /> 

			<Item href="#id3" /> 

			<Item href="#id4" /> 

		</soapenc:Array>

		<q3:CounterType id="id2" xsi:type="q3:CounterType"

			xmlns:q3="http://schemas.cisco.com/ast/soap/">

			<Name xsi:type="xsd:string">\\nozomi\tcp\Segments/sec</Name> 

		</q3:CounterType>

		<q4:CounterType id="id3" xsi:type="q4:CounterType"

			xmlns:q4="http://schemas.cisco.com/ast/soap/">

			<Name xsi:type="xsd:string">\\nozomi\tcp\Connections Reset</Name> 

		</q4:CounterType>

		<q5:CounterType id="id4" xsi:type="q5:CounterType"

			xmlns:q5="http://schemas.cisco.com/ast/soap/">

			<Name xsi:type="xsd:string">\\nozomi\tcp\Connections Active</Name> 

		</q5:CounterType>

	</soap:Body>

</soap:Envelope>

Response Format

The following example shows that the PerfmonAddCounter returns no output:

Example 

<?xml version="1.0" encoding="UTF-8" standalone="no" ?> 

<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

	xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

	xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">

	<SOAP-ENV:Body>

		<m:PerfmonAddCounterResponse xmlns:m="http://schemas.cisco.com/ast/soap/"/> 

	</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

If PefmonAddCounter fails to add one or more counters that are specified in the request, AXL-Serviceability APIs reply with a fault response. Some counters that are specified in the request may get successfully added, while others failed to be added.

In this case, AXL-Serviceability APIs reply with a fault. The Params element of CallInfo element specifies each failed counter name. Client programs can conclude that counter names, which are specified in the request but do not appear in the fault message, actually get added successfully to the query handle.

Example 

<?xml version="1.0" encoding="UTF-8" standalone="no" ?> 

<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

	xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

	xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">

	<SOAP-ENV:Body>

		<SOAP-ENV:Fault>

			<faultcode>SOAP-ENV:Server</faultcode> 

			<faultstring>Perfmon error occurs</faultstring> 

			<detail>

				<m:ErrorInfo xmlns:m="http://schemas.cisco.com/ast/soap/">

					<Version>3.2.0.1</Version> 

					<Time>07/15/2001 - 00:00:24</Time> 

					<ProcId>1212</ProcId> 

					<ThreadId>340</ThreadId> 

					<ArrayOfCallInfo SOAP-ENC:arrayType="m:CallInfoType[]">

						<CallInfo>

							<FileName>perfmon.cpp</FileName> 

							<LineNo>396</LineNo> 

							<ErrorCode>3221228473</ErrorCode> 

							<Function>AddCounter</Function> 

							<Params>\\nozomi\tcp\Invalid Counter Name 1</Params> 

						</CallInfo>

						<CallInfo>

							<FileName>perfmon.cpp</FileName> 

							<LineNo>396</LineNo> 

							<ErrorCode>3221228473</ErrorCode> 

							<Function>AddCounter</Function> 

							<Params>\\nozomi\tcp\Invalid Counter Name 2</Params> 

						</CallInfo>

					</ArrayOfCallInfo>

				</m:ErrorInfo>

			</detail>

		</SOAP-ENV:Fault>

	</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

PerfmonRemoveCounter

This operation removes an array of counters from a session handle.

Request Format

PerfmonRemoveCounter takes the following parameters:

Parameter
Type
Derived From
Description

SessionHandle

SessionHandleType

xsd:string

Contains the session handle that the PerfmonOpenSession operation previously opened

ArrayOfCounter

ArrayOfCounterType

an array of Counter elements

Contains the name of the counter to be added to the session handle


The following example shows a PerfmonRemoveCounter request with three counters in the ArrayOfCounter parameter.

Note This example uses single-reference accessor style.

Example 

<?xml version="1.0" encoding="utf-8" ?> 

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

	xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

	xmlns:tns="http://tempuri.org/"

	xmlns:types="http://tempuri.org/encodedTypes"

	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

	xmlns:xsd="http://www.w3.org/2001/XMLSchema">

	<soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

		<q1:PerfmonRemoveCounter xmlns:q1="http://schemas.cisco.com/ast/soap/">

			<SessionHandle xsi:type="xsd:string">

				{1A490F1E-D82C-403F-9CF0-C4D4ABD6FF3E}

			</SessionHandle> 

			<ArrayOfCounter soapenc:arrayType="q1:CounterType[2]"> 

				<Counter>

					<Name>\\nozomi\process(inetinfo)\handle count</Name>

				</Counter>

				<Counter>

					<Name>\\nozomi\process(csrss)\handle count</Name>

				</Counter>

<Counter>

					<Name>\\nozomi\process(regsvc)\handle count</Name>

				</Counter>


			</ArrayOfCounter>

</q1:PerfmonRemoveCounter">

	</soap:Body>

</soap:Envelope

The following example shows a PerfmonRemoveCounter that uses multi reference accessors.

Example 


<?xml version="1.0" encoding="utf-8" ?> 

<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

	xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

	xmlns:xsd="http://www.w3.org/2001/XMLSchema">

	<soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

		<q1:PerfmonRemoveCounter xmlns:q1="http://schemas.cisco.com/ast/soap/">

			<SessionHandle xsi:type="xsd:string">

				{1A490F1E-D82C-403F-9CF0-C4D4ABD6FF3E}

			</SessionHandle> 

			<ArrayOfCounter href="#id1" /> 

		</q1:PerfmonRemoveCounter>

		<soapenc:Array id="id1" xmlns:q2="http://schemas.cisco.com/ast/soap/"

			soapenc:arrayType="q2:CounterType[3]">

			<Item href="#id2" /> 

			<Item href="#id3" /> 

			<Item href="#id4" /> 

		</soapenc:Array>

		<q3:CounterType id="id2" xsi:type="q3:CounterType"

			xmlns:q3="http://schemas.cisco.com/ast/soap/">

			<Name xsi:type="xsd:string">\\nozomi\tcp\Segments/sec</Name> 

		</q3:CounterType>

		<q4:CounterType id="id3" xsi:type="q4:CounterType"

			xmlns:q4="http://schemas.cisco.com/ast/soap/">

			<Name xsi:type="xsd:string">\\nozomi\tcp\Connections Reset</Name> 

		</q4:CounterType>

		<q5:CounterType id="id4" xsi:type="q5:CounterType"

			xmlns:q5="http://schemas.cisco.com/ast/soap/">

			<Name xsi:type="xsd:string">\\nozomi\tcp\Connections Active</Name> 

		</q5:CounterType>

	</soap:Body>

</soap:Envelope>

Response Format

PerfmonRemoveCounter returns no data in the response as shown by the following example:

Example 

<?xml version="1.0" encoding="UTF-8" standalone="no" ?> 

<SOAP-ENV:Envelope SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"

	xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"

	xmlns:SOAP-ENC="http://schemas.xmlsoap.org/soap/encoding/">

<SOAP-ENV:Body>

	<m:PerfmonRemoveCounterResponse xmlns:m="http://schemas.cisco.com/ast/soap/"/> 

</SOAP-ENV:Body>

</SOAP-ENV:Envelope>

If PefmonRemoveCounter fails to remove one or more counters that the request specifies, AXL-Serviceability APIs reply with a fault response with similar semantics as PerfmonAddCounter. Some of the counters that are specified in the request get successfully removed, while some others failed to be removed. In this case, AXL-Serviceability APIs reply with a fault. The Params element of CallInfo element specifies each failed counter name. Client programs can conclude that counter names, which are specified in the request but do not appear in the fault message, actually get removed successfully from the query handle.

PerfmonCollectSessionData

This operation collects the perfmon data for all counters that have been added to the query handle.

Request Format

PerfmonCollectSessionData takes the following parameter:

Parameter
Type
Derived From
Description

SessionHandle

SessionHandleType

xsd:string

Contains the session handle that the PerfmonOpenSession operation previously opened


The following example shows a PerfmonCollectSessionData request:

Example 

<?xml version="1.0" encoding="utf-8" ?> 

	<soap:Envelope xmlns:soap="http://schemas.xmlsoap.org/soap/envelope/"

	xmlns:soapenc="http://schemas.xmlsoap.org/soap/encoding/"

	xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"

	xmlns:xsd="http://www.w3.org/2001/XMLSchema">

	<soap:Body soap:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">

		<q1:PerfmonCollectSessionData xmlns:q1="http://schemas.cisco.com/ast/soap/">

			<SessionHandle xsi:type="xsd:string">

				{FB343D6D-AA6E-4EDB-9CFA-63A5A3ED6405}

			</SessionHandle> 

		</q1:PerfmonCollectSessionData>

	</soap:Body>

</soap:Envelope>

Response Format

The PerfmonCollectSessionData operation returns the ArrayOfCounterInfo element that contains the value and status of all counters that were previously added to the session handle. The type for ArrayOfCounterInfo element specifies ArrayOfCounterInfoType, which represents an array of CounterInfo elements.

The following fragments from AXL-Serviceability APIs .WSDL show the types that this response uses: 

   117	<complexType name='ArrayOfCounterInfoType'>

   118		<complexContent>

   119			<restriction base='SOAP-ENC:Array'>

   120				<sequence>

   121					<element name='CounterInfo'

   122						type='tns:CounterInfoType' minOccurs='1' maxOccurs='unbounded'/>

   123				</sequence>

   124			</restriction>

   125		</complexContent>

126