@jmcrussellfirsthealth-org
Forum Replies Created
-
So after a bit of back-and-forth with support, it seems on-premises customers are not given access to the “Release Center” even though all their documentation points to the Release Center without mentioning on-prem’s lack of access. Here are the necessary KB articles you’re expected to know and subscribe to for updates.
KB2287007 – The announcement. No KB articles linked, instructions are for non-on-premises customers (Cloud? Only Infor hosted? They weren’t clear): (https://customerportal.infor.com/csmcore?id=kb_article_view&sysparm_article=KB2287007)</p>
KB2293813 – Release Report. This is the report that has the enhancements and bug fixes listed. https://customerportal.infor.com/csmcore?id=kb_article_view&sys_kb_id=f2471229c35f52900d906cbeb0013189</p>
KB2282305 – Technical Compatibility Overview – The actual server compatibility listing. https://customerportal.infor.com/csmcore?id=kb_article_view&sysparm_article=KB2282305</p>
If you want updates you need to subscribe to those KB articles or at least have them handy to get any release information.Naturally, to access this you will need to have an active Infor Concierge account with your facility.
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.
