|
Home > Archive > BizTalk Server General > August 2005 > Writing Distinguished Fields to Message Part in pipeline
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 |
Writing Distinguished Fields to Message Part in pipeline
|
|
| Craig Neuwirt 2005-08-21, 5:49 pm |
| How do you write Distinguished Fields on a message part. in a pipeline
component? Typicaly, you write to the MessageContext of the IBaseMessage,
but there isn't one for IBaseMessagePart.
thank,
craig
| |
| Scott Colestock 2005-08-22, 5:56 pm |
| Message context belongs to the message, rather than an individual part. So
you will have to do your property promotion (which is different than
distinguished fields - which are orchestration-only) at that level.
Scott Colestock
www.traceofthought.net
"Craig Neuwirt" <cneuwirt@emsinet.com> wrote in message
news:OV$ZpUopFHA.2156@TK2MSFTNGP14.phx.gbl...
> How do you write Distinguished Fields on a message part. in a pipeline
> component? Typicaly, you write to the MessageContext of the IBaseMessage,
> but there isn't one for IBaseMessagePart.
>
> thank,
> craig
>
>
| |
| Tomas Restrepo \(MVP\) 2005-08-22, 8:48 pm |
| Craig,
> How do you write Distinguished Fields on a message part. in a pipeline
> component? Typicaly, you write to the MessageContext of the IBaseMessage,
> but there isn't one for IBaseMessagePart.
Do you mean Property Fields? Distinguished fields are only an abstraction
used by the orchestration engine/designer, but do not reflect on actual
properties stored in the message context.
Alas, message parts do have properties associated with them in multi-part
message types, but that is not used very often. I believe they are usually
accessed through IBaseMessagePart.PartProperties.
What is it that you're trying to achieve?
--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/
| |
| Craig Neuwirt 2005-08-23, 2:47 am |
| Tomas,
The PartProperties is exactly what I needed. Basically, I am constructing
a multi-part message in a pipeline and I would like to write the
distinguished fields on the individual parts to simplify the orchestration..
Otherwise, I have to use xpath.
As a side ?, what is the right way to handle an orchestration accessing a
distinguished property that has not been assigned. Is throws an exception.
Based on my readings, distinguished fields are not stored in the message
context and are simply references to parts of the document. If that is the
case, why must I write the distringuished fields with the xpath as the name
and the Globals.DistinguishedFieldsNamespace into the context. If I do not
do this and I try to access the distinguished field in the orch, it fails.
Thanks,
craig
"Tomas Restrepo (MVP)" <tomasr@mvps.org> wrote in message
news:uYLF3L3pFHA.2588@TK2MSFTNGP12.phx.gbl...
> Craig,
>
IBaseMessage,[vbcol=seagreen]
>
> Do you mean Property Fields? Distinguished fields are only an abstraction
> used by the orchestration engine/designer, but do not reflect on actual
> properties stored in the message context.
>
> Alas, message parts do have properties associated with them in multi-part
> message types, but that is not used very often. I believe they are usually
> accessed through IBaseMessagePart.PartProperties.
> What is it that you're trying to achieve?
>
>
> --
> Tomas Restrepo
> tomasr@mvps.org
> http://www.winterdom.com/
>
>
| |
| Tomas Restrepo \(MVP\) 2005-08-23, 8:56 pm |
| Hi Craig,
> The PartProperties is exactly what I needed. Basically, I am
> constructing
> a multi-part message in a pipeline and I would like to write the
> distinguished fields on the individual parts to simplify the
> orchestration..
> Otherwise, I have to use xpath.
That's sort of the thing that has me confused. What exactly do you mean by
"write the distinguished fields"?
--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/
| |
| Craig Neuwirt 2005-08-24, 6:04 pm |
| Hi Tomas,
Writing distinguished fields means calling the Writer method on the
IBaseMessage or IBaseMessagePart. Since this is only done in the XmlDasm
component, I must do it explicitly in my pipeline since I am using a custom
component. Here is the code to do it.
propertyBag.Write(distField.XPath, Globals.DistinguishedFieldsNamespace,
distFieldNode.InnerText);
This works fine. I am just confiused why distinguished fields must be
explicitly assigned to the message. If I don't do this, I cannot access
them in the Orchestration. My understanding was that distinguished fields
are merely a shortcut into the content of a message using an XPath
expression. I would have expected the Orchestration designer to simply use
the XPath reference in the schema to make the call at runtime.
thanks,
craig
"Tomas Restrepo (MVP)" <tomasr@mvps.org> wrote in message
news:eVf6p$DqFHA.2652@tk2msftngp13.phx.gbl...
> Hi Craig,
>
>
> That's sort of the thing that has me confused. What exactly do you mean by
> "write the distinguished fields"?
>
>
> --
> Tomas Restrepo
> tomasr@mvps.org
> http://www.winterdom.com/
>
>
| |
| Tomas Restrepo \(MVP\) 2005-08-24, 6:04 pm |
| Craig,
> Writing distinguished fields means calling the Writer method on the
> IBaseMessage or IBaseMessagePart. Since this is only done in the XmlDasm
> component, I must do it explicitly in my pipeline since I am using a
> custom
> component. Here is the code to do it.
>
> propertyBag.Write(distField.XPath, Globals.DistinguishedFieldsNamespace,
> distFieldNode.InnerText);
I must be asking the wrong questions here 
That's not what I ask. what I meant what is it that you understand by
"writing" the distinguished field? I really have no idea what you feel you
need to do all this hoopla to be able to access the fields from your
orchestration. What is different about your solution that forces you to do
all of this?
FWIW, I decided to check the BTS code with a little help from reflection,
and, as far as I can tell, biztalk *does* use the XPath definition when
accessing the distinguished field. Here's a small bit of code from a test
orchestration I have here that reads the value of a distinguished field:
Debug.WriteLine("DCesc: " + ((string)
adf_1.__DF.part.GetDistinguishedField("Super.Descripcion")));
Notice the GetDistinguishedField() call, which eventually ends up in
XSDPart.GetDistinguishedField():
public override object GetDistinguishedField(string dottedPath)
{
XsdDistinguishedFieldDefinition definition1 =
(XsdDistinguishedFieldDefinition) base.GetDFDef(dottedPath);
object obj1 = base._getXPath(definition1.XPath,
definition1.IsDynamic);
if (obj1 == null)
{
return null;
}
if (obj1.GetType() != definition1.FieldType)
{
obj1 = XmlHelpers.ChangeType(obj1, definition1.FieldType);
}
return obj1;
}
It's not all that hard to realize what biztalk is doing below here (the only
confusing aspects are a few read and write caches for the properties it
keeps, but that is all, mostly...)
--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/
>
> This works fine. I am just confiused why distinguished fields must be
> explicitly assigned to the message. If I don't do this, I cannot access
> them in the Orchestration. My understanding was that distinguished fields
> are merely a shortcut into the content of a message using an XPath
> expression. I would have expected the Orchestration designer to simply
> use
> the XPath reference in the schema to make the call at runtime.
>
> thanks,
> craig
>
> "Tomas Restrepo (MVP)" <tomasr@mvps.org> wrote in message
> news:eVf6p$DqFHA.2652@tk2msftngp13.phx.gbl...
>
>
| |
| Craig Neuwirt 2005-08-24, 6:04 pm |
| Hello Tomas,
Sorry for doing a poor job of explaining. The dissasembled fragment is
very helpful in confirming my understanding of the problem.
> That's not what I ask. what I meant what is it that you understand by
> "writing" the distinguished field? I really have no idea what you feel you
> need to do all this hoopla to be able to access the fields from your
> orchestration. What is different about your solution that forces you to do
> all of this?
I need to emphasize the fact that I am not using the default XmlReceive
pipeline which is what currently does the writing of distinguished
fields into the message parts. It eventually does the following too.
propertyBag.Write(distField.XPath, Globals.DistinguishedFieldsNamespace,
distFieldNode.InnerText);
Since I am using my own custom pipeline, I have to make the above call for
all distinguished fields in my message. Otherwise,
as the reflected code seems to confrim, null is returned. My observation is
that the orchestration will choke when the
distinguished field is not property set, even if it is empty.
If I don't do the Writes, I cannot access the fields in the orchestration.
I may be a little confused, but I would expect not to have
to do the writes if BizTalk performs dynamic xpath queries at runtime.
thanks for all your help.
"Tomas Restrepo (MVP)" <tomasr@mvps.org> wrote in message
news:OTelGxNqFHA.904@TK2MSFTNGP09.phx.gbl...
> Craig,
>
XmlDasm[vbcol=seagreen]
> I must be asking the wrong questions here
>
> That's not what I ask. what I meant what is it that you understand by
> "writing" the distinguished field? I really have no idea what you feel you
> need to do all this hoopla to be able to access the fields from your
> orchestration. What is different about your solution that forces you to do
> all of this?
>
> FWIW, I decided to check the BTS code with a little help from reflection,
> and, as far as I can tell, biztalk *does* use the XPath definition when
> accessing the distinguished field. Here's a small bit of code from a test
> orchestration I have here that reads the value of a distinguished field:
>
> Debug.WriteLine("DCesc: " + ((string)
> adf_1.__DF.part.GetDistinguishedField("Super.Descripcion")));
>
> Notice the GetDistinguishedField() call, which eventually ends up in
> XSDPart.GetDistinguishedField():
>
> public override object GetDistinguishedField(string dottedPath)
> {
> XsdDistinguishedFieldDefinition definition1 =
> (XsdDistinguishedFieldDefinition) base.GetDFDef(dottedPath);
> object obj1 = base._getXPath(definition1.XPath,
> definition1.IsDynamic);
> if (obj1 == null)
> {
> return null;
> }
> if (obj1.GetType() != definition1.FieldType)
> {
> obj1 = XmlHelpers.ChangeType(obj1, definition1.FieldType);
> }
> return obj1;
> }
>
> It's not all that hard to realize what biztalk is doing below here (the
only
> confusing aspects are a few read and write caches for the properties it
> keeps, but that is all, mostly...)
>
>
> --
> Tomas Restrepo
> tomasr@mvps.org
> http://www.winterdom.com/
>
>
>
fields[vbcol=seagreen]
>
>
| |
| Tomas Restrepo \(MVP\) 2005-08-24, 8:51 pm |
| Hi Craig,
> Sorry for doing a poor job of explaining.
Don't worry, I think it was mostly a case of me not having enough context to
understand what you were saying! but I do now
> The dissasembled fragment is
> very helpful in confirming my understanding of the problem.
>
> I need to emphasize the fact that I am not using the default XmlReceive
> pipeline which is what currently does the writing of distinguished
> fields into the message parts.
Cool I get it. SO you're writing your own custom disassembler, then?
> It eventually does the following too.
>
> propertyBag.Write(distField.XPath, Globals.DistinguishedFieldsNamespace,
> distFieldNode.InnerText);
>
> Since I am using my own custom pipeline, I have to make the above call for
> all distinguished fields in my message. Otherwise,
> as the reflected code seems to confrim, null is returned. My observation
> is
> that the orchestration will choke when the
> distinguished field is not property set, even if it is empty.
>
> If I don't do the Writes, I cannot access the fields in the orchestration.
> I may be a little confused, but I would expect not to have
> to do the writes if BizTalk performs dynamic xpath queries at runtime.
Yeah, I see. I did some more digging around, and did in fact notice that
eventually all the standard disassemblers do the writing of the
distinguished properties, but, to be honest, I don't fully grasp *why* they
do it, and how the orchestration (or rather XSDPart, I guess) actually uses
that information when accessing the distinguished field. Does it have
anything to do with the prefetching done during message load, or possibly
the whole thing they do with the XmlRewritingContentFactory? I don't
know....
will definitely have to dig some more on this, but it sounds pretty
interesting to understand how biztalk is working internally...
From what I looked at the code, it does seem there are *some* cases, at
least, where biztalk will do a dynamic xpath query. My guess, without
looking too much here, is that it may have something to do with the
IsDynamic property of the XsdDistinguishedFieldDefinition class, which, I
must admit, I do not know where it gets its value. One thing might be that
the dynamic xpath query mechanism is reserved for the xpath() XLANG/s
function, while for distinguished fields biztalk always falls back to a sort
of "preloaded" values mechanism in order to improve performance in the
orchestration (since distinguished fields will likely be accessed pretty
often)... but this is nothing else than a wild guess
--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/
| |
| Craig Neuwirt 2005-08-25, 6:02 pm |
| Hello Tomas,
Thanks for baring with me on this one. Your digging around really shed
some light on this. The ability to access xpath dynamically was really what
I was trying to understanding. The "preloading" idea for efficiency reasons
sounds plausable, but I don't know either. I wish you could specify a
dynamic distinguished property in the schema since that would reduce the
need to have to explicitly writer the fields into the context.
Again, I want to thank you for effort in undertstanding and addressing my
issue.
cheers,
craig
"Tomas Restrepo (MVP)" <tomasr@mvps.org> wrote in message
news:OizKr%23QqFHA.712@tk2msftngp13.phx.gbl...
> Hi Craig,
>
>
> Don't worry, I think it was mostly a case of me not having enough context
to
> understand what you were saying! but I do now
>
>
> Cool I get it. SO you're writing your own custom disassembler, then?
>
for[vbcol=seagreen]
observation[vbcol=seagreen]
orchestration.[vbcol=seagreen]
>
> Yeah, I see. I did some more digging around, and did in fact notice that
> eventually all the standard disassemblers do the writing of the
> distinguished properties, but, to be honest, I don't fully grasp *why*
they
> do it, and how the orchestration (or rather XSDPart, I guess) actually
uses
> that information when accessing the distinguished field. Does it have
> anything to do with the prefetching done during message load, or possibly
> the whole thing they do with the XmlRewritingContentFactory? I don't
> know....
>
> will definitely have to dig some more on this, but it sounds pretty
> interesting to understand how biztalk is working internally...
>
> From what I looked at the code, it does seem there are *some* cases, at
> least, where biztalk will do a dynamic xpath query. My guess, without
> looking too much here, is that it may have something to do with the
> IsDynamic property of the XsdDistinguishedFieldDefinition class, which, I
> must admit, I do not know where it gets its value. One thing might be that
> the dynamic xpath query mechanism is reserved for the xpath() XLANG/s
> function, while for distinguished fields biztalk always falls back to a
sort
> of "preloaded" values mechanism in order to improve performance in the
> orchestration (since distinguished fields will likely be accessed pretty
> often)... but this is nothing else than a wild guess
>
>
> --
> Tomas Restrepo
> tomasr@mvps.org
> http://www.winterdom.com/
>
>
|
|
|
|
|