I have for the last couple of weeks, on and off, been attempting to connect to SAP BW using the Microsoft ADOMD.Net provider. In theory this should be possible as Microsoft and SAP both claim to be Xmla 1.1 compliant as defined by the Xmla council specifications. My efforts to find technical information regarding the SAP implementation of Xmla have had emails bouncing between The USA and Germany with varying levels of surpise and incredulity that I should attempt such a feat.
This would be quite sad if I had not experienced pretty much the same problem 2 years ago with Hyperion Essbase, an excercise that I eventually gave up on.
Xmla was heralded as the way forward for Olap about 5 years ago. Microsoft, Hyperion, SAP and SAS Institute all put resources into the Xmla council along a number of other members most notably Simba. One of my old colleagues at SAS represented them on the council for a year or so and was full of excitement at the opportunity of getting involved in the delivery of a genuine cross-companystandard.
In truth the council has failed.
Microsoft, SAS, SAP and Hyperion (Essbase) have all implemented an Xmla based solution but, with the possible exception of the Simba O2X driver that can access Microsoft Analysis Services and SAP BW (technology from which was used to deliver Microsoft’s SQL Server to SAP capability), I have seen no evidence of cross platform interoperability.
The Xmla council site www.xmla.org has been taken over by Simba, some time after the last working threads on the site died out about 2 years ago. The industry is left with 4 (or maybe 5 if you count Mondrian) independent and incompatible implementations of Xmla.
Is Xmla is dead? Does anyone else care?
Have you just been talking to Nick Goodman and Julian Hyde? I was having exactly the same conversation with them over the weekend…
No, although I would be interested to hear their opinions. The work on SAP was prompted by a sales enquiry from a company that specialises in data extract from SAP.
The previous attempt with Hyperion was our own initiative attempting to increase the potential scope of our products. 2 years ago the Xmla council members were still, slightly, interested in the idea of interoperability and we got quite a bit of encouragement and feedback on our efforts. The connection to Essbase eventually failed when we discovered that they had implemented dimension level numbering in reverse sequence when compared to the Xmla specification (i.e. the farthest leaf is level zero in Essbase). This is standard level numbering for the Essbase product but precludes an Xmla consumer from working as the enumeration of members at the root of a hierarchy cannot be correctly performed.
I have to say that although Microsoft have been accused of "spoiling" tactics by extending the Xmla specification to cater for new functionality in Analysis Services, they appear to be the only vendor that has implemented the core specification correctly (apologies to Julian if Mondrian has also implemented the spec – I have not had time to work with Mondrian yet).
My suspicion is that the provider problems could be very simply fixed if the companies involved made the effort. The focal point for demonstrating interoperability would probably have to be ADOMD.NET. This may in itself create a problem for some of the parties but if you look at newsgroups for any of the Olap vendors you will consistently find requests for ADOMD.Net support.
http://andrewwiles.spaces.live.com/blog/cns!43141EE7B38A8A7A!199.entry?ccr=5495#comment