What I would do :
Build a DDA that would contain :
- d_TWS_Alert criteria
- a list of slots that would contain target value
Build a rule which uses the DDA which does a match using d_TWS_Alert criteria and maps values according to DDA values !
- 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.
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
MY_DDA ISA DATA DEFINES
match_d_TWS_Alert: STRING, default='%s'; # %s means any string for match operator
# New values
#======= Rule using DDA
refine myrule :
# using match rather than equals... a bit slower but quite usefull
$EV.d_TWS_Alert matches $DDA.match_d_TWS_Alert
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.
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 ;-)
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.