Clovertech

Filter messages in FRL

› Clovertech Forums › Read Only Archives › Cloverleaf › Cloverleaf › Filter messages in FRL

  • Creator
    Topic
  • August 20, 2011 at 4:05 pm #52653
    Daniel Lee
    Participant

      Qdx 5.5 on AIX 5.3

      I’m hoping for some suggestions on the best way to handle filtering messages in an FRL.  Here’s what I’ve come up with so far which both have a big flaw in my opinion:

      1)  I could use an Offset and Length in the Trx ID determination of the Inbound tab on the thread configuration and then just set up my route accordingly.

      2)  I could create a tcl proc to pull out the data necessary to filter the messages and kill them in the TPS Inbound Data UPoC.

      I don’t like either of these options because they do not take the FRL format into consideration.  For example, if a field length changes in the variant at some point in the future for whatever reason and the change affects a field that precedes the field I’m keying off of, then my filter will break.  I can’t guarantee that the programmer after me will remember to look at my code if they change the variant.

      I’ve never had to use the GRM commands before but is this an appropriate time to use them?

      Thanks!

      -Daniel

    • Creator
      Topic
    Viewing 2 reply threads
    • Author
      Replies
      • August 20, 2011 at 5:25 pm #75004
        Jim Kosloskey
        Participant

          Daniel,

          I predict there will be a lot of advice against using the GRM functions.

          Having said that I will tell you that nearly all of our filtering is done with one Tcl proc that deploys the GRM functions and is driven at execute time in its work by provided arguments. We do not have any issues. Works for any mesage deinition that can be made in Cloverleaf and as you noted can be immune to layout changes (as long as the address pathing remains unchanged).

          I have a suggestion if you decide to use Tcl (with or without GRM) and that is consider placing your filter pre-route rather than at the Inbound TPS.

          The reasoning is at the Inbound TPS you effect every message no matter how many systems want the data in that message. So now all the receiving systems you know about are OK with this – but next week a new system wants that data but either unfiltered or with different filtering characteristics. Much better to move that down stream I think.

          You could also utilize a TrxId proc to cause filtering – but you only get one of those and so it could become a pretty complicated proc.

          email: jim.kosloskey@jim-kosloskey.com 30+ years Cloverleaf, 61 years IT – old fart.

        • August 20, 2011 at 11:20 pm #75005
          Daniel Lee
          Participant

            Thanks Jim. I’ll play around with the Grm and see what I think. It is a batch interface so I am a little concerned about the processing cycles during the batch run but it may not be a big issue. You always hear the warnings about Grm’s but I’m not sure how big of an issue it really is.  If your using a lot of them it may not be that bad. Any other opinions are welcome. Thanks again Jim.

          • August 22, 2011 at 3:07 am #75006
            Richard Hart
            Participant

              Hi Daniel.

              If we have a (TCL) translation before the routing and possible Xlate, we often use the translation code to set the routing details in the messages USERDATA and then the routing code is simply.

              proc icm_code_trx_id_ack {aMsgId} {

          • Author
            Replies
          Viewing 2 reply threads
          • The forum ‘Cloverleaf’ is closed to new topics and replies.