Forum Stats

  • 3,733,796 Users
  • 2,246,820 Discussions
  • 7,856,877 Comments

Discussions

Does Application Snapshot include all levels of data

Aravind_L
Aravind_L Member Posts: 413 Blue Ribbon
edited May 2020 in Financial Consolidation

Hello,

As we design and formalize our backup and restore options in HFM 11.2 we wanted to confirm if the Application Snapshot includes all data (including consolidated ) or only base level data.

Since while restoring we would have to restore all levels, since the prior periods are locked and with metadata movement we cannot afford to reconsolidate the data.

So knowing what Application Snapshot provides would drive our design.

Best Answer

  • CBarbieri
    CBarbieri Member Posts: 1,011 Gold Trophy
    edited March 2020 Accepted Answer

    I would never recommend using the Application Snapshot for any reason at all. Performance is horrible on both the export and import. If you want a reliable backup/restore strategy I highly recommend a process of either backing up at the RDBMS level (which everyone should do daily, but some companies do more often), or backing up at the virtual server level.

    HFM stores base and parent level entity data in the database, but only base level data in the Account, ICP, and custom dimensions. Value dimension members that do not have "Total" in their names are also stored in the database.

    I also advise against any design that disallows data for any period to be reconsolidated. If you want to preserve the entity hierarchies as they were, you should use OrgByPeriod. Do not move entities from one parent to another without consolidating all affected hierarchies, years, periods, and scenarios. Such an approach would prevent you from ever redesigning or restructuring the application because there is no way you could ever come back to the locked results in the current application.

    - chris

    Aravind_L

Answers

  • CBarbieri
    CBarbieri Member Posts: 1,011 Gold Trophy
    edited March 2020 Accepted Answer

    I would never recommend using the Application Snapshot for any reason at all. Performance is horrible on both the export and import. If you want a reliable backup/restore strategy I highly recommend a process of either backing up at the RDBMS level (which everyone should do daily, but some companies do more often), or backing up at the virtual server level.

    HFM stores base and parent level entity data in the database, but only base level data in the Account, ICP, and custom dimensions. Value dimension members that do not have "Total" in their names are also stored in the database.

    I also advise against any design that disallows data for any period to be reconsolidated. If you want to preserve the entity hierarchies as they were, you should use OrgByPeriod. Do not move entities from one parent to another without consolidating all affected hierarchies, years, periods, and scenarios. Such an approach would prevent you from ever redesigning or restructuring the application because there is no way you could ever come back to the locked results in the current application.

    - chris

    Aravind_L
  • Aravind_L
    Aravind_L Member Posts: 413 Blue Ribbon
    edited March 2020

    Thanks for the feedback - we do have daily db backups

    Yes we did notice the Application Snapshot is taking a while to export and import. Was just curious if we needed to restore say - reports or grids or just metadata, then instead of doing a db restore could we leverage LCM?

    You are right - we should have incorporated OrgByPeriod , am not sure how easy is that setup going to be with preserving 10 years worth of historical data without affecting them.

  • CBarbieri
    CBarbieri Member Posts: 1,011 Gold Trophy

    LCM is a good tool for restoring or migrating non-data objects.

    Slides 5 -20 in this 2014 Kscope presentation describe what would happen if you enabled OrgByPeriod. The key issue is whether you would have hierarchy changes mid-year, or only in the first period of each year. The latter should not be a problem, but the former would be difficult if you are loading and consolidating YTD.


  • Aravind_L
    Aravind_L Member Posts: 413 Blue Ribbon

    LCM is a good tool for restoring or migrating non-data objects.---- True - that is what we experienced.

    Yes we have hierarchy changes throughout the year - and we lock the prior periods to avoid any impact cause by entity movement.

    That is why only restoring data via snapshot is working at this point.

  • CBarbieri
    CBarbieri Member Posts: 1,011 Gold Trophy

    I’ve seen this approach a few times over the years. Honestly it’s not good at all. The idea of locking data in a parent entity while moving its children to other parents is flawed. I don’t understand how anyone could consider this auditable. I’m not picking on anyone personally but just this idea is wrong. A parent entity must equal the data from its children for it to be auditable. I understand it is one approach to ensuring the history remains unchanged, but when the entity structure moves around, reporting requirements are that data history should reflect the current structure. This is why external reporting requires prior year comparison.

    If someone wants to compare data in the current structure to a prior structure, there are other solutions such as alternate hierarchies which can get cumbersome to manage, or application copies which take up database space, server resources, and can be difficult to synchronize if needed.

    On a technical level the locked parents will prevent you from ever rebuilding the application or migrating to a new solution. The reason is simple: we cannot load data to parent entities and therefore, there are only two ways I can imagine getting data into the parents. The first is to create artificial base entities under each parent. This seems like an ugly idea for the hierarchy. A second approach would be to rebuild the entity structure as it was, and retroactively use org by period. However, we can only do this if we know what structure was in place at each period in history. This could be very difficult to reproduce. Of course a third option is to not migrate the historical data, but then you have to leave it in the current HFM application, and therefore you have to maintain the HFM system until the history is no longer needed, even as you migrate to something else.

    This is why I say it is a terrible idea to lock parent entities and move the children.

    Thanos A
  • Aravind_L
    Aravind_L Member Posts: 413 Blue Ribbon
    edited May 6

    @CBarbieri - i completely agree where you are coming from - and that is definitely best practice . The only justification I can think of is having access to the unchanged data that was submitted months or years ago for reporting.

    I do understand using Org by Period should help with that.

Sign In or Register to comment.