MQSeries.net :: View topic - XML to XML Mapping not available in MB7 toolkit

MQSeries.net

Tech Exchange

Education

Certifications

Library

Info Center

SupportPacs

FAQÂ Â

Usergroups

RSS Feed - WebSphere MQ Support

RSS Feed - Message Broker Support

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » XML to XML Mapping not available in MB7 toolkit

Goto page 1, 2 Next

XML to XML Mapping not available in MB7 toolkit

« View previous topic :: View next topic »

Author

Message

shalabh1976

Posted: Sun Feb 12, 2012 9:38 pm Post subject: XML to XML Mapping not available in MB7 toolkit

Partisan

Joined: 18 Jul 2002
Posts: 381
Location: Gurgaon, India

I am using Websphere Message Broker Toolkit
Version: 7.0.0
Build id: 7.0.0-20091028_2100

I have a requirement of creating XSL using source and destination XMLs.
I am not getting the XML to XML mapping option in the New Wizard.
This option was present in the version MB6 toolkit.

Please help me where to look, or if I need to get some additional plugin for it.
_________________
Shalabh
IBM Cert. WMB V6.0
IBM Cert. MQ V5.3 App. Prog.
IBM Cert. DB2 9 DB Associate

mqjeff

Posted: Mon Feb 13, 2012 2:31 am Post subject:

Grand Master

Joined: 25 Jun 2008
Posts: 17447

The feature you are looking for is not strictly part of the Broker Toolkit.

It is strictly part of RAD/WID, that happened to be included with Toolkit.

There are preferences that can somewhat control what features of the installed environment are active in Toolkit v7. Go to the Preferences and look around.

It's also possible that this particular function is no longer included with Toolkit, as part of the effort to reduce the installation footprint of Toolkit.

mqsiuser

Posted: Mon Feb 13, 2012 3:33 am Post subject: Re: XML to XML Mapping not available in MB7 toolkit

Yatiri

Joined: 15 Apr 2008
Posts: 637
Location: Germany

shalabh1976 wrote:

I have a requirement of creating XSL using source and destination XMLs.

It is emerging as general knowledge currently that XSL is a relatively slow alternative compared to other transformation technologies. Usually people talk about ... "XSL(T) is a factor {3, ..., 50} slower than this and that method". Note that it is slower, even if you do things properly (e.g. not accessing/searching elements with "//..." all the time, which would totally waist your performance).

XSL was design for "convenient" client-side transformation (in a browser) and not for high-speed (server-side) transformations. You should consider this and probably use (proper!) ESQL (or Java) code instead. Question you requirements. Ofc. there are reasons to still use XSLT is some scenarios.
_________________
Just use REFERENCEs

lancelotlinc

Posted: Mon Feb 13, 2012 5:49 am Post subject: Re: XML to XML Mapping not available in MB7 toolkit

Jedi Knight

Joined: 22 Mar 2010
Posts: 4941
Location: Bloomington, IL USA

shalabh1976 wrote:

You should be on a more modern version of v7. Update your toolkit and runtime. Current version is 7.0.0.3 IFix 2.
_________________
http://leanpub.com/IIB_Tips_and_Tricks
Save $20: Coupon Code: MQSERIES_READER

goffinf

Posted: Sat Feb 18, 2012 11:05 am Post subject: Re: XML to XML Mapping not available in MB7 toolkit

Chevalier

Joined: 05 Nov 2005
Posts: 401

mqsiuser wrote:

It is emerging as general knowledge currently that XSL is a relatively slow alternative compared to other transformation technologies. Ofc. there are reasons to still use XSLT is some scenarios.

Sorry but these sorts of unsubstantiated generalisations are pretty unhelpful and often misleading. Perhaps you would care to provide some concrete examples, and then I'll counter with other that show the reverse. My point being that the performance characteristics obtained vary from situation to situation and the choice of implementation technology is only one factor. Often raw performance isn't the most important consideration.

I didn't notice that the OP mentioned anything about performance, they simply asked where they could find the XML Mapping Editor.

mqsiuser

Posted: Sat Feb 18, 2012 12:22 pm Post subject: Re: XML to XML Mapping not available in MB7 toolkit

Yatiri

Joined: 15 Apr 2008
Posts: 637
Location: Germany

goffinf wrote:

I didn't notice that the OP mentioned anything about performance, they simply asked where they could find the XML Mapping Editor.

There should be a separate thread "XSLT v.s. ESQL" or "XSL(T) performance" or even much better than that "reference-tree-walking v.s. declarative" in this forum.

goffinf wrote:

Perhaps you would care to provide some concrete examples, and then I'll counter with other that show the reverse.

Here is a good article. Though it is not XSLT v.s. ESQL it is xPath v.s. tree-walking, which is somewhat close I think:

Quote:

running over the entire tree, testing each node for what it is you're looking for. Code gets a little uglier [...], it's not as elegant/clean, but performance starts kicking in when you do it. Moving from xpath search-style parsing, to tree walking yielded ~3x performance improvement in parsing for me.

running over the entire tree ... thats what you do when using references (in e.g. ESQL) (hopefully) and then the disadvantages in bold. Note these are the disadvantages of walking the tree! ... but as a result "performance starts kicking in when you do it".

Note that xPath is a key-technology within XSLT. Though there are also issues with "template match" (imho!), which is pure XSLT. XSLT/XPATH are both declarative which removes the control from the developer, especially the control over when expensive parsing(/operations) occur(s).

search style parsing is the death of performance.

goffinf wrote:

Often raw performance isn't the most important consideration.

Fully agreed, as I write "Ofc. there are reasons to still use XSLT in some scenarios."

stackoverflow.com wrote:

You will get performance issues if you use complex xpath expressions. Avoid "//" in your xpath expressions since every node of your input document will be evaluated.

Do I have just less performance issues if my xPath expressions are simpler ?

XSLT/xPath is influenced by paradigms used for html (and DOM manipulation): It's influenced from the ideas that the W3C had for convenient DOM (HTML) manipulation and not performant XML transformation. That is: You can select all nodes (from the "document"(HTML/DOM or XML)) with "this and that characteristic" and apply something to them. That might be convenient for HTML pages (and also for creating HTML-pages from XML), but it is (imho(!)) not fitting to nor performant(!) for XML (to XML) transformation.

Note that with Factor 3 my example is at the lower end of {3...50}: He only uses xPath not even XSLT (e.g. "template match").
_________________
Just use REFERENCEs

goffinf

Posted: Sun Feb 19, 2012 6:11 am Post subject:

Chevalier

Joined: 05 Nov 2005
Posts: 401

Well once again those are just examples for specific use cases and each use case differs. As for issues with template matching, I very much doubt it !

XSLT has moved a VERY long way from it's origins as a client side technology !

Keep in mind that recursive descent represents only one approach when using XSLT, if you need more control there are others which give you that and again have different non functional characteristics.

Similarly DOM is but one API that is available. There are circumstances in which this can yield impressive performance but in many cases a streaming approach is much more likely to do so especially when considering resources other than CPU such as memory use.

Then there's all the optimisations that are available such as cached compiled templates, reuse of transformers, yadda, yadda I could go. We can add XSLT2 and XPath2 and more recently XSLT3 as well as the specific optimisations available with the XSLT processor you care to use (S9 for example).

So as with anything else in software engineering, there are lots of variants to our choice of implementation technology that go way beyond the 'out of the box' basics.

That said, I'm a believer in using the functionality provided by higher level tools like Broker unless there's a good reason not too, so I would typically follow a path that suggests that early optimisation is something that shouldn't come into play until there is evidence that it is needed. Most times in my experience, Broker performs well enough without additional tweaks, but then again I'm not working on solution designs for the Stock Exchange or Google, so YMMV.

You're right though, if you want a reasoned debate about the merits and challenges of different transformation technologies then by all means start a new thread.

Regards

Fraser.

mqsiuser

Posted: Mon Feb 20, 2012 7:02 pm Post subject:

Yatiri

Joined: 15 Apr 2008
Posts: 637
Location: Germany

I honor deep thought, I do not want high level discussions about transf. technology (e.g. about nodes).

Note that it has been an achievement for the DOM to have this "Select all, apply to all" style (why hasn't it been there from the beginning?). There has been a time where there only was "get element by id" (dude, what's wrong with your API) and not "select (and apply to) all (this and that)".

Note that before I finish this post, XSLT will be (somewhat) dead for systems integration (then I will save it with the last 2 sentences). The truth is you are styling your xml with XSLT and not transforming it. You cannot fully decouple input from output structure with XSLT. The output-structure is created too strongly based on the input structure (by applying pattern-matching)! With ESQL you can (properly) decouple input from output structure. You can do this (at least somewhat) in the Environment-tree (also see "aggregate() compared with other approaches")! This is (somewhat easily) possible because ESQL is an imperative (reference-handling) programming language. With a utility function you can (then) decouple to the full extend (other methods may also apply).

Java-Scripting frameworks wrap the DOM-Navigation/Accessing-API, (also) because of its weaknesses. Then what happens: When using them you need to be cautious not to use wrong statement(s) (to not hog performance... though: This happens in the Browser!). Note that my ESQL-Scripting framework wraps the ESQL-Navigation-API because of ESQL's actual strengths. That is: ESQL provides the proper (very) basic functions to build anything more complex that you need on top of it. ESQL actually often does not provide higher-level abstractions. The motto (probably) is: Better not provide (do it yourself!) than to lock you into something (potentially wrong).

Though you are right, that there is ongoing investment in W3C standards, which probably change everything. Some decision cannot be changed though, e.g. I think you need to have at least imperative control to achieve certain transformation (with a reasonable performance).
_________________
Just use REFERENCEs

rekarm01

Posted: Tue Feb 28, 2012 1:47 am Post subject: Re: XML to XML Mapping not available in MB7 toolkit

Grand Master

Joined: 25 Jun 2008
Posts: 1415

mqsiuser wrote:

Here is a good article. Though it is not XSLT v.s. ESQL it is xPath v.s. tree-walking, which is somewhat close I think:

Quote:

It's a rather short article. Nokogiri seems to use a SAX-style parser. That explains why the author is trying anything to avoid XPath. One important difference between DOM-style parsers and SAX-style parsers:

DOM: Elements that are already parsed are not reparsed.
SAX: Many elements can be reparsed every time one element is accessed.

SAX is not well-suited for the random-access nature of XPath/XSLT, which explains why ...

mqsiuser wrote:

... search style parsing is the death of performance.

Fortunately, this is not so much of an issue for the broker; the XSL Transform node (and Java MbXPath) use the underlying broker parsers and message trees, so the performance difference between XSLT and equivalent ESQL may be negligible.

mqsiuser wrote:

Note that xPath is a key-technology within XSLT. Though there are also issues with "template match" (imho!), which is pure XSLT. XSLT/XPATH are both declarative which removes the control from the developer, especially the control over when expensive parsing(/operations) occur(s).

Declarative vs. imperative makes no difference. The developer has at least as much control navigating the message tree with XPath and XSLT, as it does with ESQL.

mqsiuser wrote:

You cannot fully decouple input from output structure with XSLT. The output-structure is created too strongly based on the input structure (by applying pattern-matching)!

XSLT can fully decouple input from output; the output structure need not be related in any way to the input structure.

kimbert

Posted: Tue Feb 28, 2012 1:57 am Post subject:

Jedi Council

Joined: 29 Jul 2003
Posts: 5542
Location: Southampton

I agree with almost all of that. Let's not mislead people by making inaccurate statements about transformation languages.

Being very picky now...there are XPath and XSLT processors that use a SAX-style parser under the covers and *still* manage to avoid lots of re-parsing. In order to do that, they cache some of the parsed data internally. Before rekarm01 points it out, this is equivalent to building a partial DOM tree - but more efficient because the internal data structures are purpose-built for the task.

mqsiuser

Posted: Tue Feb 28, 2012 3:25 am Post subject:

Yatiri

Joined: 15 Apr 2008
Posts: 637
Location: Germany

rekarm01 wrote:

XSLT can fully decouple input from output; the output structure need not be related in any way to the input structure.

I have relativly simple sample xmls that are transformed into another xml (the examples are from SAP-Systems integration, so they are from the real world!). How to do them in XSLT ?

1. Single hierarchy aggregation (probably/likely possible with XSLT 2.0)
2. Multi hierarchy aggregation - probably possible with concatenating several (>= 2) XSLTs (and XSLT 2.0) !?
3. Composite criteria aggregation (probably/likely possible with XSLT 2.0)

These are basically just the (3) simplest examples I could think of. More complex examples can be (easily) added:

4. Multi hierarchy aggregation with dependencies (from the sub-level(s) to the super-level(s))
5. Combinations of 2. (/4.) and 3.
6. Combinations of 2. (/4.) and 3. for multiple (differently structured) messages (one ESQL-Node / (one) XSLT)
_________________
Just use REFERENCEs

rekarm01

Posted: Thu Mar 01, 2012 5:38 pm Post subject:

Grand Master

Joined: 25 Jun 2008
Posts: 1415

mqsiuser wrote:

I have relativly simple sample xmls that are transformed into another xml ... How to do them in XSLT ?

1. Single hierarchy aggregation ...
2. Multi hierarchy aggregation ...
3. Composite criteria aggregation ...

How are these examples of decoupling the output message from the input message? Please clarify what "decoupling" means, in this context.

Here's a much simpler example where the output is not related to the input:

Code:

<xsl:stylesheet version="1.0" xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:template match="/">
<xml><greeting>Hello, world.</greeting></xml>
</xsl:template>
</xsl:stylesheet>

mqsiuser

Posted: Fri Mar 02, 2012 6:36 am Post subject:

Yatiri

Joined: 15 Apr 2008
Posts: 637
Location: Germany

rekarm01 wrote:

Please clarify what "decoupling" means, in this context.

decoupling is defined by the capabilities of the aggregate() method

rekarm01 wrote:

Here's a much simpler example where the output is not related to the input.

it's not about giving a single example, it's about showing the full capabilities.

The first example (of the 3) is just an easy getting started example. The second and third are of actual interest (and also define the meaning of decoupling). Now one (of the two) is (likely) possible. The other has to do with accessing the upper (message-)tree while being on sub(-ordinate) levels.

There are variables in XSLT but are there also something like pointers (that can be accessed "later") to retrieve/access complex content (hopefully without making any copies of data) !?

That's been really missing for me, when I used XSLT and xPath (both in version 1.0). I think they did put additions into XPATH 2.0 and call it "parent", "ancestor", "reverseAxis" and "RelativePathExpr"... (needing) to walk up the tree is not a good idea... you should really just keep references (of parents) (which were declared&set previously) and use them to navigate down (only). So references/pointers are missing (in XSLT) ?!

To clarify: I am not missing any memory-pointers and/or also not pointers to somewhere on the internet (like xPointer), but references (as in ESQL), or MBElement (as in Broker's Java). Note that likely the terminology for the W3C will be "pointer". So I am missing pointers WITHIN the message, which (probably) can be moved around (ups... probably not possible with "declarative") and that do not make (deep) copies. If you wonder "what the heck is he talking about", then look a properly coded ESQL code (likely also Java code) and the relevance (of (these certain type of) "pointers") may get more apparent.

Note that with xPath you will likely have "problems in addressing namespace nodes".

The w3c worked for more than 5 years on XSLT 2.0... either they got it right now (for using it in browsers) or it is really complex (likely both applies somewhat)....

Standard first is good and necessary for the browser(vendors), but implementation first can have better results (for server-side message transformation).

And imperative v.s. declarative... there is much more to it than "oh, you have to just think different": With declarative you are loosing the control over the on-demand-parsing and even more importantly: Treewalking (on parsed content). There will likely be much more tree-walking within the (lot of) declarative statements used, than if you'd had imperative (low level) control (that e.g. ESQL gives you).

Note that anything declarative will be executed imperativly (on the chip). Declarative is just an abstraction layer on top of imperative.

rekarm01

Posted: Sat Mar 24, 2012 5:15 pm Post subject: Re: XML to XML Mapping not available in MB7 toolkit

Grand Master

Joined: 25 Jun 2008
Posts: 1415

A more common use for the XSL Transform node is to reuse existing stylesheets, rather than write new ESQL. It's unusual to try to port existing ESQL to XSLT; ESQL targets the broker platform specifically, so it's often a better fit for the broker than XSLT would be.

mqsiuser wrote:

it's not about giving a single example, it's about showing the full capabilities ... The first example (of the 3) is just an easy getting started example. The second and third are of actual interest (and also define the meaning of decoupling). Now one (of the two) is (likely) possible. The other has to do with accessing the upper (message-)tree while being on sub(-ordinate) levels.

Wasn't it about performance? Where the languages have like capabilities (or use the same underlying broker components, such as parser or message tree), they can have comparable performance. Where one language has to emulate the capabilities of the other, that can impact performance. As the many links in the preceding post illustrate, there are plenty of forums well-suited for showing the full capabilities of XLST; these examples all appear to be variations of grouping, which even XSLT 1.0 can handle.

mqsiuser wrote:

There are variables in XSLT but are there also something like pointers (that can be accessed "later") to retrieve/access complex content (hopefully without making any copies of data) !? ... So references/pointers are missing (in XSLT) ?!

xsl:variables can bind to XPath node-sets (or node sequences), to retrieve/access complex content "later", without making any copies of data. What seemed to be missing was a built-in capability for generating node-sets from result tree fragments (i.e copies of data), and that's because result tree fragments are serialized, (not parsed). But implementations typically have an extension function to provide that capability, and XSLT 2.0 no longer uses result tree fragments.

mqsiuser wrote:

I think they did put additions into XPATH 2.0 and call it "parent", "ancestor", "reverseAxis" and "RelativePathExpr" ... Note that with xPath you will likely have "problems in addressing namespace nodes".

That's not new. XPath 1.0 has the same axes and similar relative location paths. XSLT does not support applying templates to namespaces nodes, but XPath has no problems addressing them.

mqsiuser wrote:

And imperative v.s. declarative... there is much more to it than "oh, you have to just think different": With declarative you are loosing the control over the on-demand-parsing and even more importantly: Treewalking (on parsed content). There will likely be much more tree-walking within the (lot of) declarative statements used, than if you'd had imperative (low level) control (that e.g. ESQL gives you).

Any differences in performance have more to do with the differences in the built-in capabilities or the quality of implementation, and not so much whether it's imperative or declarative; (compare MQSI v2.0 ESQL with WMB v8.0 ESQL, both imperative, or XSLT v1.0 with XSLT v2.0, both declarative). ESQL does not offer direct control of on-demand parsing - the parser does that. ESQL only offers indirect control, by either accessing or not accessing unparsed elements. The same is true for XSLT; the developer still has complete control over which nodes get applied to which templates. If XSLT is in fact forcing on-demand parsing by accessing more elements than it needs to, one way around that is to pass only the subset of the message tree that's relevant, and use a compute node to merge the result tree with the output. This is a common technique for handling large messages anyway, with or without XSLT. Both XSLT and ESQL can do an awful lot of "tree-walking" on parsed content, but ESQL developers don't usually worry about it, unless there are subscripts involved. For example:

Code:

SET OutputRoot = InputRoot;
SET OutputRoot.XMLNSC.Data.Employee.FirstName = UPPER(InputRoot.XMLNSC.Data.Employee.FirstName);
SET OutputRoot.XMLNSC.Data.Employee.LastName = UPPER(InputRoot.XMLNSC.Data.Employee.LastName);

Every fully-qualified ESQL reference has to traipse through the message tree, from the root element, through every previous sibling of every named element, until it finds the element of interest. The three lines of ESQL above traverse from the root through the children of "Employee" at least two or three times, for both the InputRoot and the OutputRoot message trees.

Try rewriting the above ESQL to make one pass through the message trees, using only reference variables with MOVE(), instead of using "." with named elements, and it should become apparent why developers don't usually bother. The resulting code is a lot harder to write, a lot harder to read, a lot harder to debug, and it's not clear that it ultimately performs any better.

mqsiuser

Posted: Sat Mar 24, 2012 9:40 pm Post subject: Re: XML to XML Mapping not available in MB7 toolkit

Yatiri

Joined: 15 Apr 2008
Posts: 637
Location: Germany

shalabh1976 wrote:

I have a requirement of creating XSL using source and destination XMLs.
I am not getting the XML to XML mapping option in the New Wizard.
This option was present in the version MB6 toolkit.

rekarm01 wrote:

A more common use for the XSL Transform node is to reuse existing stylesheets[...] ESQL targets the broker platform specifically, so it's often a better fit for the broker than XSLT would be.

I thought IBM has removed this option intentionally, because people might think that the natural choice for XML to XML mapping (within Broker) is using XSLT... which we all (technical people) agree is not... you know there also is management and it is easy to think that you shouldn't "program" (imperative) you interfaces, but just "state" (declarative) you mapping... I think that is wrong and it can be really annoying (for technical people).

The complexities of the language (language definition + all subsequent workarounds to that

) contribute to a better or worse performance.

On the capabilities: Is XSLT able to do a stable grouping ? (deterministic and great for traceability)

I would write your ESQL like that:

Code:

SET OutputRoot = InputRoot;
DECLARE refOut REFERENCE TO OutputRoot.XMLNSC.Data.Employee;
SET refOut.FirstName = UPPER(refOut.FirstName);
SET refOut.LastName = UPPER(refOut.LastName);

Note that I also argue that you should (or at least be able to) have a single mapping node only so that there should be no need for doing anything on the (parsed-out) result tree.

And... the awful lot of "tree walking" is backed by computer science computational complexity theory (or at least I try to, probably I might miss something), so it should be the "least amount of tree walking" possible.
_________________
Just use REFERENCEs

Display posts from previous:

Goto page 1, 2 Next

Page 1 of 2

MQSeries.net Forum Index » WebSphere Message Broker (ACE) Support » XML to XML Mapping not available in MB7 toolkit

Jump to:

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

Protected by Anti-Spam ACP