Hi,

Can I setup biztalk so I drop a message into the message
repository (Orchestration that monitors a File folder, and
just grabs the XML Document) and then have A number
of Orchestrations listening to that specific message type?
Orchestrations in this case could be in completely separate
deployments to the same Bt Server...

Any pointers on HOWTO:s, Tutorials or similar on this?

- Andreas

[ Post a follow-up to this message ]

Hi Andreas,
>
> Can I setup biztalk so I drop a message into the message
> repository (Orchestration that monitors a File folder, and
> just grabs the XML Document) and then have A number
> of Orchestrations listening to that specific message type?
> Orchestrations in this case could be in completely separate
> deployments to the same Bt Server...

Sure, just bind all your orchestration's receives to the same receive port.


--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/

[ Post a follow-up to this message ]

Hi Tomas, and thanks for the response.

Does this mean that It is possible to add new orchestrations that
listen to these ports in runtime? Meaning I roll-out new
Trading partners without actually having to redeploy all the
orchestrations tied to this port?

I have read somewhere a message in the Biztalk system must
have a subscription otherwise it will raise an error?

-Andreas


"Tomas Restrepo (MVP)" wrote:

> Hi Andreas, 
>
> Sure, just bind all your orchestration's receives to the same receive port
.
>
>
> --
> Tomas Restrepo
> tomasr@mvps.org
> http://www.winterdom.com/
>
>
>

[ Post a follow-up to this message ]

Hi Andreas,

> Does this mean that It is possible to add new orchestrations that
> listen to these ports in runtime?

OK, you lost me here. What do you mean by "at runtime"?

> Meaning I roll-out new
> Trading partners without actually having to redeploy all the
> orchestrations tied to this port?

Not sure what you mean here. Do you need dynamic receive ports, or what?

> I have read somewhere a message in the Biztalk system must
> have a subscription otherwise it will raise an error?

Sure it does, but that gets created when you bind your orchestration to the
receive port and enlist it. Multiple orchestrations can be bound to the same
receive port (i.e. each one is subscribed to messages arriving through that
receive port), and so, when the port publishes a new message, a new instance
of each subscribed orchestration is initiated (I'm not considering
correlations here, but those are pretty much subscriptions, as well).


--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/

[ Post a follow-up to this message ]

Hi, Sorry for the confusion,

"Tomas Restrepo (MVP)" wrote:

> Hi Andreas,
> 
>
> OK, you lost me here. What do you mean by "at runtime"?
>
The concepts inside biztalk still confuse me, but what I want to accomplish
is having a standard Corporate XML Schema for External Order,
and then have external maps from various partners
and vendors to this corporate standard object (ExternalOrder).

Thus I can just add a for example a HTTP pipeline (Dynamic Port?) to
this new partners URL and then add a map from the partner-format to
the internal ExternalOrder format.

I can then deploy the solution and it will "jack in" to my already running
business processes without having to rebuild and redeploy all existing
integrations that are using the same Schema.
 
>
> Not sure what you mean here. Do you need dynamic receive ports, or what?

Yes, I believe I mean that, but there is also the need for
a) adding new map between external format and internal format
b) having the internal already-running business processes keep processing
these messages from this new partner.

> 
>
> Sure it does, but that gets created when you bind your orchestration to th
e
> receive port and enlist it. Multiple orchestrations can be bound to the sa
me
> receive port (i.e. each one is subscribed to messages arriving through tha
t
> receive port), and so, when the port publishes a new message, a new instan
ce
> of each subscribed orchestration is initiated (I'm not considering
> correlations here, but those are pretty much subscriptions, as well).
>
>

Hmm it sounds like it is doable then, I can freely add and remove
orchestrations
that listen to this receive port without recompiling and redeploying the who
le
bunch?

1) Common entry for all XML documents
2) Route XML document based on SenderInfo inside XML document
3) Call Orchestration (in a completely different project) that handles
the Order Process (generic entry xsd and generic process flow)

-Andreas

> --
> Tomas Restrepo
> tomasr@mvps.org
> http://www.winterdom.com/
>
>
>

[ Post a follow-up to this message ]

Hi Andreas,

> The concepts inside biztalk still confuse me, but what I want to
> accomplish
> is having a standard Corporate XML Schema for External Order,
> and then have external maps from various partners
> and vendors to this corporate standard object (ExternalOrder).

Sounds like what you want is what is usually known as "document
normalization". IOW, you have various people sending you documents which in
essence contain the same kind of data but with different formats, and you
map them all to a single [equivalent] internal document format so that y
ou
can process them using the same process (pun intented)

> Thus I can just add a for example a HTTP pipeline (Dynamic Port?) to
> this new partners URL and then add a map from the partner-format to
> the internal ExternalOrder format.
>
> I can then deploy the solution and it will "jack in" to my already running
> business processes without having to rebuild and redeploy all existing
> integrations that are using the same Schema.
> 
>
> Yes, I believe I mean that, but there is also the need for
> a) adding new map between external format and internal format
> b) having the internal already-running business processes keep processing
> these messages from this new partner.

You don't really need all that. There really isn't something like dynamic
receive ports, it makes no sense in this context. Sounds to me like what you
want is this:

Have a single receive port: In this case you have a single receive port
through which all messages arrive, independent of who sent them (your
partners). It doesn't matter that they have different formats or that they
arrive through different protocols, since you can have multiple receive
locations inside this receive port.

So here you might have, for example a single receive port with both an HTTP
receive location and a WebService (SOAP) receive location, receiving
different XML formats. The port can then have multiple maps configured, and
biztalk will apply the correct one when the message is received: this is
done after the receive pipeline processes the message, and so biztalk can
use the message type discovered by the disassembler to use the correct map.

Then you just have a single orchestration, as usual.

You can also use the TPM (Trading Partner Management) facilities and BAS to
do things like identify the partner that sent the message and possibly
"parameterize" your business process depending on that.


> Hmm it sounds like it is doable then, I can freely add and remove
> orchestrations
> that listen to this receive port without recompiling and redeploying the
> whole
> bunch?

Certainly. Each orchestration can be stopped/unenlisted/unbound
independently, though in BizTalk 2004 this is not so obvious (since the
management tool itself doesn't allow you to do deployments). Keep in mind,
though, that for this to work correctly you might need to do some work on
how your deployments work and make sure you have made things "modular" by
correctly splitting orchestrations, schemas and maps across multiple
assemblies in order to manage dependencies (since deployment/undeployment
happens at the assembly level).


--
Tomas Restrepo
tomasr@mvps.org
http://www.winterdom.com/

[ Post a follow-up to this message ]

Hi Tomas, thanks for the much helpful information.

Yes, I was confused where the message dropoff/pickup was located
so I could group my orchestrations accordingly. Seems it is at the
ports, so this means my original design thought would be to
have just something like 4 assembiles
#1) Receives any XML, uses Port Types and maps to all valid External
Schemas. Then maps against internal objects
#2) Triggers on the internal objects and does the actual business
processes.
#3) Common Schemas
#4) Partner Schemas

I understand now that internally biztalk checks the messages and detects
the schema of the message, thus is able to trigger the proper orchestrations
who are using these schemas as part of a Port mapping.

Again thanks for helping out with this :-)

- Andreas

> Certainly. Each orchestration can be stopped/unenlisted/unbound
> independently, though in BizTalk 2004 this is not so obvious (since the
> management tool itself doesn't allow you to do deployments). Keep in mind,
> though, that for this to work correctly you might need to do some work on
> how your deployments work and make sure you have made things "modular" by
> correctly splitting orchestrations, schemas and maps across multiple
> assemblies in order to manage dependencies (since deployment/undeployment
> happens at the assembly level).
>


"Tomas Restrepo (MVP)" wrote:

> Hi Andreas,
> 
>
> Sounds like what you want is what is usually known as "document
> normalization". IOW, you have various people sending you documents which i
n
> essence contain the same kind of data but with different formats, and you
> map them all to a single [equivalent] internal document format so that
 you
> can process them using the same process (pun intented)
> 
>
> You don't really need all that. There really isn't something like dynamic
> receive ports, it makes no sense in this context. Sounds to me like what y
ou
> want is this:
>
> Have a single receive port: In this case you have a single receive port
> through which all messages arrive, independent of who sent them (your
> partners). It doesn't matter that they have different formats or that they
> arrive through different protocols, since you can have multiple receive
> locations inside this receive port.
>
> So here you might have, for example a single receive port with both an HTT
P
> receive location and a WebService (SOAP) receive location, receiving
> different XML formats. The port can then have multiple maps configured, an
d
> biztalk will apply the correct one when the message is received: this is
> done after the receive pipeline processes the message, and so biztalk can
> use the message type discovered by the disassembler to use the correct map
.
>
> Then you just have a single orchestration, as usual.
>
> You can also use the TPM (Trading Partner Management) facilities and BAS t
o
> do things like identify the partner that sent the message and possibly
> "parameterize" your business process depending on that.
>
> 
>
> Certainly. Each orchestration can be stopped/unenlisted/unbound
> independently, though in BizTalk 2004 this is not so obvious (since the
> management tool itself doesn't allow you to do deployments). Keep in mind,
> though, that for this to work correctly you might need to do some work on
> how your deployments work and make sure you have made things "modular" by
> correctly splitting orchestrations, schemas and maps across multiple
> assemblies in order to manage dependencies (since deployment/undeployment
> happens at the assembly level).
>
>
> --
> Tomas Restrepo
> tomasr@mvps.org
> http://www.winterdom.com/
>
>
>

[ Post a follow-up to this message ]

I'm replying to myself here, to read more about Document Normalization

(http://blogs.msdn.com/biztalk_core_.../13/228633.aspx)

- AW

"AW" wrote:
[vbcol=seagreen]
> Hi Tomas, thanks for the much helpful information.
>
> Yes, I was confused where the message dropoff/pickup was located
> so I could group my orchestrations accordingly. Seems it is at the
> ports, so this means my original design thought would be to
> have just something like 4 assembiles
> #1) Receives any XML, uses Port Types and maps to all valid External
> Schemas. Then maps against internal objects
> #2) Triggers on the internal objects and does the actual business
> processes.
> #3) Common Schemas
> #4) Partner Schemas
>
> I understand now that internally biztalk checks the messages and detects
> the schema of the message, thus is able to trigger the proper orchestratio
ns
> who are using these schemas as part of a Port mapping.
>
> Again thanks for helping out with this :-)
>
> - Andreas
> 
>
>
> "Tomas Restrepo (MVP)" wrote:
> 

[ Post a follow-up to this message ]