Code is up now, go learn something Mr. Low Code…
Thanks for posting this. I actually had a similar thought generated from that same post… I stumbled upon it when I was looking for a way to use a parameter that was automatic (like current date). And I found I could hijack it by setting the paramter default using a BPM in a similar fashion. I want to try your version out, though, because I like how it incorporates into the BAQ and it’s a one time setup to check for that subquery.
2 Likes
I’ve been outed!
Files are posted above.
Anybody ever try it?
I’m going to have to read it again tonight to follow what you are doing, but it sounds like a solution to eactly the issue I was hoping to solve:
A 3 level dashboard, customer, projects and cases:
Projects are to be filtered by selected customer, cases either by selected customer or project. I’ve got over 20,000 cases so was concerned about speed if the case BAQ downloaded all the cases then filtered out for display what it needed.
I’m a bit of a newbie so thought “simple, use a BAQ parameter to pass the selected customer or project as the parameter”. Tried it and of course every time I select a customer in my top grid I get asked to again select a customer interactively; not what I had intended.
As it is currently the dash is a little sluggish, and I’ve decided to limit my BAQ to the top 5000 most recent cases for performance reasons. I expect If I can cut off the unwanted cases at the BAQ level things should hum, and it looks like this might be the answer.
Footnote:
I would have thought there would be an easy, built-in way to do this.
If there is, somebody please stop me, before my head explodes trying to get to grips with Kevin’s work here! 
Unfortunately not.
That being said, there are certain use cases where you could do other things.
Read the thread by @JasonMcD where we discussed it.
I did provide a solution file if you want to one-shot it. I’m hoping it’s plug and play.
If not, I will troubleshoot.
It’s actually pretty simple, most of the code is just putting it all the common places, and
their associated differences, and some status features, and to make entering variables as
painless as possible.
After reading this, it sounds more like you are wanting silent parameters, than variables.
Is that correct?
yes; I am just wanting the case BAQ to filter at the query level to cases for the selected customer.
Having said that, the distinction between “variables” and “parameters” is not clear to me; but certainly have used parameters in SQL queries in the past and the use case here is analogous.
Why yes, they are the same thing at the base level.
My distinction in my question was more along were these parameters to be static and hardcoded into the baq, or to be populated via dashboard in some fashion?
Populated by the dashboard.
Currently I have this structure, to which I’d like to maybe add customer contacts also, if it can be done effifciently:
(machines are projects to us)
So here the Cases for Customer and Cases for Machine are currently filtering (cases for customer):
I am assuming this is inefficient with the grid level filtering, unless epicor is clever enough to pass the filter up.
But then I’m also wondering at which point all these views actually get populated. Do they all get loaded whether visible or not? I am creating a Kinetic app at the end of the day so only one is visible at a time, selected by the View combo.
(All Cases can probably get dumped and go into its own, separate be-slow-if-you-like dashboard)
Anyway, assuming epicor isn’t super smart with passing the grid filters up to the baq query level automatically, I thought I’d put an afterRowChanged event my customer views, and in that populate a parameter/variable in the cases query from there (similarly for machines) that would rerun the query, and i’d then get rid of my redundant grid filtering.
Having said that I’ve spent most of the day trying to get my head around Kinetic through the many and varied threads here; maybe I’m being over ambitious. Super helpful stuff, but so much I don’t yet get; my frazzled brain is going “[BPM].erp-rest’??{Transview.whaaaat}{BAQ,0}'erp.ice.bo.service@help!”
But don’t quote me on that. 
Parameters are built in to BAQs:
And they work great in (classic) dashboards:
But variables… don’t really exist in Epicor as @klincecum said.
It seems like this a wheel you are reinventing…
1 Like
The wheel seems a bit square, as you cannot set parameters silently through code/application studio. Or rather you can set them, but every time the BAQ parameterised query runs, it wants to interactively (and redundantly) ask the user for the parameters via a slider panel (at least in Kinetic, at least as far as I understand it).
I think Kevin’s project here is a workaround for that.
It’s not, but the principles behind it could be stretched to do what you want.
I had already had some thoughts along those lines.
When they are coherent I will share them 
Ah, OK, well, possibly, but your screenshots were of classic dashboards, so I was speaking to that.
I definitely know of the problem in Kinetic, but I was thinking someone had figured it out, i.e. @hmwillett ??
I tried to look but I didn’t see a solution.
Pub-sub here:
This question with no answer here:
Without reading the rest of this post (because who’s got time for that??), this may be helpful? Kinetic Dashboard with Parameters - Kinetic 202X - Epicor User Help Forum (epiusers.help)
I wouldn’t say I got it fully working, but it’s like… 80% there with what I had to work with.
2 Likes
Thanks @hmwillett,@JasonMcD and @klincecum .
To clarify: It sounds like I should not bother creating the dashboard from the classic dashboard creator at all, just start with a blank kinetic application, add my BAQ grids and link them using pub-sub and execution parameters as decribed in Hannah’s articles?
Sounds like a weekend project!