BPC NW Script Logic Troubleshooting Survival Guide

[damovand]

You have basic to intermediate knowledge of BPC script logic syntax and you need to troubleshoot a BPC logic issue.  By following the steps in this survival guide, you can identify the root cause for most logic issues. This content is also available in KBA 2239549 - BPC Script Logic Troubleshooting Survival Guide

 

Pre-requisites:

 

1. Basic knowledge of BPC logic syntax.  The following are the online help for Logic Keyword References and syntax

 

BPC 10.1 classic

BPC 10

BPC 7.5

 

1. Knowledge of UJKT.  UJKT is a BW transaction code that invokes an ABAP program through SAPGUI for testing BPC logic script.  UJKT will show you more detailed diagnostics and you can verify if your script is working correctly.
   
   
   
   • For more details see UJKT user guide
   
   
   
   


2. Access to an exact copy of the BPC environment/model where the logic is not working as expected.  This is required to run tests and to simplify the problem logic script. If you do not have an exact copy create a copy using BPC Administration functions.


3. The following steps should be followed in the prescribed order.

 

Identify the problem with the following questions: The questions can be roughly divided as What, When and How

 

WHAT

 

1. What version of BPC and NW are in use?


2. What type of logic is executing? (Script logic or business rule)


3. Is the logic producing a specific error? If yes,
   
   
   
   1. Review and analyze the error in the logs or system dump
   
   
   2. Look for any existing notes and KBA for the error
   
   
   
   


4. Is the logic completing successfully but producing incorrect results?


5. Is the problem data dependent, e.g. happens only to a specific date or account?  If yes,


6. Is there anything special about the data region that is not producing correct results? For example, is it the start of a calendar year, or a specific base node that was recently added or moved (master data modification)?


7. Does the problem happen in all systems, DEV, QA, and production? If the problem does not happen in all systems then what are the differences between the systems.  Be Specific about
   
   
   
   1. Notes applied, SP version difference for BPC and BW,
   
   
   2. Transaction and master data differences, especially if the problem is data dependent
   
   
   
   

 

WHEN

 

1. When did the problem start
   
   
   
   1. Has the logic ever completed successfully for the problem data region?
   
   
   2. When was the last time the logic completed correctly?
   
   
   3. What has changed since it last worked as expected? If you don’t know the exact answers then establish a probable scenario by following questions
   
   
   
   


2. How often and when do you execute the logic?


3. When was the last time the logic validated correctly, was your system on the same version?


4. Who executes the logic


5. What is the usual process or the data region for executing the logic


6. Does the problem happen, every time the logic is executed?


7. If random when does it seem to happen most often?  Does it seem to happen after a recent master or transaction data modification?


8. How often does master data change and what changed in the last modification?

 

HOW

 

1. Steps to reproduce
   
   
   
   1. How is the problem logic invoked, is it through DM package or is it executed as default logic when sending data
   
   
   2. If the problem logic is the default logic, can be executed when sending data or through a DM package, are the results the same both ways?
   
   
   
   


2. Does the logic produce the same behavior when executed through UJKT?

 

 

Trouble Shooting Steps

 

 

1. Use a simplified version of the logic, it needs to be a single block of statements with one simplified *REC statement.  There are two ways that a logic script can have many blocks.
   
   
   
   1. The logic has multiple *WHEN/ENDWHEN, *RUNALLOCATION or *RUN_PROGRAM blocks repeated several times in one file.  Remove all but one block for testing.
   
   
   2. Logic file has several *INCLUDE statements.  Every *INCLUDE statement references a new logic file.  When you execute a logic with several included files, you are executing all the logic contained in all the included files. Find the logic within the included file that is causing the problem and test only that logic.  Simplify the logic as described in step 1.i before testing it.
   
   
   
   


2. Replace as many parameterized values (anything between %) or variables (anything between $) with hard coded values. Often the problem is due to parsing of a parameterized value.  Removing the parameters and then adding them back one by one will show which one is causing the problem


3. Use simplified test data region, either the problem data region or any data region with test data available.
   
   
   
   1. Reduce the data region that is tested by replacing parameterized scope statements in *XDIM_MEMBERSET with individual parent or child nodes.
   
   
   2. If the problem is occurring for a particular data region, then replace the parameters in *XDIM_MEMBERSET with only the members that are to be tested.
   
   
   3. If the problem is occurring for all data region, then use a random test date region.  Replace the parameters in *XDIM_MEMBERSET with the specific data region selected for testing.
   
   
   4. Reduce the scope by removing keywords likeunless if that is the root cause of the error.
   
   
   
   


4. Reduce the complexity of *REC statements. Remove all the nested WHEN/ENDWHEN and REC statements.


5. Test the logic using UJKT, first by running in simulated mode


6. Review the error in UJKT.If you do not find any error when executing the simplified version of the logic through UJKT, add to the complexity of the original script in stages and test.


7. Review the diagnostics generated in UJKT.  Refer to example 2 in the attached document for more clarification


8. If the logic is for executing business rules, validate that the scope and context are passed correctly and then follow the guide for troubleshooting business rules, and master data configuration

 

Analysis of the information:

 

 

1. In most simple cases, you experience a problem after one or more of the following situations is met.  In such cases, you need to reproduce and verify the issue, using a simplified version of the logic and executing through UJKT. You can report the problem to SAP if it has not already been reported. The cases that qualify for this are:
   
   
   
   1. After System upgrade / migrate form a different version of BPC,
   
   
   2. After applying some notes,
   
   
   3. Changes made to master data
   
   
   4. Logic being executed for a new data region for the first time
   
   
   
   


2. If the problem is not due to any of the above conditions then you need to analyze the information further. Typically, you have development, QA and production systems.  You need to focus on two different lines of analysis when the problem happens in all systems and when it does not.
   
   
   
   1. The problem happens in all systems, but the same logic was working in the past few years and you don’t know exactly when the problem started,
      
      
      
      1. Focus on the last time the logic was validated and tested successfully in each system and confirm if you were on the same version of BPC and BW.  Sometime code bugs can remain hidden until you validate the logic. Refer to Example 3 in the attached document for further clarification
      
      
      
      
   
   
   2. The problem happens only in one system.  Analyze differences in master data and transaction data as well as system versions and configuration.
      
      
      
      1. Focus on differences between the problem system and working system.  Make sure to consider, notes, system upgrades, master data, transaction data
      
      
      2. If you confirm all versions and notes applied are the same across the system, then focus on master and transaction data differences.  By narrowing the scope to just one data region, as described in trouble shooting steps – items 2 and 3,  you can find and test the problem data region.
      
      
      
      
   
   
   
   


3. What if the error happens only when it is invoked a certain way?  This can be very well due to differences in the scope of the logic.  When the logic is invoked through data manager (DM) its scope is what is known as "external scope" set by the values selected through DM interface. When the logic is invoked through other methods it is subject to "internal scope" set by *XDIM_MEMBERSET.  For example default logic can be invoked by executing DM package DEFAULT_FORMULAS or when sending data through input forms.  The same default logic could have different results due to differences in the scope.  to learn more about the scope of default logic please review the SCN document.

When logic is executed through UJKT its scope can be controlled.  If the problem does not happen when executed with a simplified scope then the root cause is in the scope or the parsing of parameterized values for scope.