Thanks for the reply. I will try that, however I have my doubts about the FTP server on the printer being the issue – here are my thoughts on that.
Like clockwork, I have to restart the host instances every morning at 4AM. We have a couple of facilities that use the printing method described in my original post. One of the warehouses starts at 5AM EST and we’re on CST, so when they start at 4AM CST, I need to restart the host instances. Once this is done, 99% of the time, the printing will be successful until the next morning at 4AM.
We have our ERP system put the Zebra label files in a Receive folder. Then Biztalk picks them up from this folder, they run through the orchestration and format them into an XML file and send that product to a Send folder. We have send ports for each printer that constanty query that folder looking for an XML file with ‘PRINTERNAME=”myprinter” in the file. Each send port has a filter for their printer name of course.
Now – I don’t think it is the printer. The printers FTP server can only have one simultaneous FTP connection. So, when 20 label files go through basically instantaneously, one prints, 19 fail. Then 1 prints and 18 fail. So on down until they all print. This process is rather quick because each file is about 9KB and prints rather quickly. From the user’s perspective, the printer is going non stop until all labels are printed. There is no wait time. When the problem occurs, the RECEIVE folder gets backed up, meaning that the orchestration has not picked up the file to format it. If the printer FTP was an issue, i’d expect the SEND folder to be full. Also, i can open a dos prompt and ‘ftp open ip’ to the printer and get connected – meaning the FTP connecdtion is not in use. Also, If i am logged into the FTP on the printer, consuming the only active FTP connection to that printer, BizTalk throws errors when printing saying connection refused. I do not get these errors at 4AM.
Unfortunately, I do not see any errors indicating the printing is failing. I find out be either getting a phone call, or checking the RECEIVE folder and it has files in it. The files should go from that folder instantaneously. With that said, there are errors in the application log. For example, we’ll get a
rror: 1 (Field level error)
SegmentID: BIG
Position in TS: 1
Data Element ID: BIG04
Position in Segment: 4
Data Value:
6: Invalid character in data element
or a
A message sent to adapter “FILE” on send port “sprt.DynamicsAX.EDI.Outbound.vendor_name.Parts” with URI “\\server\edi$\4.Outbound\%MessageID%.edi” is suspended.
Error details: Unable to read the stream produced by the pipeline.
Details: Error in serialization
MessageId: {13506294-409B-4393-8BDF-238ADE858F74}
InstanceID: {FC45A184-FAA9-4F44-81BB-6D64CC4127E3}
Could those errors cause the printing to fail? I don’t see why. So assuming that is not the problem and since there are no errors in the application log about printing, that leads me to believe perhaps we have unknowingly set this up to do this on purpose. IE – after X minutes of being idle, BizTalk thinks it is done until the host instances are reset.
Let me explain – in the properties of one of the send ports for one of the printers, we have the FTP adapter used with the appropriate information using the XML Transmit Pipeline. On the ‘Transport Advanced Options’ and the ‘BackupTransport’ tabs, there are places for service windows and retry intervals and retry counts. What is the difference between these two? For transport options, we have retry count at 90, retry interval at 0 and priority at 2. On the backup transport tab, we have ‘Type’ as none – retry count at 3 and retry interval at 5. Neither have a service window. I’m not exactly sure what is going to retry 90 times and what will retry 3 times, from the previous example.
Then of course the receive locations have retry properties as well. For ‘Network Failure’ on the receive location for the RECEIVE folder, we have ‘Retry Count’ at 90 and ‘Retry Interval’ at 0. For the advanced settings we have polling interval at 5000ms (5 sec) for ‘Removing of old files’ we have the ‘Retry Count’ at 5, the retry interval at 5000ms and the maximum retry interval at 300,000 ms ( 5 min). So once again, im not sure what will retry 90 times, and what will retry when…
Do you think it is possible the printing is failing because of being incorrectly setup with the retries and etc as described above?