1.3 Overview

  • Article

The Microsoft SQL Server Analysis Services protocol provides methods for a client to communicate with, and perform operations on, an analysis server. The Analysis Services protocol is based on SOAP and XML for Analysis (XMLA) [XMLA] and supports TCP/IP as an underlying transport mechanism in addition to HTTP/HTTPS.

The base communication details of this protocol are specified in [MS-SSAS]: SQL Server Analysis Services Protocol.

The SQL Server Analysis Services Tabular protocol is an extension of the SQL Server Analysis Services protocol. This extension protocol provides additional protocol messages for Tabular databases that are at compatibility level 1200 or higher.

Note   For the purposes of this document, "Tabular database" refers only to a Tabular database that is at compatibility level 1200 or higher.

A Tabular database is administered by executing a set of commands that include, but are not limited to, the following:

  • XMLA-based command extensions allow an application to perform operations such as the following:

    • Create an object.

    • Alter an object.

    • Delete an object.

    • Refresh the data in an object.

  • JavaScript Object Notation (JSON)-based [RFC7159] commands can perform essentially the same operations. The JSON commands are sent as the string content of the Statement element in an XMLA command.

  • A client application can obtain the metadata of a Tabular database by using a set of DISCOVER requests. For more information about DISCOVER requests, see [MS-SSAS] and [XMLA]. The metadata that are returned by these Discover requests are made up of the same objects and properties that are managed by the Create, Alter, Delete, Refresh, and so on commands.

Section 2.2.5 defines each of the metadata objects and their properties. Section 3.1.5 defines each of the commands and references the common objects and properties that are defined in section 2.2.5.

Notes on the objects, their properties, and the commands include the following:

  • The JSON APIs use a different naming convention than the XMLA APIs. The JSON convention uses camel casing for names. For example:

    • "Name" would be "name".

    • "DefaultMode" would be "defaultMode".

      Therefore, the case of the properties and objects can be ignored in the text of this document.

  • Some of the properties are read-only and cannot be set explicitly by any of the commands. These properties appear only in the Discover operations for these objects. For example, the ModifiedTime and RefreshedTime properties are implicitly updated by different commands and cannot be explicitly changed.

  • Some properties are documented as ID-based object references. These properties represent links to other objects in the object tree. For example, the SortByColumnID property represents a reference to another column in the same table. The actual representation of object references is different between the JSON and XMLA commands and is described in the corresponding section.

  • Some properties are documented as enumerations. Their descriptions contain numeric values and strings for each accepted value. For example, SummarizeBy shows "Default (1)", "None (2)", "Sum (3)", and so on. The XMLA commands and the TMSCHEMA Discover operations use the integer values, and the JSON commands use the string values.