Here’s a really simple example: I want to ensure that a user enters an end date that is at or beyond the entered start date value. This validation rule is designed to avoid confusion since many databases will not return any rows for a “backwards” between operation. (It’s also a fairly common request, found as far back as 2006 in this topic on BOB and again 2008.) I can think of two ways to make this work. First, enforce the prompt entry order so that the user cannot enter the second date before they enter the first date, and give me some way to reference their first entered date in the list of values (LOV) for the second date. By making the second prompt constrained I would force the user to pick from the list of dates, and by referencing the first date in the LOV I can ensure that the only dates that show up do actually occur after the first date. This is technically probably easier to implement, but not the preferred solution.

A second option would be to allow me to create validation rules that fire after all of the prompts have been entered. This is far more flexible as it allows the user to respond to prompts in any order they would like (as it works today) but the validation is done before the query is sent to the database. This could be far harder to implement, primarily because I envision some form of validation language (VB? Crystal?) would be required. Do they invent some new language, or try to implement something that already exists? What if the language is not supported on all platforms? The date example that I have used so far seems fairly trivial: the rule would simply be end_date >= start_date which doesn’t look that complicated. It looks like an expression rather than a language, but a language is more than that. A full-blown language can have a grammar, reserved words, and all sorts of rules that specify how the various components can be compared.

Does my prompt validation language allow looping structures? I might want to be able to loop through a list of selected items in the case where a prompt offers more than one value. “Make sure all of the end dates are greater than or equal to the latest selected start date” would be one example. First I have to parse the list of start date values to find the largest entry, and then I have to process the list of end dates to make sure that 100% of them exceed the largest start date.

Doesn’t look so simple any more, does it?

Any prompt validation logic would also have to ensure that validation loops don’t exist. Here I have defined validation rules on each entry that can be true individually but can never be true collectively. This is actually a data entry or coding error but I need to be able to check and react to that.

• Rule 1 on the start date: Make sure that the start date is greater than the end date.
• Rule 2 on the end date: Make sure that the end date is greater than the start date.

Can the start date be greater than the end date at the same time the end date is greater than the start date? Probably not. Since only one of those two rules could ever be true at a given time the query would never run. With three (or even more) prompts the potential complexity for validation loops only gets worse.

How Might Simple Validation Logic Work?

As a universe designer I am charged with creating components of code that ultimately will be placed together in some random fashion by a query writer. I have no idea what sort of questions they’re going to want to answer, nor should I be constrained by that concern. I should be able to make prompt objects that function perfectly fine by themselves, but also in combination with other prompts. The “start date / end date” example I started with is very simple. Consider this syntax:

some_table.some_date between @prompt('Enter Start Date','D',,mono,validate:&1<&2) and @prompt('Enter End Date','D',,mono,validate:&1<&2)

What I have done here is supplement the "free/constrained/primary_key" option with a new feature: validate. The syntax breaks down like this:

The < character is providing a simple validation expression "less than" using a standard mathematical symbol. Other options might include >, >=, <=, ==, and !=. These are all single-value operators that would not support a multi-selection prompt, and the scope of the &1 and &2 doesn't extend beyond this particular prompt object, but it's a start.

Named Prompt Components

In order to extend my validation scope beyond a single prompt I need to ensure that I have a unique name that I can reference. (As an aside, this is why class names must be unique within a universe structure. The class name\object name combination must be unique within the universe in order to support the @Select() functionality.) To do this, I might extend my new prompt syntax with the following:

I have introduced two new arguments. The extra argument &0 will allow me to define a unique name for this prompt, and &n:name allows me to reference that value in another prompt. Now I can create two separate prompts that look like this:

Start date check
some_table.some_date >= @prompt('Enter Start Date','D',,mono,validate:&0:start_date&n:start_date<=&n:end_date)

End date check
some_table.some_date <= @prompt('Enter End Date','D',,mono,validate:&0:end_date&n:start_date<=&n:end_date)

Keeping in mind that it is entirely likely that I would have more than one start date or end date in my universe, I would have to use more verbose prompt names like account_start_date or invoice_range_start_date and so on. In the above example I have two prompts, each has a name, and each has a validation rule. By allowing prompts to have names I can reference the result of one prompt inside of another prompt.

Event Triggers

The next challenge could be to determine when the validation logic fires. Does it fire at the end of each prompt selection? I can't really see that working because all of the required values might not yet be defined (selected). Does the validation logic fire when the query is executed? That also might not make sense because if I have a chain of three prompts where 3 depends on 2 and 2 depends on 1 I should be able to trigger the validation as soon as any two values are present. In my simple "start date / end date" example it would be easy to say that the validation logic fires as soon as both values are present. I also haven't addressed how to create the message that is delivered to the user if the prompt validation fails...

Most of the complexity in this process comes from the fact that I'm trying to design a fully generic solution. I don't want to have to write new code for each new prompt screen that I might design, I want to create reusable logic and syntax that works across the entire universe. I think it's easy to see why this is such a complex question, and perhaps indicates why we don't have anything like it so far within the universe.

But being able to set up a date value like "today" as a dynamic default value... that should be easier to implement. I hope we see that... and soon.

The Problem Definition

For the example I will present in this post I will once again use my version of Island Resorts Marketing universe which I have converted to Oracle. I will create a report that initially shows the Resort and (for simplicity) a single measure (Revenue). The report will be designed to let the user drag on additional details like Service Line and Service. But I will design my objects in such a way that if the user doesn’t want to see the information at that level of detail they don’t incur the overhead (row count) simply because the object is present in the query. In order to accomplish this, I will prompt the user with a list that includes the tokens ‘Resort’, ‘Service Line’, and ‘Service.’ The user will select the lowest level of detail they expect to use on the report. In this particular example the selections are hierarchical, meaning that selecting ‘Service Line’ implies that the Resort data will also be present. There is another option ‘None’ that can be selected if they want to deactivate the entire list.

Note that XI 3.1 offers a new feature called Query Stripping (in service pack 3) that works for BW and other OLAP queries and does this process automatically. It is not (yet) available for relational databases.

My steps are:

• Create a derived table to provide values for my prompt
• Create a custom LOV query to display the prompt values in the desired order
• Create a prompt object that allows a user to select the desired level of detail
• Create custom Level of Detail (LOD) versions of the impacted dimension objects
• Build my report

Creating the Level of Detail Prompt

First I have to create some data in my universe to feed my list of values (LOV) query. I have detailed this technique before. It’s quite simple to use a derived table and select against the DUAL table (in the case of Oracle) or equivalent and build any sort of list. Something like this will give me a list of values for the Resort level of detail (LOD) prompt.

select 1 as LOD_Order, 'Resort'  as LOD_Resort from dual
union
select 2, 'Service Line' from dual
union
select 3, 'Service' from dual
union
select 4, 'None' from dual

I have defined two columns for my derived table. The first is called LOD_Order and it will be used to order the prompt items in the way I expect to see them. The second column is the value that will populate my LOV. After creating this derived table I checked to see what the values were, and they came up as expected.

Creating the Custom LOV Query

The next step is to build the objects I need to create the list of values (LOV) that will appear in my prompt definition. I will create a class called “LOV” that includes objects for both the LOD_ORDER and the LOD_RESORT columns. Eventually these objects will be hidden, but I will need them to be visible in order to create my custom LOV query. The LOV will be built on the Resort LOD object, and initially it won’t look too special. It includes only the selected object. The trick is that I want to see the values in a specific order; that’s why I added the “order” column to my derived table. In order to create a sort on this object, I need to click on the Manage Sorts button shown here.

That button is only active if my database supports an order by clause that includes objects that do not appear in the select clause. If that button does not appear and I know that technique will work, I can update my designer parameter file as detailed in an earlier post titled, “SORT_BY_NO=NO? Very Confusing…” which shows how to accomplish that. Clicking that button allows me to define a custom sort based on the LOD Order column.

When I run the query I see the rows in the order I expect.

Defining the Prompt

I am going to reuse the prompt logic in multiple objects (Resort, Service Line and Service) so I am going to define it once and reference it using the @Select() function. Here’s the prompt:

@Prompt('Please select desired Level of Detail','A','LOV\Resort LOD',mono,constrained)

This is fairly standard syntax. The prompt text is defined, and the type of response is ‘A’ for character data. The LOV definition points to the custom query I created in the last step. I only want to allow a user to select a single value, and because the data only works if it comes in as I expect I am constraining the user. They have to pick from my list in order to proceed.

Building the Level of Detail Objects

I will be able to save some effort by reusing the prompt definition using the @Select() function. Here’s what my new Resort object looks like:

case @Select(Level of Detail\LOD Prompt)
when 'None' then 'Resort N/A'
else RESORT.resort
end

Resort is the top of the list. That means if I pick Resort, Service Line, or Service, I want to see the resort values populated. This means I can take a shortcut. If the user selects ‘None’ then I won’t show the resort values. If they pick anything else, I will.

The rest of my objects look very similar.

Service Line

case @Select(Level of Detail\LOD Prompt)
when 'None' then 'Service Line N/A'
when 'Resort' then 'Service Line N/A'
else SERVICE_LINE.service_line
end

Service

case @Select(Level of Detail\LOD Prompt)
when 'None' then 'Service N/A'
when 'Resort' then 'Service N/A'
when 'Service Line' then 'Service N/A'
else SERVICE.service
end

What I did was add a line of code to each of my objects, since each was at a lower level of detail. Note that I could have taken the opposite approach and defined my Service object like this:

case @Select(Level of Detail\LOD Prompt)
when 'Service' then SERVICE.service
else 'Service N/A'
end

Building the Report

I can now create a very simple report that includes all three of my new LOD objects and the Revenue. When I run the report at the Service level of detail it will show all of the detailed data, just as it would have before I created these custom objects. The results from Island Resorts end up being 27 rows of data.

If I rerun the exact same report at the Resort level of detail I get three rows.

The objects that I dropped from my level of detail are showing “N/A” values in the block. The prompt shows my four choices in the desired order because of the customizations I did for the LOV earlier.

What is the true impact here? What have I really accomplished?

Impact Analysis

Sample databases like Island Resorts are great for fooling around because they’re small. They’re not so great for demonstrating techniques like this because the true impact is hard to determine. I went from 27 rows down to 3, not really a big deal, right? On a larger database with more combinations of dimension values, the impact could be far more significant. I might drop from 50,000 rows down to several hundred. And the beauty of it is that if the user doesn’t need the level of detail, they don’t pay the penalty of downloading 50,000 rows only to roll it up (via projection) on the report. If they later drag on one of the suppressed objects and see the “N/A” result, all the user has to do is refresh the report and select the new level of detail to get more rows.

My sample report screen shots included all of the objects at the same time in order to show what was really happening. When I used this technique for a real report, I only included objects that I wanted to see from the beginning. The other LOD objects were listed in the available objects.

Alternate Solution

The solution I outlined here works as desired if there is a rigorous hierarchy and the user is just selecting the lowest level of detail desired on the report. What I actually had to implement was a bit more complex and I will provide a sketch of the solution here. The actual requirement was based on different combinations of dimension objects. A matrix of choices might look like this:

Resort (by itself)
Service Line (also by itself)
Service
Resort + Service Line
Resort + Service
Service Line + Service
Resort + Service Line + Service
None

Instead of the simple case statement objects I showed earlier, I had to use a pattern matching function and look for the string “Resort” anywhere in the prompt result. If the user picked anything that included the Resort as an option, then the Resort object would return a value. Ultimately I created prompt “bit” objects in order to simplify the logic.

Conclusion

I thought this was an interesting technique to share at this point, what with the recent release of SP3 with the Query Stripping feature for cube data. It worked well for the project. In some cases this strategy allowed us to reduce the number of rows by an order of magnitude (10,000s of rows down to 1,000s or even hundreds) while retaining a large number of objects in the report. The biggest drawback of this solution is that my SQL code will still hit the requested tables, even if I am not really requesting any data. Going back to my earlier example, a true query stripping process would eliminate the resort, service line, and service tables if I selected ‘None’ from the prompt. In my “level of detail” solution all of those tables are still present and therefore have an impact on the query performance.

The issue I was trying to solve in this case was related to the number of rows downloaded to the report. The queries ran fast enough that the query performance was not as big of a concern. It was my goal to provide a way to reduce the row counts without losing the flexibility to add more dimension objects to my report on the fly. This technique accomplished that.

Documentation is Good

Designer 3.0 is the first time that I have been able to find the extended prompt syntax documented. It even mentions the primary_key attribute which was apparently present (and usable) in XI R2. This feature allows me to create prompts in the Universe Designer that will still leverage Index Awareness, assuming I have set that up.

Here is the prompt syntax shown in the XI 3 Designer manual:

@Prompt(’message’,'type’,[lov],mono/multi,free/constrained/primary_key,per
sistent/not_persistent, [{'default value':'default key'[,'default value':'default
key',...]})

I’ve covered the prompt syntax before so I won’t review everything. But the new features are interesting. The new feature primary_key was used in my “Ninja” presentation from last year with a disclaimer about it being an “undocumented feature” and the note of being a bit risky to use as a result. Now it is not only documented but there is a modifier for the default value option as well.

Using Index Aware Objects With Prompts

Recall that index awareness is designed to create more efficient SQL. Instead of

RESORT.RESORT = 'Bahamas Beach'

I would see

RESORT.RESORT_ID = 2

With the new prompt parameter I can specify the default value in a value:key pair, like this:

RESORT.RESORT_ID = @Prompt('Please select Resort', 'A', 'Resort\Resort', mono, primary_key, not_persistent,{'Bahamas Beach':'2'})

The option mono of course means I will only select one value. That is not new. The option primary_key tells the SQL generator that this object is index aware, and that I want the key to be used rather than the value. The option not_persistent is used to tell the SQL generator that I don’t want to retain the last user selected value. And finally, the string 'Bahamas Beach':'2' is used to show that the default value shown to the user is Bahamas Beach but the default value provided to the prompt is the key value 2 instead.

Special note: if I want to use a default value, then I have to specify not_persistent. If I don’t, then the default value is only good the first time the query is refreshed. From that point forward the last user selection will be used instead.

What About Those {}?

A reader with extremely good attention to detail will notice that the syntax I posted above does not match what was shown in the user manual. In order to get the object to parse I had to follow the exact syntax shown in the function help in Designer rather than what is in the documentation. What’s different? The code I used has curly braces { } around the value:key pair at the end. The curly braces are also used when providing a hard-coded list of values, so I guess that’s not too surprising.

Conclusion

The primary_key and default:key additions to the @prompt() syntax are quite powerful, and should be well-received by universe designers. I feel much more comfortable using something that is documented (even with slight errors) than using a feature that isn’t detailed in the documentation or help files anywhere. The concept of index awareness just became a lot more attractive with this addition.

This feature was one of several mentioned in my Designer Essentials presentation delivered at the 2008 GBN conference. This feature was covered on page 9.

You can’t do it, sorry.

At the end of that post I mentioned something called a “magic date” that I frequently use in my universes to get past this limitation. That’s my subject for today.

Problem Definition

I have a date prompt in my universe. I would like to be able to provide a default value of today’s date. This would allow my users to click-n-go on the report without having to update the date value each time. It is also essential for scheduled reports, which is something I didn’t really touch on last time. When I schedule a report, I have to provide values for every prompt. I have a long series of posts on how to create some dynamic date objects that can be used for scheduling, but those were not prompts.

In a nutshell: I need a way to accept a prompt value and convert it to today’s date for user convenience and for scheduling. Can I make that happen?

Defining the Magic Date

First, a quick recap. When I set up a prompt in the universe, one of the required arguments is the datatype. A ‘D’ designates a prompt as a date value. That means that anything entered in that date prompt field has to pass the basic validation that will be done by the application. I can’t put the word “Today” in this prompt, as “Today” is not anywhere close to being a valid date. That’s where the concept of a “magic date” comes from.

What I do is define a specific date as the magic date. Quite frequently I will use something like January 1, 1900, as it is highly unlikely that any of my records will include that date as a valid entry. That is the first important point about this concept: I must pick a date that will never appear as part of my normal data. That’s my magic date.

Defining the Prompt

Once I have selected my magic date I can now create my prompt using the basic five parameters. It might look something like this:

@prompt('Enter shipping date','D',,mono,free)

In this prompt I am asking for a shipping date, I am expecting a valid date value, there is no list of values, and the user will enter only one value. There’s nothing magical about that prompt. The magic comes in when I create the condition object that includes that prompt. Imagine that I have a report that is designed to show orders that shipped today. Suppose that my magic date is January 1, 1900, as I mentioned before. Here’s what the code looks like (I will explain it after):

orders.ship_date = case when @prompt('Enter shipping date','D',,mono,free) = '1900-01-01' then DATE else @prompt('Enter shipping date','D',,mono,free) end

I’ve used Teradata syntax here but the concept applies to any database. (Teradata offers several options to return the date for “today” and DATE is the example I selected here.) One of two things will happen in this condition. A user will either enter a standard date, or they will enter the magic date. If they enter a standard date the code resolves to this:

orders.ship_date = case when '2008-07-21' = '1900-01-01' then DATE else '2008-07-21' end

In this case the case logic eliminates the first option and takes the second option and the net logic becomes:

orders.ship_date = '2008-07-21'

What if the user enters the magic date? Using the same process the code first resolves to this:

orders.ship_date = case when '1900-01-01' = '1900-01-01' then DATE else '1900-01-01' end

Which is logically the same as this:

orders.ship_date = DATE

So, there I have it. By applying a case statement to the right-hand side of this database condition, I can react in two different ways. In one case I take the user parameter value exactly as entered. In the other case I convert a special date (magic date) into the system current date instead. Now if one of my users schedules a report with this prompt, all they have to do is enter 1900-01-01 as their date parameter and each time their scheduled report is executed the parameter value will change.

Conclusion

With some creative date logic I can convert the magic date to today, yesterday, end of this week, end of last week, end of the month… just about anything else that I’ve already covered in my dynamic date series of posts. I can use the concept of a “magic number” for numeric prompts and a “magic string” for text prompts as well, although those are generally not used as frequently.

Would it be nice if I could use a variable in a prompt to avoid this sort of extra work? Sure, I think it would. I listed a bunch of different prompt enhancements that I have been looking for, in some cases for years, in my last post on prompts. One of those enhancements that I (and a gazillion other folks) would like to see is proper cascading prompts. I plan to have that as my next post on prompts.

Problem Description

I have a report. The report has a date prompt. I want the date prompt to have a default value (partially possible) and I want the default value to be “today” instead of a standard date. The question is quite reasonable, in my opinion. Prompt handling has been one of the weakest points of the Business Objects tools for a long, looonnng time. A prompt can be created on a report or in the universe. If the prompt is defined in the universe there is a standard syntax. So I will start with a brief review of that syntax and move on from there.

@Prompt() Me One More Time…

The standard prompt syntax has five arguments. The first two are generally considered required while the remaining three are optional. Here is the syntax:

@prompt('Enter prompt text here','A',LOV Source,mono/multi,free/constrained)

I’ll break down each of those five parameters next. First, the prompt text. The first argument is required and is the most obvious… it contains the text that the user will react to. It’s a good idea to let the user know what’s going on and to provide some clue as to how the prompt will operate. For example, if you are using a prompt in an equality test, you should inform the user that they can only select a single value. If you are using the prompt in a list, then let them know they can select one or more values.

The next argument has three options: A, N, or D. These match with the datatype expected from the prompt. The ‘A’ represents alphanumeric data, and any data entered is accepted as it was entered. Using an ‘N’ denotes a numeric prompt and only valid numeric values are accepted. Finally, a ‘D’ represents a date prompt. With this type of prompt Webi will include a spiffy calendar that a user can use to select their entry. This is available even if the LOV has been turned off.

The third parameter is a reference to a potential list of values for the prompt. There are two possible options: either a hard-coded list, or an object from the universe. If I wanted to make a hard coded list with the values “Yes” and “No” on it here is the syntax:

{'Yes','No'}

The values are surrounded with curly braces { } and entered as a comma-separated list. Character data is in quotes. Simple enough, yes? no?

If I wanted to use an existing object in the universe for the list of values I would enter that choice without the curly braces and in the format 'Class Name\Object Name' instead. One common designer mistake is attempting to use a table.column syntax here. The table.column is of course the eventual source for the list of values, but the LOV query is defined as part of an object definition. That’s why you enter an object here rather than a table column.

The last two parameters are optional, but even if you leave them out you have to include the commas for the prompt syntax. In other words, this is valid:

@Prompt('Do you like BOB?','A',{'Yes','Yes, of course'},,)

Even though the values are missing the commas remain. What do the values do if you include them? The fourth parameter allows you to specify whether the prompt is a multi-select option or not. The value mono (no quotes here) says the prompt is restricted to a single value. The value multi (again, no quotes) allows for multiple values to be selected. The fifth parameter determines whether the user can type the prompt response or if they are required to pick from the list of values. The value free does the former, and the value constrained requires the LOV selection. Here’s a hint: don’t make a prompt constrained without providing a valid list of values source.

So those are the five basic arguments for the @Prompt() function. Most of you will have noticed that none of them have anything to do with providing a default value.

@Prompt() Extended Syntax for Web Intelligence

We got some new prompt options starting with Web Intelligence 6.x. One of the options a report writer could use was whether or not the last prompt value entered was the default for the next report run or not. Another option was whether the prompt had a default value or not. And finally, report prompts could appear in a user-specified order rather than in alphabetical order as before. But all of these options were report specific and not supported in Universe Designer.

Here’s what the extended prompt syntax looks like:

@Prompt('Enter value(s) for Something:','A','Class\Something',Multi,Free,Persistent,{'Default Option'},User:0)

I’ve already covered the first five parameters so now I’ll detail the last three. The sixth parameter has the value Persistent or Not_Persistent. The default value is to retain the last value entered (Persistent). This is also the legacy behavior; previous versions of the reporting tools only worked in a persistent manner.

The seventh parameter has a syntax that looks a bit like the hard-coded LOV from earlier with the curly braces. This is where a default value for the prompt can be stored. And finally, the last parameter determines the order of the prompt, starting with zero (0) as the first prompt and incrementing from there.

To reiterate something I stated earlier: These are report options only. These parameters can be entered into a prompt object definition in the universe, but they are unlikely to parse because of the extended syntax. In order to test this syntax I would have to export my universe and test in a Web Intelligence query.

What About That Default Value?

Extended prompt parameter number six: a default value. That brings me back to the original subject for this post, doesn’t it? I wanted to have a value like “sysdate” or a formula of some kind like CurrentDate() plugged into that parameter. Unfortunately, it doesn’t work. Any value entered for that parameter is treated as data, and no formulas or calculations will be calculated. So anything like sysdate or getdate() or CurrentDate() is going to fail.

The next trick is to try to reference an object, and store the formula as the object definition instead. Unfortunately, again, it fails. The object name becomes the default value for the prompt which is generally not the intended result.

Conclusion

What it boils down to, as I see it, is this: you can’t do it. There is no way to create a prompt syntax that will substitute in a value like “today’s date” for a prompt default value. It would be nice, but it doesn’t work.

However, I do have a work-around that I’ve used for many years. I create a “magic date” and some creative logic within the prompt to do the substitution after the user has already responded to the prompt. That’s the subject for the next post in this series. Stay tuned for details.

Things I really REALLY wish prompts could do…

1. Set a default with a variable. It’s the subject of this post, need I say more?
2. Be optional! With XI 3.0 a report writer can create optional prompts now, but we still can’t do them in Designer. Boo.
3. Do cascading prompts effectively. This has been on my wish list for-EVER. I have another post about cascading prompts coming up soon so I’ll save the majority of my whining until then.
4. We have free and constrained, I want a third option: validated. This would be the best of both worlds. A user would be “free” to enter the value if they wanted to, but it would be validated against the LOV provided in the universe. Today I have to allow the user to shoot themself in the foot by typing the wrong value, or I have to force them to use the LOV.
]]> http://www.dagira.com/2008/07/15/how-can-i-make-today-my-default-prompt-value/feed/ 47