Hello.

I created a custom pipeline that gets the size of the file that's being
processed.
I then promote this value as a distinguished property as follows:

inmsg.Context.Write("FileSize","http://schemas.microsoft.com/BizTalk/2003/btsDistinguishedFields", FileSize).

I now want to access the distinguished property "FileSize" in an
orchestration but don't know how to go about it. In my orchestration I have a
mesage defined but FileSize has nothing to do with the schema that's
associated with the message.

Any suggestions will be greatly appreciated!

Ritag

Ritag,
> I created a custom pipeline that gets the size of the file that's being
> processed.
> I then promote this value as a distinguished property as follows:
>
> inmsg.Context.Write("FileSize","http://schemas.microsoft.com/BizTalk/2003/btsDistinguishedFields",
> FileSize).
>
> I now want to access the distinguished property "FileSize" in an
> orchestration but don't know how to go about it. In my orchestration I
> have a
> mesage defined but FileSize has nothing to do with the schema that's
> associated with the message.

Distinguished properties aren't really meant to be used like this; instead
they are meant to be used in association with specific fields in the message
schema.

Instead, you should define a real custom context property (of type
MessageContextPropertyBase) and use that instead. Then you can simply read
it in your orchestration using the "msg(NS.MyProperty)" syntax.

Thanks Tomas. I will try that but before I do I'd just liek to try one more
thing regarding the distinguished property.
If I use the following to promote the distinguished property:
inmsg.Context.Write("/*[local-name()='myInfo' and namespace-uri()
='http://FIC.BizTalk.Orch.GetFileSize']/*[local-name()='FileSize' and
namespace-uri()='']", BTSNameSpace, DataSize);

what xpath would I use in the orchestration's expression?

Thanks,
Rita

"Tomas Restrepo [MVP]" wrote:
[..]

Ritag,

> Thanks Tomas. I will try that but before I do I'd just liek to try one
> more
> thing regarding the distinguished property.
> If I use the following to promote the distinguished property:
> inmsg.Context.Write("/*[local-name()='myInfo' and namespace-uri()
> ='http://FIC.BizTalk.Orch.GetFileSize']/*[local-name()='FileSize' and
> namespace-uri()='']", BTSNameSpace, DataSize);
>
> what xpath would I use in the orchestration's expression?

Context properties are not accessed through XPath. I think maybe you have a
slight confusion regarding:

- Context (data) properties, which are values from the message _content_
that are promoted to the message content and available both inside the
orchestration (using the msg(property) syntax) as well as in messaging
scenarios for routing.

- Context (context-only) properties, which only exist in the message
_context_ itself, but are not related in any way to the message payload.
Examples of these are the adapter-specific properties like
FILE.ReceivedFileName or MSMQ.MessageId.

- Distinguished properties, which are only used inside orchestrations as a
"quick hand" way of accessing values *present* in the message XML content.
It's true that because of the way distinguished properties are implemented
in BizTalk, these get written to the message context during parsing, but you
don't really used them there directly. In fact, it makes no sense to talk
about distinguished properties without there being a matching field in the
message schema (and present at runtime in the document).

Also, notice that technically speaking, Context.Write() only *writes*
something into the message context, it doesn't promote it. For that, you'd
need to use Context.Promote(). And, either way, context properties are
accessed using, as I mentioned before, the context-accessor syntax in
XLANG/Sharp, for example "msg(FILE.ReceivedFileName)".

Does this clarify things somewhat?

FWIW, Maybe I'm just not quite getting what you're trying to accomplish.
Really, carrying out-of-band data like the file name (or, in your case, the
file size) is exactly what context properties were created for; so not quite
sure why you try to shoehorn them into distinguished properties. Perhaps if
you could help me understand a bit better what you want and why I can offer
better advice.

Thanks for that explanation - it helped my understanding.

I discarded trying to promote the property as distinguished and tried your
recommendation of using inmsg.Context.Promote. I'm currently having the
custom pipeline blow up as follows.

I have a custom pipeline that calculates the size of the incoming file.
I then use inmsg.Context.Promote("FileSize",
"http://FIC.BizTalk.Orch.GetFileSize.MyContextProperty", (long) DataSize); to
promote the FileSize property.

(DataSize is defined as ulong in pipeline component and FileSize in the
schema is long).

In an orchestra (FIC.BizTalk.Orch.GetFileSize) I have a property schema called
MyContextProperty.xsd. I also have a message defined as an EDI schema which
is applied to the first Receive shape.

I then have an Expression shape where I access the promoted FileSize
property and write the value ot the EventLog (this is just for testing
purposes). In my Expression I use "varTmp =
System.Convert.ToString(EDI837I(FIC.BizTalk.Orch.G etFileSize.FileSize));"
which I then write to the EventLog.
I'm able to see the FileSize in intellisense.

When the input EDI fiile is picked up by the Receive Port with the Receive
Location that has my custom Pipeline it blows up and never gets to the
orchestration. I know this as I placed a couple of lines to write to the
Eventlog in the custom pipeline code.
I get the first Eventlog message before this line of code and then it blows
up.
I do not get the Eventlog message after this line of code.

System.Diagnostics.EventLog.WriteEntry("FileLevelL ogging", "Test1"); - I see
this in the EventLog
inmsg.Context.Promote("FileSize",
"http://FIC.BizTalk.Orch.GetFileSize.MyContextProperty", (long)DataSize);

System.Diagnostics.EventLog.WriteEntry("FileLevelL ogging", "Test2"); - I
don't see this in the EventLog.

The error message I get is: There was a failure executing the receive
pipeline: "FIC.BizTalk.PipeLine.GetFileSize.GetFileSizeRecei ve,
FIC.BizTalk.PipeLine.GetFileSize, Version=1.0.0.0, Culture=neutral,
PublicKeyToken=585b3f1e468ca8f5" Source: "PipeCompGetFileSize" Receive Port:
"rcvGetFileSize" URI: "C:\Ports\FileLevelLogging\In\*.txt"
Reason: The property is an unsupported type.

What am I missing?
I wasn't sure if the Property Schema MyContextProperty.xsd has to be in the
orchestration. THis is where I've placed it. If not, where does it go?

Your help is much appreciated!

"Tomas Restrepo [MVP]" wrote:
[..]

Tomas - I finally got it to work!
The trick was to create a new project with just the property schema and
deploy it.
I made some changes to the namespace in the inmsg.Context.Promote line to
accommodate this and it worked perfectly.

Many, many thanks for your help.

"RitaG" wrote:
[..]

Hi Tomas,

I came across the same situation as Rita was saying in this post. I have developed a custom pipe line component to promote a property (requested user id) into the message context. I exposed the orchestration as a wcf service and submitting the request. When I debug I was able to see the promoted property in the message context (in admin console). But I was unable to access the same inside the orchestration. Actually I followed the process in the link http://www.richardhallgren.com/writi...ing-behaviors/
to develop the application.

Could you please help me in solving this?

Regards,
Giri

Hi,

In fact in one of the projects I had similar situation and still don't
know how to handle it.

Here is what happens,

I need to expose a schema on WCF.
I need to get the Application Name and User Name accessing the WCF in
BizTalk.
I do not want to put these informations in the schema (because they
would be exposed to users and we don't want that)

So What we did is : Create two properties inside the Context of the
Message.
Then we wanted to retrieve them from the a .NET Component called
inside the orchestration.

We didn't succeed, we had some kind of "first chance exception, ...
bla bla bla"

Thomas, is what we did right? Could we do it?

Regards,
Stéphane

In article <26ec16a0-48cc-4996-9e55-
48f24756082e>, malti
says...>
[..]
> Then we wanted to retrieve them from the a .NET Component called
> inside the orchestration.
>
> We didn't succeed, we had some kind of "first chance exception, ...
> bla bla bla"
>
> Thomas, is what we did right? Could we do it?
>
> Regards,
> Stéphane

Hi guys,

have you tried to set into PropertySchema for each promoted property
Property Schema Base to MessageContextPropertyBase?
You can also try to read your context property like this:
public static string ReadContextProperty(XLANGMessage msg, Type
propertyType)
{
return msg.GetPropertyValue(propertyType).ToString();
}
for type you specify: typefo(MyContextProperty)

Ivane (odakle si?)

I'll try to use the 1st option
> have you tried to set into PropertySchema for each promoted property
> Property Schema Base to MessageContextPropertyBase?

Because the second one generates a first chance exception, hmm,
however it doesn't generate this exception if we try to access a
ContextProperty used natively (example if we access MessageID no
problem, if we access our custom Property we got the first chance
exception)

Regards,
Stefan
http://www.itsconsulting.fr
http://www.itsconsulting.fr/blog

Hi Giri,

I saw you comment on Richard's blog. Try accessing your context property
like this

YOU_MESSAGE_VARIABLE(WCFCustomProperties.PropertyS chema.WindowsUserName)

Infact you should see the intellisense once you open the curley brace