Now that should confuse you.

I have an input schema where I have multiple parent records, each with child
records.

I want to be able to pass the messages to my orchestration as one parent per
message, rather than all the parents at once.

So as an example, the way I have it now, my stored procedure returns
parent1(+children), parent2(+children) and one orchestration gets fired to
handle the lot.

I want to have two orchestrations fired - one for each parent. I am sure
there is a setting somewhere that encourages the original message to be
broken into mini messages.

Obviously, what I want is the output to be one parent per file.

Any suggestions on how to do this?

Thanks
Steve

[ Post a follow-up to this message ]

Steve,

I'm not sure if this is exactly your scenario but I wrote a short article
describing how to logically split an XML document. I hope this helps.

http://codebetter.com/blogs/jeff.ly...les/128664.aspx

--
Jeff Lynch
"Ramblings From A [Microsoft] Connected Universe"
http://codebetter.com/blogs/jeff.lynch


"SteveM" <SteveM@discussions.microsoft.com> wrote in message
news:97C44148-6E85-4240-B292-3860E81CC7BA@microsoft.com...
> Now that should confuse you.
>
> I have an input schema where I have multiple parent records, each with
> child
> records.
>
> I want to be able to pass the messages to my orchestration as one parent
> per
> message, rather than all the parents at once.
>
> So as an example, the way I have it now, my stored procedure returns
> parent1(+children), parent2(+children) and one orchestration gets fired to
> handle the lot.
>
> I want to have two orchestrations fired - one for each parent. I am sure
> there is a setting somewhere that encourages the original message to be
> broken into mini messages.
>
> Obviously, what I want is the output to be one parent per file.
>
> Any suggestions on how to do this?
>
> Thanks
> Steve

[ Post a follow-up to this message ]

Thanks Jeff, this looks pretty close to what I want and I will play with it
over the weekend to bend it to me needs.

The basic difference appears to be that I actually have mutiple headers,
rather than needing to repeat a single header. (If I read your blog
correctly).

Cheers
Steve

"Jeff Lynch" wrote:

> Steve,
>
> I'm not sure if this is exactly your scenario but I wrote a short article
> describing how to logically split an XML document. I hope this helps.
>
> http://codebetter.com/blogs/jeff.ly...les/128664.aspx
>
> --
> Jeff Lynch
> "Ramblings From A [Microsoft] Connected Universe"
> http://codebetter.com/blogs/jeff.lynch
>
>

[ Post a follow-up to this message ]

Steve,

Yes I did have a single header. If you actually have different instance
documents within a single interchange and just need to split it up, there
are much simpler methods and Stephen Thomas [MVP - BizTalk] has done a l
ot
of work on this.

http://www.biztalkgurus.com/Labs/Me...h-Envelope.html
--
Jeff Lynch
"Ramblings From A [Microsoft] Connected Universe"
http://codebetter.com/blogs/jeff.lynch


"SteveM" <SteveM@discussions.microsoft.com> wrote in message
news:5A91B576-BB58-4BB3-B3EC-4FA26F9563F7@microsoft.com...
> Thanks Jeff, this looks pretty close to what I want and I will play with
> it
> over the weekend to bend it to me needs.
>
> The basic difference appears to be that I actually have mutiple headers,
> rather than needing to repeat a single header. (If I read your blog
> correctly).
>
> Cheers
> Steve
>
> "Jeff Lynch" wrote:
> 
>

[ Post a follow-up to this message ]

Hi Guys,

I think you need some best practice in this case.

First Jeff :

I saw your site, it is interesting how you deal with the orchestration
and all the bla bla, however what you could do, is instead of doing
your mapping inside an orchestration you could have done it straight in
the port. In the inbound maps, it is much quicker! like this the
orchestration receives directely the correct mapping.


Second Steve :

There is a fantastic tric, I do not know if it applies for your case
but here is the case:
- In the schema you must declare in the part that repeats its self that
the max occurs is "1"
- The pipeline will interpret the message it receives and split it into
as many parts as it is necessary.
Example:
if you have a message that is something like
<Root>
<PurchaseOrder>
<bla/>
<bli/>
<blou/>
</PurchaseOrder>
<PurchaseOrder>
<bla/>
<bli/>
<blou/>
</PurchaseOrder>
</Root>
Then in your Schema you declare the PurchaseOrder as having max occurs
equal to 1
The pipeline will do the splitting, and you'll have two orchestration
started.

Hope this will help you guys
Stefan

[ Post a follow-up to this message ]

Hi Guys,

I think you need some best practice in this case.

First Jeff :

I saw your site, it is interesting how you deal with the orchestration
and all the bla bla, however what you could do, is instead of doing
your mapping inside an orchestration you could have done it straight in
the port. In the inbound maps, it is much quicker! like this the
orchestration receives directely the correct mapping.


Second Steve :

There is a fantastic tric, I do not know if it applies for your case
but here is the case:
- In the schema you must declare in the part that repeats its self that
the max occurs is "1"
- The pipeline will interpret the message it receives and split it into
as many parts as it is necessary.
Example:
if you have a message that is something like
<Root>
<PurchaseOrder>
<bla/>
<bli/>
<blou/>
</PurchaseOrder>
<PurchaseOrder>
<bla/>
<bli/>
<blou/>
</PurchaseOrder>
</Root>
Then in your Schema you declare the PurchaseOrder as having max occurs
equal to 1
The pipeline will do the splitting, and you'll have two orchestration
started.

Hope this will help you guys
Stefan

[ Post a follow-up to this message ]

There are a number of ways of splitting an incoming batch into multiple
messages.
The choice of which one you use will vary depending on your requirements.
Splitting in the pipeline using the disassembler is the most efficient but
will not always be the best choice.
A good example:
On Biztalk 2004 has no recoverable batch processing (new feature in 2006).
If one of the child messages fails processing in the pipeline (e.g.
Validation error) Then then entire batch of messages will fail. By moving
this into an orchestration you can have more control, catch exceptions and
only reject the offending message.
There are a number of good reasons for using an orchestration - I would
suggest reading Stephan Thomas' paper that Jeff mentioned.

Both the FFDisassembler and XmlDisassembler will split incoming batches into
multiple messages, however the mechanism is different for each.
If you are receiving a Flat File then you can use the maxOccurs=1 technique
as mentioned.
If you are receiving an Xml file then you should use an Envelope and message
schema..


Greg

<maltistefan@yahoo.co.nz> wrote in message
news:1142591136.582338.134560@e56g2000cwe.googlegroups.com...
> Hi Guys,
>
> I think you need some best practice in this case.
>
> First Jeff :
>
> I saw your site, it is interesting how you deal with the orchestration
> and all the bla bla, however what you could do, is instead of doing
> your mapping inside an orchestration you could have done it straight in
> the port. In the inbound maps, it is much quicker! like this the
> orchestration receives directely the correct mapping.
>
>
> Second Steve :
>
> There is a fantastic tric, I do not know if it applies for your case
> but here is the case:
> - In the schema you must declare in the part that repeats its self that
> the max occurs is "1"
> - The pipeline will interpret the message it receives and split it into
> as many parts as it is necessary.
> Example:
> if you have a message that is something like
> <Root>
>  <PurchaseOrder>
>    <bla/>
>    <bli/>
>    <blou/>
>  </PurchaseOrder>
>  <PurchaseOrder>
>    <bla/>
>    <bli/>
>    <blou/>
>  </PurchaseOrder>
> </Root>
> Then in your Schema you declare the PurchaseOrder as having max occurs
> equal to 1
> The pipeline will do the splitting, and you'll have two orchestration
> started.
>
> Hope this will help you guys
> Stefan
>

[ Post a follow-up to this message ]

Thanks Greg,

> If you are receiving an Xml file then you should use an Envelope and messa
ge
> schema..

This is what I will be doing. Do you have any exmaples you can point me at?

BTW - using BTS 2006

Basically, I have a XML schema generated from SQL Server

<Calls>
<Job>
.. elements/attributes ...
</Job>
</Calls>

Used this as my Envelope schema (And set the Envelope property of the Schema
node to Yes)

Took
<Job>
.. elements/attributes ...
</Job>
and used it as my document

Created a pipeline which specifed the element and document schemas

Created a new map to use the document instead of the envelope.

However, despite not making any changes to the receive pipeline (only the
underlying schema), apparently the schema of the selected data no longer
matches any of the given schemas.

Will try different combinations in the pipeline, but would appreciate any
pointers to this approach.

Otherwise I may have to try the approach suggested by Jeff

Thanks
Steve

"Greg Forsythe" wrote:

> There are a number of ways of splitting an incoming batch into multiple
> messages.
> The choice of which one you use will vary depending on your requirements.
> Splitting in the pipeline using the disassembler is the most efficient but
> will not always be the best choice.
> A good example:
> On Biztalk 2004 has no recoverable batch processing (new feature in 2006).
> If one of the child messages fails processing in the pipeline (e.g.
> Validation error) Then then entire batch of messages will fail. By moving
> this into an orchestration you can have more control, catch exceptions and
> only reject the offending message.
> There are a number of good reasons for using an orchestration - I would
> suggest reading Stephan Thomas' paper that Jeff mentioned.
>
> Both the FFDisassembler and XmlDisassembler will split incoming batches in
to
> multiple messages, however the mechanism is different for each.
> If you are receiving a Flat File then you can use the maxOccurs=1 techniqu
e
> as mentioned.
> If you are receiving an Xml file then you should use an Envelope and messa
ge
> schema..
>
>
> Greg
>

[ Post a follow-up to this message ]

With an Envelope schema you also need to specify the node that contains the
documents.
You need to set the Body Xpath property on the root node.
In your case this should be set to the root node itself -> Calls.
This will produce a new message for each child of the <Calls> node.

Greg

"SteveM" <SteveM@discussions.microsoft.com> wrote in message
news:DB6BD260-674C-407C-918B-6549F2933AC8@microsoft.com...
> Thanks Greg,
> 
>
> This is what I will be doing. Do you have any exmaples you can point me
> at?
>
> BTW - using BTS 2006
>
> Basically, I have a XML schema generated from SQL Server
>
> <Calls>
>  <Job>
>    ... elements/attributes ...
>  </Job>
> </Calls>
>
> Used this as my Envelope schema (And set the Envelope property of the
> Schema
> node to Yes)
>
> Took
>  <Job>
>    ... elements/attributes ...
>  </Job>
> and used it as my document
>
> Created a pipeline which specifed the element and document schemas
>
> Created a new map to use the document instead of the envelope.
>
> However, despite not making any changes to the receive pipeline (only the
> underlying schema), apparently the schema of the selected data no longer
> matches any of the given schemas.
>
> Will try different combinations in the pipeline, but would appreciate any
> pointers to this approach.
>
> Otherwise I may have to try the approach suggested by Jeff
>
> Thanks
> Steve
>
> "Greg Forsythe" wrote:
> 
>

[ Post a follow-up to this message ]

Thanks Greg, still getting the error message though.

When I google for the message, the first two posts tell me that this is not
possible due to the schema not having a fully qualified assembly name to
search for (or some such).

Apparently this was a problem in BTS 2004 and appears to continue to be so
in BTS 2006

When tested just loading my data and dumping with XML Receive, no trouble.
As soon as I put in a custom pipeline for the XML document, it all falls ove
r.

I believe Jeff came across this problem at some stage also.


"Greg Forsythe" wrote:

> With an Envelope schema you also need to specify the node that contains th
e
> documents.
> You need to set the Body Xpath property on the root node.
> In your case this should be set to the root node itself -> Calls.
> This will produce a new message for each child of the <Calls> node.
>
> Greg
>

[ Post a follow-up to this message ]