Integration dilemma フォローする

0
Avatar
Thomas Winstead

I hope somebody here can help me.

I have created integrations where a file of a certain name is dropped in a monitored folder that has the data that the bartender document needs to have populated to print. Fairly simple.

Here's another integration I need to figure out, and it's kind of the opposite:

I'd have some static labels (everything is screen data) of different file names depending on the item it has on it. I'd like to drop a csv file into a bartender monitored folder that's the same name all the time, say static.dat, that doesn't contain any data for the label but contains the document to print and how many of them to print.

for example, a static.dat may have just this:  date-code-m-molding.btw,12 that represents the document and the qty to print (12)

I'd like to convert the file name into a variable, and the qty to print to a variable, then use those 2 variables to populate the document field and the print option override 'copies'

It will then delete that file wait for another file of the same name, reads the contents, and prints another document  and another value for qty to print and then deletes that one, on and on as long as the integration is running.

If anybody has any idea about how I can do that, it would be most appreciated

 

 

 

 

6 コメント

0
Avatar
Gene Henson
モデレータ 正式なコメント
コメントアクション Permalink

Hi Thomas,

Here's one approach you could take:

You can setup your integration to treat the text file as a database, and then execute a series of actions for each record in the database (even if there's only one record). When you do this, Integration Builder will read each line from your database and store each field value in it's own variable. You can then use those variables in a subsequent Print Document action to set the .btw file and number of copies.

So your integration might have the following Actions:

  • "Transform Text To Record Set" - this is what converts your text document into a database and lets you define the delimitation.
  • "For Each Database Record" - this is what reads the Record Set created above and stores each field in a variable
  • Print Document - this is what prints the document

One thing to note, if you don't have a header row in the your database, Integration Builder stores the field values in variables like "Field1", "Field2", etc.

Hopefully that makes sense and gets you on the right path.

0
Avatar
Thomas Winstead
コメントアクション Permalink

Thanks for the suggestion. I will look into it first thing tomorrow!

This is still part of a file integration, right?

0
Avatar
Gene Henson
モデレータ
コメントアクション Permalink

Yep, it's still part of a file integration. Hope it all works out for you.

0
Avatar
Peter Thane
コメントアクション Permalink

Gene responded before I had a chance, but you may want to checkout this video of a training seminar that Seagull run a while back (was with 2019) but it goes through the process of how you can make the label format name dynamic with the data coming from a trigger file

 

https://support.seagullscientific.com/hc/en-us/articles/115004072388-Building-a-file-integration-using-a-CSV-file-38-26-

0
Avatar
Thomas Winstead
コメントアクション Permalink

I've got it set up the way I think it should, but when I test the integration and static.dat gets dropped in the watch folder, I get an error that says:

Unable to run action 'Transform Text To Record Set'. Details: The file 'C:\home-date-motors\static.dat' could not be opened, read, or accessed. Verify that the path is correct, exists, and has the correct permissions.

Details: Could not find file 'C:\home-date-motors\static.dat'.

and the static.dat is renamed to static.failed

Which I think means means that my file integration knows the file was dropped, and renamed it static.failed before the transform text to record set has a chance to process it. This is confusing 

 

 

0
Avatar
Peter Thane
コメントアクション Permalink

Here are a couple of screenshots from a test system I setup some time ago (in 2016)

Transforms to Record Set screen above

and part of the Print Document screen above (note how the Print Document command is an action run under the main For Each Database Record. Field 10 of the trigger file contains the name of the label format but without the .BTW and so I had to add this on after the %Field10% variable, but if you trigger file includes the .BTW then you wont need this 

 

 

ログインしてコメントを残してください。