Authentication for Bartender REST

Kinetic ERP
,
1

I am trying to convert away from file-drop Bartender Integration to the REST API in Bartender 2022. But it looks like the only authentication supported is Windows Authentication and then there is this statement in the Bartender REST Documentation:

  • User sending the request must have permission to log into the server
  • User must have permissions to administer integrations as set in the Administration Console

So for my many production users that want to print pallet labels through bartender I have to give them Admin rights to Bartender and allow Sign-on to that server?? I can turn on Basic Authentication, but then I have to ask them for their Username and Password continuously. For Epicor REST I am using Application accounts, has anyone built a REST integration with Bartender and not done Windows authentication for the requests? (BTW needs to be on-prem Bartender, seems Cloud Bartender does support OAuth authentication but on prem does not).

2

I built a Bartender REST integration. It’s really a one-way process. BPM/Function fires off a call to BT and that’s it. I don’t even do anything with the response. I simply didn’t use any authentication on the Bartender side. Wasn’t worth it. We’re entirely on-prem, and have fairly ridiculous networking security (not my area, so I won’t comment) so it’s not like our little Zebra printers are completely unsecured.

2 Likes
3

I complained to Seagull last year about this.

You could use basic auth and use a secret manager to get the creds. To be more secure, proxy the BT REST call in an API and insert the username/password there.

3 Likes
4

I commented on that mark on their site.

1 Like
5

Thank you, I decided to go ahead and use a local user account to that machine and have all my code use that user account. I know it isn’t greatly secured, but that user is locked down to that machine and only Bartender usages, soooo, meh. Dumb but workable.

6

That’s what I did. I haven’t deployed my REST integration yet, but it works.

7

I thought about switching to Rest from the old commander files, but then really couldn’t justify the effort with my custom code to do it. What tipped the scales for you? I really don’t mind the flat files for troubleshooting and label creation.

The only reason I looked at it (and TCP/IP or WebSocket printing) was for super quick printing at the production line, but BarTender image rendering was still too slow compared to straight up ZPL

2 Likes
8

I haven’t fully moved yet, still in testing. Having problems printing multiple labels in 1 REST call still, opened a support case with Bartender. Anyway, the main reason is Printer failures. With the Flat file if Bartender fails to print for any reason the user is never informed, so they run the transaction again, and again. Then we have to undo all those transactions later. With REST I can send the request and give it a few seconds and check the status, if it failed to print I can inform the user right away to use a different printer or inform IT.

2 Likes
9

I, too, like having something for troubleshooting and was thinking of logging the request at the API.

2 Likes
10

The bartender admin console is pretty decent at logging the integration calls, at least for the rest integrations.

11

Interesting. We rarely have failures, so I never really considered it.

1 Like
12

We don’t often have failures either, but when it does occur it generally causes enough problems that I get complaints. We also shove a LOT of labels through bartender, 1,000s per day especially during 3rd and 4th quarter.

2 Likes
13

So when you guys use Bartender’s REST API, does your input come from custom code? What if you want to use Epicor printing framework, and want the data that normally is inside the commander files? Wouldn’t you still need to read those files, or is there some other way to get to that data without completely rebuilding it from scratch?

14

All of my Bartender data is coming from custom code, so not using Epicor’s printing framework. Though due to what I see as limitations of the Bartender REST implementation, I had to design some of my label printing in Bartender to still use some form of File-Drop method.

I am using REST to initiate the print and get communications back to the calling app regarding warnings and errors, while telling Bartender in the REST call to use a specified Database File unique to that print job. The benefit I see of this change from the older file-drop method is the new file I am creating is only the CSV, it no longer has any header commands for things like Template and printer, it can be just a raw csv (or other Bartender supported database file). So you may be able to use that method have bartender refer to Epicor created data files.

1 Like