Filtering messages on a particular thread

Rehman,

We use an argument driven, reusable Tcl Proc in the Pre-Xlate (it can be used at most any UPoC but that is where we prefer to use it 99% of the time).

You can also do this in an Xlate by using the SUPRESS Action subordinate to an IF Action.

Hi Rehman,

I’m not sure there is a “best” way to do this, just preferred methods…

…if you’re approaching from an engine performance perspective, the message should be killed with Tcl in a pre-translation Upoc as Jim correctly suggests;

…or it can be done in the translate, where I find it more “in the open” and easier to keep track of — although processing a message through translation is more overhead, especially if you’re going to SUPRESS it;

Here’s how I would do it…using a table of PV1-3 values

TABLE -> @SendMsg (the table would contain true for allowed PV1-3 values and false as the default)

IF @SendMsg eq =true

…….Process the message for other edits, etc.

ELSE

…….SUPRESS

This should work for your example.

Rehman,

Here is some input:

If you apply filtering at the Inbound TPS then ALL inbound messages are affected.

If you apply filtering at the Route (pre xlate or pre raw), then you only affect those routed messages. The down side is if you have many routes that need filtering you need to place the filtering on every route.

Here we apply the filtering on the routing.

Hi Rehman.

We use this fairly often when we are already using some TPS inbound code or we use the TPS code in the routing script.

Use the TPS inbound to parse the message and set a routing tag according to the business rules.  

Store the tag in the message metadata.

The routing script  then just grabs the metadata and returns the code

eg

proc icm_code_trx_id_ack {aMsgId} {

               #

               # The Route is in the user data

               #

       set myTrxId [msgmetaget $aMsgId USERDATA]

       return $myTrxId

}

When the filtering is relatively simple I like using the tps_msg_action.tcl argument driven proc preroute.

When the filtering becomes complex like with more than 2 compound conditions, I like to us a TrxID proc to route unwanted messages to hcitpsmsgkil.

Here is a clovertech post illustrating how I used a TrxID proc to do complex filtering by routing messages to hcitpsmsgkill:

    <a href="https://usspvlclovertch2.infor.com/viewtopic.php?t=1562&#8243; class=”bbcode_url”>https://usspvlclovertch2.infor.com/viewtopic.php?t=1562

Here is a clovertech post illustrating the use of Jim’s tps_msg_action.tcl plus the proc source code to do simple filtering using a lookup table to define the filter values.

    <a href="https://usspvlclovertch2.infor.com/viewtopic.php?t=1578&#8243; class=”bbcode_url”>https://usspvlclovertch2.infor.com/viewtopic.php?t=1578

I did a recent filter with tps_msg_action that’s about as simple as it gets and perhaps more applicable to your case.

Here are the arguments copied from the pre-xlate route in the NetConfig so you can see how to get tps_msg_action to do a very simple filter: