Ability to import/export BAQ via plain-text format

I am requesting this feature to make it easier to share/view/mange BAQ code via GitHub, something which benefits all of us.

Currently when I export a BAQ, it doesn’t open in editors like Notepad++ or Sublime, instead it seems to be some proprietary format. It would be very useful if the .BAQ format was something human readable so that the BAQ code can be added to GitHub in a human readable format. Yes, I can copy the SQL code from the BAQ window to GitHub, (which is great!) but then there is no way to import this code back into a new BAQ, so it is mostly unusable by others.

Rather than a feature to copy/paste the SQL code directly into a BAQ (which has its obvious risks), a way to import/export a BAQ to a human readable format would provide one layer of abstraction to shield the general BAQ user from editing the SQL code, but still allow the rest of us to share our BAQ code on GitHub in a way that is actually useful to others.

I understand but why limit it to just BAQs? I completely agree that source control is the right way to go but I’d like to be able to do so with all of my customizations:

  • BAQs
  • BAQReports
  • BaseExtensions
  • BPM Directives
  • Customizations
  • Dashboards
  • ExtenstionSets
  • IPForms (BPM Form Designer)
  • Localizations
  • Menus
  • Productizations
  • QuickSearchs
  • Reports
  • Report Styles
  • RDDs
  • Security
  • Translations
  • UD Codes
  • UD Maps
  • Verticalizations
  • XXXDefs
  • ZBODefs
  • ZDataSets
  • ZDataTables
1 Like

That sure would be nice to have it all! The reason that I only mention BAQ is that I am in BAQ every single day, as are several people here. The other stuff would be nice but is only used once every few months or less by me (and not at all by others here) and so not nearly as relevant. I probably wouldn’t use this for anything except BAQs.

It’s all already plain text. Everything exported is metadata. Open .baq with something like win-rar some of the stuff it makes sense to package other stuff like a dashboard definition it’s not necessary so it’s straight xml.


same goes for bpms

Figured that out because I refused to believe that a simple widgetized alerting BPM could not be moved between different versions of Epicor. Be warned start messing with version numbers to jam stuff across systems I won’t be liable, really know when you should or shouldn’t attempt that but…

Where there’s a will there’s a way


Joshua, that is awesome! So what is the process to convert it back to a BAQ then? If I edit the .XML then do I just:

  1. zip up all the files
  2. rename the .ZIP to .BAQ
  3. import the .BAQ

Yeah or if you use win-rar you can just open files inside edit them directly and it will repackage them for you. I’m sure there are other archive programs that do that too, i just have been using win-rar so long it’s what i know


An “Un-zipper” program with a built in text editor? That way the “re-zipped” should be the same type and format of the original “zipped” .baq file

Yes, BUT using comparison tools in source control systems like Git are slightly different for XML/JSON than plain source code. Two XML/JSON files may be the “same” in content (no changes in the important stuff like the SQL code) but would be considered different from a straight-up text compare. A good comparison tool is necessary to identify changes between versions or from the vanilla code.

Mark W.

A great use case for this method that I’ve used recently is I wanted to copy a complex epicor dashboard and replace one of the main baqs with a copy of the system baq but with a few more columns added. Normally that would require rebuilding from scratch, but all I did was

  • Copy the system baq to my own
  • Copy the system dashboard to my own
  • Exported my dashboard copy
  • Edited the XML def of my dashboard from the system query ID to my query ID
  • Import it over the top and viola the ol’ bait n’ switch.

It can be hand to make manual edits like that, but remember we always teach the right way first and shortcuts second never shortcuts first! With great power comes great responsibility etc etc.

I mean different is different right? If you exported the same BAQ back to back there would be no change in something like KDiff or Git if you make changes and export again even it it’s not in the phrase builder tabs it’s still different and should be treated as such, no?

Sure, but what if there was a node called “Date Exported” or “CurrentVersion?” Are those customizations different or the same? Functionally, it’s the same code in all ways but only the export method or some environmental characteristic has changed.

I ran into this using XML report comparisons to automate version upgrades. The datetime run makes them not equal right off the bat. ALSO, I have had two reports that were the same besides the dates when comparing the PDF versions by hand but the order of the XML was slightly different. Again, the PDF was the same for all of the totals for each part/group but the XML file was different.

So it depends on the meaning of different… :wink:

1 Like

BTW, all is not lost. Microsoft released a library called XMLDiff that does this (and there are commercial products that intelligently compare XML files) but you would want it to be Git-aware.