Dashboard Pass Silent Parameters to BAQ

Dare I say CTE!!! Would love love love to use this with a nice CTE

2 Likes

Bingo! Recursive Job to Job, Serial Numbers, BOMs etc… It would make it so much easier to just run the Query with params and get exactly it than trying to grab it all and then filter on hierarchy and putting in customizations to look for ‘*\Job*’ etc…


2 Likes

yeah words

OMG, three CTEs within the single query. You are realy in love with CTE :slight_smile:

2 Likes

Sometimes you need all the data’s

1 Like

All right so @Dmitry_Kashulin is claiming his future chances at finally acquiring a unicorn are at risk. I for one would never, ever deny anyone their shot at :unicorn: glory!

What if we scope it to just this for now:
When you add a Query (BAQ) to a dashboard your tab are: General, Publish, Filter
We are talking about adding an addition tab Parameters
it would look very much like the filter tab - except you cannot add or set columns here you simply see the list of BAQ parameters and you cannot control condition it is just equals.
You can then map that parameter to the same value options you have when setting the filter. If you leave it unmapped you get the prompt to enter the value like you do today.

If we go to size this and do, I want to keep the first pass simple. Every additional complexity layer adds significantly more cost and my goal is to keep this small enough that we might be able to just sneak it in one dark sprint. If it gets too big it goes into the ‘whose demands for the release get done’ scrum and past experience doesn’t bode well.

So if this basic set meets your needs, I’ll go grab a developer and get them to size it up for me.

1 Like

This needs to be in the add a tracker though. Not in the add BAQ. The tracker needs a field for the user to type in something that will be used as a parameter. So really just adding the parameters from the BAQ into the list on the general tab, would be all that needs to be done.

The way you proposed, the parameter may not be a column value, so the mapping as you explain it would be odd, because only columns in the query show up in the tracker.

3 Likes

Perhaps in that the instance of a BAQ having params it forces a tracker panel even and that does what Patrick described functionally but from the panel. The panel would be editable like normal but the query fields handled like native fields in any screen we can’t touch them. Not sure if that falls into the realm of not flying under the radar though lol

Got it I think there are two underlying concerns. The one that I was drawn in for is this problem:
When filtering results in subquery I do not want to pull back all data and do a client filter, I want to be able to use the published value from Query 1 mapped to a parameter in Query 2 so the result set to hte client is vastly reduced.

Your bringing up a related problem which is I want to add a query parameter as a user enter able criteria option. I will have to go back and look I haven’t spent much time in dashboards recently but I thought how it handled the criteria panels was to build a where clause and pass that up to the Dynamicquery service to run it already. My memory may be incorrect on that.

Ahh, I wasn’t even thinking of the pub-sub part of it. Yes that would be helpful for sure. I was just thinking of the simple single query dashboard. I figured that would be an easier nut to crack first.

I like the thought. My instinct is never force anyone to have UI elements they don’t want - some significant portion of the user base will get mad at me :grimacing: The idea of mapping the control to a parameter and having parameters in the list of selection options may work though.

Fair enough. Do both lol! For sure it’s out of the under the radar scope I know it ha ha ha ha

1 Like

If parameters can be passed in as a “sudo” filter (like filters are now) and they can be pub sub to a header query that would cover nearly all cases.
Because we could easily make a little query which is just used for Parameter prompting.

This I think would work, (at least until a full UI for parameters can be developed)

1 Like

Just a tought … and it’s out of scope right now.

IF and only IF, Epicor was plannig to provide a way for a BAQ to call another BAQ’s (as a subquery), the solution will have to be able to handle that case also (passing parameters to the subquery).

Thanks, Patrick.
You described exactly what I envisioned to get my unicorn finally.

1 Like

Rumor has it that a PO on the tools team may have just completed the smoke test of a new feature for 10.2.vnext. Something about being able to, on the query object in the Dashboard designer to map a value such as a published column to a BAQ Parameter.

These reports are of course completely unconfirmed and the nameless PO preemptively denies being the source of any leaks to that affect.

7 Likes

That PO May have earned him/herself quite a few drinks at insights! If one were to figure out who he/she is.
That is delightful!

1 Like

That. Is. AWESOMESAUCE!

@Banderson probably wishes now he could come back do Epicor and not NetSuite.

2 Likes

@pferrington @Dmitry_Kashulin I know this is out of scope - But slim chances in the near future we could apply something similar to BAQ Reports, so we can pass one of those Form Bindable fields to the BAQ before it runs. Just like Dashboards… BAQRpt’s BAQ Grabs 10,000,000 rows (lets say you have that many Jobs) and then filters it after execution, thats the only reason I try to avoid them BAQ Rpts and Quick Searches etc… all have to run wide-open and can’t bind to a param.

Lets say a Quick Search if I can atleast bind the text-box to a BAQ Param and then when user types “123” I can do a LIKE “@txtBox1%”

1 Like