12 Replies Latest reply: Jan 16, 2012 6:44 AM by Laurent NameToUpdate RSS

MRL syntaxe question (case XXX in XXX)

Laurent NameToUpdate

Hey guys,

 

I'm trying to use a "case XXX in XXX" state in a Refine rule and can't seem to find the correct syntax.

 

I've tried:

 

refine TWS_P_UNTIL_APP :
      TWS_EVENT ($EV)
       where [ ($EV.status != CLOSED AND $EV.status != BLACKOUT) ]
       {
        case  $EV.d_TWS_AlertReff in

               P_DEADLINE_JOBSTREAM )

                     {

                      $EV.mc_object_class = ... ;                     

                      concat ([...],$msg);
                      $EV.msg = $msg;
                       };

               P_DEADLINE_JOB )

                      $EV.mc_object_class = ... ;                      ...

                      concat ([...],$msg);
                      $EV.msg = $msg;
                       };

          ...

          }

END

 

But this doesn't work.

Can we use a "case" logic in MRL?

If yes, what's the syntax? I can't find any examples in the existing rules.

 

Thanks for your help

Laurent.

  • 1. MRL syntaxe question (case XXX in XXX)
    Ferry Bolhar

    There is no "case" syntax im MRL.

     

    You must use if - then - else. In your example:

     

    if ($EV.d_TWS_Alert == P_DEADLINE_JOBSTREAM) then

    {

      ...

    }

    else

    {

      if ($EV.d_TWS_Alert == P_DEADLINE_JOB) then

      {

        ...

      };

    };

  • 2. MRL syntaxe question (case XXX in XXX)
    Laurent NameToUpdate

    Erf, ok thanks.

     

    Is it better / more efficient to have?

    - 1 big refine rule containing multiple "if" for all my alet references (10 => 15) or

    - Multiple refine rules (1 per alertref) with the Alert References in the ECF

     

    Cheers,

  • 3. MRL syntaxe question (case XXX in XXX)
    Ferry Bolhar

    From my experience, having one big rule is better (it's also easier for tracing).

  • 4. Re: MRL syntaxe question (case XXX in XXX)
    Jonathan Coop

    You're stuck with if then else, try splitting into multiple rules for readability. Jon

     

    Sent from my iPhone

  • 5. MRL syntaxe question (case XXX in XXX)
    Jean-Sébastien Roques

    Hello,

     

    What I would do :

     

    Build a DDA that would contain :

    • d_TWS_Alert criteria
    • a list of slots that would contain target value
      • mc_object_class_values
      • msg_values

     

    Build a rule which uses the DDA which does a match using d_TWS_Alert criteria and maps values according to DDA values !

     

    Pros :

    • your not using any if/then/else : if/then/else  statement are VERY inefficient in MRL rules. You should avoid this whenever you can.
    • in case you have a new value for d_TWS_Alert, you just have to add an entry into the DDA and not modify your code !

     

    Cons : none ?

     

    Hope this helps.

    Jean-Sébastien

  • 6. Re: MRL syntaxe question (case XXX in XXX)
    Jonathan Coop

    I would create multiple rules, each with condition as part of the ECF, ok lots of rules but very fast. Jon

     

    Sent from my iPhone

  • 7. Re: MRL syntaxe question (case XXX in XXX)
    Ferry Bolhar

    Why are if-the-else statements so inefficient? Could you explain this?

     

    Could you show the code to implement DDA for this example?

  • 8. Re: MRL syntaxe question (case XXX in XXX)
    Jean-Sébastien Roques

    Hello,

     

    I would not be able to explain exactly why... but it is due to the fact that MRL is Prolog based which is not a "procedural" language like C or perl. if/then/else does not exists natively in Prolog and have been implemented in MRL for convienience and should be avoided whenever possible.

     

    As Jon suggest, it is more efficient to have several rules with specific ECF.

     

    But it means readability / maintenance problems...

     

    Here is a little example of DDA usage (not tested... and not even compiled... so there may be, at least, some syntax issues...) based on Laurent's post :

     

    #======== DDA Definition
    MC_DATA_CLASS:
      MY_DDA ISA DATA DEFINES
      {
        # Criterias
        match_d_TWS_Alert: STRING, default='%s'; # %s means any string for match operator

        # New values
        val_mc_object_class: STRING;
        val_msg:STRING;
      };
    END

    #======= Rule using DDA
    refine myrule :
    EVENT($EV)
    using {
      MYDDA ($DDA)
      where [
                # using match rather than equals... a bit slower but quite usefull
                $EV.d_TWS_Alert matches $DDA.match_d_TWS_Alert
            ]
    }
    {
      $EV.mc_object_class=$DDA.val_mc_object_class
      $EV.msg=$DDA.val_msg;
    }
    END

     

    HTH.

    Jean-Sébastien

     

          mc_object_class: STRING;
  • 9. Re: MRL syntaxe question (case XXX in XXX)
    Ferry Bolhar

    The fact that MRL is prolog-based doesn't necessarily mean that it hat performance problems with if-then-else... I think, accessing a DDA also wouldn't be an easier action in Prolog than a simpe if-then-else...

     

    I've never seen a suggestion "avoid if-then-else whenever possible" in BMC documentation.

     

    I have rules with 20 and more nested if-then-else constructs, and they run without problems (and even without any performance impact). So even Prolog may not have a construct like this, there are no problems when using it in MRL.

     

    Having 20 rules instead would result in maintenance problems, and in case of program faults, would mean to trace 20 rules instead of one. And AFAIK processing more rules is more expensive than less since all rule's ECF must be re-evaluated for each event.

     

    But of course, you're right that there are situations where a DDA is a better choice than a nested if-then-else. However, it's not always a replacement for DDA.

  • 10. Re: MRL syntaxe question (case XXX in XXX)
    Jean-Sébastien Roques

    Hello again,

     

    Actually, I strongly beleive that accessing a DDA is more efficient that building a (nested) if-then-else because of the way Prolog is "searching for a solution".

     

    There is a quite interresting document here : The specified item was not found.. It gives some interresting performance tips & tricks, including avoiding (when possible / realistic) if-then-else. It is true that this is not documented in "official" documentation... silly, isn't it ?

     

    Unfortunately, it seems that this document is not publicly available. You may want to ask BMC if you can get it though.

     

    Anyway, it is just the way I would do it ;-)

     

    Jean-Sébastien.

  • 11. Re: MRL syntaxe question (case XXX in XXX)
    minigts

    Hi Jean-Sébastien,

     

    Thanks for posting this link. Some of the images were not available in the slide presentation, but very good read.  There was only one slide on the if/then/else, simply stating to avoid it, so I'm sorta with others as to the questions about the purported inefficiencies of it. Regardless, hopefully it will lead me to write better MRL.

     

    EDIT:  Didn't scroll down far enough to see the PDF download. I can see all the images in the doc.

  • 12. MRL syntaxe question (case XXX in XXX)
    Laurent NameToUpdate

    Hey Guys,

     

    Thank you verry much for all your help.

     

     

    Cheers,

    Laurent.