| Author |
Message
|
| brusha |
 Posted: Sun Dec 12, 2010 11:41 am Post subject: XSLTransform vs Mapping |
 |
|
Newbie
Joined: 12 Dec 2010
Posts: 5
|
Dear Forum members,
First of all, I'm sorry for possible newbie question. I'm new to Message Broker and now I have to do my first project using it without any formal training, just using online documentation and samples...
Anyway, the problem is that I need to perform some basic XML transformation. As my tests have shown, it is possible to do it using both XSLTransform node and Mapping node. What is preferred method? I.e. what would work better (faster) in production environment? If there is some kind of related best practice guide, it would be highly appreciated if someone provide me with the link.
I've tried to search through this forum, but "XSLTransform" search query returns just a few results...
Thanks in advance.
Cheers! |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Sun Dec 12, 2010 1:54 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
The best practice is to use ESQL, not Mapping or XSLT.
But since you don't have any training, use Mapping.
UNLESS you have training in XSLT. |
|
| Back to top |
|
|
| brusha |
| Posted: Sun Dec 12, 2010 2:14 pm Post subject: |
|
|
Newbie
Joined: 12 Dec 2010
Posts: 5
|
Well, indeed I have training with XSLT, but as it appears, mapping is not the rocket science either.
As for the ESQL, weird enough (?), but our WebSphere guys (IBM certified) prefer Mapping nodes over ESQL nodes. They say that performance is better and the flow is clearer to understand and, if it would be necessary in future, to change. Is it really the best practice to use ESQL? Would you be so kind to give a link to some related IBM document/article/whatever? |
|
| Back to top |
|
|
| mqjeff |
| Posted: Sun Dec 12, 2010 2:44 pm Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Performance is not better.
Performance is close, but not better. Map nodes are internally compiled *into* ESQL.
Mapping is easier to understand for people who are not programmers.
All of the comparisons you will find on line will say that Mapping, JCN, XSLT, PHP and ESQl are "comparable", and that the best practice is to use the one that you are most familiar with.
But fundamentally, ESQL is going to provide the most straightforward and direct expression of the transformations that are being performed compared to the other options, and can handle transformations that are significantly more complex than Mapping can handle.
At least in my opinion. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Sun Dec 12, 2010 11:05 pm Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
 I don't work for IBM and I'll second that. 
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| kimbert |
| Posted: Mon Dec 13, 2010 2:29 am Post subject: |
|
|
Jedi Council
Joined: 29 Jul 2003
Posts: 5542
Location: Southampton
|
| Quote: |
| what would work better (faster) |
IBM's advice on choosing a mapping language has been consistent for years now - understand your requirements, and choose the one that fits *your* requirements best. For most projects/sites, 'better' involves a lot more than just 'faster'. It includes maintainability, speed of development, serviceability - all the usual 'non-functional requirements'.
If performance is the most important thing for your project, then you need to test ESQL and XSLT and find out which it faster on your hardware, for your flows. Sometimes an XSLT transform is faster than the equivalent ESQL. |
|
| Back to top |
|
|
| brusha |
| Posted: Mon Dec 13, 2010 2:36 am Post subject: |
|
|
Newbie
Joined: 12 Dec 2010
Posts: 5
|
Thank you, kind sirs  |
|
| Back to top |
|
|
| joebuckeye |
| Posted: Mon Dec 13, 2010 5:48 am Post subject: |
|
|
Partisan
Joined: 24 Aug 2007
Posts: 365
Location: Columbus, OH
|
| Quote: |
| IBM's advice on choosing a mapping language has been consistent for years now - understand your requirements, and choose the one that fits *your* requirements best. For most projects/sites, 'better' involves a lot more than just 'faster'. It includes maintainability, speed of development, serviceability - all the usual 'non-functional requirements'. |
You don't understand how this drives our architects crazy. They want a 'playbook' that will tell them which transformation method works best for various situations.
Even though we had Anthony (main IBM WMB architect) tell us the above over a year ago.
As for me, I prefer to use ESQL for the reasons Jeff mentioned. We used to use Mapping nodes but when we moved from v5 to v6 the migration tools were not able to migrate our maps from v5 to v6 so we took the opportunity to change them to ESQL instead. |
|
| Back to top |
|
|
| fjb_saper |
| Posted: Mon Dec 13, 2010 5:57 am Post subject: |
|
|
Grand High Poobah
Joined: 18 Nov 2003
Posts: 20756
Location: LI,NY
|
| joebuckeye wrote: |
You don't understand how this drives our architects crazy. They want a 'playbook' that will tell them which transformation method works best for various situations.
Even though we had Anthony (main IBM WMB architect) tell us the above over a year ago.
As for me, I prefer to use ESQL for the reasons Jeff mentioned. We used to use Mapping nodes but when we moved from v5 to v6 the migration tools were not able to migrate our maps from v5 to v6 so we took the opportunity to change them to ESQL instead. |
Well I would have expected your architects to be a little bit more flexible:
Derive a standard, and then produce a procedure (with justifications) allowing you to deviate from the standard.... That should have you covered...
_________________
MQ & Broker admin |
|
| Back to top |
|
|
| pavan343 |
| Posted: Fri Dec 17, 2010 1:37 am Post subject: |
|
|
Novice
Joined: 17 Dec 2010
Posts: 13
|
| i dont know abt the performance factor but it is easier to develop xsl(i.e if you know xsl well) than using esql .having said that there are few limitations in using xsl. |
|
| Back to top |
|
|
|
|
