Forum Replies Created
-
AuthorReplies
-
Clovertech – I’d like to see the email problem fixed. I only get a small percentage of the postings in my inbox.
😕
Jim, I have not tried it but from what I’ve read on other threads… SFTP is NOT supported in Cloverleaf and no one has yet been able to make it work in TCL/TclCurl. So you will probably have to do something outside the engine to send the files.
Scott
July 25, 2008 at 11:58 am in reply to: We are currently having issues with forum email notification #65174I am still not getting the email digests regularly. I got one last night – the first I’ve gotten in a week. Scott
I agree with Max – although I also have never tested it to find out for sure. 🙄 My feeling is, if they process in about the same time, then the syntax I should use should be, to the human eye, the most easily readable at a glance. For me that means I write them like this…
Code:ADT_A(01|02|03|04|06|08)
IMO, It’s easy to read and understand even for someone relatively new to regular expressions.
But I know, that doesn’t answer the question… Anyone know for sure? I am curious too.
Is there still a problem with the digest emails? I am set up to get them hourly and I have only gotten a few this month. From the activity recently I see there should be several just from today but I have received none. Is this on the Health Vision side or on ours? Thanks!
Scott
Courtney, Another option, perhaps the easiest to implement, is to put each message into it’s own batch. Every message coming in gets a header and footer attached to it and sent on to the recieving system. Every batch sent would have only one message.
Scott
I had a similar requirement for an outbound thread that the recieving system could not handle the volume of messages the sending system was supplying. I added a ‘sleep’ command to a tclproc in the SEND OK UPOC. A couple caveats – Be careful you are not tying up the process manager if there are other threads in the process. Also be careful you will not have too many messages queueing up in the engine.
Here is the proc…
Code:######################################################################
# Name: tps_msg_throttle
# Programmer: Scott R. Lee
# Purpose: Slow down messages going out to EDM. Charges from Affinity
# can be sent too quickly for EDM to handle them and
# other messages (mainly ADTs) get queued up behind them.
#
# Edits: 6/4/07 – Scott R. Lee
# Changed sleep time from 1 second to .5 seconds.
# 6/6/07 – Scott R. Lee
# Changed sleep time back to 1 second.
#
# UPoC type: tps
# Args: tps keyedlist containing the following keys:
# MODE run mode (”start”, “run” or “time”)
# MSGID message handle
# ARGS user-supplied arguments:
#
#
# Returns: tps disposition list:
#
#proc tps_msg_throttle { args } {
keylget args MODE mode ;# Fetch modeset dispList {} ;# Nothing to return
switch -exact — $mode {
start {
# Perform special init functions
# N.B.: there may or may not be a MSGID key in args
}run {
# ‘run’ mode always has a MSGID; fetch and process it
keylget args MSGID mh
echo sleeping 1
sleep 1
lappend dispList “CONTINUE $mh”
}time {
# Timer-based processing
# N.B.: there may or may not be a MSGID key in args
}
shutdown {
# Doing some clean-up work
}
}return $dispList
}
HTH
Scott
1) 91 threads in 17 processes in 3 sites. 2) One analyst, full time, Level two certified. I also am the Unix Administrator and backup support for a few other applications.
3) Not adequate. We should have two Analysts >75% dedicated to interfaces.
You could set it up as a pre or post proc to the Xlate. To call it from the Xlate though it has to be an xltp proc. I think I found a bug in your code… Note to self – Next time test it on someone else’s car!Sorry, you lost me…. email about what? Exchanging with whom? If you do a ‘showroot’ you will see which site is the current site that the hci commands will be working on. The current folder you are in does not tell hcienginestop which site to act upon. If that doesn’t help, maybe you could post the whole script?
Scott
Are you doing a setsite before that? Great idea Charlie… Code:hcitcl>set regexp {ADT_A[10,12]}
ADT_A[10,12]hcitcl>for {set i 1} {$i < 40} {incr i} { set ADT ADT_A[format %02d $i] if {![regexp -- $regexp $ADT]} {echo $ADT FAILED} } ADT_A30 FAILED ADT_A31 FAILED ADT_A32 FAILED ADT_A33 FAILED ADT_A34 FAILED ADT_A35 FAILED ADT_A36 FAILED ADT_A37 FAILED ADT_A38 FAILED ADT_A39 FAILED hcitcl>
It may not be the only problem, but it’s definitely a problem.
😀 I see now the square brackets with the commas so that probably works. I’ve always used the parens and pipes so that caught my eye. If some messages are going, some are not, then I might look more closely at the translations? What are you doing in the xlates? I see the 17s and 34s are raw… is there a TCL proc there?
Can you show us the metadata for one of these messages in the error database?
Are these going to a real destination or are they routed back into the engine?
-
AuthorReplies