feristhia / xmla4js

Automatically exported from code.google.com/p/xmla4js
0 stars 0 forks source link

HTTP 500 when using Xmla4js against msmdpump.dll #7

Closed GoogleCodeExporter closed 9 years ago

GoogleCodeExporter commented 9 years ago
Reported by mic.cross:

my Flex/Actionscript app is talking with XMLA quite happily with local SS2008 
cube through msmdpump.dll. Just found xmla4js and am excited to use it to 
convert app to HTML5/Javascript.

In the xmla4js Sample:Pivot Table URL I put 
"http://localhost/olap/msmdpump.dll" and am getting that generic 500 error. 
Inspecting the xmla4js SOAP request it looks like the actionscript request 
other than my AS request has a restriction:

<SOAP-ENV:Envelope 
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/" 
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/">
  <SOAP-ENV:Body>
    <Discover xmlns="urn:schemas-microsoft-com:xml-analysis">
      <RequestType>MDSCHEMA_CUBES</RequestType>
      <Restrictions>
        <RestrictionList>
          <CATALOG_NAME>Adventure Works DW</CATALOG_NAME>
        </RestrictionList>
      </Restrictions>
      <Properties>
        <PropertyList>
          <DataSourceInfo>http://localhost/olap/msmdpump.dll</DataSourceInfo>
          <CATALOG>Adventure Works DW</CATALOG>
          <Format>Tabular</Format>
        </PropertyList>
      </Properties>
    </Discover>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

and xmla4js does not:

<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
 <SOAP-ENV:Body>
  <Discover xmlns="urn:schemas-microsoft-com:xml-analysis" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">    <RequestType>DISCOVER_DATASOURCES</RequestType>
   <Restrictions> </Restrictions>
   <Properties>
    <PropertyList>
     <DataSourceInfo>http://localhost/olap/msmdpump.dll</DataSourceInfo>
     <Catalog>Adventure Works DW</Catalog>
    </PropertyList>
   </Properties>
  </Discover>
 </SOAP-ENV:Body>
</SOAP-ENV:Envelope> 

(using  

xmla.setOptions({
                    url: "http://localhost/olap/msmdpump.dll",
                    async: true,
                    properties: {
                    DataSourceInfo: "http://localhost/olap/msmdpump.dll",
                    Catalog: "Adventure Works DW"

    }
                    }); 

            }
)

Original issue reported on code.google.com by roland.bouman on 2 Dec 2011 at 1:15

GoogleCodeExporter commented 9 years ago
I think this is an IIS issue at the moment. I am now sending:

<?xml version="1.0" encoding="utf-8"?>
<SOAP-ENV:Envelope xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/" 
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
  <SOAP-ENV:Body>
    <Discover xmlns="urn:schemas-microsoft-com:xml-analysis" SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/">
      <RequestType>DISCOVER_DATASOURCES</RequestType>
      <Restrictions> </Restrictions>
      <Properties>
        <PropertyList>
          <DataSourceInfo>http://localhost/olap/msmdpump.dll</DataSourceInfo>
          <Catalog>Adventure Works DW</Catalog>
        </PropertyList>
      </Properties>
    </Discover>
  </SOAP-ENV:Body>
</SOAP-ENV:Envelope>

from the xmlajs4:Pivot Table Example and getting the same HTTP:500 error from 
IIS. However if I grab that same xml and paste it into a New Query in 
SqlServer2008 SSAS and run it, I get the correct response:

<row>
            <DataSourceName>TBC</DataSourceName>
            <DataSourceDescription />
            <URL />
            <DataSourceInfo />
            <ProviderName>Microsoft Analysis Services</ProviderName>
            <ProviderType>MDP</ProviderType>
            <ProviderType>TDP</ProviderType>
            <ProviderType>DMP</ProviderType>
            <AuthenticationMode>Authenticated</AuthenticationMode>
          </row>

I find the security around IIS totally incomprehensible and am going to beat 
that up for a while :-)

Original comment by crzymnm...@comcast.net on 8 Dec 2011 at 5:07

GoogleCodeExporter commented 9 years ago
Turned out to be cross-domain issue, nothing specific to this particular setup

Original comment by roland.bouman on 9 Dec 2011 at 11:11