With SP1 SQL Server Reporting Services 2005 will now also accept SAP BW as a data source. The connection will be established without any custom code in SAP BW (and therefor no need of installation assistance by SAP Administration) using XML/A (XML for Analysis, XML standard for Online Analytical Processing [OLAP] using standard Internet protocols), which is an established standard as described at the website of the organization (http://www.xmla.org/, http://www.xmlforanalysis.com/).
Microsoft provides a really good white paper, which includes a step-by-step guidance and also describes some prerequisites and basics. There is also a video, which visualizes the described steps of the white paper.
The whole documentation and the connect to SAP BW is real good work, but some things regarding "real life" is not included in the white paper or is not mentioned as clearly as needed - in my personal opinion.
Basic Information
The SDN at http://www.sdn.sap.com/ (SAP Developers Network - do not hesitate to surf there, you will not get infected... 
) provides a real good basic information as pdf-file for XML for Analysis from the SAP point of view.
SAP System Prerequisites
If you are authorized to connect to the SAP system and would like to test if the XMLA SOAP Services is up and running please use transaction SICF (Service Maintenance) to check this - as described in the above mentioned pdf-file on page 14. And if SAP Administration does not know how to verify this hand them over the pdf-file...
You will also be able to discover the service url using the transaction SE37 and the function module RSBB_URL_PREFIX_GET as desribed on page 13.
Patch Level
As described in the white paper, there is a certain patch level required to assure a working XMLA-Connect.
- Support Package 30 for SAP BW 3.0B
- Support Package 24 for SAP BW 3.1
- Support Package 16 for SAP BW 3.5
- Support Package 6 for SAP NetWeaver 2004s (BW 7.0)
Other patch levels will also work BUT... will not support real interesting things like selections via variables for example. But I would suggest that you COULD use Reporting Services to do a real smart master data reporting for example - the best way to convince the stakeholder of the SAP System that doing the patching will be really worth the work.
You will not be able to convince the SAP Administration to do the patching required for Reporting Services, because implementing a Patch is not as "easy" as in the SQL Server World, doing a patch in SAP BW definitely means a own and time intense project, because all implementations in the system have to be checked, if they would work as expected and as designed at the current patch level.
So just think about this point and do not hassle with SAP Administration and please do not start moaning, if they are not willing to do the patch update - remember, it is not as in other worlds...
Language / Communication with SAP BW Developers
Do not wonder about the terms that SAP Developers are using while talking about the objects in SAP BW - this will be different from the terms you will encounter using XMLA or you certainly will know from the SQL Server world. So communication sometimes will be difficult but an accurate translation will be helpful and is also provided in the pdf-file on page 19 and 20.
Security & Single Sign on (SSO)
To be shure, that we think and talk about the same thing while having SSO in the mind first a definition:
"What’s the Difference Between Authentication and Single Sign-On?
Authentication, or initial authentication, occurs when users first identify themselves to a system, and in turn this identification is verified. Initial authentication in SAP environments can take a number of different forms, ranging from anonymous or guest access to a Web site through the familiar user ID and password procedure, to using X.509 digital certificates.
Where single sign-on is in place, the user is issued credentials in one form or another following initial authentication. This allows the user to forego subsequent authentication steps when accessing further systems, offering not only convenience, but also increased security by limiting the number of times users enter sensitive information. This reduces the temptation for users to choose an easy-to-guess password. Single sign-on authenticates the user to access all the applications they have been given rights to in the SSO landscape, and eliminates future authentication prompts when the user switches applications during that particular session."
[from the SAP Developers Network]
But what does this mean regarding RS on SAP BW?
While SAP BW is a data storage and reporting system whith an own authorization system you definitely would like to make the usage of the reports as comfortable as possible. Though a user should not need to athenticate against the SAP system as backend while running the different reports and provide his credentials again and again. Therefor a automatic authentification should be possible and established by the system without contacting the user.
Normally in enterprise environments you will not face a homogeneous landscape whith SAP BW residing on a Windows Server but will discover, that SAP BW is running on a UNIX OS.
If you are a lucky one with SAP in a windows environment, you probably will be able to use kerberos and the SAP CUA (central user administration) and this will be the right documentation:
But what to do, if you are facing the "standard", SAP BW on UNIX OS??
There are alos certain ways to implement a SSO solution between Windows and UNIX, including Kerberos, or 3rd-Party-Tools like the ticketing with the Tivoli Access Manager or the solution from secude. You will find appropriate documents on the SDN or other sources like:
If you do not like to establish the SSO via a 3rd-Party-Tool and are using the SAP ITS (Internet Transaction Server) than you should read this article provided by Thomas Jung very intendly.
If you can not solve the above mentioned topics, you probably could use a technical user to connect RS via XML/A, but please consider, that the user authorization in SAP BW normally is based on so called authorization objects (for example key identifiers like company code) and you will not be able to use this build-in security concept for the user while using a technical one and though you will have a loose of security. If you are just planning to deploy master data reports, than the use of a technical user could be without security concerns.
I would highly recommend that you avoid a scenario where you implement your own security structure in Reporting Services or in SQL Server. Then you are only building up certain places for administration and could not be sure that your "home-made" security provides the same security settings for the users as the settings in SAP BW. And because of SAP BW normally being the leading system and the main reporting system you should prevent this situation.
Please do not forget to ONLY use the https-SOAP-Connection, whether you are using SSO nor provide the credentials via the reporting manager application during the report call.
Conclusion
Doing Reporting Services on SAP BW is a good option to enhance enterprise reporting towards the microsoft plattform regardless, which data source is connected. Doing so also will bring up some points for discussion or some pain points - if you face a hardliner SAP Administration for example...
But to be honest, you also would not be really glad if your SQL Server data would be assimilated by a SAP BW system, would you?
If someone has other arguements, opinions and especially hints on the SSO-topic please feel free to use the comments