Skip to end of metadata
Go to start of metadata

Product versions:
Xcelsius 2008
BusinessObjects Enterprise XI 3.1 SP3

Table of contents

This article is part of a series

Main components and Process Flow

The process flow and decision tree (on how a client request is routed) is presented in the following deployment diagram :
There are up to 4 main components involved in the processing of a QaaWS request :

  1. the QaaWS end point URL
    • is part of the web service deployed within the dsdwbobje war file
    • is responsible to redirect to the Xcelsius Cache server is the query caching (also called "QaaWS Accelerator") is enabled or the Web Intelligence Processing Server as it does prior to SP3
  2. the Xcelsius Cache Server
    • is part of the BOE cluster and administered from the CMC
    • is caching the result sets and associated security settings
    • is in charge of auditing the execution of a QaaWS object
    • sends a request to the Xcelsius Processing Server if the result set is not already in the cache
  3. the Xcelsius Processing Server
    • sends the SQL query to the database and retrieves the result set, it is using the same Connection Server libraries than the WebIntelligence server, hence supports all data sources that WebI / Universe support
    • sends the result set back to the Xcelsius Cache Server for caching and response to the client
    • connects to the WebIntelligence Processing Server is the SQL needs to be regenerated or the universe has security restrictions at the user or group level
  4. the WebIntelligence Processing Server
    • regenerates the SQL query when asked to do so by the Xcelsius Processing Server
    • apply the security restrictions defined within the universe

After an "warm up" period where the cache is being built, it is expected that only #1 and 2 handle the bulk of the workload. #3 and 4 are more resource intensive and from a performance standpoint roughly equivalent to the pre-SP3 architecture.

Details on decision points

  1. "Is QaaWS Accelerator enabled ?"
    is a web application wide configuration setting, see configuration details here
  2. "Is result set already cached and user allowed to view it ?"
    The Cache server keeps a map of result sets in memory, each result set is identified by a security hash key. It does not pre-cache data, it will cache each result set at the first request and re-use it until it expires. The key is a combination of the QaaWS object ID, the security settings on the underlying Universe and Connection objects. The Cache server maintains a map of the user security settings and identifies who can see what. Here are scenarios to illustrate :
    • Use Case 1 : everyone shares the same data, the query has no prompt. The simplest case is when the QaaWS object returns the same result set for everyone, has no prompt and all users are allowed to see the same data. The same result set will be fetched once from the database and cached for all users. As long as the result set stays in the cache, all requests from all users will get it from the cache, leading to shorter response times.
    • Use Case 2 : everyone shares the same data, the query has prompt(s). If all users have access to the same data but the QaaWS object has prompts, the result of each combination of prompt values will be cached as a separate result set. Example : QaaWS object has a prompt on Year with 4 possible values and a prompt on City with 10 possible values, the Cache will maintain up to 40 distinct result sets in memory. This does not have an impact of response time as long as the cache is large enough to contain all possible result sets.
    • Use Case 3 : data security is done via universe restrictions (also called overloads) When the underlying universe has security restrictions at the user or user group level, the Xcelsius Cache Server will enforce those restrictions and re-use cached data only if the user is allowed to access it. If the current user requests data that is not already cached (because his restrictions are different than for all other cached result sets), the request is forwarded to the Xcelsius Processing Server, then WebIntelligence Processing Server to generate the SQL query.
    • Use Case 4 : the underlying database has row-level security The Xcelsius servers will not support in their first release the use of the 2 universe connection options "Use BusinessObjects credential mapping" and "Use Single Sign-On when refreshing reports at view time", or the use of the BOUSER variable. This is documented in the SP3 release notes.
  3. "Regenerate SQL or Universe Security Overload ?"
    The Xcelsius Processing Server can process queries to the database but it still relies on the WebIntelligence Processing Server to re-generate the SQL when required. The latter will parse the Universe, generate the new SQL query and send it back to the Xcelsius Processing Server.
    • The most common case where the SQL needs to be generated is when the universe is newer than the QaaWS object definition. The Xcelsius Processing Server will perform a time stamp comparison between the QaaWS and universe objects and request for a SQL re-generation to WebIntelligence Processing Server if the Universe has been updated since the QaaWS object was last published.
    • The Xcelsius Processing Server will also check whether the universe has its own security restrictions. If so, it will request for a SQL generation to the WebIntelligence Processing Server.

How to maximize the benefits of caching

Based on the process flow described above, here are factors that will limit the benefits of query caching.



user-level universe security restrictions

delegate row level security to DB when possible

use of free text prompt(s) leading to potentially unlimited possible values

replace by a limited List Of Values (LOV)

high number of prompts and / or values in each LOV

reduce the number of combination (simplify the dashboard) or increase the cache size to ensure it can store all combination

Frequent changes to universes

Ensure the QaaWS objects are re-published whenever the underlying universe is changed

Cache size too low

When the cache reaches the maximum size allowed, it deletes result sets, starting with the least used result set (based on frequency of access). It the cache size is too low, the cache server will delete result sets too early and users will not benefit from the caching.

See article on tuning for further details on cache size : Xcelsius tuning options in XI 3.1 SP3.

  • No labels

1 Comment

  1. Unknown User (borbsad)

    Patrice Le Bihan,

    According to the following article, in 4.0 the WebI processing server does not exist in this process flow, is that an improvement in 4.0, giving Xcelsius Processing Server(aka Dashboard Design Processing Server) the capability to generate SQL on its own with out depending on Webi Processing Server?