As of BW 3.0A, there is an Export DataSource for the PSA. You can use this DataSource like any other DataSource, for example to read data from the PSA with a RemoteCube. In the example shown here, we will compare data that has been loaded to the InfoCube with data loaded into the PSA. In a query, you can see the data from the InfoCube in one column and the data from the corresponding PSA table in another column. You can compare the results and judge whether they match.

This White Paper (PDF) only gives you an introduction about how you can work with the PSA Export DataSource.

Today, in SAP’s Business Information Warehouse, currency conversion can take place using different parameters defined in a currency translation key (source currency, target currency, exchange rate type and time reference) and in different layers (during update of data to the data targets, at query definition time and at query runtime).

One major requirement, not fully covered by today’s architecture, is the dynamic time currency conversion using variables in Reporting. The dynamic time reference in the above mentioned table only includes dynamic conversion using a “date InfoObject” (no variable input) or the query key date (applicable in only some business cases, see comment below). Therefore, this technical solution shows you how to implement multiple and dynamic time currency conversions in one query. This includes especially variable time conversions allowing the customer to execute different conversions to the same target currency using different dates (example: simulate influence of exchange rates on sales). Please note: the variable selection of the target currency mentioned in this paper can be achieved using standard functionality.

The solution needs to be implemented only once per InfoCube but is very usable for the BW end users. Only the conversion rates (table TCURR) have to be loaded (and maintained on R/3) on a regular basis. Key benefits of this solution are:

• Very easy to use (simple input of time reference by user)
• Independent of data model (solution works with any Infocube and query).
• Correct aggregation of converted quantities (totals and subtotals are calculated).
• Low performance impact: usage of the OLAP BADI (virtual exit) is not leading to bigger data amounts being processed by the OLAP processor.
• No impact on transaction data stored in the BW database.

Know more about it in this manual(PDF).

As of SAP BW 3.5, you will have additional options to create variables for the following components of a currency conversion type:

Exchange rate type: The exchange rate type distinguishes between exchange rates that are valid in the same time frame, for example, the bid rate, ask rate or middle rate. The exchange rate types are stored and can be maintained in a central table (TCURV). Create a variable for the technical InfoObject 0RTYPE.

Target currency: The target currency can either be fixed in the translation type or not selected until the time of translation. Create a variable for the technical InfoObject 0CURRENCY.

Fixed time reference: If the time reference is fixed for a currency translation type, then the point in time for the exchange rate determination is independent of the data. The fixed point in time can either be a fixed key date that is stored in the translation type or can be determined using the system date when executing the currency translation. Create a variable for the technical InfoObject 0DATE.

Download and Understand more about this in this Whitepaper (PDF).

A successful SAP BW implementation requires that end user query response times are consistently running in the fast to reasonable range, in order to gain user acceptance and help drive overall productivity. There are many factors that influence the response time of a BW query, including its complexity, the volume of data involved, architecture of the data model, and the existence of pre-summarized or pre-calcultated objects. A sound OLAP performance strategy includes the utilization of several of the important tools that are available for SAP BW tuning efforts, such as multi-provider, aggregates, and pre-calculated templates. Introduced in SAP BW version 3.0, the OLAP cache offers a valuable compliment to these other useful techniques used for accelerating query response times.

The OLAP cache is architected to store query result sets, and to give all users on an application server access to those result sets. If a user executes a query, the result set for that query’s request can be stored in the OLAP cache. If that same query (or a derivative) is then executed by another user, the subsequent query request can be filled by accessing the result set already stored in the OLAP cache. In most cases, a query request filled from the OLAP cache is significantly faster than queries that receive their result set from database access.

A savvy performance tuning strategy could include scheduling background jobs to load specific query result sets into the OLAP cache. Therefore, initial user query executions against newly loaded data can “hit” and OLAP cache result sets in running queries, boosting performance significantly. For more information about performance tuning in general, see also SAP Service Marketplace alias /bw -> Performance.

View/Download the Manual on Performance Tuning.

You have an SAP BW system with several (application) servers. You would like to distribute the workload of the data loads and other data warehouse management activities in a way that fits your needs best. This could mean that you would like to have all processes distributed across all available servers or that you would like to have one dedicated server for these processes.

Download from Rapidshare or Mediafire.