noob questions, mainly around inbound/outbound threads and contexts

[Jason]

when I replay messages, how can I replay messages on the inbound thread, have them go through the XLT and then hit the outbound thread? whenever I try to replay on an inbound thread it never seems to hit the outbound thread, I always have to replay it on the outbound thread in order to see it there.

I guess my confusion lies with the definition of inbound/outbound on inbound or outbound threads. Like, what’s the differentiation between replaying a message on an inbound thread with inbound or outbound context?

Thanks and any help is greatly appreciated

Topic

[David Barr]

All threads send messages both inbound and outbound. What we think if as inbound threads receive messages in the inbound direction and send acks in the outbound direction. Outbound threads send messages outbound and receive acks inbound. If you resend a message to an inbound thread but with an outbound context then my guess is that the message will be sent through that interface to the original sending system, and that system is only expecting acks from you.

Messages that are stored in inbound SMAT were saved when the messages were in the inbound_pre_tps context, so if you resend from that file, you should use that same context when resending to the inbound thread. If you do that, then they should go through the regular message routing, translation and be sent on the outbound thread. If that’s not working, then context is not the problem. You may have something else going on, and I would look at the process log file and error log to start troubleshooting. If I didn’t see any errors, I’d make sure that my outbound interface was connected and the resent message isn’t hanging around in the recovery database.

[Jason]

David,

Thanks for that reply, I did not know that SMAT messaves were saved as inbound_pre_tps context. So there is a difference if I pick inbound pre_tps vs post_tps when I resend… interesting. I know that if I resend a SMAT message on an outbound thread with outbound post_tps context, it works fine; I just never really understood how to resend it over the inbound thread, but I will try inbound_pre_tps next time.

Another analyst here told me once that if we don’t have any TPS translation on a certain thread (inbound or outbound) then pre_tps vs post_tps shouldn’t matter…? Made sense at the time.

 

[David Barr]

The difference between resending with ib_pre_tps or ib_post_tps is whether or not you want the inbound TPS procs to run on the message. If you don’t have any inbound TPS procs, then it doesn’t matter which you pick, but I would go with ib_pre_tps anyway because that corresponds to the context when the messages were saved, and it will get you in trouble if you’re developing a habit of doing that without realizing when it matters. If you’re sending from outbound SMAT, you should pick ob_post_tps for the same reasons. Resending ob_pre_tps will send messages through the OB TPS procs twice, and that doesn’t match what should be normally happening.

[Jason]

Resending ob_pre_tps will send messages through the OB TPS procs twice

Can you explain this part more? How does resending ob_pre_tps (assuming there are OB TPS procs) make it go through TPS procs twice? In my mind it should only go through once..? Is it because the original SMAT message was saved on the ob_post_tps side and replaying it would effectively run it through the TPS procs twice? (first time before it got saved in SMAT and then the replay)

thanks again btw

[Rob Abbott]

I think David means that the message will go through the OB TPS once when it’s first delivered and saved to SMAT.   Then it would go through again if you resent to “ob_pre_tps”.

 

Think about where the message gets dropped in the data flow.  It looks like this:

 

(inbound protocol)–(save to SMAT)—1—ib_tps—2——-xlate——-10—ob_tps—11–(save to SMAT)–(outbound protocol)

 

If you resend to ib_pre_tps, the message will be deposited in state 1

ib_post_tps deposits to state 2

ob_pre_tps deposits to state 10

ob_post_tps deposits to state 11

 

 

Rob Abbott
Cloverleaf Emeritus

[Jason]

thanks Rob, yeah I figured it out, I didn’t know where the SMAT messages actually get saved but it helps to know.

So is it safe to say, if you don’t have any TPS procs in the ib/ob thread, it doesn’t matter if you pick pre/post TPS?

[David Barr]

Yes, that’s the reason.

[Jason]

thanks David, appreciate the help

[Jim Kosloskey]

Excellent exchange of information.

If there is any filtering going on in the path from IB to OB then obviously the IB message may not make it to the OB thread.

Also resending a SMAT message to the OB thread should be an OB message. Normally it does not make sense to resend an IB message from SMAT to the OB thread.

I would also follow the recommendation to resend IB messages to the IB pre-Tps context. If there is no proc specified – no harm. But if later a proc is added (maybe by another team member or contracted hand) and you are not aware of it, the result will not be as it should be if you resend post-tps.

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

[Rob Abbott]

Jason wrote:

So is it safe to say, if you don’t have any TPS procs in the ib/ob thread, it doesn’t matter if you pick pre/post TPS?

yep, that’s correct!

Rob Abbott
Cloverleaf Emeritus

[Robert Kersemakers]

With receiving tcp/ip threads I always make sure that the only proc in TPS Inbound Data is the generation of the ACK. When resending an inbound message, I will want to use Inbound post-TPS, so we don’t send an ACK to the sending system (sending system going: what???).

Ideally in TPS Inbound Data you only want procs regarding the receiving of the message and not the subsequent processing of the message; that should be done in the routing. But I can’t say I abide to that rule myself.

Zuyderland Medisch Centrum; Heerlen/Sittard; The Netherlands

[Author]

Replies