| Author |
Message
|
| pfaulkner |
 Posted: Sun Oct 12, 2003 9:27 am Post subject: help with ESQL PROCEDURE |
 |
|
Master
Joined: 18 Mar 2002
Posts: 241
Location: Colorado, USA
|
I have a compute node with a huge block of code (over 6000 lines). The code is broken up into various sections to build an output message. Right now my code is all lumped together and has IF's to determine which sections of code to execute.
Any recommendations on how to structure my code to make it easier to maintain and read.
I thought I could put each section in a procedure with in the compute node and just make calls to the sections I needs. I couldn't find anything in the ESQL manual about this though.
Any suggestions would be greatly appreciated.
thanks |
|
| Back to top |
|
 |
| kimbert |
| Posted: Mon Oct 13, 2003 2:29 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
You don't say what your input domain and format are. However, I suspect you may be using the XML domain for input. If so, you should seriously consider modelling your input and output messages using the MRM domain. This almost always results in simpler ESQL, because
1) The MRM domain builds simpler message trees
2) It is sometimes possible to get the MRM to map your input fields to your output fields automatically - you just write one line of ESQL to change the message type, and it happens for free.
Without knowing a bit more about your messages, I cannot be any more specific - but 6000 lines does sound like a lot of ESQL, and you're quite right to be looking for ways to simplify. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Oct 13, 2003 4:44 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
There is a CREATE PROCEDURE function.
Also, you can consider this. Put all your various different pieces of ESQL into their own compute nodes. Use a new compute node to determine which sets of things need to be done, and then create a destination list from that. Use the destination list with a RouteToLabel and a set of Label nodes to run the right set of ESQL against your incoming message.
Then you will later have the option of moving different pieces of code into their own separate message flows, if you need to assign more processing power (additional instances) to them.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| pfaulkner |
| Posted: Mon Oct 13, 2003 6:41 am Post subject: |
|
|
Master
Joined: 18 Mar 2002
Posts: 241
Location: Colorado, USA
|
I am using XML in and MRM out. My input message structure is nothing like my output tree and has a ton of custom rules that are required in the logic in order to build the output message so I can't just map the root structures and change the message type.
I did think about using the Route to Node, but I was concerned what that and all the addition Compute nodes would do to performance. |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Mon Oct 13, 2003 12:30 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
| pfaulkner wrote: |
| I did think about using the Route to Node, but I was concerned what that and all the addition Compute nodes would do to performance. |
Performance considerations are usually, in my opinion, best backed up by facts and put into context with design and maintainability requirements.
There are performance documents for WMQI that talk about how to design message flows for performance. And those documents may suggest that putting all your ESQL in a single node will give better performance than putting your ESQL across many nodes.
But you're the only one that knows what your real design, maintainability and performance requirements are, and so you're the only one who can measure whether there is a noticable performance hit by putting the code in separate nodes, and whether that hit is acceptable or not.
I mean, if you're doing stuff that's got a 5 minute turnaround, and changing the flow to make it more flexible and maintainable adds 2 seconds to the execution time... Then I don't think you have a problem. 
But with over 6000 lines ( ) of ESQL in a single node, I don't think you can tell the performance hits without measuring it. 
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| ernest-ter.kuile |
| Posted: Thu Oct 16, 2003 7:19 am Post subject: Re: help with ESQL PROCEDURE |
|
|
Apprentice
Joined: 13 May 2002
Posts: 49
Location: KLM Holland
|
| pfaulkner wrote: |
... I thought I could put each section in a procedure with in the compute node and just make calls to the sections I needs. I couldn't find anything in the ESQL manual about this though...
|
If your code is longer 5999 lines you should indeed check if multiple computer nodes might not help clarify your program.
Check if at some point you could simplify your code by reparsing your data differently for different parts of your program
Check if you have big IF sections in your code, which could be beter handled in different paths in you flow.
Anyway, if your are missing the docs about procedures and functions, you should try to find the docs from after wmqi 2.1 csd 2. Before that the esql ref about function and procedures where flimsy at best.
Silly example PROCEDURE :
| Code: |
/*
* Check to prevent infinite loop in this compute node.
* for this to work, must :
* DECLARE safetycnt INT; and initialise it to a large number (10000)
* DECLARE Env REFERENCE TO Environment.GlobalVariables;
* CALL InfiniteLoopCheck (safetycnt, Environment);
* Insert in all loops behond a certain complexity.
*/
CREATE PROCEDURE InfiniteLoopCheck (INOUT LoopCount INT, IN Env REFERENCE)
BEGIN
IF LoopCount <= 0 THEN
SET Env.ErrorString = "Safety Count Flipped: Infinite loop in flow";
THROW USER EXCEPTION CATALOG 'WMQIv210' MESSAGE 2949
VALUES('LoopCount flipped');
END IF;
SET LoopCount = LoopCount - 1;
END; |
- inside a function or a procedure, you cannot access any global constructs except whatever you passed as parameters. Above I passed Environemnt as a reference parameter.
Example function:
| Code: |
CREATE FUNCTION CalcDate (year_of_flt CHAR, month_of_flt CHAR, day_of_flt CHAR,
legdate CHAR) RETURNS CHAR
BEGIN
RETURN year_of_flt || month_of_flt || day_of_flt || legdate;
END; |
All parameters in function calls are implicitly or must be explicitly IN parameters.
have fun. |
|
| Back to top |
|
|
| pfaulkner |
| Posted: Thu Oct 16, 2003 11:51 am Post subject: |
|
|
Master
Joined: 18 Mar 2002
Posts: 241
Location: Colorado, USA
|
Thanks for the reply. I am running CSD5 and assumed when I installed the CSD it also updated my documentation files. I searched the ESQL manual for both PROCEDURE and FUNCTION and found nothing (except for it being a reserved word).
How do I check I have the latest documentation and how do I get the latest if it doesn't come with the CSD download?
thanks |
|
| Back to top |
|
|
| EddieA |
| Posted: Thu Oct 16, 2003 6:39 pm Post subject: |
|
|
Jedi
Joined: 28 Jun 2001
Posts: 2453
Location: Los Angeles
|
The CSDs, unfortunately, don't update the documentation.
Head over to the IBM web site for the latest and greatest.
Cheers,
_________________
Eddie Atherton
IBM Certified Solution Developer - WebSphere Message Broker V6.1
IBM Certified Solution Developer - WebSphere Message Broker V7.0 |
|
| Back to top |
|
|
|
|
