Creating a 'client-server' behaviour

I have created a customised dashboard to generate Bartender command/data .btxml files in order to print labels from Epicor. This works fine.
In order for it to work the .btxml file is written to a shared network location that serves as a watch folder for Bartender Integration builder.

As the file is written from the client PC, the logged on user needs write access to the watch folder. I wondered whilst writing the customisation if there was a simple way of using Epicor’s scheduler to get the file generated server side so the user write access isnt needed.

If you write this as an updateable datashboard, the BPM in the Query can write to the server folders.

That is an interesting idea

Are the BO methods accessible from the code, so i could call the method on a button press??

Do you have a well organized Active Directory? I like having AD groups like “EpicorLiveUsers”, “EpicorTestUsers”, etc. which can make folder permissions and things like this a lot simpler. Unless there is some other reason you don’t want the clients to write to that folder, other than maintenance/support.

Oh I like a well-organised everthing in IT!

It’s not a show stopper, but architecturally i would prefer the file generation to occur server side

Architecturally, I would prefer a separation of duties. Epicor should not be formatting files for Bartender! I don’t have Bartender but I swear I’m going to be forced to write a web-service/API that creates Bartender files. This way, all your code is in one place. No business logic in Customizations. You can pass all the parameters in the URL: the template name, the data values, number of copies, even the printer location can be dynamic. Bartender upgrades would require no changes to your Epicor system. No file shares, permissions, SMB vulnerabilities to worry about. Works on-prem and in the cloud. AND you can generate labels on the fly with a simple web form.

But that’s just me. :wink:

To be clear I am not creating layouts within Epicor. They are separate .btw files with variable fields within them. I am creating the .btxml files which contain such information as the template name, printer name and the data i want printed on the label. This is no different than Epicor/SSRS.

The Bartender Integration program reads the file from a drop folder and processes it.

Your point, Mark about the location of business logic is a good one.

The integration program is very flexible and can receive data on a http listener with data formatted in various ways.

Right. This is what the web service would do now. The drop folder would exist on the web server now.

Personally, Epicor/SSRS/BPMs/BAMs should also separate this business logic out. These were built at a time (the 90s) where email was the only tool for notification - well, OK, beepers too. Today, we have things like Collaborate, Teams, Slack, To Do/Lists, custom Mobile apps, so many more effective notification strategies than email. Hopefully Epicor will be also refactoring this out of the core system and into a service.

I started a thread a while back about label printing architecture ideas (I think you commented on it) and got some great ideas that I would love to try. I do like the web service idea a lot, especially because it future proofs if we ever move off prem and into the cloud.

However, major refactoring projects like this are a tough sell to the higher-ups, especially when there’s so much else to do. Usually the best I can do is follow the Boy Scout rule and take baby steps to nix the super egregious things I stumble upon.

I wonder if the web service idea could be created generically enough / with enough functionality to exist as an “add-on product” that customers would buy? Even if it’s not a “real product” you could probably sell code to people in my situation. Let us know if you end up developing the idea further!

No doubt! The reason I bring this up is the goal of Epicor has been to reduce it codebase across all their product lines. (See the Chicklet Chart below). A Notification service - which would include email, etc., a logging service, a printing service, etc. would run across all Epicor product lines and work on-prem and in the cloud. Why build the same functionality for each of the remaining products when you can write it once and use it for all? It makes support easier too since the group responsible for any of those services could support all product lines.