A.0 WSAPI 1.1

The interface point for WSAPI 1.1 is:

http://MOServername:WebServicePort/wsapi/services/Moswsapi_1_1 

The WSDL can be viewed at:

http://MOServername:WebServicePort/wsapi/services/Moswsapi_1_1?wsdl

The Web services reference client has been updated to automatically include the 1.1 service calls when a 1.1 connection point is accessed.

WSAPI 1.1 extends WSAPI 1.0 with three new service calls designed to facilitate the management of large services models through Web services, as described in Table A-1.

Table A-1 New Service Calls

Name

Description

createElements(session:WsSession, transactionBlockSize:int, data:ElementCreateData[]):ElementsWriteResponse

Creates new elements on the Operations Center server.

updateElements(session:WsSession, , transactionBlockSize:int, data:ElementUpdateData[]):ElementsWriteResponse

Updates elements on the Operations Center server.

removeElement(session:WsSession, , transactionBlockSize:int, elementDName:string[]):void

Removes elements from the Operations Center server.

These new service calls can dramatically improve the performance of large write operations by:

  • Reducing the amount of communications overhead required when performing multiple write operations. In addition to allowing multiple write operations in a single Web service call, the returned ElementsWriteResponse does not include copies of the resulting elements.

  • Reducing the number of round-trip operations to the Operations Center persistent store (also called the Config Store) by using the transactionBlockSize argument to wrap these operations in transactions. The transactionBlockSize argument specifies the number of element creates/updates/deletes to wrap in a single transaction.

    Specifying a transactionBlockSize of 0 disables the wrapping transaction and degrades performance. A transactionBlockSize of less than 0 (such as ‑1) wraps all write operations in the service call in a single transaction, potentially improving performance.

Although increasing the transactionBlockSize improves the performance of the write operations, it also incurs additional risk in the event of an error. When an error occurs, all write operations in the transaction are rolled back from the persistent store. However, this rollback does not currently impact the in‑memory element model. Elements that were created in a rolled-back transaction still appear in the elements tree and must be manually removed, or removed when the server is restarted.