| Author |
Message
|
| dyson |
 Posted: Tue Jun 18, 2013 5:53 pm Post subject: ESQL - converting variables into literals |
 |
|
Apprentice
Joined: 04 Apr 2011
Posts: 45
|
Hi,
I'm looking for a way to convert variables into literals e.g.
| Code: |
set x = 'InputRoot.XMLNSC.*:Transaction.*:TranID';
set y = '<>';
set z = '1234567';
IF {x} {y} {z} THEN
go home and eat something;
END IF; |
Is ESQL capable of this? |
|
| Back to top |
|
 |
| kash3338 |
| Posted: Tue Jun 18, 2013 8:17 pm Post subject: Re: ESQL - converting variables into literals |
|
|
Shaman
Joined: 08 Feb 2009
Posts: 709
Location: Chennai, India
|
| dyson wrote: |
| Is ESQL capable of this? |
ESQL is certainly capable of doing this.
One approach is by the use of EVAL Statement. But I am not sure if this is the best approach since there are performance constraints in using EVAL statements.
There may be other approaches as well. |
|
| Back to top |
|
|
| Esa |
| Posted: Tue Jun 18, 2013 10:31 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
Looks like you are looking for a way to convert Message Broker into a rules engine.
Doesn't sound right. I would rather implement the rules on an application server, expose it as web services and call there from broker flows.
Or, depending on your budget, buy a real rules engine. |
|
| Back to top |
|
|
| smdavies99 |
| Posted: Tue Jun 18, 2013 10:34 pm Post subject: |
|
|
Jedi Council
Joined: 10 Feb 2003
Posts: 6076
Location: Somewhere over the Rainbow this side of Never-never land.
|
| Esa wrote: |
Or, depending on your budget, buy a real rules engine. |
didn't broker once upon a time have such a beast? 
(ducks to avoid incoming missiles, brickbats and other projectiles)
_________________
WMQ User since 1999
MQSI/WBI/WMB/'Thingy' User since 2002
Linux user since 1995
Every time you reinvent the wheel the more square it gets (anon). If in doubt think and investigate before you ask silly questions. |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Jun 19, 2013 2:37 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| @dyson: I agree with Esa - and using ESQL in this way is not a viable approach. But I am interested to know what the underlying requirement is. Can you tell us? |
|
| Back to top |
|
|
| vmcgloin |
| Posted: Wed Jun 19, 2013 3:58 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
| I agree with the previous posters but am I right in remembering that you can do this substitution with fieldnames? So that {x} in the OP's example might work? |
|
| Back to top |
|
|
| kimbert |
| Posted: Wed Jun 19, 2013 4:14 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| @vmcgloin: yes- it could be made to work that way. I'm just being careful because we don't really know what the requirement is yet - and I don't want to encourage the wrong technical solution. |
|
| Back to top |
|
|
| Esa |
| Posted: Wed Jun 19, 2013 5:18 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| vmcgloin wrote: |
| I agree with the previous posters but am I right in remembering that you can do this substitution with fieldnames? So that {x} in the OP's example might work? |
Yes, {x} and even {z} could work, but I doubt {y} could easily be made to work as an operator... |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jun 19, 2013 5:43 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Esa wrote: |
| vmcgloin wrote: |
| I agree with the previous posters but am I right in remembering that you can do this substitution with fieldnames? So that {x} in the OP's example might work? |
Yes, {x} and even {z} could work, but I doubt {y} could easily be made to work as an operator... |
In fact, {x} as stated can't work.
{variable} can only evaluate a single part of a path. So it can evalute {'InputRoot'}, and {'XMLNSC'} but it can't evaluate {'InputRoot.XMLNSC'}.
kimbert - you need to kick some of your ESQL colleagues for failing to point this out. |
|
| Back to top |
|
|
| Esa |
| Posted: Wed Jun 19, 2013 6:55 am Post subject: |
|
|
Grand Master
Joined: 22 May 2008
Posts: 1387
Location: Finland
|
| mqjeff wrote: |
kimbert - you need to kick some of your ESQL colleagues for failing to point this out. |
I don't think you need to point out everything that doesn't work  |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jun 19, 2013 7:14 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| Esa wrote: |
| mqjeff wrote: |
kimbert - you need to kick some of your ESQL colleagues for failing to point this out. |
I don't think you need to point out everything that doesn't work |
I'd not have bothered if it were merely the original poster's confusion. But several of you all suggested that it could work as written.
Which it can't.
{} can only be used to refer to a specific individual segment of an ESQL path, not a full path nor even more than one segment of a path.
EVAL may work but doesn't perform terribly well compared to other things. But if one needs to implement one's own rules engine, and one has to do it in Broker and one has to do it in ESQL, then EVAL is the choice available aside from writing one's own code to parse paths and move references.
There are better options in other transformation interfaces, including writing a java procedure that can use evaluteXPath.
And there are other rules engines available that can be used from within broker, for a number of values of "from within". |
|
| Back to top |
|
|
| mgk |
| Posted: Wed Jun 19, 2013 8:05 am Post subject: |
|
|
Padawan
Joined: 31 Jul 2003
Posts: 1642
|
So to be completely pedantic  , {'InputRoot'} will not work either because {...} cannot be the first item in a field reference, that is it can be part of a field reference but not the correlation name.
Kind regards,
_________________
MGK
The postings I make on this site are my own and don't necessarily represent IBM's positions, strategies or opinions. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Wed Jun 19, 2013 8:27 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| mgk wrote: |
| So to be completely pedantic , {'InputRoot'} will not work either because {...} cannot be the first item in a field reference, that is it can be part of a field reference but not the correlation name. |
To be completely pedantic, I never said if {'InputRoot'} was the first part of the field reference...
| Code: |
| Environment.Variables.{'InputRoot'} |
 |
|
| Back to top |
|
|
| dyson |
| Posted: Wed Jun 19, 2013 10:04 am Post subject: Rules engine |
|
|
Apprentice
Joined: 04 Apr 2011
Posts: 45
|
You are correct I am trying to build a very simple rules engine. And you may be correct that my approach is wrong.
Little background:
Instead of publishing the same message to multiple destinations only to have most of those destinations reject/filter out most of the messages I wanted to filter in one place reducing network traffic. Now I know that it sounds like I'm recreating the wheel, the wheel being topic trees, but the problem is that topic trees are static which means I need guess right the first time and then recode every time the business changes their mind.
So the goal is to create a publishing component that will publish to topics based on the business ever change requirements. There won’t be a lot of rules but want to avoid having to recode if possible.
Sounds like java is the best approach any suggestions on this would be great.
Thanks. |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Wed Jun 19, 2013 10:18 am Post subject: Re: Rules engine |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
|
| Back to top |
|
|
|
|
