Restrict Drill up in hierachy

Hi
i have created a report, which has some account dimensions and it has 11 level as default hierarchy
i need to show from level 04 in my report , so i have taken level 04 and rest of the levels in query and enabled the drill option,
now what happens is, it is allowing me to drill up, when i am not taking levels 01,02 and 03 objects from queries,
i dont want this to happen,
is there any way to restrict this drill up object from account level 04 alone,??
Regards
Dineshkumar

Hi,
Scope of analysis is the process of refining the data to lower levels of detail is calleddrilling down on an object.
First you set Scope of analysis. You can set the scope of analysis level when you build a query so that your query includes objects lower down the hierarchy, but the objects do not appear in the Results Objects Pane.
Steps:-
1. First drop the objects in the Result Objects.
2. Select radio button "Display by hierarchies". Opens Create Query window.
3. In Create Query Window, click on "Show/Hide scope of analysis" button.
4. Now you can see scope of analysis pane below the query filters. Now you can now define how many levels ofdetail you want to include in the data that is retrieved by the query for which you want.
5. Click on Scope level dropdown list, select levels, and run query.
6. Click on Drill button

Similar Messages

Restricting drill in graph bean ?

Hi,
Im developing a web bi app (uix) and when the user drill down from graph bean and there is no legend, there is no way to drill up. This is not so nice so i`d like to restrict this from the graph bean. It is possible from UIX or not.
More generaly, how we can set and get properties of Beans from UIX ??
Thnx:--PS

In 11g it is bug....
For this u should create 3 individual reports (1 for country, 2. Region, 3. Branch) and give action link one to another.
for filter make sure the required column "Is Prompted" for every detailed reports.
Pls mark if it helps
-Chinna

How to restrict document types in hierachy

Hi
My scenario is
For DIR of document type A only DIRs of document type B and C should be attached in the document hierarchy. How to restrict the user from attaching other type of documents?
What will be the best solution for this scenario?
Thanks in advance
Prasad K

Hi
Plz
Any inputs on this?
Regards
Prasad

Disco Viewer is slow - Maybe drilling data?

I have a Worksheet which when run in Disco Desktop runs and displays in about 1.5 seconds.
When I run it in Viewer it takes 4 seconds to get as far as displaying the title of the report and then a further 50 seconds before the main body of data appears.
I had a look at the HTML Source in Internet Explorer and it amounts to over 5Mb of HTML Source!!!
A bit of investigation reveals that a lot of this is great long lists of drill-related information.
I had noticed that every cell on the report has a little blue arrow for drilling and if I click on this and hover over Drill To Related, I get very long lists of other fields I could drill to.
I wonder whether reducing the drill possibilities to a minimum would speed things up (by 'minimise drill possibilities' I mean restricting the drilling to only the fields that I foresee anyone drilling to.)
(a) Is there a way of restricting drill possibilities?
(b) Has anyone found that adjusting drill possibilities speeds up Viewer?
(c) Any other ways to speed up viewer?
Kind regards
Suhada

Sri.
Actually what I suggesting is pretty simple in that it's 'technology stupid'.
I've found that when most clients say they want their end users to have "drill down" capabilities, what they really want is to just see summary level data in one worksheet and a few detail level worksheets, but all either from the same area (ie: gl_budgets) or by another logical grouping.
So, for example, you could have something like a summary worksheet that showed a salesperson's total sales by customer for an entered time period under a certain sales manager in a summary format (ie: only SUMs on the totals, etc.).
Then, you just know the sales manager is going to want to see a detail level of the same info but maybe show detail info and they have parameters for a time period and choosing a particular customer.
And then, they'll want another worksheet that'll be detail level again, but showing some other aspect of the data.
IMO, it really boils down to say 1 or 2 summary worksheets, and maybe 2 - 3 detail worksheets for an entire area of concern.
As for the parameters, as of 10g you have cascading parameters which allow going between the worksheets easily BUT as you mentioned, if the worksheets go to different folders (and they're not joined of course), then parameters cannot be used across worksheets.
Additionally, you can set up the drilling capability to display what you want in the EUL, but I usually find it's just not needed.
Russ

Drill down with Parent at the bottom

Does anyone know how to set the drill function so that the new rows are inserted above the parent? The default setting for inserting new rows always insert new rows below the parent. By the way, I am using BPC 5.1.

Another way is to use DEP,SELF. This gives immediate children of CV with parent at the bottom. Then if you double click on one of the children it gives you its immediate children with itself at the bottom. It allows you to drill down any hierachy and then come back up and drill down another branch.
Paul Rowbotham
CopperMan Consulting

Drill Filters In Block

Hi All,
    I have created a report with two separate tables namely Block1 and Block2.
   I have enabled a drill filters in my report.It reflects both the blocks.
   But the requirements is,I need a drill filters only for my Block2.
   How can I achieve this?Can anyone please help to solve this?
Regards,
Maya

You can use for Block1 the objects from the first query only.
For example:
=[Query1].[Region]
and for block2 you use the merged dimension:
=[Region]
If it doesn't work you can try this other way of solving it (check this link):
restrict drill downs in two blocks
Edited by: PadawanGirl on Jan 19, 2011 5:53 PM

Indivdual Drill Filters for each Block

Hello,
Is it possible to have individual Drill Filters for each block of a report in BO XI R2? Suppose i have a Cross tab report and graph in the same report, and i want to apply individual Drill FIlters for Cross Tab Report and Graph. Can we do this in BO XI R2?

You can use for Block1 the objects from the first query only.
For example:
=[Query1].[Region]
and for block2 you use the merged dimension:
=[Region]
If it doesn't work you can try this other way of solving it (check this link):
restrict drill downs in two blocks
Edited by: PadawanGirl on Jan 19, 2011 5:53 PM

Attribute with forumula to only accept 20 characters

Good evening Oracle,
Currently, I have an attribute called "Activity_Name". I have a team that has an ETL process that will only accept an attribute length of max of 20 characters.
So, I have another Attribute called "Activity_Name20".
So basically, if anything in "Activity_Name" is under characters, "Activity_Name20" will assume that value.
If there is a value in "Activity_Name" that is over 20 characters, "Activity_Name20" will assume the first 20 characters.
However, the formula I have with it is not working, and in fact, preventing me from trying to drill into the hierachy.
Has anyone dont anything similar at a client? Could use some pointers.
Thank you!

Must be an issue with the derivation logic, can you post the same,
Alternatively,try the below for Activity_Name20
SubString(PropValue(Custom.Activity_Name,1,20)
Thanks!

ODS to ODS initialization and delta

Hi All BW Gurus,
We have recently started our BW implementation for COPA module and after successfully loading all the historical data, started running into issues with delta loads. Here is the scenario. R/3 --> PSA --> ODS1 --> ODS2/Cubes. Even though ODS1 and ODS2 are exactly the same, the reason for having ODS2 was to restrict drill down reporting to transaction level detail only for the last 6 months of data. The other advantage (I think) was to do a direct update instead of going through all the logic in the start routine again.
R/3 --> PSA --> ODS1 has been succesful so far with the full loads, initialization and delta updates. Full loads from ODS1 to ODS2 and Cubes have been successful too. Once we triggered initialization without data transfer from ODS1, it errors out with a message that ODS2 already has a full update and hence we cannot trigger an initialization. Researching OSS notes, found a note (689964) for the same issue but the solution was to change all full request loads to repair requests and then trigger the initialization. At the same time they mention that we could end up with other issues with this procedure where we might have duplicate records or even loose data if we ever have to run initialization again.
Any one face this issue? Solutions or work arounds?
Thank You.
Shri

Hi Sreedhar,
It would have been simplar to have followed the OSS 689964 by changing the full loads to repair requests. I ve done it in our production boxes and have not faced any issues yet. If an administrator takes good care of his dataloads then why would a question of duplicate records come in to picture.
But since data has been deleted from ODS2 already, you could follow the step1 and step2 as mentioned, it would work. If you see the Selection Criteria completely greyed out, then please right click on the Infopackage and choose the CHANGE option, this will enable the selection criteria for that Infopackage.
But if you ask my suggestion I would advice you to load the ODS2 using Full Loads from ODS1 and then use the OSS to change full to Repair Full, then run an Init Without Data transfer.
Hope this helps.
Thanks and Regards,
Praveen Mathew

How to set hierachy to drill across multiple dimensions?

Hello
I have a situation:
There are 3 tables: Credit Manager Dim, Customer Dim and Sales Fact
There are 3 columns: Credit Manager ID, Customer ID and Document Number (from sales fact).
The request is to create a hierachy so that the report can drill from credit manager to Customers (for that credit manager) and then to all the document numbers for that customer.
I think I will need to create one hierachy that uses these 3 columns in each of the level. However, the challenge now is that one dimensional hierachy can only accept columns from one dimension tables.
Please advice
Thank you

Thanks for the reply Dbettinger.
For now I am ignoring document number part for testing purpose. In my credit manager dim, the lowest level is detail level where credit manager code is assigned under (Credit Manager Code is key enabled for drill-down). I have set the 'prefer drill path' of this level to point to Customer Dim- Detail level (where customer ID is assigned) as you suggested.
However, when I tried running the reports, the credit manager code column is still not drillable. I think it is because this column is already at the lowest level of credit manager dim hierarchy and BI server doesn't take the preferred path of deeper level (customer dim)..
This is where I am stuck.
Any idea on how to make it work?
Thanks

Drill down with manager restrict access

Group,
I applied a restricted view of an object (CITY) to a particular group.
This object belongs to a table like the one below:
TABLE X
     FIELD - COUNTRY
     FIELD - CITY
     FIELD - NEIGHBORHOOD
The restriction that I created will not allow certain group has access to the cities.
I Build a Web Intelligence report with field COUNTRY and enable drill down. When I login with the user group that owns the restrictions, it can drill from the view cities. When I update the report, I get an error because the user doesn´t have privilege to update some fields (CITY).
I need to create a restriction that makes when you can not see a field, it jump to the next filel in the hierarchy from the drill down. Is it possible? eg. COUNTRY> NEIGHBORHOOD
Thank you

This should be achievable using Report to Report Interface (RRI) or by using the Dashboard..
The requirement on the calculated key figure is not quite clear? If you could elaborate.. some one could help..

How can we Restrict the Drill Down upto certain levels

Hi Friends,
We have the Date Hierarchy with the following Levels,
Year-> Semester -> Qaurter -> Month -> Week -> Day
Our requirement is Wehen we run the Report, User would able to drill from From year- > Semester -> Quarter,We need to prevent drill down from Month to date.
Thanks
Laxman

One way is to create a role and restrict access through it
see
http://cwebbbi.wordpress.com/2011/06/22/denying-access-to-an-entire-level-with-dimension-security/
Please Mark This As Answer if it helps to solve the issue Visakh ---------------------------- http://visakhm.blogspot.com/ https://www.facebook.com/VmBlogs

Poor performance with WebI and BW hierarchy drill-down...

Hi
We are currently implementing a large HR solution with BW as backend
and WebI and Xcelcius as frontend. As part of this we are experiencing
very poor performance when doing drill-down in WebI on a BW hierarchy.
In general we are experiencing ok performance during selection of data
and traditional WebI filtering - however when using the BW hierarchy
for navigation within WebI, response times are significantly increasing.
The general solution setup are as follows:
1) Business Content version of the personnel administration
infoprovider - 0PA_C01. The Infoprovider contains 30.000 records
2) Multiprovider to act as semantic Data Mart layer in BW.
3) Bex Query to act as Data Mart Query and metadata exchange for BOE.
All key figure restrictions and calculations are done in this Data Mart
Query.
4) Traditionel BO OLAP universe 1:1 mapped to Bex Data Mart query. No
calculations etc. are done in the universe.
5) WebI report with limited objects included in the WebI query.
As we are aware that performance is an very subjective issues we have
created several case scenarios with different dataset sizes, various
filter criteria's and modeling techniques in BW.
Furthermore we have tried to apply various traditional BW performance
tuning techniques including aggregates, physical partitioning and pre-
calculation - all without any luck (pre-calculation doesn't seem to
work at all as WebI apparently isn't using the BW OLAP cache).
In general the best result we can get is with a completely stripped WebI report without any variables etc.
and a total dataset of 1000 records transferred to WebI. Even in this scenario we can't get
each navigational step (when using drill-down on Organizational Unit
hierarchy - 0ORGUNIT) to perform faster than minimum 15-20 seconds per.
navigational step.
That is each navigational step takes 15-20 seconds
with only 1000 records in the WebI cache when using drill-down on org.
unit hierachy !!.
Running the same Bex query from Bex Analyzer with a full dataset of
30.000 records on lowest level of detail returns a threshold of 1-2
seconds pr. navigational step thus eliminating that this should be a BW
modeling issue.
As our productive scenario obviously involves a far larger dataset as
well as separate data from CATS and PT infoproviders we are very
worried if we will ever be able to utilize hierarchy drill-down from
WebI ?.
The question is as such if there are any known performance issues
related to the use of BW hierarchy drill-down from WebI and if so are
there any ways to get around them ?.
As an alternative we are currently considering changing our reporting
strategy by creating several higher aggregated reports to avoid
hierarchy navigation at all. However we still need to support specific
division and their need to navigate the WebI dataset without
limitations which makes this issue critical.
Hope that you are able to help.
Thanks in advance
/Frank
Edited by: Mads Frank on Feb 1, 2010 9:41 PM

Hi Henry, thank you for your suggestions although i´m not agree with you that 20 seconds is pretty good for that navigation step. The same query executed with BEx Analyzer takes only 1-2 seconds to do the drill down.
Actions
suppress unassigned nodes in RSH1: Magic!! This was the main problem!!
tick use structure elements in RSRT: Done it.
enable query stripping in WebI: Done it.
upgrade your BW to SP09: Has the SP09 some inprovements in relation to this point ?
use more runtime query filters. : Not possible. Very simple query.
Others:
RSRT combination H-1-3-3-1 (Expand nodes/Permanent Cache BLOB)
Uncheck prelimirary Hierarchy presentation in Query. only selected.
Check "Use query drill" in webi properties.
Sorry for this mixed message but when i was answering i tryied what you suggest in relation with supress unassigned nodes and it works perfectly. This is what is cusing the bottleneck!! incredible...
Thanks a lot
J.Casas

Dynamically select drill toolbar filters

Hi,
Is it possible to use drillfilters() as dynamic variable objects to use as filter menus in the drill toolbar during "Drill mode"?
As an example, I have State and City as two objects. By default if each of these objects are used as drillable dropdown filter objects in drill mode, you see all states and all cities in the data cube by default. My requirement is to first select the State. Secondly, the logic of City dropdown should look at what was selected for State (via drillfilters()?). Based on which state I select, the list of cities would update.
Is this possible in WEBI XIR2? I have seen the cascading prompt pre-query execution but this is different. This is post-query execution.
Thanks in advance!
-Phil

Hi,
I guess this is possible.
Create a custom hierarchy in the universe for the objects state, city ...more if required and export it
you will get the option to create a hierachy as: Tools->Hierarchies->custom hierarchies->New
Now, it will give you the restricted set of cities for the selected state.
Regards,
Rohit

How can I restrict options result to only one cost center?

In transaction KS03 (Display cost Center), when I search for a cost center (hit F4), I have an option to drill down by Company code, controlling area, Cost Center Category, Person Responsible etc.
My question is, how can I restrict users to select only controlling area they are authorized for ? Is there any authorization object I can use to restrict user's access to particular value in the table CSKS ?
Thanks,
Karan.

Hi Karan,
If you want to restrict on the values users can return when using F4 lookup then there may be some useful info in the following link:
Authorization object for capacity planning CM03

Restrict Drill up in hierachy

Similar Messages

Maybe you are looking for