Skip to Content
*A reservation of a different kind – why, what and how of BPC name space* Having a reserved namespace is not new to SAP. Anyone who has worked in Netweaver BI arena for some time knows that the objects starting with 0 are delivered by SAP and are part of the business content (0ACCOUNT, 0AMOUNT etc.). So if you are developing some new objects, one should avoid starting anything with 0 and in fact, should use the customer namespace of objects starting with y and z for technical names. Enter stage right BPC for Netweaver and we have a new namespace for some objects created by BPC. In this blog, let us try to understand this namespace in some details. Here is the why, what and how of this new namespace.  *Why the new namespace:* Business Planning and Consolidation version for Netweaver  (BPC7NW for short) delivers almost all of the end user functionality that was available in BPC for Microsoft platform with the difference that the master data and transactional data are stored in Netweaver BI. So when the BPC user creates a dimension, a BI characteristic is created in the BI system and when he/she creates an application, BI infoproviders are created in the BI system.  So these objects are system generated objects (using a service user) and not user created. At the same time, they are not ‘delivered’ objects. So they can’t be ‘z’ objects and they can’t be ‘0’ objects. Hence there was a need for having a separate namespace for such objects. The extent of the BPC namespace can not stop just at the namespace for BI objects alone.  We should store the BPC related data dictionary separately; and hence there is a need for a separate namespace for the BPC dictionary namespace as well.     *What is the new namespace:* Now we have /CPMB namespace for all the BPC related infoobjects that are generated by the system when a BPC user creates BPC objects using BPC front end. For example, when a BPC user creates a new appset, an infoarea is created in the /CPMB namespace. When he/she creates a new BPC dimension in that appset, a corresponding BI characteristic is created in the /CPMB namespace in the same info area. Following is a screenshot of a BPC7NW system for our familiar transaction rsa1 (Datawarehousing Workbench) and it shows the BI objects in the /CPMB namespace.    image
To report this post you need to login first.

15 Comments

You must be Logged on to comment or reply to a post.

  1. Shailesh Unny
    Hi,

    Thanks for the information. I had a Q. While I understand that you do need a different namespace for these generated objects, how does this compromise the fact that you will have to load the data in multiple objects and info providers. For e.g the master data in the BI infoobject might be the exact data that we need in the BPC object. Does the creation of a new namespace not make this more difficult? For e.g can it be made configurable in the future that data for both objects is read from the same place and there is no need to replicate it?

    Thanks again.
    Shailesh

    (0) 
    1. Scott Cairncross
      Hi Shailesh,

      The purpose of this separate namespace IS to create a separate AREA that is completely segregated from the EDW, on purpose.

      You are correct you have all of the data you need for planning if you have a full fledged data warehouse, however most of the time this data is too granular for planning. You would roll up this data to the level planned at and load this into your planning model.

      Now you have a pristine environment for your finance users to work in without impacting your EDW.

      If you think about BI-IP and BPS most of the time you would have to create some redundancy as well at least as it relates to transactional data. For example, if you have a great reporting model you would need to create a real-time infoProvider in order to be able to actually write data back.

      Another huge benefit you get from this particular model is the no Data Modeling effort needs to be done. The system generates all of the objects for you (and optimizes them for you too).

      In summary, if you think about it, it makes sense to have a separate space where your finance users can run there BPC implementation without impacting your EDW.

      Make sense?

      Cheers, Scott

      (0) 
      1. Shailesh Unny
        Hi Scott,

        It makes perfect sense. There are numerous cases where this scenario will be efficient and will work.

        Consider a scenario in which the data in BPC is intended to be the same as in BI, wouldn’t some amount of flexibility in defining the namespace allow you to just reuse the BI data in BPC without having to replicate/load it again? For e.g. the CPM namespace object could just be a view on the BI namespace object if the user chooses so.

        Just a thought. I am sure this would result in several complications in the application framework etc.

        Thanks again for your response.
        Shailesh

        (0) 
  2. LOKESH NANDULA
    Hi,

    Excellent blog. We are expecting more such blogs to clarify our doubts w.r.t BPC 7.0NW. Thank you very much.

    Now its very clear that we can load master/transaction data from EDW Char/Cubes into BPC char/Cubes. Can we assume that we can also use ETL to load data into BPC Char/Cubes directly from R/3 or ECC. Or do we need to first load data to EDW Char/Cubes and then from there load it into BPC Char/Cubes.

    Can we assume that its possible to move data within BPC Char/Cubes from NW BI? If yes, then this should also work for BPC char/cubes of two different application sets.

    We create reports/input schedules in BPC. Can we format/publish the same report using BO frontend tools.

    Will BPF will exist in new releases or can we use STS. Can you please clarify roadmap w.r.t BPF. Why it wasn’t part of BPC 7.0NW?

    Please give us some inputs on BPC security and work status and how this is integrated with BI authorization concepts and data locks.

    How can we create a BPC application which is a multiprovider and not just a cube?

    If not in this blog, please include these queries in subsequent blogs.

    thanks/regards,
    Lokesh Nandula

    (0) 
  3. Pravin Datar Post author
    Hi Lokesh,
    Sorry for the delay in responding.
    You can use ETL to load master data for generated BPC characterstics. So if you want to write new extractors for doing so, you can configure them. You can get transactional data from other NW cube – so you can surely do so for NW BI cube of other appset. It will be treated as any other NW BI cube though and you will have to create the transformations, coversions etc.
    As far as the BPF and integration for BO is concerned, that is something that we can look forward to in the next release.
    BPC7NW security remains similar to that in BPC5.x. As I said in the blog, BPC front end talks with NW backend by means of a service user and hence regular BI authorization is not involved. However if you are trying to get data from other EDW cube, BI authorization will be checked for that cube(as it should be)
    Every BPC application has a multiprovider. I will write another blog to explain this further.
    Regards
    Pravin
    (0) 
    1. Wessels Crouse
      Hi Pravin,

      Thanks for the explanations, but can I have a bit more clarity around the security aspect, and your statement that “…BPC front end talks with NW backend by means of a service user and hence regular BI authorization is not involved. However if you are trying to get data from other EDW cube, BI authorization will be checked for that cube(as it should be)” ?

      What about Master Data – can I control what Master Data the end user can get from BI?  E.g. 0EMPLOYEE has Salary as an attribute – can I control which Employees’ Master Data the user can get into BPC, and/or which Attributes ?

      How do I control which Cubes (and subsets of Cubes) the user can extract into BPC ?

      In the case of Virtual Cubes, do the BI authorizations still apply?

      Thanks in advance.

      Wessels

      (0) 
      1. Pravin Datar Post author
        Hi Wessels,
        The non-BPC infoobjects and infoproviders in the EDW layer will be goverend by the regular BW security and BPC security will be applicable to the infoobjects and infoproviders in the BPC name space.
        Regards
        Pravin
        (0) 
    2. Manuel Ortiz
      Hi Pravin,

      Good information on this blog.

      We are considering using BPCNW, I have not found information on BPC retractors.  Are there any?  If not, what do you suggest would be the options as far as creating custom retractors?

      Thanks,

      Manuel

      (0) 
      1. Pravin Datar Post author
        Hi Manuel,
        In 7.5NW, we have a badi that can help youin doing retraction. In 7.0 Nw, you can write a badi to do the retraction. Make sure that the data passes through the shared query engine.
        Regards
        Pravin
        (0) 
        1. Manuel Ortiz
          Thanks for your reply Pravin.

          What is the badi in 7.5NW that we can use for refraction?  Is there any documentation that you can share?

          I really appreciate your comments & feedback.

          Regards,

          Manuel

          (0) 
  4. Mansi Dandavate
    Hi Pravin,

    I attended your session on BPC last year in TechEd. Thanks for throwing light on BPC topic. Looking forward to more blogs on the same.

    Regards,
    Mansi

    (0) 

Leave a Reply