nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Oracle Communities

Oracle Analytics and AI

Child Item

Copy Dashboards from My Folder to Shared Folder

3310714

Hi,

I created an Analysis and added it into a Dashboard in My Folders. I copied both the Analysis and Dashboard to the Shared Folder for others to see, but the Dashboard doesn't work. Getting an error "Referenced Catalog Object Inaccessible". I have to re-link the Analysis to the version sitting in the Shared Folder. Is this always the process if we copy Dashboards from one folder to another folder?

Find more posts tagged with

Accepted answers

All comments

Joel Acha

That is the process.

Gianni Ceresa

To extend what @Joel Acha posted (which is correct) it's not about a process it's just how the tool works.

Object embedded into a dashboard are referenced by an absolute path and not a relative one based on the dashboard itself. So your analysis added to a dashboard will be referenced by it's position from the root of the catalog.

This means that if you move your dashboard around the catalog it will keep working and still display the same objects.

In your case the problem is that you start from "My Folder" which is a private location. So your dashboard when you move it in the shared folder continue to link to the analysis using the absolute path pointing to your "My Folder" and this give you the error.

If you want to avoid to have to re-link all the objects in your dashboard you must develop it directly in the shared folder linking analysis stored directly in their final folder.

It's up to you to adapt your development process based on your needs knowing how OBIEE link objects in a dashboard: absolute paths from the root of the catalog.

3310714

Thank you guys for the insights! I will adapt my process for dashboard development.

Since dashboards are based on absolute paths, I'm assuming it will be fine when I migrate it (Archive/Unarchive) from one environment (DEV) to another (TEST), given I maintain the same folder structure under Shared Folders.

Joel Acha

That again is correct. If the structure is kept the same in all your environments then catalog migration is much easier and no additional work is required after archiving/unarchiving.

[Deleted User]

Yes.

As I recently stated in another thread - OBI uses one of two ways of referencing things:

1.) Absolute paths / fully qualified names like for dashboard object mappings and intra-object references in the XML and

2.) ID referencing as it is used for dashboard customizations.

So watch out as when you move stuff you need to think about both!

SPowell42

I so wish they would update the system to use relative paths. Doesn't seem like it should be that hard to do. Put in a request for this many many years ago but hasn't happened.

Scott

[Deleted User]

Will never happen

SPowell42

Hi Christian, is there something in the code that prevents them from doing this?

One note, in the past I've used the XML find / replace functionality in the catalog manager to update the absolute paths to the new locations. This works pretty well...but I'm always hesitant to use it. For the most part, we have folks develop in our DEV environment in the same location as where it will end up in Prod to prevent issues. But the xml find and replace does work.

Thanks,

Scott

[Deleted User]

Not in the code, no, but it's just a lot more convenient to keep using fully qualified paths. Several objects can share a name, reference and lifecycle checks work nicely (extended usage tracking, orphaned objects, missing refs etc), XML search&replace is very literal compared to if you had to use IDs or relative paths (so you only ever replace objects you really want) etc.

Gianni Ceresa

Actually an absolute path is easier for debugging and maintaining the catalog "from outside".

Using relative paths would be easier at a first look if objects (analysis, prompts etc.) are inside the dashboard folder, but if outside when having to deal with ../ etc. is easily a nightmare ...

And the relative path would make search/replace a lot more dangerous (same relative path for different objects and so a search/replace will replace things not supposed to be changed).

So I can only say that as long as you have backups in place search/replace is the simplest way (my opinion at least).