Skip to Content

Let’s face it, the SAP BW front-end tools (not including Business Objects here) have never really scored fantastically on being intuitive or visually appealing.  They could probably best be described as adequate in these categories, and despite being otherwise powerful and feature-rich analysis tools this has often resulted in a less than enthusiastic adoption by end-users.  On the other hand we have SAP Crystal Dashboard Design (Xcelsius Engage) that is capable of generating very sexy looking (only a true IT geek uses this word to describe technology) and intuitive dashboards. 


It’s no wonder that many BW clients have explored the option of using Xcelsius as a visualisation tool for their BW data.  However, many have also abandoned the idea when faced with the prospect of having to implement the SAP Business Objects Enterprise Platform architecture to facilitate this, or having to upgrade the production SAP NetWeaver instance  to 7.0, EHP1 (also called 7.01) with SP 5 to exploit the direct connectivity that comes with the BI Consumer Services (BICS).  This is especially true when they may only have a handful of dashboards they might use it for.


Fortunately that’s not the end of the story.  Read on to find out more about an alternative solution that we implemented for one of our clients.



Aren’t open standards brilliant?

Oh yes, they are! Especially when the developers of software like SAP and Business Objects choose to adopt them.  For our solution it’s all about web services.  SAP BW (version 7.0 and up) includes a standard web service for calling SAP BW queries.  At the same time SAP Crystal Dashboard Design supports acquiring data from web services via a ‘Web service’ data connection. 


This enables us to get data out of our SAP BW system into a SAP Crystal Dashboard Design dashboard without needing any other integration architecture. Seems simple enough and in principle it is, but as with all things tech there are a few catches.


Getting to your BW queries

There are a number of aspects that need to be addressed when trying to access your BW queries from an external system.  Firstly, you need to consider any potential licensing impacts carefully and it’s best to have an open conversation with your SAP account manager on the topic. 


What the implications might be will depend greatly on how and by whom the dashboard will be used and the existing licensing framework you have with SAP. A detailed discussion of this is outside the scope of this blog and we will focus on the technical aspects of the solution instead.


Secondly, authentication or single sign-on between the two systems. SAP have done a great job here by providing an extensive range of options around security that can be configured on a service-by-service basis. Options range from having an unsecured service to encrypted Username/password elements in the document header to SAP logon tickets to SAML Assertions and more. 


Again, the chosen solution will be influenced by a number of factors including your internal security policies and how you choose to expose the dashboard to users i.e. within SAP Portal, within a 3rd party portal (e.g. MS Sharepoint or IBM Websphere Portal) or even embedded in a slide deck attached to an email.


Finally, the required format of the data to make it useable in the receiving system.  This is probably the biggest catch with this approach.  The ability of SAP Crystal Dashboard Design to map to elements of complex web service response messages is limited. Unfortunately, the standard web service for accessing BW queries delivers a response message that is about as complex as you would expect from any web service.


So out-of-the-box, it does not lean itself to being consumed by SAP Crystal Dashboard Design. In fact, you can’t really use it for any queries that have more than one column of data in the results.  To be fair though, dashboards are typically comprised of small sets of highly aggregated data so it is still useful even with this limitation.


Dashboard-friendly output

However, to get around this limitation we created a ‘wrapper’ function module around the standard function module that is the engine beneath the standard web service.  We used this wrapper function module to simplify the output from the standard function module so that it is easier for SAP Crystal Dashboard Design to interpret.  We then generated a bespoke web service based on our wrapper function module. 


This approach gained us the ability to embed queries with multiple output columns in SAP Crystal Dashboard Design but also comes with some limitations. Most significantly, the number of columns in the output structure is fixed.  But again, when it comes to data for dashboards you are typically  working with a small number of data sets (less than 15 columns). So fixing the output structure to a maximum of e.g. 20 columns should cater for the vast majority, if not all requirements. 


 From a purist perspective it’s not an ideal solution, but from a pragmatic perspective it does the trick.





The fundamental tools for integrating SAP BW queries with SAP Crystal Dashboard Design (formerly Xcelsius Engage) dashboards are available as standard within these applications. 


The use of web services provides and alternative integration model for customers that do not require the full set of features provided by the BOXI architecture, but still desire to exploit SAP Crystal Dashboard Design to visualise their BW data.

To report this post you need to login first.


You must be Logged on to comment or reply to a post.

  1. Durairaj Athavan Raja
    I completely agree with your view. We were in the same boat few years back. and when ahead and created a RFC wrapping the WS RFC. But we still dont use much of Xcelsius, instead go for plain flex programming for the sheer flexibility.

    this may be of interest to you

    Execute BW query using ABAP Part I
    Execute BW query using ABAP Part II
    Execute BW query using ABAP Part III

  2. Former Member
    Thanks for sharing Herman,

    Have you conducted any performance testing?  If the connection is set to refreh before components are loaded, how long does the dashboard take to Initialize if the returned dataset is 100+ or 500+ rows?

    Appreciate your input!

    1. Former Member Post author
      Hi Ryan,

      In our scenario we always used queries that returned 20 rows or less, so I’m afraid I don’t have much hard data to help you out with. 

      However in my unit testing I did run queries returning 100+ rows through the web service using SOAPUI as a testing harness (download free at and the runtime was always acceptable (didn’t time it precisely, but my gut feel is less than 30s).

      Of course this doesn’t necessarily reflect accurately what the runtime would be for the .swf initialisation, so I guess that still leaves you with an open question.

      My opinion is that the BW web service is unlikely to cause dramatic performance increase in the overall process, but I can’t vouch for the Crystal Dashboard Design.  The recommendation there is not to exceed 500 rows, so I suspect you might hit some issues going beyond that.  I would expect 100 rows to still be fine though.

      Sorry I couldn’t be of more help and hope you get it sorted.


      1. Former Member
        Thanks for taking the time to reply.  I’ll do some additional benchmarking on our end…we’ve implemented a solution very simular to the one you describe.

        So far, the use of the webservice for a returned dataset of up to 100 rows is a little slow, but  acceptable.  However, 200+ rows takes in excess of 30 seconds to paint the components.


Leave a Reply