How to:

Create Conditional Logic in SAP

Business Objects Planning &
Consolidation, version for NetWeaver

Applicable Releases:
Software Component Version Support Package
CPMBPC 800 SP18+
CPMBPC 801 SP11+
CPMBPC 810 SP07+
1. Business Scenario
Business logic is often dependent on which process is being performed. For example, during Budget season, an
EPM application will execute one set of logic over many different time periods. However, during a monthly
Consolidation process, a different set of logic will be executed to prepare data for financial reporting.

Ideally, all business logic could run on the fly or in default logic. However, it would be detrimental to
performance and data integrity if all logic ran for each individual process. Instead, the system would need to
determine which logic to run based on which process was being run. In the past, this hasnt been possible if
there is any complexity to the logic at all. Either the logic would have to be run in batches, or a custom BADI
would have to be written to execute the correct logic depending on which process was being run.

Fortunately, SAP has provided an enhancement to script logic for BPC NW which enables different logic to run
based on certain conditions. The enhancement comes in the form of a new key word, and is explained in SAP
Note 2146749 - New keyword *XDIM_SKIPNULLCHECK is introduced. A PDF of this note can be found in the
appendix.

2. Explanation
The *XDIM_SKIPNULLCHECK key word works by checking whether the next *XDIM_MEMBERSET statements
return a null value or not. If the null condition is met, the *XDIM_SKIPNULLCHECK key word will skip any code
below an *XDIM_MEMBERSET statement which returns a null value, all the way to the next *COMMIT
statement.
The practical way to force this condition is with a *SELECT statement. Within a *SELECT statement multiple
criteria can be used, and if all the conditions are met, the statement returns a valid dimension member or list of
dimension members, which can then be passed into the scope of the logic script with an *XDIM_MEMBERSET
statement. However, if all the conditions are not met, the statement will return a null value.
In the example below, we will show an example of this by leveraging the CATEGORY dimension in *SELECT
statements.
3. Setup
In our scenario, imagine that the Actual Consolidations logic should be performed by the system every time data
is loaded from BW. By contrast, Planning logic should be performed every time an input to the Budget or
Forecast Categories is performed by a user.
In this case, the master data would look something like this:
Category Dimension
ID Description RUNLOGIC
ACTUAL Actual CONSOL
BUDGET Budget PLAN
FORECAST Forecast PLAN

Note that the CATEGORY Dimension has a custom property called RUNLOGIC. This will be used to create our
conditional criteria within *SELECT statements as shown below.

In Default logic, we need to call CONSOLIDATION.LGF for the Actual Consolidations logic. For the Planning logic,
we will call a custom BADI.
Individually, these two logic calls look like this:
However, if left like the above, both calculations would run every time. To run these conditionally, we must use
*XDIM_SKIPNULLCHECK.
First, set up the *SELECT statements one to check whether the Consolidations logic should be run, and one to
check whether the Plan logic should be run. Note that the ID cannot be used twice as criteria so the RUNLOGIC
property is required.

The %CONSCAT% variable would return a null value whenever %CATEGORY_SET% is not ACTUAL
The %PLANCAT% variable would return a null value whenever %CATEGORY_SET% is not BUDGET or
FORECAST

Next, use *XDIM_SKIPNULLCHECK, *XDIM_MEMBERSET and *COMMIT statements to set the conditions for
when the logic should run:

Because of the above configuration, CONSOLIDATION.LGF will only run when ACTUAL records are submitted,
and PLAN_LOGIC will only run when BUDGET or FORECAST records are submitted.
4. Other considerations
One common issue with the *INCLUDE statement is that it will append the called logic script to the calling LGF at
runtime. Because of this, any *COMMIT statements in the included LGF will be considered by the
XDIM_SKIPNULLCHECK key word. Thus, the entire LGF is not always skipped as intended.
There are two known workarounds to this issue:
1) Remove unnecessary *COMMIT statements in the included LGF file.
Since the *COMMIT statement only serves to reset the scope or place an endpoint for *XDIM_SKIPNULLCHECK
in BPC NW script logic, *COMMIT statements can be replaced with *XDIM_MEMBERSET [DIM] = %[DIM]_SET%
statements for any scope that needs to be reset.
2) Implement RUNLOGIC_PH and call the LGF this way. When a BADI such as RUNLOGIC_PH is called, any
commit statements that are run within are not considered by the *XDIM_SKIPNULLCHECK key word so calling an
LGF with RUNLOGIC_PH is a safe way to bypass this issue. The How-To guide for RUNLOGIC_PH can be found
here.

5. Appendix
SAP Note 2146749 - New keyword *XDIM_SKIPNULLCHECK is introduced