Still waiting for this check.
And you’ve confirmed that on the network tab in Dev Tools?
What happens if you run it through Swagger?
Something @klincecum is dearly missing.
I can confirm that the rest call that is made by the BAQ builder succeeds and returns data without error.
Whats swagger? Never used it. (or more likley, I probably have and never knew it was called that)
It’s a browser REST, um, thingie (technical term).
I’m not at my computer but the URL is similar to the one you go to Kinetic with, but after Apps/ change it to RestHelp (Apps/RestHelp) or something. You’ll be able to call your BAQ via REST and see what it does.
Oh that thing, yes I know exactly what you mean, that’s called Swagger? huh, I’ve always just called it the rest helper
Yep
Epicor Swagger → https://serverpath/api/help/v2/
Epicor Rest Help → https://serverpath/apps/resthelp
Two flavors of basically the same thing.
erm, its super slow for some reason, not sure if that is due to the browser parsing the Json or something, but it does run via servername/api/v2/odata/JAMS/baqsvc/[BAQ NAME]
(after I created a new API key, forgot i had done a live to test copy the other day and overwritten my API key, that stumped me for a minute )
edit:
Thats a bit of RAM usage!
So yeah… erm…
i got nothing, it works literally everywhere but in application studio.
Start debugging. Rogue where clause?
Let’s take a look at the request to run the baq.
what was funny, with the amount of data it returned broke the swagger UI in the browser and it did this with the shocked emoji
but I confirmed in the dev tools that it ran, succeeded and the content was returned, was just too much JSON for the browser to parse.
here is everything in the network tab when attempting to refresh the data grid view thingy
I do see it is using v1 not v2, could that matter?
For shits and giggles, throw a new panel card grid in there and set the provider model to execute your BAQ. Does that run? If yes, then the conversion messed up and you should probably just build this one from scratch.
If that doesn’t work, indulge me and make a copy of your BAQ with a shorter name and try again.
Thats what this is already.
I had given up on the conversion a while ago, what I have done now to try and figure this out, is go back to the BAQ, added some new where clauses to limit the data returned (this was done in the browser in the new BAQ builder) to less than the BAQ test limit, so I know that I am seeing all rows and it’s not a strange thing like you suggested and on Row 12069 there is a rogue null where there shouldn’t be that breaks it.
Then I went into Application studio and did just that, added a grid and wired it to the BAQ, I did this via the wizard and manually and it does the same thing either way, the new app studio dashboard will not run the BAQ but every other method of doing it works just fine.
This is leaning more towards a bug to me now, rather than something I am doing wrong.
Just trying the shorter name thing, stand by
^ try that
Next question, and I’m sorry of you’ve answered this already (it’s been a night ): is this the only BAQ this happens with? Do others work?
Yes we tried a bunch and it affects some but not others, the simpler ones seem to be OK but the more complex queries have this issue, have not been able to extensively test everything though, let me just do a quick test on name length and see what happens
made a copy called km01, tested in BAQ builder and works a treat, added to app studio dashboard - nothing.