Oracle Analytics Cloud and Server

Welcome to the Oracle Analytics Community: Please complete your User Profile and upload your Profile Picture

Copy Dashboards from My Folder to Shared Folder

Received Response
331
Views
13
Comments
3310714
3310714 Rank 6 - Analytics Lead

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? 

«1

Answers

  • Joel
    Joel Rank 8 - Analytics Strategist

    That is the process.

  • 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
    3310714 Rank 6 - Analytics Lead

    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
    Joel Rank 8 - Analytics Strategist

    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]
    [Deleted User] Rank 2 - Community Beginner

    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
    SPowell42 Rank 5 - Community Champion

    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]
    [Deleted User] Rank 2 - Community Beginner

    Will never happen

  • SPowell42
    SPowell42 Rank 5 - Community Champion

    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]
    [Deleted User] Rank 2 - Community Beginner

    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.

  • 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).