Optimize the performance of your

SAP BusinessObjects Design Studio solutions – tips and tricks

     SAP BusinessObjects Design Studio allows you to build solutions on SAP Netweaver, SAP HANA and with the new version 1.2 on BusinessObjects Universes. With the technical possibility to create very advanced dashboards, one of the main criteria driving the End User adoption is performance: whatever you may bring into these dashboards in terms of content and nice design, you will get the buy-in you are looking for only with a very high interactivity, there is no time to wait !

     After a first blog on Design Tips and Tricks, here is a second article that specifically deals with performance. Based on our experience with real implementations (SAP Runs SAP), we have collected and documented a list of things to do to make sure our Design Studio Apps are optimized to offer the highest responsiveness!

      Note: for each item in the list below, we have made an assessment on the potential performance improvement. This potential is an indicator, it does not mean it systematically brings the same percentage of speed growth, as there are many parameters entering into the overall results.

     Disclaimer: all information below are the result of investigation made by myself and some other colleagues from the team. There is no commitment from SAP regarding the points below. We just want to share our point of view, our investigations about how we have improved our performance.

          1. PageBooks and Tabs – management of the initial view 

               –>  Performance improvement potential : very high

     This is the most important of all of the aspects! With a careful handling of such design configurations, you can drastically influence the perception at each navigation step.



     When your app includes Tabs or Pagebooks, this means that there are several “screens” where only one is active and visible. Therefore, only the data sources on this active screen (page or tab) should be processed.

– When leaving this active view, “Resetting” the corresponding data sources should not be done (the screen it not visible anyway).

– All the data sources of the other inactive views should not be the object of any action as long as these views are not visible.

The code in this event handler must be structured in a way that only the data sources related to the displayed view are processed:

if ((PAGEBOOK_1.getSelectedPageIndex() == 0)) {

    // Touch data sources relevant for your first page

  // …

} else if ((PAGEBOOK_1.getSelectedPageIndex() == 1)) {

   // Touch data sources relevant for your second page

   // …

} else if ((PAGEBOOK_1.getSelectedPageIndex() == 2)) {

   // Touch data sources relevant for your third page

   // …


         2. Carefully select the data sources that are loaded at startup

               –>  Performance improvement potential : very high

     By default, all data sources are loaded in Design Studio at start up. For simple dashboards, this does not alter the perception of the end user and the data show up in a few seconds – with the advantage that they are now included.

     For multi-page applications, the number of data sources and of components to be loaded will have a more significant impact and the end user may need to wait for an approximate 30s to 1 minute if nothing is settled to change this.

     Solution: since only the data sources for the first screen are needed at startup, all other data sources should set the “Load In Script” to “true”.

/wp-content/uploads/2013/11/load_in_script_334302.png These other data sources must be loaded afterward within the script making the related components visible:     


     Note: when a startup script is used (for example in the case of multiple views, to handle the fact only one view is visible), not only “Load in Script” must be properly set as described above, but also you need to pay attention for the “loadDataSource()” in the script to avoid to load Datasources unnecessarily with a performance impact. To make it simpler:

Load in script loadDatasource Consequence on processing Consequence on Performance
False Not called KPI is visible – the datasource is loaded

Positive impact – Expected setting for visible KPIs on startup
performance depends on the datasource, and will impact the opening time

False Called Second loaddatasource() is ignored No impact
True Called KPI is not visible on startup – however you load the Datasource

Positive impact – Expected setting for KPIs not visible on startup – performance depends on the datasource, and will impact the time to switch to the KPI

True Not called Error: you try to display a KPI while the datasource is not loaded Negative impact

          3. Initialize data sources in “background processing” (available since 1.2)

               –>  Performance improvement potential : very high

     This feature can help if:

– Multiple data sources per screen are really needed

– The components relying on these data sources are visible at the same time.

     With “background processing”, the “most important” data sources can be initialized first (and these components show the data right away) and the other components are initialized shortly after in the “On Background Processing” script of the application.


Supposing when you open your dashboard, you have several datasources/charts to show in the first page, and other datasources/charts in other pages.

What the background processing will allow you to do is:

  • Show data, chart after chart for the first page (You have to define which chart you want to load/show first, then the second one, third one, …)
  • As soon as all charts from page 1 are loaded, load charts for the other pages with the background processing mode. This will improve your opening time, and the load of datasources from page 2, 3, … will be transparent for end-users.

     In Design Studio:

  • For datasources/charts that you need first, keep “Load in script = false”
  • For all other datasources, please select “Load In Script = true”. Then in the “On Startup” script this line must be added:


     This will trigger the “On Background Processing” script after the rendering has finished. Inside the “On Background Processing” script, the other data sources can be initialized with line calls like:


Note that this concept is not limited to two levels (“main” data sources vs. other data sources), but it is also easily possible to create a sequence-chain of data sources to be initialized.

Note: the “On Background Processing” concept is not limited to the application startup. On newly displayed pages of a pagebook or tabstrip the most important data can also be shown first and the other data sources can be initialized subsequently.

Taking an example:

     To use a tile effect, in which datasources are loaded one-by-one, the application designer can use the recursive functionality.

     If 6 different DSs are used within the application, and they show their data one after the other, a script like this one could be used:


On the “On Startup” script, please add


Create a variable Variable1, initialize it to 0

Then, on the background processing function, add:

if(Variable1 == 0){


//the chart linked to DS_1 will appear


if(Variable1 == 1){


//the chart linked to DS_2 will appear


if(Variable1 == 2){


//the chart linked to DS_3 will appear


if(Variable1 == 3){


//the chart linked to DS_4 will appear


Variable1 = Variable1 +1;

if(Variable1 < 6){



     Following this code, tiles will appear one after the other one. During the time you will load DS_2, DS_3, etc… end-users will be able to read/play with DS_1, and the loading time of DS_2, DS_3, etc… will be transparent for end-users. So, the perception of the loading time will be completely different.

          4. Upgrade to version 1.5 SP0

               –> Performance improvement potential : very high

     In this release, a number of changes have been introduced in the Designer and in the BIP Add-on. Please find more information here:


          5. SetVariableValue/setFilter/setDataSelection

               –> Performance improvement potential : very high

     Depending on the definition of the source BW Queries, you may have to create some filters in Design Studio especially in case end-users have required drop down lists, list boxes, etc…

     To achieve this, there are various possibilities with different costs on the performance. In particular, it is preferable to use a “setFilter” instead of  setVariableValue” wherever possible. “setVariableValue” impacts the VariableContainer and therefore refreshes all the datasources embedded in this container. This may significantly impact the performance, executing more data refresh than needed.

     To summarize, here is a general impact of the different types of filters on the performance:

          Highest: “setVariable”: BW roundtrips for multiple data sources

          Medium: “setFilter”: BW roundtrip for one data source

          Lowest: “setDataSelection”: no BW roundtrip

          6. Use one datasource for multiple charts (available since 1.2)

               –> Performance improvement potential : medium / high

     If several charts show the result set of the same query in different ways in your application, this requires any version until 1.1 to create distinct data sources for each chart. Each of the data sources used a different “Initial View” setting to display the different data.

     Design Studio 1.2 offers the possibility to use a single data source in multiple charts. The data source has an Initial View that contains the superset of all needed data. The chart itself has a new property “Data Selection” which allows filtering only the relevant data for the specific chart.


     The “Data Selection” can be exposed via a “picking tool” in the property sheet or by editing the “Data Selection” manually. In most cases the picking tool should be enough. The syntax for manual data edition is not yet fully documented.

     As data sources are the most significant performance driver in Design Studio applications, minimizing the number of data sources is always a significant performance gain.

          7. Care of issues on the “Error log”

               –> Performance improvement potential : small / medium

     When the application is running, you should check carefully “Message View” or in the Designer’s “Error Log” view. Sometimes these entries indicate programming errors/issues. Some programming errors could impact performance.

     For example, if the data source is asked for data that does not exist (warning message: There is a problem with the measure or dimension that you wanted to select using getData or getDataAsString), the tool will check for a non-existence, with high cost (generally via a backend-roundtrip).

          8. Use “Global Script Variables” instead of “hidden text fields”

               –> Performance improvement potential : small / medium

     In the past, Global Script Variables were not available in Design Studio; therefore, you had to use “Hidden text fields” or Dropdown lists to simulate variables.

     This has changed since version 1.1. Global variables are available and use far less resources than a hidden text field as it overall reduces the number of components. It also cleans up the “Outline View” of the application.

          9. Use CSS classes in one text field instead of two text fields

               –> Performance improvement potential : small / medium

     On your app, if you need:

  • to increase size when an item is selected
  • to put a text when an item is selected
  • show values in red or green depending of the value (for e.g. up or down to 0)

     You should leverage the dynamic javascript code (setCSSClass), instead of:

  • overlapping two texts (one in bold and one without bold) and play with dynamic visibility
  • overlapping two texts (one in red and one in green) and play with dynamic visibility

     Doing this, the number of text fields is reduced and performance improved. The reduced number of components will save resources and make the complex tree in the “Outline” view more usable.


     Following all of these recommendations with a careful management of your javascript, your queries, and your components, you can expect to have a dashboard running very fast.

     Design Studio offers a smart way of data management, processing the right minimum of sources (only information that your business can view). In parallel, the background processing helps to load the data for other KPIs, other views, in a transparent way for the end user. With this, data are already there when the user switches to another view and information comes up instantaneously.

Have a good time on Design Studio!!

To report this post you need to login first.


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

  1. Bharath Ramamurthy

    Hi Pierre,

    Good read.

    In point 4 – You have mentioned that : Upgrade to 1.2 SP1.

    SP1 is not yet released, only planned for early next year.

    Please be aware that there is no commitment from that the performance improvements planned (if any) to be released with SP1. It would be misleading to include this statement.

    Could you remove this point from the blog? or add a disclaimer?



  2. Tammy Powlas

    I agree, this is very nicely documented and described.  I will have to try after our holidays here.

    Thank you for sharing and I look forward to the next series.

  3. David POISSON

    Great job Pierre putting all our findings together – all of this based on real scenarios implemented within SAP for internal Business users – let’s continue in this way !

  4. David Gyurasz

    Thanks Pierre for writing this very useful post.

    It’s a pitty that “6. Use one datasource for multiple charts (available since 1.2)” thanks to the possibility to make data selections is only available for charts and not for crosstabs yet. Looking forward to this important feature in DS 1.3.

    1. Dirk Mayrock

      Hi David,

      have you checked the documentation for the SDK in 1.2? There are some examples embedded and the “Simple Crosstab” might be what you are looking for.

      Or it might be a good starting point for your own component ๐Ÿ˜‰


  5. Christian Ettenauer

    Hi Pierre,

    thank you for your explanatio of the Background Processing. But I’ve one Problem my variable doe’s not Change from 0 to 1 etc. It would be great, If you could ad an Information how you’ve set the variable for each tile.

    Best regards


    1. Pierre COMBE Post author

      Hello Christian,

      If you have for example 9 tiles, you could have something like that:


      if( backgroundVariable == 1){update your first tile}

      if( backgroundVariable == 2){update your second tile}

      if( backgroundVariable == 9){update your ninth tile}

      backgroundVariable = backgroundVariable + 1;

      if(backgroundVariable < 10) {




      So in the first loop, DS will update the first tile. Then we increment +1, but still below 10. So, going back to background process, and DS will update the second tile. Then we increment +1, ….

      Thank you,

      Best Regards, Pierre

      1. Koen Hesters

        Hi Pierre,

        VC= Variable Container

        “The VC combines all variables of all data sources in the application.[…]”

        The prompt selection, where you remove the variables you do not want to see in your prompt. does is remove the variables as well in the VC, or not?



  6. Biswajit Biswas

    Hi All,

    Is there any document available on performance bench marking of Design Studio Dashboards. If there is any it would be of great help.



  7. Andreas Appelt

    Hi Martin,

    we have been able to improve the performance by reducing the number of datasources. We identified that we could also reduce the number of variables in each query from 5 down to 1 (currently each query uses the same set of 5 variables).

    1.Can we inspect a significant performance improvement by reducing the variables in each query(=datasource) or is the number of datasources (which would use always the same variable) the bottleneck?

    2.If we reduce the variables then we have to use setFilter to allow filtering. I assume that in this case DS retrieves more data from BW (BW on HANA) and then the filtering takes place inside DS. Does this have a negative performance impact?


    Regards, Andreas

    1. Martin Kolb

      Hi Andreas,

      ad 1)

      Reducing the number of variables does not have a significant advantage.

      Unless you can remove them altogether, then significant performance gains can be expected because then this query does not join the variable container

      ad 2)

      Filtering is not done in Design Studio. Filtering takes place in BW or HANA. There is no negative performance impact when using filters instead of variable.



      1. Andreas Appelt

        Hi Martin,

        thanks for your reply.

        Our problem is that we have 9 datasource on the first view. Unfortunately we can’t reduce the number of datasources that are initially used. Background processing doesn’t really help in this situation.

        So far we improved the performance by:

        1. Reducing the total number of datasource used in the dashboard.
        2. We also reduced the number of variables from 4 to 1 per query. This also had an positive impact on the performance for initialising the dashboard.
        3. Because we replaced the 3 of 4 variables with filters using the setFilter function, now switching between dashboard views takes significant longer (If a user selects another view than in the script we assign query to a datasource and filter the datasource depending on selections in dropdown boxes). So the initial loading time improved by about 40% whereas the time for switching between views is about 50% higher. So moving to filters didn’t help us in general.
        4. Does it make sense to define the BW query in such a way that it provides only a very limited set of data (for example set a global query filter 0Divsion=# which means there is no result) and then use setFilter in DS to retrieve the data that is really needed (for example setFilter(0DIVSIÓN,”mydivision”))? Would this ensure that only needed data is retrieved?
        5. During the next days we plan to move on to DS 1.5 to overcome current limitations. Would you still recommend setFilter instead of setVariable? We have the impressions that it’s easier to work with variables than with filters and hope that due to the parrallel query processing feature the performance would improve significantly.
        6. We considered all improvement tips except of one. You recommend to put coding like APPLICATION.setVariableValueExt(“CO2_FISCPER3”,DS_4B.getVariableValueExt(“CO2_FISCPER3”)); from the “On Startup” event to the “On Init.” event. It seems to be that getVariableValueExt can’t be used in the “On Init.” event. We need the coding to filter a query to a period. This query feeds our dropdown with valid values.

        Thanks for your support.

        Regards, Andreas

        1. Martin Kolb

          Hi Andreas,

          from my experience with customer’s applications it’s very, very, very rare that really 9 data sources on the first view are needed.

          I don’t know the application itself, so it’s very hard to judge from a distance, but I doubt that background processing cannot help when 9 data sources are involved. A user won’t be able to spot 9 aspects of an applications at the same time. So there should be like 4 aspects that are more important than the other 5 ones. And with that these 4 data sources could be loaded initially and the other 5 in background processing.

          The suggestion to use “setFilter” instead of “setVariableValue” holds true in general, because of the fact that “setFilter”always affects only one data source whereas “setVariableValue” typically affects multiple data sources (all data sources in the variable container).

          However my statement was done in the context to change the result of an existing query with either “setFilter” or “setDataSource”. If, like in your scenario, you exchange the complete query with “assignDataSource” in addition, then there might be other performance effects.

          I am not sure what you intend by defining a query first with a limited data set. If a result of a query is not needed then the data source should not be initialized. If the result is needed, then it should be processed with the appropriate filters and variables. An uninitialized data source is always much faster and more efficient than a query with an empty result set. Even empty result sets are often achieved by scanning lots of records in the BW.

          When you move to 1.5 you will most likely consider using the “parallel execution” of data sources to speed up your application. Using this feature requires that the variable container is turned off (i.e. the property “Merge Prompts” of the application is set to “false”). When the variable container is turned off then it is possible to use “setVariableValue” not only on the application, but also on a specific data source, which means that it only affects one specific data source, like “setFilter”. But be aware that “APPLICATION.setVariableValue” still affects all data sources in the application (no matter what value the “Merge Prompts” has).

          So working with variables when “Merge Prompts” is “false” can be done in a way that it is equally efficient like “setFilter”, however it’s not as easy anymore, because variable values are not automatically distributed by the variable container – and therefore often additional code is needed to provide this distribution where it is required.

          Actually I’m a little confused what you say about this line of code:


          It’s not referenced in this blog. Especially this blog is not written by me anyway. You might be referring to my blog “Design Studio 1.5 – The Performance Release” (http://scn.sap.com/community/businessobjects-design-studio/blog/2015/04/15/design-studio-15–the-performance-release).

          There I recommend to use “setVariableValue” in “On Variable Initialization” instead of “On Startup”. As you already mentioned, methods that retrieve information from data sources (e.g. variable values) cannot be called in “On Variable Initialization” because at that point in time the data sources are not yet initialized. For your scenario you should consider thinking about where did the value of “CO2_FISCPER3” in DS_4B come from. Was is calculated at some lines before in the script and set to “DS_4B”? Then you can use this calculated from within the script, instead of retrieving it again from “DS_4B”.




Leave a Reply