|
Home > Archive > BizTalk Server Orchestration > June 2004 > Looping through a message & XLANG/s musings
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 |
Looping through a message & XLANG/s musings
|
|
| Alan Smith 2004-06-20, 11:09 pm |
| Hi,
I noticed a few threads on how to loop through a repeating node in a schema, and create a message for each node repetition. I managed to get it to work at last, but I'm not too sure if I am using XLANG/s the best way.
(Mail me if you have any questions, address in my "User Info")
I tried several ways to set the count:
"/root/employee[" + counter + "]/fields"
Gives: "operator + cannot be applied to operands of type 'System.String' and 'System.Int32'
"/root/employee[" + counter.ToString() + "]/fields"
Gives: distinguished types cannot be referenced with the dot opeartor.
Both the above are fine in C#.
In desperation I tried:
"/root/employee[" + System.String.Format ("{0}", counter)+ "]/fields"
Which gave: 'System.String.Format ("{0}", counter)': an xpath expression must be of the form yadda yadda...
And finally settled with:
stringCount = System.String.Format ("{0}", counter);
and "/root/employee[" + stringCount + "]/fields"
Which worked OK.
Is this really the optimal way to contatinate an int value inside a string?
It seems like you need to jump through a few hoops to get things done in XLANG/s.
And anyone know why the ++ operator is depricated?
Cheers,
Alan
| |
| Christof 2004-06-20, 11:09 pm |
| I'd do a normal XPath selection selecting all nodes you need. (Any .NET
component will do...) That will result in an XmlNodeSet, which you can loop
over using an iterator...
Kind regards,
Christof
"Alan Smith" <AlanSmith@discussions.microsoft.com> wrote in message
news:B1208E88-A112-4905-AF2E-15ECF62D9354@microsoft.com...
> Hi,
>
> I noticed a few threads on how to loop through a repeating node in a
schema, and create a message for each node repetition. I managed to get it
to work at last, but I'm not too sure if I am using XLANG/s the best way.
> (Mail me if you have any questions, address in my "User Info")
>
> I tried several ways to set the count:
>
> "/root/employee[" + counter + "]/fields"
> Gives: "operator + cannot be applied to operands of type 'System.String'
and 'System.Int32'
>
> "/root/employee[" + counter.ToString() + "]/fields"
> Gives: distinguished types cannot be referenced with the dot opeartor.
>
> Both the above are fine in C#.
>
> In desperation I tried:
> "/root/employee[" + System.String.Format ("{0}", counter)+ "]/fields"
> Which gave: 'System.String.Format ("{0}", counter)': an xpath expression
must be of the form yadda yadda...
>
> And finally settled with:
> stringCount = System.String.Format ("{0}", counter);
> and "/root/employee[" + stringCount + "]/fields"
>
> Which worked OK.
>
> Is this really the optimal way to contatinate an int value inside a
string?
> It seems like you need to jump through a few hoops to get things done in
XLANG/s.
> And anyone know why the ++ operator is depricated?
>
> Cheers,
>
> Alan
>
>
>
>
>
>
>
>
>
>
>
| |
| Lee Graber [MSFT] 2004-06-20, 11:09 pm |
| I don't really know your scenario, but you might consider breaking the
document up in the receive pipeline. If possible, this is the ideal place
to do it since the document is already loaded and has not been persisted
yet. If you send the whole document to the schedule, you incur more
persistence points and data copying as we create more messages and persist
more data.
Christof is right about what he said. In comparison to how you are desiging
it, simply doing a select nodes will only evaluate the xpath once and so
only traverse the tree once, whereas your method is traversing the tree n
times. Ideally, you would like to do all of this in a streaming fashion
which is why I recommended the first approach, but again, I don't know your
scenario.
HTH
Lee
This posting is provided "AS IS" with no warranties, and confers no rights.
EBusiness Server Team
--------------------[vbcol=seagreen]
cpmsftngxa10.phx.gbl!TK2MSFTNGXA06.phx.gbl!cpmsftngxa06.phx.gbl!TK2MSFTNGP08
.phx.gbl!TK2MSFTNGP10.phx.gbl[vbcol=seagreen]
loop[vbcol=seagreen]
| |
| Christof 2004-06-20, 11:09 pm |
| Lee,
have a little side question here. You mentioned: "and has not been
persisted yet"!
what do you exactly mean with this. I assume you mean "logically been
persisted yet", arent you? When an adapter submits a message into BizTalk I
always "assumed" that the message first was persisted in the MBox and
afterwards passed the pipeline. If this is not the case, how is failover
handled with please? (Let's say your custom code screws up in the pipeline
:-))) Two options here:
1) the data was actually persisted to the MBox before and will be marked as
"failed" in HAT (suspended)
2) the adapter will get a failure notification in the BatchComplete callback
and is responsible for suspending the message. In that case the stream has
been read already and possible cannot be set to its beginnin again...
(Imagine a very large HTTP request...)
Could you provide me with more details on this please?
Thanks!!
Christof
"Lee Graber [MSFT]" <leegr@microsoft.com> wrote in message
news:WwIcM$MVEHA.1996@cpmsftngxa10.phx.gbl...
> I don't really know your scenario, but you might consider breaking the
> document up in the receive pipeline. If possible, this is the ideal place
> to do it since the document is already loaded and has not been persisted
> yet. If you send the whole document to the schedule, you incur more
> persistence points and data copying as we create more messages and persist
> more data.
>
> Christof is right about what he said. In comparison to how you are
desiging
> it, simply doing a select nodes will only evaluate the xpath once and so
> only traverse the tree once, whereas your method is traversing the tree n
> times. Ideally, you would like to do all of this in a streaming fashion
> which is why I recommended the first approach, but again, I don't know
your
> scenario.
>
> HTH
> Lee
>
>
> This posting is provided "AS IS" with no warranties, and confers no
rights.
>
> EBusiness Server Team
> --------------------
>
cpmsftngxa10.phx.gbl!TK2MSFTNGXA06.phx.gbl!cpmsftngxa06.phx.gbl!TK2MSFTNGP08
> phx.gbl!TK2MSFTNGP10.phx.gbl
> loop
it[vbcol=seagreen]
way.[vbcol=seagreen]
'System.String'[vbcol=seagreen]
expression[vbcol=seagreen]
in[vbcol=seagreen]
>
| |
| Lee Graber [MSFT] 2004-06-20, 11:09 pm |
| With the side excpetion of MSMQt large message data, data is not persisted
into the messagebox until after the receive pipeline and any inbound maps
have been executed. Persisting before hand would be a large perf hit as
this is not the data you actually want routed and potentially you are not
even persisting it to the messagebox it will eventually be routed to. If a
message stream is not seekable, the adapter is expected to either build a
new stream which can be suspended, or to simply return an error to the
caller and not actually suspend anything. I believe that for HTTP, you will
get the error returned to the client without an actual suspend occuring.
HTH
Lee
This posting is provided "AS IS" with no warranties, and confers no rights.
EBusiness Server Team
--------------------[vbcol=seagreen]
<#cUXz2iUEHA.3780@TK2MSFTNGP10.phx.gbl>
<WwIcM$MVEHA.1996@cpmsftngxa10.phx.gbl>[vbcol=seagreen]
cpmsftngxa10.phx.gbl!TK2MSFTFEED01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP09
.phx.gbl[vbcol=seagreen]
BizTalk I[vbcol=seagreen]
pipeline[vbcol=seagreen]
as[vbcol=seagreen]
callback[vbcol=seagreen]
has[vbcol=seagreen]
place[vbcol=seagreen]
persist[vbcol=seagreen]
n[vbcol=seagreen]
08[vbcol=seagreen]
.NET[vbcol=seagreen]
get[vbcol=seagreen]
opeartor.[vbcol=seagreen]
"]/fields"[vbcol=seagreen]
done[vbcol=seagreen]
| |
| Christof 2004-06-20, 11:09 pm |
| thanks Lee, this is definately something to blog about :-)
Regards,
Christof
"Lee Graber [MSFT]" <leegr@microsoft.com> wrote in message
news:ebx1qaYVEHA.308@cpmsftngxa10.phx.gbl...
> With the side excpetion of MSMQt large message data, data is not persisted
> into the messagebox until after the receive pipeline and any inbound maps
> have been executed. Persisting before hand would be a large perf hit as
> this is not the data you actually want routed and potentially you are not
> even persisting it to the messagebox it will eventually be routed to. If a
> message stream is not seekable, the adapter is expected to either build a
> new stream which can be suspended, or to simply return an error to the
> caller and not actually suspend anything. I believe that for HTTP, you
will
> get the error returned to the client without an actual suspend occuring.
>
> HTH
> Lee
>
> This posting is provided "AS IS" with no warranties, and confers no
rights.
>
> EBusiness Server Team
> --------------------
> <#cUXz2iUEHA.3780@TK2MSFTNGP10.phx.gbl>
> <WwIcM$MVEHA.1996@cpmsftngxa10.phx.gbl>
>
cpmsftngxa10.phx.gbl!TK2MSFTFEED01.phx.gbl!TK2MSFTNGP08.phx.gbl!TK2MSFTNGP09
> phx.gbl
> BizTalk I
failover[vbcol=seagreen]
> pipeline
> as
> callback
> has
> place
persisted[vbcol=seagreen]
> persist
so[vbcol=seagreen]
tree[vbcol=seagreen]
> n
fashion[vbcol=seagreen]
>
> 08
microsoft.public.biztalk.orchestration:6532[vbcol=seagreen]
> NET
can[vbcol=seagreen]
a[vbcol=seagreen]
> get
> opeartor.
> "]/fields"
a[vbcol=seagreen]
> done
>
|
|
|
|
|