@jmcrussellfirsthealth-org
Forum Replies Created
-
Jeff, I simplified Paul’s script a bit, and it does what you’re looking for. You still have to rename the file for it to work properly. The files I use simply get named with ‘<filename>.processed’ in the same directory they were stored. I’m going to do something more akin to what Paul did on the FTPs, but this I’m using for local files.
The main issue I found with his is an errant return that didn’t return the disposition list which I believe is why you’re getting repeated files. Make sure the “return {}” is removed so it can finish processing the file properly.
# Get message handle
keylget args MSGID mh# Check for correct context
keylget args CONTEXT ctxif {$ctx != “fileset_ibdel”} {
echo “\nERROR proc used in wrong context”
echo “Context should be fileset_ibdel”
echo “Proc called in: $ctx\n”
return {CONTINUE $mh}
}# In this context the message handed to this proc
# by the driver in not a data message. Rather
# it is a list of file names from the directory
# the fileset driver is configured to read.
#
# The list of files to process is accessed
# in the same way data messages in other contexts
# are accessed.
#
# The list is manipulated and returned
#
# The fileset driver now processes the files in
# order they appear in the returned message list.set msg_list [msgget $mh]
set ofileid [open file_process.log a]
echo “Inbound File: $msg_list”
#set destination_file $arg_dest_dir
set destination_file $msg_list.processed
#echo “ofile: $msg_list.processed”file rename -force $msg_list $destination_file
# Put modified list in the message handle
msgset $mh $msg_listlappend dispList “CONTINUE $mh”
Dear Cloverleaf, please let me edit my message over and over to cover for my mistakes:
I think my edit is answered by the comments, but it is still unclear to me why you would have: return “{CONTINUE $mh}” in the error but a blank return at the end of the command. That return near the end would stop the command before the displist return is processed.
I love it when I come in and someone asked the same question I was about to.
First off, thank you for the answers above. I’m probably going to grab Paul’s code and modify a bit.
However, is there a ‘default’ tps that is used, or is file deletion simply written into the engine itself?
edit: Also, I’m not seeing the return of a dispList in some form, are these not necessary? I see it in Paul’s code for the error (IE: Nothing happens), but not after everything gets moved.
I made a mistake. The msgcopy should be inside the loop. msgcopy will give you a new message handle for each message while maintaining the original metadata. To make it better, if he original message was large, after getting the data from the original message handle you could do something “msgset $mh “. That way you are not copying the data with each msgcopy, only the metadata. Note the original message handle is killed since it contains nothing needed after the loop. I hope this makes sense.
A lot of this nuance is what I’m trying to figure out. I’m assuming my statement prior about different message handles being passed in is correct. msgset puts data into the current message ID, so I don’t think I want that, I think msgcopy will be fine (since the original message is a small ADT), then I can replace the message itself. The script would be more like:
set fileList [lsort [glob /folder/ORU_R01_*.HOLD]]
foreach fileName $fileList {
set newmh [msgcopy $mh]
set fh [open $fileName r]
set newmsg [read $fh]
close $fh
set newmh $newmsg
lappend dispList “CONTINUE $newmh”
}I would do msgcreate, but I do want to keep the intial metadata (where it came from, etc). I believe this is ultimately what I’m looking for.
