|
Home > Archive > BizTalk Server Orchestration > September 2005 > Correlation Question
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 |
Correlation Question
|
|
| PeterW 2005-09-08, 7:51 am |
| I note that decorating class properties with the
[DistinguishedFiledAttribute] is not enough for make the property usable in
CorrelationSets and that a property schema must be used. If one is using
assembly references to identify a class in a message, then the object being
is being serialized from a class.
This must mean that in addition the classes that have been created using the
XLANGs.BaseTypes and [DistinguishedFiledAttribute] is not enough and that
schemas and property schemas must also be maintained.
I notice that if you access a message element that is based on a class
instance, that an orchestration will accept that for assigning to
orchestration variiables so they are obviously visible.
My question is why is any non BizTalk assembly installed in the gac and
referenced by a BizTalk project, not visible to the correlation properties
dialog box? Or have I missed something along the way? I know that it is not
difficult to generate xsd schemas from classes or vice versa and then to
create property schemas and then promote elements but why is it that creating
a class with the correct decorations does not do the same only for defining
correlationTypes but is enough for the orchestration itself?
Is there any way to do this in code?
--
PeterW
| |
| PeterW 2005-09-08, 5:51 pm |
| Is there a way for a message which is obtained from a WebService WebMethod
Response to have a Message Type based on a reference to an Assembly whilst at
the same time conforming to a schema with promoted elements that have been
promoted using a property schema? If so, how is the relationship between the
assembly and the schema/property schemas managed?
If assemblies cannot be used for correlationTypes then it appears to me that
the message's Message Type must always be bound to a schema which in turn has
its elements promoted using one or more property schemas and that binding to
a referenced assembly only works for anything that does not need to use
correlation.
Is that assumption wrong?
cheers
--
PeterW
"PeterW" wrote:
> I note that decorating class properties with the
> [DistinguishedFiledAttribute] is not enough for make the property usable in
> CorrelationSets and that a property schema must be used. If one is using
> assembly references to identify a class in a message, then the object being
> is being serialized from a class.
>
> This must mean that in addition the classes that have been created using the
> XLANGs.BaseTypes and [DistinguishedFiledAttribute] is not enough and that
> schemas and property schemas must also be maintained.
>
> I notice that if you access a message element that is based on a class
> instance, that an orchestration will accept that for assigning to
> orchestration variiables so they are obviously visible.
>
> My question is why is any non BizTalk assembly installed in the gac and
> referenced by a BizTalk project, not visible to the correlation properties
> dialog box? Or have I missed something along the way? I know that it is not
> difficult to generate xsd schemas from classes or vice versa and then to
> create property schemas and then promote elements but why is it that creating
> a class with the correct decorations does not do the same only for defining
> correlationTypes but is enough for the orchestration itself?
>
> Is there any way to do this in code?
> --
> PeterW
| |
| Matt Milner 2005-09-08, 5:51 pm |
| I think I have a sample that will provide answers to what you are looking
for on my old blog:
http://www.m3technologypartners.com...e8-ea70a1ed69ab
Take a look at the comments where I also talk about how to deal with the web
service issue you raised in your follow up post.
Thanks,
Matt
"PeterW" <nspw@noemail.nospam> wrote in message
news:C9A1DDAE-7CEF-439B-AAC7-6005A6445DB0@microsoft.com...
>I note that decorating class properties with the
> [DistinguishedFiledAttribute] is not enough for make the property usable
> in
> CorrelationSets and that a property schema must be used. If one is using
> assembly references to identify a class in a message, then the object
> being
> is being serialized from a class.
>
> This must mean that in addition the classes that have been created using
> the
> XLANGs.BaseTypes and [DistinguishedFiledAttribute] is not enough and that
> schemas and property schemas must also be maintained.
>
> I notice that if you access a message element that is based on a class
> instance, that an orchestration will accept that for assigning to
> orchestration variiables so they are obviously visible.
>
> My question is why is any non BizTalk assembly installed in the gac and
> referenced by a BizTalk project, not visible to the correlation properties
> dialog box? Or have I missed something along the way? I know that it is
> not
> difficult to generate xsd schemas from classes or vice versa and then to
> create property schemas and then promote elements but why is it that
> creating
> a class with the correct decorations does not do the same only for
> defining
> correlationTypes but is enough for the orchestration itself?
>
> Is there any way to do this in code?
> --
> PeterW
| |
| PeterW 2005-09-09, 7:49 am |
| Matt
That looks right on the money to me on all counts. I am away from my
development machine at the momemnt but will try this out on Monday. I'll let
you know how I get on.
I really appreciate your input.
cheers
--
PeterW
"Matt Milner" wrote:
> I think I have a sample that will provide answers to what you are looking
> for on my old blog:
> http://www.m3technologypartners.com...e8-ea70a1ed69ab
>
> Take a look at the comments where I also talk about how to deal with the web
> service issue you raised in your follow up post.
>
> Thanks,
> Matt
>
>
> "PeterW" <nspw@noemail.nospam> wrote in message
> news:C9A1DDAE-7CEF-439B-AAC7-6005A6445DB0@microsoft.com...
>
>
>
| |
| PeterW 2005-09-22, 7:49 am |
| Matt
On playing around the ball park a bit I have come to the conclusion that
the classes made available through the webService interface need to have a
reference to my schemas project (as it contains all the property schemas).
It also needs to have a reference to Microsoft.XLANGs.BaseTypes to allow it
to know what [DistinguishedField()] and [Property()] are and needless to say
to System and System.XML.Serialization for [Serializable].
When those are all present and an actual property schema exists, using an
attribute like
[Property(typeof(someSchemaNamespace.somepromotedproperty))]
can finally work as all the prerequisites are there and visible.
It means that interdependent schemas must be shared by related projects and
that WebServices which are accessed by BizTalk have a dependency on
Microsoft.XLANGs.BaseTypes that would otherwise not be there.
In that case I think that the compiler will stop reporting the class as non
serializable and forcing it to be used within an atomic scope. That is if
the class has been marked as [Serializable].
The proof of the pudding will be inthe eating. I will know this afternoon
when I go and make changes to the WebServices which are created by another
team. :-)
I wish to public acknowledge that access to the sort of input you have given
is invaluable in unsnarling what could otherwise be unsurmountable issues and
is very much apprecaited.
cheers
--
PeterW
"PeterW" wrote:
[vbcol=seagreen]
> Matt
>
> That looks right on the money to me on all counts. I am away from my
> development machine at the momemnt but will try this out on Monday. I'll let
> you know how I get on.
>
> I really appreciate your input.
>
> cheers
> --
> PeterW
>
>
> "Matt Milner" wrote:
>
| |
| Matt Milner 2005-09-24, 8:48 pm |
| I'm not sure I totally followed what you are doing, but you shouldn't have
to change the web services you are calling or update their references in any
way. The changes you would make are to your web reference. You might need
to choose to "show all files" in your solution to see the schema for the web
service, but that is where you would make the changes and promote
properties. It won't really matter if the web service itself knows anything
about promotion or how you are managing correlation etc. in your
orchestration.
Your orchestration should already have a reference to everything anyway as
you are creating correlation sets and have references to the schemas for
your message types.
So, just to be clear, web services accessed by BizTalk, regardless of what
you are doing with correlation and property promotion, have no dependencies
on BizTalk or BizTalk binaries.
Matt
"PeterW" <nspw@noemail.nospam> wrote in message
news:4C3D82C4-596F-4EA3-9885-1FB1408B5A80@microsoft.com...[vbcol=seagreen]
> Matt
>
> On playing around the ball park a bit I have come to the conclusion that
> the classes made available through the webService interface need to have a
> reference to my schemas project (as it contains all the property schemas).
> It also needs to have a reference to Microsoft.XLANGs.BaseTypes to allow
> it
> to know what [DistinguishedField()] and [Property()] are and needless to
> say
> to System and System.XML.Serialization for [Serializable].
>
> When those are all present and an actual property schema exists, using an
> attribute like
> [Property(typeof(someSchemaNamespace.somepromotedproperty))]
> can finally work as all the prerequisites are there and visible.
>
> It means that interdependent schemas must be shared by related projects
> and
> that WebServices which are accessed by BizTalk have a dependency on
> Microsoft.XLANGs.BaseTypes that would otherwise not be there.
>
> In that case I think that the compiler will stop reporting the class as
> non
> serializable and forcing it to be used within an atomic scope. That is if
> the class has been marked as [Serializable].
>
> The proof of the pudding will be inthe eating. I will know this afternoon
> when I go and make changes to the WebServices which are created by another
> team. :-)
>
> I wish to public acknowledge that access to the sort of input you have
> given
> is invaluable in unsnarling what could otherwise be unsurmountable issues
> and
> is very much apprecaited.
>
> cheers
> --
> PeterW
>
>
> "PeterW" wrote:
>
|
|
|
|
|