PDA

View Full Version : Dashboard issue



Jeff Kimmel
30-Jan-2018, 03:34 PM
All,

I've setup a couple reports that have parameters defined in the SQL view connection setup. I'm using @PARM1@ and @PARM2@ as customizable variables for the query. I then pass in the values via the URL, so far so good. I then create a dashboard that contains the 2 reports and pass in the variables in the URL & it looks like it works. However, I'm using the 'Tiles' option and when I click on the tile to get the detail the passed in parameters are not being used, the defaults that I've setup in the database query are. Is there a trick or a flag that I'm not setting or using correctly?

Thanks,

Jeff

Bob Cergol
1-Feb-2018, 08:54 AM
Hi Jeff,

Dynamic view parameters aren't cached and propagated across multiple reports in a dashboard like filters are, so the 2nd report is not inheriting the values passed to the first report so is just using the defaults and no user-interface object is generated for the 2nd tile to prompt for values.

Redirected filters might work. See the doc for details but basic syntax is:

@FILTER_T:columnname@ or
@FILTER_F:columnname@
Example:@FILTER_T:EmployeeNumber@

The 'T' indicates true value, 'F' false.

This can be a bit confusing to use. Basically Dynamic AI replaces this symbol with a Boolean expression consisting of: (ColumnName = ‘RunTimeFilterValue’)

For Example:
@FILTER_F:Material

If the run time value for Material filter entered is ‘Fiber’, then the translation/replacement is: (Material = ‘Fiber’) and this will resolve true or false on any given row in the query.

In case when no value is provided at run time, then the “_F” or “_T” translates the expression as simply (1=2) to produce a ‘False’ and a (1=1) to produce a ‘True’.

This is problematic if attempting to use this syntax in the select column list because at run time it is resolved to a value of 0 or 1 – not the data values driving the expression.

It is primarily useful in a where clause. It does not work consistently if attempting to use in case or IFF statements in the query, especially regarding drill-downs.

Regards,
Bob

Jeff Kimmel
1-Feb-2018, 09:12 AM
Bob,

Thanks for the reply, although I'm not 100% sure it will work because the value I need to propagate is a date I need to compare. I did a search in the help for @FILTER and it doesn't show anything, what doc are you referring to? Also, if I can't get this to work is there a way to cancel out the click to the report or otherwise redirect what happens when the user clicks on the tile?

Thanks,

Jeff

Bob Cergol
1-Feb-2018, 09:26 AM
Search for 'redirect' in the doc. FWIW, I rarely ever use the on-line doc. Search just works better and at more granular a level using the PDF file you can download from out ftp site. See the sticky 'resources' post at the top of this forum. The doc isn't all that detailed on this subject and a bit scattered which is why I posted the additional information in my reply.

Any custom behavior such as intercepting a mouse click, would have to be accomplished using 'rule' scripting. I've done some trivial cosmetic type stuff but it's not my area of expertise. There's a "rules' tab in dashboards just like in individual reports where you can inject javascript into page before Dynamic AI sends it to the browser.

Bob

Jeff Kimmel
1-Feb-2018, 10:16 AM
Bob,

Thanks, although that doesn't appear to be able to work for me. Not sure if you'll know this or not but are the ID's that are generated by DAI always the same for the various dashboard tiles? It appears to be but I'm not 100% sure so thought I'd ask.

Thanks,

Jeff

Bob Cergol
1-Feb-2018, 07:55 PM
I don't know the answer to that but I'll try to get more information for you Jeff.
-Bob

Bob Cergol
2-Feb-2018, 07:53 AM
Jeff, I confirmed with Cintac that the tile IDs will be consistent on subsequent retrieves of the dashboard. Also confirmed scripting will be the only way you might be able to get view parameters to propagate across the tiles. If you can figure out a way to use report filters, then those will propagate. I have found that attaching a common keylist to a given filter in the reports is another method of forcing filters that otherwise are not common, to be common, across those same reports in a dashboard.

Bob

Jeff Kimmel
2-Feb-2018, 09:07 AM
Bob,

Thanks, that helps me a bit. I think I'll redirect dashboard to go to a separate report.

Jeff