LO COCKPIT - V3 update: Questions and answers

Added By Vinay

Question 1
Update records are written to the SM13, although you do not use the extractors from the logistics cockpit (LBWE) at all.
Active datasources have been accidentally delivered in a PI patch.For that reason, extract structures are set to active in the logistics cockpit. Select transaction LBWE and deactivate the active structures. From now on, no additional records are written into SM13.
If the system displays update records for application 05 (QM) in transaction SM13, even though the structure is not active, see note 393306 for a solution.

Question 2
How can I selectively delete update records from SM13?
Start the report RSM13005 for the respective module (z.B. MCEX_UPDATE_03).

• Status COL_RUN INIT: without Delete_Flag but with VB_Flag (records are updated).
• Status COL_RUN OK: with Delete_Flag (the records are deleted for all modules with COL_RUN -- OK)

With the IN_VB flag, data are only deleted, if there is no delta initialization. Otherwise, the records are updated. MAXFBS : The number of processed records without Commit.

ATTENTION: The delta records are deleted irrevocably after executing report RSM13005 (without flag IN_VB). You can reload the data into BW only with a new delta-initialization!
Question 3
What can I do when the V3 update loops?
Refer to Note 0352389. If you need a fast solution, simply delete all entries from SM13 (executed for V2), however, this does not solve the actual problem.
ATTENTION: THIS CAUSES DATA LOSS. See question 2 !
Question 4
Why has SM13 not been emptied even though I have started the V3 update?

• The update record in SM13 contains several modules (for example, MCEX_UPDATE_11 and MCEX_UPDATE_12). If you start the V3 update only for one module, then the other module still has INIT status in SM13 and is waiting for the corresponding collective run. In some cases, the entry might also not be deleted if the V3 update has been started for the second module.In this case, schedule the request RSM13005 with the DELETE_FLAG (see question 2).
• V3 updating no longer functions after the PI upgrade because you did not load all the delta records into the BW system prior to the upgrade.Proceed as described in note 328181.

Question 5
The entries from SM13 have not been retrieved even though I followed note 0328181!
Check whether all entries were actually deleted from SM13 for all clients. Look for records within the last 25 years with user * .
Question 6
Can I schedule V3 update in parallel?
The V3 update already uses collective processing.You cannot do this in parallel.

Question 7
The Logistics Cockpit extractors deliver incorrect numbers. The update contains errors !
Have you installed the most up-to-date PI in your OLTP system?
You should have at least PI 2000.1 patch 6 or PI 2000.2 patch 2.

Question 8
Why has no data been written into the delta queue even though the V3 update was executed successfully?
You have probably not started a delta initialization. You have to start a delta initialization for each DataSource from the BW system before you can load the delta.Check in RSA7 for an entry with a green status for the required DataSource. Refer also to Note 0380078.

Question 9
Why does the system write data into the delta queue, even though the V3 update has not been started?
You are using the automatic goods receipt posting (transaction MRRS) and start this in the background.In this case the system writes the records for DataSources of application 02 directly into the delta queue (RSA7).This does not cause double data records.This does not result in any inconsistencies.

Question 10
Why am I not able to carry out a structural change in the Logistics Cockpit although SM13 is blank?
Inconsistencies occurred in your system. There are records in update table VBMOD for which there are no entries in table VBHDR. Due to those missing records, there are no entries in SM13. To remove the inconsistencies, follow the instructions in the solution part of Note 67014. Please note that no postings must be made in the system during reorganization in any case!

Question 11
Why is it impossible to plan a V3 job from the Logistics Cockpit?
The job always abends immediately. Due to missing authorizations, the update job cannot be planned. For further information see Note 445620.
Posted by Vinay

How to Restore Query into Older Version

 

• Added by Mahesh Kumar, last edited by Arun Varadarajan

Once older verion (3.x) queries are migrated into latest version (7.0).Query can be restored to 3.x after migration. The backup for any query created in 3.x will be taken when first opened for editing in 7.0 Query Designer. The backup contains the last change done to the query using 3.x editor, any changes done in 7.0 Query Designer will be lost on restore. Also the query originally created in 7.0 can not be restored to older versions as there is no Backup in 3.x.

   Queries can be restored to 3.x version using program COMPONENT_RESTORE.

Steps followed for Restoring Query with 3.x versions:

Step 1 : Execute "COMPONENT_RESTORE" program in SE38.

Step 2 :   Next screen Select InfoProvider and component type. Different component types are available like

Step 3 : Select REP as a component type to revert back Query.  


Step 4 :  Execute (F8). In the next screen it will displays all related Queries for that particular infoprovider.

Step 5 : Search for the query which you want to revert back to older versions.

Step 6 : Then say transfer selection. below message will appears in the system.

Technorati Tags: SAP BI INTERVIEW QUESTIONS,SAP BI,BI Reporting,BI QUERIES

Step 7 : Once we select Yes, Query successfully restored into older versions.

The below 25 points are the small tips to increase your query performance. You can use them as a checklist while creating a Query. Here it goes..

1. If exclusions exist, make sure they exist in the global filter area. Try to remove exclusions by subtracting out inclusions.
2. Use Constant Selection to ignore filters in order to move more filters to the global filter area. (Use ABAPer to test and validate that this ensures better code)
3. Within structures, make sure the filter order exists with the highest level filter first.
4. Check code for all exit variables used in a report.
5. Move Time restrictions to a global filter whenever possible.
6. Within structures, use user exit variables to calculate things like QTD, YTD. This should generate better code than using overlapping restrictions to achieve the same thing. (Use ABAPer to test and validate that this ensures better code).
7. When queries are written on multiproviders, restrict to InfoProvider in global filter whenever possible. MultiProvider (MultiCube) queries require additional database table joins to read data compared to those queries against standard InfoCubes (InfoProviders), and you should therefore hardcode the infoprovider in the global filter whenever possible to eliminate this problem.
8. Move all global calculated and restricted key figures to local as to analyze any filters that can be removed and moved to the global definition in a query. Then you can change the calculated key figure and go back to utilizing the global calculated key figure if desired
9. If Alternative UOM solution is used, turn off query cache.
10. Set read mode of query based on static or dynamic. Reading data during navigation minimizes the impact on the R/3 database and application server resources because only data that the user requires will be retrieved. For queries involving large hierarchies with many nodes, it would be wise to select Read data during navigation and when expanding the hierarchy option to avoid reading data for the hierarchy nodes that are not expanded. Reserve the Read all data mode for special queries---for instance, when a majority of the users need a given query to slice and dice against all dimensions, or when the data is needed for data mining. This mode places heavy demand on database and memory resources and might impact other SAP BW processes and tasks.
11. Turn off formatting and results rows to minimize Frontend time whenever possible.
12. Check for nested hierarchies. Always a bad idea.
13. If "Display as hierarchy" is being used, look for other options to remove it to increase performance.
14. Use Constant Selection instead of SUMCT and SUMGT within formulas.
15. Do review of order of restrictions in formulas. Do as many restrictions as you can before calculations. Try to avoid calculations before restrictions.
16. Check Sequential vs Parallel read on Multiproviders.
17. Turn off warning messages on queries.
18. Check to see if performance improves by removing text display (Use ABAPer to test and validate that this ensures better code).
19. Check to see where currency conversions are happening if they are used.
20. Check aggregation and exception aggregation on calculated key figures. Before aggregation is generally slower and should not be used unless explicitly needed.
21. Avoid Cell Editor use if at all possible.
22. Make sure queries are regenerated in production using RSRT after changes to statistics, consistency changes, or aggregates.
23. Within the free characteristics, filter on the least granular objects first and make sure those come first in the order.
24. Leverage characteristics or navigational attributes rather than hierarchies. Using a hierarchy requires reading temporary hierarchy tables and creates additional overhead compared to characteristics and navigational attributes. Therefore, characteristics or navigational attributes result in significantly better query performance than hierarchies, especially as the size of the hierarchy (e.g., the number of nodes and levels) and the complexity of the selection criteria increase.
25. If hierarchies are used, minimize the number of nodes to include in the query results. Including all nodes in the query results (even the ones that are not needed or blank) slows down the query processing. The "not assigned" nodes in the hierarchy should be filtered out, and you should use a variable to reduce the number of hierarchy nodes selected.

Copying Queries between InfoCubes

By Debasish BI EXPERT

You can use this function to copy queries and their sub-objects (structures, calculated key figures and restricted key figures) between different InfoCubes.

The target InfoCube, the InfoCube for the query copies, must contain all the InfoObjects of the source InfoCube (InfoCube of the original queries).

Procedure...
1. In the SAP Easy Access Menu of the BI system, choose SAP Menu  Business Explorer  Query  Copy. Double-click on Copy Queries. The Copying Queries between InfoCubes dialog box appears.
2. Select the required source and target InfoCube.
3. Choose Continue. A selection box appears that contains all the queries of the source InfoCube.
4. Select a query from those available.

You have the following options for selecting multiple queries.
• To make several selections from the list, select the required queries with a mouse click and the Ctrl key.
• If you want to select several queries that are next to each other in the list, you can select whole blocks by holding down the Shift key.

5. Choose Transfer Selections.

Note the following if you are working with reusable sub objects such as variables, structures, calculated key figures and restricted key figures:

• Variables are not dependent on InfoCubes so they are not copied.
• If you select more than one query to be copied and these queries reference reusable sub objects that are next to each other in the list, the system only makes one copy of the sub object. The references of the copied queries are retained.
• If you copy queries again at a later time, the system creates new sub objects. The references to queries that have already been copied are lost.

6. Change the technical names of any copied query components in dialog box Rename Components.

7. Choose Continue.
Result:
The copied queries and the copied sub objects have their own names. The new names are derived from the name of the original object and the added element _.

This does not affect variables, since they are not copied.

Example:

The queries weekly report, monthly report and annual report use company code as a variable and the calculated key figure contribution margin. If you copy the queries weekly report and monthly report into another InfoCube, the queries weekly report_1 and monthly report_1 are created along with the calculated key figure contribution margin_1. The new queries refer to the new key figure contribution margin_1 and the variable company code.
If you copy queries quarterly report and annual report, a new calculated key figure, contribution margin_2, has to be created as a copy of contribution margin. Quarterly report_1 and annual report_1 then refer to contribution margin_2 and not contribution margin_1. Company code is still used as a variable.