Prev
Next
Forums Integration / Customization IPA/ProcessFlow

IPA locks text file if process errors out

 2 Replies
 0 Subscribed to this topic
 52 Subscribed to this forum
Sort:
Author
Messages
mikeP
Veteran Member
Posts: 151
Veteran Member
8/26/2015 6:56 PM

    I have a process that uses a FTP node to transfer a CSV file from a remote server to a share on the LSF server, then uses a Data Iterator to read the CSV, construct, then execute a SQL Update command.  It's been working fine, then I had to spoil it by testing my error handling. 

    I induced an error by putting invalid syntax in the SQL command. The error handler works as expected, but when the process completes, the Lawson user still has the CSV locked.  The next run, the FTP node bombs because the file's in use.  I added a SysCommand node with a DEL command, but that also bombs because the file's in use.  I can't delete it from the share using Windows Explorer for the same reason. 

    The lock seems to be induced when the process encounters an error. 

    Anybody know how to get IPA to let go of the file?

    If it's something I can do in the error handler, that would be great, but another concern is "log/notify and stop" error, but I haven't had chance to try that yet.

     

    mikeP
    Veteran Member
    Posts: 151
    Veteran Member
    8/27/2015 6:30 PM
      I found a workaround for this.

      If you configure a Data Iterator to read a file directly using input method "File", and the iterator is interrupted by an error before it reads all the records in the file, the input file may be locked; held open by the java runtime. In testing, this happened when an error was trapped by an error hander and control went to a node in the process that is outside the iterator loop. I did not test what happens if you stop the process when an error occurs.

      When the file is locked, subsequent runs of the process won't be able to access it, e.g., FTP a new version of the file into place or delete it; nor can it be deleted manually via Windows Explorer using a file share. This happens when running on the IPA server or on the PC in IPD.

      A workaround is to configure the iterator input method to "Data", read the file using a File Access node, then feed that node's output data into the iterator. Presumably this works because the File Access node reads the entire file without interruption.

      Another option would be to set an error flag when the error occurs, handle the error, then linking the last node of the error handler to the iterator's end node. Then, first thing in the iterator loop, test the error code and branch directly to the end node if it was set. This would allow the iterator to complete, and presumably release its input file. That might result in many needless iterations if the error occurred early in a large file.
      John Henley
      Posts: 3353
      8/31/2015 11:27 AM
        With IPA (and particularly when IPA is on separate server from LSF), using the fileaccess node to read the file first into memory and then using the DataIterator against the data instead of the file will become a necessity. One pattern that I've noticed with the move to v10 IPA is that customers who used to have LSF / PF on the same server now have IPA on a separate server and when they use the FileAccess nodes to write from within an iterator loop that means a network round-trip for every read or write...

        Thanks for using the LawsonGuru.com forums!
        John