Put $mh back into recovery database

[David Speare]

I have a tcl proc that evaluates whether an incoming message should continue on or not.  If the procedure determines that a certain action is taken, I would like to add that message back into the recovery database for it to be processed again.  Here is the bottom logic where I am trying to reprocess it.  I thought the PROTO command would send it back around, but that isn’t doing it for me.

# if an EPIC order file was created, go ahead and kill this message

# b/c it was placed in the recovery db for reprocessing

if {$IsCreated == “created”} {

echo Original incoming message will be sent back in

lappend dispList “PROTO $mh”

} else {

lappend dispList “CONTINUE $mh”

}

echo $dispList

       }

Bottom line is that if the $IsCreated == “created” i want this message sent back in to the Inbound-pre TPS.

Topic

[Max Drown (Infor)]

What do you mean by “back into the database”? Or you wanting to change the state of the message like move it back to state 1?

-- Max Drown (Infor)

[Charlie Bursell]

In what context is the Tcl proc.  If an OB Tcl proc simply CONTINUE if you want to send or OVER it to go back to IB

[David Speare]

Sorry for my delayed response, I think the answer would be that I want to move it back to state 1 and have it process from the beginning.  It would hit a different “if” condition the second time around.

[Max Drown (Infor)]

Disposition Description

CONTINUE: send on to the next state

KILL abort processing of the message and destroy it

KILLREPLY abort processing of the message and destroy it; terminates await-reply mode; clear the await-reply flag, useful only in IB Reply TPS

OVER abort processing of the message, for IB DATA TPS the message is placed in state 10 (pre-outbound in case you have a proc), for OB Data TPS the message is placed in state 1, causes an engine panic if used in the translation thread

PROTO abort processing of the message, place message in state 11, places the message on top of the queue (increase priority), causes an engine panic if used in the translation thread (ex. resend in check_ack)

SEND abort processing of the message, place the message into outbound pre-tps queue of the thread specified in the DESTCONN metadata field, set the SKIPXLT flag

ERROR abort processing of the message, the message is placed into the error database, forces an error (tcl erorr), tip: add reason in the metadata

# Purpose: [code]# Purpose:

-- Max Drown (Infor)

[David Speare]

This isn’t quite working out like i had hoped.  I can’t really place this on the outbound stack b/c my messages come into my thread as an MDM and my ib tps determines if the message continues as an MDM or if that MDM should be killed and an ORU put in it’s place.

i’d rather not run it through up through the xlates if i don’t have to, but on the copy as you gave me above (good stuff though) my msgState is not known.  I have no idea where the $copymh is going.  I don’t see it in recovery db or error

msg: 0x03D2B8F8

   msgType           : DATA

   msgClass          : PROTOCOL

   msgState          : Unknown: 0 (0)

   msgPriority       : 5120

   msgRecoveryDbState: Log:new (2)

   msgFlags          : 0x8002

   msgMid            : [0.0.91497998]

   msgSrcMid         : midNULL

   msgSrcMidGroup    : midNULL

   msgHostId         : 3148155885

   msgOrigSrcThread  : fr_Onbase_dms

   msgOrigDestThread :

   msgSrcThread      : fr_Onbase_dms

   msgDestThread     :

   msgXlateThread    :

   msgSkipXlate      : 0

   msgSepChars       :

   msgNumRetries     : 0

   msgGroupId        : 0

   msgDriverControl  : {CONNID 0} {IPVERSION 4} {CLIENTIP 10.34.10.103} {CLIENTPORT 65482}

   msgRecordFormat   :

   msgRoutes         :

   msgUserData       :

   msgStaticIsDirty  : 1

   msgVariableIsDirty: 1

   msgTimeStartIb    : 1426026311.981

   msgTimeStartOb    : 1426026287.651

   msgTimeCurQueStart: 0.000

   msgTimeTotalQue   : 0.000

   msgTimeRecovery   : 1426026312.606

   msgEoConfig       : 0x00000000

   msgData (BO)      : 0x03D2B9E0

   message           : ‘MSH

[David Speare]

FTR – i’ve omitted the actual message, it’s there on my msgdump

[Max Drown (Infor)]

Where is your tclproc? Which field?

-- Max Drown (Infor)

[David Speare]

TPS IB

it happens right after my ack

[Max Drown (Infor)]

Ok. Little confused as to what you are trying to do. Can you explain high-level for me, please?

-- Max Drown (Infor)

[Jim Kosloskey]

Hmmm won’t putting the message back into State 1 on the Inbound trigger your Ack again? If so, I don’t suppose your sending system expects to get multiple Acks for one message.

So I think you might need to make your Ack proc aware of that.

Do you want to process through your proc again?

A couple of thoughts – set somethiing in the message metadata to indicate your new message is to be received again, then OVER the message. This will place it on the Outbounnd side of the inbound thread. Then on the Outbound Tps use annother proc to OVER the message again – now the message is back on the inbound side of the inbound thread.

In your ack proc check the metadata to see if this is a message to be acked or not. Also modify your original proc to properly react to this message versus an original.

Or —

Set your thread to be mulltiserver.

Change the field you route on to a value whcih allows you to route thse messages o an outbound thread which connects back into your inbound thread. Now the message arrives from a different host (your local outbound thread), the ack proc does not have to be changed but your inbound proc following the ack proc may need to be awwar of this message so as not to get in a nevver-ending loop.

This will also give you the messages stored in various SMATs so you can track it and a visual in the NetMonitor and NetConfig.

Both of the above are thoughts off the top of my head so they could be absolutely worthless.

email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.

[David Speare]

Both thoughts are valid and I’ll test the first idea out.

For the moment, I’m dropping the incoming message – if it is to be reprocessed – to a file and have an identical filesetlocal thread picking it up and processing it.  this is taking a little longer than i’d like, but it’s doing the trick.

[Dirk Engels]

I think there is currently no way of requeueing an ib message. You may could work with a little trick.

In an ib tps check you status and over the message if it doesn’t meet your test criteria.

In an ob tps just over the message again, so it goes back to the inbound.

This of course is working very fast. Please be aware, that if you put a sleep command in the proc you’re blocking the whole process for that amount of time, so you may should configure the thread in a separate process if you like to do that.

[Author]

Replies