| |
|
RSS Feed - WebSphere MQ Support
|
RSS Feed - Message Broker Support
|
| Passing parameters to XSLT with XSLTransform Node in MB 7 |
« View previous topic :: View next topic » |
| Author |
Message
|
| DevNYC1 |
 Posted: Thu Sep 27, 2012 8:27 am Post subject: Passing parameters to XSLT with XSLTransform Node in MB 7 |
 |
|
Apprentice
Joined: 22 Aug 2012
Posts: 32
|
I would like to use the XSLTransform node in the Message Broker 7 environment to apply the XSL stylesheet to the XML retrieved from MQ.
I would like to pass the parameters (<xsl:param>) to the XSLT Stylesheet that would preferably be retrieved from a property file.
These are going to be the constant values that rarely change so I want to isolate them into a property file that if they do change there will not be a need to re-build/re-deploy the BARs/JARs.
I looked through the IBM docs and this forum but have not found any applicable examples. |
|
| Back to top |
|
 |
| mqjeff |
| Posted: Thu Sep 27, 2012 9:57 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
Most of what you would like to do is to use features of XSL where features of Broker are easier to use instead.
You've presumably paid money to use broker, and presumably paid more money to use Broker instead of just using an XSLT engine to perform your business transformations.
Why do you want to keep a parameters file for an XSL transform when you can modify User Defined Properties on a Bar file and access those from ESQL or Java or .NET or potentially even from XSLT (not sure on that one) instead?
Why do you want to use XSLT instead of using ESQL or Java or .NET? |
|
| Back to top |
|
|
| DevNYC1 |
| Posted: Fri Sep 28, 2012 6:59 am Post subject: |
|
|
Apprentice
Joined: 22 Aug 2012
Posts: 32
|
| mqjeff wrote: |
| You've presumably paid money to use broker, and presumably paid more money to use Broker instead of just using an XSLT engine to perform your business transformations |
Excellent point. However, it's not always that simple at the large companies where one group may have the license to use the Message Broker and other groups are encourage to use without incurring any additional fees. I did not choose to use the Message Broker. This is a choice that was made on a higher level. What I need to do is get a message from the MQ, apply certain transformation to it (mostly, adding constant values, additional static XML fields, etc.) and writing the resulting message to another MQ. I could just use a straight MQ program or Message Driven Bean, but have to use MB. Hence, this question.
| Quote: |
| Why do you want to keep a parameters file for an XSL transform when you can modify User Defined Properties on a Bar file and access those from ESQL or Java or .NET or potentially even from XSLT (not sure on that one) instead? Why do you want to use XSLT instead of using ESQL or Java or .NET? |
Since the transformation that I need to perform only involves XML processing, no database calls or calls to any APIs/business logic routines, XSLT seems a natural and simple choice to take one XML message and produce another without complicating the architecture (following the principle of "doing the simplest thing that works"). Also, IBM has a very good simple sample flow with the XSLTransform node that does exactly that. If I can pass the parameters to the XSLT stylesheet, that would solve my requirement. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Fri Sep 28, 2012 7:44 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
You've already been told not to to do the simplest thing that works - you've been told instead to use Broker.
The simplest way IN BROKER to transform one XML message to another is to use a Mapping node, not an XSLTransform node. No coding of any kind required!
The simplest way, IN BROKER, to handle externally configured parameters is to use User Defined Properties that are set on the message flow.
Having made that argument now twice, I'll not restate it again.
Presumably, there's some XSLT standard way of having properties files that you are having issues using with this <xsl:param> tag in your transform when running the transform within broker. So the first thing to do is verify the version of XSLT that Broker supports at the level you're using, and confirm that it supports the properties files in the way you're trying to use it.
If XSLT doesn't have a standard way of doing this, then you're stuck at the point of trying to use a Java Compute node to load the properties file, and then insert the relevant properties into the logical message tree where you can access them from your XLSTransform node, or just using Java to run the XSLT directly. |
|
| Back to top |
|
|
| mapa |
| Posted: Fri Sep 28, 2012 10:58 am Post subject: |
|
|
Master
Joined: 09 Aug 2001
Posts: 257
Location: Malmö, Sweden
|
Looking at the documentation it says that you can only access the XML payload in your XSLT.
Since the broker is using Apache Xalan-Java I guess you could (although I wouldn't do it myself) try to use Xalan-Java extensions.
Haven't used it for quite some time so don't remember the details.
http://xml.apache.org/xalan-j/extensions.html#ext-func-calls |
|
| Back to top |
|
|
| mqsiuser |
| Posted: Fri Sep 28, 2012 11:58 am Post subject: |
|
|
Yatiri
Joined: 15 Apr 2008
Posts: 637
Location: Germany
|
The most natural transformation (& processing) language for experienced broker users (and mqseries gurus) is the (ESQL) compute node. There are some simple rules and then ESQL is really handy.
When you use ESQL the decision (from above (to use Message Broker)) will likely make sense (probably later) to you.
Because other means to do transformation and message processing are quite superior to XSLT (in Broker) the support for XSLT is (imho) a bit neglected (e.g. the version of xalan isn't the latest, passing params in is not obvious how to or if possible at all).
XSLT is probably overused/overhyped ?! It lives of the web-hype ... but it does not scale (performance-wise). |
|
| Back to top |
|
|
| DevNYC1 |
| Posted: Mon Oct 01, 2012 6:19 am Post subject: |
|
|
Apprentice
Joined: 22 Aug 2012
Posts: 32
|
| mqjeff wrote: |
| The simplest way IN BROKER to transform one XML message to another is to use a Mapping node, not an XSLTransform node. No coding of any kind required! |
Understood. However, the downside as it seems to me (maybe because I am new to MB I don't see the whole picture) is that in this case we are tying ourselves to MB any if we need to any change in the mapping we would need to use the MB Toolkit to update the Message Set/mapping and re-test/re-deploy the updated BAR file. In addition, it is very easy to test XSLT outside of the MB environment. Also, everyone in our DEV team knows XSLT and understands it quite well, whereas we are new to the MB concepts. Therefore, using XSLT seems like a solution that is more flexible, easier to test and re-deploy any changes, and easier for us to develop as everyone here knows the technology and, therefore, it seems like a lower risk approach for our team. That is why I was hoping to take advantage of XSLT. Plus, we already have some XSLT we can re-use for these new flows.
| Quote: |
| The simplest way, IN BROKER, to handle externally configured parameters is to use User Defined Properties that are set on the message flow |
OK, thanks for this tip. I am reading about that option - it seems like a great one. But how do I access these properties in the XSL Transform node/XSLT?
| Quote: |
| If XSLT doesn't have a standard way of doing this, then you're stuck at the point of trying to use a Java Compute node to load the properties file, and then insert the relevant properties into the logical message tree where you can access them from your XLSTransform node |
Trying to understand how. Knowing that would help me a lot. |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Oct 01, 2012 6:45 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| DevNYC1 wrote: |
| mqjeff wrote: |
| The simplest way IN BROKER to transform one XML message to another is to use a Mapping node, not an XSLTransform node. No coding of any kind required! |
Understood. However, the downside as it seems to me (maybe because I am new to MB I don't see the whole picture) is that in this case we are tying ourselves to MB any if we need to any change in the mapping we would need to use the MB Toolkit to update the Message Set/mapping and re-test/re-deploy the updated BAR file. |
Again, that appears to be what you've been instructed to do. In part, presumably, to recoup the investment made in Broker.
| DevNYC1 wrote: |
| In addition, it is very easy to test XSLT outside of the MB environment. Also, everyone in our DEV team knows XSLT and understands it quite well, whereas we are new to the MB concepts. Therefore, using XSLT seems like a solution that is more flexible, easier to test and re-deploy any changes, and easier for us to develop as everyone here knows the technology and, therefore, it seems like a lower risk approach for our team. That is why I was hoping to take advantage of XSLT. Plus, we already have some XSLT we can re-use for these new flows. |
Yes, okay. Those are valid reasons.
But it may be more complicated in Broker than expected.
| DevNYC1 wrote: |
| Quote: |
| The simplest way, IN BROKER, to handle externally configured parameters is to use User Defined Properties that are set on the message flow |
OK, thanks for this tip. I am reading about that option - it seems like a great one. But how do I access these properties in the XSL Transform node/XSLT?
| Quote: |
| If XSLT doesn't have a standard way of doing this, then you're stuck at the point of trying to use a Java Compute node to load the properties file, and then insert the relevant properties into the logical message tree where you can access them from your XLSTransform node |
Trying to understand how. Knowing that would help me a lot. |
It seems like you will have to augment the message itself with additional tags that contain the property values. I don't see anything in the docs on accessing fields in LocalEnvironment or Environment with XSLT.
So you'll have to add fields to the XML document that contain the properties you're trying to use and then access those fields from your XSLT.
or, again, use a different transformation interface in Broker. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 01, 2012 7:21 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| DevNYC1 wrote: |
| However, the downside as it seems to me (maybe because I am new to MB I don't see the whole picture) is that in this case we are tying ourselves to MB any if we need to any change in the mapping we would need to use the MB Toolkit to update the Message Set/mapping and re-test/re-deploy the updated BAR file. |
Granted but someone in your organisation has made a very serious committment to WMB; it's not a cheap piece of software. This leads to 2 broad points: firstly, that kind of dollar spend indicates a committment typing you to WMB. It's unlikely your management will turn round in 12 months and say, "well, gosh, shouldn't have spent all that on IBM; let's just write Java".
Secondly, for that kind of spend someone is going to ask at some point what measurable return they're getting on their investment. A repsonse of "well we're just using it for XSLT like it's SAXON" is not likely to go over all that well. Embrace the new world order.
| DevNYC1 wrote: |
| In addition, it is very easy to test XSLT outside of the MB environment. Also, everyone in our DEV team knows XSLT and understands it quite well, whereas we are new to the MB concepts. Therefore, using XSLT seems like a solution that is more flexible, easier to test and re-deploy any changes, and easier for us to develop as everyone here knows the technology and, therefore, it seems like a lower risk approach for our team. That is why I was hoping to take advantage of XSLT. Plus, we already have some XSLT we can re-use for these new flows. |
I don't think it's invalid for you to utilize WMB's XSLT capabilities as a bridge, especially if you hav existing XSLT you don't want to convert to flows yet. That's a principle reason WMB has such support. That doesn't mean WMB doesn't have better ways to achieve what you can achieve with XSLT nor that you shouldn't be trying to embrace the new technolgy.
Or you should be pushing back and explaining that WMB is a risk for your team, not needed for the role it's been purchased for and is a lock in to a given technology. Maybe IBM will give a refund.
| DevNYC1 wrote: |
| how do I access these properties in the XSL Transform node/XSLT? |
AFAIK you don't, but don't take that as definitive. My understanding is that the XSLT node is intended for static XSLT that needs to run under WMB until it's converted to a flow. Trying to bend it to do more is likely to be a bigger risk than just learning WMB and doing it right.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| McueMart |
| Posted: Mon Oct 01, 2012 7:40 am Post subject: |
|
|
Chevalier
Joined: 29 Nov 2011
Posts: 490
Location: UK...somewhere
|
| Quote: |
| My understanding is that the XSLT node is intended for static XSLT that needs to run under WMB until it's converted to a flow. |
Im not exactly an XSLT whiz but wouldnt it be possible to:
- Use a JavaCompute/FileOutput node before the XSLTTransform node which dynamically created a new XSLT (based on a template XSLT). This new XSLT would have the variables which you require input into it.
- Use the LocalEnvironment to make the XSLTTransform node use your newly created XSLT.
Seems a bit long-winded though i'll give you that! |
|
| Back to top |
|
|
| mqjeff |
| Posted: Mon Oct 01, 2012 7:42 am Post subject: |
|
|
Grand Master
Joined: 25 Jun 2008
Posts: 17447
|
| McueMart wrote: |
but wouldnt it be possible to:
- Use a JavaCompute/FileOutput node before the XSLTTransform node which dynamically created a new XSLT (based on a template XSLT). This new XSLT would have the variables which you require input into it.
- Use the LocalEnvironment to make the XSLTTransform node use your newly created XSLT. |
Yes... this is possible. And you wouldn't even need the file output - the xsltransform node can use an xslt in the message.
But
| Quote: |
| Im not exactly an XSLT whiz |
so I wouldn't know *how* to build this dynamic xslt. |
|
| Back to top |
|
|
| Vitor |
| Posted: Mon Oct 01, 2012 7:58 am Post subject: |
|
|
Grand High Poobah
Joined: 11 Nov 2005
Posts: 26093
Location: Texas, USA
|
| McueMart wrote: |
Im not exactly an XSLT whiz but wouldnt it be possible to:
- Use a JavaCompute/FileOutput node before the XSLTTransform node which dynamically created a new XSLT (based on a template XSLT). This new XSLT would have the variables which you require input into it.
- Use the LocalEnvironment to make the XSLTTransform node use your newly created XSLT. |
Should be possible. I'd hate to try it, or support it if I got it working. 
| McueMart wrote: |
| Seems a bit long-winded though i'll give you that! |
Well exactly. You also compromise the OP's stated advantage of being able to test & develop XSLT outisde WMB. I also see this as the kind of "bending" I was talking about in my previous post. It's possible to do anything; how wise it is in terms of future development, maintability, support and obtaining value from the product is questionable.
Each "anything" of course needs to be questioned with it's own question, and evaluated in context.
_________________
Honesty is the best policy.
Insanity is the best defence. |
|
| Back to top |
|
|
| goffinf |
| Posted: Mon Oct 01, 2012 11:38 am Post subject: |
|
|
Chevalier
Joined: 05 Nov 2005
Posts: 401
|
| DevNYC1 wrote: |
| ... it is very easy to test XSLT outside of the MB environment. Also, everyone in our DEV team knows XSLT and understands it quite well, whereas we are new to the MB concepts. Therefore, using XSLT seems like a solution that is more flexible, easier to test and re-deploy any changes, and easier for us to develop as everyone here knows the technology and, therefore, it seems like a lower risk approach for our team. That is why I was hoping to take advantage of XSLT. Plus, we already have some XSLT we can re-use .... |
I have some sympathy with this position. Using XSLT, especially when you have existing expertise seems perfectly reasonable. Likewise the portability of the code can provide more flexibility in terms of deployment options. In my organisation we have a number of places where we can host XSLT (and Java) code .. Maybe you do too. I'm less convinced by the '.. what if wanted to stop using MB and use some other integration technology. As others have said MB is something your company has invested in and you really ought to be trying to leverage as much as possible from the product as you can IMHO.
Anyway back to XSLT. Many years ago we found the XSL Transformation node in Broker to be inadequate for our purposes. Not supporting global params was one of those areas. We also wanted to be able to use XSLT2 and own own URI resolvers. In the end we just built a custom node (Java) as a simple wrapper to the standard API (we used Saxon as the implementation because it is the most complete as far as the XSLT specs are concerned as well as being one of the fastest). It wasn't that hard (I implemented it and at best I would only consider myself an intermediate level Java guy), and it gives us access to the full power of XSLT, performance thru caching of compiled style sheets, global params, et al. Why not give it to one of your young and enthusiastic team members as a research project. I'll bet they have something functioning in no time. |
|
| Back to top |
|
|
| vmcgloin |
| Posted: Mon Oct 01, 2012 11:56 am Post subject: |
|
|
Knight
Joined: 04 Apr 2002
Posts: 560
Location: Scotland
|
| Vitor wrote: |
It's unlikely your management will turn round in 12 months and say, "well, gosh, shouldn't have spent all that on IBM; let's just write Java".
|
It happens... |
|
| Back to top |
|
|
| lancelotlinc |
| Posted: Mon Oct 01, 2012 12:05 pm Post subject: |
|
|
Jedi Knight
Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA
|
| vmcgloin wrote: |
| Vitor wrote: |
It's unlikely your management will turn round in 12 months and say, "well, gosh, shouldn't have spent all that on IBM; let's just write Java".
|
It happens... |
IBM expenditures represent much more value to the customer than just a language. It's like saying shouldn't have spent all that money paying a builder to build my house when I could build my house for just the cost of materials.
If you haven't read Geoffrey Moore's Crossing The Chasm book series yet, you really should. It explains in clear detail why Gorilla Market players are successful at being the dominant force. Companies like IBM, HP (which is used as an example in his series), Coca Cola, BP Amoco, Honda, Vizio, Sealy, Gerber, Hunter, Toshiba.
http://www.amazon.com/Crossing-Chasm-Marketing-Disruptive-Mainstream/dp/0060517123
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER |
|
| Back to top |
|
|
|
|
|
  |
Goto page 1, 2 Next |
Page 1 of 2 |
|
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
|
|
|
|
