The document goal is to help end users to use input controls to change report behavior, design, appearance, etc. using some Web Intelligence functionalities that are only available for report creators.

The objective of this document is to show how can dynamically change the sections content using input controls without asking a report creator.

The main idea is to be able to add any dimension in a section to display the measures total per section and then also change the structure of the table detail.

You can create as many sections as needed and the process is the same for 1 or n sections.

Users can enter text or not for a given section to display total and remove the associated dimension from the detail table.

Dynamic sections: objective

To simplify the usage of input controls, the user is able to enter any text in a variable driven by an input control. The another variable transform the text in an existing dimension of the report.

Here is a screenshot of a report containing 5 empty sections.

A cell is added on top of the report to explain how to use the input controls:

Enter dimension name or part of dimension name in each Section.

Example:

   Categ

   category

   Product Category

   Country

   ount

etc.

A variable associated with each variable used by the input control is created to transform the text entered by the user into a valid dimension.

And a screenshot of the report with the sections containing the valid dimensions.

You can notice that the dimensions displayed in the sections are removed in the detail table.

There is also a total table linked to each valid section.

Dynamic sections: variables definition

In the report there are 5 sections, so there are 5 variables used to enter text and 5 variables to transform the text in valid dimension.

Then in the detail table, each dimension of the body and each dimension name of the header contains a specific formula.

Variables used to enter the text and input controls

1. These variables (“Section 1” to “Section 5”) are very simple because there are defined as string with empty value à formula: =""

An input control is created and linked to each of these variables:

• Type: Entry field
• No default value
• Operator: Equal to

Here is a screenshot of one of the input controls.

Variables used by the sections

Each section is based on a variable (“Hierarchy 1” to “Hierarchy 5) that interprets and transforms the text entered by the user into a valid dimension or an empty value.

Here is the formula of variable “Hierarchy 1” based on “Section 1”:

=If [Section 1] = "" Then ""

Else

If Pos(Lower(NameOf([Product Family])); Lower([Section 1])) > 0 Then [Product Family]

ElseIf Pos(Lower(NameOf([Product Department])); Lower([Section 1])) > 0 Then [Product Department]

ElseIf Pos(Lower(NameOf([Product Category])); Lower([Section 1])) > 0 Then [Product Category]

ElseIf Pos(Lower(NameOf([Product Subcategory])); Lower([Section 1])) > 0 Then [Product Subcategory]

ElseIf Pos(Lower(NameOf([Brand Name])); Lower([Section 1])) > 0 Then [Brand Name]

ElseIf Pos(Lower(NameOf([Product Name])); Lower([Section 1])) > 0 Then [Product Name]

ElseIf Pos(Lower(NameOf([Country])); Lower([Section 1])) > 0 Then [Country]

ElseIf Pos(Lower(NameOf([State Province])); Lower([Section 1])) > 0 Then [State Province]

ElseIf Pos(Lower(NameOf([City])); Lower([Section 1])) > 0 Then [City]

ElseIf Pos(Lower(NameOf([Customer Name])); Lower([Section 1])) > 0 Then [Customer Name]

ElseIf Pos(Lower(NameOf([Year])); Lower([Section 1])) > 0 Then [Year]

ElseIf Pos(Lower(NameOf([Quarter])); Lower([Section 1])) > 0 Then [Quarter]

ElseIf Pos(Lower(NameOf([Month])); Lower([Section 1])) > 0 Then [Month]

Else ""

It’s important to notice that the user is free to enter the full name of a dimension or a part of it. There is no constraint regarding match case.

So if part of the text entered by the user is contained in a name of the dimension then we transform it into the dimension itself.

So if 2 or more dimensions contain the same part of text, then only the first 1 in the expression is taken into account.

In each section there is a total table that is displayed only if the section is not empty.

Here is a formula for one of the measures used in the table: =If [Hierarchy 1] <> "" Then Sum([Store Cost])

For this table the option “Hide when empty” is checked. It means that if the section is empty, all measures are not filled then the table is hidden.

Detail table formulas

The body

Now for each dimension in the body there is a formula.

Here is the formula for the Country dimension:

=If [Hierarchy 1] <> [Country]

And [Hierarchy 2] <> [Country]

And [Hierarchy 3] <> [Country]

And [Hierarchy 4] <> [Country]

And [Hierarchy 5] <> [Country]

Then [Country]

Here is the formula for the Year dimension:

=If [Hierarchy 1] <> FormatNumber([Year];"#")

And [Hierarchy 2] <> FormatNumber([Year];"#")

And [Hierarchy 3] <> FormatNumber([Year];"#")

And [Hierarchy 4] <> FormatNumber([Year];"#")

And [Hierarchy 5] <> FormatNumber([Year];"#")

Then [Year]

And so on for each dimension.

The idea is to display the dimension only if the dimension is not in a section, otherwise it’s empty.

The header

Now for each dimension in the header there is a formula.

Here is the formula for the Country dimension:

=If [Hierarchy 1] <> [Country]

And [Hierarchy 2] <> [Country]

And [Hierarchy 3] <> [Country]

And [Hierarchy 4] <> [Country]

And [Hierarchy 5] <> [Country]

Then NameOf([Country])

Here is the formula for the Year dimension:

=If [Hierarchy 1] <> FormatNumber([Year];"#")

And [Hierarchy 2] <> FormatNumber([Year];"#")

And [Hierarchy 3] <> FormatNumber([Year];"#")

And [Hierarchy 4] <> FormatNumber([Year];"#")

And [Hierarchy 5] <> FormatNumber([Year];"#")

Then NameOf([Year])

And so on for each dimension.

The idea is to display the name of a dimension only if the dimension is not in a section, otherwise it’s empty.

Formatting rules

For each dimension present in a section and therefore removed from the table, I created a formatting rule “Empty cell” with the following parameters:

• If Cell contents is null
  • Text size: 6
  • Border: No border

As the table contains no border, we have the feeling that the column has been removed from the report.

So I can play with the sections, to display different report contents:

You can view the video published on Youtube: https://youtu.be/MrR0i_lOzyY

You can download the Web Intelligence report attached to that publication.

Didier MAZOUE

Hi,

My scenario:

• Web Intelligence Rich Client
• 2 x Data Providers:
  • 1 x Universe data
  • 1 x Excel spreadsheet

I created both queries in Web Intelligence Rich Client and merged the common dimensions, [Address Number] without any issues. My problem started when I tried to change the unique dimension, [Long Address], in the Excel data provider to a detail object (associated to the merged object, [Address Number]) but got the following error: Web Intelligence cannot build the query or generate the report. (WIS 30351)

I tried various recommendations from SCN on error WIS 30351 without success.

In the end I found a fix\work-around on the report level by creating a new variable, [Long Address Detail] (Qualification: Detail) from the original dimension [Long Address] and then associating it with merged\linked dimension [Address Number]:

This allowed me to display data from both data providers, Universe and Excel spreadsheet, in 1 report linked on the [Address Number] .

Hope this helps

Gerrie

Hi All,

I had a strange requirement from my client to sort the data dynamically based on fields selected by end user in Read mode as not all users allowed in to go in Design Mode. I searched through a number of blogs but couldn't find anything that could really help me in this case I also noticed a query posted for similar requirement Is it possible to sort data in reading mode? | SCN. as unanswered.

I worked through it and finally got a solution that could really help us in future requirements. I will be using E-fashion universe to demo this.

In this report based on below screen shot I have Year, Article Name, Amount Sold, Quantity Sold and Margin. Now, I want end user to give a flexibility to choose the measure to which he wants to sort the data like Amount Sold, Quantity Sold or Margin.

For this we will first create a Dimension Sort Field as

[Sort Field]="Amount Sold"  ( I am just giving it a random field for the one end user wants later on it will be automatically updated based on end user selection).

Next step is to create a Input Variable that will be displayed to end user in Read Mode along with the choices to which he wants to sort the data. This Input Variable will have a Custom List Of Value containing the Texts that should be available to end user for Sorting the Data in our example we have inserted texts for "Amount Sold", "Quantity Sold" and "Margin".

Now in the next step we will create a Dimension that we will be using for Sorting the Data in the Block.

[SortVariable ]=If ReportFilter([Sort Field])="Amount Sold" Then [Amount Sold]

                      Else If ReportFilter([Sort Field])="Quantity Sold" Then [Quantity Sold]

                      Else If ReportFilter([Sort Field])="Margin" Then [Margin]

                      Else 1

Now Pull this variable in the Block and Hide this Dimension so that it should not be visible to End User. And then just sort the data in the Block based on this variable as shown in scneen shot below.

Now just select the option from the Input Control on which you want the data to be sorted in the Block and you can add up measure if you want the end user to give some more options to sort the data.

This option will be available to end user when in Read mode. The only limitation that I see with this approach is that we can give flexibility to end user on only the objects with similar Data Type like here Amount Sold, Quantity Sold and Margin are Number type if we try to include Article Name as well to the Sorting field I am afraid we will experience some weird results.

Please do share your thoughts and comments on the above approach your suggestions and comments will help me in improving this.

Best Regards

Niraj Parihar

Overview

This document describes the corrections and changes to the calculation engine in Web Intelligence 4.1 compared to Web Intelligence XI 3.1, XI 3.0, and XIR2 SP06 and SP03. It compares the new behavior of the calculation engine to its behavior in the previous versions.

It also suggests migration strategies for accommodating the calculation engine changes.

It gives a description of the formula rewrite mechanism introduced in 4.1 SP03 to preserve the reports created with an older version, from specific changes.

(Document authored by Pierre Saurel & Pascal Gaulin / Web Intelligence Product Experts)

Table of contents

Introduction

The 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 on a dimension

Previously, dimensions were incorrectly added to the dimensional context of the condition. Now dimensions are only used for 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 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 FPs
• XI3.1 SP03 RTM
• XI3.1 SP04 RTM
• XI3.1 SP05 RTM
• BI4.0 SP01 RTM and All Patches
• BI4.0 SP02 RTM and All Patches
• BI4.0 SP03 RTM and All Patches
• BI4.0 SP04 RTM and All Patches

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

Interaction between a context modifier on a measure aggregation and the “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 is

Interpreted 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 an aggregation expression

For a “where” operator with a condition on a dimension outside an aggregation function, the “where” condition was incorrectly applied before the aggregation calculation. The condition is now applied after the aggregation with the respect to calculation accordingly of the parenthesis.

Example:

AggregationFct ([measure]) 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 values

Details 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 will 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:

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 running calculations will not automatically reset for each new 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.

After 4.1 SP03, the running 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 (3^rd 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" .

Data order in running calculations

A running 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 previous result (processing by column)  with a new version (BI 4.1 SP03), the user can use the value COL as 2^nd parameter.

From BI 4.1 SP03.3, to ensure that you receive results for this formula that correspond to the previous document versions, the system automatically rewrites the formula using an ad-hoc parameter FORCE_COL with 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:

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

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 December the 31th of 2012 = 1

“MonthsBetween” function

A set of days over two months was 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 # and if ending day # is the end of the month and 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 dimensions inside 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.

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

Aggregation functions can process individual objects inside a merged object

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 merged object

An aggregation on a variable object whose formula is based on an object [A] that is participating in a merged object, was processed based on the merged object instead of the given object [A]. The aggregation is now processed according to the given object [A].

Migration:

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 regression was found in the following 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:

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 1^st query, the intersection of the two objects results in the values 2004 and 2005, while with the year from the 2^nd 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 1^st or the 2^nd query:

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:

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]:

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

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]):

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 6
  • SP04, 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:

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.

Hiding a Report Element when a Formula is True

This section is about the “Hide when following formula is true” setting. This setting can be found in the Format dialog box of any Web Intelligence report element: tables, charts, forms, sections and free cells.

Formula Evaluation when the Data is Null

Null is not 0. It is neither greater nor lower than 0. Indeed, Null is not a numeric value and will not return any result in a numerical expression. As a consequence, hiding a report element on a formula condition will not give any result when the evaluated data is Null.

Example:

Hiding a table when the formula “[Data] >= 0” is true, will not hide this table if [Data] is Null.

To hide this table, the formula should be: “[Data] >= 0 Or IsNull([Data])”.

A defect in previous versions of Web Intelligence would evaluate Null as a numeric value greater than 0. This issue has been corrected, which may explain why some report elements are no longer hidden in migrated documents.

Versions where the wrong behavior can be found:

• 4.1 SP3 from patch 2 to 6
• 4.1 SP4 from patch 1 to 3

Versions where the correct behavior can be found:

• 4.0
• 4.1 up to SP2
• 4.1 SP3 and SP4, outside the above patches
• 4.1 since SP5
• 4.2

Formula Evaluation with a Filter on the Data

When a filter is applied to an object assigned to a report element and that filter removes all values of the object, then this object no longer exists in the calculation context of the report element (i.e. at the most detailed level). As a consequence, hiding the report element on a formula condition based on the filtered object is no longer possible: the evaluation returns no result and the report element is not hidden.

In previous versions of Web Intelligence, the filtered object would sometimes remain in the calculation context and be evaluated as null or zero, depending on the evaluated formula. As a consequence, the report element would get hidden.

Example:

We have the following table:

1) Format the table as follows:

“Hide when following formula is true:” = [Year] <> “2016”

Result: the table is hidden as expected

2) Now, filter out [Year], in the table:

For instance, define a filter such as: [Year] equals to “2012”

Result: the table is no longer hidden. Since [Year] is completely filtered out, it is removed from the calculation context of the table. As a consequence, the "hide on formula" condition cannot be evaluated.

In this situation, hiding the report element can be achieved in two ways:

• Use the “Hide when Empty” format setting on the report element.
• Alternatively, the object can be evaluated at the report level in the “Hide when following formula is true” condition, with the “In Report” context modifier. For example: “Hide when following formula is true:” = [Year] <> “2016” In Report will hide the above table even when [Year] no longer exists in the context of that table.

Versions where the wrong behavior can be found:

• 4.1 SP3 from patch 2 to 6
• 4.1 SP4 from patch 1 to 3

Versions where the correct behavior can be found:

• 4.0
• 4.1 up to SP2
• 4.1 SP3 and SP4, outside the above patches
• 4.1 from SP5
• 4.2

Other Functions and Calculation Changes

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

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.

In the example below, Year and Country are incompatible:

After XI R2 SP03, Web Intelligence returns the measure value calculated using the compatible dimensions. In the example below, Revenue is calculated by Country:

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

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

As shown in the following table, in XI R2, the sum for the formula if([Year]=”2002”;1;0) returns the sum of the visible values, whereas the sum of the variable referring to the same formula (MyVarIf) returns the sum of the multiple occurrences 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 can have its own projection function. The projection function is the default aggregation used by the Web Intelligence calculation engine when consuming a measure in a block. The projection function can be a sum (by default), a count, a min, a max, or it can be delegated to the data source. The projection function can also be set to “none”, in which case the Web Intelligence calculation engine will process the measure as a dimension (aggregation by identical values).

The “Count” projection function counts the occurrences of each unique value in the list of values of a measure. But it 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:

•       Web Intelligence server: (64bits): C:\Program Files (x86)\SAP  BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\win64_x64\config
•       Web Intelligence 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 did not 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:

<Rules>

  <Rule name="ExtractPlainDimFromWhereCond" enable="true" force="false">

    <!--List of version where the behavior changed-->

    <Version value="12.3.6.1006"/>  <!-- Titan XI3.1 SP3 FP06 -->

    <Version value="12.4.1.1188"/>  <!-- Titan XI3.1 SP4 FP01 -->

    <Version value="12.5.1.1357"/>  <!-- Titan XI3.1 SP5 FP01 -->

    <Version value="14.0.5.882"/>    <!-- 4.0 SP5 RTM -->

  </Rule>

  <Rule name="ResetOnSectionForCumulative" enable="true" force="false">

    <!--List of version where the behavior changed-->

    <Version value="11.5.10.0"/>

  </Rule>

  <Rule name="UseMergeDimInAgg" enable="true" force="false">

    <!--List of version where the behavior changed-->

    <Version value="12.3.2.0"/>

  </Rule>

  <Rule name="UseColForCumulativeOnXTabBody" enable="true" force="false">

    <!--List of version where the behavior changed-->

    <Version value="12.x.x.x"/> <!-- All XI3.x versions -->

    <Version minvalue="14.0.2.798" maxvalue="14.0.2.846"/>

    <Version minvalue="14.0.5.882" maxvalue="14.0.5.1249"/>

    <Version minvalue="14.0.6.1036" maxvalue="14.0.6.1145"/>

    <Version minvalue="14.0.7.1147" maxvalue="14.0.7.1147"/>

    <Version minvalue="14.1.0.896" maxvalue="14.1.0.896"/>

    <Version minvalue="14.1.1.1036" maxvalue="14.1.1.1072"/>

  </Rule>

</Rules>

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.

Introduction

SAP BusinessObjects Web Intelligence (WebI) allows its documents content to be exported as Microsoft Excel files, either in XLS or XLSX format. This functionality exports each report of a document as an individual tab into an Excel file.

Important Differences between WebI and Excel

Before exporting WebI data to Excel, it is important to understand some important differences between WebI and Excel.

In WebI, each table in a report is truly independent. Tables are distinct objects, each of them with its own format, number of columns and rows. They can be optionally related to each other in terms of relative position or filtering (element linking), but this is as far as it goes in terms of dependency.

In Excel, there is in fact only one large table in each spreadsheet (tab). Users can group their data in distinct areas in this table but these areas are not distinct and they cannot, for instance, have the same size and a different number of rows or columns...

What this major difference means is that when exporting a report with several tables, vertically aligned and of different widths and number of columns, WebI will have to create additional columns in order to match the vertical cells alignment in Excel and then merge the cells of the larger columns:

A similar operation occurs when the WebI report contains several horizontally aligned tables and these tables have rows of different heights. In that situation and for the same reason, WebI will need to create additional rows to match the horizontal cells alignment in Excel and merge the cells of the larger rows.

Exporting with Focus on Format or on Data?

There are two mutually exclusive options when exporting WebI data to Excel: either the export is done with a focus on the format or the focus is on the data.

The difference between these two options is that when focus is on the format, WebI will add as many columns and rows as necessary, to best match the format of the source WebI report.

On the opposite, when focus is on the data, WebI will prevent as much as possible the addition of extra rows or columns. Typically, small column or row size differences between distinct tables will be ignored. This second option is called “Prioritize easy data processing in Excel” and this is the option to choose when exporting WebI data for further processing.

Best Practice Rules when Exporting Data for Further Processing

If the goal of exporting WebI reports to Excel is to further process the extracted data, then by adopting the following rules, WebI report designers will make sure that they always get the same number of columns and rows in their Excel spreadsheets:

Rule #1: One table per WebI Report!

This is the best way to export data to Excel for further processing. With only one table per report, the export to Excel will result in a single table per spreadsheet with a one-to-one cell matching between WebI and Excel. No additional columns, no additional rows…

Rule #2: No vertical alignment of tables in WebI, same rows height

If several tables need to share the same WebI report, then it is better to align them side-by-side rather than on top of each other. With horizontally aligned tables, WebI will not need to create additional columns and merge cells in Excel.

Further, if the side-by-side tables have identical rows height, then WebI will not need either to create additional rows and merge cells in Excel.

To make sure the table’s rows keep the same heights after a data refresh, the report designer should not use the “auto fit” parameter. Instead, all rows should have a fixed height value.

Rule #3: If you really need to vertically align tables, then they must have identical columns width

If despite the above rules, multiple tables are vertically aligned in the same WebI report, then these tables should have columns of equal width. This will prevent WebI from creating additional columns and merge cells in Excel.

Again, to make sure the table’s columns keep the same width after a data refresh, the report designer should not use the “auto fit” parameter. Instead, all columns should have a fixed width value.

Rule #4: No overlap of report elements!

This is by far the worst situation...

WebI will move apart each element, in order to try to fit them in the Excel spreadsheet. But then, each data refresh will potentially add new values, both horizontally and vertically, thus leading to the creation of additional rows and columns in the exported Excel data.

WebI cannot guarantee a stable Excel format output in that case.

Additional Notes

• WebI report headers and footers are not exported to Excel.
• WebI free cells do not generate additional rows or columns. They make use of whatever space is available in the Excel spreadsheet.

Gartner Magic Quadrant

In this document I will show you how we can plot data to display a Gartner Magic Quadrant chart.

Gartner Magic Quadrant is used by Gartner to do company analysis on a given subject (big data, BI, cloud, data services, etc.).

But we can use this chart to propose new business cases.

Before detailing the solution described in this document, here is a Gartner Magic Quadrant chart I picked on internet.

The chart choice is the Scatter Plot and that’s not the biggest challenge.

To represent the data on this chart we only need 2 measures: ability to execute and completeness of vision.

Now the difficulty is to split the chart in 4 equal parts for Challengers, Leaders, Niche Players and Visionaries.

As we only have one title in a chart it seems difficult to display each category.

Moreover, it’s also not possible to have only 1 line for the X axis and 1 line for the Y axis representing the zero or the average.

I tried to do it using a single chart and here is the best chart I obtained.

As you can notice there is no title for the categories and it’s not so easy to identify them in the chart.

The last issue is that the minimum value and maximum value can be defined for the entire chart but not for the zero/middle axis. So I we want to simulate or change the average, this is not possible.

The best solution: 4 charts

So I decided to use 4 charts, 1 for each category.

All the charts are aligned each other:

• LEADERS is aligned on the right of CHALLENGERS
• NICHE PLAYERS is aligned on the bottom of CHALLENGERS
• VISIONARIES is aligned on the left of NICHE PLAYERS and is aligned on the bottom of LEADERS

The dataset I used contains:

• a dimension named Company
• a measure name Ability to Execute
• a measure named Completeness of Vision

The 2 measures contain decimal data between -1 and 1.

So each chart contains the dimension “Company” and the 2 measures as following:

I set the minimum value and maximum value for each chart:

• CHALLENGERS:
  • Value Axis: Min = -1, Max = 0
  • Value Axis 2: Min = 0, Max = 1
• LEADERS:
  • Value Axis: Min = 0, Max = 1
  • Value Axis 2: Min = 0, Max = 1
• VISIONARIES:
  • Value Axis: Min = 0, Max = 1
  • Value Axis 2: Min = -1, Max = 0
• NICHE PLAYERS:
  • Value Axis: Min = -1, Max = 0
  • Value Axis 2: Min = -1, Max = 0

Then I created a filter for each chart:

• CHALLENGERS:
  • Completeness of Vision Less than 0
  • Ability to Execute Greater than or Equal to
• LEADERS:
  • Completeness of Vision Greater than or Equal to
  • Ability to Execute Greater than or Equal to
• VISIONARIES:
  • Completeness of Vision Greater than or Equal to
  • Ability to Execute Less than 0
• NICHE PLAYERS:
  • Completeness of Vision Less than 0
  • Ability to Execute Less than 0

Common properties:

• Each chart has the same width and same height
• Each chart has a title corresponding to each category.
• The Legend is hidden
• Data values
  • Data type = Label
  • Data position = Outside First, Inside Otherwise
• Same font size for Data Values
• Chart border:
  • CHALLENGERS: Top, Left
  • LEADERS: Top, Right
  • VISIONARIES: Bottom, Right
  • NICHE PLAYERS: Bottom, Left
• Category Axis:
  • Design is hidden
  • Title is hidden
• Value Axis:
  • Design is hidden
  • Title is hidden
• Value Axis 2:
  • Design is hidden
  • Title is hidden

Here is the result obtained with the 4 Scatter Plot charts:

You can tweak the layout depending on the maximum number of values for a given part of the SWO matrix: increase or decrease the font size, increase or decrease the width and height.

What-if

Now we can easily simulate the moving of data from one quadrant to another by changing the middle value if each axis.

To achieve this requirement, I created a measure variable for Ability to Execute and a measure variable for Completeness of Vision

Then I created an input control associated to each variable.

Each input control has a value varying from -10 to 10 with a default value equal to 0.

Now to simulate the variation I modified the minimum value and maximum value of each chart as below.

• CHALLENGERS:
  • Value Axis: Min = -1, Max = =[Variables].[Completeness of vision] / 10
  • Value Axis 2: Min = =[Variables].[Completeness of vision] / 10, Max = 1
• LEADERS:
  • Value Axis: Min = =[Variables].[Completeness of vision] / 10, Max = 1
  • Value Axis 2: Min = =[Variables].[Completeness of vision] / 10, Max = 1
• VISIONARIES:
  • Value Axis: Min = =[Variables].[Completeness of vision] / 10, Max = 1
  • Value Axis 2: Min = -1, Max = =[Variables].[Completeness of vision] / 10
• NICHE PLAYERS:
  • Value Axis: Min = -1, Max = =[Variables].[Completeness of vision] / 10
  • Value Axis 2: Min = -1, Max = =[Variables].[Completeness of vision] / 10

Now because the minimum value and maximum value are changing I created a new variable named “Quadrant” with the following formula:

=If [Query 1].[Ability to execute] >= [Variables].[Ability to execute] / 10 And [Query 1].[Completeness of vision] < [Variables].[Completeness of vision] / 10 Then "CHALLENGER"

Else If [Query 1].[Ability to execute] >= [Variables].[Ability to execute] / 10 And [Query 1].[Completeness of vision] >= [Variables].[Completeness of vision] / 10 Then "LEADER"

Else If [Query 1].[Ability to execute] < [Variables].[Ability to execute] / 10 And [Query 1].[Completeness of vision] < [Variables].[Completeness of vision] / 10 Then "NICHE PLAYER"

Else If [Query 1].[Ability to execute] < [Variables].[Ability to execute] / 10 And [Query 1].[Completeness of vision] >= [Variables].[Completeness of vision] / 10 Then "VISIONARY"

The I removed the previous filters and created a new filter for each chart:

• CHALLENGERS:
  • Quadrant Equal to CHALLENGER
• LEADERS:
  • Quadrant Equal to LEADER
• VISIONARIES:
  • Quadrant Equal to VISIONARY
• NICHE PLAYERS:
  • Quadrant Equal to NICHE PLAYER

And now I can change the middle value to simulate updates in the Gartner Magic Quadrant.

You can use this solution for other business cases than company analysis.

You can download the Web Intelligence report attached to that publication that details all the steps described in that document.

Didier MAZOUE

In a previous publication I described how we can display a large number of values on a chart and zoom in the chart using input controls: Charts windowing.

Concerning tables this is not really an issue because a table can be displayed on multiple charts.

If we have to export to PDF, Excel or print the report this is of course mandatory.

But in some cases it could be interesting to display the table on a single page and scroll inside the table without changing pages.

Tables scrolling

So the idea is to change the content of a table without changing page. Moreover, we can also set the number of visible rows in the table as the below screenshot.

In the above example, there are 2 tables and I created a break on Product categories in the first table and a break on Country in the second table.

To scroll in the table, I created 2 numeric variables:

• Number of visible rows: =0
• Vertical scrolling: =0

The I created one input control liked to each variable:

• Number of visible rows:
  • Minimum value: 1
  • Maximum value: 40
  • Maximum value: 1
  • Default value: 20
• Vertical scrolling:
  • Minimum value: 1
  • Maximum value: 700
  • Maximum value: 1
  • Default value: 1

So the table can display from 1 to 40 rows.

And in, my example, the table can contain from 1 to 700 rows

Now to use the 2 input controls with the tables I created a variable named “MaxRows” with the following formula:

=If RowIndex() >= [Vertical scrolling] And RowIndex() <= [Vertical scrolling] + [Number of visible rows] Then "OK"

And I created the following filter applied on the report: MaxRows Equal To“OK”

So the table only displays the rows between the value of [Vertical scrolling] and [Vertical scrolling] + [Number of visible rows]

See below screenshot:

As the total for the break is changing when the scrolling variables change I added 2 other subtotals to always have the correct total for Order Quantity and Sales Amount:

• =Sum(NoFilter( [Order Quantity]))
• =Sum(NoFilter( [Sales Amount]))

So you can see that the totals are not changing whenever we scroll down or up in the table.

You can see in the published video how we can play with the table and the input controls: https://youtu.be/mf7iYovuf5w.

You can download the Web Intelligence report attached to that publication.

Didier MAZOUE

Overview

This document describes the corrections and changes to the calculation engine in Web Intelligence 4.1 compared to Web Intelligence XI 3.1, XI 3.0, and XIR2 SP06 and SP03. It compares the new behavior of the calculation engine to its behavior in the previous versions.

It also suggests migration strategies for accommodating the calculation engine changes.

It gives a description of the formula rewrite mechanism introduced in 4.1 SP03 to preserve the reports created with an older version, from specific changes.

(Document authored by Pierre Saurel & Pascal Gaulin / Web Intelligence Product Experts)

Table of contents

Introduction

The 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 on a dimension

Previously, dimensions were incorrectly added to the dimensional context of the condition. Now dimensions are only used for 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 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 FPs
• XI3.1 SP03 RTM
• XI3.1 SP04 RTM
• XI3.1 SP05 RTM
• BI4.0 SP01 RTM and All Patches
• BI4.0 SP02 RTM and All Patches
• BI4.0 SP03 RTM and All Patches
• BI4.0 SP04 RTM and All Patches

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

Interaction between a context modifier on a measure aggregation and the “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 is

Interpreted 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 an aggregation expression

For a “where” operator with a condition on a dimension outside an aggregation function, the “where” condition was incorrectly applied before the aggregation calculation. The condition is now applied after the aggregation with the respect to calculation accordingly of the parenthesis.

Example:

AggregationFct ([measure]) 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 values

Details 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 will 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:

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 running calculations will not automatically reset for each new 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.

After 4.1 SP03, the running 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 (3^rd 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" .

Data order in running calculations

A running 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 previous result (processing by column)  with a new version (BI 4.1 SP03), the user can use the value COL as 2^nd parameter.

From BI 4.1 SP03.3, to ensure that you receive results for this formula that correspond to the previous document versions, the system automatically rewrites the formula using an ad-hoc parameter FORCE_COL with 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:

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

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 December the 31th of 2012 = 1

“MonthsBetween” function

A set of days over two months was 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 # and if ending day # is the end of the month and 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 dimensions inside 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.

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

Aggregation functions can process individual objects inside a merged object

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 merged object

An aggregation on a variable object whose formula is based on an object [A] that is participating in a merged object, was processed based on the merged object instead of the given object [A]. The aggregation is now processed according to the given object [A].

Migration:

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 regression was found in the following 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:

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 1^st query, the intersection of the two objects results in the values 2004 and 2005, while with the year from the 2^nd 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 1^st or the 2^nd query:

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:

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]:

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

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]):

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 6
  • SP04, 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:

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.

Hiding a Report Element when a Formula is True

This section is about the “Hide when following formula is true” setting. This setting can be found in the Format dialog box of any Web Intelligence report element: tables, charts, forms, sections and free cells.

Formula Evaluation when the Data is Null

Null is not 0. It is neither greater nor lower than 0. Indeed, Null is not a numeric value and will not return any result in a numerical expression. As a consequence, hiding a report element on a formula condition will not give any result when the evaluated data is Null.

Example:

Hiding a table when the formula “[Data] >= 0” is true, will not hide this table if [Data] is Null.

To hide this table, the formula should be: “[Data] >= 0 Or IsNull([Data])”.

A defect in previous versions of Web Intelligence would evaluate Null as a numeric value greater than 0. This issue has been corrected, which may explain why some report elements are no longer hidden in migrated documents.

Versions where the wrong behavior can be found:

• 4.1 SP3 from patch 2 to 6
• 4.1 SP4 from patch 1 to 3

Versions where the correct behavior can be found:

• 4.0
• 4.1 up to SP2
• 4.1 SP3 and SP4, outside the above patches
• 4.1 since SP5
• 4.2

Formula Evaluation with a Filter on the Data

When a filter is applied to an object assigned to a report element and that filter removes all values of the object, then this object no longer exists in the calculation context of the report element (i.e. at the most detailed level). As a consequence, hiding the report element on a formula condition based on the filtered object is no longer possible: the evaluation returns no result and the report element is not hidden.

In previous versions of Web Intelligence, the filtered object would sometimes remain in the calculation context and be evaluated as null or zero, depending on the evaluated formula. As a consequence, the report element would get hidden.

Example:

We have the following table:

1) Format the table as follows:

“Hide when following formula is true:” = [Year] <> “2016”

Result: the table is hidden as expected

2) Now, filter out [Year], in the table:

For instance, define a filter such as: [Year] equals to “2012”

Result: the table is no longer hidden. Since [Year] is completely filtered out, it is removed from the calculation context of the table. As a consequence, the "hide on formula" condition cannot be evaluated.

In this situation, hiding the report element can be achieved in two ways:

• Use the “Hide when Empty” format setting on the report element.
• Alternatively, the object can be evaluated at the report level in the “Hide when following formula is true” condition, with the “In Report” context modifier. For example: “Hide when following formula is true:” = [Year] <> “2016” In Report will hide the above table even when [Year] no longer exists in the context of that table.

Versions where the wrong behavior can be found:

• 4.1 SP3 from patch 2 to 6
• 4.1 SP4 from patch 1 to 3

Versions where the correct behavior can be found:

• 4.0
• 4.1 up to SP2
• 4.1 SP3 and SP4, outside the above patches
• 4.1 from SP5
• 4.2

Other Functions and Calculation Changes

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

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.

In the example below, Year and Country are incompatible:

After XI R2 SP03, Web Intelligence returns the measure value calculated using the compatible dimensions. In the example below, Revenue is calculated by Country:

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

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

As shown in the following table, in XI R2, the sum for the formula if([Year]=”2002”;1;0) returns the sum of the visible values, whereas the sum of the variable referring to the same formula (MyVarIf) returns the sum of the multiple occurrences 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 can have its own projection function. The projection function is the default aggregation used by the Web Intelligence calculation engine when consuming a measure in a block. The projection function can be a sum (by default), a count, a min, a max, or it can be delegated to the data source. The projection function can also be set to “none”, in which case the Web Intelligence calculation engine will process the measure as a dimension (aggregation by identical values).

The “Count” projection function counts the occurrences of each unique value in the list of values of a measure. But it 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:

•       Web Intelligence server: (64bits): C:\Program Files (x86)\SAP  BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\win64_x64\config
•       Web Intelligence 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 did not 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:

<Rules>

  <Rule name="ExtractPlainDimFromWhereCond" enable="true" force="false">

    <!--List of version where the behavior changed-->

    <Version value="12.3.6.1006"/>  <!-- Titan XI3.1 SP3 FP06 -->

    <Version value="12.4.1.1188"/>  <!-- Titan XI3.1 SP4 FP01 -->

    <Version value="12.5.1.1357"/>  <!-- Titan XI3.1 SP5 FP01 -->

    <Version value="14.0.5.882"/>    <!-- 4.0 SP5 RTM -->

  </Rule>

  <Rule name="ResetOnSectionForCumulative" enable="true" force="false">

    <!--List of version where the behavior changed-->

    <Version value="11.5.10.0"/>

  </Rule>

  <Rule name="UseMergeDimInAgg" enable="true" force="false">

    <!--List of version where the behavior changed-->

    <Version value="12.3.2.0"/>

  </Rule>

  <Rule name="UseColForCumulativeOnXTabBody" enable="true" force="false">

    <!--List of version where the behavior changed-->

    <Version value="12.x.x.x"/> <!-- All XI3.x versions -->

    <Version minvalue="14.0.2.798" maxvalue="14.0.2.846"/>

    <Version minvalue="14.0.5.882" maxvalue="14.0.5.1249"/>

    <Version minvalue="14.0.6.1036" maxvalue="14.0.6.1145"/>

    <Version minvalue="14.0.7.1147" maxvalue="14.0.7.1147"/>

    <Version minvalue="14.1.0.896" maxvalue="14.1.0.896"/>

    <Version minvalue="14.1.1.1036" maxvalue="14.1.1.1072"/>

  </Rule>

</Rules>

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.

Multiple Web Intelligence user’s questions are regarding date and time and especially difference between 2 dates.

Web Intelligence already offers 2 functions dedicated to dates difference:

• DaysBetween()
• MonthsBetween()

Those functions work well when we are manipulating dates but the result is not perfect when we are manipulating date + time: datetime, timestamp, etc.

Moreover, there is no out of the box functions to compute the difference for years, quarters, hours, minutes and seconds.

The goal of this document is to present you how to compute time difference functions with correct results.

Let’s assume we have 2 variables containing date + time and respectively named:

• [Start Date]
• [End date]

Years difference

Here is the formula:

=If ToNumber(FormatDate([End Date];"yyyyMMddHHmmss")) - ToNumber(FormatDate([Start Date];"yyyyMMddHHmmss")) >= 0

Then

ToNumber(FormatDate([End Date];"yyyy")) - ToNumber(FormatDate([Start Date];"yyyy")) - (If ToNumber(FormatDate([End Date];"MMddHHmmss")) - ToNumber(FormatDate([Start Date];"MMddHHmmss")) >= 0 Then 0 Else 1)

Else

(ToNumber(FormatDate([Start Date];"yyyy")) - ToNumber(FormatDate([End Date];"yyyy")) - (If ToNumber(FormatDate([Start Date];"MMddHHmmss")) - ToNumber(FormatDate([End Date];"MMddHHmmssMM")) >= 0 Then 0 Else 1)) * -1

Formula explanation:

• if [End Date] >= [Start Date], all computations will compute [End Date] - [Start date]
• if [End Date] < [Start Date], all computations will compute [Start Date] - [End Date] and the final result will be multiplied by -1
• If the difference between the 2 dates with the format “MMddHHmmss” is negative, then we subtract 1 from the result in both expressions

Quarters difference

Here is the formula:

=If ToNumber(FormatDate([End Date];"yyyyMMddHHmmss")) - ToNumber(FormatDate([Start Date];"yyyyMMddHHmmss")) >= 0

Then

((ToNumber(FormatDate([End Date];"yyyy")) - ToNumber(FormatDate([Start Date];"yyyy"))) * 4) + (If ToNumber(FormatDate([End Date];"MMddHHmmss")) - ToNumber(FormatDate([Start Date];"MMddHHmmss")) >= 0 Then Truncate((ToNumber(FormatDate([End Date];"MM")) - ToNumber(FormatDate([Start Date];"MM"))) / 3;0) Else Truncate((ToNumber(FormatDate([Start Date];"MM")) - ToNumber(FormatDate([End Date];"MM"))) / 3;0))

Else

(((ToNumber(FormatDate([End Date];"yyyy")) - ToNumber(FormatDate([Start Date];"yyyy"))) * 4) + (If ToNumber(FormatDate([End Date];"MM")) - ToNumber(FormatDate([Start Date];"MM")) >= 0 Then Truncate((ToNumber(FormatDate([End Date];"MM")) - ToNumber(FormatDate([Start Date];"MM"))) / 3;0) Else Truncate((ToNumber(FormatDate([Start Date];"MM")) - ToNumber(FormatDate([End Date];"MM"))) / 3;0))) * -1

Formula explanation:

• if [End Date] >= [Start Date], all computations will compute [End Date] - [Start date]
• if [End Date] < [Start Date], all computations will compute [Start Date] - [End Date] and the final result will be multiplied by -1
• If the difference between the 2 dates with the format “MMddHHmmss” is negative, then we revert the order of dates to compute the remaining quarters
• The number of remaining quarters is always rounded to the lowest integer (Truncate function) when computing the difference between months.

Months difference

Here is the formula:

=If ToNumber(FormatDate([End Date];"yyyyMMddHHmmss")) - ToNumber(FormatDate([Start Date];"yyyyMMddHHmmss")) >= 0

Then

MonthsBetween([Start Date];[End Date]) - (If ToNumber(FormatDate([End Date];"ddHHmmss")) - ToNumber(FormatDate([Start Date];"ddHHmmss")) >= 0 Then 0 Else 1)

Else

(MonthsBetween([End Date];[Start Date]) - (If ToNumber(FormatDate([Start Date];"ddHHmmss")) - ToNumber(FormatDate([End Date];"ddHHmmss")) >= 0 Then 0 Else 1) ) * -1

Formula explanation:

• if [End Date] >= [Start Date], all computations will compute MonthsBetween([End Date];[Start date])
• if [End Date] < [Start Date], all computations will compute MonthsBetween ([Start Date];[End Date]) and the final result will be multiplied by -1
• If the difference between the 2 dates with the format “ddHHmmss” is negative, then we subtract 1 from the result in both expressions

We are sure we have exactly the number of months by taking into account a timestamp.

Days difference

Here is the formula:

=If ToNumber(FormatDate([End Date];"yyyyMMddHHmmss")) - ToNumber(FormatDate([Start Date];"yyyyMMddHHmmss")) >= 0

Then

DaysBetween([Start Date];[End Date]) - (If ToNumber(FormatDate([End Date];"HHmmss")) - ToNumber(FormatDate([Start Date];"HHmmss")) >= 0 Then 0 Else 1)

Else

(DaysBetween([End Date];[Start Date]) - (If ToNumber(FormatDate([Start Date];"HHmmss")) - ToNumber(FormatDate([End Date];"HHmmss")) >= 0 Then 0 Else 1) ) * -1

Formula explanation:

• if [End Date] >= [Start Date], all computations will compute DaysBetween ([End Date];[Start date])
• if [End Date] < [Start Date], all computations will compute DaysBetween ([Start Date];[End Date]) and the final result will be multiplied by -1
• If the difference between the 2 dates with the format “HHmmss” is negative, then we subtract 1 from the result in both expressions

We are sure we have exactly the number of days by taking into account a timestamp.

Hours difference

Here is the formula:

=If ToNumber(FormatDate([End Date];"yyyyMMddHHmmss")) - ToNumber(FormatDate([Start Date];"yyyyMMddHHmmss")) >= 0

Then

(DaysBetween([Start Date];[End Date]) * 24) +

(ToNumber(FormatDate([End Date];"HH")) - ToNumber(FormatDate([Start Date];"HH")))-

(If ToNumber(FormatDate([End Date];"mmss")) - ToNumber(FormatDate([Start Date];"mmss")) >= 0 Then 0 Else 1)

Else

((DaysBetween([End Date];[Start Date]) * 24) +

(ToNumber(FormatDate([Start Date];"HH")) - ToNumber(FormatDate([End Date];"HH")))-

(If ToNumber(FormatDate([Start Date];"mmss")) - ToNumber(FormatDate([End Date];"mmss")) >= 0 Then 0 Else 1)) * -1

Formula explanation:

• if [End Date] >= [Start Date], all computations will compute DaysBetween ([End Date];[Start date])
• if [End Date] < [Start Date], all computations will compute DaysBetween ([Start Date];[End Date]) and the final result will be multiplied by -1
• The number of days is multiplied by 24
• If the difference between the 2 dates with the format “mmss” is negative, then we subtract 1 from the result in both expressions

Minutes difference

Here is the formula:

=If ToNumber(FormatDate([End Date];"yyyyMMddHHmmss")) - ToNumber(FormatDate([Start Date];"yyyyMMddHHmmss")) >= 0

Then

(DaysBetween([Start Date];[End Date]) * 1440) +

((ToNumber(FormatDate([End Date];"HH")) - ToNumber(FormatDate([Start Date];"HH"))) * 60)  +

(ToNumber(FormatDate([End Date];"mm")) - ToNumber(FormatDate([Start Date];"mm"))) -

(If ToNumber(FormatDate([End Date];"ss")) - ToNumber(FormatDate([Start Date];"ss")) >= 0 Then 0 Else 1)

Else

((DaysBetween([End Date];[Start Date]) * 1440) +

((ToNumber(FormatDate([Start Date];"HH")) - ToNumber(FormatDate([End Date];"HH"))) * 60)  +

(ToNumber(FormatDate([Start Date];"mm")) - ToNumber(FormatDate([End Date];"mm"))) -

(If ToNumber(FormatDate([Start Date];"ss")) - ToNumber(FormatDate([End Date];"ss")) >= 0 Then 0 Else 1)) * -1

Formula explanation:

• if [End Date] >= [Start Date], all computations will compute DaysBetween ([End Date];[Start date])
• if [End Date] < [Start Date], all computations will compute DaysBetween ([Start Date];[End Date]) and the final result will be multiplied by -1
• The number of days is multiplied by 1440
• If the difference between the 2 dates with the format “ss” is negative, then we subtract 1 from the result in both expressions

Seconds difference

Here is the formula:

=If ToNumber(FormatDate([End Date];"yyyyMMddHHmmss")) - ToNumber(FormatDate([Start Date];"yyyyMMddHHmmss")) >= 0

Then

(DaysBetween([Start Date];[End Date]) * 86400) +

((ToNumber(FormatDate([End Date];"HH")) - ToNumber(FormatDate([Start Date];"HH"))) * 3600)  +

((ToNumber(FormatDate([End Date];"mm")) - ToNumber(FormatDate([Start Date];"mm"))) * 60) +

(ToNumber(FormatDate([End Date];"ss")) - ToNumber(FormatDate([Start Date];"ss")))

Else

((DaysBetween([End Date];[Start Date]) * 86400) +

((ToNumber(FormatDate([Start Date];"HH")) - ToNumber(FormatDate([End Date];"HH"))) * 3600)  +

((ToNumber(FormatDate([Start Date];"mm")) - ToNumber(FormatDate([End Date];"mm"))) * 60) +

(ToNumber(FormatDate([Start Date];"ss")) - ToNumber(FormatDate([End Date];"ss")))) * -1

Formula explanation:

• if [End Date] >= [Start Date], all computations will compute DaysBetween ([End Date];[Start date])
• if [End Date] < [Start Date], all computations will compute DaysBetween ([Start Date];[End Date]) and the final result will be multiplied by -1
• The number of days is multiplied by 86400

Report example

Here is a screenshot of a report.

The dates in red mean that [End Date] < [Start Date]

You can download the Web Intelligence report attached to that publication.

Didier MAZOUE

In this document, I want to illustrate how to have a better reading of a report containing a large list of people, customers, products, or anything that need to be listed.

To facilitate the reading, we create sections but that’s not enough we also want to manage the number of items in each section.

In the document I will show you how to manage a long list of customers sorted in alphabetical order.

The idea is to create a section by letter (or left part of the customer name) and to dynamically change the length to reduce the size of the section.

In addition, we can also easily swap the first name and the last name to have a better visibility of the customers list.

Variables creation

Full name type

As we want to display customers by the first name or the last name, we need to create a variable named “Full name type” and create an input control to manage the content of this variable.

We create an input control with the following properties:

• Radio buttons type input control based on “Full name type” variable.
• Custom list of values with 2 values:
• First name + Last name
• Last name + First name
• Only those 2 values are displayed
• Default value: First name + Last name

Full name

Now we create the “Full name” variable using the value of “Full name type” variable. Here is the formula:

=If [Full name type] = "First Name + " " + Last Name" Then [First name] + [Last Name] Else [Last Name] + " " + [First name]

Length

Now we create the “Length” variable that is a measure with a numeric value, formula: =1.

This variable is managed by an input control with the following parameters:

• Simple slider
• Minimum value: 1
• Maximum value: 10
• Default value: 1

Initial

We create the variable “Initial” that will be used in the section to filter the table containing the list of customer.

This variable is using the “Full name” variable” and the “Length” variable. The formula is:

=Left([Full Name];[Length])

Report creation

We can then create the report that contains a table with “Full name” and all other dimensions, attributes or measures that are necessary to display the list of customer.

We create a section based on “Initial variable”.

The report will look like this:

Now we can play with the 2 following input controls to change the report content.

In conclusion, this is an easy way to filter a large list of items and also to swap components of a given item

You can download the Web Intelligence report attached to that publication.

Didier MAZOUE

A report needs a visualization of the used fiters, certainly when it is exported.

In webi you can use some nice formula's to show the filters used via prompting.

Example: Userresponse("Ledger"), Ledger is the promptname defined in BEX query or via Edit query panel

This handy formula retrieves indeed the used filter on one specific prompt, however it has is disadvantages when you chase the promptname, you have to change the userresponsevariabels in every webi-document as well.  Or when your report is Language dependent, the promptname "Ledger" will change as well.

In new SAP BusinessObjects versions '(4.1 SPX) this formula is easily useable via >> ReportElement >> Cell >> Predefined Elements

Example: Promptsummary()

This handy formula retrieves all the used filters, however when you use a bex query as datasource, you will see a lot of redundant info.  The queryname, when multiple queries are included this can lead to unwanted complexity.

This formula, removes the redundant info form the promptsummary.

Create a variable: Promptbox define it via the formula underneath and apply it in your report.

=Replace(Replace(If Pos (Right(Right(PromptSummary();Length(PromptSummary())-3);Length(PromptSummary())-3-Pos((Right(PromptSummary();Length(PromptSummary())-3));"*")-2-4);"*") = 0 Then (Right(Right(PromptSummary();Length(PromptSummary())-3);Length(PromptSummary())-3-Pos((Right(PromptSummary();Length(PromptSummary())-3));"*")-2-4)) Else Left((Right(Right(PromptSummary();Length(PromptSummary())-3);Length(PromptSummary())-3-Pos((Right(PromptSummary();Length(PromptSummary())-3));"*")-2-4));Pos((Right(Right(PromptSummary();Length(PromptSummary())-3);Length(PromptSummary())-3-Pos((Right(PromptSummary();Length(PromptSummary())-3));"*")-2-8));"*"));"(Optioneel)";"");"(Optional)";"")

Hi All,

In this article, I will be providing all the perquisites and details that are required to enforce the following security in BI 4.1

• Any new Ad-Hoc report created in BI4.1,  should only use *.UNX universes.
• While Selecting Datasource for creating a new report based on Universe, only *.UNX should be listed.
• Existing reports Pointed to .UNV should refresh without error.

Overview:  As per the requirement, user’s should use only .UNX universes for creating new reports, however exiting reports on top of .UNV should refresh without any error.

In Order to enforce this, we need to enforce security at the universe level for the user/user groups in Bi4.1.

This is very common scenarios while migrating from 3.1 to 4.1 environment where we want to use UNX parallel to existing UNV sources. 

Scenarios:

1. We have a WebI report based on efashion.unv, named as “Unvbasedreport.wid”
2. We have Test User, “TestUsr” with Developer Access to refresh/edit  the “Unvbasedreport.wid” as well as create a new reports.
3. Test User can create new report on UNV as well as UNX based universes, whole list of unv and unx universes is available while creating reports.

What needs to achieve:

1. TestUsr should be able to refresh the unv based report(“Unvbasedreport.wid”)
2. While creating new report, TestUsr should only see the list of UNX universes (should not be able to create new reports on UNV’s)

Steps to implement:

1. Login to CMC with user id that has Admin access.
2. Go to the Universe and navigate to particular .unv universe in directory. In this case eFashion.unv
3. Right click on UNV and go to user security.
4. Click “Add Principals “, add TestUsr  from user list and click on assign Security.

   5. Click on Advanced tab, and Add/Remove Rights

    6. On the left Pane, Click System and Revoke mentioned right by selecting Deny radio Button:

                     I.        Create and Edit Queries Based on Universe

Note: Deny “Owner right” as well if , user is owner of the Object.

  7. Apply and OK.

Steps to confirm the change:

1: Login to BI Launchpad with TestUsr

2: Create new Webi report and select source as Universe

Result: User will only see eFashion.unx, Efashion.unv is not in the list.

Now , Refresh the existing report Unvbasedreport.wid  based on efashion.unv

Result: Refresh is ok

Note: User won’t be able edit the query of the existing report based on unv. “This Query cannot be edited” message will be displayed.  Only report structure can be modified.

Regards,

Manveer Nakoti

BO Consultant

Accenture

Environment:

SAP BI Platform 4.1 SP6 Patch 4

This Internal Error is seen when you open a Web Intelligence report and resize the Prompts window in Internet Explorer 11

Resolution:

Click OK and refresh again. The reports should run fine

or Don't expand the prompt window

or Use Firefox

or Google Chrome

Hope this helps!

MK

Following the enhancements introduced in SAP BI 4.2 (see SAP BI 4.2: What's New in Web Intelligence and SAP BI 4.2: What's New in Semantic Layer), Web Intelligence keeps on improving in SAP BI 4.2 SP3. This article describes its new features in this Support Package:

• Java/DHTML Clients Parity
• Cascading Input Control
• Publication Delivery Rules
• Merged Variables and Objects Display
• References
• Shared Elements
• Comments
• Geo Maps
• Parallel Queries
• SAP BW
• SAP HANA
• Change Source
• Miscellaneous

To complete this description, you might also be interested by:

• SAP BI 4.2 SP3: What's New in Semantic Layer
• SAP BI 4.2 SP3: What's New in Web Intelligence and Semantic Layer SDK

Java/DHTML Clients Parity

As some browsers do not support Java anymore, or to avoid Java version update, the functional parity between Web Intelligence Java and DHTML is seen as a priority by customers.

In SAP BI 4.2 SP3, the features that are the most requested have been implemented in Web Intelligence DHTML:

• Support of Excel data source
• Query Panel for SAP BEx, UNX on SAP Bex data providers
• Complex filters in Query Panel
• Conditional formatting
• Format number
• Change Source
• Export As dialog box

Some features, like Free-Hand SQL support or the Data Manager panel are not yet available and should be released in next Support Packages.

Excel Query Panel in DHTML

Note that since 4.2, all new features are implemented in all Web Intelligence clients, to avoid creating new gaps between Java and DHTML.

Cascading Input Controls

Input controls allow you to filter dataset in a document or one of its report through checkboxes, drop-down menus, sliders…

In SAP BI 4.2 SP3, you can gather input controls into group input control that are logically linked:

• In the InputControls side panel, input controls of a group are displayed gathered into a same frame.
• In a group, when values have been selected for an input control:
  • These values are used to filter the list of values of the other input controls the group contains
  • The answered input controls are collapsed and are displayed with their selected values on top of unanswered input controls. The answered input controls and their values defines the group filter path.

Displaying Two Groups Input Control: Product and Geography

To define a group input control, you must be in Design mode and in the InputControls side panel, click the Group button. In the Manage Groups dialog box, you can then create a new group, define if it is used to filter the document or a report and assign it at least two input controls.

Creating a Group Input Control

Publication Delivery Rules

In a first step to improve Web Intelligence scheduling and publishing capabilities, some recipient delivery rules are now supported for publication:

• Do not send the publication if scheduled content has no data
• Do not send the publication if scheduled content has not fully refreshed

These rules can be defined for each publication source document.

Web Intelligence Publication Delivery Rules

As these rules are checked before the document is sent to individual recipients, these rules can be used to prevent publishing empty or non-meaningful documents.

If the publication contains several source documents, you can also define the behavior for a recipient if one rule is not met:

• Cancel the publication (Deliver all documents only when all conditions are met)
• Deliver only the documents that met the rule (Deliver individual document when conditions is met)

Merged Variables and Objects Display

Merged dimensions are helpful to link data coming from two different data sources. But often, the datasets from the two data sources are not identical.

In 4.2 SP3, you can now merge variables; which allows you to modify/cleanse a dataset with the formula language before merging it with another dataset.

In the dialog box used to create merged objects, the AvailableObjects list now displays also variables that can be selected. To help selecting the right object to merge, variables are displayed by query

Selecting a Variable for Merge

In the AvailableObjects side panel, objects are displayed alphabetically or by queries.

In SAP BI 4.2 SP3, you can also display these objects by data source. If the data source is a universe, it displays the universe folder path containing the objects.

Available Objects Side Panel: Display by Data Source

References

Web Intelligence 4.2 SP3 introduces a new variable type: reference. A reference is a variable that returns the value of a specified cell in the document.  To create a reference; in design mode, right-click a cell and in the contextual menu, select the Assign Reference command.

In the dialog box that opens, keep the default Create a new reference for this cell option and enter a name for the reference.

Creating A Reference

Once defined, the reference is displayed in the AvailableObjects side panel under the References folder.

References In Available Objects

A reference can be used in any formula to define new variable or conditional formatting. It can be handy to directly get a result in the calculation context. Furthermore, as a reference returns the value actually displayed in a cell, it is impacted by report filters or input controls.

Variables Based on References

A reference can be displayed anywhere in the document through a cell. References can be useful to create a summary that retrieve figures or content from other reports.

Shared Elements

Shared elements have been introduced in SAP BI 4.2. They allow a report designer to save in the CMS repository a report element and the data sources, queries, variables, styles… required to create it. This shared element can be reused by other users, if they have the required security rights.

In SAP BI 4.2 SP2, shared elements have been released with some limitations. These limitations are addressed in SAP BI 4.2 SP3:

• A geographical map chart can be saved as a shared element
• A report element displaying a custom element can be saved as a shared element
• Measure’s big number setting is persisted when saved in as a shared element
• Embedded background image is saved in the shared element (it is possible in 4.2 if the image is referenced through an URL)
• Categories can be assigned to shared elements. In the SharedElements side panel, you can browse shared elements by categories.

Browsing Categories in Shared Elements Side Panel

From usability point of view, some enhancements have been done to ease shared elements use:

• In the SharedElements side panel, additional details are displayed for a shared element: author, last edit date, creation date…
• When publishing a shared element, the option Link to the source document allows you to link the published shared element to the current document
• When updating a shared element whose query has been modified, if its query is used by another report element in the document, then a copy of a previous query is kept in the document for this report element. Otherwise, the query is just updated.
• You can use the document new option Update shared elements to automatically update the shared elements the document uses when it is opened
• In the CMC, the Check Relationships command allows you to get shared element dependencies

Comments

When comments have been released in SAP BI 4.2, only document comments were available: the comments are displayed as free cells in the document and adding such comment can only be done in Design mode.

In SAP BI 4.2 SP3, you can now add comments to any block (tables or charts) or any table cells

This is possible both in Reading and Design modes.

When the comment is created, an icon is displayed on the cell or the block to show that a comment has been added. When hovering the mouse over this cell or block, a pop-up opens to show this comment.

Displaying a Comment on a Cell

Displaying a Comment on a Chart

When saving a document under a different name, you can select to keep its comments. If you do so, these comments are duplicated in the comments database for this new document.

When a document with comments is scheduled, the resulting scheduled instances also share the same comments from the comments database.

The Comments side panel user interface has been redesigned for better clarity. If you have the security right granted to you, you can delete a comment in the Comments side panel.

Geo Map

In 4.2, geo qualifying a dimension is done by mapping data coming from the dimension to the geographical names available in the geographical database embedded in Web Intelligence.

In SAP BI 4.2 SP3, you can geo qualify a dimension with latitude and longitude. The Edit as a geography has now two sub-commands:

• By Name
• By Longitude/Latitude

If you select By Longitude/Latitude, you are asked to select two dimensions that contain the latitude and longitude data.

Geo-Qualify by Longitude/Latitude

When geo qualifying a dimension by name, if the location is not known in Web Intelligence geographical database, you can explicitly add it through its latitude and longitude: in the EditasaGeography dialog box, select the Selectlocation command in the Location drop-down list. Then, in the Selectlocation dialog box, click the AddLocation button to add the location’s latitude and longitude.

Add a Location by Longitude/Latitude

In SAP BI 4.2 SP3, you can now also geo-qualify a variable, a merged variable (see Merged Variables and Objects Display) or a merged dimension. The menu Edit as a geography is available when right-clicking any of them in the Available objects side panel.

Geo-Qualified Variable and Merged Variable

Parallel Queries

In SAP BI 4.2 SP3, parallel queries are supported for SAP BW data providers.

Parallel queries settings can be fine-tuned in CMC, information design tool and universe design tool, rather than through configuration files.

• In universe design tool and information design tool: Max Parallel Queries per connection parameter for relational connections.
• In CMC and information design tool: Max Parallel Queries per connection parameter for OLAP connections.
• In CMC: MaxParallelQueries per document parameter and enable/disable parallel queries for scheduling

CMC: Parallel Queries Settings for Web Intelligence Processing Server

SAP BW

Several enhancements for SAP BW have been implemented in SAP BI 4.2 SP3:

• DHTML Query Panel (see DHTML Catchup)
• Parallel Queries support (see Parellel Queries)
• In the formula language, QuerySummary (StatusOfData) returns the SAP BW InfoProvider’s last upload data.
• SAP BW linked nodes are supported both for SAP BW direct access and UNX based on SAP BW
• When running a query on a universe based on a SAP BEx query, usage statistics are sent to SAP BW.
• As described below, the Change Source proposes new paths to move a SAP BW direct access data provider to SAP HANA direct access or to a universe based on a SAP BEx query

SAP HANA

In SAP 4.2, two new supports for SAP HANA have been added in Web Intelligence:

• SAP HANA direct access, where you can directly connect to the SAP HANA view to create a query before running it.
• SAP HANA Online mode, where you also directly connect to the SAP HANA view but without having to get data in the Web Intelligence cube. This mode takes advantage of the HANA in-memory database and when possible, delegates computation to SAP HANA. In this mode, the query panel is not used since the query is run against SAP HANA each time a new object is added to the document.

For SAP HANA Online mode, the following enhancements are now available in SAP BI 4.2 SP3:

• When only partial result has been retrieved (e.g. data Max Row), then you are notified through the Partial Result icon.
• In the Available Objects side panel, a new option (Navigation paths) can be selected to display the objects in their parent hierarchies.

Display by Navigation Paths in SAP HANA Online Mode

In SAP HANA direct access, the Set Variables dialog box that was available in SAP HANA online mode, is now also available in the Query Panel. It can be used to fix variables values and to avoid you to answer them at each refresh.

Set Variables Dialog Box in SAP HANA Direct Access Query Panel

The following enhancements are available for both SAP HANA direct access and online modes:

• When answering a variable, interval and range are supported. The list of operators are available in a drop-down list. You can also provide several answers.

HANA Interval and Range Operators

• Dynamic default values for HANA variables. If the variable’s default value is defined as a formula in SAP HANA, then this default value computation is delegated to SAP HANA. This default value is the one set in the Set Variables dialog box, unless you select the Use BEx/HANA defined default values at runtime checkbox and purge the document to make sure it is evaluated at refresh time as well.
• Conversion for any unit measure is supported (In SAP BI 4.2, only currency conversion is supported). When a measure unit has been defined as a prompt in HANA, Web Intelligence also prompts you for this unit measure.
• When selecting a SAP HANA view as a data source, the search in the connection dialog box is now case insensitive.

Change Source

In addition to be available in DHTML, the change source has been improved to support new data sources supported in SAP BI 4.2. The new supported paths are:

• From SAP BW Direct Access to SAP BW Authored Universe
• From SAP BW Direct Access to SAP HANA Direct Access
• From SAP HANA Authored Universe to SAP HANA Direct Access

Some enhancements have been done in order to avoid asking for prompts during change source, except for SAP BW and SAP HANA when they require prompt answers to generate metadata.

Miscellaneous

Some additional changes are available in Web Intelligence:

• In Web Intelligence calculation engine, a new function returns the members of a level in a hierarchy: MemberAtDepth(Hierarchy, Level)
• The Web Intelligence charts engine propose the following options:
  • In Pie charts, you can display both value and percentage
  • In Bar/Column charts, you can customize borders of each data series
  • In Bar/Column charts, you can also inverse legend order in stacked
  • In Waterfall charts, you can customize Total value label
• When exporting a document to PDF or Excel, you can choose the image resolution (DPI)
• Web Intelligence supports Server Group:

Hi everyone,

I am pleased to share with you some tips on the advanced use of Web Intelligence. These few tutorials allow you to give more value to your existing documents or to come or just to give you ideas for your future designs.

All my tricks are just a focus on some capabilities of the application, if you want more details about what you're able to do with it, share your thought with me I'll be happy to talk about it.

All entries are ranked by difficulty and by authors because I spend a lot (lot, lot, lot) of time searching on SCN great tips on Web Intelligence and some good entries are unfortunaltely hidden...so it's time to raise your hands guys (and girls ).

New features in Web Intelligence 4.2

New features in Web Intelligence 4.2 SP3

SAP BI 4.2 SP3: What's New in Web Intelligence by  Christian AH-SOON available here SAP BI 4.2 SP3: What's New in Web Intelligence

Summary

Legend

Picture	Level	Description
	Level 1	Difficulty is very low. Easy to set up and you can turn easily your existing document into value-added report effortless
	Level 2	Difficulty is low. Use analysis tools to interact with your report and give extra value to your operational reporting.
	Level 3	Difficulty is medium. Some of features used are advanced features and you've to be familiar with Web Intelligence.
	Level 4	Difficulty is high. Damn, your Webi document is so interactive and so cool. Restless to show and share it with others !
	Level 5	Difficulty is extreme. How did he do that ? I've read 8 times the document and I still understand nothing.

Tricks

Difficulty	Author	Link to document
	Abhijit Ingale	WEBI 4.0 Trick - Creating Progress Bar
	Rakesh Pattani	BOBJ Trick To Display Table Data In Hierarchy Format
	Durgamadhab Mishra	Webi tricks : Selecting Top N customers by Sales Percentage using a Slider
	WILLIAM MARCY	Webi tricks : Interactive selecting and viewing TOPn data
	Abhijit Ingale	WEBI - Dynamic Line Chart driven by Input Control
	Harsha Ganapathy	Creating a Sparkline chart for IPad
	Neha Kumari	How to use formulae to change date and time formats in WebIntelligence
	Andreas Kaufmann	alternate row colors in a break
	Tauseef Ali Mir	Dynamic Variables using Input Control
	Nagavaibhav Elluru	Custom message to replace 'No Data in the query'
	Victor Gabriel Saiz Castillo	All you need to know about #TOREFRESH
	Michael Thompson	Webi tricks: How to build a butterfly chart
	Huu Nguyen	Linear & Polynomial Trend Lines in Webi
	Michael Thompson	Webi tricks: Bars embedded into rows
	Huu Nguyen	WebI Trick: Line chart to show running average for each year
	Harshil Joshi	Date Variables in Web Intelligence
	Huu Nguyen	WebI Trick: Top N data for any integer N using Entry field Input controls
	Tanav Gupta	How to Add Document links (Interlink WEBI reports) in SAP Business Objects Web Intelligence 4.0
	Sateesh Kumar	Show Trend Icon/Arrows in webi as per conditions
	Huu Nguyen	Conditional formatting based on User input
	Koen Hesters	Dynamic Visibility within a Webi Report
	David G	WebI trick: Create a SEARCH Input Control for your WebI report part!
	Sateesh Kumar	Dynamic Ageing Buckets in Webi
	Sujitha Grandhi	Dynamic Visibility - Input Controls with Ranking
	Jonathan Brown	Creating a Webi doc off of an unmanaged Excel data source on a network share
	Rakesh Pattani	Merging Charts in WebI
	Rogerio Plank	How to insert a Gauge chart inside a WEBI Document
	Selvarasan Subramanian	Dense Ranking in SAP Business Objects Web Intelligence
	Jordan Bishop	How to create a Speedometer inside of a Web Intelligence document
	Mahboob Mohammed	Secret Custom Format (for Date) in Webi
	swapnil bhootwala	String aggregation on WEBI report level.
	Rogerio Plank	How to set a WEBI document to autorefresh each n seconds
	Kwaja Noorullah Khateef	How to grant filtering functionality for viewers/end-users on 'Input Control' enabled report blocks(Chart & Table) in web Intelligence reports without enabling the design mode'
	SANDEEP SINHA	Dimensions as Input Control- Dynamic Control | SCN
	Rogerio Plank	Merging 3 Data Providers compatible 2 by 2
	Rogerio Plank	Implementing a calendar like filter in the body of a report
	Didier MAZOUE	Usage of mini charts in tables
	Didier MAZOUE	Sort columns using input controls in read-only access
	Didier MAZOUE	Top-Bottom ranking using input controls in read-only access
	Didier MAZOUE	Display vertical labels in tables
	Mahboob Mohammed	Sum & Avg lines in Chart
	Mahboob Mohammed	Accurately positioned Custom Comments in Column Charts
	Didier MAZOUE	Display numbers in English words
	Niraj Parihar	Dealing with Null Values in a Chart
	Didier MAZOUE	Charts windowing

Designing

This section will help you designing the structure of your Web Intelligence document. You will be able to highlight your data into a Webi document well-designed with some best practices from experts.

Performance

Challenge accepted ! Once your document is complete and functionnal, think about performance. A well designed document is nothing for user if it opens in 10 minutes. So performance is the key to help users to understand the power of Web Intelligence. Jonathan Brown made a full document containing all tips for Optimizing the Performance of Web Intelligence Documents.Others related documents can be added to this table to find easily how to optimize performance.

One of the big challenge with SAP BusinessObjects on SAP landscape is to get best performances with Web Intelligence based on SAP BW using BICS (Business Intelligence Consumer Service) connection. @kurt.holst gave us a complete overview of best practices using Webi against SAP BW.

Sizing

Auditing

Following

The Web Intelligence Bulletin (this page) is a timely and regularly-updated information source providing links to hot issues, new documentation and upcoming events of interest to Web Intelligence Users and Administrators (extract from the Web Intelligence Bulletin - source : see below).

Debugging

A structured introduction and collection of hints, basic product information, best practices and links in the area of Web Intelligence. The goal is to provide end users a basic knowledge package to avoid or solve issues during the day to day business.

Special ovation to Timo Seufert and ALL the BI TEAM HUNGARY for their work knowing that Webi incidents can make you crazy. Good job team !

Additional ressources

You can see more things about Web Intelligence on space dedicated :

SAP BusinessObjects Web Intelligence

Creating Extensions to SAP BusinessObjects Web Intelligence

http://scn.sap.com/docs/DOC-54507

And more official documentation on Help Portal at :

SAP BusinessObjects Web Intelligence 4.1 – SAP Help Portal Page

One more thing, if you want to index your entry with a "Webi trick", leave a comment and I'll add your link ASAP. I'll update this document frequently with new entries I'll find out on SCN.

Have fun !

Overview

This document describes the corrections and changes to the calculation engine in Web Intelligence 4.1 compared to Web Intelligence XI 3.1, XI 3.0, and XIR2 SP06 and SP03. It compares the new behavior of the calculation engine to its behavior in the previous versions.

It also suggests migration strategies for accommodating the calculation engine changes.

It gives a description of the formula rewrite mechanism introduced in 4.1 SP03 to preserve the reports created with an older version, from specific changes.

(Document authored by Pierre Saurel & Pascal Gaulin / Web Intelligence Product Experts)

Table of contents

Introduction

The 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 on a dimension

Previously, dimensions were incorrectly added to the dimensional context of the condition. Now dimensions are only used for 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 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 FPs
• XI3.1 SP03 RTM
• XI3.1 SP04 RTM
• XI3.1 SP05 RTM
• BI4.0 SP01 RTM and All Patches
• BI4.0 SP02 RTM and All Patches
• BI4.0 SP03 RTM and All Patches
• BI4.0 SP04 RTM and All Patches

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

Interaction between a context modifier on a measure aggregation and the “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 is

Interpreted 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 an aggregation expression

For a “where” operator with a condition on a dimension outside an aggregation function, the “where” condition was incorrectly applied before the aggregation calculation. The condition is now applied after the aggregation with the respect to calculation accordingly of the parenthesis.

Example:

AggregationFct ([measure]) 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 values

Details 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 will 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:

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 running calculations will not automatically reset for each new 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.

After 4.1 SP03, the running 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 (3^rd 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" .

Data order in running calculations

A running 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 previous result (processing by column)  with a new version (BI 4.1 SP03), the user can use the value COL as 2^nd parameter.

From BI 4.1 SP03.3, to ensure that you receive results for this formula that correspond to the previous document versions, the system automatically rewrites the formula using an ad-hoc parameter FORCE_COL with 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:

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

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 December the 31th of 2012 = 1

“MonthsBetween” function

A set of days over two months was 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 # and if ending day # is the end of the month and 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 dimensions inside 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.

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

Aggregation functions can process individual objects inside a merged object

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 merged object

An aggregation on a variable object whose formula is based on an object [A] that is participating in a merged object, was processed based on the merged object instead of the given object [A]. The aggregation is now processed according to the given object [A].

Migration:

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 regression was found in the following 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:

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 1^st query, the intersection of the two objects results in the values 2004 and 2005, while with the year from the 2^nd 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 1^st or the 2^nd query:

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:

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]:

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

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]):

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 6
  • SP04, 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:

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.

Hiding a Report Element when a Formula is True

This section is about the “Hide when following formula is true” setting. This setting can be found in the Format dialog box of any Web Intelligence report element: tables, charts, forms, sections and free cells.

Formula Evaluation when the Data is Null

Null is not 0. It is neither greater nor lower than 0. Indeed, Null is not a numeric value and will not return any result in a numerical expression. As a consequence, hiding a report element on a formula condition will not give any result when the evaluated data is Null.

Example:

Hiding a table when the formula “[Data] >= 0” is true, will not hide this table if [Data] is Null.

To hide this table, the formula should be: “[Data] >= 0 Or IsNull([Data])”.

A defect in previous versions of Web Intelligence would evaluate Null as a numeric value greater than 0. This issue has been corrected, which may explain why some report elements are no longer hidden in migrated documents.

Versions where the wrong behavior can be found:

• 4.1 SP3 from patch 2 to 6
• 4.1 SP4 from patch 1 to 3

Versions where the correct behavior can be found:

• 4.0
• 4.1 up to SP2
• 4.1 SP3 and SP4, outside the above patches
• 4.1 since SP5
• 4.2

Formula Evaluation with a Filter on the Data

When a filter is applied to an object assigned to a report element and that filter removes all values of the object, then this object no longer exists in the calculation context of the report element (i.e. at the most detailed level). As a consequence, hiding the report element on a formula condition based on the filtered object is no longer possible: the evaluation returns no result and the report element is not hidden.

In previous versions of Web Intelligence, the filtered object would sometimes remain in the calculation context and be evaluated as null or zero, depending on the evaluated formula. As a consequence, the report element would get hidden.

Example:

We have the following table:

1) Format the table as follows:

“Hide when following formula is true:” = [Year] <> “2016”

Result: the table is hidden as expected

2) Now, filter out [Year], in the table:

For instance, define a filter such as: [Year] equals to “2012”

Result: the table is no longer hidden. Since [Year] is completely filtered out, it is removed from the calculation context of the table. As a consequence, the "hide on formula" condition cannot be evaluated.

In this situation, hiding the report element can be achieved in two ways:

• Use the “Hide when Empty” format setting on the report element.
• Alternatively, the object can be evaluated at the report level in the “Hide when following formula is true” condition, with the “In Report” context modifier. For example: “Hide when following formula is true:” = [Year] <> “2016” In Report will hide the above table even when [Year] no longer exists in the context of that table.

Versions where the wrong behavior can be found:

• 4.1 SP3 from patch 2 to 6
• 4.1 SP4 from patch 1 to 3

Versions where the correct behavior can be found:

• 4.0
• 4.1 up to SP2
• 4.1 SP3 and SP4, outside the above patches
• 4.1 from SP5
• 4.2

Other Functions and Calculation Changes

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

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.

In the example below, Year and Country are incompatible:

After XI R2 SP03, Web Intelligence returns the measure value calculated using the compatible dimensions. In the example below, Revenue is calculated by Country:

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

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

As shown in the following table, in XI R2, the sum for the formula if([Year]=”2002”;1;0) returns the sum of the visible values, whereas the sum of the variable referring to the same formula (MyVarIf) returns the sum of the multiple occurrences 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 can have its own projection function. The projection function is the default aggregation used by the Web Intelligence calculation engine when consuming a measure in a block. The projection function can be a sum (by default), a count, a min, a max, or it can be delegated to the data source. The projection function can also be set to “none”, in which case the Web Intelligence calculation engine will process the measure as a dimension (aggregation by identical values).

The “Count” projection function counts the occurrences of each unique value in the list of values of a measure. But it 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:

•       Web Intelligence server: (64bits): C:\Program Files (x86)\SAP  BusinessObjects\SAP BusinessObjects Enterprise XI 4.0\win64_x64\config
•       Web Intelligence 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 did not 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:

<Rules>

  <Rule name="ExtractPlainDimFromWhereCond" enable="true" force="false">

    <!--List of version where the behavior changed-->

    <Version value="12.3.6.1006"/>  <!-- Titan XI3.1 SP3 FP06 -->

    <Version value="12.4.1.1188"/>  <!-- Titan XI3.1 SP4 FP01 -->

    <Version value="12.5.1.1357"/>  <!-- Titan XI3.1 SP5 FP01 -->

    <Version value="14.0.5.882"/>    <!-- 4.0 SP5 RTM -->

  </Rule>

  <Rule name="ResetOnSectionForCumulative" enable="true" force="false">

    <!--List of version where the behavior changed-->

    <Version value="11.5.10.0"/>

  </Rule>

  <Rule name="UseMergeDimInAgg" enable="true" force="false">

    <!--List of version where the behavior changed-->

    <Version value="12.3.2.0"/>

  </Rule>

  <Rule name="UseColForCumulativeOnXTabBody" enable="true" force="false">

    <!--List of version where the behavior changed-->

    <Version value="12.x.x.x"/> <!-- All XI3.x versions -->

    <Version minvalue="14.0.2.798" maxvalue="14.0.2.846"/>

    <Version minvalue="14.0.5.882" maxvalue="14.0.5.1249"/>

    <Version minvalue="14.0.6.1036" maxvalue="14.0.6.1145"/>

    <Version minvalue="14.0.7.1147" maxvalue="14.0.7.1147"/>

    <Version minvalue="14.1.0.896" maxvalue="14.1.0.896"/>

    <Version minvalue="14.1.1.1036" maxvalue="14.1.1.1072"/>

  </Rule>

</Rules>

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.

In order to achieve financial statements reports, I had to work out how to work with the BW hierarchies.  This document is meant to share the things I learned.

This is accomplished in BI 4.1 SP6 for a NEW GL reporting environment.  Virtual BW InfoPorviders - Inverse routines and Hierarchies to set it all up.

• To have the complete Hierarchy, inclusive the nodes/GL accounts not booked, I had to merge hierarchies.  One from a Bex Query based upon Transactional Data, ie InfoCube and one based upon Master Data, ie InfoObject.

2 queries added in query panel

• Select all members to represent all in your report

• To have a correct merge, you have to merge "uniquely", ie you have to have each node and each GL account uniquely defined in your merge.

Use Unique nodes/gl Accounts, no linked hierarchy possible in WebI,

• If it is not possible to work on the KEY/Code of your hierarchies, then merge the Hierarchy as Text and Merge as well the Key

     If Hierarchy is based on TEXTS then MERGE KEY as well, to have an unique Hierarchy

• Set Merged hierarchy properties to the MD-hierarchy to represent the entire hierarchy

• Set Default Hierarchy Expansion if needed. This feature is available in BI 4.1 SP6 and ensures when opening/refreshing the report the hierarchy will be expended as set by default.  Note the selection is level-based!

• Put Make up to the hierarchy to achieve a higher readability, by using formula depth()

You can add Conditional formatting to achieve that.

• Calculate specific parts of your Hierarchy by using depth as well, DO NOT USE sum()

Total of the hierarchy if the hierarchie exists without one upper top node is calculated by just [amount]

OR by sum ([amount] where ([Hierarchy].depth=0)) (In older BI versions we noted, by expanding/collapsing the sum result calculated as above changed)

• Reverse Sign of Hierarchies is accomplished by using a Formula Variable (Replacement Path on your infoobject) in Bex Query Designer, The new measure can be used for calculations, NOTE DO CALCULATE WITH THE INITIAL VALUES DO NOT CALCULATE WITH THE MULTIPLIED BY REVERSE SIGN VALUES

• Multiple Language is set by using next to GL account - infoobject also using a node - infoobject;  Both infoobjects are set as language depended.  By changing the viewer local the user is capable to see the reports/Hierarchies in different languages.

• SAVE REPORT PURGED and set REFRESH ON OPEN, to dynamically retrieve hierarchies updates. The default level will expand the renewed hierarchy nicely. Otherwise a manual handling (purging will be necessary)

• INPUT CONTROL - tree list, only possible on not merged dimension

Hi guys,

Error:

"The system cannot find the path specified" when trying to open a Web Intelligence report saved as an Excel file.

Environment:

• SAP BusinessObjects Enterprise 3.1 SP6
• Web Intelligence reports

Steps to get Error:

1. Open the report
2. Select 'Document'
3. Select 'Save to my computer as'
4. Select 'Excel'
5. Select 'Open'

Error Details:

The system cannot find the path specified

Version:12.6.0.1596

Application server:

http://businessobjects:8080/AnalyticalReporting/cdzServlet

Stack trace:

java.io.IOException: The system cannot find the path specified

at java.io.WinNTFileSystem.createFileExclusively(Native Method)

at java.io.File.createNewFile(Unknown Source)

at com.businessobjects.wp.tc.TCMain.saveToFile(Unknown Source)

at com.businessobjects.wp.tc.TCMain.saveToFile(Unknown Source)

at com.businessobjects.wp.tc.TCMain.saveAsExcel(Unknown Source)

at com.businessobjects.wp.tc.TCMainPanel.showSaveAs(Unknown Source)

at com.businessobjects.wp.tc.TCMainPanel.actionPerformed(Unknown Source)

at javax.swing.AbstractButton.fireActionPerformed(Unknown Source)

at javax.swing.AbstractButton$Handler.actionPerformed(Unknown Source)

at javax.swing.DefaultButtonModel.fireActionPerformed(Unknown Source)

at javax.swing.DefaultButtonModel.setPressed(Unknown Source)

at javax.swing.AbstractButton.doClick(Unknown Source)

at com.jidesoft.plaf.vsnet.VsnetMenuItemUI.doClick(Unknown Source)

at com.jidesoft.plaf.vsnet.VsnetMenuItemUI$MouseInputHandler.mouseReleased(Unknown Source)

at java.awt.Component.processMouseEvent(Unknown Source)

at javax.swing.JComponent.processMouseEvent(Unknown Source)

at java.awt.Component.processEvent(Unknown Source)

at java.awt.Container.processEvent(Unknown Source)

at java.awt.Component.dispatchEventImpl(Unknown Source)

at java.awt.Container.dispatchEventImpl(Unknown Source)

at java.awt.Component.dispatchEvent(Unknown Source)

at java.awt.LightweightDispatcher.retargetMouseEvent(Unknown Source)

at java.awt.LightweightDispatcher.processMouseEvent(Unknown Source)

at java.awt.LightweightDispatcher.dispatchEvent(Unknown Source)

at java.awt.Container.dispatchEventImpl(Unknown Source)

at java.awt.Window.dispatchEventImpl(Unknown Source)

at java.awt.Component.dispatchEvent(Unknown Source)

at java.awt.EventQueue.dispatchEventImpl(Unknown Source)

at java.awt.EventQueue.access$200(Unknown Source)

at java.awt.EventQueue$3.run(Unknown Source)

at java.awt.EventQueue$3.run(Unknown Source)

at java.security.AccessController.doPrivileged(Native Method)

at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)

at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)

at java.awt.EventQueue$4.run(Unknown Source)

at java.awt.EventQueue$4.run(Unknown Source)

at java.security.AccessController.doPrivileged(Native Method)

at java.security.ProtectionDomain$1.doIntersectionPrivilege(Unknown Source)

at java.awt.EventQueue.dispatchEvent(Unknown Source)

at java.awt.EventDispatchThread.pumpOneEventForFilters(Unknown Source)

at java.awt.EventDispatchThread.pumpEventsForFilter(Unknown Source)

at java.awt.EventDispatchThread.pumpEventsForHierarchy(Unknown Source)

at java.awt.EventDispatchThread.pumpEvents(Unknown Source)

at java.awt.EventDispatchThread.pumpEvents(Unknown Source)

at java.awt.EventDispatchThread.run(Unknown Source)

Cause:

The report name contained a forward slash (/)

Resolution:

Renamed the report without a forward slash (/)

Thanks

Gerrie

SAP BO Webi report development on HANA views:

This document explains step by step creation of Hana views, Universe in IDT and development of Webi report on top of the Hana views universes. This document will give understanding of the complete development/creation of end to end scenario from Hana views to report.

In this scenario we are considering Purchase application flow and analysis of report for purchase users assuming that Purchase related data extracted thru SLT from ECC system.

Applications & Versions used for this scenario:

SAP Hana Studio 2.0.7

Information Design Tool 4.1

SAP BO Webi 4.1

This Document explains below major topics:

1. Creation of Attribute View
2. Creation of Analytical View
3. Creation of calculation View
4. Creating and Publishing universe using IDT (Information Design Tool)
5. Creation of Webi Report

Extracted Purchase order header, Item and account assignment tables and also Material, Vendor, Company code and G/L account master data tables in to HANA from ECC using  SLT.

As a best practice need to follow the proper naming conventions for creating any views. (ex: Attribute view –starting with AT followed by table name)

Step 1. Creation of Attribute View:

Step 1.1. Select the respective package –>  Right click –->  New  à Select Attribute View

Step 1.2. Select the Mara table from the schema and drop it in Data Foundation in view and double click on the selected fields for output display.

Save and activate the view. Attribute view AT_MARA created on Material Master data table – Mara:

Similar way creates other attribute views and by selecting the respective master data tables from the schema, and enable the fields which we want to see in output in each view for below.

Vendor Master – LFA1 – Attribute View

Material Master – MARA – Attribute View

Company Code master – T001 – Attribute View

G/L Account master - SKB1 – Attribute view

Once all attribute views are created it displays as below:

Step 2. Creation of Analytical View:

Below Purchase order tables are from ECC thru SLT.

EKKO : Purchase Document Header

EKPO : Purchase order Item

EKKN : Purchase Data (Account Assignment)

Step 2.1. Right click on your package -- Select New – Analytical View:

Enter the details

Step 2.2. Drag the EKKO table in to data foundation and AT_LFA1 and AT_T001 attribute views in to star join.

Join the appropriate fields of EKKO table with both attribute views based on the requirements.

EKKO.company_code = AT_T001.Company_Code

EKKO.vendor = AT_LFA1.Vendor

Step 2.3. In Semantics keep the Key fields, correct the Attributes and measures if required.

Save and activate the view.

Similarly create the other two Analytical views, all three analytical views will displays as below:

Step  3. Creation of Calculation View:

3.1.  Right click on your package -- Select New – Calculation View:

Drag two Aggregation nodes and select AN_EKKO and AN_EKPO analytical views in each node respectively.

Select required output fields in each Analytical view

3.2.  Connect the two aggregation nodes to Join Node and connect the related common fields.

Drag the Projection node and select required fields.

3.3 Select the key fields and adjust the dimensions and measures.

Save and activate the view.

Right click on the view and select Data Preview, we can see the data output of calculation view CL_Purchase

Now Calculation view is ready need to create universe to expose this data thru webi report.

Step 4: Creating universe using IDT (Information Design Tool)

1. 4.1.  Logon to IDT, In Repository Resources under the respective system expand right on Connections Node.

Select ‘Insert Relational Connection’

Enter the connection name:

Click on Next, and then select the database middle ware drivers under SAP node

Click on Next, and then enter the User name, password details of Hana system and click on Test connection button.

Then click on Finish, Now connection established to Hana system.

Expand the Connections node there we can find the new connection ‘Purchase_Flow’.

1. 4.2. Create project ‘Purchase_Flow’ by clicking on File à Newà Project and enter the project name.

Click on Finish. New project ‘Purchase_Flow’ created in Local Projects node.

4.3. Now select Purchase_Flow connection, right click and click on ‘Create Relational Connection Shortcut’.

It will popup Select a Local Project window; select our ‘Purchase_Flow project.

Relational Connection connected to project as shown below:

Select Project à right click à select New Click on ‘Data Foundation’

Enter the name of Data Foundation

Select Multi Source Enabled as IDT will support.

Check for the user authentication details..

Click on Next and select the connection which was created earlier.

Click on Next, displays the connection parameters.

Click on Finish.

Open the Purchase_Flow_DF, expand the connection node, select _SYS_BIC  schema node where all Hana views columnar table will store. Select the CL_Purchase Calculation view table.