Currently, we are still using a file drop system for Bartender via FTP.
I have already built a solution using the Bartender REST API, to be called from Epicor to my plant.
Epicor → Custom C# Minimal Api (Mine) → Bartender
It works well in testing, but we haven’t moved it into production.
Well today, I was tasked to move up the priority on moving it over, after having
ongoing problems with the FTP solution.
Putting it in place is not real difficult, just gotta do it.
But now, I’m having second thoughts, and I wanted your input.
Here’s where I am now:
We are definitely moving from the file drop solution.
We will be using the Bartender REST endpoint for printing, no folder monitoring.
My options now are:
A: Go with the solution I’ve already made, which is an Epicor Function, that calls my API,
(Bartender REST is not secure), which calls Bartender for printing.
or
B: Create a polling solution on the Bartender server, that polls Epicor, via REST, and a UDTable,
and that will call Bartender via REST.
What say you? I can see advantages and disadvantages to both.
I went with Option A. There isn’t anything being sent over the network that isn’t going to be printed on a label for everyone to see anyway. Note: security is not my specialty. Take that as you will.
I like your queuing idea of solution B, but I also like the event driven concept (and the security) of solution A. So, maybe something like write the file to the UD table with a status, submitted, and printed times. Upon new or udpated record, call your function. When complete, update the status and print time. This would then allow you to reprint easily and monitor failures.
I’d lean A, one as it’s already done/mostly-done. I’d be interested in seeing your solution whichever you do as we’re looking to move off the file-drop solution too.
Ditto @Randy. While I’ve got a solution for Receipts already running, we’re expanding it to job receipts and shipping out and I’m reworking the existing implementation to be more generic and also moving it from BPM into functions. The latter wasn’t available on the E10 version I developed it on.
If it’s only ever going to talk to Epicor, seems pretty easy to whitelist that and block everything else. Though, again, I don’t deal with security, so I could be talking out of my ass.
Let’s see, my minimal API is HTTPS, has a real Cert, has an API Key, restricted by IP,
and only shows swagger page to internal IPs, and I can turn it off.
All good stuff. You might also add authentication and authorization to explicitly control access to the API with all the goodness that an OAuth provider could give you. While label printing is not super critical, it could stop a prankster from printing rolls of all over the shop floor over the weekend…
Sorry, I was referring to Azure AD so you could use the user’s Epicor credentials (if also using Azure AD) to pass along to your API. I’m not as familiar with Epicor’s Identity provider to know if one can do the same. @olga may shine some light on that though.
Yes, a label printer service may not need that level of security but you will eventually build an API that does.
Can I know the premise on this decision? why you want to move away? We are curently using that way for our printing of labels, and have (well so far) no intentions of changing… We need to upgrade to a more recent labeling system (either Bartender or NiceLabel (which we currently use but very old version)) .
We currently manage our printing of labels via a .Net app which shows , given a job number, all the labels generated, with printed date, then scan date etc… When we print the selection of labels, a file is saved at a specific drive location and gets picked up to print.
Works very well…
so that is why I just wanted to know why you guys want to move away from it…
It may change my view on our current way…
on other forums too. 
