BWtopics.com

By default, SAP BW only allows the following as valid characters for characteristics values during data loading:

‘ !”%&”()*+,-./:;<=>?_0123456789ABCDEFGHIJKLMNOPQRSTUVWXYZ’

In case you need to add more character as valid for data loading, you have to input the character in transaction RSKC – Maintenance of the permitted extra characters in BW.

If you enter the character string “ALL_CAPITAL“, all characters which are uppercase letters in the codepage are permitted for data loading. This is useful if, for example, you allow Asian character sets such as Chinese or Japanese.

The following characteristic values can never be permitted:

• The value that only consists of the single character ‘#’ is not allowed because the initial input is masked with ‘#’. It is acceptable if # is combined with other characters, for example ‘#001’.

• Values starting with the character ‘!’ are not allowed, because variable entry is deleted at the first position due to this character.

In case the source system does have such values, you may need to do some conversions on the incoming record using the start routine of a transformation.

For some reason, sometimes an attribute change run for a master data in process chain may get cancelled. Then, the next time of loading the master data a locked error would appear.

Fig.1 - Lock Error When Loading Master Data

This error appears even though there is no any job running and no table locked when checking in tcode SM12.

The reason for this is because you have to close any cancelled change run before starting data load again for that master data. To do this, you can use  transaction RSATTR. Just press the button “Monitor and Start Terminated Change Runs” at the bottom.

You may also display table RSDDAGGRMODSTATE to check for any change run job that are still open.

In case the change run always gets cancelled and your system have a BI Accelerator installed, it could be due to a corrupted BIA index. To fix this, recreate the BIA indexes of datamarts using the infoObject then try to use RSATTR again.

When running tcode DB02 (or DB02OLD) to check database, you may find references to objects (tables, views, triggers) that have /BI0/0 preifx. These are actually temporary objects for the query and other processes that the BW system generates outside the ABAP dictionary.

All these objects have names that start with /BI0/0… followed by a number
for the object type and an eight digit identification. A temporary table
may be named /BI0/0101234567, for example.

To remove these objects, run the report SAP_DROP_TMPTABLES. Note that this program will remove all the temporary objects regardless whether it is currently being used, so make sure that nobody is currently running queries when you execute this.

If temporary objects prove to be inconsistent under DB02, you must execute
report SAP_UPDATE_DBDIFF once.

There are 5 percentage functions you can use in defining calculated key figures or formulas in the query:

Percentage Share (%A)

Generates the percentage share of Operand 1 and Operand 2. Put simply, OP1 %A OP2 = OP1 / OP2 * 100%. This function is also useful in order to quickly change any key figure or formula to use percentage format – by getting the percentage share of that number against 100.

Percentage Variance (%)

Gives the percentage variance between Operand 1 and Operand 2. OP1 % OP2 = (OP1 – OP2) / OP2 * 100%. If you need (OP2 – OP1)/OP2 * 100%, multiply the expression by -1, i.e. OP % OP2 * (-1).

Percentage Share of Result (%CT)

Gives the percentage share of the single value agains the subtotal defined in query. For example, %CT Sales (assuming the query have store and month data) will provide percentage of sales vs the total at store/month level, not the overall total at month.

Percentage Share of Overall Result (%GT)

Generates the percentage share of the overall results. If the query has a filter, this percentage ignores that filter. For example, %GT Sales (in the same scenario above) will give the percentage against the overall result regardless of the current filter.

Percentage Share of Report Result (%RT)

Generates the percentage share of the query results. It is similar to %GT except that if the query has a filter, it will be applied before this percentage calculation.

Sure, you can reactivate objects using RSA1. But the following programs are quite handy especially when you need to reactivate a number of objects at once:

RSAU_UPDR_REACTIVATE_ALL

This report reactivates all already active update rules or a selected one.

Selection can be made for UPDID, target or source of the update rules.

(See SAP Note 631601)

RSDG_CUBE_ACTIVATE

The report can be used for activation of infocubes or a single cube. Selection can be done for cube type, infoarea, infocube and version.

If the A version is activated it will not effect the M version.

If the M version is activated it will overwrite the A version with the M.

RSDS_DATASOURCE_ACTIVATE_ALL

The report reactivates A versions or activates M versions according to the selection.

Both source system and datasource should be entered.

(See SAP Note 1056060)

RSDG_ODSO_ACTIVATE

You can activate ODS and DSO’s with help of the report. During activation the M version will be read.

There are two other options besides the activation:

• Check only – this will only check consistency of the DSO and no activation will be executed
• Clean up DDIC structures – this deletes old generated tables, which were only necessary in previous releases

RS_TRANSTRU_ACTIVATE_ALL

Transfer structures can be reactivated by this report.

Selection can be made by source system or infusource. For a single transfer structure both field should be filled.

If the option LOCK is flaged during activation the object is locked. If only inactive transferstructure should be activated the flag ONLY INACTIVE can be checked.

RSDG_IOBJ_ACTIVATE

The report activates infoobjects from the M version.

In the expert mode the processing lock can be swithed off, however it is not suggested to use.

First of all, SAP BW reporting (or any data warehouse reporting, for that matter) is designed to analyze highly aggregated data. So, it should be a very rare case that your query would reach Excel’s limit of 65,536 records. Query designers and end users, especially those who are new to SAP BW, must realize that the objective of BW is not for such transactional reports and need to think about creating proper restrictions and summarizations in the reports. If your primary purpose in BW is to analyze, do you really need millions of records to analyze meaningfully?

In case you really need to output such huge amount of records, there are some alternatives you may use:

• Web reporting
• Use transactions RSRT or RSCRM_REPORT to generate the query and send the output to a flat file or table,
• Using OpenHub tool, you can create an InfoSpoke and dump the results into a flat file.

You can configure BEx Analyzer to display recently opened workbooks and queries as items in the Open menu providing easy access for those reports that you are currently working on.

Open Menu Showing Local History

To do this, open the “global settings” option and set the “Maximum Number of Objects in Local History”. The submenu will not display more than the number of queries or workbooks you configure with this setting. If you have not opened this many items, the submenu will only display as many as you have opened. To turn off the display of the Local History submenu, set this value to zero.

Fig.2 - BEx Global Settings

Checking the option “Display System Name in Local History” will also show the system name besides the query or workbook.

As with any other project, a BW project would benefit from clear documentations and standards. Following are some of the documents that must exist in a BW project:

• Project Charter – states the project objectives, deliverables, sponsors, success measures, etc.
• Project Plan – typically, you may want to have an overall project plan and another project plan with very detailed tasks. The overall project plan integrates all the detailed plans and with other projects to ensure goals and milestones are met.
• Organizational Chart – documents the BW team members and their roles. It may also include a list of all stakeholders and their roles in the project.
• Development Standards document – basically, the technical blueprint, i.e. whether to employ 3-layer approach, or whether to use function modules, etc.
• Naming Standards – define the convention to name custom objects that will be created for the project.
• Landscape & Transport document – details the different systems in the landscape and the transport path of those systems. Typical BW systems in a landscape are sandbox, development, QA, production, and training.
• Architecture – shows the different infoproviders and the flow of data through the system.
• Model document – shows the requirements and scope of a subject area. It also defines and details the design of BW implementation.
• Security Standards – details the security standards as well as  authorization plan.
• Report Specifications – the requirements and specifications for each reports and queries.
• Change Management Strategy
• Unit tests, UAT scripts and various review checklists
• Go-live checklist
• Status reports, issue lists, gap lists, etc.

Having the document is important, but even more important is to have these documents well organized and updated. Steps should be taken in order to have these documents circulated, reviewed and approved by necessary team members.

A query/workbook which had been running perfectly well may suddenly get the following error message:

Fig 1. BEx Analyzer Error Message

This error is caused by inconsistency in the table RSDRHLRUBUFFER.

Under normal circumstances, the value of LOCK_CNT is being increased everytime a query with hierarchy is run, and then reduced again once it is finished. Also, if an entry of table RSDRHLRUBUFFER is not used for 72 hours it will be reused. However, there are times when this LOCK_CNT will erroneously get a negative value which causes the error during query execution.

In order to remove the inconsistencies, use transaction code SE38 and run the report SAP_DROP_TMPTABLES.  Check the option to delete “Temporary Hierarchy Tables” and then press Execute button. Make sure that there is no query running when you start this program.

Fig 2. Report SAP_DROP_TMPTABLES Options

In a typical BW data model, data is loaded into 3 layers – extraction, integration (or harmonisation) and datamart (or presentation) layer. With SAP BI 7.0 a Write-Optimized type of DataStore Object (DSO) was introduced, which is ideal for storing data in extraction layer.

When creating a DSO, you can set this type thru the settings and pressing the function button next to “Type of DataSore Object.”

Selecting DSO Type Fig. 1

Selecting DSO Type Fig. 2

The Write-Optimized DSO does not have the usual 3-table structure that Standard DSO have, namely: staging table, active data table and change log table. Rather, Write-Optimized DSO only have one table and once data is loaded, it will be available immediately. There is no need for activating, which also makes the ETL process faster.

Since it does not need the extra tables as Standard DSO, Write-Optimized DSO also reduces the total database storage space required by Standard DSO by at least 50%.

The downside for Write-Optimized DSO is that it is slow for query or even when displaying data in Data Warehousing Workbench (RSA1). Therefore, it is not recommended to use for queries or if you will need to display data as much.