Printing via FTP

Home Page Forums BizTalk 2004 – BizTalk 2010 Printing via FTP

Viewing 1 reply thread
  • Author
    Posts
    • #22448

      Ok – so I have an issue that is about to get the best of me….

      Some quick information –

      We have an ERP system (Microsoft Dynamics AX) that we print labels from.  These labels go from AX to BizTalk – then to the printer via FTP (BizTalk FTP and FTP server on Zebra label printer)  The FTP server can only accept one connection at a time – this cannot be changed.  About twice a day, this gets hung and restarting the host instances will resolve the issue. 

      The send port for this has a retry interval of 0 (which should make it retry instantly…i think).  What we have is the XML files get sent from AX to a receive folder.  BizTalk takes these labels from the receive folder and moves them to a send folder.  Once in the send folder Biztalk sends the file to the printer and to an Archive folder.

      Does anyone do anything similar with printing?  Does anyone use the BizTalk FTP adapter to send files to printers?  Do the FTP servers on your printers allow more than one simultaneous FTP connection?  How do you do it?  I’m trying to figure out what makes this break.  Sometimes it works, sometimes it doesn’t and so far I have only a few ideas.

      Can BizTalk handle multiple FTP requests at the same time?  We have a couple of applications that use the FTP adapter.  If one of those applications is using FTP when someone tries to print via this FTP method described above, do you think that might cause an issue?  Any suggestions would be most appreciated.

       

      Thanks,

       

      Zach

    • #22473

      Zach,

      First impressions suggests that this is an issue with the FTP server running on your printer (which is a novel idea – something I’ve never come across before!).

      One way to determine whether the problem is with BizTalk or your printer’s FTP server is to create another send port that FTP’s the message going to the printer to a different FTP server (say the in-build IIS FTP server). Alternatively, write a simple C# app to hit your printer’s FTP server with several connections at the same time and see what happens.

      Let me know how you get on.

      Rgds, Nick.

      • #22508

        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?

         

         

        • #22509

          When you queue 20 print requests to a single printer, Biztalk will initiate 20 send port instances which will each attempt to send. The first one will succeed the rest will fail. Each failed port will retry immediately up to 90 times before suspending the message. This is like a machinegun approach to message delivery.  Although in your case you have a backup transport which will attempt to send the message but only retry 3 times.

          My first suggestion is to set Ordered Delivery on the send port (Advanced options). This will result in a single send port instance sending all the messages (one ftp connection – no errors). I would also set a retry interval to greater than zero. Also probably remove the backup transport – if it doesn’t work the first 90 times having 3 last attempts probably won’t work.

          • #22512

            Thank you for the reply.  I made the suggested changes.  I have also set up a temporary scheduled task to restart the host instances every morning at 3:45 AM.  I will pause this.  I’d rather not use it anyways because it’s not a permanent solution – but it does keep me from getting called in the AM most of the time.

            I’ll keep you posted on the results.

            • #22514

              The user called and said printing was a bit laggy after making the changes.  This is probably because of the retry interval.  Normally everything prints right away.  So here are my thoughts on the cause of this recent delay.   **Please let me know if ordered delivery resolves my hypothesis or not**

              The FTP server can have only 1 simultaneous connection.  So, if the user sends (this sending is done through a batch process, so multiple label requests exists simultaneously) ..sends print jobs through the batch process, does BizTalk send one file of all the print jobs to the printer, or does each different print job in the batch process exists as a file?   If BizTalk sends multiple files, then the first will fail and then the next will now wait 1 minute before retrying. 

              What is causing this is the FTP server will disconnect the connection after 5 seconds of being IDLE.  I changed this to 5 seconds – the default was 5 minutes.  So that tells me BizTalk does not disconnect from the FTP after each print request.  So, to resolve the user’s problem (at least as far as i know) i’ll have to either change the retry interval back to 0 OR, make BizTalk disconnect from the FTP server after it sends through a print job.   So, would that mean I need to edit the SEND port and click ‘Configure’ on the FTP portion and insert a command on the ‘AFTER PUT’ field?  I assume if that is the case I would insert the command of ‘quit’ or ‘bye’.  Would that make BizTalk disconnect from the FTP server after each print attempt?

               

              Thanks for the help.

              Zach

              • #22515

                Now, the send port instance is doing something different.  It stays active for a while.  I was on the phone with the guy while he was printing – he ran a batch through and they printed and he quit printing, however the send port instance in the BizTalk Query Analyzer stayed in the ACTIVE state.  Do you have any ideas as to why this would happen?  Is it not a big deal?

                Zach

Viewing 1 reply thread
  • The forum ‘BizTalk 2004 – BizTalk 2010’ is closed to new topics and replies.