Planning

Get Involved. Join the Conversation.

Topic

    Jash Joshi
    Converting on premise BSO cube to PBCS ASO
    Topic posted June 29, 2019 by Jash JoshiRed Ribbon: 250+ Points, tagged Financial Planning, Integration, PBCS, Planning, Projects, Reports, SmartView, Workforce 
    90 Views, 4 Comments
    Title:
    Converting on premise BSO cube to PBCS ASO
    Content:

    Hi All,

    I have a requirement to convert the on-premise BSO cube to the PBCS ASO cube. On-premise BSO cube is mainly used by the client's users as a reporting cube. It has dimensions 11 dimensions, account dimension has around 140 member formulas and few calculation scripts. Member formulas has functions like @ISMBR, @Relative and @SUM etc.

    Account and Entity dimension has lot of members as Ignore and in ASO if you want to use consolidation operator as ignore than you have to make parents as a label only, this affects the reporting at the parent level.

    I would like to know, whether we should go for the ASO cube conversion or not? and if we should go for it? what are the things that we should keep in mind while converting BSO to ASO?

    Thank You.

    Regards,

    Jash Joshi

    Comment

     

    • Mark Rinaldi

      This is the ultimate "It depends" question.  ASO is meant as a reporting solution for data sets with many, large, dimensions and sparsely populated data.  ASO cubes are fully dynamic with all upper level members set as such.  An ASO model provides instant aggregations, which makes it ideal for pure reporting solutions.

      Be sure to read the ASO chapter of the Planning Admin Guide for more information. You should also read the Calc Manager chapter on Using ASO Components to Design Business Rules.

    • Vatsal Gaonkar

      In addition to what Mark is stating here are some considerations for your BSO to ASO conversion - 

      1) Time Balance - ASO will not have time balance conversion from BSO to ASO. Best practice is to create another dimension to house a Load member, and other time balance members such as QTD, YTD, HTD and so and so forth. In some implementations I have built alternate roll-ups in the time periods dimension, but found this approach cumbersome while dealing with average and first time balance formulae

      2) Consolidation operators - Very important to keep in mind the position you are stating in question/ statement.

      3) BSO member formulae to ASO MDX member formula conversion - you will have to convert all your BSO member formulae to ASO MDX formula

      4) Mark has already pointed you to the business rules conversion section

      5) Merging of data slices - It is best to merge data slices in the ASO plan type to ensure optimal performance in addition to the aggregate views - https://docs.oracle.com/en/cloud/saas/enterprise-performance-management-common/prest/pbcs_merge_data_job.html

      Hope this helps 

      Vatsal

    • Kyle Goodfriend

      Go for it.  I have not had a situation where performance was not better.  It might take you some time to get familiar with MDX but you will love it.  Make sure you use the NONEMPTYTUPLE and NONEMPTYMEMBER operators.

      • Peter Nitschke

        I do agree - you'll generally find a lot of optimisations available for ASO when it's primary function is a reporting cube. 

        MDX (black magic wrapped in brackets) does takes a little bit of getting used to, but isn't horrific once you do. You'll also need to understand the basics of solve order (kind of like two pass on steroids) to deal with the reporting order of KPIs -> Views - > Scenario Variances

        Some more complicated things (allocations \ FX conversion etc) are available as well (albeit slightly more complicated) but can be highly performant. 

        p