We are working on updating to .600 and are having users test their things in our new environment. We ran into an issue where new parts weren’t showing up in a dashboard. After some troubleshooting, I noticed that the BAQ used in the dashboard was actually an External BAQ. The odd thing being that the external BAQ data connection is pointed at the Epicor database. This ended up being the issue because it was still pointing to the old database. This dashboard and BAQ were created by consultants that we occasionally use. Does anyone know why they would use an External BAQ? Are there some sort of benefits to doing it this way?
My best guess is that they were accessing a stored procedure, custom view, table valued function, etc. that cannot be accessed other than through an external BAQ.
3 Likes
^-- that would be my guess as well. We also use it to point to a utility DB that has SP/Functions that point back to the Epicor DB so that we can do things that are not available in BAQs. The issue is that even the external BAQs are limited in their own way.
3 Likes
probably to bypass BAQ security - company limits, etc
3 Likes
Just be aware:
“Normal” BAQs always have the extra layer of security applied to your query data… ie… it will filter out (hide) data that the user who is running the BAQ is not allowed to see. There are three main categories of additional filters: SITE (Plant), Company, and Workforce (SalesPerson). If the sales person is restricted, then only certain customers will be visible.
BUT
EXTERNAL BAQs have NONE of these additional security filters in place. The world is wide open. This can be both good and bad. but it means that if you thought something was hidden/secure, but then expose the External BAQ via a dashboard, the user may still see it.
3 Likes
We use it to access tables we added to the Epicor Database that contains info from other apps we use/created… Reading only access 
Pierre
Thanks everyone, I really appreciate it! It seemed like a silly thing to do but I guess knowing the limitations of BAQs, it makes more sense now.
i would be curious to know if these were Epicor consultants or 3rd party. Most 3rd party are not Certified and you run the risk of something like this. Please feel free to share these names with your Epicor CAM, not here, so we may look into this. Keep in mind with something like this if it breaks something support is not obligated to fix it as you may very well have voided your software warranty.
One possible reason for going to an External BAQ is simply for performance. On occasion i have moved a BAQ to External because the extra overhead consumed by the extra security that Epicor adds makes the BAQ too slow. by moving it to External, it removed the security and improved the speed. THEN we simply need to make sure that only the right people can access the dashboard so that it remains secure.
1 Like
The ole “Current Company” performance issue comes to mind here.
Agreed… I have even seen Epicor Gold/Platinum whatever Partners do everything wrong in Epicor… I wont bash them here or mention names. But there are a handful that hire juniors and charge you 200+/hr and write crap code. If any one ever needs a code review before you pay an invoice, send it in pm - free of charge!
I used Epicor for 8yrs and customized everything to the max… Multi-Company, Multi-Site, International and RARELY do I need to use External BAQ or do stuff outside of Epicor. If you use Epicor properly and have proper processes you can stay within Epicor just fine. #myopinion
I’ve seen people do direct datasets just because they dont know any better how to use RDD. They connect directly to pull a column, funnier even the column exists in the base RDD just needed to be added to the SELECT Statemenent. 
11 Likes
I’ve seen this quite a bit and also question why it’s done so often. The security reasons make sense on paper, but I feel those business cases are very rare in real life. I think it’s more a reputation thing that caught on of “external BAQs are faster”. Sure, maybe they are a little faster, but they are also a maintenance problem. When I was a consultant I didn’t think enough about maintenance / sustainability when delivering a solution. Now, as a customer, that’s all I can think about.
3 Likes
^^^^^^
This.
You hear that consultants? That goes for all customizations. Think of upgradability and maintainability with our customizations. External queries, alterations to the database (views/indexes/triggers/…, custom DLLs, etc. all can make sustainability more difficult.
7 Likes
The bums will always lose Lebowski
1 Like
Is Lebowski the head of Professional Services? 
I’ve seen some productization that ain’t very upgrade friendly. 
I had wondered about this. Some of the customization stuff that I have looked through is just mind boggling. I definitely wondered if the use of the external BAQ was something similar. Basically “this might not be the right or best way, but it’s the way I know.”
1 Like
I wouldn’t say using external BAQ’s is “wrong” per se. The mechanism is there to be used. Of course building a regular BAQ is preferable for everyone, because of simpler deployment, security, etc… But if I build a regular BAQ and it takes 20 minutes to run, while the exact same query runs in SQL in 1 minute, guess which one is going to get used. There are also queries that are simply impossible to recreate in a normal BAQ. Any query that uses OUTER APPLY, or temporary tables for example. Or a query that needs 10+ subqueries, or multiple PIVOT/UNPIVOTs. Just too cumbersome to maintain or debug in a regular BAQ IMO.
At the end of the day you do whatever you can to make the customer happy. But I agree that a regular BAQ should come first before thinking about an external BAQ.
1 Like
The flip side of this coin is that sometimes external DLLs, external queries, or additional indexes in the database can significantly improve performance or usability for the customer. If the consultant keeps proper records of everything they develop and package, there is near-zero difficulty added to deployment. Issue may come out if the customer stops doing business with said consultant and neglects to make sure they have all the proper documentation (or if said consultant neglected documentation themselves).
Ask any customer if they prefer a query they use every day running four times as fast versus a half hour more time in deployment when they upgrade.
Absolutely, the right tool for the job I always say. But unfortunately some use it as their default and use Views as a default because it is easier, yes it is - absolutely. But once they try to use the tools it’s not so bad.
I have a BAQ once pasted into Word it spans about 43 pages, it runs in about 9 seconds (CTEs, Recursion on JobProd, PartTran, UNIONs etc…) and it even has a PIVOT for RefCat. Maybe it’s just the way I lay my BAQs out strategically.
- RAW Tables first
- Work my way out to Metadata - for example there is no need to join on Customer in SubQuery1 with TranGLC – I can get the Customer Name in TopLevelQuery.
But Agreed - Right tool for the job. Also usually when we do have this massive giant Queries they are already outside of Epicor in EDD, EDA, XL Connect, PowerBI.
Typically the Consultant Companies that complain about speed (this is how their BAQs Look Like) [ Not Fake ]:
WTF - #PartnerOfTheYearAward
Their BPMs re-invent the wheel:
You have to rewrite almost everything (left is new one after I was done)
2 Likes
PS: In the Cloud you have to use the Tools, no bypassing it. 
2 Likes