Tools Manage Folders to share folders pitfall to watch out for

Question

Just thought I would share something I learned today. In Discoverer Administration, you have a Manage Folders function, which you access by doing Tools > Manage Folders. This lets you assign a folder to multiple business areas. An obvious advantage of this is that you only have to bring in one copy of an Oracle table into the EUL. Joins, item classes, and hierarchies associated with the folder are also available to all business areas as well, which also sounds great. Except if you are exporting/importing individual business areas rather than the whole EUL. Then you can run into potential problems with the import. At McCarthy, we do not use the Oracle seeded business areas. We develop our own. We have a development environment we use to create business areas and workbooks. When ready for users to test, we "promote" the appropriate stuff (business area and/or workbook(s)) by exporting out of development and importing to the test instance. When users approve what is being worked on, we then "promote" to production, again via export/import of business area/workbook. In this kind of environment, sharing folders caused us to run into import errors, because of trying to reference folders and joins and item classes and stuff that did not exist yet in the instance we were promoting to (had been created in another business area originally). I logged a service request with Oracle support. Support's reply is that it is their suggestion to customers to import a new copy of an Oracle table into a new business area, rather than attempt to share folders, because of this potential pitfall. So just something to consider if you want to try and share folders among business areas.
John Dickey

Answer 1

Rod,
I agree. That is another option. But it still faces potential danger. Let's say I create business area A. I import Oracle tables into that business area, say for project expenditures, project master, and people master. I create a join between expenditures and project master and a join between expenditures and people master. I create an item class LOV called Project ID LOV and assign project id column from expenditures and project master folders to that item class. I create an item class called Person ID LOV and assign person id column from expenditures and people master folders to that item class. Now I create business area B. I bring in the Oracle table for assignments. I use Tools > Manage Folders to assign the people master folder to B and the projects folder also to B. That sharing brings both item class LOVs into business area B, as well as all existing joins for those 2 shared folders. In B I do want to use the Person ID LOV. If I export and import the people master folder, I should be okay, since I am not bringing the joins or item classes in - just the folder. Next I do want to export Person ID LOV. If I then try to import that Person ID LOV, I will get import error, because this item class is assigned to a column in a folder (expenditures folder in business area A) that I have not yet imported to the target instance. So I would have to know and manage that I need to export/import the Expenditures folder first before I export/import the item class I want. Trying to manage all of this seems like it would be a pain, in my mind. You and others may disagree. The simplest process seems to be to keep the business areas self contained (or independent - whatever you want to call it) and then you can export/import using the business area option without any issues (or none that we have run into yet). That was the way things were being done before I arrived and after Discoverer training, which covered the Tools > Manage Folders function, I talked the folks into trying to share folders rather than importing new "copies" (really, a new definition) for each new business area. The concept of sharing folders across business areas sure seemed like the smart way to go at the time. Oh well, live and learn. But certainly what you have suggested would be another way to handle this kind of situation - cannot argue that.
John Dickey
Edited by: John Dickey, McCarthy on Mar 3, 2010 2:40 PM
Edited by: John Dickey, McCarthy on Mar 3, 2010 2:41 PM