Filling Out A Calendar

My report requirement states that all months – whether they have sales data or not – must appear in my output. Because Web Intelligence cannot make up data to fill out the missing months, I need to have an alternative source. In the first post in this series I showed how to do that with a personal data provider as I built out the data in a spreadsheet. This time I am going to show how to do the same thing using only a universe. In order to provide a complete (clean) solution I am going to have to make a new object in my universe.

The first step is to create a query that returns some data. I am going to use the same data that I started with on the last post, which is six months of sales revenue data from the eFashion database. I am also limiting the data to the year 2001 in order to match the example from the last post.

Next I will create a second data provider from the calendar table that includes all of my month values. Since this query has no restrictions (conditions) and no measures (no joins to any fact table) it will be guaranteed to return every month. At this point in the last post I detailed how to merge (link) two data providers together. This time that step is not required. That’s the first advantage of using universe data to perform this step: the dimension objects that are shared across my two queries are already merged (linked). When I used personal data, I had to do the merge step myself.

Once I drag the merged month into my report block I will see all 12 month names. As I did last time I will also replace the existing Month Name detail object with the one that comes from my calendar data provider. The results from these operations are shown in the screenshot below. The “Discontinued” value comes from a custom format used in the eFashion universe. The universe was designed with the assumption that if any cell was empty (as opposed to zero) then there were no sales for that item, and it must have been discontinued.

I would like to insert a zero value into those “Discontinued” cells. I could make it look like it has a zero by changing the format. But if I want an average of that column to be impacted by the fact that I had zero sales for six months out of the year, I need to have an actual zero in the cell, not just a custom format. It’s at this point that I have gone as far as I can without talking to my universe designer.

Creating and Using Placeholder Objects

As a universe designer I can help solve this problem. I might create a special class called “Placeholder Objects” that includes new objects used to solve this type of problem. (I have also seen these objects called “dummy” objects because they are only going to work in very specific situations. They’re not “smart enough” to be used by themselves.) When I used personal data to solve this issue I created a new column in my spreadsheet and put a zero in for every month. In my universe I will create just one object with a zero value in the select clause and nothing in the tables. Note that this object will not parse; that is expected.

Since this object does not have a table associated with it I will need to make sure that it’s used with at least one “real” object in a query. As a universe designer I can’t enforce this. But if a report writer tried to use this object by itself the query would not run. I have seen some folks suggest that objects like this should be pointed to the DUAL table (in Oracle) or something similar. I disagree. The only benefit to doing this is that the object will parse. But at the same time I am fixing that issue I would be introducing an entirely new set of issues because the DUAL table isn’t typically going to join to any other table. It’s much more effective to leave this object in a state where it won’t parse than to deal with all of that mess.

Rebuilding the Query

Once I have created my dummy object and exported the updated universe I can fix the problem. In fact I can fix it a couple of different ways. First, I could mimic the solution from the last post by adding the zero object to my calendar-only data provider. Since I have already covered all of those steps I thought I would show a different technique for this post. I am going to use a UNION query.

A union requires that all of the queries (you can have two or more) match. Each query has to include the exact same number of objects, and the object types (character, date, number) have to match as well. For the scenario I am using for this post each query will have three objects. Both queries will include the Month and Month Name. The first query will also include the new Zero object. The second query will include the regular revenue object. Here are the two screen shots showing what this query looks like.

Query Panel Union Part 1

Query Panel Union Part 2

Notice that the first query does not have any conditions at all? The second query includes the condition that I created to drop out months (it only shows months with an “e” in their name) as well as a limit to show data only for 2001 as mentioned earlier. When I run the combined queries I see this output.

At this point the data looks great, and it was obtained with a minimal amount of fuss. All of the months show up as required. There are no merged dimensions here since everything is returned in a single data provider. However, there is one item that needs to be fixed. Check out the column headers… they’re not exactly “user friendly” at this point. What happened? It turns out that column headers from a union query are taken from the first pass of the data provider. As a result my column header says “Zero” instead of “Sales revenue” as I would expect. Fortunately Web Intelligence (the Rich Client in this case) makes this process extremely simple. All I have to do is open the query panel and drag “Query 2″ in front of “Query 1″ in the union area of the query panel and rerun. After rerunning the query I am left with a report block that is missing a measure. This is okay, because the object named “Zero” has been removed from the query, and a new object “Sales revenue” has appeared. All I have to do is drag that new measure onto the block and I see these results.

Notice that I have added an Average calculation in the footer to show that the zero values are being included during the calculation. The result obtained via this process is now essentially identical to that shown in the first post about making up data.

Conclusion

So far I have shown two different techniques that can be used to “make up” data for a report: personal data and universe data. Which is better? As with many questions the answer is “It depends.” Personal data has an advantage in that it can be built on the fly by a report user and does not require any universe maintenance. Universe data has an advantage in that the extra objects are reusable and are available to anyone. With proper training users can build queries that can include extra data that does not exist in the database.

Personal data requires me to know how to merge the results. With universe data the merge step (as long as I use the same objects) is performed automatically.

In this post I also showed two different techniques for getting the “filler data” into my report. With personal data I have to create two data providers and merge the results. With universe objects I have the option of creating a single data provider using a Union technique and my placeholder object.

The placeholder measure object that I created is not limited to this particular report. I can use (and reuse) it for any other report with similar requirements. Since the object is not tied to the calendar (or any other dimension) I can use it anywhere. It can be used to merge data providers or in a union query. I can create similar “dummy” objects for dates or text fields as needed. Ultimately I can decide if I want these special objects to be visible to all users or to a selected subset of “power user” report writers using the standard security process.

Next Time

For Part III of this post I am going to create a more complex example where data might be missing from more than one dimension (instead of just month as I have used in the last two posts.) I am also going to show cross tab and a section output because each of those can cause some interesting challenges as well. Maybe I’ll even do a sectioned cross tab.

Related Posts

• Making Up Data Part I: Personal Data Providers

I have only six months of data, but I have to show all twelve months in my report. How can I show the missing data?

The trick is to understand that Business Objects does not make up data. It just doesn’t have that capability. And you can’t edit the report directly in order to add those extra values to the result set. However, there are a couple of tricks that I can share that will help solve this issue.

Special Note to Blog Readers: This post is fairly long because it has quite a few screen shots to illustrate the process. As a result it will be presented in several pages. When you get to the bottom of a page just click on the next page number from the links provided to continue reading the post. Since this is the first time I have used this feature I thought I would warn you about that. Now on with the solution.

Using Personal Data

One of the easiest ways to make up data for a report is to use a personal data provider. This technique can be used in all versions of Desktop Intelligence and also in the newer “rich client” version of Web Intelligence. While the specific steps are unique to each tool the general concept is the same, so I will only show how to do this using the rich client. Screen shots for this blog post were taken from version 3.0 of the Web Intelligence Rich Client.

The first step is to determine what is missing and therefore what you need to make up as filler information. It’s also important to know that the format of your personal data has to match what is coming from your enterprise data source or the data won’t merge properly. For this scenario I will show some data coming from the eFashion database. I am going to restrict the data to months that include an “e” in their name, just to make sure that I have holes in my data. If you’re wondering, that includes February, June, September, October, November, and December. Why did I pick that? No reason, really, just thought it would be fun.

After applying that condition (along with another to restrict to one specific year) I see the following data on my report.

In the eFashion universe the Month is a dimension object and is a numeric value. The Month Name is a character string containing the month name spelled out (October rather than just Oct) and is configured as a detail object. This is important. When I want to merge two different data providers together I have to perform that process (the merge or link step) using only dimension objects. I cannot use detail objects. That means my personal data provider will have to include the month number as a dimension, and it should also include the month name as a detail.

After building up this query I have six months of data, as described in my original scenario. To meet the report requirements I have to show all twelve months, including those that don’t have sales that meet my current criteria. How can I make this happen?

Making Up Data

I am going to use a spreadsheet to make up my data, but I could just as easily use a delimited text or CSV file created with any text editor. The trick is that I have to structure my personal data so that it matches what I already have from the universe. To solve the scenario I am currently working on that means that I need the month number and the month name in my personal data. Here’s how that looked when I was done.

I saved this data on my computer as a standard spreadsheet file. I could also have used a comma separated values (CSV) or other structured text file just as easily. The next step is to import this data into my document.

Adding Personal Data

In order to add personal data to my document I open the query panel, right click on the current query tab, and select the option to add a new data provider. After I do that I see this dialog box.

After making sure I select “Local data source” I move on to the next step, which is to browse my computer and find the spreadsheet file I saved earlier. Once I find the file I am presented with a few configuration options as shown here.

The filename is there, of course. Since I am using a spreadsheet I can pick which sheet from the workbook contains my data. I can also determine whether to use a named range, to enter the range myself, or to let the client try to figure out where all of the data is for me. For this simple case I mark “All fields” and let the client do just that. Finally, I confirm that the box for “First row contains column names” is checked and click the Next button. Here is what I see at this point in the process.

There are a couple of problems with this result. The client is trying to be helpful, but it’s making the wrong decisions for me. The Month column contained all numeric values so it was imported as a measure. The Month Name contained character data so it was imported as a dimension. Both of these assumptions are wrong. I need the month number to be a dimension so I can link it to the value I already have, and I need the name to be a detail in order to match the existing structure on the report. Fortunately, since this is my own personal data, I am allowed to make changes to the configuration.

So how do they work, exactly? What do I mean by unbalanced data providers? How is it fixed with these functions? Are there any special conditions to be aware of?

Merged Data Provider Review

I recently published a blog post that described unbalanced data providers. If you want the full description, I have included a link at the end of this post. If you want the executive summary, here it is:

When you have two (or more) data providers in the same document and want to merge the data, you have to link them using dimension objects. If you don’t have the same number of dimensions from each data provider, then they are unbalanced. That can cause issues.

It took me twelve hundred words (and six pictures) to provide a detailed explanation in my earlier post. In the sample report I used for that post I had one common dimension (Year) and one unique dimension from each side (Resort and Region). I showed how I could use Year with either measure since it was a shared (and linked) dimension.

I also showed how (and explained why) trying to use the “extra” dimensions like Region or Resort caused problems. I don’t intend to repeat everything here; please use the link at the end of this post to read the prior post if you are unclear on anything so far.

What About MultiCube()?

One of the comments I got on that post suggested that MultiCube() could be used to fix the issue. My response was accurate as far as I was concerned, but later when I read it again I realized it could also be quite confusing. Here’s what I said:

…the MultiCube() function will help if data providers are unbalanced “upwards” but not “downwards” …

After reviewing my response, I realized that it was quite likely that I was the only person that understood what I meant by that statement. While at times I do enjoy talking with myself that’s not why I have this blog. So I am going to try to explain that a bit further.

The problem with trying to use MultiCube() or the Web Intelligence equivalent ForceMerge() to solve this specific case is that the data doesn’t support the solution. There is no hierarchy or relationship between Region and Resort. (Yes, they are both related via links to the fact table but that’s not what I mean.) Resort is a place. Region is an attribute of the customer. There is a many to many relationship between regions and resorts, and that sort of relationship is essentially worthless. If I can’t determine how to put things together, how are the numbers going to make sense? Neither of these functions can create a relationship from nothing.

Yet there are some cases where I can fix unbalanced data providers. I need to talk about the data first, then I need to create a new document with the proper structure in order to show how the ForceMerge() function works.

Hierarchical Data

Here is what I consider to be a really good example of why this is a problem. Most people think of time as a really clean hierarchy. On the surface the hierarchy is simple: Months go into quarters, and quarters go into years. Yet if I create a query with the Quarter and Revenue from the Island Resorts database here is what I get.

Take a look at the data and tell me how you would break out the quarter data into different years.

Go ahead and think a bit, I can wait.

One-Mississippi.

Two-Mississippi.

You can’t do it, can you? You don’t have enough information. As defined, with the format “Q1″ and “Q2″ and so on, there is no indication as to which year the quarter revenues are coming from. You can’t “break down” the quarter by year with the information that you have. That is what I meant by data being unbalanced “downwards” in my comment on my prior post. I can’t break data down because the information simply isn’t there.

What I can do, however, is roll up or move “upwards” via a hierarchy. That’s where the ForceMerge() function comes into play.

Introducing the ForceMerge() Function

Here is what the help text says for the ForceMerge() function.

Forces Web Intelligence to account for synchronized dimensions in measure calculations when the synchronized dimensions do not appear in the calculation context of the measure

I will explain what this means, but first I am going to build my example. My document will have two data providers from the Island Resorts Marketing universe. My first data provider has dimension values Country and Resort and the Revenue measure. My second data provider has the dimension Resort and the measure Guests. I will link the two data providers by Resort as it is the only common dimension.

Data Provider 1

Data Provider 2

Data Provider Results

Merged Dimensions

From this point I will create a merged block using all of the measures and both dimensions. Here are the results from that experiment.

Everything is fine so far. The issue becomes evident when I remove the Resort object from the block. Remember that my two data providers are merged (synchronized) by Resort. When that object is no longer present in the block, the measures roll up. Revenue is still okay because the Country object was part of the query context of that data provider. The Guests measure fails because it is now being viewed out of context. (At the risk of becoming tedious, I will point out one last time that this issue is covered in much more detail in the first post in this series.)

I have created a problem. Next, I will explain how to fix it.

ForceMerge() In Action

All of the information I need is there in the document. It just does not show up in the block. Here once again is the help text for the ForceMerge() function:

Forces Web Intelligence to account for synchronized dimensions in measure calculations when the synchronized dimensions do not appear in the calculation context of the measure

Simply put, the function tells Web Intelligence to use all of the information from the cube, rather than being limited to what is shown in the block. I will create a new variable with this formula:

=ForceMerge([Number of guests])

I will replace my “broken” measure with my new variable and observe the results.

I haven’t changed my dimension linking. I haven’t changed my data providers. I didn’t even change the block structure, other than to replace the broken measure with my corrected calculation. If you were looking for something more complex, I’m afraid that’s all there is. The complicated part is understanding just what the function does and when to use it, rather than how to use it. I am glad this function is now available in Web Intelligence starting with XI 3.x. In my opinion, it should have been there since merging data providers was an option.

Summary

The magic of the ForceMerge() function (or if using Desktop Intelligence the MultiCube() function) is that it changes the behavior of the report engine. Normally when dimension values are removed from a block they are taken out of context. By using one of these functions I can specify that linked dimensions still have to be considered by the measures even if those dimensions no longer appear in the block structure.

Even with this magic function in my arsenal, I cannot rely on it to fix every problem that I have. If the data can be “rolled up” by the calculation process then I am fine. If the data has to be “broken down” then I am in trouble, and these functions will not fix the issue. Each resort exists in exactly one country so I can move up the hierarchy from the resort link and the results are valid.

Special Note
If there are smart measures in a universe, then ForceMerge() will not work. In order to calculate the results correctly, smart measures (using the “database delegated” projection function) need to have the block structure in place to define the query. According to the documentation, the ForceMerge() function will return a #MULTIVALUE error if used in this situation.

Related Links

• Blog Post: What Are Unbalanced Data Providers… And Why Should I Care?
• Blog Post: “Smart” aka Database Delegated Measures

What was that “Mississippi” thing earlier?
From Wikipedia:

Children in the United States and Canada often count ‘One-Mississippi, two-Mississippi’ during informal games such as hide and seek to approximate counting by seconds.

So now you know.

Merging Data Providers in Web Intelligence

Dimensions are the “keys” of a data provider. When two database tables are linked in a universe, certain columns are used to join them together. Dimensions serve this role in linking two data providers. When two (or more) data providers are built in Web Intelligence from the same universe they are automatically linked together using any common dimension objects. What happens when two different data sources are used? In that case, the report writer has to merge the information manually. And if the dimensions from each data provider are not identical, the report has what I call “unbalanced” data providers. That’s what I want to describe in this blog post.

For my sample I will join two data providers from the Island Resorts Marketing universe. I am going to structure my queries in such a way that they will result in an unbalanced scenario. For my first query I will return Resort + Year + Revenue. For the second query I will return Region + Year + Number of Guests. Resort, Year, and Region are all dimension objects, of course, and Revenue and Number of Guests are my measures. Here are the raw results from each individual data provider. (I am using Web Intelligence XI 3.0 for this demonstration.)

I have one common dimension. I also have two dimensions that are unique, one from each data provider. Since both data providers come from the same universe, the common or shared dimension value (Year) has already been linked, as shown here.

Because the Year object was already merged, I can create a report block that contains Year, Revenue, and Number of Guests. I can also do local variable calculations like Revenue per Guest using simple division.

This is what happens when everything works. What if something doesn’t work?

Mixing Dimensions Generates Unexpected Results

This block shows what happens when I add Resort to the block shown previously.

Notice anything interesting about the data? About the Number of Guests column specifically?

When the year repeats, the Number of Guests repeats. The Revenue measure seems fine. Before I explain this, let me exchange the Region object for the Resort object and show what happens.

In this case, the Revenue column is strange and the Number of Guests looks okay. To make matters even more confusing, here’s what I get if I apply a Sum() to the Revenue column after doing a break on the Year…

The sum on the footer is identical to the values displayed in the block! Any idea what’s going on?

Measures Do Not Sum, They Project

The secret is that Web Intelligence does not sum a column of values like Excel does. A few weeks ago I discussed the difference between SQL Aggregation and Report Projection which helps explain this. Simply put: when a measure is combined with a set of dimension values in a block, the measure will project (roll up) based on the structure of the block. This is also called the context of the measure within the block. (Please note: The use of the word “context” in this case should not be confused with the concept of a context — set of joins — in a universe design.)

Because of the way I structured my queries, the Revenue context is determined by combinations of the Resort and Year objects. The context of the Number of Guests was set by Region and Year. The Year value is the only common dimension between the two data providers, which is why the block with only the Year dimension object showed valid data. However, if I include a dimension that is not part of a measure context, a problem occurs. When Region was added to the block the Revenue was wrong. When Resort was added the Number of Guests was wrong. In each case, the measure was out of context for at least one dimension.

To repeat: When I created the block with Year as the only dimension everything was fine. Each measure includes Year as part of its context. When I added Resort, the Revenue measure was still in context (and therefore showed the correct results) but the Number of Guests object was out of context. As a result, it used the only context it could (Year) and rolled up to that value, then repeated that value each time the year appeared on the block.

What about that weird behavior of the Sum() function? It turns out that a Sum() doesn’t really add up the column values. It does a projection instead. When the block included both Year and Region, the Revenue measure was valid for only the Year therefore it projected to that value. As a result, the measure value is repeated for each different Region in the body of the block as long as the Year is the same. Adding a break on Year created a footer for the block. Since the context for the footer was Year only, that made the Revenue projection (total) for the Year the same on the footer as it was for the body.

Unbalanced Dimensions

Now that I have been through all of that, let me finally explain what I mean by “unbalanced dimensions” as used in the title of this blog post. In my data providers I have Year as a common dimension and Resort hanging off of one side and Region hanging off of the other. Web Intelligence will prevent me from adding both Resort and Region to the block at the same time, but it will allow me to add one of them. Assuming I do that (add an extra dimension) I will have two dimensions from one data provider and one from the other. Two against one is unbalanced.

Resort, Year <-> Year
        Year <-> Year, Region

It doesn’t matter which side the extra dimension comes from either.

If you have more than one data provider the following rules apply.

1. All common dimension values should be linked
2. Measure context is defined by the dimensions in their source data provider
3. A block with linked dimensions and measures works fine
4. Unlinked dimensions from one data provider can be used; others will be designated as incompatible
5. Measures from the data provider that includes the extra unlinked dimension will be fine
6. Measures from the other data provider will repeat for each unlinked dimension value because they are at least partially out of context

With all of these complications, Web Intelligence does what it can to show the data properly, even to the point of having the footer totals be correct despite the presense of an unlinked dimension. It’s better to manage your data providers to avoid this challenge, but it’s nice to know how things work if you can’t do that. There are other techniques that can help (like creating variables to demote a dimension to a detail object, if that action is appropriate) but this post is long enough already.

Both Desktop Intelligence and Web Intelligence provide options to coordinate the placement of one block based on the size of another. This technique is used when you have more than one block on a page and you want the lower blocks to move up and down (or left and right) on the page based on the volume of data shown in the “relative” block. This works quite well with two blocks as shown below.

The block on the left in this case (the blue box) would be the anchor block. The block on the right (the red block) would float relative to the anchor block. I can accomplish this by right-clicking on the floating block and selecting Format Block. The Appearance tab includes the following settings that I can tweak:

This technique works well for a chain of tables either horizontally or vertically. But what if I have the following scenario where I need to float blocks both horizontally and vertically?

The screen shots that will be included in this post are taking from Business Objects 6.5. The same concept should work in Web Intelligence as well, although I don’t at this time intend to post those instructions. If you don’t know how to simulate the “hide block” option in Web Intelligence you can review my prior post on Chart Alerters in Web Intelligence to see how that could work. Now on with the show.

The Setup

I created a query with Year, City, Store Name, Lines, and Revenue from the eFashion universe. My requirement calls for a three-block layout with the top-left block being store revenues, the top-right block is annual revenues, and the lower chart block will show lines revenues in a bar chart. Either the store block or the annual sales block could grow vertically. My requirement also calls for a prompt on the state. My challenge will be to figure out how to make the chart shift up or down based on either of the two top blocks. There is no option to make one block relative to two other blocks, so I will have to be creative. I like challenges like this.

Take Care of the Basics First

The first step I take to solve this challenge is to give each of my blocks a descriptive name. Since the annual sales block is to the right of the store sales block I will let it float horizontally based on the width of the store block. That’s fairly straightforward. Here is what the data looks like when I refresh the report for Colorado:

Everything looks fine. But when I select Texas for my second refresh notice the problem that I have:

I could solve this by making the chart block float relative to the store revenue block. But that won’t help if there is only one store that has ten years of sales. In that scenario the annual sales block will encroach on the lines chart just like the store sales block has done in this case. I need to make the chart block float relative to two blocks rather than just one.

Variables to the Rescue

The solution requires me to be able to tell which block has more data. In this simple scenario it will not be too hard. I have two blocks each with one dimension each. If I count how many dimension values there are and compare the two, I will be able to tell which block is going to be bigger. Here is the variable that I created, called Which Chart:

This flag returns two distinct values: Year Chart or Store Chart. The formula is structured in such a way that the flag returns the name of the chart that I want to hide. But wait a minute, I only have one chart, right? How does one chart end up with two names?

Double Charts

In my earlier post on Chart Alerters I showed how to create two duplicate charts, one green and one red, and then set up formulas to only show one or the other. I think I can use that trick again here. To solve this challenge I will create two charts. In this case the charts are identical other than their names. They even share the exact same location on the page, as shown here.

By the way, the Structure Mode option from Business Objects really helps in completing this report.

The final steps are to float each chart relative to one of the two upper blocks, and then hide based on the variable that I created earlier. If the annual block has more rows than the store block, then the chart that floats relative to the store block needs to hide since it won’t move down far enough. If the store block has more rows then the chart related to the annual block needs to hide for the same reason. Here are the screen shots of those settings:

Notice that the float is relative to the Annual Sales block, and the hide formula is active if the chart to hide is the Year Chart.

For the second chart the float is relative to the Store Revenue block, and the hide formula is active if the chart to hide is the Store Chart.

Test the Results

Once I finish creating my two charts, configure the relative float numbers, and create my hide conditions, how does it all look? The pictures tell the tale…

Summary

The purpose of this article was to show how to simulate the ability to float a block relative to two anchor blocks rather than just one. Since Business Objects does not provide this feature directly I used a variable, two charts, and a “hide block” setting instead.

Associated Downloads

• BusinessObjects 6.5 Sample
  This download was built using the eFashion sample database provided by Business Objects. It should be accessable to anyone using version 6.5 or higher. The source file is zipped so you will need an unzipping utility to extract the file.

Officially there is no way to put an alerter on a chart. Yet some time back I was challenged by a client to create a line chart that was green if the overall trend was up, and red if the overall trend was down. This chart appeared in a sectioned report so there was a different chart for each section value. Possible? It turns out that there was an answer that works. With minor changes it works in both the desktop and the web products as well.

The eFashion database and universe are used in this demonstration.

Solution using Business Objects 6.5

The first step is to get some data that will support this requirement. I selected the Lines objects from the Product class, the Year from the Time class, and the Sales revenue from the Measures class. Depending on your version of eFashion data you might have slightly different values but the 6.5 version of the database looks like this:

As you can see from reviewing the data the Accessories product line is in an overall downward trend if you take the first and last year as the only data points. City Skirts is in an upward trent, and City Trousers is again in a downward trend. I don’t intend to do a true trend analysis with moving averages; I am going to make a very simple definition of “up” or “down” and use the first year and last year as my only two data points for this tip.

The next step is to create a variable that determines the trend direction. I am going to need a variable because that’s how I can determine which chart to show later on. The variable is hard-coded in this sample since I know what the end points are. The formula for the variable looks like this:

=Sign(<Sales revenue> Where (<Year>="2003") - <Sales revenue> Where (<Year>="2001"))

There are two components to this formula. The first is the “Where” clause on the measure value. This applies a filter to the revenue so that the value for the measure is filtered to a specified year rather than showing a total. The second component is the Sign() function. The Sign() function is fairly simple: it returns the numeric sign of the argument. If the argument is any positive value, no matter how big or small, the sign is +1. If the numeric argument is negative, the sign is -1. If the number is zero the sign is zero, and finally if the number is undefined the sign is also undefined.

The results of this formula are shown here:

Notice that each product line has an appropriate trend, based on the difference in the 2003 revenues and those for 2001? I will be using this again shortly.

The next step is to set up the chart. For this example I am going to use a simple line chart as it shows the trend in the most obvious fashion. First I created a section on Lines, and then a line chart with Sales revenue and the Year data. Here’s what the first version of the chart looked like, and I’m not entirely happy with the results:

What don’t I like? Because of the difference in scale I can barely see the second chart as it is using the same scale as the first chart. Here is what I would rather see:

What I have done here is activate a setting that tells the report to use the scale within each section rather than for the overall report. I think it’s going to be much easier to read. Here’s where that setting appears:

I now have a chart that I like, but it doesn’t fit the requirement yet. All of the charts are green, even those that are in a downward trend. The next few steps will complete this tip and solve the problem. First, I will duplicate the chart so that I have two identical charts. I will then change the color on the second chart so that it is red. (At the same time I increased the weight of the line just to make the charts more visible.) Here’s where these steps leave me:

The final step is to ensure that only one of these two charts appears for each section. This is done by right-clicking on the chart, selecting Format Chart, and going to the Appearance tab of this dialog box. I started on the red chart and entered a “Hide” formula that looks like this:

=<Sales Trend> = 1

For the green chart I do something similar but use this formula instead:

=<Sales Trend> <> 1

Here’s the screen where this is done:

What does this do? If the trend is positive then the red chart is hidden. If the sales trend is negative or zero then the green chart is hidden. So I get something like this:

I’m almost to the end of the technique… the last step is to carefully size and position the two charts so that they occupy the same space. Since I know only one or the other will ever be displayed I want them to be in exactly the same space. This provides the illusion that there is a chart alerter that is changing the color of the chart based on the trend of the sales data. The reality is there are two charts that switch places. Here is the final output:

Part II of this article will continue this idea and show how to accomplish the same illusion using techniques available in Web Intelligence.

Summary

The purpose of this article was to show how to simulate the appearance of a chart alerter. Since the tools do not provide this feature directly I used a variable and the “hide block” feature instead.

Functions Used

• Sign()

Associated Downloads

• BusinessObjects 6.5 Sample
  This download was built using the eFashion sample database provided by Business Objects. It should be accessable to anyone using version 6.5 or higher. The source file is zipped so you will need an unzipping utility to extract the file.