- This topic has 10 replies, 4 voices, and was last updated 18 years, 11 months ago by
.
-
Topic
-
hi all, I also got this from the Error db: Unsupported Trxid (101) on a Ack msg. I do NOT Route any Reply, how come I still get this error???
Thanks! 8)
msg: 0x3000003c
msgType : DATA
msgClass : ENGINE
msgState : Unsupported Trxid (101)
msgPriority : 5120
msgRecoveryDbState: 3
msgFlags : 0x8002
msgMid : [0.0.7668993]
msgSrcMid : midNULL
msgSrcMidGroup : midNULL
msgOrigSrcThread : to_star_rx
msgOrigDestThread :
msgSrcThread : to_star_rx
msgDestThread :
msgXlateThread :
msgSkipXlate : 0
msgSepChars :
msgNumRetries : 0
msgGroupId : 0
msgDriverControl :
msgRecordFormat :
msgRoutes :
msgUserData :
msgStaticIsDirty : 0
msgVariableIsDirty: 0
msgTimeStartIb : 1129751770.492
msgTimeStartOb : 1129751770.184
msgTimeCurQueStart: 0.000
msgTimeTotalQue : 0.002
msgTimeRecovery : 1129751770.497
msgEoConfig : 0x0
msgData (BO) : 0x30000120
message : ‘MSH:;~&:0:H:::200510191554::ACK;ACK;03::P:::x0dMSA:AA::::x0d’
-
Replies
-
-
-
Jim, I did put a check_ack proc below in the “TPS Inbound Reply” under the Outbound tab of the OB thread, and also a sendOK_save proc in the “Send OK Procs”, but leave the “Reply ‘generation'” blank.
Looks like I am handling the ACK msg…
sam
__________________________________________________________
proc check_ack { args } {
keylget args MODE mode ;# Fetch mode
# ob_save is global holding message we sent
# send_cnt is a count of how many resends
global ob_save send_cnt
global HciConnName
if ![info exists HciConnName] { set HciConnName UNKNOWN }
set module “(RESEND_OB_MSG/$HciConnName)”
switch -exact — $mode {
start {
if ![info exists ob_save] { set ob_save “” }
set send_cnt 0 ;# Init counter
return “”
}
run {
keylget args MSGID mh
set my_mh $ob_save
# Null out the global variable
set ob_save “”
set msg [msgget $mh]
set fldsep [csubstr $msg 3 1] ;# Field separator normally “|”
set segments [split $msg r] ;# Get segments
set msaflds [split [lindex $segments 1] $fldsep] ;# MSA fields
set acktype [lindex $msaflds 1] ;# The ack type
set ackmsg [lindex $msaflds 3] ;# Ack message, if any
if [cequal $ackmsg “”] { set ackmsg “NO MESSAGE” }
#
# Look for all possible hl-7 ack types and take appropriate action
#
switch -exact — $acktype {
AA – CA {
# Good ACK – Clean up
set send_cnt 0 ;# Init counter
return “{KILLREPLY $mh} {KILL $my_mh}”
}
AR – CR {
# AR – resend up to 3 times
if {$send_cnt > 3} {
set send_cnt 0
echo “$module : Three consecutive AR responses – $ackmsg”
echo “Message to Error Database”
echo “Reply is:”
echo $msgnn
echo “Message is:”
echo [msgget $my_mh]n
msgmetaset $my_mh USERDATA “Exceeded Application Reject (AR) retrys – $ackmsg”
return “{KILLREPLY $mh} {ERROR $my_mh}”
} else {
incr send_cnt
return “{KILLREPLY $mh} {PROTO $my_mh}”
}
}
AE – CE {
set send_cnt 0
echo “$module : Received AE response”
echo “Message to Error Database”
echo “Reply is:”
echo $msgnn
echo “Message is:”
echo [msgget $my_mh]n
msgmetaset $my_mh USERDATA “Application Error (AE) – $ackmsg”
return “{KILLREPLY $mh} {ERROR $my_mh}”
}
default {
set send_cnt 0
echo “$module : Received Invalid response”
echo “Message to Error Database”
echo “Reply is:”
echo $msgnn
echo “Message is:”
echo [msgget $my_mh]n
msgmetaset $my_mh USERDATA “Invalid response – [msgget $mh]”
return “{KILLREPLY $mh} {ERROR $my_mh}”
}
}
}
default {
error “Unknown mode ‘$mode’ in validate_reply”
}
}
}
-
Have you turned up the EO so that you can observe the flow. The proc you show has echos and so you should be able to detect the activity with the noise level up. In any case, the engine is trying to route what appears to be an ACK so that particular message was not handled.
Please note the message type is DATA not REPLY in the metadata – that may give you a clue.
Jim Kosloskey
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
-
Rentain, I’d want a look at how that connection is configured becuase it’s not really correct to say that you get replies as data messages sometimes. What’s really happening is that the remote system is sending messages that have a format of a reply at a time when your thread isn’t waiting for replies. The engine decides to store a message as type reply if it was waiting for replies. The engine stores a message as type data if it wasn’t waiting for replies.
That means that it won’t do any good to change your check ack procedure because it’s located in inbound replies and the data messages are being processed in inbound data.
So, how could a reply message enter as a data message? If the timeout value for await replies is too short or the remote system is sending unsolicited replies.
-
Greg, You are right, I added this code in check_ack but I am still getting the same err…
switch -exact — $acktype {
AA – CA {
# Good ACK – Clean up
set send_cnt 0 ;# Init counter
#handling inbound Data type reply
if {[cequal [msgmetaget $mh TYPE] DATA]} {
return “{KILL $mh} {KILL $my_mh}”
} else {
return “{KILLREPLY $mh} {KILL $my_mh}”
}
…………
Do you mean the msgType in the metadata is NOT sent together with the msg data, but the engine puts it in???
Thanks! -Sam
🙂
This is my config: (I only put in fields that have value)
*** Properties of Inbound thread ***
Inbound tab:
Inbound Data
TPS Inbound Data: hl7Raw_ack
Trx id determination Format: hl7
EDI Batch: None
Outbound Replies
Retries: -1
Interval: 10
*** Properties of Outbound thread ***
Outbound tab:
Outbound Data
Retries: -1
Interval: 10
Send OK Procs: sendOK_save
EDI Batch: None
Inbound Replies
Await Replies (checked)
Timesout: 15
TPS Inbound Reply: check_ack
Trx id Determination Format: hl7
proc hl7Raw_ack { args } {
global HciConnName
set mode [keylget args MODE]
set context [keylget args CONTEXT]
if { ! [info exists HciConnName] } {
set HciConnName “UNKNOWN_TD”
}
switch -exact — $mode {
start {
return “” ;# Nothing specific
}
run {
set mh [keylget args MSGID] ;# Message header
set msg [msgget $mh] ;# The message
#
# Make sure we are in proper context
#
if {$context != “sms_ib_data”} {
echo “$HciConnName: hl7Raw_ack; wrong context $context”
echo “CONTINUE MESSAGE — NO ACTION TAKEN”
return “{CONTINUE $mh}”
}
#
# Set up defaults
#
set mtype “ACK” ;# Message type
set ack_type “AA” ;# Assume good ack
set send_appl “”
set rx_appl “Cloverleaf”
set send_fac “”
set rx_fac “”
set p_type “P”
set seq_no “”
set rx_ID “”
set version “2.2” ;# assume 2.2
set ack_msg “”
set fldsep “|”
set sepchar “^~\&”
set dttm [fmtclock [getclock] “%Y%m%d%H%M”]
#
# Split the message and get MSH segment
#
set segments [split $msg r]
#
# If valid MSH segment, get data else send NAK
#
set mshseg [lindex $segments 0] ;# MSH segment
set mshname [csubstr $mshseg 0 3] ;# Segment name
if ![cequal $mshname “MSH”] { ;# Invalid MSH
set ack_msg “Invalid MSH segment”
set ack_type “AR”
} else { ;# Valid MSH
set fldsep [csubstr $mshseg 3 1] ;# get field sep char
set mshflds [split $mshseg $fldsep] ;# get MSH fields
set sepchar [lindex $mshflds 1] ;# Sep characters
set send_appl [lindex $mshflds 2] ;# Set send to receive
set rx_appl [lindex $mshflds 4] ;# Set receive to send
set send_fac [lindex $mshflds 5] ;# Set send to receive
set rx_fac [lindex $mshflds 3] ;# Set receive to send
set p_type [lindex $mshflds 10] ;# Set processing type
set rx_ID [lindex $mshflds 9] ;# Message Control ID
set version [lindex $mshflds 11] ;# Version
set seq_no [lindex $mshflds 12] ;# Set sequence number
}
#
# Now build the ACKNOWLEGEMENT message
#
set ACK “MSH$fldsep$sepchar$fldsep$rx_appl$fldsep$send_fac$fldsep”
append ACK “$send_appl$fldsep$rx_fac$fldsep$dttm$fldsep$fldsep$mtype$fldsep”
append ACK “$rx_ID$fldsep$p_type$fldsep$version$fldsep${seq_no}r”
append ACK “MSA$fldsep$ack_type$fldsep$rx_ID$fldsep${ack_msg}r”
set obMsg [msgcreate -type reply]
msgset $obMsg $ACK
#
# Now continue original message and send response
# unless there was an error, then kill original
#
if [cequal $ack_type “AA”] {
return “{CONTINUE $mh} {OVER $obMsg}”
} else {
return “{KILL $mh} {OVER $obMsg}”
}
}
shutdown {
# Doing some clean-up work
}
default {
return “” ;# don’t know what to do
}
}
}
-
You cannot issue a KILL for the reply message, you must issue a KILLREPLY. When a message is sent with Wait Reply enable, a flag is set to tell the engine to open the IB and take everything in as a Reply messages. No more messages are sent until that reply is either recieved ofr the Wait Reply time is exceeded and it times out.
The only difference betweena KILL and a KILLREPLY that, in addition to doing all of the things a KILL does, the KILLREPLY clears the AWAIT REPLY flag to allow the next OB message to be sent.
Also I noted you set ypu Wait Reply time to 5 seconds. This is not long enoygh and will probably cause duplicate messages to be sent. Be sure and set this to several orders of magnitude greater than the longest time it takes the receiver to resond. As a rule, except for extrodinary circumstances, I set mine to 45 seconds. It will not affect the normal message flow. It will only be in affect if the receiver’s port is still active and he does not respond.
It covers those times when perhaps you sent a message and smehow it got lost on his side.
-
-
-
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
