Hi,

Soon I need to deploy a new version of our orchestrations and messages.
We're running version 1.0 of everything on the live server and when I
build for our next deployment I'm going to set the new version to 1.1.
This is because we have many orchestrations waiting for responses from
our customers. I don't want the new 1.1 version to disturb the running
processes in 1.0. New "orders" should run on 1.1 and old ones that
correlates to an ID in a 1.0 orchestration should ofcourse continue its
process.

We use web services to receive all messages to the orchestrations and
these are created (bts web service wizard) for a specific version of
the orchestration (right?), at least the version is mentioned in the
attributes of the web services. The expected input is also changed from
1.0 to 1.1 because of schema changes.

How should I handle this problem? I need my web service to be able to
handle both 1.0 and 1.1 responses from our customers depending on wich
assembly version they where started on.

[ Post a follow-up to this message ]

Hi Magnus,

You Can not deploy more than one copy of the same schema with the same
namespace - as the combination of schema &root-node-name is the primary key,
to look up the schema for an incoming message.
You can go with a library assembly for the schema but as you said you change
some element from the old schema to the new one it will be than more
complicated.
why you didn't chose business rule engine to handle that rather than having
to version??

Younes
"Magnus" <larsson76@gmail.com> wrote in message
news:1132332915.953396.47780@g49g2000cwa.googlegroups.com...
> Hi,
>
> Soon I need to deploy a new version of our orchestrations and messages.
> We're running version 1.0 of everything on the live server and when I
> build for our next deployment I'm going to set the new version to 1.1.
> This is because we have many orchestrations waiting for responses from
> our customers. I don't want the new 1.1 version to disturb the running
> processes in 1.0. New "orders" should run on 1.1 and old ones that
> correlates to an ID in a 1.0 orchestration should ofcourse continue its
> process.
>
> We use web services to receive all messages to the orchestrations and
> these are created (bts web service wizard) for a specific version of
> the orchestration (right?), at least the version is mentioned in the
> attributes of the web services. The expected input is also changed from
> 1.0 to 1.1 because of schema changes.
>
> How should I handle this problem? I need my web service to be able to
> handle both 1.0 and 1.1 responses from our customers depending on wich
> assembly version they where started on.
>

[ Post a follow-up to this message ]

Versioning the web service with different schema generally means creating a
new service endpoint, or for BizTalk, republishing your orchestration.

Versioning for the orchestration is using .net versioning as you have done.
When you deploy version 1.1, stop the version 1.0 orchestration and start
the 1.1 version.  Those items that are in-flight will continue to process
with the messages and state they already have (1.0), and new messages coming
in will get routed to your 1.1 version.

Matt

"Younes Amar" <y_amar@msn.com> wrote in message
news:OAklScH7FHA.3276@TK2MSFTNGP15.phx.gbl...
> Hi Magnus,
>
> You Can not deploy more than one copy of the same schema with the same
> namespace - as the combination of schema &root-node-name is the primary
> key, to look up the schema for an incoming message.
> You can go with a library assembly for the schema but as you said you
> change some element from the old schema to the new one it will be than
> more complicated.
> why you didn't chose business rule engine to handle that rather than
> having to version??
>
> Younes
> "Magnus" <larsson76@gmail.com> wrote in message
> news:1132332915.953396.47780@g49g2000cwa.googlegroups.com... 
>
>

[ Post a follow-up to this message ]

Matt,

Thanks for your reply. If I understand you correctly the only thing i
need to do for the orchestrations is to stop the 1.0 version and
deploy/enlist/start the 1.1 version. That way new messages will be
routed to the 1.1 version. That's sort of good new but only solves part
of my problem. What can I do about the message assemblies? For
information we don't use any schema validations in the receive
pipelines. It's a bit difficult to tell our customers to send old
messages to a certain web service and new messages to another one...

Younes was talking about the business rule engine as a solution but
where not using that in this project and I have no experience of it.
Can you tell me some more about a solution using the business rule
engine?

//magnus

[ Post a follow-up to this message ]

Hi Younes,

I just thought I had to create a new version to be able to deploy it
because of the old version.

//Magnus

[ Post a follow-up to this message ]