| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
  |
|
| Extending ESQL functionality using a parser - WILL IT WORK |
« View previous topic :: View next topic » |
| Author |
Message
|
| warrenpage |
 Posted: Tue Mar 12, 2002 11:33 am Post subject: |
 |
|
Acolyte
Joined: 19 Feb 2002
Posts: 56
Location: Australia
|
Actually I have it working, so my real question is why won't it work. Have I missed something about the way parsers work that will mess me up later.
Let me explain
I took the WKSPACE parser and overrode the SETVALUE function such that, if I set a node called 'function' - my C code will check the value that is trying to be set and return a value (or create a bunch of node under my modified WKSPACE parser domain)
I have called my new parser PROC, and the functions I have written work against nodes under an XML parser domain.
For example - see the following ESQL code
SET OutputRoot.PROC.parm = 'phone';
SET OutputRoot.PROC.function = 'find_nodes';
This returns
(0x1000000)PROC = (
(0x3000000)parm = 'phone'
(0x3000000)function = 'find_nodes'
(0x1000000)node = (
(0x3000000)val = '12345678'
(0x3000000)path = 'xml.Biller.phone'
)
(0x1000000)node = (
(0x3000000)val = '87654321'
(0x3000000)path = 'xml.Primary.Customer.phone'
)
(0x1000000)node = (
(0x3000000)val = '555-1234982'
(0x3000000)path = 'xml.Secondary.Customer.vendor.phone'
)
)
So here are the issues..
1. This only works on the OutputRoot - and you can't see the values in the InputRoot - This means that you need to copy the entire message in the compute node (rather than just the headers). (I'm pretty sure that if you really wanted to get at the input message - you might be able to if you got creative)
2. The Manual says.. dont go jumping into other Parser domains - when you are parsing.. - its unstable.. hmmm Why? what makes it unstable?
The only things I can think off are
a) Partial parsing
b) a another parser overriding the GET/SET function
Currently all I need to do it read stuff from the XML domain. I don't change nodes in another parser domain. I don't go off to ANY old domain.
I am pretty sure that the XML domain - does NOT use partial parsing - since to parse in the first place it would use either SAX or DOM, and its likely to parse whole document in one hit. And even if my access caused a further parse, why would that be a problem, as long as the other parser returned the values I need.
I am also pretty sure the XML domain does not override the Get-Value function. And again even it did, i doubt it does anything that will affect me.
There are some other issues that I won't get into here. So my question still stands, can you think of a reason why this WONT work. Maybe something to do with threading/concurrency?
I would love to hear Mr Kolban's thoughts on this.
Warren
[ This Message was edited by: warrenpage on 2002-03-12 12:57 ] |
|
| Back to top |
|
 |
| kolban |
| Posted: Tue Mar 12, 2002 11:51 am Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
Not a 100% sure on the intent of your logic and my first thought was why not a custom node as opposed to a custom parser?
A parser has a contract with the environment. That contract is that the environment will supply a binary data buffer and the parser will build a tree from that buffer. By attempting to access any existing trees or "walking around" outside the tree your parser is building, is an unsupported operation. It may work now but may not work in the future.
A custom node has the ability to see all trees and create new trees for propagation. If you can come back with more logic on what you needed from the custom code, it might be clearer.
Oh ... Mr Kolban is my Dad ...  |
|
| Back to top |
|
|
| warrenpage |
| Posted: Tue Mar 12, 2002 1:32 pm Post subject: |
|
|
Acolyte
Joined: 19 Feb 2002
Posts: 56
Location: Australia
|
Our problem is that we need to implement data driven validation of an XML document. So we don't directly use ESQL addressing to get to elements. We get an address or a wild-card type address from a database, and some validation rules for all the nodes that match the address.
e.g. from above Validate all phone numbers in the input document - where the only thing you know about the input document is that it has phone tags/elements somewhere, with supposedly phone numbers in it
[ASIDE - also note that we are presently restricted to MQSI 2.0.2 - so we don't have access to some of the new cool commands in 2.1 - though I'm not sure they
answer all our questions]
[ASIDE2 - also also note that IBM marketing has worked it's wonders and convinced management that MQSI can do anything, so we can't go off and use another language or tool that might better suited to this problem]
[ASIDE3 - from ASIDE2 - management thinks that coding MQSI - means coding compute nodes in ESQL - and doesn't want us coding plugin nodes in Java/C++ {I think they are scared that if we code the plugins in java, then we may get to the point where we ask - why are we using MQSI at all} {i guess they also think its easier to teach pgmers ESQL than Java}]
The problem is that ESQL gives us very little in the way of help in terms of walking around the XML document (esp. A document whose structure we do not nec. know at programming time). So we need an efficient way to find a list of nodes based on an addressing schema (think XPath which returns a node-list).
The reason we wouldnt use a plugin node {I am thinking of a single purpose plugin here - like a POSTIT node} is that we need to do many of these node searches (one for each address we have validation rules for).
The advantage of the Parser is that the results are given immediately to the COMPUTE node. We don't need three nodes to do anything, like a Plugin node would do (i.e. one compute to set up the parms, one plug in node, and one Compute to look at the results). The solution is cleaner and performs better since we saved 2 extra node to node tree copies.
Even more generally there are many times, when we wish, heck I wish I had an ESQL function to do X. Using this method I can provide that function. (e.g. Say I wanted a function to break an ESQL address up into its nodes so A.B.C.D gives me node[1]=A,node[2]=B,node[3]=C,node[4]=D. Yep - I can do this in ESQL, but ughh it's not pretty - with lots of substrings etc. I can do it faster and cleaner in C/C++ and make my ESQL look cleaner too.)
Back to the XML navigation issue. Our specs may require us to walk the tree in several different ways depending on what we are trying to validate. Each of these walks would be very clumsy (and slow) in ESQL if possible at all, but C/C++ is not so bad, and my guess is pretty quick in C/C++ [esp. since I'm pretty sure any time you resolve an ESQL address like A.B.C.D - you walk the tree having to go through all the children on nodes looking for the next level].
On your notes about Contracts with the environment - I understand that, and that IBM won't commit to not changing the internal representation of trees/messages in such a way that my solution no longer works. Although, by providing the navigation routines, and I'm sure wanting to provide backward compatibility to old plugins/parsers, my guess is I'm ok for a release or two. And by then, hopefully the functions I need will be in the ESQL language - or I'll have the freedom (from management) to code the solution in a Java plugin node.
You asked for more details - and I'm sure you got more than you wanted. I really just want to find out if I code this up - what are the chances that in production we get some weird segmentation fault, or deadlock because of what I'm doing.
Warren
(P.S. If your dad can help me - by all means ask him too )
(P.P.S It's all a game and you got to play by the rules - no matter how stupid - or go insane)
[ This Message was edited by: warrenpage on 2002-03-12 13:33 ] |
|
| Back to top |
|
|
| kolban |
| Posted: Tue Mar 12, 2002 2:34 pm Post subject: |
|
|
Grand Master
Joined: 22 May 2001
Posts: 1072
Location: Fort Worth, TX, USA
|
I see what you want now. Chances are good that what you have implemented will work and without current side-effects. However, be warned, things may change in the future. By accessing data outside of the tree you are building in the parser, you run various risks that your code may not work in the future.
By having coded a plugin parser, you have already taken the step away from a "vanilla" WMQI system. Its only a little further to the custom node dark-side.
As I look closer, I also think I see that on assigning a value, you may potentially create additional nodes in the message tree ... again, another undefined area. The docs probably don't say what will happen in this area.
The requirement to be able to enhance ESQL with plugin functions has been heard and now with WMQI 2.1, we have gotten a long way closer to describing the transformation in Java ... |
|
| Back to top |
|
|
|
|
|
| |
|
Page 1 of 1 |
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
|
|
