I have a message with a field containing blob data (up to 20Mb). I need to
retrive its value for futher processing.
There two ways to do it:
1. Make the field distinguish
2. Use xpath expression.

What is more optimal in terms of memory utilization and, finally, performanc
e?

Thanks in advance.

[ Post a follow-up to this message ]

Hello Michael,

Distinguished fields are in general faster in terms of performance. The info
rmation
is fetched from the message context as opposed to fetched from the message
itself when you use Xpath.
In your case I would strongly advice not to use the message context (disting
uished
fields) because you're using large amounts of data.
Although there is no size limit for distinguished fields it is not a good
thing to have blob data with that size in the message context.

HTH,
Randal van Splunteren
http://biztalkia.blogspot.com


> I have a message with a field containing blob data (up to 20Mb). I
> need to
> retrive its value for futher processing.
> There two ways to do it:
> 1. Make the field distinguish
> 2. Use xpath expression.
> What is more optimal in terms of memory utilization and, finally,
> performance?
>
> Thanks in advance.
>

[ Post a follow-up to this message ]

Only properties are stored in the message context and they are limited to
255 characters

Distinguished fields are evaluated/saved into the message in the
orchestration the same as the xpath function. With distinguished fields the
xpath string is in the XSD schema, while the xpath function has the xpath
string in the code.
A distinguished field is good for quick access to fixed fields while the
xpath function is required if you need to customise the xpath (e.g. index a
repeating element) or want to return a nodeset.

I am not sure there will be much performance difference between the two
mechanisms.

The best way to tell would be to test it.

Greg

"Randal van Splunteren" <randal.van.splunteren@hotmail.com> wrote in message
news:3ee20e0fc7478c81ad49e5e5fa0@news.microsoft.com...
> Hello Michael,
>
> Distinguished fields are in general faster in terms of performance. The
> information is fetched from the message context as opposed to fetched from
> the message itself when you use Xpath.
> In your case I would strongly advice not to use the message context
> (distinguished fields) because you're using large amounts of data.
> Although there is no size limit for distinguished fields it is not a good
> thing to have blob data with that size in the message context.
>
> HTH,
> Randal van Splunteren
> http://biztalkia.blogspot.com
>
> 
>
>

[ Post a follow-up to this message ]

Hello Greg,

I am a little bit confused here. I got the following information from Matt
Milners great white paper on the Biztalk messaging Engine:

['One of the benefits of promoted properties is that the value of the el
ement
that is promoted is available in the context of the message. This means that
retrieving that value is inexpensive, as it does not require loading the
message into memory to execute an XPath statement on the message. Instead,
a simple property bag can be used along with a key to get the value. This
type of behavior is desirable in situations other than message routing and
is the reason for creating distinguished fields. While promoted properties
are promoted into the message context, distinguished fields are written into
the message context. Unlike promoted properties however, there is no propert
y
schema for distinguished fields. This is why distinguished fields cannot
be used for routing and are therefore not available as filter criteria in
a send port or orchestration receive shape. Distinguished fields can, howeve
r,
be used in orchestrations to read or write values from the message context
instead of having to load the message into memory and extract the value.
'] [from Matt Millner, http://msdn.microsoft.com/library/d...a951700f840.asp]

This white paper also states that only promoted properties are limited to
255 characters but distinguished are not.

To my opinion this means that distinguished fields are in the message contex
t.
Also when I examine the message context (using the biztalk 2006 administrati
on
console) for any message that has distinguished fields defined I see them
in the message context.

Do I miss something here. Do I interpret this white paper in the wrong way?

Thanks,

Randal van Splunteren
http://biztalkia.blogspot.com



[vbcol=seagreen]
> Only properties are stored in the message context and they are limited
> to 255 characters
>
> Distinguished fields are evaluated/saved into the message in the
> orchestration the same as the xpath function. With distinguished
> fields the
> xpath string is in the XSD schema, while the xpath function has the
> xpath
> string in the code.
> A distinguished field is good for quick access to fixed fields while
> the
> xpath function is required if you need to customise the xpath (e.g.
> index a
> repeating element) or want to return a nodeset.
> I am not sure there will be much performance difference between the
> two mechanisms.
>
> The best way to tell would be to test it.
>
> Greg
>
> "Randal van Splunteren" <randal.van.splunteren@hotmail.com> wrote in
> message news:3ee20e0fc7478c81ad49e5e5fa0@news.microsoft.com...
> 

[ Post a follow-up to this message ]

Randal,
My reply was based on some incorrect assumptions and general lack of
knowledge.
I had not seen Matt's whitepaper, until you pointed it out, thanks 
You are correct Distinguished Fields are indeed written to the Message
Context and there is no size limit on written properties.

So, in Michael's case using a distinguished field for his 20MB blob would be
a bad idea.
Using the xpath function would make much more sense.

Greg



"Randal van Splunteren" <randal.van.splunteren@hotmail.com> wrote in message
news:3ee20e0fc7b38c81af0360fd9b0@news.microsoft.com...
> Hello Greg,
>
> I am a little bit confused here. I got the following information from Matt
> Milners great white paper on the Biztalk messaging Engine:
>
> ['One of the benefits of promoted properties is that the value of the
> element that is promoted is available in the context of the message. This
> means that retrieving that value is inexpensive, as it does not require
> loading the message into memory to execute an XPath statement on the
> message. Instead, a simple property bag can be used along with a key to
> get the value. This type of behavior is desirable in situations other than
> message routing and is the reason for creating distinguished fields. While
> promoted properties are promoted into the message context, distinguished
> fields are written into the message context. Unlike promoted properties
> however, there is no property schema for distinguished fields. This is why
> distinguished fields cannot be used for routing and are therefore not
> available as filter criteria in a send port or orchestration receive
> shape. Distinguished fields can, however, be used in orchestrations to
> read or write values from the message context instead of having to load
> the message into memory and extract the value. '] [from Matt Millner,
> http://msdn.microsoft.com/library/d...a951700f840.asp]
>
> This white paper also states that only promoted properties are limited to
> 255 characters but distinguished are not.
>
> To my opinion this means that distinguished fields are in the message
> context. Also when I examine the message context (using the biztalk 2006
> administration console) for any message that has distinguished fields
> defined I see them in the message context.
>
> Do I miss something here. Do I interpret this white paper in the wrong
> way?
>
> Thanks,
>
> Randal van Splunteren
> http://biztalkia.blogspot.com
>
>
>
> 
>
>

[ Post a follow-up to this message ]