Once you've set up the data sources, you need to create in Microsoft IIS a virtual directory for the XMLA Provider. The virtual directory lets IIS access a specific folder on the server through HTTP, which is how we'll connect to the XMLA Provider for this example. The easiest way to set up a virtual directory is to open the IIS Manager, select the server on which you want to create the virtual directory, right-click the Web site you want to use for the XMLA Provider, and select New, Virtual Directory. The Virtual Directory Creation Wizard then guides you through the rest of the process. The first step is to name the virtual directory; XMLA is usually a good choice. Next, you select the content directory, which lets IIS map files in that directory to HTTP requests. For the XMLA Provider, the content directory is the path to the Msxisapi.dll file installed in the C:\Program Files\Microsoft XML For Analysis SDK\Isapi folder (the default location) during setup. Then, set the access permissions for this folder by selecting the Read, Run Scripts, and Execute check boxes, and finish the wizard.
After you configure the virtual directory, you set access permissions on it. In IIS Manager, right-click the virtual directory you just created and select Properties. In the Properties window, select the Directory Security tab and configure the security permissions. For learning about how XMLA works, the default permissions setting (anonymous access) is sufficient.
If you're configuring the XMLA Provider on Windows Server 2003, you must take some additional steps to enable the protocol on the server. The XMLA Help topic "Enable the XML for Analysis Web Service Extension on Windows Server 2003" tells you how to get the XMLA Provider to work on Windows Server 2003.
Using XMLA: Discover and Execute
One of XMLA's greatest strengths is that it simplifies data retrieval compared to working directly with OLE DB for OLAP. The XMLA Provider has only two methods: Discover and Execute. You use the Discover method to retrieve metadata that describes the services a specific XMLA Provider supports. You use the Execute method to run queries against the Analysis Services database and return data from those queries.
Discover. Discover is a flexible method that a client can use repeatedly to build a picture of the configuration and capabilities of the data provider. So, for example, a client might first request the list of data sources that are available on a particular server, then inquire about the properties and schemas those data sources support so that a developer can properly write queries against the data source. Let's look at the arguments you send to Discover, then walk through some examples that show how to use the method.
Listing 1's XML code shows a SOAP call to retrieve a list of data sources from the server. The first parameter, RequestType, determines the type of information that Discover will return about the provider. The available types let you get a list of the data sources available on the server (DISCOVER_DATASOURCES), a list of properties about a specific data source on the server (DISCOVER_PROPERTIES), a list of supported request types (DISCOVER_SCHEMA_ROWSETS), a list of the keywords the provider supports (DISCOVER_KEYWORDS), and a schema rowset constant to retrieve the schema of a provider-defined data type. Table 1 lists the RequestType parameters.
The second parameter, Restrictions, lets you put conditions on the data that Discover returns. The RequestType in the call to the Discover method determines the fields that the Restrictions parameter can filter on. Table 2 describes the fields that the various schema types in XMLA can use to restrict returned information. If you want to return all the data available for a given RequestType, leave the Restrictions parameter empty.
The Properties parameter provides additional information about the request that the other parameters don't contain. For example, Timeout specifies the number of seconds the provider will wait for the Discover request to succeed before returning a timeout message. Table 3 lists some common XMLA Provider for Analysis Services properties you're likely to use. You can specify properties in any order. If you don't specify a Properties value, Discover uses the appropriate default value.
The Discover method call in Listing 1 returns results in XML. The settings you give the parameters RequestType, Restrictions, and Properties determine the contents of Result, which is an output parameter. In Listing 1, note that I set RequestType to DISCOVER_DATASOURCES and Restrictions and Properties to null so that Discover returns the entire list of data sources in the default format (tabular format in this case). To call a SOAP method, you have to send the SOAP envelope to the Web service through HTTP. I've provided a sample Web application, which you can download at InstantDoc ID 44006. The sample application shows exactly how you might send a SOAP envelope in JScript by using the Microsoft.XMLHTTP object in the SubmitForm() method. The sample also shows you more examples of how to use the Discover method and how to use the data-source information retrieved from the first call to Discover to populate the next call to Discover.
Execute. After you use Discover to determine the metadata for the data source, you can use that metadata to retrieve data. For data retrieval, XMLA provides the Execute method. The method call for Execute looks like this:
Execute (Command,Properties,
Results)
As Listing 2's SOAP call to Execute shows, the Command parameter contains in a <Statement> tag the MDX statement you want to run against your OLAP server. Similar to the Properties parameter in the Discover method, the Properties parameter in Execute provides additional information that controls the data the method returns or the connection to the data source. You must include the Properties tag in your Execute method call, but the tag can be empty if you want to use the defaults for your request. The Results parameter represents the SOAP document the server returns. Results' contents are determined by the other two parameters.
Listing 2's code shows an example of a call to Execute that contains an MDX SELECT statement. You call the Execute method the same way you call the Discover method, by sending the SOAP envelope to the Web service through HTTP. As with any SOAP request, the entire message is contained in a SOAP envelope. Within the SOAP envelope, the SOAP body contains the guts of the Execute method call, starting with the Command parameter. The Command parameter contains the MDX query that will run on the server. The Properties parameter comes next, containing the PropertyList parameter that holds each of the properties the XML code will use for the Execute request. In this case, the Execute call specifies in the PropertyList parameter DataSourceInfo, Catalog, Format, and AxisFormat. You can retrieve all this information in a call to Discover like the one that Listing 1 shows. Finally, you close the body and envelope, and the request is ready to send via HTTP to the XMLA Provider.
Prev. page
1
[2]
3
next page 
