sap businessobjects web intelligence 4.1_ calculation engine changes

8/18/2019 SAP BusinessObjects Web Intelligence 4.1_ Calculation Engine Changes

1/20


2/20

Aggregation of Merged Data from Business Warehou se (BW)

Merged dimensions combined with dimension objects

Custom sorts on merged objects

Data Ranking

“Ranked by” option using a dimension which is not in the table

Ranking data by a dimension, in sections

Other Functions and Calculation Changes

Previous() in a cross-table no longer returns values for the first column.

Measures will ignore incompatible dimensions

"If" expressions return the same values for formulas and variables referencing formulas

UNV vs. UNX Count projection function

Automatic formula rewrite mechanism

Automatic formul a rewrite mechanism rul es

IntroductionThe calculation engine for Web Intelligence was updated for Business Objects XI 3.0 and 3.1 to include several corrections

and improvements. These changes are present in the 4.1 releases.

This document describes these changes and the way they might affect the calculation results in Web Intelligence documents.

Where() Operator

"Where" operator works on measures

Prior to XI 3.0, the "Where" operator accurately supported conditions on dimensions or detail objects only. Conditions on

measures were possible, but did not always return accurate results.

Web Intelligence XI 3.0 fully supports the usage of measures in "Where" conditions.

More details can be found in the documentation.

“Where” operator on measure with a condition on a formula based ona dimension

Previously, dimensions were incorrectly added to the dimensional context of the condition. Now dimensions are only used fo

the conditional evaluation.

=[Revenue] Where ( DataProviderType(DataProvider([Quarter])) = "Universe";))

when used in a table with [Quarter], the result of the formula with the condtion was processed without [quarter] in the table

(same value replicated for each different quarter).

Document migration:

User can aggregate on the related dimension in the context of the measure (=[Revenue] ForAll([Quarter]) Where (

DataProviderType(DataProvider([Quarter])) = "Universe";))

From BI 4.1 SP03, to ensure that you receive results for this formula that correspond to the previous document versions, the

http://scn.sap.com/docs/DOC-39973#jive_content_id_Automatic_formula_rewrite_mechanism_ruleshttp://scn.sap.com/docs/DOC-39973#jive_content_id_Automatic_formula_rewrite_mechanismhttp://scn.sap.com/docs/DOC-39973#jive_content_id_UNV_vs_UNX_Count_projection_functionhttp://scn.sap.com/docs/DOC-39973#jive_content_id_If_expressions_return_the_same_values_for_formulas_and_variables_referencing_formulashttp://scn.sap.com/docs/DOC-39973#jive_content_id_Measures_will_ignore_incompatible_dimensionshttp://scn.sap.com/docs/DOC-39973#jive_content_id_Previous_in_a_crosstable_no_longer_returns_values_for_the_first_columnhttp://scn.sap.com/docs/DOC-39973#jive_content_id_Other_Functions_and_Calculation_Changeshttp://scn.sap.com/docs/DOC-39973#jive_content_id_Ranking_data_by_a_dimension_in_sectionshttp://scn.sap.com/docs/DOC-39973#jive_content_id_Ranked_by_option_using_a_dimension_which_is_not_in_the_tablehttp://scn.sap.com/docs/DOC-39973#jive_content_id_Data_Rankinghttp://scn.sap.com/docs/DOC-39973#jive_content_id_Custom_sorts_on_merged_objectshttp://scn.sap.com/docs/DOC-39973#jive_content_id_Merged_dimensions_combined_with_dimension_objectshttp://scn.sap.com/docs/DOC-39973#jive_content_id_Aggregation_of_Merged_Data_from_Business_Warehouse_BW


3/20

system automatically rewrites the formula using an ad-hoc parameter with the “where” operator to specify the dimension to

take into consideration ((=[Revenue] Where ( DataProviderType(DataProvider([Quarter])) = "Universe";([Quarter]))).

This functionality is available as of BI 4.1 SP03 for documents created using the following versions:

XIR2 all releases

XI3.0 all releases

XI3.1 SP01 RTM and All FPs

XI3.1 SP02 RTM and All FPsXI3.1 SP03 RTM

XI3.1 SP04 RTM

XI3.1 SP05 RTM

BI4.0 SP01 RTM and All Patches




For more details, refer to the Automatic Formula Rewrite section, below.

Interaction between a context modifier on a measure aggregation andthe “Where” operator

Dimensions were incorrectly added as dimensional contexts into the list of dimensions for the context modifiers that have

been applied to a measure. This problem happened when "where" operators that used conditions on dimensions were used

on expressions that used measures and context modifiers.

Example:

AggregationFct( [measure] forall([dim1]) ) where ( condition on [dim2])

Was processed as: AggregationFct( [measure] forall([dim1];[dim2]) ) where ( condition on [dim2])

Is now processed as: AggregationFct( [measure] forall([dim1]) ) where ( condition on [dim2])

Interaction between a context modifier on a dimension and the“Where” operator

For a “where” operator with a condition on a dimension applied to an expression on a dimension with context modifier, the

dimension of the condition was incorrectly added to the context modifier.

Example:

[dim 1] in ([dim 2]) where( condition on [dim1]) was

Interpreted before as: [dim 1] in ([dim 2],[dim1) where( condition on [dim1]) and isInterpreted now as: [dim 1] in ([dim 2]) where( condition on [dim1])

Migration:

To get the previous behavior, swap the “where” operator and the context modifier. Example: [dim 1] where( condition on

[dim1] ) in ([dim 2]).

“Where” operator is incorrectly applied when outside of anaggregation expression

For a “where” operator with a condition on a dimension outside an aggregation function, the “where” condition was incorrectly


4/20

applied before the aggregation calculation. The condition is now applied after the aggregation with the respect to calculation

accordingly of the parenthesis.

Example:

AggregationFct ([meas ure]) Where([dim] ..).

Before, where([dim]) was applied on measure before “agregationFct”.

Now, “aggregationFct” is applied on [measure] and the “Where” is applied after.

Migration:To get the previous behavior, move the “Where” expression inside the parenthesis. Example: AggregationFct ([measure]

Where([dim]…))

Filters

NoFilter() function and “In Break” context modifier

When using the NoFilter() function, the filters would be applied when they were not supposed to, if an "In Break"parameter was used. This problem has been fixed and the filters are now ignored, as expected.

Using filters on object details with multiple valuesDetails can have multiple values. When displayed in a table together with the dimension object which they depend

on, they could show #MULTIVALUE (when there are multiple detail values for a single dimension value), unless the

“Avoid duplicate row aggregation” table setting has been checked.

Filtering on details with multiple values would not select the individual values on rows where they show as

#MULTIVALUE. To work around this issue, it was then necessary to check the “Avoid duplicate row aggregation”

table setting.

This problem has been fixed: when a filter is applied to an object detail where it shows as #MULTIVALUE, this wil

correctly select the actual value. Example: We have an object [Range] with a detail [Detail] which has multiple values:

We set a filter on [Detail] to select the values “220” (which is part of the #MULTIVALUE) and “350”.

Before the fix: Error: the “220” [Detail] value does not show in the table, although it has been selected in the filter:

http://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-718865/Table+with+detail.png


5/20

After the fix:The “220” [Detail] value will correctly show in the table, even when the “Avoid duplicate row

aggregation” setting is unchecked:

Versions where this behavior has changed:

XI 3.1 since SP7 patch 3

4.1 since SP4 patch 10, SP5 patch 6, SP6 patch 1 and SP7

Running Calculations

Running calculations will not reset

After 4.1 SP03, the runnin g calculations wil l not automatically reset for each n ew section value. As a result, the calculation for

the first cell of a block for a particular section value instance is based on the last cell value of the block from the previous

section instance.

Before 4.1 SP03, the running calculation was reset for each new section value. In the example below, the running sum for 2005 (cell in bold) is independent from the running sum for 2004.

http://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-718867/With+a+filter+on+Detail+-+after.pnghttp://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-718866/With+a+filter+on+Detail+-+before.png


6/20

After 4.1 SP03, the runnin g calculation for the current section value is based on the calculation from the previous section. In

the example below the running sum for 2005(cell in bold) is based on the running sum for 2004.

Migration:

To keep the original behavior, specify a list of dimensions as a reset parameter (3rd parameter of the function

running[Calculation]):

=RunningSum([Sales Revenue];([State])).

From 4.1 SP03, to ensure that you receive results for this formula that correspond to the previous document version, the

system automatically rewrites this formula accordingly (using the keyword "section" as 2nd operand of the running

calculation). This function is available only for documents created before XI 2 SP 05.9 versions. For more details, refer to the

following section "Automatic formula rewrite" .

http://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-422091/Reset2.jpghttp://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-422090/Reset1.jpg


7/20

Data order in running calculations

A run ning calculation was not respecting the order of the data but the default order of the result set. The running calculation

now takes into account the graphically displayed order of the data (table or chart).

Running calculations in cross tables and reset context

By default “Running Sum” is evaluated in a cross-table following a row direction (from left to right row by row).

With XI.x version, when adding a dimension as reset context (3rd parameter), the “running sum” was improperly evaluated on

column based direction (from the top to the bottom column after column).

Now, in this case it is processed following a row direction.

Example: =RunningSum([Sales revenue];([State])),

Previously: column direction (wrong) processing:

New behavior: row direction processing:

Migration: to get the previou s result (processing by column) with a new version (BI 4.1 SP03), the user can use the value

COL as 2nd parameter.

From BI 4.1 SP03.3, to ensure that you receive results for this formula that correspond to the previous documentversions, the system automatically rewrites the formula using an ad-hoc parameter FORCE_COLwith the

“RunningSum” function to force the process order to column in ther body of the cross-table.

This functionality is available as of BI 4.1 SP03.3 for documents created using the following versions:

All XI 3.X versions,

BI 4.0 patch 2.20, 2.21

BI 4.0 SP5 and all patches

BI 4.0 SP06 and patches 6.1, 6.2, 6.3, 6.4

BI 4.0 SP07

BI 4.1

BI 4.1 SP1 and patch 1.1

For more details, refer to the section on Automatic Formula Rewrite, below.

Running sums with reset in cross table footers

In cross-table footers, the RunningSum() function will sum up the values of its measure

per row if it is in the row footer

per column if it is in the column footer

Example:

In the following table, we have a running sum of the measure used in the body, in the column and row footers:


8/20

If this running sum has a reset dimension on one of the cross-table axis, then it will reset its value at the end of this

axis. On the other axis, the reset dimension will be ignored. For example, in the footer of each row, if the reset

dimension is [Year]:

Similarly, with [Quarter], in the footer of each column:

In previous versions, the running sum in the footer of the other axis would give unpredictable results. Typically, with

a reset on [Year] in both the row and column footers, the result in the column footers would be meaningless:

Versions where this wrong behavior has been corrected:

XI 3.1 since SP6

4.0 since SP4

4.1

http://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-874897/Clipboard04.pnghttp://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-874896/Clipboard03.pnghttp://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-874895/Clipboard02.pnghttp://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-874873/snapshot.png


9/20

Date Functions

LastDayOfWeek() uses Monday as first day of week

To respect the ISO 8601 standard, and to be consistent with the DayNumberOfWeek() function, the LastDayOfWeek() function

now considers Monday as the first day of the week instead of Sunday.

Example:

XI R2: LastDayOfWeek(todate(“05/11/2005”;”MM/dd/yyyy”)) returns 14 May 2005 (Saturday),XI 3.1: LastDayOfWeek(todate(“05/11/2005”;”MM/dd/yyyy”)) returns 15 May 2005 (Sunday).

Migration:

To keep the original behavior, use the RelativeDate() function:

RelativeDate(LastDayOfWeek(todate(“05/11/2005”;”MM/dd/yyyy”)),-1) returns 14 May 2005 (Saturday).

Wrong time zone for formula with “CurrentDate” and a date field

The time zone of the server was applied to the “CurrentDate” evaluation (instead of UTC) when used with another date field

in a formula. It is now evaluated in the UTC time zone.

“Week” function

The function “Week” was returning an incorrect number for when the last day of a leap year is a Monday. (This situation

occurs every 28 years).

Before update: Week # of Monday December the 31th of 2012 = 53

After update: Week # of Monday Decembe r the 31th of 20 12 = 1

“MonthsBetween” function

A set of days over two months w as considered a month if the starting day # < ending day # of ending date. This was not

working for months ending with day 30 (29/28) compared to a month ending with day 31.

(4.1 SP1 to come) A set of days over two months is now considered a month if the starting day # ending day # .

Before fix: MonthsBetween(31/03/2008 , 30/04/2008) = 0

After fix: MonthsBetween(31/03/2008 , 30/04/2008) = 1

Merged Objects

Aggregation functions return correct values for original dimensionsinside merged dimensions

Prior to XI R2 SP06, Web Intelligence did not return a correct result in the body of a table when aggregating an original

dimension that participates in a merged dimension. (Note that the result is correct when the related dimension is in the table

or in a free standing cell).

In the example below, depending on the query , the number of resorts is different. When asked for a count of the resorts from

query 1 or 2, Web Intelligence returns the total number of resorts for the merged object instead of the individual object.


10/20

After SP03, the system returns the correct count for the queried objects.

Aggregation functions can process individual objects inside a mergedobject

The aggregation function (e.g: Count, Min, Max) applied to an object [A] participating in a merged object, was processed on

the value set of the merged object instead of the given object [A]. It is now processed on the original object [A] value set.

Document migration:

To get the previous behavior, you can replace the original object by the merged object.

From BI 4.1 SP03 (patch2 or upper required), to ensure that you receive results for this formula that correspond to the

previous version, the system automatically rewrites the formula using an ad-hoc function “useMerged” with the aggregation

expression as a parameter to force the use of the merged dimension. This is available on request on BI 4.1 SP03 for reports

created with earlier version of XI 3.1 SP03.2. For more details, refer to the following section:Automatic formula rewrite.

Aggregation on a variable based on individual objects inside a mergedobject

An aggregation on a variabl e object whose formula is based on an object [A] that is participating in a merged object, w as

processed based on the merged object instead of the given object [A]. The aggregation is now processed according to the

given object [A].

Migration:

http://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-202371/5_1_b.pnghttp://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-202370/5_1_a.png


11/20

To get the previous behavior, replace the original object with the merged object.

Aggregation in free cells of an object participating to a merged object,combined with the Where() operator

In free cells, the aggregation function (e.g.: Count, Min, Max) applied to an object [A] participating to a merged object was

processed on the value set of the merged object instead of the given object [A], when the context of this aggregation was

modified by the Where() operator.

Workflow example:

1. We have a first query “Query1” giving a single value for the [Year] dimension and a second query giving two other

values for the same dimension.

2. When in a table, the formula =Count([Query1].[Year]) Where([Query1].[Quarter]=”Q1”) would return 1, which is the

correct result.

3. When in a free cell, the same formula would return 3, which is the result of the merged [Year] dimension (the single

value from Query1 + the two values from the second query).

This behavior was found in WebI XI 3.1 SP1 and was corrected in XI 3.1 SP2.

A reg ression was found in the fol lowi ng versions, when the “Extend merged dimension values” document setting was

activated:

XI 3.1 SP5 FP5.6

XI 3.1 SP6 FP6.3 to FP6.5

XI 3.1 SP7

This regression was corrected on the same branches, in later patches.

To get the previous behavior, replace the object with the merged object.

Aggregation of Merged Data from Business Warehouse (BW) Data fetched from a BW data source have a unique key allowing data with similar values to be treated as different.

In earlier versions of WebI 4.0, this key was wrongly managed when the data was merged, resulting in spurious

rows when in a table, such as in the example below.

Example with [Region] as the merged dimension:

Since WebI 4.0 SP5 patch 5, this issue has been corrected. The keys are correctly managed and the above table

will show the properly aggregated data with no additional rows:

http://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-671987/img1.png


12/20

Versions where this issue has been fixed:

4.0 SP5 patch 5

4.0 since SP6

4.1 since RTM

Merged dimensions combined with dimension objects

When using in the same table a merged dimension and an object participating to that merged dimension, Web

intelligence 4.0 will perform an intersection of the values coming from the merged dimension and the values coming

from the participating object.

Example: We have two queries, each of them returning a year dimension, which are merged together:

When using the merged year with the year from the 1st query, the intersection of the two objects results in the

values 2004 and 2005, while with the year from the 2nd query, the intersection of the two objects results in the

values 2005 and 2006:

In version 4.1, this behavior has been modified and Web Intelligence will perform a union instead of an intersection

of the values. This new behavior has been implemented to comply with the general behavior of Web Intelligence

regarding the use of merged dimensions, where the merged dimension always take precedence over any object

participating to that merge, thus showing all values from the merged object.

This new behavior results in the same list of values whatever the query where the object comes from. For instance,

in the above example, this will result in the values 2004, 2005 and 2006 whether the year object comes from the

1st or the 2nd query:

http://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-702006/Image2.pnghttp://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-702005/Image1.pnghttp://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-671988/img2.png


13/20

Versions where this behavior has changed:XI 3.1 since SP4 patch 3, SP5 patch 3 and SP6

4.0 since SP5 patch 15, SP6 patch 10, SP7 patch 6, SP8 patch 1 and SP9

4.1 since SP1 patch 5, SP2 patch 1 and SP3

Custom sorts on merged objects

When defining a custom sort on an object, this custom sort is propagated to all instances of that object in the Web

Intelligence document. This is not the case with simple ascending or descending sorts, which only apply to the

block where they are selected.

When merging custom sorted objects, their custom sorts are disabled. The reason is that objects participating to a

merge all share the same list of values, which could therefore result in conflicting custom sorts. The custom sorts

are automatically re-enabled when the object is unmerged.

Note that it is still possible to define a custom sort on a merged object. This custom sort will apply to all objects

participating to the merge.

Example:

1) Before merge, [Query 1].[City] has a custom sort showing Chicago before Boston:

2) After [Query 1].[City] and [Query 2].[City] have been merged, the custom sort on [Query 1].[City] is disabled and

does not show either on the merged object:

http://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-903288/pastedImage_10.pnghttp://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-702007/Image3.png


14/20

In some Web Intelligence versions, the custom sorts are not disabled when objects are merged. Instead, the custom

sort of the first selected object is applied to the merged object as well as to all participating objects. Because of the

impact on migrated documents, this wrong behavior has been corrected.

Versions where the wrong behavior can be found:

4.1 SP5 up to patch 12, SP6 up to patch 6 and SP7 up to patch 2

Versions where the correct behavior can be found:

XI 3.1

4.0

4.1 up to SP4, SP5 since patch 13, SP6 since patch 7, SP7 since patch 3 and since SP8

4.2

Data Ranking

“Ranked by” option using a dimension which is not in the table

Up until 4.0 SP07, a dimension used in the “Ranked by” option of the Ranking functionality is always taken into account, even

when this dimension is not part of the table where the ranking is applied.

Example: Ranking the top 2 [Quantity sold] by [Store name]:

Year State Store name Quantity sold

2005 New York e-Fashion New York Magnolia 9,990

2006 New York e-Fashion New York Magnolia 11,651

2005 California e-Fashion Los Angeles 9,792

2006 California e-Fashion Los Angeles 9,869

Behavior until 4.0 SP07: if [Store name] is not part of the table, this will not modify the ranking:

Year State Quantity sold

2005 New York 9,990

2006 New York 11,651

2005 California 9,792

http://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-903290/pastedImage_0.png


15/20


Starting from 4.0 SP07, if [Store name] is not part of the table, then the “Ranked by” option is ignored and we therefore get a

different ranking. Note that, in this particular case, the aggregated measures are not sorted ([Quantity sold]):

Year State Quantity sold


2006 New York 19,109

This behavior change can be found into the following versions:

In BI 4.0:

SP07, since Patch 7

SP08, since Patch 3

SP09, since Patch 1

SP10 and all patches

In BI 4.1:

SP03, up to Patch 6SP04, up to Patch 3

SP05

Starting from 4.1 SP03 Patch 7, 4.1 SP04 Patch 4 and 4.1 SP05 Patch 1, we are reverting to the original behavior (prior to

version 4.0 SP07), i.e.: whether or not the dimension used in the "Ranked-by" option is part of the table, this will modify the

ranking of the table.

Ranking data by a dimension, in sections

In Web Intelligence 4.0 prior to SP11, ranked measures were not properly sorted when the data was within a section and

ranked by a dimension.

For example: top 3 [Sales revenue] ranked by [State] in the [Year] section:

When a measure is ranked by a dimension, the sort expression is: =[M] in ([D]), where [M] is the measure and [D] is the

dimension it is ranked by.

If in addition the data is within a (sub-)section, then the sort expression becomes: =[M] in ([D], section1; section2, …etc.),

where section1, section2, etc. are the expressions of the sections containing the data block. This is the sort expression which

has been fixed and which now gives a correct behavior:

http://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-627390/Wrong+sort+in+section.png


16/20

The behavior modification can be found into the following versions:

In BI 4.0, starting from SP11

In BI 4.1, since SP03 Patch 9, SP04 Patch 7, SP05 Patch 2 and later

Note that there is no behavior modification when there is no ranked by dimension defined for the ranking.

Other Functions and Calculation ChangesPrevious() in a cross-table no longer returns values for the firstcolumn.

In prior versions, the Previous() function carried the last value in a row over to the first value of the next row in a cross-table.

This behavior was confusing because there was often no link between the last column of one row and the first column of the

next.

In the following example, using XI 3.0, the first column in the second row returns the last column in the first row, even though

there is no link between France and US.

In XI 3.1, Web Intelligence no longer returns a previous revenue for US in 2004 (since there is none available for that report).

This change is also applicable when you use Previous with the COL keyword. In this case the last value in a column is not

carried over as the first value of the next column.

Measures will ignore incompatible dimensions

Prior to XI R2 SP03, a measure in a table returned an empty value when the table contained an invalid dimension present in

the section header.

http://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-202367/3_2_b.pnghttp://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-202366/3_2_a.pnghttp://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-627391/Good+sort+in+section.png


17/20

In the example below, Year and Country are incompatible:

After XI R2 SP03, Web Intelligence returns the measure value calculated u sing the compatible dimensions. In the example

below, Revenue is calculated by Country:

"If" expressions return the same values for formulas and variablesreferencing formulas

The sum of a formula containing an "If" expression will now return the same result as a variable referring to an

http://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-202369/4_1_b.pnghttp://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-202368/4_1_a.png


18/20

identical formula.

As shown in the following table, in XI R2, the s um for the formula if([Year]=”2002”;1;0) returns the sum of the visiblevalues, whereas the sum of the variable referring to the same formula (MyVarIf) returns the sum of the multipleoccurrences of the underlying data (which are hidden).

If you deselect the “Avoid duplicate row aggregation” option, you can see the duplicated data.

In XI R3 and subsequent releases, the system returns the same result for the variable and the formula.

UNV vs. UNX Count projection function

When creating a universe in Information Design Tool (IDT) or Universe Design Tool (UDT), each measure object canhave its own projection function. The projection function is the default aggregation used by the Web Intelligencecalculation engine when consuming a measure in a block. The projection function can be a sum (by default), acount, a min, a max, or it can be delegated to the data source. The projection function can also be set to “none”, in

http://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-202363/2_2_c.pnghttp://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-202362/2_2_b.pnghttp://scn.sap.com/servlet/JiveServlet/showImage/102-39973-34-202361/2_2_a.png


19/20

which case the Web Intelligence calculation engine will process the measure as a dimension (aggregation byidentical values).

The “Count” projection function counts the occurrences of each unique value in the list of values of a measure. But i

is processed differently in the Web Intelligence calculation engine, depending on whether the measure comes from a

UNV or a UNX universe:

If the measure comes from a UNV universe, the count aggregation will not take into account the empty values

of that measure

If the measure comes from a UNX universe, the count aggregation will take into account its empty values

As a result, if a UNV universe is exported as a UNX universe, a Web Intelligence document built with that universe

as a data source might show different results before and after the export operation, if one of its measure objects is

using a count projection function.

In a future version of Web Intelligence and IDT, it will be possible to choose between the two count projection

functions: count with or without empty values.

Versions where this behavior is observed:

Since 4.0 (when UNX universes were released for the first time)

Automatic formula rewrite mechanism Web Intelligence provides an Automatic Formula Rewrite mechanism that automatically modifies a selection of formulas (see

list below) in a document. The formulas that follow a certain pattern are modified when you open a document migrated from a

previous version (see above for a list of the applicable versions). After modification the formula returns the same result than

before the calculation change.

We then recommend that you save the document so that the modifications are stored in the document, thus completing the

formula rewrite mechanism.

The Automatic Formula Rewrite mechanism is available by default for documents migrated to BI 4.1 SP03 for the following

formula pattern:

“where with dim as parameter in condition”

“running calculation reset on section”

BI 4.1 SP03 (patch2 required)

“merged object in aggregation function”

BI 4.1SP03 patch3:

“running calculation in column”

The releases that apply for this solution are specified above in the sections.

Automatic formula rewrite mechanism rules

The rules to automatically modify the formulas are stored in an XML file called "Formula_migration_rules.xml", located in

the [installation directory]\[SAP BusinessObjects Version]\[OS]_[PLATEFORM]\config folder.

For example, on Microsoft Windows:


20/20

Web Intelligen ce server: (64bits): C:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects Enterprise XI

4.0\win64_x64\config

Web Intelligen ce Rich Client (32 bits): C:\Program Files (x86)\SAP BusinessObjects\SAP BusinessObjects

Enterprise XI4.0\win32_x86\config

BEWARE!!!

Modifying this file may have an unexpected impact on all of your Web Intelligence documents. In particular if you enable

the "force" attribute, the formulas in your documents may be rewritten and introduce behaviors and results that you didnot expect.

You should never use the "force" attribute for all of your documents. Use it only for specific documents. In order to do

this you should enable the "force" attribute, open the document, save it and then disable the "force" attribute

immediately afterwards.

Note: If you modify the XML file, then you need to restart the server or the application to apply the changes.

The XML file has the following content:

Where:

enable=“true” means that the rule is applied, depending on the document version.

force="true" means that the rule is applied, regardless of the document version.

sap businessobjects web intelligence 4.1_ calculation engine changes

Documents