| Author |
Message
|
| kirank |
 Posted: Thu Nov 02, 2006 9:39 am Post subject: ESQL Files |
 |
|
Centurion
Joined: 10 Oct 2002
Posts: 136
Location: California
|
Hi,
Is it possible to call Multiple ESQL files from one Compute Node? The Compute node property allows only one ESQL module to be specified. But I was just wondering is there any other way of calling multiple ESQL modules from one compute node?
Environment is WBIMB 5.0 CSD3.
Thanks in advance.
Kiran |
|
| Back to top |
|
 |
| jefflowrey |
| Posted: Thu Nov 02, 2006 9:45 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
...
...
Why?
...
No, it's not possible to have a compute node invoke more than one Main method at the same time. That doesn't mean you can't call multiple ESQL procdures in different modules in different brokers schemas from within a single Main method.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kirank |
| Posted: Thu Nov 02, 2006 10:09 am Post subject: |
|
|
Centurion
Joined: 10 Oct 2002
Posts: 136
Location: California
|
Yes I know we can use Broker Schema to do something similar. But Broker schema is good for functions which can be reused.
We are planning to Develop some transformation code for multiple traget systems but same Message type. So if it was possible to have multiple ESQL files called from one compute we could develop code for One Target system and release it for Testing. Then create separate ESQL file for another target system and so on. That approach enables us to do parallel Development and Testing without having to touch the code that has been already tested. It can be done with multiple compute nodes but that is not good for performance reasons.
Thanks
Kiran |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Nov 02, 2006 10:29 am Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You're trying to be way too clever.
You're also trying to code for performance too soon.
Unless you're in the sub-microsecond response time frame, you won't notice the difference that adding another compute node will add.
Regardless, there's still no reason you can't do this in one compute node, with different procedures being called for each target system, and then put each procedure in it's own ESQL file.
The main procedure would then use some mechanism for calling the appropriate procedure based on input name.
Or you could do this using PROPAGATE TO LABEL.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
| kirank |
| Posted: Thu Nov 02, 2006 10:54 am Post subject: |
|
|
Centurion
Joined: 10 Oct 2002
Posts: 136
Location: California
|
Well we are kind of stuck with existing outdated hardware and have to watch performance closely. With multiple compute nodes it creates copies of the message and needs more memory for parsing those. The messages are high volume and large in Size (SAP Idocs) so I am trying to optimize the design as much possible.
I will see if calling procedures from multiple ESQL files in one compute works.
Thanks
Kiran |
|
| Back to top |
|
|
| kirank |
| Posted: Thu Nov 02, 2006 1:59 pm Post subject: |
|
|
Centurion
Joined: 10 Oct 2002
Posts: 136
Location: California
|
I tried calling procedures from different ESQL files but it does not work. In the ESQL file that is not attached to any compute node I can not access the Message Tree. I am assuming I can not pass Whole Message as variable to the procedure. Without the message tree I can not do the transformation so i guess the conclusion is I can't do transformations using multiple ESQL files and one compute node.
I am hoping this might work in Java compute node in 6.0 with Java being more object oriented.
Regards
Kiran |
|
| Back to top |
|
|
| jefflowrey |
| Posted: Thu Nov 02, 2006 2:23 pm Post subject: |
|
|
Grand Poobah
Joined: 16 Oct 2002
Posts: 19981
|
You have to pass InputRoot and OutputRoot as REFERENCES.
It entirely works to do this.
I have code running that is calling ESQL procedures from ESQL files in another project.
_________________
I am *not* the model of the modern major general. |
|
| Back to top |
|
|
|
|
