I think you’ve noted some of the major pros and cons between the two. I think Jim Kosloskey has done a load and timing comparison doing TCL vs Xlate, and I think the difference was minimal.
I will add this, when we were coming onboard with Cloverleaf, they (Cloverleaf reps/trainers) pushed against filtering in Xlate.
However, the answer comes down to “it depends”. It’s a whole lot easier and cleaner to write generic filters (we have a lot of facility and department filtering) that are stored in master that a LOT of our interfaces use. You call the filter, pass in a table, and it does it’s work based on that. When troubleshooting, while it does add an extra step, you know it’s there, it’s marked and you immediately understand what it does. There is no need to parse the entire message (just pop out the data you need, check to see if it needs to go, and work it based on that).
On the inverse, when you get to specific filtering that is unique to a specific vendor/interface, it’s almost easier to do in the XLate. However, when doing it that way, there has to be an easy way to see if you’re filtering in the Xlate. Comments and whatnot can help, but again, that’s a high level design choice. Filtering in TCL helps quickly see IF it’s happening, and then you dig deeper to see how it’s happening. Keeping the filters in Xlates means you have to dig into the Xlate itself and see if it’s filtering and how it’s filtering it.
And this is my personal opinion, to me it’s easier to read filter rules in TCL, depending on how it’s written (assuming some decent style guides and good variable naming).
One of the things that a senior tech has emphasized is “make it so it’s easy as possible to troubleshoot at 3 AM after being woken up out of a deep sleep, and you didn’t write it”.
.
