SAP – BPC: Implementation Lesson Learnt Part – 5.

SAP – BPC: Implementation Lesson Learnt Part – 5.

Continuing from our last series. We will discuss about the Point # 5: 'Configuration/Development Best Practices.'
      
Object & development method standardization -


       To start with in this topic, let me reiterate the term ‘Flexibility', which I was so passionate about. No doubt it is BPC's main strength, with that, I also do consider that can be a potential weakness too. Because you can do same thing in multiple different way and creative team will do anything to achieve the result with a different route. Beware, before you start developing, make your standard and guidelines, consider the best possible route to achieve a solution and communicate. A creative solution might not be always the best solution for everyday use and might not be easy to maintain and control.

Consider scalability as a building block -
       Always build/configure with scalability in mind. For example, you creating a Financanial Planning AppSet and in future you do foresee customer demand integration over there. In that scenario, do add a ‘Customer' dimension to start with. Adding dimension in BPC at a later stage is quite a job. Hierarchy eats up a considerable amount of resources while reporting. Try to limit the number of Hierarchy you build in a system.

InApp consideration -
       InApp property while designing the Dimension properties, works as in Navigational attribute concept in BI. All the BPC MDX OLAP gets loaded (overloaded) with the dimension properties if the InApp property is switched on. Studies showed more than 33% increase in response time when you clean up your InAPP properties.


Audit trail & high maintainability by ‘Request ID’ -


       The SAP BI has a concept of tracking data loads by ‘Request ID'. This helps tremendously during the support and data management process. Unfortunately BPC doesn't have any request ID concept. What BPC has a ‘Clear' package, which import zero value for the selective dataset. But there can be several scenarios (particularly in planning) where people do planning at a same overlapping combination level. To clearly segregate who did what, having a custom dimension to populate this sequence number will help tremendously.


One AppSet -

      In QA & particularly in Production always try to have only one AppSet.

Default Logic & modularization -

      Default logic in BPC gets executed every time there is a data load or input schedule sends data. So building default logic need to be well planned. If you put all the code in the default logic it will add overhead to the system. Consider modularize your code and manage better. Talking about modularization, SAP BPC can hold the entire global constants in a file ‘System Constant' in the server. The file can be found in ‘ \Data\Webfolders\\AdminApp\' location. Avoid hard coding different constants in the different program and instead use the ‘System Constant' file wisely.

Control transformation file –
       There will be cases when BPC creates input file for external system loading. In this scenario we use the DTS package to ‘Export from the Fact table'. There are examples when the column sequence gets interchanged for some reason. To counter this, always try to use a transformation file to control the different columns in the output file.

Transformation debugging –

         When you are using a conversion & transformation file testing, keep the files open in excel and try loading the data. In case there are any problems in those files, the error will be highlighted in those files. This works like a charm when you have lengthy control files.
        
Work status & Security-

         Use ‘work status' extensively rather than building complex security design.
When you are building security for the system, make sure you have 2 separate users from Application Administrator & System Administrator. SAP BPC tool is heavily dependent on this 2 segregation.

         Also during the security design, never assign a ‘Team' to another ‘Team' or grant somebody two different access profile. In BPC, whenever there is a conflict in multiple access profiles, the less restrictive access always win. All these ensure a robust and friendly security design.
It is wise to use the formatting options (for EvDRE) whenever you are creating a report. Make a format template available in the server and ask your development team to reuse it whenever they are building reports. This ensures a consistency & decrease in development effort.

Comments -

        Lastly, ‘Comments'. BPC does support the intelligent auditing process and with many other features it also has a feature of adding comment (more like metadata information). Always train your user (or force the system) to add a comment with all the base level member selected. People sometimes associate comment with one or the other dimension value blank and those are hard to find. Always remember in classical SAP means all whereas it is just the opposite in BPC.