|
Home > Archive > BizTalk Server General > December 2005 > reordering elements before processing
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
reordering elements before processing
|
|
|
|
I would trying to reorder the elements of an xml document before processing
them in an orchestration. I tried to solvew this using my own xslt in a map,
and used the map in a transform shape and also in a receive port. In both
cases, the elements in the xml document are processed in the original order.
I'm not certain, but I now believe my problem is due to the fact that is the
incoming xml is passed as a byte stream and thus cannot be reordered via an
xsl transform.
Does anyone have any thoughts on this and advise on how I can accomplish
this? Could I do this using a custom pipeline component to reorder the xml
before it enters the orchestration?
Thanks in advance.
Jim.
| |
| Samuel L 2005-12-21, 2:49 am |
| Hi Jim!
> I'm not certain, but I now believe my problem is due to the fact that is the
> incoming xml is passed as a byte stream and thus cannot be reordered via an
> xsl transform.
I don't really see why this would be the case!?! Could you please explain
further?
If this would have been the case I think the transform shape would have
failed.
What does your custom XSLT look like? Have you tested it and seen that it
works?
"Jim M" wrote:
>
> I would trying to reorder the elements of an xml document before processing
> them in an orchestration. I tried to solvew this using my own xslt in a map,
> and used the map in a transform shape and also in a receive port. In both
> cases, the elements in the xml document are processed in the original order.
>
> I'm not certain, but I now believe my problem is due to the fact that is the
> incoming xml is passed as a byte stream and thus cannot be reordered via an
> xsl transform.
>
> Does anyone have any thoughts on this and advise on how I can accomplish
> this? Could I do this using a custom pipeline component to reorder the xml
> before it enters the orchestration?
>
> Thanks in advance.
>
> Jim.
| |
|
| Hi Samuel,
Yes. my xslt xcript is rather simple, and works fine in XMLSPY, and using
the XML/XSL namespace classes in .NET.
The script is shown below along with an XML sample.
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl:output omit-xml-declaration="yes" version="1.0" method="xml"/>
<xsl:template match="/">
<ITEM>
<xsl:apply-templates select="/*[local-name()='ITEM' and
namespace-uri()='']"/>
</ITEM`>
</xsl:template>
<xsl:template match="/*[local-name()='ITEM' and namespace-uri()='']">
<xsl:copy-of select="*[local-name()='A']"/>
<xsl:copy-of select="*[local-name()='B']"/>
<xsl:copy-of select="*[local-name()='C']"/>
</xsl:template>
</xsl:stylesheet>
XML before:
<ITEM>
<A/>
<C/>
<B/>
<C/>
<A/>
</ITEM>
after
<ITEM>
<A/>
<A/>
<B/>
<B/>
<C/>
</ITEM>
--
Jim
"Samuel L" wrote:
[vbcol=seagreen]
> Hi Jim!
>
> I don't really see why this would be the case!?! Could you please explain
> further?
> If this would have been the case I think the transform shape would have
> failed.
>
> What does your custom XSLT look like? Have you tested it and seen that it
> works?
>
>
> "Jim M" wrote:
>
| |
| Samuel L 2005-12-21, 7:55 am |
|
Hrm.. This seems weird... It works for me when I test it in the BizTalk
mapper.
What do you mean when say that "the elements in the xml document are
processed in the original order"? How are the elements processed in the
orchestration? Maybe there is something wrong here instead of in the mapping?
"Jim M" wrote:
[vbcol=seagreen]
> Hi Samuel,
>
> Yes. my xslt xcript is rather simple, and works fine in XMLSPY, and using
> the XML/XSL namespace classes in .NET.
>
> The script is shown below along with an XML sample.
>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> version="1.0">
> <xsl:output omit-xml-declaration="yes" version="1.0" method="xml"/>
> <xsl:template match="/">
> <ITEM>
> <xsl:apply-templates select="/*[local-name()='ITEM' and
> namespace-uri()='']"/>
> </ITEM`>
> </xsl:template>
> <xsl:template match="/*[local-name()='ITEM' and namespace-uri()='']">
> <xsl:copy-of select="*[local-name()='A']"/>
> <xsl:copy-of select="*[local-name()='B']"/>
> <xsl:copy-of select="*[local-name()='C']"/>
> </xsl:template>
> </xsl:stylesheet>
>
>
> XML before:
> <ITEM>
> <A/>
> <C/>
> <B/>
> <C/>
> <A/>
> </ITEM>
>
> after
>
>
> <ITEM>
> <A/>
> <A/>
> <B/>
> <B/>
> <C/>
> </ITEM>
>
> --
> Jim
>
>
> "Samuel L" wrote:
>
| |
| Samuel L 2005-12-21, 7:55 am |
| Additionally, how exactly do you apply this custom XSLT in the mapper?
Do you use it as it is as Inline XSLT Call Template in the scripting funtoid?
"Jim M" wrote:
[vbcol=seagreen]
> Hi Samuel,
>
> Yes. my xslt xcript is rather simple, and works fine in XMLSPY, and using
> the XML/XSL namespace classes in .NET.
>
> The script is shown below along with an XML sample.
>
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> version="1.0">
> <xsl:output omit-xml-declaration="yes" version="1.0" method="xml"/>
> <xsl:template match="/">
> <ITEM>
> <xsl:apply-templates select="/*[local-name()='ITEM' and
> namespace-uri()='']"/>
> </ITEM`>
> </xsl:template>
> <xsl:template match="/*[local-name()='ITEM' and namespace-uri()='']">
> <xsl:copy-of select="*[local-name()='A']"/>
> <xsl:copy-of select="*[local-name()='B']"/>
> <xsl:copy-of select="*[local-name()='C']"/>
> </xsl:template>
> </xsl:stylesheet>
>
>
> XML before:
> <ITEM>
> <A/>
> <C/>
> <B/>
> <C/>
> <A/>
> </ITEM>
>
> after
>
>
> <ITEM>
> <A/>
> <A/>
> <B/>
> <B/>
> <C/>
> </ITEM>
>
> --
> Jim
>
>
> "Samuel L" wrote:
>
| |
|
| By original order, I mean the xml elements are in the order they appear in
the original xml, not reordered.
I apply the custom xml by setting the map grid's Custom XLT Path property.
I have played around with other xslt scripts and they seem to work fine. It
doesn't work, however, when I try to reorder the xslt.
A little more background. First, the original message is a flat file, which
I dissasemble into an internal xml file using the usual method (receive
pipeline).
This xml has multiple elements with the same name, but they are not
contiguous. In my orchestration's expression shape, I need to loop over
these elements. The problem is the code I designed only sees the first
contiguous set of elements. Other like elements are ignored because they
are not contiguous with the first set.
Now, I could rewrite the expression to take the noncontiguous elements into
consideration, but I thought it would be quicker to simply use a custom xslt
script to reorder them so all similar elements are contiguous before my
expression shape processes them. In hindsight, I should just rewrite the
code, but it still leaves the question why my script doesn't work.
Jim
"Jim M" wrote:
>
> I would trying to reorder the elements of an xml document before processing
> them in an orchestration. I tried to solvew this using my own xslt in a map,
> and used the map in a transform shape and also in a receive port. In both
> cases, the elements in the xml document are processed in the original order.
>
> I'm not certain, but I now believe my problem is due to the fact that is the
> incoming xml is passed as a byte stream and thus cannot be reordered via an
> xsl transform.
>
> Does anyone have any thoughts on this and advise on how I can accomplish
> this? Could I do this using a custom pipeline component to reorder the xml
> before it enters the orchestration?
>
> Thanks in advance.
>
> Jim.
| |
|
| As I said before, the script I have works fine when run in other hosts
(XmlSpy, .NET). But, I think it's interesting that my script worked in the
mapper for you. In actuality, I dummied it down so it was much simpler to
read. Let me play around with it some more and see what happens. I'll
report back here.
Thanks,
--
Jim
"Samuel L" wrote:
[vbcol=seagreen]
>
> Hrm.. This seems weird... It works for me when I test it in the BizTalk
> mapper.
>
> What do you mean when say that "the elements in the xml document are
> processed in the original order"? How are the elements processed in the
> orchestration? Maybe there is something wrong here instead of in the mapping?
>
>
> "Jim M" wrote:
>
| |
| Samuel L 2005-12-21, 5:54 pm |
| Well, actually it worked for me after making some changes to reflect the test
schema that I used.
I had to take care of namespaces and therefore made some tweaking which got
the whole thing to work...
The thing is that I think the mapping doesn't succeed and therefore the
original version of the message is being processed later on in the
orchestration.
This is the optimized version of the XSLT code that I used:
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
version="1.0">
<xsl:output omit-xml-declaration="yes" version="1.0" method="xml"/>
<xsl:template name="test">
<xsl:copy> <!-- copies the root node -->
<xsl:copy-of select="*[local-name()='A']"/>
<xsl:copy-of select="*[local-name()='B']"/>
<xsl:copy-of select="*[local-name()='C']"/>
</xsl:copy>
</xsl:template>
</xsl:stylesheet>
Hope this helps!
"Jim M" wrote:
[vbcol=seagreen]
> As I said before, the script I have works fine when run in other hosts
> (XmlSpy, .NET). But, I think it's interesting that my script worked in the
> mapper for you. In actuality, I dummied it down so it was much simpler to
> read. Let me play around with it some more and see what happens. I'll
> report back here.
>
> Thanks,
>
> --
> Jim
>
>
> "Samuel L" wrote:
>
| |
|
| Samuel,
Thanks for your help. I discovered what was happening. The script was
probably working correctly. The problem occurred because the incoming xml
was not what I expected.
The schema property OrderType value had a value of Sequence which was
forcing an order on the xml instance. This effectively "filtered" the
noncontinguoius elements from the message which I was trying to reorder. I
simply changed the value to Choice and my orchestration logic worked like it
should. No need to reorder the elements before hand.
Thanks,
Jim
-
Jim
"Samuel L" wrote:
[vbcol=seagreen]
> Well, actually it worked for me after making some changes to reflect the test
> schema that I used.
>
> I had to take care of namespaces and therefore made some tweaking which got
> the whole thing to work...
>
> The thing is that I think the mapping doesn't succeed and therefore the
> original version of the message is being processed later on in the
> orchestration.
>
> This is the optimized version of the XSLT code that I used:
> <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
> version="1.0">
> <xsl:output omit-xml-declaration="yes" version="1.0" method="xml"/>
> <xsl:template name="test">
> <xsl:copy> <!-- copies the root node -->
> <xsl:copy-of select="*[local-name()='A']"/>
> <xsl:copy-of select="*[local-name()='B']"/>
> <xsl:copy-of select="*[local-name()='C']"/>
> </xsl:copy>
> </xsl:template>
> </xsl:stylesheet>
>
> Hope this helps!
>
>
> "Jim M" wrote:
>
|
|
|
|
|