Is there a limit on number of integration files that are deployed?
At the moment we are using roughly 35 seperate integration files. Each integration is using a static printer, static .btw file, and a unique directory name to watch for csv files.
I would like to merge all these integrations into a single dynamic integration, where the csv file contains the printer name and btw file to use. In my opinion this will free up system resources and bartender could run more smoothly overall. It would also simplify adding additional label formats and new printers. I would even like to take it further and move to a web service opposed to csv.
My boss disagrees as he is afraid of merging everything into a single failure domain. If you lose that 1 integration then you lose all printers. He would rather keep it this way so that if one printer/label integration fails that 1 printer is affected and users can use a different printer. I see his point but I also feel using this many integrations is the cause of the random performance issues he is afraid of. Also wants to keep the csv in play as an easy way to confirm the integration is running correctly at any given time.
I am not sure if there is a maximum number but each integration that is active will take a certain amount of system resources to run and so making it one file would certainly free up those and improve performance, I would suggest.
Prior to the release of 2019 setting the printer name and label field was accomplished by including a series of BarTender commands in the the trigger file, such as /AF=LabelFormatName.BTW and /PRN=ThePrinterName for the label and printer, all in %BTW% and %END% "brackets". After these command lines then the trigger file would include the data line(s). These were known as Commander Script file triggers.
With the updated and more powerful Integration these and other variables can now be included in the data element of the file itself without the need for the brackets and as you say makes the whole system more dynamic. The trigger files would need to be saved to one location for an integration to locate the,, although it can be set to scan child folders of this location.0
Peter Thane, if the csv trigger files are organized into a separate folder for each printer and automatically placed in the specific folder by the ERP system, is it possible to have the integration scan a parent folder, and then specify the desired printer based on the child folder the file is discovered in, without using the Print Command Script? I thought maybe Custom variables might work for this but that feature is poorly documented so I haven't been able to figure out how to use it yet.0
If you are scanning a different folder for each task then you could create a separate integration for each and hard code the printer name into integration builder commands0
That is how we currently handle our integrations. Each label gets it's own .btin file, and each printer gets its own integration within that, scanning it's specific folder on the network and printing to the associated printer. However, it seems that more system resources would be consumed by running that many integrations all the time, especially when they are so similar.
Not sure if it's more efficient to have one integration scan a few dozen child folders or have about 4 nearly identical integrations all scanning a single folder. I was hoping to do this without changing my ERP output trigger files to include the printer name in Printer Code.
I know that there's currently a variable called "DetectedFileFolder". I'd need some way of transforming variable text or mapping that name to a printer name, or efficiently using Select Case. Just not sure how to go about it0
Couldn't you add the label format name and the printer into the data/trigger file and set those up as variables?
So for the printer shown in the image above instead of the printer name you would have something like %field12% for example if the printer name were output in field 12 of your file. That would mean you only need 1 integration to run0
Peter that is the solution I like best, it just puts everything in one failure domain. There is a fear that if the single integration fails then all labels fail opposed to just 1 label/printer0