@ian-morris
Forum Replies Created
-
AuthorReplies
-
Got it. Thanks! Rob Abbott wrote:Announcement here – https://usspvlclovertch2.infor.com/viewtopic.php?t=7527
I attempted to find some more detailed fix information on Xtreme but failed to find anything specific.
Rob, can you share fix information (beyond new features) included in this latest release?
Thanks, Charlie!
set klst [msgmetaget $mh DRIVERCTL] was exactly what I needed. However, I had to do some additional massaging to get purely the file name.In my case the inbound file is one folder down from my PWD.
Is there a way to pull the FILENAME based on a key rather than performing string manipulation to get down to it?
Code:
set fn [msgmetaget $mh DRIVERCTL]
set filename [split $fn “/”]
echo filename: [regsub -all {}} [lindex $filename 1] {} filename]
echo filename: $filenameCharlie Bursell wrote:You do not need to define Directory Parse/Delete routines to get file name if Fileset/Local
Unless changed the message metadata will always contain it
I posted this before:
set klst [msgmetaget $mh DRIVERCTL]
Or, if in Xlate
set klst [xpmmetaget $xlateID DRIVERCTL]
# Always set a default
set filepath “”; keylget klst FILENAME filepath
filepath will contain full path.
Yves Guerin wrote:Dear,
to send file to ftp server I used tclCurl (bundle in cloverleaf) from my tcl script, works great and more easy than using expect.
Regards,
Yves
Interesting! Did you use it for
SFTP, though?I also have a need to transmit files to vendors via SFTP. I’d like to employ the script max first posted in this thread. However, I’m unclear on which thread configuration to use and exactly where to place this proc.
Max or Robert, Did you create a single thread and specify the .tcl on the “Inbound – TPS Inbound Data” field in order to create your interface?
That’s exactly what I needed to do. Thank you! Seems like no matter which do-not-use-recovery-database options I choose on the thread or the proc the messages go to a state 10? Any way around this?
I considered clearing the recovery database on thread startup but I can’t get that going either.
👿
As a matter of fact, I just realized something else.
Every time I restart this pass through thread, all of the STATE 10 messages in the recovery database get resent!!!
!HELP! 😯
I just realized that my recovery database is getting cluttered with these messages that I am OVER-ing. They are ending up in a state 10 even though they are getting to their destination. I can’t say I’m completely suprised by this because my notes from training do say “Over -> Puts message in state 10”.
Is there a way to have the “Pass Through” messages just pass through without ending up in a state 10 in the recovery DB? I know they are ultimately getting to their destination. I suppose I could remove the USERECOVERDB option from my OVER command, but I don’t know if that’s a good idea.
Here’s my current OVER command:
set overmh [msgcreate -meta {USERECOVERDB true} [msgget $mh]]
Just wanted to say that this post made my day. I was able to create a pass-through thread using your snippet, which is what I’ve been working on all afternoon. Thanks so much.
Robert Kersemakers wrote:We used to do this all the time: from thread 1 the messages were translated into a ‘known’ HL7 variant into thread 2. And from thread 2 these HL7 messages were further translated into different formats for the different target-systems (threads 3, 4 and 5). And all this in one process.
You need to OVER the message in thread 2. Include a tcl-proc in the TPS outbound in thread 2, that contains the following code:
We’d like a webex too!
That’s very helpful. Thank you!
Thank you for all of the ideas and tips. I’m going to think this one over.
Jim Beall wrote:I need to check PR1.18 and if it’s one of five values do the same thing.
That is helpful. Thank you for the proc.
-
AuthorReplies
