- This topic has 7 replies, 5 voices, and was last updated 6 years, 2 months ago by
.
-
Topic
-
Is there a reason why we should put our TCL scripts in the Inboound threads “route details” verses in the outbound threads “TPS Outbound data”? We just ran into a problem where an old tcl script was causing the Process to PANIC and making all threads in the process to shutdown. The TCL script was in the TPS Outbound Data. So we were able to turn everything on except that one thread until we figured out the issue.
That made me think is there a reason to put a TCL script in Route Details vs TPS Outbound data?
-
Replies
-
-
Well it depends on what is needed to be done.
Typically the Route Details is pre (meaning before Xlate or raw route) when some modification is needed on a message before the Xlate.
On the other hand if what is needed to be done is just before the message is delivered but after routing (Xlate perhaps) then the Outbound TPS can be used.
While there are generalities it really depends on what is needed to be accomplished.
The reason for the PANIC does not inherently have to do with placement of a Tcl proc typically but rather with what is done inside the individual proc.
It is quite likely you would still get a PANIC if the same proc was invoked elsewhere.
email: jim.kosloskey@jim-kosloskey.com 29+ years Cloverleaf, 59 years IT - old fart.
-
Yes the PANIC would still happen but because the TCL script was in the TPS Outbound data I was able to put this Thread in its own Process to isolate the issue so other threads in the previous process could get turned on and process their messages.
We do not do any xlate here so from what I understand is there is no issues/concerns with putting tcl procs in the TPS Outbound data vs route details? I was thinking there might be some issues with how the messages queue if there are multiple threads in a process with tcl scripts in TPS Outbound data but wasn’t sure.
-
-
A good example I have of using the post-Xlate UPoC is message modification. Most things can be done in an Xlate, but some things are just faster and easier to do in a TCL script.
For my example, our system generates an ORU results with a single OBX segment where the entire body of text resides in OBX:5 (a repeating field). There are several recipients of this message, but one of them (McKesson) wanted the results in multiple OBX segments where OBX:5 was no more than 80 characters long. Yes, this was a long time ago…
The script I wrote for that scenario broke up the body text into lines of 80 or less, but it also accounted for word wrapping and paragraph breaks. Theis is not something easily done in an Xlate, even today.
By using this script post-Xlate, I did not have to change the general ORU Xlate variant we were already using for several other systems. Had I made it pre-Xlate, I would have had to changed the variant and the Xlate to iterate through the numerous OBXs created by the script.
There are many more examples where having the script post-Xlate and not pre-Xlate or in the OB TPS made my day easier, but I hope you get the picture from this small one.
-
-
-
As someone who prefers TCL to Xlates, I usually put TCL scripts on the raw route between the source and the destination unless I have one source sending to multiple destinations (I put the proc on the inbound TPS) or multiple sources sending to a single destination (I put the proc on the outbound TPS).
-
- The forum ‘Cloverleaf’ is closed to new topics and replies.
