| Author |
Message
|
| RocknRambo |
 Posted: Mon Sep 14, 2009 1:17 pm Post subject: Transformation options |
 |
|
Partisan
Joined: 24 Sep 2003
Posts: 355
|
What should be the preferred way for transformations in MB (Compute/ESQL, JCN/Java, MappingNode, XSLT, PHP)? I understand there were performance advantages on choosing ESQL to be the preferred. Is that still true?
IBM claims the mapping node in MB v7.0 has been refined/modified to match the performance with introduction of parser 'XMLNSC'. But, I always had a perception that using mapping nodes we have to create message sets which increases the LOE.
Can anyone share their experience in establishing a standard in an organization on using transformation nodes.
Thanks
-RR |
|
| Back to top |
|
 |
| fjb_saper |
| Posted: Mon Sep 14, 2009 1:30 pm Post subject: Re: Transformation options |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| RocknRambo wrote: |
What should be the preferred way for transformations in MB (Compute/ESQL, JCN/Java, MappingNode, XSLT, PHP)? I understand there were performance advantages on choosing ESQL to be the preferred. Is that still true?
IBM claims the mapping node in MB v7.0 has been refined/modified to match the performance with introduction of parser 'XMLNSC'. But, I always had a perception that using mapping nodes we have to create message sets which increases the LOE.
Can anyone share their experience in establishing a standard in an organization on using transformation nodes.
Thanks
-RR |
The main performance gain in ESQL was that it allowed you to work with REFERENCES and as such you were not forced to "walk the tree" for each assignment.... 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| RocknRambo |
| Posted: Mon Sep 14, 2009 1:41 pm Post subject: |
|
|
Partisan
Joined: 24 Sep 2003
Posts: 355
|
REFERENCES , you mean ESQL field references?. We are trying to establish standards in using MB especially development (code standards) as dev. team has consultants working for a particular period of time or project, we don't want everyone using their own transformation options based on their comfortness.
I might be too ambitious, will there be a doc from IBM or any article outlines the criteria to choose transformation nodes.
Thanks
-RR |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Sep 14, 2009 1:46 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| RocknRambo wrote: |
| REFERENCES , you mean ESQL field references?. |
Exactly what I am talking about... 
You can also write snippets of code, say transforming a particular msg header, package it into a procedure and put this into a broker schema.
You can then call this from which ever flow when needed and have to code it only once...
Have fun
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kimbert |
| Posted: Tue Sep 15, 2009 12:42 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| IBM claims the mapping node in MB v7.0 has been refined/modified to match the performance with introduction of parser 'XMLNSC'. But, I always had a perception that using mapping nodes we have to create message sets which increases the LOE. |
Is that really a direct quote from an IBM document? The facts are:
- XMLNSC was introduced in v6.0
- XMLNSC was rewritten with significant performance gains and major new functionality in v6.1
- XMLNSC has zero effect on mapping performance. XMLNSC is a parser. Mapping node is a transformation option. XMLNSC creates a message tree from an XML document. The Mapping node ( or ESQL, or Java, or PHP ) makes changes to a message tree.
| Quote: |
| The main performance gain in ESQL was that it allowed you to work with REFERENCES and as such you were not forced to "walk the tree" for each assignment |
If you are using a JavaCompute node, an instance of MbElement is exactly equivalent to an ESQL reference.
| Quote: |
You can also write snippets of code, say transforming a particular msg header, package it into a procedure and put this into a broker schema.
You can then call this from which ever flow when needed and have to code it only once |
In the Mapping node, you can create 'sub-maps' to do a similar trick. In Java, you can organise your classes/methods however you like to achieve good code structure.
| Quote: |
| But, I always had a perception that using mapping nodes we have to create message sets which increases the LOE. |
It is good practice to create message sets to describe your messages whether or not you deploy them. It makes your message flow easier to write ( you get content assist in ESQL ). It makes your message flow easier to maintain. It allows you to validate your input/output messages if you need to. What I'm trying to say is, 'don't avoid creating message sets'.
There are certain features which are only available in ESQL ( mostly relating to ASBITSTREAM and CREATE...PARSE ). Don't make the decision on performance alone - Java and ESQL are roughly equivalent.
If you choose Java, make sure you know why you are choosing it. It's quite easy to write poor transformation logic using a JavaCompute node.
( mind you, same's true of ESQL or any other language ). |
|
| Back to top |
|
|
| Gaya3 |
| Posted: Tue Sep 15, 2009 1:12 am Post subject: |
|
|
Jedi
Joined: 12 Sep 2006
Posts: 2493
Location: Boston, US
|
kimbert, thanks for sharing this info,
_________________
Regards
Gayathri
-----------------------------------------------
Do Something Before you Die |
|
| Back to top |
|
|
| rbicheno |
| Posted: Tue Sep 15, 2009 11:21 am Post subject: |
|
|
Apprentice
Joined: 07 Jul 2009
Posts: 43
|
|
| Back to top |
|
|
| RocknRambo |
| Posted: Thu Oct 29, 2009 12:46 pm Post subject: |
|
|
Partisan
Joined: 24 Sep 2003
Posts: 355
|
We are down to using either ESQL or Mapping Node.
we are trying not to narrow down the developer options but at the same time come up with standards based on some criteria. Can any share what could be the criteria for choosing mapping node over ESQL or vice versa.
The need for using 'ASBITSTREAM and CREATE...PARSE' is the criteria to choose ESQL. |
|
| Back to top |
|
|
| kimbert |
| Posted: Thu Oct 29, 2009 3:07 pm Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Why does it have to be Mapping node *or* ESQL? Why not using Mapping node for the simple stuff, and ESQL when you need the power? |
|
| Back to top |
|
|
| RocknRambo |
| Posted: Thu Oct 29, 2009 4:17 pm Post subject: |
|
|
Partisan
Joined: 24 Sep 2003
Posts: 355
|
I like the approach of hybrid option. In order for us to put up standards for the same, we need to come criteria or requirement scenario.
Can you pls. elaborate "when you need the power?" like what kind?
Thanks for your response.
-RR |
|
| Back to top |
|
|
| sirsi |
| Posted: Fri Oct 30, 2009 1:50 am Post subject: |
|
|
Disciple
Joined: 11 Mar 2005
Posts: 177
|
you will need compute node for complex transformations(applying complex business logic for transformations)...
use mapping node for simple mappings between input-output tree, like if the requirement is to map using simple transformations like substring, cast etc etc
it comes down to you to decide what to use... if u still cant figure out... try a POC with both mapping and compute node |
|
| Back to top |
|
|
| kimbert |
| Posted: Fri Oct 30, 2009 4:19 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| In order for us to put up standards for the same, we need to come criteria or requirement scenario. |
I advise you to lower your expectations. You cannot make simple rules about software development. You can issue guidelines, and ask developers to justify their decisions.
My advice - let the developers decide what the criteria are, and then docment them. Make sure that they are flexible, though. |
|
| Back to top |
|
|
|
|
